You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 23 Next »

Issue

BluJay is the legacy TMS system in North America (NA). This system support multiple modes of Transport; Road, Rail, Air and Ocean. With the introduction of SAP Transportation Management in S/4 HANA, there are many functions that can be considered overlapping with BluJay. The complexity of North America transportation industry makes implementing a new TMS solution challenging. This KDD will set out some of these known challenges and potential solutions in order to make an informed decision if BluJay needs to be retained, or should be replaced as part of ERP Rebuild project. 


Recommendation

If Syensqo would decide to replace BluJay as part of ERP Rebuild project, it would have significant impact on the scope and requirements of SAP Transportation Management. This would increase the risk for the project overall. Business users are very familiar with BluJay and we know for sure that carriers are already using BluJay as a platform. And, BluJay must be replaced with a new version before 2026.

It will be very challenging to include replacement of BluJay within the scope of ERP Rebuild project. To mitigate these risks, it is recommended to integrate SAP TM with BluJay rather than undertaking a replacement as part of ERP Rebuild Project. 


Background & Context

Introduction to BluJay

BluJay Transportation Management is a complete, integrated software solution that manages the entire logistics operation from front to back, handling multiple languages, currencies, and time zones. It allows shippers to manage all multimodal transportation activities for one shipment. BluJay is used by all GBU's in North America region.

Features:

  • Contracts & tariffs management
  • Load optimisation
  • Mode and carrier determination
  • Electronic booking
  • Freight cost calculation (planned & unplanned costs)
  • Collaborative status tracking
  • Transport reporting (carrier compliance, freight costs, KPIs…)
  • Freight audit
  • Freight payment

BluJay integration process (based on WP1)


Planned Replacement of current BluJay version

Currently a project is starting to implement a new BluJay version (aka TM Shippers). The current BluJay solution (aka Kewill Transport) will no longer be supported by CLX (an important TSP). The deadline for this transition is set at beginning of 2026. As this transition has been postponed multiple times it is no longer possible to extend beyond that.

The expectation is that the TM Shippers transition is a 5-6 month project and some of high level activities required are listed below:

  • Business requirements to be accounted for.
  • Thorough TMS configuration.
  • Establish super users and Training.
  • New integration between SAP and TM Shippers.
  • Carriers to be transferred over...

This transition is more than just a system upgrade and should be considered as a new implemented solution.

North America Specific Requirements

United States is the most tightly regulated country concerning transportation. Transportation law covers most aspects of travel and commerce on the road, air, and water. This includes regulating vehicles and vessels, safety standards, and shipping activity. The U.S. Department of Transportation (DOT) is the primary federal regulatory agency.

Federal agencies charged with regulating the various means of transportation include:

  • Air transportation via the Federal Aviation Administration
  • Highway transportation via the Federal Highway Administration
  • Railroad transportation via the Federal Railroad Administration
  • Water transportation via the Maritime and Waterways Administration


SMC3 CzarLite & CarrierConnect XL

The industry standard for charge calculation in United States is to calculate transportation charges using CzarLite and CarrierConnect. Both are managed by SMC3. In a nutshell, SMC3’s CzarLite LTL base rate provides a neutral rating standard that allows LTL shippers to quickly and accurately evaluate shipping rates from multiple carriers at a glance to help make informed carrier selection decisions - removing the unnecessary complexity that would otherwise accompany this process.

In North America the rate base - or “list price” of freight charges - is usually not the price shippers actually pay for services. This is because carriers deliver discounts on top of this price to account for the variances in freight class, density, distance, and other factors.

Another layer of complexity: each carrier works with their own base rate and these “list prices” vary across each carrier. This means understanding the true cost of working with an individual carrier requires complicated math to untangle base rates, freight discounts, and other factors. This makes it difficult to compare carriers, and it often leads to billing discrepancies. This is where SMC3’s CzarLite fills a critical and growing need.


Requirements for further detailed analysis

If BluJay is to be replaced, then the SAP TM system has to take over the North America specific functions. To do a full breakdown of all transportation functions and requirements would go into too much detail for this KDD. Instead this KDD will focus on the functions that have been highlighted as most challenging and critical for any TMS system to be considered a mature solution for North America. Three toptics have been highlighted and these topics are all in the category of charge calculation:

  1. SMC3 CzarLite & CarrierConnect XL
  2. Fuel Price and other index tables
  3. Accessorial Charges

