Capabilities Unified transport & distribution

Capability · Unified transport & distribution

Transport and distributionshould never be managed separately.

Connect order, allocation, picking, dock, route, delivery, proof and cost in one flow, without blurring each system’s responsibility.

A capability shaped by your flows, rules and field evidence.

Long-haul transportActive scenario01SignalTransport slot is firm but picking is slipping.02DecisionReprioritise the wave or reassign the slot based on customer impact.03ProofNew decision shared by WMS, TMS and customer.04Active systemOMS05Active systemWMS
01 / 04Synchronise dock with scarce capacity
Urban parcelActive scenario01SignalPriority parcels arrive after initial close.02DecisionCompare insertion, dedicated shuttle or deferment using SLA and capacity.03ProofChoice, cost and impacted customers retained.04Active systemOMS05Active systemWMS
02 / 04Absorb late volume without losing the route
Store replenishmentActive scenario01SignalA critical store falls below threshold while a route is being built.02DecisionIntegrate the need if stock, dock and capacity remain compatible.03ProofAvailability, sequence and ETA recalculated.04Active systemERP05Active systemOMS
03 / 04Serve the store without shifting the stockout
E-commerce deliveryActive scenario01SignalRecipient is absent and proof is incomplete.02DecisionQualify reason, replan or return based on contract and preference.03ProofNew action linked to the order and parcel.04Active systemTMS05Active systemMobilité
04 / 04Turn delivery failure into a controlled action
01 / 0402 / 0403 / 0404 / 04
01

Realistic plan

Transport uses the real state of picking, docks and capacities.

02

Visible execution

Operations, customer and partners share understandable milestones.

03

Connected proof

POD, reservation, return and document remain attached to the correct record.

04

Reconciled cost

Planned service is compared with what was actually executed.

Decision framework

Connect promise, responsibility and proof.

Unification does not mean one system does everything. It means each relay receives the right event, makes its decision and returns usable proof.

Business logic

Decisions start with explicit rules.

Connected architecture

Clear responsibilities, from signal to proof.

ERP / OMSCarries commitmentPROTECH WMSCarries fulfilmentCANDOR TMSCarries transportMobilité / portailsCarries the fieldBICarries insight

Gaps to eliminate

What weakens day-to-day decisions.

Each gap connects an observable situation to a business consequence. Diagnosis then verifies frequency, impact and cause.

01

Unknown readiness

TMS plans without knowing whether goods or dock will be ready.

Waiting, replanning and extra cost
02

Misaligned statuses

Order, shipment and mission use different identifiers and milestones.

End-to-end view rebuilt manually
03

Partners outside the flow

Carriers, drivers and customers communicate by email or phone.

Late decision and scattered proof
04

Disconnected finance

Billing, dispute and cost cannot retrieve actual execution.

Margin and service hard to explain

Operational journey

A chain of decisions, not a stack of screens.

Each transition identifies the participant, responsible system and expected proof.

1

Demand

Create transport demand

Order, destination, window, units, constraints and service are qualified.
Owner
ERP / OMS
Proof
Identifiable requirement
2

Allocation

Confirm origin

Site, stock and availability date become firm for transport.
Owner
OMS / WMS
Proof
Expected shipment
3

Picking

Make physical flow ready

Picking, control, consolidation, weight, volume and dock are confirmed.
Owner
PROTECH WMS
Proof
Ready to load
4

Transport plan

Assign capacity and mission

Equipment, carrier, driver, sequence and slots are planned.
Owner
CANDOR TMS
Proof
Mission acknowledged
5

Execution

Track useful milestones

Loaded, departed, ETA, incident, arrived and delivered return from their sources.
Owner
TMS / mobile / partners
Proof
Timestamped events
6

Close

Reconcile proof and finance

POD, reservation, return, cost and billing are consolidated.
Owner
TMS / ERP / finance
Proof
Defensible transport record

Decision lab

Change context. Follow what genuinely needs to happen.

These scenarios are illustrative: they show decision logic and responsibilities without claiming to simulate your actual outcomes.

Long-haul transport

Synchronise dock with scarce capacity

Signal

Transport slot is firm but picking is slipping.

Decision

Reprioritise the wave or reassign the slot based on customer impact.

Expected proof

New decision shared by WMS, TMS and customer.

B‑AGILEdecision flowERP / OMSPROTECH WMSCANDOR TMSMobilité / portailsBI

Responsibility architecture

Unify the flow without pretending one system does everything.

The responsibilities below form a reference architecture to adapt to the existing IT landscape.

01

ERP / OMS

Carries commitment
Owns
Order, promise, customer and management billing
Publishes
Requirement and priority
02

PROTECH WMS

Carries fulfilment
Owns
Stock, units, picking, consolidation and dock
Publishes
Ready, weight, volume and departure
03

CANDOR TMS

Carries transport
Owns
Resource, mission, route, milestones and cost
Publishes
Assignment, ETA and status
04

Mobilité / portails

Carries the field
Owns
Instruction, acknowledgement, proof and interaction
Publishes
Events and documents
05

BI

Carries insight
Owns
Definitions, history and reconciliation
Publishes
Service, cost and exceptions

Actionable cockpit

Shared shipment timeline

Value comes from a reliable sequence: validated demand, confirmed ready, assigned vehicle, departure, ETA, POD, dispute and invoice.

  • OTIFConnect promise to outcome
  • Dock waiting timeSeparate transport delay from warehouse unavailability
  • Cost per missionExplain transport margin
  • Complete PODAccelerate close and billing
Operational view · example
OTIF01Delivered on time and in full using a shared definition
Dock waiting time02Arrival, dock-in and departure by mission
Cost per mission03Planned, committed, additional and disputed
Complete POD04Proof received, valid and usable
Unknown readinessMisaligned statusesPartners outside the flow
No value is a customer measurement. Illustrative functional example.

Success conditions

What must be true before automation.

01

Reconciliable identifiers

Order, shipment, logistics unit, mission, delivery and proof link without re-entry.

02

Governed events

Each milestone has a source, frequency, owner and recovery rule.

03

Integrable partners

Portal, app, API, EDI or file are selected based on partner and risk.

04

Controlled access

Customer, driver, carrier and operations see only their scope.

Go further

Content to prepare a real discussion.

View all resources

Frequently asked questions

Decide with the right boundaries.

Which systems must be connected?

Only those carrying a useful flow responsibility: order, fulfilment, transport, proof, finance or customer information.

Does TMS replace WMS?

No. WMS carries stock and fulfilment; TMS carries resources, missions and transport execution.

How are exceptions managed?

With a qualified event, owner, action window, decision and closure feedback linked to the record.

Can a carrier connect without an app?

Yes, via portal, EDI, API or file depending on maturity and required events.

Are ETAs always real time?

No. Frequency and accuracy depend on source, connectivity and calculation method.

Can we start with a pilot flow?

Yes. One site, one carrier and one delivery type can validate identifiers, events and adoption.

Your context first

Unify the decision flow, from stock to customer.

Identify the decisions, data, responsibilities and pilot that will deliver observable value.

Talk to an expert All capabilities