Jerry Dolinsky is the CEO of Dozuki, a leading connected worker solution for enterprise-level manufacturing companies.
Early in my manufacturing career, I was working overseas when I was put in charge of a major traceability project. The objective sounded straightforward. We needed to trace raw materials through the manufacturing process into finished products. If there was a quality issue or recall, we needed to know exactly which products were affected.
The facility had more than 5,000 employees. It was vertically integrated, with multiple production areas and complex processes.
Then I learned something that changed my perspective on transformation projects: The implementation had already failed three times.
I wasn’t starting from zero. I was starting from negative three.
The Problem Was Bigger Than Technology
The existing processes showed how much work we had ahead of us. People were manually creating labels for raw materials using Microsoft Paint, printing them on paper, then using Excel spreadsheets to track where materials were located. Once those materials moved deeper into production and started getting combined, maintaining traceability became increasingly difficult.
We were preparing to introduce SAP warehouse management and quality management systems into an environment that had operated very differently for years.
It would have been tempting to view this as a technology implementation. I learned that it was really an organizational transformation involving people, processes and technology simultaneously.
Leaders should examine three dimensions:
• People: Who will have to behave differently once the new system exists?
• Process: Which workflows must change rather than simply become digital?
• Technology: What new capability will workers gain that they don’t have today?
If all three are changing, installing technology is only one part of the transformation.
We Started With Two People
Trying to transform all three dimensions across more than 5,000 people created too much complexity. So we went small—very small.
We searched the factory for the smallest operational area that still represented a complete production cycle. We found a flavor compounding room staffed by two people who made flavoring used in toothpaste. That became our starting point.
My reasoning was simple. If we couldn’t successfully implement the system with two people in a contained environment, we had no chance of implementing it across thousands.
Starting small doesn’t mean choosing something insignificant. A useful pilot should be small enough to control but complete enough to teach you something.
I would look for three characteristics in choosing the environment to test the idea:
• Contained: Can we control enough variables to understand what caused the result?
• Representative: Does this environment contain problems we’ll encounter at scale?
• Measurable: Can we establish a clear “before” state and compare it with what happens next?
The objective isn’t to find the easiest possible place to succeed. It’s to find the smallest possible version of the real problem.
Our Six Month Pilot Became A Learning System
We mapped the operation using the people, process and technology framework. Then, we involved the operators directly.
Instead of assuming we understood their work because we had documentation describing it, we asked how the process actually happened. That distinction is critical in manufacturing. The documented process and the performed process are rarely identical.
The operators told us where the friction was. They didn’t want to manually create labels. They wanted to print a barcode, attach it to the material, scan it and continue working. Their feedback shaped the implementation.
The pilot took around six months—considerably longer than we expected. But that delay taught us things we couldn’t have predicted during planning.
A useful pilot should expose:
• Bad Assumptions: What did we believe about the operation that turned out to be inaccurate?
• Hidden Work: What workarounds or decisions never appeared in the documented process?
• Worker Friction: Where did the new process make someone’s job harder?
Learning that something doesn’t work when two people are using it is relatively inexpensive. Learning the same lesson after deploying it to 5,000 people isn’t.
Success Changed The Adoption Conversation
Eventually, the pilot worked. Manual processes disappeared. Information became easier to access. Traceability improved. We finally had a functioning example of what the new operating model could look like.
Then, something happened that I think every transformation leader should pay attention to: Other areas of the facility started asking for it. Instead of trying to convince thousands of workers that a theoretical transformation would make their jobs better, we could show them a working example inside their own facility.
I would watch for three signals:
• Evidence: Can workers see a concrete improvement rather than another promise?
• Advocacy: Are pilot participants willing to tell colleagues that the change works?
• Demand: Are other teams beginning to ask for the same capability?
We took what we learned and expanded into another process area, then another. That expansion continued for more than three years.
A project that had failed three times eventually succeeded, not because we attacked the problem with greater force but because we reduced the initial scope.
Start Small Without Thinking Small
If I were starting manufacturing transformation today, I would follow six principles:
1. Start with an operational outcome. Identify the quality, scrap, downtime, throughput, safety or other metric you’re trying to change.
2. Find the smallest representative environment. Reduce variables without removing the realities you need to test.
3. Map people, process and technology. Understand how all three must change together.
4. Use the pilot to challenge assumptions. Treat surprises and failures as valuable information.
5. Produce evidence before expanding. Give people something they can observe rather than another transformation promise.
6. Scale one controlled success at a time. Apply what you learned before introducing the next set of variables.
The purpose of a pilot isn’t simply to prove that technology functions. It’s to reduce uncertainty before uncertainty becomes expensive.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?