AI, Meet ERP

The ERP computes. The AI guesses. Keep them straight.

Part 1 of 10 — Means before ends

Every management meeting at a mid-sized manufacturer now has this moment. Somebody asks what our AI strategy is, and the room fills with answers that all start in the same place.

We should have a chatbot. AI should do our forecasting. Can it just tell me why we missed the ship date on the Kohler order?

These are reasonable questions. They are also, every one of them, asked backwards — and there is a good chance your AI project is going to fail for exactly that reason. Gartner expects more than 40% of agentic AI projects to be cancelled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls. That is not a technology problem. It is a sequencing problem, and it was diagnosed in 1941.

Louisiana, 1941

In the late summer of 1941, the U.S. Army fought a mock war across the piney woods and red mud of Louisiana — the largest peacetime maneuvers it had ever conducted. A forty-seven-year-old Ordnance colonel named Henry Spiese Aurand went down to watch.

He was not impressed. Writing up his notes on the train back to Washington, he judged the performance generally shoddy, and the first failing he listed was a lack of realism.

One thing did impress him. Someone had persuaded IBM to mount business machines on the back of two trucks — sorters on one, card punches on the other — and was using them to track what ammunition actually sat in which dump. Telling the story more than thirty years later, Aurand was still enthusiastic about it: "They worked out beautifully."

Those two reactions are the same reaction. A man who thought the Army's central problem was a lack of realism found exactly one thing in Louisiana worth praising — a machine that counted what was really there.

He spent the rest of his career on that idea, in the least glamorous work the Army had: supply, transportation, ordnance. In December 1944 he took over Normandy Base Section where, in the Ordnance Corps' own words, he "pioneered the use of IBM punch cards" to manage its ammunition inventory. By the late 1940s he was the Army's first Director of Logistics, and automation fascinated him: the "electronic brains" then being built at the University of Pennsylvania, he thought, promised a revolution in centralized accounting as a management tool.

Those machines have a family tree, and it is probably your family tree. The punch card and the sorter became the machine records unit, which became the mainframe, and the servers and databases every ERP runs on today. (If you are on the IBM midrange, that line runs unbroken — machine records unit, System/38, AS/400, IBM i.) A great many mid-sized manufacturers are running their ERP on the direct descendant of the equipment Aurand admired on the back of a truck in 1941 — still doing the same job, which is keeping an honest count of what you have.

Aurand's own principle, in his biographer's phrase, was the primacy of logistics in industrialized warfare. But the punch cards are what made that principle usable. Logistics is not a philosophy; it is an inventory. You cannot plan from what you have until something reliably tells you what you have.

The inversion we draw from that is ours rather than his, but it follows directly. Conventional planning runs ends, then ways, then means: decide what you want, design an approach, then go find the resources. Start at the other end. Determine your means first, and derive realistic ways and ends from them.

That is not defeatism. It is the difference between a plan and a wish.

What are your means?

Meet Spiese Fluid Power of Racine, Wisconsin — a fictional company we will use throughout this series, built as a composite from real operating benchmarks.

Eighty-five million dollars in revenue. Spiese manufactures hydraulic power units, custom manifolds and hose assemblies to order — four-fifths of the business — and also distributes components from a stocked catalog of 12,000 SKUs. A hundred and ninety employees, 4,200 active customers, two facilities. Twenty-two years on the same ERP.

Ask what Spiese wants from AI and you get a wish list. Ask Aurand's question — what are our means? — and you get an inventory:

What they have. Twenty-two years of transactional history that is arithmetically perfect. Every quote, order, work order, material issue, receipt, invoice and payment, balanced and auditable, with an unbroken journal. Bills of material and routings for 2,400 assemblies. Roughly 184 orders a day. Item masters and 4,200 customer relationships with real payment behavior behind them — two decades of build that no competitor can buy.

What they don't have. A data engineer. A data scientist. Documentation for a decade of customizations. Field names a human can read without a decoder ring. Five people in IT total, and four of them are keeping the lights on.

That inventory is the whole strategy. Everything Spiese should do with AI in the next three years is derivable from those two lists, and almost everything on the original wish list is not.

Two machines, two jobs

Here is the framing this series is built on.

Your ERP is a system of record. It is deterministic — the same inputs produce the same outputs, every time. It is arithmetic. It is auditable. When it is wrong, it is wrong loudly and traceably, and you can find out who did what on which date.

A large language model is a system of inference. It is probabilistic. It is linguistic. It is extraordinarily good at ambiguity, and it is fast. When it is wrong, it is wrong quietly and plausibly — which is a far more dangerous property than being wrong loudly.

Neither substitutes for the other; all of the value is in the handoff between them. Which lets us restate the title precisely: system of inference, meet system of record.

Who the conversion story is for

