ERP for Logistics: What We Built and Why

In August, we shipped a complete ERP rebuild for a logistics client. Not a migration. Not an upgrade. A from-scratch redesign built on completely different assumptions about how logistics actually works.

Most ERP systems assume that business flows sequentially: you receive an order, you schedule delivery, you track shipment, you close transaction. That's manufacturing-centric thinking.

Logistics is different. It's simultaneous optimization problems all running in parallel.

The Core Problem With Standard ERP in Logistics

Our client: a mid-sized logistics company handling 5,000 shipments per day. Their SAP system was drowning them.

Here's why. SAP was designed around the idea that workflows are sequential. This triggers that. That triggers this. Orderly progression.

But logistics isn't orderly. A single shipment interacts with:

• 12 different pickup locations (warehouses, retail stores, customer sites)
• 3 different carrier systems (must integrate in real-time)
• 40+ delivery routes (optimized by geography, capacity, time windows)
• Customs and compliance rules (varies by destination)
• Real-time market conditions (fuel pricing, traffic, weather, carrier availability)

Each of these is constantly changing. SAP's approach: record each change, trigger a workflow, wait for human approval.

In logistics, you have 5,000 shipments a day. You can't wait for human approvals for each one. By the time you approve it, the delivery window has closed.

Our client was approving shipments a day after they arrived. The system was built for 500 shipments a day in a controlled environment. It was trying to manage chaos with a tool built for order.

What We Designed Instead

We rebuilt the system around the idea that logistics is real-time, probabilistic optimization with human decision-making at the edges.

Here's the architecture:

Core optimization engine: Instead of a workflow engine, a continuous optimization engine. The system ingests: current inventory at each location, active shipments, carrier capacity, route profitability, delivery windows, customs requirements.

It continuously generates the optimal allocation: which shipments go on which routes, routed through which carriers, scheduled for which time windows. All in real-time.

Constraint manager: Some constraints are hard (customs rules, carrier agreements). Some are soft (prefer fewer stops, minimize fuel cost). The system enforces hard constraints, optimizes around soft ones.

Exception handler: The system flags exceptions: delivery window impossible, route blocked, carrier capacity exceeded. Instead of stopping the process, it surfaces the exceptions to a human. The human resolves them, the system continues.

Feedback loop: The system learns. If a certain route always takes longer than predicted, it adjusts future routing. If a carrier always misses time windows on Fridays, it deprioritizes them.

How This Feels Different

From a user perspective, it's night and day.

Previously: dispatcher would receive 100 pickup requests. Spend 4 hours manually assigning them to routes. Check availability. Resolve conflicts. Coordinate with carriers. Get it wrong half the time.

Now: system ingests 100 pickups. Computes optimal allocation in 60 seconds. Surfaces the 5 edge cases (route unavailable, carrier at capacity, delivery window conflict) to the dispatcher. Dispatcher resolves them in 20 minutes. System executes.

The system isn't perfect. But it's 90% right automatically, and the human fixes the 10%.

Compare that to the old system where the human was 40% right after 4 hours of work.

The Data Architecture

This required a completely different data structure than SAP.

SAP is optimized for ACID consistency: every transaction recorded, every balance always accurate. Good for accounting. Bad for real-time optimization.

We built around eventual consistency: the system makes decisions based on best-available data (current inventory, last known carrier status), then continuously updates as new data arrives.

If the system thought we had 100 units available and we actually have 95, the system notices, learns, and adjusts future decisions.

That sounds chaotic. It's actually more stable than traditional ERP because the system is built to handle uncertainty. SAP requires perfect data; if data is wrong, the system breaks. Our system assumes data is imperfect and handles it.

Integration Challenges

Logistics isn't a closed system. A freight company has:

• Three to five different carrier integrations (FedEx, UPS, DHL APIs)
• Customer systems submitting pickup requests (different formats, different APIs)
• Real-time market data (fuel prices, weather, traffic)
• Customs and compliance systems (international shipments)

Each integration has its own quirks. FedEx has one way of reporting capacity. UPS has another. They both change their APIs every 18 months.

We built an integration abstraction layer. Instead of coupling the core optimization engine to specific carrier APIs, we abstract it.

Carrier integration → standardized event stream → optimization engine

If FedEx changes their API, we update one integration. The core system doesn't care.

The Results

Three months in:

• On-time deliveries increased from 82% to 94%
• Average route utilization increased from 64% to 78%
• Dispatcher time per 100 shipments dropped from 4 hours to 1 hour
• Cost per shipment decreased 12%

More interesting: the types of decisions humans are making shifted. Previously, humans were making tactical decisions (which shipment on which truck). Now, humans are making strategic decisions (should we add a new route? should we contract more capacity?).

The system handles the 10,000 tactical decisions per day. Humans handle the 10 strategic decisions.

Why Standard ERP Can't Do This

I want to be clear: this wasn't a SAP limitation. Oracle, NetSuite, Workday would all struggle the same way.

Those systems are optimized for different problems. They're good at: managing accounts, tracking inventory, recording transactions, following workflows.

They're bad at: real-time optimization under uncertainty, handling continuous data streams, making probabilistic decisions, adapting as conditions change.

Logistics needs a different substrate.

What's Coming

We're planning to productize this. We're building a "Logistics ERP" offering: not a system you install, but a platform where logistics companies can plug in their carrier integrations, define their constraints, and run the optimization engine.

It's a different business model than traditional ERP licensing. It's usage-based: the company pays based on shipments processed. The better the system works, the more shipments they send, the more they pay.

Aligns incentives: we make money when the system helps them process more efficiently.

The Bigger Picture

This project taught me something important: modern ERP isn't about better tools for doing traditional business processes faster.

It's about finding new processes that only become possible with the right infrastructure.

Logistics dispatch has always been a bottleneck. Not because dispatchers are bad, but because the problem is too big for human-only decision-making. With the right optimization infrastructure, you eliminate the bottleneck entirely.

That's the pattern for all of enterprise software moving forward. The winners will be the ones who figure out which traditional processes can be transformed, not just accelerated, with better infrastructure.