Why We Consolidated Three Logistics Channels Before Touching the ERP: An ERP Modernization Consulting Perspective
- Ed Hitchcock
- Apr 14
- 6 min read
By Ed Hitchcock, Enterprise AI Systems Architect, SupplyTech Solutions
Every ERP modernization consulting engagement starts with a question about sequencing. Which problem do you solve first? Our team spent considerable time on that question with a mid-market specialty hardware distributor operating four regional distribution centers and roughly 1,200 commercial accounts. The answer we landed on was not what they expected: consolidate the logistics channels first, and leave the ERP alone until that foundation holds weight.
This post explains that decision, the reasoning behind it, and what we actually built. We are not covering the full implementation here. We are focused on one phase, one architectural choice, and why we made it.
The Starting Condition: Three Systems That Did Not Speak to Each Other
Before any design work began, we documented how freight actually moved through the organization. What we found was three disconnected logistics systems operating independently, each with its own workflow, its own data trail, and its own blind spots.
Contract carriers were booked through email confirmations and phone calls. Spot loads were posted to external load boards with no integration back into any internal system. Private fleet, which represented a meaningful slice of daily volume, ran on dispatch sheets updated manually by a single fleet coordinator.
The financial consequence was predictable: reconciliation happened monthly, with a lag of 30 to 45 days between when a load moved and when the numbers were confirmed. The operational consequence was roughly 15 hours of manual data coordination per week across these systems, just to produce a working picture of what was in motion.
No one had unified carrier performance visibility. No one had a procurement flow that connected freight spend to the PO and AP modules in the ERP. The ERP itself was not broken. The problem was that logistics operated entirely outside of it, and the seams between the three channels created compounding reconciliation debt every week.
The person who felt this most acutely was the fleet coordinator, who spent a material portion of every week pulling data from three sources into a format that finance could work with. That is not a technology problem on its face. But it is a technology problem when you realize that the same manual effort was happening every single week without any structural change, because no system existed to handle the handoff automatically.
The instinct in many organizations would be to fix the ERP first. Modernize the system of record, then figure out how the operational data flows into it. We argued for the opposite.
Why We Chose to Consolidate Logistics Channels First
The core argument was about data quality and system confidence.
If we had modernized the ERP first, we would have given the organization a clean, capable system of record fed by three messy, disconnected input streams. The ERP would have looked modern on paper while producing outputs that no one trusted. Reporting would have been unreliable. Carrier data would have been inconsistent. Financial visibility would have remained a lagging, manual process.
We have seen this pattern before in legacy ERP modernization engagements. The organization invests heavily in the platform upgrade, goes live, and then spends the next six to twelve months trying to reconcile why the data coming out of the new system does not match operational reality. The answer is almost always that the source data was never cleaned up or unified before it was handed to the new system. The ERP is only as accurate as what feeds it.
Consolidating the logistics channels first meant that by the time we introduced ERP integration, we had a single operational layer with consistent data structures, a defined event model, and a tested workflow engine. The ERP integration then became a straightforward mapping exercise rather than a data normalization project layered on top of an ERP migration.
There is also a risk argument. ERP modernization is disruptive. It touches finance, procurement, inventory, and reporting simultaneously. Adding a complex logistics data unification effort on top of an active ERP migration would have multiplied the failure modes. Sequencing the logistics consolidation first isolated that risk and gave the team a stable, well-understood foundation before the higher-stakes ERP work began.
This is a sequencing principle we return to often in our legacy ERP modernization work: stabilize the data before you modernize the system that depends on it.
Designing the Unified Operations Layer
The operational layer we designed unified three carrier categories that the client already worked with: asset-based carriers operating under contract, owner-operators functioning as independent capacity, and brokered capacity sourced from spot market load boards.
These three groups represented meaningfully different business relationships. They had different onboarding requirements, different compliance obligations, and different payment terms. Treating them identically in the system design would have created problems downstream, particularly in financial settlement and carrier qualification.
Our approach was to classify each carrier type explicitly and manage the differences at the configuration level, not at the workflow level. Each classification had its own onboarding path, its own compliance document requirements, and its own payment term logic. But every carrier, regardless of classification, operated through the same dispatch interface and moved through the same workflow sequence.
That workflow sequence covered the full load lifecycle: creation, tendering, acceptance, tracking, proof of delivery, and settlement. A single carrier could be asset-based, an owner-operator, or brokered capacity. The classification determined how they were set up and how they were paid. The workflow treated them identically from a dispatching standpoint.
This was a deliberate design choice, not an accident of the build. Operational simplicity at the dispatcher level required structural differentiation at the data level.
How ERP Modernization Consulting Shaped the Integration Logic
Once the workflow engine was defined, we designed the ERP integration points to sit at natural handoff moments in the load lifecycle. The integration logic was event-driven rather than batch-driven, which addressed the 30 to 45 day reconciliation lag directly.
When a carrier accepted a load, the system generated a purchase order. When proof of delivery was confirmed, the system triggered an accounts payable voucher. When payment terms cleared, the settlement posted automatically.
Three events. Three integration points. Each one replacing a step that had previously required manual intervention and a monthly reconciliation cycle. The financial data no longer accumulated in a backlog waiting to be processed. It moved in near real-time, attached to the operational events that generated it.
This matters for AI for distributors specifically because automated financial integration is a prerequisite for any meaningful analytics work. You cannot build useful predictive models on carrier performance or freight spend if the underlying data is 30 days stale and requires manual cleanup before it can be analyzed. The integration layer we built created the data hygiene that supply chain AI requires to function accurately.
This is also where the legacy ERP modernization conversation often gets sequencing wrong. Organizations invest in analytics tooling before they have clean, integrated operational data. The analytics then produce outputs that practitioners do not trust, and adoption stalls. Clean integration before analytics is not a nice-to-have. It is a structural requirement.
What the Unified Layer Made Possible
Once the three channels were consolidated into a single operations layer, several things became visible that had not been visible before.
Carrier performance data could be tracked across the full carrier base rather than segmented by channel. Tender acceptance rates, on-time delivery, and POD confirmation timing were now measured against a common baseline. The private fleet, which had previously existed only in dispatch sheets and phone logs, now appeared in the same operational view as contract and spot carriers.
Freight procurement could be connected to PO and AP workflows directly, for the first time. The ERP was no longer receiving a monthly data dump from a manual reconciliation process. It received structured, event-driven data from a unified operational layer that had already validated and classified that data.
The organization moved from approximately 15 hours of weekly manual coordination to a workflow where the system handled the handoffs that had previously required human intervention at every step. The coordinator role did not disappear. The role shifted from data entry and reconciliation toward exception management and carrier relationship work.
For an ERP implementation partner, this kind of sequencing changes the nature of the ERP work itself. Instead of migrating a system and simultaneously untangling operational data problems, the ERP integration becomes a defined, bounded project with clean inputs. The risk profile is different. The timeline is more predictable. The outputs are more reliable from day one.
What Comes Next
This post covered one design decision in a multi-phase engagement: why we built the consolidated logistics layer before touching the ERP, and what that layer looked like structurally. Future posts in this series will cover the tendering waterfall logic, the financial integration architecture, and the analytics layer we built once clean operational data was flowing consistently.
Comments