You will read a great deal right now about your system of record becoming something else. Forbes ran the clearest version last November — From Systems of Record to Systems of Reason, arguing that AI belongs natively inside the ERP rather than beside it. Most major ERP vendors are now telling some version of that story.

It is worth asking who the story is for. A conversion narrative — your system of record is becoming something new and larger — is precisely what a software company needs when it is explaining itself to investors. It reframes a mature product in a slow-growing market as a platform in transition. Whether it describes anything a mid-sized manufacturer should do on Monday morning is a separate question, and mostly an unasked one.

We should be plain about our own position. HarrisData is family-owned. We have no outside investors to impress and no funding round to narrate, and most of the manufacturers we work with are privately held businesses with the same freedom. That does not make us right about anything. It does mean that when we tell you a technology is not worth buying yet, nothing bad happens to us.

And we think this one has the architecture backwards. Your system of record does not need to become anything. It needs an introduction — to a second machine, kept cleanly separate, with a carefully engineered boundary in between.

The ERP computes. The inference layer reads, routes, explains, and drafts.

A pairing guide

If you take one thing from this post into your next meeting, take this.

The last pair is the one to remember. Numbers come from the system of record. Sentences come from the system of inference. When you find yourself asking a language model to produce a number that someone is going to put in a board deck, stop.

Where this idea comes from

We did not invent the shape of this argument. Geoffrey Moore drew the first version for AIIM in 2011 — systems of record versus systems of engagement. Jerry Chen extended it at Greylock in 2017. Benn Stancil said the operative part plainly in 2024: LLMs shouldn't write SQL.

The evidence arrived this year, when dbt Labs benchmarked the two approaches head to head. Point a model at raw tables and let it write its own SQL: 64.5% accurate. That is roughly double what it managed three years ago, which is precisely the danger — it is improving fast enough to be trusted well before it is good enough to be trustworthy. It is still wrong better than a third of the time, silently, handing back a plausible figure rather than an error.

Now give the same model a narrow semantic layer to work through: 100% accurate on the questions the layer covers — and when one falls outside that coverage, it says so instead of guessing.

Same model, same questions. The difference is entirely architectural. That is not a verdict on AI, and it is not an argument against it. It is a verdict on matching the design to the task — and on the expertise required to know which design a given task needs. That judgment is the actual work, and it is what the next nine posts are about.

What's coming

Nine more posts, one a month, each one working a single real problem at Spiese all the way through — what it costs today, where the boundary sits, what the AI does, what it must never do, how you would know it worked, and the smallest version you could start on Monday.

The first arc is the unglamorous wins: inbound customer POs arriving as PDFs, the institutional knowledge that walks out when your longest-tenured planner retires, and then the one everybody wants and almost everybody gets wrong — why chatting with your ERP fails, and what to build instead.

The second arc goes to the plant and the back office: MRP exception triage, three-way match, the inside sales desk, and getting paid.

Then two closing posts that will make some vendors unhappy: where AI does not belong — including demand forecasting, where it is the wrong tool and something older and duller is the right one — and the autonomy ladder, on how you actually earn the right to remove the human.

Every number we publish about Spiese will be computed, not asserted, from a published set of operating assumptions. A series arguing that arithmetic belongs to the system of record should not run on made-up figures.

Start with what you have

Aurand spent his career arguing that the Army systematically undervalued the people who did this work. Coming home from Louisiana, he named the shortage of supply specialists as the most serious problem he had seen, and blamed it on what he called the prevailing prejudice against supply men — few talented officers would accept the stigma of the label, because the road to the top ran through the combat arms.

He was still losing that argument in retirement. He wrote a memoir of his war, COMZ Command, and never found a publisher for it. He was told that no one wants to read a book about logistics.

Anyone who has run a plant or a back office knows the feeling. The AP clerk reconciling a mismatched receipt. The planner scrolling past three hundred and seventy exception messages to find the six that matter. The inside sales rep keying a PDF at four in the afternoon so it ships tonight.

That is where this technology is going to pay for itself. Not in the demo. In the unglamorous middle, where the work actually is.

And it will pay off there for the same reason the punch cards did in 1941 — because everything downstream depends on an honest count of what you actually have.

Start with your means.

Spiese Fluid Power is fictional — a composite built from published industry benchmarks and anonymized operating ratios. Its full operating profile, with sources, is published [here].

Henry S. Aurand was real, and a relative of the author. Biographical details are drawn from John Russell Reese, "Supply Man: The Army Life of Lieutenant General Henry S. Aurand, 1915–1952" (PhD dissertation, Kansas State University, 1984); the U.S. Army Ordnance Corps Hall of Fame citation; and Aurand's 1974 oral history interview with Major William O. Morrison, Jr., for the U.S. Army Center of Military History.