top of page

AI Isn't New. Start With Your ERP Data.

Writer: Andy Collier
Andy Collier
Jun 6, 2025
6 min read

Updated: Oct 1

Only 37% of companies can tie AI to earnings, unchanged in a year. The ones that can measure the work first — on data most manufacturers already own.

Andrew S. Collier  ·  Founder & Managing Principal, Collier & Associates  ·  October 1, 2026.


AI Isn't New. Start With Your ERP Data

McKinsey's 2026 State of AI survey, published August 25, is the clearest picture yet of where enterprise AI stands. Nearly nine in ten organizations use AI regularly in at least one function. Eighty percent of respondents say it has improved their own productivity. Among companies above $1 billion in revenue, the share scaling AI agents jumped from 27% to 40% in a year. And the share that can attribute any EBIT impact to AI is 37% — unchanged from 2025. The high performers, those crediting 5% or more of EBIT to AI, are 6% of respondents. Also unchanged.


Individual productivity is real. Enterprise earnings impact is flat. That gap is the story of enterprise AI in 2026, and it has a cause.


Adoption is broad, earnings impact is flat — McKinsey Global Survey on the state of AI, August 2026

Adoption is broad, earnings impact is flat — McKinsey Global Survey on the state of AI, August 2026

What the 6% do differently

McKinsey's own read of its high performers: nearly three-quarters have fundamentally redesigned workflows rather than inserting AI into existing ones, against one-quarter of everyone else, and they are twice as likely to have a defined process for measuring the impact. Where the cost reductions show up tells you where to look. Respondents most often report them in supply chain management, service operations, and manufacturing — the three functions that, in any mid-market industrial company, run on the ERP.


So the question isn't whether your company has AI. It's whether anyone has measured the work the AI is supposed to change, and whether the data that work produces sits where a model can reach it.


AI isn't new to me, and neither is the lesson

I've been putting decision logic inside enterprise systems since the 1990s and running machine-learning models against ERP data since 2011, across 29 JD Edwards implementations and a hundred-plus enterprise systems engagements. The names of the techniques changed. The discipline didn't.

•    1996–98. A custom collaborative planning, forecasting, and replenishment system for Volvo Penta, integrated with JD Edwards World, with the forecasting programs customized to honor bill-of-material effectivity dates in DRP so each year's engine model sold through before its successor released. It formalized global S&OP.

•    2005–07. A heuristics-based configurator and estimator for Alstom Power's blade manufacturing plant, writing live sales orders and work orders into JDE. Blade quotes went to under two hours against a roughly three-week industry standard, and shortly after go-live an emergency multimillion-dollar utility RFP was estimated in half a day while every competitor quoted two weeks or more.

•    2011–12. Data mining — clustering, neural networks, Naive Bayes, decision trees — over a custom molding job shop's routings and manufacturing orders to answer one question: is there any commonality in our jobs? The client's working hypothesis was no. Five core profiles covered every job type, and the future-state quote-to-cash design was approved at the C-level.

