Visibility is the capability logistics teams ask for most and specify least precisely. "We want to know where our freight is" almost always turns out to mean something more specific: we want to stop customers phoning to ask; we want production to know before a component is late, not after; we want to identify which lane or carrier is quietly costing us money.
Those are different requirements with different designs. Getting that clear before configuration starts is most of the work.
A note on the name
SAP's current official product name is SAP Business Network Global Track and Trace. Most practitioners still say SAP GTT, and many job specifications and searches still use the older name. We use both on this site so the page is findable either way — they refer to the same capability area.
What the platform actually does
The model is event-based. You define what you want to track, what should happen to it, and when. The system then compares reality against that plan:
- Tracked objects. The things you care about — a shipment, a freight order, a delivery, a purchase order, a handling unit. Each gets a timeline.
- Expected events. What should happen and when: departure from origin, border crossing, arrival at destination, proof of delivery.
- Actual events. What did happen, reported by carriers, telematics devices, terminal operators, or your own systems.
- Deviation and exception handling. The gap between expected and actual, evaluated against rules you configure — so a two-hour delay on a domestic run and a two-hour delay on a cold-chain shipment can be treated very differently.
- Predictive arrival times. Estimated arrival updated from current position and conditions rather than left at the original plan.
Because it is part of the SAP Business Network family, it draws on carrier and location data providers already connected to the network, rather than requiring you to build a feed per carrier. Emissions data captured from carriers along the same event stream is increasingly used for sustainability reporting.
What we deliver
Visibility platform implementation
Tracked object model, expected event definitions, deviation rules and user interfaces configured around the questions your business actually needs answered.
Predictive ETA and exception management
Tuning what counts as an exception, who is notified, and what action is expected — the difference between a visibility platform that changes behaviour and one that produces reports.
IoT and telematics integration
Connecting GPS, temperature and door-sensor data where the freight justifies it — cold chain, high-value or regulated goods — so condition is tracked alongside location.
Carrier and 3PL event feeds
Onboarding carriers and logistics providers as event sources, including the data-quality work that determines whether the timeline is trustworthy.
Customer-facing visibility portals
Exposing a filtered view of shipment status to your own customers — usually the fastest way to reduce inbound "where is my order" calls.
SAP TM and ERP integration
Connecting the visibility layer to the systems that create the shipments, so tracked objects are generated automatically and status flows back where it is needed. See our SAP TM services.
Avoiding the failure mode: alert fatigue
The most common way a visibility project fails is not technical. It is configured to alert on every deviation, users receive dozens of notifications a day, they stop reading them within a fortnight, and the platform becomes an expensive map.
What we do differently:
- Start from the decision, not the data. For each proposed alert, ask what someone would do differently on receiving it. If there is no answer, it is a report, not an alert.
- Set thresholds per freight profile. A delay that is routine on a long-haul lane may be critical on a same-day pharmaceutical run. One global tolerance guarantees both false alarms and missed exceptions.
- Route by role. A customer service agent, a production planner and a transport manager need different subsets. Everyone receiving everything means nobody owns anything.
- Review after go-live. Six weeks in, look at which alerts were acted on and which were dismissed. Retire the noise. This step is almost always skipped.
Where the tracking data comes from
Visibility is only as good as its event sources, and this is where expectations need setting early. Typical sources, in rough order of reliability:
| Source | Typical coverage | Practical note |
|---|---|---|
| Telematics / GPS on own fleet | Continuous position | Highest fidelity; only covers freight you move yourself |
| Carrier system integration | Milestone events | Good for large carriers; depends on their data discipline |
| Network / location data providers | Multi-carrier milestones | Broad coverage without per-carrier integration |
| Ocean and air feeds | Vessel and flight milestones | Reliable but coarse-grained; gaps at the first and last mile |
| Manual or portal entry | Whatever gets keyed in | Fallback for the long tail; assume latency and gaps |
An honest design accounts for the fact that some legs will always be less visible than others, and says so, rather than presenting a partial picture as complete.
Frequently asked questions
Is SAP GTT the same as SAP Business Network Global Track and Trace?
They refer to the same capability area. SAP Business Network Global Track and Trace is the current official product name; SAP GTT is the abbreviation that practitioners, job postings and searches still use widely. If you are reading older documentation or a consultant's CV, expect to see the older name.
Do we need SAP TM to use Global Track and Trace?
No, though the two work well together. Tracked objects can be created from deliveries, purchase orders or shipments originating in ERP, so you can implement visibility without a full TM programme. That said, if you also plan and settle freight in SAP, running TM alongside gives you a single chain from planning through execution to cost — and most of the value in visibility comes from being able to act on what you see, which usually means acting in TM.
How accurate are the predictive arrival times?
Accuracy depends almost entirely on the quality and frequency of the underlying event data. Continuous telematics from your own fleet supports genuinely useful predictions. Milestone-only events from a carrier who reports at departure and arrival will produce a much coarser estimate, because there is nothing to refine it in between. We recommend setting expectations by lane and carrier during design rather than promising a single accuracy figure across a mixed network.
Can we give our customers access to shipment tracking?
Yes, and it is often the change with the clearest return. A filtered, customer-facing view of shipment status typically cuts inbound status enquiries substantially. The design questions are which fields a customer should see, how they authenticate, and what happens when a shipment goes wrong — a portal that shows a customer a problem before your team knows about it creates a different kind of call.
What about emissions and sustainability reporting?
Actual transportation emissions data can be captured from carriers along the same event stream used for tracking, which makes it considerably more defensible than modelled estimates based on distance alone. If sustainability reporting is a driver for the project, raise it during design — it affects which carriers you prioritise for integration and what data you ask them for.