The benefits of integrating SAP Transportation Management with a Geographic Information System (GIS)
SAP has been offering in its solutions portfolio (for over 15 years) the SAP Transportation Management component, which is a leading TMS (Transportation Management System) in the market with a shipper and carrier approach.
In the process of digitizing the business processes of a company, it's crucial to maximize the enrichment of transportation-related information by relying on complementary solutions (Customs, 5PL, GIS, etc.).
SAP TM offers a set of configurations and a data modelization that allows smooth operation with geographic information systems.
The limitations of SAP TM Backend
By default, without a GIS (Geographic Information System), SAP TM offers very generic logic to manage the geographic aspect. Indeed, only a parameter table is provided to retrieve geographical coordinates at the regional level (usually corresponding to the barycenter of the department). Thus, all points belonging to the same region in SAP TM will have assigned the same geo-coordinates. This leads to incorrect distance and duration calculations because the distance between two superimposed points is... null.
How to address this issue
Four services are essential to enrich all transportation data:
Map Integration
The basis of our implementation relies on rendering an interactive map across several SAP S/4 applications, notably:
- Transport cockpit - Transport planning interface
- Transport network cockpit - Transport network management interface
- Business documents (Freight Units/Orders, Container Units, etc.).
Geocoding
The first step in enriching SAP TM data with attributes from the Geographic Information System is to accurately place 'points' on our map through geo-coordinates concept on location master data.
Within the SAP ecosystem, two objects will be involved through geocoding:
- The Business Partner (BP): which constitutes a common data model for all third parties such as clients, suppliers, etc...
- The location: which is the fundamental data dedicated to SAP TM and will centralize geo-coordinates, opening hours, etc...
In a TMS approach, it's important not only to input the address of the BP but also the associated geo-coordinates of the location. SAP cannot independently determine which geo-coordinates are linked to an address, so we must rely on a geocoding service.
Geo-routing
Once the geo-coordinates of the locations are calculated, we can delve deeper and calculate the distances, durations, and routes for our transport missions based on:
- Truck speeds (possibility to apply speeds per segments in order to be more accurate on the planned duration)
- Truck dimensions (height can significantly influence routing)
- Locations to visit
Technical Note:
To display a route on a map, we expect the GIS to provide us with all the points to visit. A pair of points will form a segment, and the collection of segments will form the route.
To trace a route between Lyon and Le Havre, no less than 12,000 segments are necessary. If the GIS provided us with the pairs of geo-coordinates for all these segments, the message would become extremely heavy.
The GIS provider decided not to supply all the segments but rather encode all this information into a string (similar to what is done by Google Maps) called a Polyline to reduce the message size propagated from the GIS to SAP TM by about a factor of 10.
Instead of resorting to an external system we opted to implement the decoding algorithm for this string directly in ABAP as close to SAP TM as possible. This decision was made to benefit from:
- Availability - No reliance on third-party systems
- Performance
Example:
Polyline : BFoz5xJ67i1B1B7PzIhaxL7Y
Polyline decoded:
Some editors directly provide the coordinates as a matrix, so you don’t need to decode the string and you can directly integrate it into the process controller configured on your backend.
If you decide to use SAP HSS, the route is already decoded before being propagated to SAP Transportation Management.
Note that, by default, SAP TM allows for setting up a 'buffer' on the calculation of these distances to avoid constantly querying the GIS.
For instance, if the buffer is set to 365 days, SAP checks internally if it already has the distance and duration information for a transport mission. If it does and the information is less than 365 days old, the system won’t call the GIS.
Configuration
On a SAP TM perspective, we based our implementation on process controllers.
SPRO > Transportation Management > Basic Functions > Geographical Map > Define Settings for Geographical Map
Georouting strategy
Then, we copied the standard class (/SCMB/CL_GEOROUTING_CONNECTOR) assigned to the standard georouting strategy and enhanced it with our custom method:
Standard class
Custom class based on standard class
Define and declare the strategy and the associated method on
SPRO > Transportation Management > Basic Functions > Process Controller > Assign Methods to a Strategy
Define Methods
SPRO > Transportation Management > Basic Functions > Process Controller > Define Methods
SPRO > Transportation Management > Basic Functions > Process Controller > Assign Methods to a Strategy
Geopositioning of Resources
Lastly, if your organization provides real-time geopositioning of trucks, this information can be represented on the map within SAP TM. We typically manage the geopositioning of the transport vector, and naturally, all associated business documents (Freight Units/Orders among others) inherit the geopositioning of the resource.
For this, we exposed the function module /SCMTMS/RES_POSITION_UPDATE as a webservice.
Further possibilities
Cost and CO2 Allocation
During these few lines, I haven't delved into a comprehensive presentation of SAP TM. It's important to note that we distinguish Freight Units (which represent transportation requirements) from Freight Orders (which represent transportation vectors). A Freight Order can contain multiple stages. A Freight Unit shares at least one stage with the Freight Order.
Each stage of the Freight Order is assigned a distance and duration. This information is propagated to the Freight Unit. As a result, your organization naturally reconciles the distances traveled on transportation missions with the distances covered by goods, even if they have multiple stages. These data can then be used to:
- Better allocate the costs of transported goods before analysis by controllers of management
- Understand better the CO2 generated by transportation activities on a product level
ETA
In addition to propagating positional information to SAP TM through geolocation, it's possible to calculate the Estimated Time of Arrival (ETA) for trucks. This ETA should be used within organizations to be proactive. For instance, in certain logistical situations, such as a traffic jam on a highway, the ETA can serve as the basis for issuing alerts to anticipate managing a potential crisis.
How to Implement a GIS?
You can rely on SAP Hana Spatial Services or go with your own connectors.
Two methodologies exist for implementing a TMS <> GIS integration:
- The TMS is not yet live: In this case, as data gradually integrates between the ERP and TMS, the TMS queries the GIS to enrich the data as they're created.
- The TMS is already live: Data has been used for some time with incorrect geographical attributes. It would be necessary to proceed with enriching the existing data as part of a mini-project.
Hopefully these few lines help businesses and consultants to understand better how powerful and flexible the GIS integration can be on SAP Transportation Management.
Any question or remark, don't hesitate.
Adrien MANIER
SAP Transportation Management Expert
- SAP Managed Tags:
| User | Count |
|---|---|
| 4 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
