- SAP Managed Tags:
Transporting goods from once place to another may not be the core-competency of many manufacturers/shippers. Hence, most of the manufacturers/shippers subcontracts the physical transportation process to external carriers rather than maintaining an internal fleet. In such scenarios, communication with the carriers is very critical. Carrier should know the details of the transportation requirements of the shipper/manufacturer and accordingly communicate their availability to execute the movement. Subsequently, during execution, carrier should report various shipment statuses to the shipper/LSP (Logistic Service Providers). They should be able to receive this information and capture it in the documents for tracking. Once the shipment is executed, the carrier should be able to communicate the invoice details and the shipper/LSP must evaluate these details to process the payment. Based on the mode of transport and other business requirements, additional communication may be required. For example, communication of shipping instructions & customs manifest, freight rates, ocean schedule, appointment information etc... Depending on the complexity and volume of communication, these communications are usually through phone calls, emails, external portals, third parties, electronic data interchange (EDI) or other means.
SAP TM Solutions:
Currently on-premise SAP Transportation Management (TM) solution has many solutions to communicate with carriers. Some of the most commonly used functionalities are:
For outbound communication to carriers, using Post Processing Framework emails can be triggered from TM documents such as Freight Order. For tendering process, there are out-of-the-box solutions available for emails and SMS (inbound and outbound). The content in the email and SMS can be configured. This is a common method to communicate with carriers if the volume is less and the shippers/carriers are comfortable handling the shipments via emails and SMS.
The SAP TM carrier collaboration portal (CCP) is a web portal UI supporting collaboration with carriers. It covers freight procurement, tendering, freight order execution and freight settlement. The portal uses the data from the shipper’s or LSP’s SAP TM system and provide most of the details required by the carrier. Additionally, carriers can respond to the shipper/LSP requirements through the portal. For example, carriers can respond to tender requests, update statuses and submit invoices for the executed shipment. Shippers/LSP usually manage the carrier’s access to the CCP and provide the URL link. CCP is designed for small carriers which do not have big IT infrastructure for other electronic communication. However, some shippers/LSP use CCP for all types of carriers.
Electronic Data Interchange (EDI) is the system-to-system exchange of business data in a standard electronic format. A standard format is needed so that the systems will be able to read and understand the data. There are several EDI standards in use today, including ANSI, EDIFACT, TRADACOMS and ebXML. For each standard there are different versions, e.g., ANSI 5010 or EDIFACT version D12, Release A. When two businesses decide to exchange EDI documents, they must agree on the specific EDI standard and version. The EDI architecture for communication is detailed below:
Even with standards like EDI, different carriers can use different kind of data and can have specific requirements for these communications. Hence, there is a significant investment required by shippers/LSPs to setup the connection to each of the carriers. In order to reduce this effort, cloud portals and EDI VAN are available which can take care of the communication from cloud portals to each of the carriers. The shippers/LSP need to connect the SAP system with only one portal and instead of each of the carriers. EDI VAN (such as SPS, Klientschmidt etc..) provides carrier connections, whereas cloud portals (GTNexus, INTRAA etc...) provide additional functionalities to carriers/shippers such as maintenance of schedules, freight contracts etc... The Cloud Portal architecture for communication is detailed below:
Issues:
Emails and SMS are not a scalable solution for most of the shippers/LSP to communicate with the carriers. The volume of communication can be very high and reading through each emails/SMS may not be a practical solution.
Carrier collaboration portal is designed for small carrier. Big carriers with EDI infrastructure may not be willing to use shipper’s portal (until and unless it is for a big shipper/LSP with high volume). For each shipper/LSP, the CCP URL will be a different and from a carrier’s perspective it will be cumbersome to log into each of the portal to respond to the orders. There is no standard integration of the CCP to the carrier’s system. As a result, the orders should be exported to the excel sheet manually, cleansed and then uploaded to the carrier system. Additionally, the carriers will have to download the data from their system, format and then upload in the CCP. Moreover, the shipper must manage the user access and credentials of these carriers, which can change over time. This solution becomes unsustainable as more and more shippers/LSPs use CCP and demand carriers to process orders via CCP.
EDI is the old and currently the preferred option for carriers to connect and communicate with shippers and LSPs. However, the EDI implementation is complex and shippers/LSP will have to invest significant time and money to set it up. There are several EDI formats for various communications. (Refer https://ediacademy.com/EDI%20Transactions.pdf more details). Skilled practitioners are required to implement and maintain the complex mapping in the middleware to convert the SAP TM XML format to EDI format. In addition to different standards of the communication, many carriers and shippers use customized segments and fields. Overtime this may become complex and without the key EDI practitioners, it becomes extremely challenging for the shipper/LSP to maintain the EDI set up. Secondly, EDI may not be real-time, as the processing can be done on a batch mode. There is a technological revolution currently going on to replace the EDI communication with APIs (Application Programming Interface). Since IT may not be the core-competence (refer https://hbr.org/1990/05/the-core-competence-of-the-corporation for more details) of shippers/LSPs, investing and maintaining the EDI (which has a chance to get phased out by APIs) may not be the ideal solution for many shippers/LSPs.
Cloud portals and EDI VAN can significantly reduce the shipper’s investment in the IT systems. However, the integration of the cloud portal to standard ERP/TMS systems is not easy. For example, the same cloud portal will have to integrate with multiple ERP/TMS products such as SAP, Oracle, JDA etc.… As a result, the integration is not standard and PI mapping is required to connect the SAP systems with Cloud portals. Additionally, not all carriers will be connected to the cloud portal and we may require other integration set up to connect with these carriers. This again is a niche skill set and maintenance of this integration is still a considerable effort.
Business case of LBN
Because of these issues, a SaaS (Software as a service) model cloud portal/network solution from SAP is a practical solution for SAP customers. In this architecture the carrier and shippers/LSPs connect to one cloud network for freight collaboration.
SAP Logistics Business Network (LBN) is a secure network from SAP to connect multiple business partners for inter-company logistics collaboration. In tight integration with the SAP TM, it shall allow parties to manage logistics transactions, exchange relevant information & documents, and gain insights across the complete value chain. It is a cloud-offering subscribed by shippers/LSPs, who then invite their carrier ecosystem to the service. For companies looking to holistically manage and drive efficiencies in global shipping & logistics, SAP LBN will be the only network in the market to cover all major modes and geographies, as well as tying into other networks.
From a shipper/LSP perspective they need to connect to only one cloud system (LBN). SAP takes care of the connection with individual carriers – either via EDI/API or portal/LBN UI. Since there is standard integration between LBN and SAP TM, middleware mapping is not necessary to convert the SAP TM XML messages to any other format. SAP LBN can receive SAP TM XML format and process it. Similarly, there will be standard receiver programs to receive the messages from the LBN. This will greatly reduce the IT investment required to communicate with the carriers. The communication architecture for LBN is detailed below:
Similarly, for carriers, they need not work individually with every shipper/LSP to set- up/update the EDI connections. Carriers will be able to see the shipments of multiple shippers/LSPs using one LBN log-in. For big carriers, SAP may provide solutions to connect LBN with carrier systems. So, this will be a one-time activity and once the connection is set-up, the carriers can seamlessly integrate with all SAP TM shippers/LSPs without much effort.
Additionally, LBN has its own database and UI with most of the SAP TM CCP functionalities(tendering, subcontracting, execution and settlement). It runs on SAP Cloud Platform, which uses the Amazon Web Services infrastructure hosted in a data center. Non-EDI carriers can use the FIORI based UI to execute various processes. Latest LBN 2.0 release has some additional functionalities in UI which are not present in TM CCP. Some of the advanced functionalities in LBN 2.0 (freight collaboration option) are:
We expect SAP to provide more functionalities in LBN, as per the market requirement.
Conclusion:
LBN – freight collaboration seems to be the right architecture to solve the long-standing carrier communication problem in the transportation process for SAP shippers/LSP. Since LBN has its own UI for carriers and shippers to collaborate, this solution can be used for both big and small carriers. However, number of carrier systems which are connected directly to LBN (B2B integration) are very limited. We expect this to grow over a period and SAP publishes the details publicly, so that customers can take calculated decisions.
LBN – freight collaboration is only a part of the product functionality. GTT and Material tractability (beta program) are also available in the same network. It is important to understand LBN modules and the currently available functionalities in freight collaboration option. Moreover, LBN is connected to digital networks such as uber freight which is an entirely new process. In my next blog, I will be detailing the available functionalities in LBN – freight collaboration option.
SAP TM Solutions:
Currently on-premise SAP Transportation Management (TM) solution has many solutions to communicate with carriers. Some of the most commonly used functionalities are:
- EMAIL / SMS:
For outbound communication to carriers, using Post Processing Framework emails can be triggered from TM documents such as Freight Order. For tendering process, there are out-of-the-box solutions available for emails and SMS (inbound and outbound). The content in the email and SMS can be configured. This is a common method to communicate with carriers if the volume is less and the shippers/carriers are comfortable handling the shipments via emails and SMS.
- Carrier Collaboration Portal (CCP):
The SAP TM carrier collaboration portal (CCP) is a web portal UI supporting collaboration with carriers. It covers freight procurement, tendering, freight order execution and freight settlement. The portal uses the data from the shipper’s or LSP’s SAP TM system and provide most of the details required by the carrier. Additionally, carriers can respond to the shipper/LSP requirements through the portal. For example, carriers can respond to tender requests, update statuses and submit invoices for the executed shipment. Shippers/LSP usually manage the carrier’s access to the CCP and provide the URL link. CCP is designed for small carriers which do not have big IT infrastructure for other electronic communication. However, some shippers/LSP use CCP for all types of carriers.
- EDI/Interfaces:
Electronic Data Interchange (EDI) is the system-to-system exchange of business data in a standard electronic format. A standard format is needed so that the systems will be able to read and understand the data. There are several EDI standards in use today, including ANSI, EDIFACT, TRADACOMS and ebXML. For each standard there are different versions, e.g., ANSI 5010 or EDIFACT version D12, Release A. When two businesses decide to exchange EDI documents, they must agree on the specific EDI standard and version. The EDI architecture for communication is detailed below:
- Cloud portals/EDI VAN:
Even with standards like EDI, different carriers can use different kind of data and can have specific requirements for these communications. Hence, there is a significant investment required by shippers/LSPs to setup the connection to each of the carriers. In order to reduce this effort, cloud portals and EDI VAN are available which can take care of the communication from cloud portals to each of the carriers. The shippers/LSP need to connect the SAP system with only one portal and instead of each of the carriers. EDI VAN (such as SPS, Klientschmidt etc..) provides carrier connections, whereas cloud portals (GTNexus, INTRAA etc...) provide additional functionalities to carriers/shippers such as maintenance of schedules, freight contracts etc... The Cloud Portal architecture for communication is detailed below:
Issues:
Emails and SMS are not a scalable solution for most of the shippers/LSP to communicate with the carriers. The volume of communication can be very high and reading through each emails/SMS may not be a practical solution.
Carrier collaboration portal is designed for small carrier. Big carriers with EDI infrastructure may not be willing to use shipper’s portal (until and unless it is for a big shipper/LSP with high volume). For each shipper/LSP, the CCP URL will be a different and from a carrier’s perspective it will be cumbersome to log into each of the portal to respond to the orders. There is no standard integration of the CCP to the carrier’s system. As a result, the orders should be exported to the excel sheet manually, cleansed and then uploaded to the carrier system. Additionally, the carriers will have to download the data from their system, format and then upload in the CCP. Moreover, the shipper must manage the user access and credentials of these carriers, which can change over time. This solution becomes unsustainable as more and more shippers/LSPs use CCP and demand carriers to process orders via CCP.
EDI is the old and currently the preferred option for carriers to connect and communicate with shippers and LSPs. However, the EDI implementation is complex and shippers/LSP will have to invest significant time and money to set it up. There are several EDI formats for various communications. (Refer https://ediacademy.com/EDI%20Transactions.pdf more details). Skilled practitioners are required to implement and maintain the complex mapping in the middleware to convert the SAP TM XML format to EDI format. In addition to different standards of the communication, many carriers and shippers use customized segments and fields. Overtime this may become complex and without the key EDI practitioners, it becomes extremely challenging for the shipper/LSP to maintain the EDI set up. Secondly, EDI may not be real-time, as the processing can be done on a batch mode. There is a technological revolution currently going on to replace the EDI communication with APIs (Application Programming Interface). Since IT may not be the core-competence (refer https://hbr.org/1990/05/the-core-competence-of-the-corporation for more details) of shippers/LSPs, investing and maintaining the EDI (which has a chance to get phased out by APIs) may not be the ideal solution for many shippers/LSPs.
Cloud portals and EDI VAN can significantly reduce the shipper’s investment in the IT systems. However, the integration of the cloud portal to standard ERP/TMS systems is not easy. For example, the same cloud portal will have to integrate with multiple ERP/TMS products such as SAP, Oracle, JDA etc.… As a result, the integration is not standard and PI mapping is required to connect the SAP systems with Cloud portals. Additionally, not all carriers will be connected to the cloud portal and we may require other integration set up to connect with these carriers. This again is a niche skill set and maintenance of this integration is still a considerable effort.
Business case of LBN
Because of these issues, a SaaS (Software as a service) model cloud portal/network solution from SAP is a practical solution for SAP customers. In this architecture the carrier and shippers/LSPs connect to one cloud network for freight collaboration.
SAP Logistics Business Network (LBN) is a secure network from SAP to connect multiple business partners for inter-company logistics collaboration. In tight integration with the SAP TM, it shall allow parties to manage logistics transactions, exchange relevant information & documents, and gain insights across the complete value chain. It is a cloud-offering subscribed by shippers/LSPs, who then invite their carrier ecosystem to the service. For companies looking to holistically manage and drive efficiencies in global shipping & logistics, SAP LBN will be the only network in the market to cover all major modes and geographies, as well as tying into other networks.
From a shipper/LSP perspective they need to connect to only one cloud system (LBN). SAP takes care of the connection with individual carriers – either via EDI/API or portal/LBN UI. Since there is standard integration between LBN and SAP TM, middleware mapping is not necessary to convert the SAP TM XML messages to any other format. SAP LBN can receive SAP TM XML format and process it. Similarly, there will be standard receiver programs to receive the messages from the LBN. This will greatly reduce the IT investment required to communicate with the carriers. The communication architecture for LBN is detailed below:
Similarly, for carriers, they need not work individually with every shipper/LSP to set- up/update the EDI connections. Carriers will be able to see the shipments of multiple shippers/LSPs using one LBN log-in. For big carriers, SAP may provide solutions to connect LBN with carrier systems. So, this will be a one-time activity and once the connection is set-up, the carriers can seamlessly integrate with all SAP TM shippers/LSPs without much effort.
Additionally, LBN has its own database and UI with most of the SAP TM CCP functionalities(tendering, subcontracting, execution and settlement). It runs on SAP Cloud Platform, which uses the Amazon Web Services infrastructure hosted in a data center. Non-EDI carriers can use the FIORI based UI to execute various processes. Latest LBN 2.0 release has some additional functionalities in UI which are not present in TM CCP. Some of the advanced functionalities in LBN 2.0 (freight collaboration option) are:
- Uber Freight real-time pricing in Freight tendering and subcontracting
- Dock appointment scheduling
- Dispute Management in Freight settlement
We expect SAP to provide more functionalities in LBN, as per the market requirement.
Conclusion:
LBN – freight collaboration seems to be the right architecture to solve the long-standing carrier communication problem in the transportation process for SAP shippers/LSP. Since LBN has its own UI for carriers and shippers to collaborate, this solution can be used for both big and small carriers. However, number of carrier systems which are connected directly to LBN (B2B integration) are very limited. We expect this to grow over a period and SAP publishes the details publicly, so that customers can take calculated decisions.
LBN – freight collaboration is only a part of the product functionality. GTT and Material tractability (beta program) are also available in the same network. It is important to understand LBN modules and the currently available functionalities in freight collaboration option. Moreover, LBN is connected to digital networks such as uber freight which is an entirely new process. In my next blog, I will be detailing the available functionalities in LBN – freight collaboration option.
8 Comments
| User | Count |
|---|---|
| 3 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
