AI Consulting for Mid-Market Distributors: Why the ERP Backbone Has to Come Before the Models
By Ed Hitchcock, Enterprise AI Systems Architect, SupplyTech Solutions
Mid-market distributors spend a lot of money on AI tools that produce nothing because the data underneath them is fragmented across five systems that do not talk to each other. We have walked into enough of these to recognize the pattern within an hour: a legacy ERP doing 60% of the work, a CRM that nobody trusts, a separate warehouse system, freight booked manually in spreadsheets, and finance running in a parallel universe. Bolt a model on top of that and you get expensive hallucinations.
This post is about a recent engagement with an industrial parts distributor running roughly $140M in annual revenue across four branches and a counter-and-outside-sales model. Their executive team had been pitched copilots, agents, and intelligent automation by half the major consultancies. They asked us a simple question: what would AI consulting for mid-market actually look like if it were not a sales pitch.
The honest answer is that for most distributors at this revenue range, the right project is not an AI project. It is an ERP modernization project that creates the conditions for AI to work. We took them through what we call the 5-Phase AI Capability Pyramid, and the work that came out of it focused on Phase 4: replacing their fragmented operational stack with a modular cloud ERP. That is the foundation everything else sits on.
What AI Consulting for Mid-Market Actually Means
The mid-market distribution segment, broadly $50M to $500M in revenue, gets pitched the same enterprise AI playbook that gets sold to a $5B manufacturer. The playbook does not fit. A $140M distributor does not have a 20-person data engineering team, a dedicated ML platform, or the budget to spend two years on a strategic AI program before producing operational value. They have a small IT team, a few power users in finance and operations, and a CEO who wants something deployed inside 12 months that pays for itself.
AI consulting for mid-market means three things in our practice. First, prioritize the foundation work that pays for itself even if the AI layer never gets built. Second, sequence the work so each phase produces measurable operational improvement, not just architecture diagrams. Third, build the data plumbing in a way that makes the eventual AI layer real, not theatrical.
For this client, that meant starting with Phase 4 of our capability pyramid rather than chasing Phase 5. The pyramid runs from bottom to top: documented and costed processes, knowledge management system, operational AI, modular cloud ERP, and enterprise AI. Most distributors at this revenue point have decent process documentation, an okay KMS, and could use tactical AI today. What they do not have is a coherent ERP backbone. Skip that, and every AI investment above it sits on quicksand.
The Operational Stack We Inherited
The current state for this client looked like what we see in roughly two out of three mid-market distributor assessments. A legacy ERP that had been customized over 15 years and was now expensive to maintain and harder to change. A standalone CRM that the sales team complained about constantly. A warehouse system that exported flat files into the ERP overnight. Transportation booked through carrier portals and tracked in spreadsheets. Finance running a parallel reporting environment because the ERP could not produce the views they needed.
We mapped the data movement across the stack during the assessment phase. Roughly 40 to 50 hand-off points where data moved between systems, with about a third of those involving manual intervention. The same customer record existed in four different shapes across four systems. The same purchase order had three different states of truth depending on which system you asked. Month-end close took 9 to 11 business days because reconciling those parallel truths was the only way to produce financials.
We added up the labor cost of running that operational stack. Roughly $850K to $1.1M annually in fully loaded labor was spent on activities that existed only because the systems were fragmented: reconciliation, manual data movement, parallel reporting, error correction, and the IT custom development needed to keep the legacy ERP integrated with everything else. That number is a sharper argument for modernization than any AI capability deck.
Why Modular Cloud ERP, Specifically
We recommended Dynamics 365 with the Supply Chain Management modules as the Phase 4 target. We are platform-agnostic on principle, but for distribution-heavy mid-market clients the D365 + SCM combination is usually the right answer for four reasons.
It is modular. The client can adopt CRM, Finance, Supply Chain Management, Warehouse Management, and Transportation Management as separate modules, in a sequence that matches their pain. They do not have to do a 24-month big-bang cutover.
It is native to Microsoft 365. This client already runs M365 across the business. Power Automate, SharePoint, Power BI, and Teams integrate with D365 without custom connectors. That alone saves six figures in integration work over the life of the platform.
It has a clean integration surface for AI. Azure ML, Azure AI Services, and Copilot Studio sit one connection away. When this client is ready for Phase 5, they will not need to rebuild data pipelines. The pipelines that feed D365 will be the same ones that feed the AI layer.
It centralizes the operational data model. CRM, Finance, OMS, WMS, and TMS share one customer record, one product record, one order record. The reconciliation labor we costed out above stops being necessary in the new model.
We avoid framing this as a digital transformation. It is a system consolidation that happens to use modern tools. The distinction matters because every distributor we have worked with has been burned at least once by a vendor who sold them transformation and delivered a configuration project.
The Phased Cutover Plan
For a distributor of this size, we do not recommend trying to land all of D365 in one go. The 24-month plan we built for this client has four releases.
Release 1, months 0 to 6: CRM module replacing the existing standalone CRM. Integrated to the legacy ERP via API so order history flows in. Sales team starts working out of the new CRM while everything else runs unchanged.
Release 2, months 6 to 12: Finance module replacing the legacy ERP financial functions. This is the hardest release because it includes the general ledger cutover, the AP/AR migration, and the close process redesign. We estimate 45 to 55% of total program effort lives here.
Release 3, months 12 to 18: Supply Chain Management modules. Order management, procurement, and warehouse management replace the legacy ERP operational modules and the standalone WMS. The legacy ERP gets decommissioned at the end of this release.
Release 4, months 18 to 24: Transportation Management module replacing the manual freight workflow. This is the smallest release and the one that produces the most visible early ROI because TMS automation saves real labor and produces real margin improvement on freight billing.
Each release has a defined exit criteria, a designated business owner, and a measurable operational metric. Finance close compresses from 9 to 11 days to 4 to 6 days by end of Release 2. Order-to-cash cycle compresses by roughly 20 to 30% by end of Release 3. Freight cost as a percent of revenue improves by roughly 1 to 2 points by end of Release 4.
We do not let clients sign the contract without these exit criteria written into the program plan. The vendors that pitch the platform have an incentive to declare success at go-live. We have an incentive to declare success when the operational metric moves.
What AI Looks Like on Top of This
The Phase 4 work creates the conditions for AI to be useful. Once D365 is live, the client gets four things they did not have before that matter for the eventual Phase 5 work.
A unified customer record that an agent can reason about without joining four databases. A single source of truth for inventory, order status, and shipment status. A clean financial data model that feeds Power BI without 14 spreadsheet manipulations. An integration surface that Azure ML and Azure AI Services connect to in days, not months.
We do not promise this client a Chief of Staff copilot on day one of Release 4 cutover. We tell them that once the ERP backbone is in place, building the first leadership copilot is roughly 8 to 12 weeks of work rather than 18 to 24 months. That delta is the entire reason mid-market distributors should do the foundation work first.
The math on AI consulting for mid-market is simple. A copilot built on top of a clean ERP produces value in months. A copilot built on top of a fragmented legacy stack produces a demo that gets unplugged within a quarter. We have seen both. The first one is durable. The second one is a story the CIO regrets telling at the board meeting.
What This Means If You Are Evaluating AI Consultants
If you are an executive at a mid-market distributor and you are evaluating consultants for AI work, the most useful question we know is whether their proposed first deliverable depends on data that you can actually produce cleanly today. If the answer is no, the first project should be foundation work, not model work. If the consultant cannot articulate that, the engagement will not produce durable value.
We do this work because it produces durable value. The Phase 4 program for this client is not glamorous. It will not get a press release. What it will do is take 9 to 11 days of close down to 4 to 6, take roughly $850K to $1.1M of fragmentation labor off the table, and put the company in a position to make the eventual AI investment a 12-week project rather than an 18-month one.
If your organization is at the point where someone is pitching you intelligent agents on top of an ERP you do not trust, the right conversation starts further down the pyramid. That is the call we take. No tool pitch. A read on where you are, and what would need to be true before any AI investment would actually work.
Comments