Case Study · 3D Systems · PLM & MRP · 2013–2019
The change was approved. The consequence wasn't.
A flag is a small thing
Every purchased or manufactured item in an ERP carries a flag that says whether the company makes it or buys it. It is one field. Flip it on a parent assembly and the planning engine does exactly what you asked: it starts generating a purchase signal for the finished assembly, and it stops generating purchase signals for every component underneath it — because if you're buying the assembly whole, you don't need its parts.
That logic is correct. It is also how a production line quietly starves.
The first one: a truth that hadn't happened yet
I was new, and I had just taken over the sourcing and procurement for an entire production line. My job in that seat is simple to state: keep material flowing so the factory stays alive.
The buyer before me had been working a project to outsource an assembly we were currently building ourselves. That project generated an engineering change order, and the change order flipped the assembly from make to buy. Every step of that was legitimate. The problem was timing — the outsourcing work was maybe ten percent complete. No supplier was ready. We were still building the assembly in-house, out of components the system had just stopped telling anyone to order.
The record had gotten ahead of reality. It described a future state as though it were the present one.
I didn't find it by auditing the system, because I didn't yet know that was a thing to look for. I found it walking the production line counting parts in the bins, doing the physical inventory check that new buyers do because they don't trust anything yet. The counts didn't match what I expected. Tracing back from there led to the flag.
When I raised it, nobody argued. Everyone agreed immediately that it had to be reversed. That is worth noting: this was not a failure of judgment that anyone defended. It was a consequence nobody had looked for.
One field, changed by an approved change order. Everything below it goes dark.
The second one: a truth that was never true
Years later I was the senior analyst, and by then I had built an MRP dashboard projecting fifty-two weeks of net-available inventory across roughly three thousand purchased components. I ran it weekly and recalibrated it against actuals.
One week the inventory position on a machine looked wrong and kept getting worse. Nothing about it made sense — until I worked backward. We weren't placing orders. We weren't placing orders because the buyer wasn't getting signals. The buyer wasn't getting signals because a change order had flipped that machine from make to buy.
This one wasn't premature. It was simply a mistake — someone released a change and didn't notice the flag was included in it, and the buyer downstream didn't catch it either. We reversed it before the line stopped.
What the two have in common
Different root causes. One was a record running ahead of reality; the other was a record that drifted sideways from it. What they share is more interesting than what separates them: in neither case did the change-control process surface its own consequence.
Both changes were raised properly, reviewed, and approved. The system did what it was told. What no step in that process did was trace what the change would do three levels down, to a buyer who had no idea a decision had been made about parts they were responsible for.
Detection came from outside both times. The first time it was my eyes on a bin. The second time it was instrumentation I had built for an entirely different reason.
The gap between the record and the floor
The lesson I've carried since is not really about make/buy flags. It's that PLM and ERP will always lag real-world action. There is no configuration that eliminates that. A system of record is a description of the physical world, written down by people, and the world keeps moving while the description sits still.
So the inherent goal — and the inherent difficulty — is keeping that gap as small as possible. That reframes a lot of work I've done since. BOM audits aren't hygiene; they're gap measurement. An MRP dashboard isn't reporting; it's an instrument pointed at the distance between what the system believes and what the floor is doing. Item master governance isn't administration; it's how fast the description catches up.
I've found that gap twice by accident. The interesting problem is finding it on purpose.