Enterprise AI Architecture in Practice: How We Built a Logistics Analytics Layer for a Specialty Hardware Distributor

Ed Hitchcock
May 5
7 min read

By Ed Hitchcock, Enterprise AI Systems Architect, SupplyTech Solutions

The Operational Layer Was Working. The Analytics Layer Did Not Exist.

This is the fourth post in our series on a specialty hardware distributor where we have been redesigning the enterprise AI architecture from the ground up. By the time we started this phase, three earlier rounds had already shipped. We consolidated three logistics channels into one operations platform, rebuilt purchase order automation around a tendering waterfall, and added a financial integration layer so PO, AP, and accessorial postings landed in the ERP within the same day instead of weeks later.

The operational layer was running. Loads moved. POs posted. Accessorials got captured. The problem was that nobody could answer simple questions about what was happening inside that flow. Which lanes were losing money. Which carriers were rejecting tenders on which days. Which brokers were carrying a disproportionate share of high-margin work. Which customers were quietly costing the business more than they paid.

This phase was about building the enterprise AI architecture that turns operational data into decisions. We are calling it the analytics layer.

Outcomes from the analytics layer build: 10 to 15 hours per week of analyst capacity redirected, two of the top ten customers reclassified on margin, three customer renewals priced with cost-to-serve data, and nightly forecast refresh.

Why an Analytics Layer Is a Distinct Architectural Problem

The mistake we see most often in mid-market distribution is treating analytics as a reporting feature inside the operational system. The TMS has dashboards. The ERP has reports. The dispatch tool has a metrics tab. Each one shows a partial view of the same business, calculated differently, refreshed on different schedules, owned by different teams.

That model breaks down the moment leadership asks a cross-functional question. What is our true cost per loaded mile after accessorials and fuel surcharges. How does that move when we shift volume from a primary carrier to a secondary one. Nobody can answer in less than a week, and the answers do not agree.

A real enterprise AI architecture treats analytics as its own layer. It pulls from the operational systems but owns its own data model, metric definitions, refresh cadence, and access controls. It is where the business asks questions and gets a single, defensible answer. That was the brief for this phase.

What We Built Inside the Enterprise AI Architecture

We built five foundational analytics modules on top of the operational platform. Each one solves a question leadership had been asking for months. Each one runs against the same governed data warehouse. Each one is the single source of truth for that question.

Lane Forecasts

The first module forecasts demand at the lane level. A lane in this context is an origin-destination pair tied to a customer or customer group. The model uses 24 months of historical load data, seasonality patterns, customer reorder cycles, and known commercial commitments to project expected volume by week for the next 90 days.

Lane forecasts feed three downstream decisions. They drive primary carrier capacity commitments in the routing guide, flag lanes where forecasted volume no longer justifies the current contract structure, and give the brokerage team a heads-up on spot exposure spikes.

We did not chase prediction accuracy as the headline metric. Forecasts are useful if they are directionally right and refreshed weekly. Ours run nightly and roll forward automatically.

Resource Allocation Through Linear Programming

The second module is the one we get the most questions about. Resource allocation across a mixed fleet, brokerage, and contract carrier base is a constrained optimization problem. You have a finite pool of trucks, drivers, and contracted capacity. You have demand forecasts, customer service-level commitments, and cost differentials between carrier types. The question is how to allocate capacity to maximize contribution margin while honoring commitments.

We built this as a linear programming model. The decision variables are how many loads of each forecasted lane go to each carrier type. The constraints encode capacity ceilings, customer-level service commitments, and carrier-level minimum volume agreements. The objective function is contribution margin after expected accessorials.

The model does not run in real time. It runs weekly, and the output is a recommended allocation plan that the operations director reviews before the routing guide updates. That review step matters. The model surfaces tradeoffs the team would not have caught manually, but a human still owns the final call.

Analytics layer flow: operational systems write to transactional databases, change-data-capture streams into a governed warehouse, versioned SQL metric definitions feed the analytics modules, and outputs land as decisions and a daily brief.

Tender Rejection KPIs

The third module is the most operationally useful, even though it is the least sophisticated technically. We mentioned in an earlier post that this client had a 38 percent Friday rejection rate from primary carriers before we touched the routing guide. The number was not visible at the time. We had to dig for it. The whole point of the tender rejection KPI module is that this kind of pattern is now visible by default.

The dashboard tracks rejection rate by carrier, by lane, by day of week, by time of day, and by customer. It flags any combination that drifts more than two standard deviations from its trailing 90-day baseline. When a primary carrier starts rejecting more than usual on a specific lane, the routing guide team sees it the next morning instead of a quarter later.

This module pays for itself in carrier renegotiation cycles. When the team sits down with a carrier to talk about contract performance, they walk in with rejection patterns the carrier cannot dispute.

Financial Metrics Dashboards