•    2015–17. A SIOP algorithm suite in Oracle PL/SQL on the JD Edwards EnterpriseOne schema for a commercial pipe distributor with 250,000 active SKUs: demand classification, ABC ranking by unit volume (which JDE doesn't do natively), lead-time and safety-stock calculation, forecast spreading — on automated hourly, daily, weekly, and monthly cycles. It eliminated roughly 99% of manual procurement planning and purchasing execution. Staff still review and approve before a purchase order executes.

•    2016–18. Machine-learning text matching that auto-assigned Amazon payments and charges to A/R records at a publishing distribution center — the parent company took over its development — and an Oracle Analytics/ML intelligence platform across roughly 60 rent-to-own stores and 48,000 agreements, delivered as an MVP the client chose not to fund into production.


None of those was sold as an AI project. Each started with a measured process and a system of record, and each wrote its answer back into that system where people could act on it.


Six documented builds, 1996–2018 — the technique changed, the discipline didn't (Software Engineering Case Library v2)

Six documented builds, 1996–2018 — the technique changed, the discipline didn't (Software Engineering Case Library v2)


The data is already there

If you run JD Edwards, you are sitting on the dataset the 6% are using. The sales ledger, item and branch masters, bills of material, routings, forecasts, work-order and purchase-order history — years of it, keyed and dated, in one schema. Oracle has committed Premier Support for EnterpriseOne 9.2 through at least 2036; Release 26 ships an Enterprise Automation Dashboard and Process Modeler that read process metrics and KPIs straight from that data, and the Orchestrator has been able to call OCI AI services since Release 24. The platform is not the constraint, and the same is true of SAP, Epicor, Infor, or Dynamics — whatever runs your plant.


Three things usually are. The item master carries dead and duplicate records; one natural gas compression equipment manufacturer I modeled held more than 500,000 items where fewer than 40,000 were needed. The real process runs partly in spreadsheets and Access databases the ERP never sees — the spreadsheet tax. And nobody has priced the work the AI is meant to replace, so there is no baseline to show a return against.


Four jobs, four engines

The job picks the engine, and it is never the same engine for all four. Demand forecasting, with DRP and MRP downstream, is a statistical and machine-learning problem: a method assigned per planning family by the shape of its demand curve, instrumented with MAPE and a tracking signal, actuals appended and never overwritten, planners approving before purchase orders execute. Item-master and parameter hygiene is classification plus rules, with a named data owner signing every change. Exception triage — late POs, credit holds, customer disputes — is where a language model earns its keep: reading, summarizing, and routing with retrieval over ERP records, proposing an action a person decides. Process metrics and bottlenecks come from the process modeler and a task-level cost model that reconciles to the ledger.


The engine is chosen by the job — and a language model is never the numeric forecasting engine

The engine is chosen by the job — and a language model is never the numeric forecasting engine


One rule I won't break: a language model is not a numeric forecasting engine. It can explain a forecast, flag an outlier, draft the exception note. It does not generate the number that drives a purchase order. The forecasting engine stays statistical, instrumented, and auditable — the same discipline that ran plants before "AI" was a budget line.


Measure before you automate

Every AI engagement in my practice opens the same way: a task-level model of the process in scope — which tasks, which roles, which systems, how many hours, at what cost, reconciled to the general ledger — before any architecture is drawn. That is what the BAS™ Value Creation Sprint produces, and it is the baseline the other 63% are missing. It shows which hours the AI is meant to remove, what they are worth as released capacity, realized cost-out, or avoided cost, and whether the data to do it lives in the ERP or in a coordinator's workbook. Then the engine is chosen, built against the system of record, and re-measured on the same instrument. The data is there. The tools exist. The step most companies skip is the one that makes the return real.


If you run a plant, a distribution operation, or a portfolio and want to know where AI will actually pay on the data you already own, start with one process measured in two weeks: call 502-317-8900 or write to andy@andrew-collier.com. I'll show you the method on real data before you spend anything.



Andrew S. Collier

Founder & Managing Principal, Collier & Associates  ·  Greater Louisville, KY


Creator of the BAS™ Value Creation methodology. 38+ years in enterprise transformation; 100+ enterprise systems engagements; 29 JD Edwards implementations; six interim technology-executive seats; 6+ years of PE M&A work as an advisor to PwC, Deloitte, and Crosslake Technologies.


Related Reading  ·  BAS™ Value Creation Series


Sources: McKinsey & Company, "The state of AI in 2026: On the road to ROI," August 25, 2026 (1,719 respondents, May 4–June 8, 2026); Oracle, JD Edwards EnterpriseOne Release 26 documentation and Premier Support commitment through at least 2036 (LearnJDE); Collier & Associates Software Engineering Case Library v2 and engagement record (Volvo Penta, 1996–98; Alstom Power, 2005–07; McClarin Plastics, 2011–12; Columbia Pipe, 2015–17; Macmillan/MPS, 2016–17; Premier Rental, 2018; Exterran, 2007).


Comments


bottom of page