Next in this document we'll look into how SAP can handle these type of charges. If these solutions are considered mature enough, then North America could be included as part of standard SAP TM rollout with replacement of BluJay. If these solutions are insufficient then BluJay has to stay part of the system landscape.



Replacement vs Integration

Replacing BluJay

In this section we'll go into more detail on the critical requirements for North America and the solutions that SAP TM offers to handle these requirements.

1. SMC3 CzarLite & CarrierConnect XL 

SCM3 offers support for integration of SAP TM with SMC3 platform (please see service offering attachment in See Also). SAP provides a prepared configuration guide on how to set up integration from SAP TM to SMC3 platform.

When transportation charges are to be calculated SAP calls the SMC3 platform and it receives the calculated charges, including duration information. When and for which carriers this call needs to happen is part of the Freight Agreement setup.  The Freight Agreement has a Charge Calculation Sheet. Inside this calculation sheet a charge line can be assigned with calculation method "External" (CALL_SMC3).

This calculation method utilises web services that encapsulate functionality that are called over the internet. For these charge types the system will call SMC3 to collect the transportation charges.

Some comments:

  • Configuration guide is attached (see section See Also).
  • SAP code has been last updated in 2023 (class /SCMTMS/CL_TCC_GET_RATE_SMC3), latest SAP note is from 2024 (3439301). This indicates that code has been maintained and is being used.
  • SMC3 has support for integration with SAP TM.

When North America is going to be scoped, this is the technology that is going to be used to support SMC3 CzarLite & CarrierConnect XL processes.

 2. Fuel Price and other index tables

Introduction

A fuel surcharge is an extra fee that is charged by trucking companies to help cover the constantly fluctuating cost of diesel fuel. As fuel prices increase or decrease, fuel surcharge rates can increase or decrease along with them. The U.S. Department of Transportation estimates that fuel charges change about $0.10 per week on average, meaning fuel surcharges are always fluctuating with them. There is no single method to calculate fuel surcharge. Each carrier typically has their own formula for calculating fuel surcharge.

Solution

Fuel surcharges can be custom build using web services (similar as SMC3 integration), however most often this is solved by using Rate Tables. Rate Tables can be embedded in the Freight Agreement, but it is also possible to maintain a rate table outside of the agreement and reference it in multiple agreements.

Note: This rate table can also be setup with a dimension of carrier id, so that one rate table can cater for multiple carriers.

It can be decided if this requires automation, or that manual maintenance of the rate table is sufficient.

3. Accessorial Charges

Introduction

Carrier accessorial charges occur for many different reasons. Generally, these fees fall into three different categories: administrative, in-transit, and equipment.

  • Administrative: Errors with a bill of lading or other documentation discovered after a shipment’s pick-up.
  • Equipment: Shipments that require additional equipment for loading, delivery, or transport. Additional accessorial fees may be charged if those requirements aren’t stated in advance of pick-up.
  • In-transit: Charges incurred after shipment pick-up, during transport, or at the time of delivery, such as layover, out-of-route miles, limited access, or redelivery.

Some accessorial charges in transportation are anticipated as part of the transportation needs of a shipment. These carrier accessorial charges are applied at the time of shipment booking. Fees incurred later often result from errors during planning or poor visibility of transportation movements.

Solution

Accessorial charges is a broad category. How these charges are determined and calculated requires multiple solutions. Here an overview of solutions that can be utilised in the solution design.

a. Calculation Base in Charge Calculation Sheet

Calculation bases specify the base that the system uses to calculate charges for the scale. Calculation bases always correspond to an underlying scale base. There are 131 standard calculation bases available in the system. Some bases to highlight, together with accessorial type it can be used for:

  • Dangerous Goods Indicator (Hazmat Surcharge)
  • Days (Layover)
  • Goods Value / Insurable Value (Excess Cargo Insurance)
  • Number of intermediate stops (Additional Stops)
  • Delivery location holiday / Weekday (Weekend Surcharge)

For complete list of calculation bases, click here.

b. Event Driven Charge Calculation