The fourth module turns the financial integration layer we built in the previous phase into actual visibility. The integration was already posting PO, AP, and accessorial entries to the ERP in close to real time. The financial metrics dashboard turns those entries into the numbers leadership actually wants: ROI by customer, cost per load by lane, cost per mile by mode, contribution margin by broker.

These are not novel metrics. The novelty is that they are now calculated consistently, refreshed daily, and visible to the leadership team without anyone exporting a spreadsheet. The CFO looks at the same cost-per-load number the operations director looks at, and they agree on what it means.

We also built a customer profitability view. It surfaces customers whose all-in cost to serve has drifted upward faster than revenue. Two of the top ten accounts on revenue turned out to be in the bottom quartile on contribution margin once accessorials and detention costs were properly attributed. The commercial team is now using that view to drive contract renewal conversations.

Utilization Metrics

The fifth module is the asset and team utilization layer. Asset usage by truck, driver hours by lane, bookings per broker, average load count per dispatcher. These are operational metrics, but they belong in the analytics layer because they are most useful when they can be cross-cut against the financial and rejection data.

A high-booking-per-broker number on its own does not tell you anything. A high-booking-per-broker number cross-cut against contribution margin per booking tells you whether that broker is moving cheap loads fast or actually generating margin.

Layered enterprise AI architecture for the analytics layer: foundation layer with operational systems, change data capture, metric definitions, and access governance; analytics layer with five modules (lane forecasts, LP allocation, tender rejection KPIs, financial dashboards, utilization metrics); decision layer producing the daily brief, carrier renegotiations, customer renewals, and routing guide updates.

The Architecture That Made It Possible

All five modules run on a single governed data warehouse. The operational systems write to their own transactional databases as they always have. A change-data-capture layer streams updates into the warehouse continuously. Metric definitions live as version-controlled SQL views in the warehouse, not inside individual dashboards. The dashboards themselves are thin presentation layers on top of those views.

Three architectural decisions made this work.

First, every metric has exactly one definition, owned by one analyst, version-controlled, with a documented change history. When the CFO asks why cost per load moved, we can show the exact data and the exact formula. When a definition needs to change, the change is reviewed, dated, and applied everywhere.

Second, the analytics layer never writes back to the operational systems. The LP model produces recommendations, not direct routing-guide updates. The forecasts inform planning, not automated tendering decisions. This separation is deliberate. It keeps the operational systems deterministic and auditable, and it keeps human judgment in the loop where it belongs.

Third, access is governed at the metric level, not the dashboard level. A dispatcher sees the lane-level KPIs they need to do their job. A broker sees their own bookings and margin. The CFO sees everything. That control lives in the data layer, not in who happens to have a link to which Power BI workspace.

What Changed for the Business

The operations director gets a daily one-page brief with the metrics that matter most: rejection rate trend, top three lanes flagged for variance, top three customers flagged for margin drift, and the LP-recommended allocation deltas for the next planning cycle. That brief used to be a Friday afternoon scramble across four systems. It now lands at 6 a.m. with one source.

The CFO closes the month with the same numbers the operations team uses. There is no more reconciling between an operations P&L and a finance P&L. They are the same data, viewed through different lenses.

The commercial team has converted three customer renewals in the last quarter using the customer profitability view. None of those renewals would have been priced the way they were priced without the cost-to-serve data the analytics layer surfaces.

Roughly 10 to 15 hours per week of analyst time that previously went to spreadsheet assembly now goes to actual analysis. The team is building new views instead of rebuilding the same ones every Monday.

What This Phase Was Not

We did not build a predictive AI platform that automates decisions. We did not deploy ML-based dynamic pricing or automatic re-tendering. Those land when the business is ready, and the analytics layer is the foundation they will sit on.

What we did build is the layer that makes the next round possible. Lane forecasts become inputs to dynamic capacity commitments. The LP model becomes the basis for automated routing guide updates with human approval gates. Tender rejection KPIs trigger adaptive carrier scoring. Financial dashboards become the feedback loop for any AI-driven decision the platform makes.

That is what enterprise AI architecture as a layered problem means in practice. You do not start with the AI. You start with the data foundation, the metric definitions, and the access controls that make AI safe to deploy. The intelligence comes after.

What We Took Away From This Phase

Three things keep coming up when we look back at this work.

First, analytics is an architecture problem before it is a tooling problem. Picking a BI tool is the easy part. Defining metrics once, governing them across the business, and refreshing them on a schedule everyone trusts is the hard part. Most of the work in this phase was definitional, not technical.

Second, the value of an analytics layer compounds with the operational systems beneath it. We could not have built useful financial dashboards without the financial integration layer from the previous phase, or useful tender rejection KPIs without the tendering waterfall from the phase before that. Each layer earns its keep by making the next one cheaper.

Third, the right output of an analytics layer is not a dashboard. It is a habit. The operations director reading the daily brief at 6 a.m. is the artifact that matters. The dashboards are just the surface.

This is the fourth and final post in our series on this engagement. The next round of work moves into predictive layers and automated decisioning, which we will write about as that work ships.