Simplifying complexity: The power of standard SAP ERP / SAP TM integration

In the past, before SAP TM, customers running SAP ERP had a much taller wall to scale in order to reap the benefits of having a sophisticated Transportation Management System (TMS) integrated to their SAP ERP system. The various benefits that a customer typically seeks in a TMS implementation are contingent on having a solid integration between the systems, and for customers already using SAP ERP there are some tremendous advantages that are brought to the table via the standard integration options between SAP ERP and SAP TM.

Other non-SAP TMS solutions have varying ways of integrating to the SAP ERP system, and have APIs that are used to exchange and process data, but as one digs into the details things are not necessarily as simple as they may sound during a sales cycle.

For example, here are some typical questions in the design of any custom integration:

* Which APIs need to be triggered? In which order should they be arranged?

* Which middleware to use?

* Which SAP ERP fields should be used to map to the fields in the TMS? Do the fields' lengths, data types, and other attributes match, or is there interpretation that needs to be made in passing the data from one system to the other (and back)?

* Does the process require complex orchestration by the middleware? For each piece of the process, should the APIs be triggered in a particular order in real time, or instead in the background via a batch job?

* Do any background processes need to be scheduled at a carrier and/or shipping location level? (If so, likely multiply the number of API integrations and batch jobs by the number of carriers / shipping locations…)

* Is it the right level to integrate to the SAP order (sales or purchase order), or to the delivery? or both? ...and is it possible for the TMS to handle both?

* How should the dates flow through the process? If the TMS determines different dates, which fields in SAP ERP should be modified to reflect this?

* Considering the availability of this rich transportation network master data in the TMS, what is the best approach to manage transit time determination in SAP ERP? Continue to use the standard ERP route determination, or build an integration to the TMS that runs during the Available To Promise (ATP) process?

* How will the key data elements (customer / customer location / carrier / material) from the ERP system be synchronized with the TMS? (read: custom interfaces…)

* At which point(s) in the process should a document be locked in one system so that the user cannot modify it in the other?

Certainly, with this complexity comes work effort for the whole team – documenting and mapping the fields, setting up the technical integration between the systems, constructing any programs that need to be run in SAP ERP to create the messages and send the information to the TMS, as well as any corresponding programs that need to be constructed to process the information that comes back from the TMS to SAP ERP, and so on. In a complex / sophisticated integration this can take months to fully scope, build, and test, and all of this work only then finally puts the team in a position where the integration is up and running and the actual end-to-end process can be tested. Depending on the way the integration works, the outcome can be as many as hundreds of API calls that need to be made – and orchestrated perfectly – in order to support a transportation process with the number of carriers and locations that a sizable shipper typically has.

With SAP TM, and the use of SAP PI, SAP ERP customers have the opportunity to save significant amounts of time, effort, and risk in realizing the benefits of having a sophisticated TMS. The connectivity between ERP and TM for transactional data, via PI, is in this scenario a case of system configuration rather than development and complex middleware integration work, and can be done very quickly, with a skilled PI consultant reducing the time to having the systems communicating (orders, deliveries, shipments if necessary, freight settlement documents) to possibly being a week or less, as opposed to the weeks or months described above. The key master data (customers, locations, vendors, materials) is sent in a different manner – via the Core Interface, aka “CIF” – which uses an RFC connection from ERP to TM…and is also standard. When considering the amount of work and complexity that can come with custom interfaces, just the things mentioned in this paragraph can save thousands of dollars and significantly reduce risk in a project.

Additionally, there are some very helpful and powerful functionalities that are enabled out-of-the-box with this integration model. For example, when the planning is done in SAP TM and the freight order is created, the key dates from this freight order are conveyed back to SAP ERP automatically. The Sales Order Scheduling (SOS) process enables a standard call from the sales order in SAP ERP to SAP TM in order to access TM’s detailed transportation data, including customer-specific delivery windows as well as carrier transit times, and use this to determine the transportation mode and transit time that should be considered for the ATP process in SAP ERP. Planning can take place seamlessly at the order and the delivery level, for example creating a preliminary plan based on the order and then replanning once the deliveries are created / actual quantities updated etc. There is standard functionality from TM to trigger delivery creation in ERP based on the document splitting in TM (for example two incompatible hazardous materials on the same order being planned separately and resulting in two deliveries). The Change Controller enables out-of-the-box, configurable flexibility to manage changes in various ways, so that if for example an order quantity is changed by <5% to not replan it, but above a 5% deviation to rescind the tender to the carrier and replan the order. And don’t forget the power of the "document flow" in SAP – a user can very quickly (and with minimal training compared to a non-TMS user needing to log in and access a separate TMS system) move from the base document in SAP ERP and jump into TM to view the transportation-related event milestone information that has come back from the carrier in order to answer the “where is my order?” question that Customer Service so often receives. These things are also generally possible with an external TMS, but again, require construction instead of configuration.

SAP has been investing heavily into their TMS product, driving SAP TM a long way in only the past five years in the chase to close the gaps in functionality and reach the competitors residing in the top right corner of the Gartner quadrant, and SAP is generally accelerating their pace of innovation even faster than their competitors. For customers with must-have functionalities that are not standard in SAP TM, Novigo has significant experience extending the solution as well, for example calling out to SMC3 CarrierConnect for US-based LTL transit times. Now, for SAP ERP customers, the decision as to whether to pursue a TMS project or not can have a much lower “cost hurdle” rate, as the time to value realization can be much quicker due to the efficiencies that the native integration brings, significantly reducing time (and therefore cost) in all phases of an implementation project – blueprinting, build, testing, etc. Additionally, the connections that are available and standard between the systems are supported by SAP, so this is not a static set of functionalities that is developed for one specific purpose and would likely require development to upgrade in the future, or significant additional consideration and testing for example when undertaking either a TMS or ERP version upgrade.

Indeed, for existing SAP ERP customers there is now also the decision-maker’s question from the other perspective – if the benefits of the SAP TMS can be realized so quickly using standard SAP connections, there would need to be a truly game-changing benefit to elect to do things “the hard way” and take on the challenge of a custom integration to a non-SAP TMS.

It is of course also possible to use middleware products other than SAP PI to facilitate this communication, and also to connect other 3rd-party tools to TM; if the customer does elect to go this route Novigo has deep experience here as well – possibly a topic for a subsequent blog post...

Novigo has more experience than any other partner in the SAP ecosystem in helping customers to realize the benefits of SAP TM solutions, with total implementation times as low as 19 weeks(!). For customers who run SAP ERP and are considering whether to embark on a TMS project, we can only encourage you to contact Novigo and learn more about what “doing things the easy way” can look like.