In SAP TM, there is Event Driven Charge Calculation functionality. An event profile can be defined that is added to Freight Order type customisation. The events in the profile can be linked to a charge type. Hence during FO charge calculation, if the the charge type is present in the Freight Agreement and the respective event is reported, the charges associated become active and are calculated accordingly.

Common scenarios:

  1. Specific event and flat charges: In this scenario, the carrier charges an additional amount if a specific event occurs. For example, carrier may charge for cleaning, destination charges, fumigation etc… A flat rate is usually charged and the same can be maintained against the charge type in the freight agreement. Above screen shots detail a working model for cleaning event scenario.

  2. Charges based on expected and actual events: In this scenario, based on planning, an event (for example departure) is expected to happen on a certain date/time. If the actual event happens after a specified grace period, then the penalty amount is charged by the carrier for the additional waiting time. TM can automatically detect the charge applicability based on the timing of the actual event posted. Based on the expected event date, reported event date and the grace period, the charge is applied on freight order. SAP has provided a standard calculation bases - DELAY_TOT & GRACE_DAYS. The charge type, created using these calculation bases, can use rate table with the delay duration for various combinations. Currently the delay is calculated in days and in case we require hours or minutes in the rate tables, then the helper assignment in these calculation bases (/SCMTMS/CL_TCC_CB_DELAY & SCMTMS/CL_TCC_CB_REL_CBASE) have to be modified. This scenario/requirement is predominantly for delay/demurrage charges.

c. Dispute Management for Freight Settlement

A freight settlement dispute case is an individual business document that captures differences in logistics item quantities or charge amounts in a freight order or carrier invoice. As a requester of transportation services, such as a shipper, you own the information in the freight order. Your provider of transportation services, such as your carrier, checks the accuracy of the charge and logistics details in your freight order.

In the self-billing process, the service provider uses the SAP Business Network for Logistics to create a dispute case against a freight order.

In the invoice submission process, the process of settlement between you and your service provider is based on an invoice that your service provider submits to you for a freight order. Your service provider can use the SAP BNL portal to submit such an invoice. For example, your service provider can submit an invoice that contains changes to logistics details such as gross weight or gross volume, or changes to charge details such as rate or an additional charge line for an unplanned charge. In these situations, the system captures the changes in a dispute case and links the dispute case to the invoice your service provider submits.

If the dispute case fails the tolerance limits you specify in Customising, you must manually review the dispute case on the Freight Settlement Dispute Cases app.


Assumptions for replacing BluJay

  • SAP Transportation Management license will be Advanced TM
  • SCM3 can support on the integrating CzarLite & CarrierConnect XL.
  • Not all possible accessorial charges need to be supported.
  • Accessorial charges that are not supported can be handled by Dispute Management.
  • Most accessorial charges that are part of normal charge calculation can be handled with standard TM calculation bases. Some enhancements might be required, but scope are expected to be limited.
  • Events are integrated back to SAP TM.
  • Events with a fixed rate are covered by standard SAP. There where calculations are involved for e.g. duration or number of occurrences, enhancements might be required.
  • Carriers start using SAP Business Network for Logistics.



Integration with BluJay

To have a better understanding of what the process will look like when SAP S/4 HANA system is integrated with BluJay it is probably easiest to describe it by following a (complex) transportation scenario. Below describes a scenario with two Sales Orders for one customer, consolidation in one container and it is a CIF shipment to port of discharge.

Note: Steps described are based on full manual planning. For automation see paragraph "Automation and Shortcuts".

  1. Two Sales Orders are created (CIF incoterms in this scenario).
  2. With early transportation planning setup, two Freight Units are created.
  3. The Freight Units are captured in the Transportation Cockpit for consolidation planning. User will create a Container Unit for the consolidation.
  4. On the Container Unit a Default Route is applied, creating several stages for transportation.
  5. A Freight Order is created for Pre-Carriage from plant to port.
  6. A Freight Booking is created for ocean freight stage (port to port) (Ocean Freight Booking follows standard process - no BluJay integration).
  7. The TM Road Freight Order is interfaced to BluJay to create a TMS Order.
  8. In BluJay, through a carrier selection process, a carrier is assigned.
  9. TMS Order is communicated with carrier.
  10. Updates from TMS Orders are updated back to Freight Order, including carrier, planned departure date, planned arrival date, transportation charges, order status.
  11. When the delivery is created the Freight Unit is updated with linkage to the delivery (the Freight Unit is consumed by the delivery).
  12. The deliveries are prepared and loaded into the container.
  13. Once the truck departs the deliveries are PGI-ed (goods are stock in transit).
  14. Events as reported in TMS order are updated back to Freight Order.
  15. The Freight Order charges are posted to ERP.
  16. The Freight Booking charges are posted to ERP.
  17. Once vessel has arrived at port of discharge, the POD is posted (goods are out of stock).


