Introduction
A successful factory implementation (factory digitalization) does not end when the on-site workshop is completed. In many ways, the real implementation work begins after we leave the factory. The context of this article is factory digitalization in garment factories – implementation of real-time shop floor control system, quality control system and MES systems.
During the workshop, we observe the manufacturing process, understand the operational flow, identify checkpoints, study existing systems, and document the factory’s requirements. Once we return to our work location, the next challenge is to convert those observations into an actionable implementation plan. Read the previous article – Pre-Implementation Workshop.
This is where we conduct internal brainstorming, perform a detailed fit-gap analysis, cross-check the factory’s operational activities against our SaaS product, identify configuration requirements, and determine whether any product customization or new development is required.
The objective is simple:
Do not start implementation until we know exactly what needs to be configured, what needs to be developed, what the factory needs to prepare, and what our team needs to deliver.
From Workshop to Implementation
The overall journey can be viewed in three major stages:
- Pre-Workshop Activity → Workshop Plan Preparation → On-Site Workshop Activity
- Post-Workshop Analysis → Implementation Readiness → Implementation
- Post-Go-Live Support
The on-site workshop gives us the operational understanding. The post-workshop phase converts that understanding into a structured implementation plan.
Post-Workshop Brainstorming and Fit-Gap Analysis
At this stage, we cross-check the factory’s actual operational activities against the capabilities of our SaaS solution.
We ask several practical questions:
- Which factory processes are already supported?
- Which processes can be handled through standard configuration?
- Are there any process gaps?
- Does the factory require a different workflow?
- Are additional validations required?
- Are there any reporting or dashboard requirements?
- Are there integration dependencies?
- Is customization required?
- Are there hardware or infrastructure dependencies?
This exercise is essentially a fit-gap analysis between the factory’s current operational requirements and the available product functionality.
The purpose is not to customize everything the factory requests.
The purpose is to identify the minimum required changes that allow the solution to support the factory’s critical business processes without unnecessarily increasing implementation complexity.
Standard Configuration vs. Customization
After the fit-gap analysis, requirements generally fall into three categories.
1. Standard Functionality
The requirement is already supported by the product. In this case, we proceed with configuration and implementation planning.
2. Configuration Requirement
The functionality exists, but factory-specific parameters, workflows, master data, user roles, validations, or other settings need to be configured. The implementation team prepares the required configuration based on the information collected during the workshop.
3. Product Customization
The factory has a unique operational requirement that is not currently supported by the existing product functionality. In this situation, the requirement enters the product-development lifecycle.
This distinction is important because every customization has an impact on development effort, testing, UAT, deployment, project timelines, and future product maintenance.
Hardware and Infrastructure Readiness for Factory Digitalization
Software readiness alone is not enough for a shop-floor implementation.
During the workshop, we also identify the hardware, accessories, and infrastructure required to operate the solution effectively.
We prepare a Hardware Acceptance Requirement covering the required devices, accessories, connectivity, installation requirements, and other infrastructure dependencies.
The factory team can then arrange the required hardware either through the local market or through its preferred procurement channel.
Depending on the implementation scope, this may include:
- Shop-floor devices
- Scanners or data-capture devices
- Printers
- Display systems
- Dashboard TVs or monitors
- Required accessories and mounting arrangements
- Network infrastructure
- Wi-Fi/Internet connectivity
- Power and charging arrangements
However, purchasing the hardware is only the first step.
The hardware must also be tested in the actual operating environment.
A device may work perfectly in an office environment but perform differently on a production floor because of network coverage, distance from access points, interference, environmental conditions, or operational constraints.
Therefore, infrastructure readiness and connectivity validation should be completed before implementation begins.
Factory Readiness Before Implementation of the System (Factory Digitalization)
There are several activities that remain with the factory after the workshop.
The factory may need to:
- Purchase and arrange the required hardware.
- Complete hardware installation.
- Test device functionality.
- Verify Wi-Fi coverage across all required operating areas.
- Verify internet connectivity.
- Confirm power availability.
- Prepare required workstations or installation points.
- Prepare dashboard locations for TV or display installation.
- Ensure required users and departments are available for training and UAT.
- Prepare relevant master data and operational information.
For example, if a dashboard is expected to be displayed on a production-floor TV, the factory should identify the location, arrange the mounting infrastructure, ensure power and network connectivity, and make the display location ready before deployment.
These activities may appear small individually, but missing any one of them can delay implementation.
What Happens If No Customization Is Required?
If the fit-gap analysis confirms that there is no new product development or customization requirement, the implementation can move directly into the readiness stage.
At this point, we confirm the factory-side arrangements, infrastructure readiness, required hardware, master data, and stakeholder availability.
Once the required arrangements are confirmed, we can commit to starting the implementation within the agreed project timeline, typically within approximately one month depending on the project scope and readiness.
The important point is that the timeline should be based on actual readiness and dependencies, rather than simply promising a start date.
What Happens When Customization Is Required?
If customization is identified, the process becomes more structured.
We first document the requirement clearly and establish a development timeline covering:
Requirement Definition → Product Review → Development → QA Testing → UAT → Production Deployment
The client is informed about the expected timeline and the activities that need to be completed before implementation can begin.
This prevents a common implementation problem: starting the factory deployment while critical product functionality is still under development.
Lifecycle of a New Customized Product Requirement
When we encounter a unique factory process, we do not immediately jump into development.
First, we understand the requirement in depth.
Step 1: Observe the Unique Process
Study the process again using the workshop observations.
Document:
- Process steps
- Users involved
- Inputs and outputs
- Business rules
- Validations
- Exceptions
- Approval points
- Data requirements
- Reporting requirements
- Operational dependencies
The objective is to understand not only what the factory wants, but why the process works that way.
Step 2: Document and Obtain Client Approval
The observed requirement is documented in a clear and structured format.
The documentation should represent the actual factory process and expected system behavior.
The client reviews the requirement and confirms that the documented understanding is correct.
This becomes the baseline for product discussions and development.
Implementation Process Overview
1. User Story Creation
The approved requirement is converted into a structured User Story describing the business requirement, expected functionality, acceptance criteria, and relevant process details.
The User Story is then forwarded to the product team.
2. Product Team Review
The product team conducts an internal brainstorming and feasibility assessment.
The team evaluates:
- Business requirement
- Product impact
- Technical feasibility
- Existing functionality
- Reusability
- Dependencies
- Development effort
- Testing requirements
- Potential impact on other customers or modules
Based on this assessment, a technical JIRA ticket is created and the proposed solution is shared with the client for verification where required.
3. Client Approval and PBR Meeting
Once the client confirms the requirement and proposed functionality, a Product Backlog Review (PBR) meeting is conducted with the product and development teams.
During the PBR, the functionality is explained in detail, questions are clarified, dependencies are identified, and the development team receives a clear understanding of the expected outcome.
Only after the requirement is sufficiently clear should development begin.
4. Development and QA Testing
The development team implements the approved functionality.
Once development is completed, the solution moves through QA testing.
QA validates the functionality against the defined requirements and acceptance criteria and checks for functional issues, regression impact, and other relevant defects.
After successful QA verification, the build is promoted to the UAT environment.
5. User Acceptance Testing
The client or designated business users perform User Acceptance Testing (UAT) in the UAT environment.
The objective is to confirm that the functionality works according to the agreed business requirement and reflects the actual factory process.
Any UAT observations are documented, evaluated, and addressed through the appropriate process.
Once UAT is successfully completed, the solution becomes ready for production deployment.
6. Production Deployment
The validated functionality is deployed to the live production environment according to the approved release and deployment plan.
At this point, the implementation team can proceed with the relevant factory implementation activities.
Pre-Implementation Preparation
While product requirements are being finalized, the implementation environment also needs to be prepared.
1. Production Skeleton
A production skeleton is created based on the agreed implementation scope. The basic environment is prepared so that it can eventually be handed over to the client for implementation.
2. Configuration and Cross-Verification
Using the data collected during the workshop, we perform the required basic configuration. The configuration is then tested and cross-verified against the factory process.
This is an important checkpoint.
We should not assume that because configuration has been completed, the environment is automatically ready. The implementation team needs to verify that the configured workflows, masters, users, operations, validations, and other relevant settings behave as expected.
3. Issue and Defect Management
If any issue, configuration error, or defect is identified during the verification process, it is logged with the appropriate support or technical team.
The issue is tracked through resolution and retested.
The environment is considered implementation-ready only after the critical issues affecting deployment have been addressed.
Standard Operating Procedure
Every implementation should follow an established Standard Operating Procedure (SOP).
The SOP provides consistency across projects and ensures that important implementation activities are not missed.
A detailed Gantt chart should also be prepared covering:
- Activity
- Planned start date
- Planned completion date
- Responsible person/team
- Dependencies
- Deliverables
- Milestones
- Client responsibilities
- Implementation-team responsibilities
This creates a single project-level view of the implementation.
Typical Project Timeline
A typical implementation may take approximately 24 to 40 days, depending on factory capacity, location, operational complexity, number of users, number of modules, infrastructure readiness, customization requirements, and other project dependencies.
The timeline should therefore be treated as a planning range rather than a fixed number.
The most important factor is not simply completing the implementation quickly.
It is completing the implementation with the factory, infrastructure, users, product, and processes ready at the same time.
Core Implementation Activities
Once the project enters the implementation stage, the major activities include:
Software Deployment
Deploy and configure the SaaS solution according to the approved implementation scope.
End-User Training
Conduct training for the relevant factory users and stakeholders.
Training should be process-oriented rather than limited to explaining software screens.
Users should understand:
What to do → When to do it → Why the data is required → What happens to the data after submission.
Improvement and Change Management
During implementation, practical improvement points may emerge.
These should be evaluated carefully.
Minor changes can be handled through the established change process, while larger requirements should follow the same structured requirement, product, development, QA, and UAT lifecycle.
This prevents uncontrolled scope expansion during implementation.
Digitizing the Factory Process
One of the key objectives of a manufacturing SaaS implementation is not simply to replace one report with another.
The larger objective is to move the factory toward a more digitized and data-driven operating model.
- Manual reports can be converted into digital workflows.
- Paper-based data collection can be reduced.
- Production information can become available closer to real time.
- Quality information can be connected with production activity.
- Management can gain better visibility through dashboards and analytics.
The goal is to create a system where operational data is captured at the source and becomes available for decision-making without unnecessary manual consolidation.
Stakeholder Engagement
Technology implementation is ultimately a people-and-process transformation.
Therefore, continuous stakeholder engagement is required throughout the project.
We conduct multiple sessions with:
- Factory management
- Production teams
- Quality teams
- IT teams
- ERP teams
- Project coordinators
- Department heads
- End users
- Product and implementation teams
The purpose is to maintain alignment, resolve blockers quickly, manage expectations, and keep the project moving according to the agreed timeline.
Stakeholders should always know:
What has been completed → What is currently in progress → What is pending → Who is responsible → What is required next.
This level of visibility creates confidence during implementation.
Post-Go-Live Review and Hypercare
Going live does not mean the implementation is finished.
The initial post-go-live period is critical because users are now working with the system in the real production environment.
We allocate approximately four days for comprehensive post-implementation review and stabilization, depending on the project requirement.
During this period, we work closely with IT, management, and operational teams.
We demonstrate the value of real-time data and verify that the system is supporting the intended manufacturing processes.
Management Visibility and Digital Enablement
Once the core system is stable, additional visibility and communication capabilities can be configured.
These may include:
- Mobile access
- BI dashboards
- Management visibility
- Automated email scheduling
- Alerts and notifications
- Real-time production visibility
- Quality visibility
- Operational reporting
The objective is to ensure that the data captured at the shop floor is not trapped inside the application.
It should reach the right person, at the right time, in a form that supports decision-making.
Returning to the Factory
Once the environment is stable and the required configurations are completed, the implementation team returns to the client site when required to provide post-go-live support and stabilization.
This is where the difference between a software deployment and a manufacturing implementation becomes very clear.
The system has to work not only from a technical perspective but also within the reality of the factory.
- Users have to be comfortable.
- Devices have to work.
- Connectivity has to be reliable.
- Processes have to be followed.
- Data has to be captured correctly.
- Management has to see the expected visibility.
Only when these elements come together can we consider the implementation truly stabilized.
What Experience Teaches You
After working across different manufacturing environments, one lesson becomes increasingly clear:
The hardest part of implementation is rarely the software itself.
The difficult part is connecting the software with the reality of the factory.
Every factory has different people, processes, constraints, infrastructure, priorities, and ways of working.
That is why an implementation team cannot depend only on product knowledge.
- You need to understand manufacturing.
- You need to understand the shop floor.
- You need to understand people.
- You need to understand data.
And you need to understand how a process behaves when it moves from a presentation or process document into the real production environment.
A successful implementation therefore requires a combination of process understanding, product knowledge, technical readiness, stakeholder management, disciplined execution, and continuous feedback.
Conclusion
The factory workshop is not the end of discovery.
It is the point where observation becomes execution.
The real implementation journey starts when we return from the factory and begin converting shop-floor observations into product decisions, configurations, development requirements, infrastructure plans, implementation timelines, and measurable deliverables.
The sequence is straightforward:
- Understand the factory.
- Document the process
- Perform the fit-gap analysis.
- Configure what already exists.
- Develop what is genuinely required.
- Validate through QA and UAT.
- Prepare the factory infrastructure.
- Deploy the solution.
- Train the users.
- Stabilize the operation.
- And finally, measure the value created.
After years of working with manufacturing teams, I have learned that implementation success is not determined by how quickly software is deployed.
It is determined by how well the technology, process, people, data, and factory environment are brought together.
That is the difference between simply installing a SaaS product and actually enabling a factory to become more connected, more visible, and more data-driven.
I would keep Article One focused on discovering and understanding the factory, and make Article Two the “what happens after we leave the factory” story. That gives the series a logical progression rather than making both articles repeat the workshop itself.
Leave a Reply