The ERP Is Often Blamed for Revealing a Problem It Didn’t Create | Observations from the Shop Floor
Michael Gardner, COO
The ERP is often blamed for revealing a problem it didn’t create: I learned this lesson long before I was on the software side of the conversation. I learned it as a customer implementing an ERP system.
At Goshen, we manufactured prehung door units, taking individual components and assembling them into finished products. When we implemented WoodWare, we used the Var-I-Frame method to define the relationships between the components and the finished units.
The concept itself made perfect sense. Build a particular door unit and the system knew which components should be consumed, along with the associated labor and burden. What we didn’t fully appreciate at the time was how much knowledge about building those units existed outside of those records.
Our shop floor was full of experienced tradesmen who knew how to get the job done. If a particular component wasn’t available, they often knew exactly what could be substituted without compromising the finished product. Their responsibility was to build the unit correctly, meet the customer’s requirements and get the order shipped, and they were very good at doing exactly that.
The challenge was that those substitutions didn’t always make their way back to the people responsible for maintaining the records.
The system might have been told that a particular unit required parts A, B and C, while the tradesman knew that under the right circumstances part D could replace part B. He used D, completed the unit and kept production moving. From the customer’s perspective, everything worked exactly as it should.
The inventory records told a different story.
The system relieved B because that was what we had told it should consume, while physically we had consumed D. Neither the tradesman nor the system had necessarily done anything wrong. We simply had two different versions of what had happened, and for the first time we had a system detailed enough to expose the difference.
In our prior ERP, many of those differences could disappear into the larger operation. We had experienced people who knew the business well enough to recognize when something didn’t look right. On the financial side, they had an almost encyclopedic understanding of what our expected gross profit should be and could recognize when something needed attention before an invoice went out. We benchmarked ourselves against the industry, and when we performed our year-end physical inventory, the overall variance was generally within what we considered a reasonable range.
From a financial perspective, the business looked right.
When we converted to WoodWare and began using Var-i-Frame to track perpetual inventory, however, we could see much more than the total variance. We could see which parts were wrong, how far they were off and, most importantly, begin asking why.
That visibility was valuable, but it didn’t immediately make things easier.
Our purchasing manager was one of those people who carried an enormous amount of operational knowledge with him. He had green-bar report after green-bar report, maintained safety-stock numbers and spent hours every week studying reports and walking the floor. Over the years, he had developed a very good sense of what we needed, when we needed it and how much was enough.
He knew how to make purchasing work.
Then we gave him an ERP system that calculated inventory requirements differently from the methods he had spent years learning. He also hadn’t been part of the team that built all of the new product records, so he had a perfectly reasonable concern about whether we had defined everything correctly in the first place.
In effect, we had taken away the compass he had spent years learning to navigate by and handed him another one that pointed in a way he didn’t yet understand.
Not surprisingly, he didn’t trust it.
For the first several months, he tried to reconcile what the ERP was telling him with the methods and experience that had served him well for years. Without a true north he trusted, our inventory investment began to climb.
Eventually we reached the point where continuing to debate whether the system was right wasn’t going to teach us anything. We needed to give it a chance to prove itself, so he and I made an agreement.
We would trust the system.
If inventory continued to grow, that was on me. If inventory came down but our fill rates suffered, that was on me too. But if inventory stabilized or decreased while our fill rates stayed the same or improved, the success belonged to him.
What followed didn’t happen overnight.
Inventory that had grown toward $4 million eventually dropped to roughly $2.7 million. Our fill rates improved, and our physical inventory variance continued to get better year after year.
Looking back, it would make a much cleaner ERP success story if I could say we installed a new system and immediately discovered more than a million dollars of excess inventory.
That isn’t what happened.
It took us roughly two years to really learn what the system was telling us.
During that time, we corrected product records. We investigated perpetual inventory differences instead of simply accepting the overall variance. We found places where what happened on the shop floor differed from what our records said should happen. We challenged assumptions we had carried for years. And, just as importantly, the people who already understood the operation began learning how to combine their experience with the information the system was giving them.
The ERP didn’t suddenly make us smarter. It gave us a different way to see the business, and we had to learn how to use that visibility.
Years later, now sitting on the other side of the ERP conversation, I still think about that experience whenever I hear someone say, “We never had this problem until we put the new system in.”
Sometimes they’re right. Software can certainly create problems, and a poorly implemented system can create plenty of them.
But sometimes the problem was already there.
Experienced people may have been compensating for it so effectively that no one recognized it as a problem. Financial results may have looked reasonable. A year-end physical inventory may have brought everything back into line. Someone may have walked the floor every morning and quietly reconciled what the reports said with what they knew to be true.
The business worked because good people knew how to make it work.
Then the ERP began keeping score at a level the organization hadn’t before. Suddenly those differences had item numbers, quantities, transactions and dollar values attached to them.
And when a problem becomes visible at the same time a new system arrives, it is very easy to believe the system created it.
Final Observation
There is a natural tendency during an ERP implementation to judge the new system against the way the business has always worked. When the numbers don’t agree, our first instinct may be to question the system, particularly when the people questioning it have years of experience telling them something different.
That experience matters. In fact, we eventually learned that the knowledge carried by the people on our shop floor and in purchasing was every bit as important as the information coming from the ERP. The opportunity wasn’t to choose one over the other. It was to bring the two together.
At Goshen, we spent nearly two years asking whether we could trust the new system. Along the way, we discovered records that needed correcting, processes that needed tightening and operational knowledge that had never made its way into any system at all.
In the end, perhaps the better question wasn’t whether we could trust the ERP.
It was whether we were willing to learn from what it was showing us.
Because sometimes the ERP didn’t create the problem; it was simply the first thing that made the problem visible enough to do something about it.