Automation and Shortcuts

The presented scenario is a complex scenario. However, for scenarios where the process is more straightforward there are options to have automation or apply shortcuts. Where and how this is applied in the process will be part of detail design. Some options that can be considered are;

  • Based on Shipping Conditions e.g. "Sea FCL 40ft", where the full delivery will be loaded into one container, instead of Freight Unit creation the system can create the Container Unit directly.
  • Based on Shipping Conditions e.g. "Road FTL", where the full delivery will be loaded into one truck, instead of Freight Unit creation the system can create one Road Freight Order directly.
  • In case from Freight Unit or Container Unit, Freight Orders and Freight Bookings can automatically be created there are ways to automate this process.
  • For consolidation planning it can be investigated if optimiser planning can be utilised to automate this process.


Decisions to be taken during detail design

  • (Pre-)carrier selection could also be done in SAP TM.
  • How and where automation and shortcuts need to be applied.
  • Solution on making sure that Road Freight Order dates are aligned with the Ocean Freight Booking.

Assumptions for integrating with BluJay

  • Consolidation planning will be done in SAP TM (instead of BluJay). Considering the process it easier to execute in SAP.
  • Tendering of TMS Orders will be handled in BluJay.
  • With BluJay, SAP Business Network for Logistics will be out of scope for North America.
  • Standard SAP interfaces can be used to cater for TMS Order integration. When there are gaps in the existing interface these will be enhanced.
  • With the use of interface mapping software (like SAP PI) existing BluJay interfaces can be re-used.



General Assumptions

Deadline for retirement old BluJay version
The deadline for this transition is set at beginning of 2026. As this transition has been postponed multiple times it is no longer possible to extend beyond that.

Transition to new BluJay version is relatively easy
As current BluJay version and new BluJay version are both products of e2open, it is to be expected that there will be support in the replacement. Also, the carriers that are linked to the old platform are assumed to be linked to the new platform. There is no question about changes to be made by carriers to support another platform. These benefits should make the transition to the new platform relatively easy.


Impacts

  • Replacement of current or new BluJay version will impact the scope significantly for ERP Rebuild project. Transportation processes are complicated and are often underestimated in effort required.
  • When replacing BluJay with SAP TM, carriers that Syensqo does business with have to support SAP Business Network for Logistics.
  • When replacing BluJay with SAP TM after BluJay has transitioned to new version, users have to adapt again to a new solution.


Business Rules

  • When replacing BluJay with SAP TM, carriers that Syensqo does business with have to support SAP Business Network for Logistics.


Evaluation

Moving forward there are a few paths that could be considered.

Option A) Continue to use BluJay with updated new version. SAP TM to be integrated with BluJay.

Option B) After ERP Rebuild project has finished and the new situation has stabilised, SAP TM is made ready to replace BluJay and BluJay is phased out.

Option C) BluJay is updated and when ERP Rebuild is being deployed BluJay will be replaced.

Option D) To replace old BluJay build a stand alone SAP TM system with integration to WP1 and PF1. Migrate this system to S/4 Hana as part of ERP Rebuild.


Without considering the risks, it might be very attractive to replace BluJay as soon as possible (option C or option D). One solution for entire Syensqo. Functionality developed for one region can be re-used in other regions. Costs are saved on licenses. There is only one system to maintain.

