A cheese factory, a WMS, and an ERP that refused to talk to it

Client anonymized. The work is described in full; the company is not named.

The problem

A process manufacturer made cheese at industrial scale. Two systems ran the operation, and they didn't get along.

On one side was the warehouse management system — the WMS — which tracked the physical world: what came off the dock, what moved into which cooler, what got consumed in production, what shipped, and when. On the other side was Ross ERP, the system of record for everything the business actually reported on: inventory valuation, orders, lot traceability, financials, compliance. The WMS knew where the cheese was. Ross knew what the cheese was worth, who it was promised to, and whether it could legally ship.

The two were supposed to agree. They didn't.

Every day, the physical reality on the floor drifted away from the numbers in Ross. A lot got split in the WMS and the split didn't land in the ERP. A yield came in under plan and the variance sat in one system for hours before the other heard about it. A shipment left the dock and the inventory relief lagged behind it. None of these were catastrophic on their own. Together they meant that at any given moment, nobody could say with confidence that the two systems matched.

So somebody reconciled them by hand. Every day. For a food manufacturer, this isn't a tidiness problem — it's a compliance problem. Lot traceability is the thing an auditor asks about, and the thing a recall depends on. If your ERP can't prove which raw lots went into which finished lots and where they shipped, you don't have a data-quality issue. You have exposure. And the manual reconciliation that was papering over the gap was slow, error-prone, and entirely dependent on the one or two people who understood both systems well enough to do it.

The stakes were the usual ones for process manufacturing, which is to say they were unforgiving. Downtime on a production line costs money by the hour. A blocked shipment costs a customer relationship. A traceability gap costs a great deal more than either if it surfaces at the wrong moment.

The approach

The temptation with a problem like this is to start writing an interface immediately — grab the tables, push the records, call it integrated. That's how you get an integration that works in the demo and falls apart the first time a lot gets split at 2 a.m.

I started with the data model instead, because Ross does not make this easy and the edges are where these projects live or die. Ross's schema carries a lot of history, and process manufacturing adds its own complications on top: lots and sub-lots, jobs and JPC, unit-of-measure conversions that have to be exactly right, quality holds that can change whether inventory is even eligible to move. Mapping the WMS's view of the world onto Ross's — and back — meant understanding not just where the data lived but what it meant on each side, including the cases where the two systems had genuinely different opinions about the same physical pallet.

The second decision was directional. This couldn't be a one-way push. Receiving, production, QC, and shipping all generate events that matter on both sides, so the integration had to move information both directions and stay consistent while doing it. That raised the real design question: what happens when a message is late, or duplicated, or arrives out of order? In a system where "close enough" is not an acceptable answer for a lot record, you design for those cases first, not last.

So the integration was built around reconciliation as a first-class feature rather than an afterthought. It didn't just move data; it continuously checked that both systems still agreed, and it surfaced the disagreements it couldn't resolve on its own instead of silently guessing. Process manufacturing doesn't tolerate a system that quietly picks a number. It tolerates a system that says, clearly, these two don't match, here's why, here's what I need.

The last decision wasn't technical at all. I worked directly with the people on the floor, in operations, and in finance — not only with IT. The reason integrations like this fail is almost never the code. It's that the person who wrote the code never watched how a lot actually gets split during a run, or what the shipping team does when a truck shows up early, or why finance needs the variance posted before a certain hour. I wanted those answers before I designed anything, because they change the design.

The solution

What got built was an integration layer that kept the WMS and Ross in real-time agreement across the full physical lifecycle — receiving, production, QC, and shipping — moving events in both directions with reconciliation safeguards underneath.

Receiving events landed in Ross as they happened. Production consumption and yield flowed through with the lot and sub-lot relationships intact, so traceability was built as the cheese was made rather than reconstructed afterward. Quality holds were respected on both sides, so inventory that wasn't cleared to move couldn't accidentally be shipped or sold. Shipping events relieved inventory in step with the physical trucks instead of hours behind them. And running underneath all of it, the reconciliation logic watched for the drift that used to be somebody's full-time morning and either resolved it or flagged it.

The finance side mattered as much as the floor. Because I understood how Ross valued inventory and posted variances — not just how it stored rows — the integration kept the books consistent with the physical movements, which is the part that usually gets discovered to be wrong six months later during an audit.

The result

The two systems agreed, in real time, without a person standing between them.

The daily manual reconciliation — the fragile, expert-dependent ritual that had been holding the operation together — went away. Lot traceability became fully auditable through Ross, end to end, because it was captured correctly as it happened rather than stitched together after the fact. The compliance exposure that came from two systems quietly disagreeing about the same lot closed. And the business stopped depending on the one or two people who happened to understand both systems well enough to keep them in sync by hand.

I'm keeping this one qualitative on purpose — the specific figures belong to a client relationship I'm not going to speak for. But the shape of the outcome is the honest version of what "integration" is supposed to mean: the physical world and the system of record telling the same story, at the same time, without anyone refereeing.

Tech stack

Aptean Ross ERP, DML, and EMF; SQL Server; the plant's WMS; a bidirectional integration layer with reconciliation safeguards. The interesting work wasn't the technology list — it was the data model in the middle and the edge cases nobody wants to think about until they're on the floor at the wrong hour.

Have two systems that won't agree with each other? That's most of what I do. Let's talk →

Next case study: CFB Automation — automated document delivery for a manufacturing ERP →