However, for risk management the following facts should not be ignored:

  • There is not a full understanding if SAP TM system has any significant gaps.
  • Replacing BluJay will have a significant impact on ERP Rebuild scope.
  • For each new system there is a risk that deployment is not successful. When replacing BluJay and the functionality turn out to be insufficient then it would impact ERP Rebuild as a whole.
  • As the ERP Rebuild project is challenging as it is, it might be welcome to avoid on-loading extra challenges onto the project.

For these reasons it would be advised as part of ERP Rebuild project to integrate with BluJay instead of replacing it. Syensqo can then later decide, with more knowledge and confidence, that it will replace BluJay, or that it stays within the landscape permanently.



Option A: Integrate with BluJay

Option B: Integrate with BluJay and replace BluJay later
Option C: Replace BluJay at go live ERP Rebuild
Option D: Set up Stand Alone SAP TM and replace with ERP Rebuild

Costs

(minus) Having two systems within Syensqo that have similar functionality might not be ideal.

(plus) Building the interfaces to BluJay will be less effort and cheaper than building required functionalities.

(minus) Building an interface with a system that will later be replaced can be viewed as waste of effort.

(minus) BluJay could be replaced before there is a return on investment.

(plus) Functionality build for one region can be re-used in another.

 

(minus) North America requirements have a significant impact on ERP Rebuild scope.

(plus) Syensqo doesn't end up with two systems that have similar functionality.

(plus) Functionality build for one region can be re-used in another.

(minus)  Setting up Stand Alone SAP TM will be a project on its own.

(plus) Syensqo doesn't end up with two systems that have similar functionality.

(plus) Functionality build can be re-used in ERP Rebuild project.

Knowledge

(plus) Users are well know with current version of BluJay and know what to expect from new version.


(plus) When there is sufficient knowledge and maturity on solution, Syensqo can make a replacement decision based on experience and knowledge of both solutions.

(minus) For business representatives there is limited knowledge of SAP TM to have an understanding where there are gaps in the solution.

(minus) For business representatives there is limited knowledge of SAP TM to have an understanding where there are gaps in the solution.

(plus) Experience can be build in stand alone TM which can be re-used in ERP Rebuild.

Network

(plus) Carriers are familiar with BluJay and will be easy to transition to new version.

(plus) Carriers are familiar with BluJay and will be easy to transition to new version.

(plus) Carriers can transition slowly to SAP BNL.

(plus) Syensqo can build up experience in this transition and do this in phases.

(minus) Carriers will be asked twice to change platform.

(minus) For some carriers integration with BNL might be new.

(plus) Carriers will only be asked once to change platform.

(minus) For some carriers integration with BNL might be new.

(plus) Carriers only be asked once to change platform.

(minus) For some carriers integration with BNL might be new.

Risks

(plus) New version of BluJay is a separate project and will have limited impact on ERP Rebuild project.

(plus) Business representatives and users are familiar with BluJay, having a positive impact on a successful implementation.

(plus) With the knowledge gained Syensqo can make an informed decision on what the most optimum system landscape is, without risking operations.

(minus) For TM, North America requirements are expected to be most challenging. Including BluJay replacement will have a significant impact on the scope. This should be taken into account for development, testing an deployment.

(minus) If there are unforeseen gaps in the solution then this could impact operations.

(minus) Deadline for go-live is very tight to implement stand alone SAP TM. When rushed and solution is sufficiently developed and tested, it could disrupt operations.



Change log

Version Published Changed By Comment
CURRENT (v. 23) May 15, 2025 11:15 VAN OS-ext, Nico
v. 26 Oct 08, 2024 15:44 VAN OS-ext, Nico
v. 25 Oct 08, 2024 12:43 VAN OS-ext, Nico
v. 24 Oct 08, 2024 12:40 VAN OS-ext, Nico
v. 23 Sept 27, 2024 10:30 NID BOUFKER, Naijate
v. 22 Sept 18, 2024 15:21 VAN OS-ext, Nico
v. 21 Sept 09, 2024 08:32 WENNINGER-ext, Sascha
v. 20 Sept 05, 2024 15:21 NARAHARI-ext, Bhargavi
v. 19 Sept 05, 2024 12:22 VAN OS-ext, Nico
v. 18 Sept 05, 2024 12:19 VAN OS-ext, Nico

Go to Page History



Workflow history

Title Last Updated By Updated Status  
There are no pages at the moment.

  • No labels