1. EXECUTIVE SUMMARY

The widespread Indian road network contributes to majority of the logistics within country. With this high capability, the road transportation is highly inefficient attributed to lack of technology and poor information flow along the system. This paper deals with how DHL eCommerce India started the DHL SmarTrucking business unit in India to disrupt the $300 billion industry using technology as a base to provide Full Truck Load(FTL) logistics solution pan-India. DHL would own the assets and provide trucking services to multiple industries using their unique operating model of driver relay methodology. The solution involves implementing SAP Transportation Management(SAP TM) as a core to perform majority of the operation, that is also capable of integrating with different external system(telematics, data analytics etc.)

2. ROAD TRANSPORTATION IN INDIA
Indian road network is the second largest road network in the world with 5.5 mn km in length. This widespread road network makes it critical for the Indian logistics transportation network. Around 60% of the transportation is carried out by road in India, significantly higher than the global average of 30-40%. The dominance of road transportation, although is costlier, will likely sustain and grow due to the expanding road infrastructure.
The road logistics in India, however, has remained largely unorganized with 90% of the industry comprising of transporters with fleets of under six vehicles. There has been a significant lag in adopting technology with a huge reliance on phone calls, paperwork and manual process. Majority of the companies don’t even use a Enterprise Resource Planning(ERP) system.
The labour intense Indian logistics industry, with nearly a quarter of jobs linked to logistics, has the road logistics occupying the major share. However, the industry usually consists of a network of small operators and middlemen which has a detrimental effect on the free exchange of information. Driver of truck is perceived as one of the worst jobs in the country with minimal wages, highly risky, no respect in the society. This in turn reduces the wellbeing of the driver’s community and directly impact the driver’s efficiency.

3. DHL ECOMMERCE
DHL eCommerce, a part of Deutsche Post DHL Group (the world’s leading mail and logistics company is the leading global brand in the logistics industry) offers a range of cross border shipping services covering more than 220 countries and territories around the globe along with Domestic Delivery service in a unique and reliable way to deliver goods to customers with end-to-end holistic delivery and logistics service.

4. DHL SMARTRUCKING
DHL eCommerce identified the challenges in the Indian road transportation logistics industry and wanted to disrupt the the $300-billion goods transportation segment in India using technology.
DHL eCommerce setup the business unit DHL SmarTrucking in order to provide standard and temperature controlled trucking services pan India using it’s own trucks. DHL eCommerce would enhance the service by reducing the transit time, tracking the goods carrying trucks and thereby improving the livelihood of truck drivers. From buying the first 100 trucks, DHL SmarTrucking had aimed to grow to 10,000 trucks in 10 years.

5. IMPLEMENTATION OBJECTIVE
DHL SmarTrucking wanted to implement SAP Transportation Management application to achieve the following
• The solution to support DHL’s operating model (driver relay with intermediate hubs across India)
• Seamless working of all their business process
• Integrate multiple teams across different geographic location to have proper process flow
• SAP TM to carry out majority of the operation activities with little reliance on ECC system
• SAP TM to support various data analytics initiatives
• SAP TM to integrate with external system to provide digital solution (mobile/web application)
• Telematics services to be integrated with SAP TM for tracking the status of trucks/trips
• Route optimization to be carried out using SAP TM, integrated with external system

6. DHL SMARTRUCKING OPERATING MODEL
• Standard and temperature-controlled trucking services
• Trucking service all over India
• The fleet with mix of single and multi-axle trucks with 24 and 32 feet long trucks
• Only Full Truck Load (FTL)
• Driver relay model along with intermediate hubs – to boost morale of driver drivers and reduce the transit time
• Long term contracts with large customers along with fixed schedule and ad hoc orders for spot market
• End-to-end tracking of trucks with real time visibility.
• Value added services to customers
• Various industries served

7. SAP TRANSPORT MANAGEMENT
SAP TM is a standalone Application from SAP AG. The application caters to the Transportation Management Software market. SAP TM Solution was designed for transportation and logistics requirement of all industries and to reduce transportation costs and improve logistics efficiency and flexibility. It enhances the architecture of SAP’s existing transportation solution for manufacturers. SAP TM enables to manage all inbound and outbound domestic and international freight in the same environment and provides traceability and visibility of orders, shipments, items, and logistics processes. With SAP TM, it is possible to plan the transportation of shipments for many common order types such as sales and purchase orders, returns, and stock transfers.
DHL used SAP TM version for its DHL SmarTrucking business unit

8. SOLUTION
The SAP TM solution provided to DHL SmarTrucking involves process improvement across the following business tracks

8.1. CONTRACT MANAGEMENT
DHL SmarTrucking’s customers can be classified into two based on the maintenance of contracts. For enterprise customers that maintains a long-term relationship with DHL, a contract is created between both parties. For ad-hoc based customers a Service Product Catalog is maintained. The various parts of the solution to contract management are given below

8.1.1. FORWARDING AGREEMENT
An agreement/contract is maintained as a Forwarding Agreement (FWA) in the SAP TM system. It consists of various items like validity of the contract, the rates for different routes that are decided upon for the given customer, customer details etc. When an order is created, the information from the FWA are fetched. Details like sales organization and ordering party are used in invoicing the customer

8.1.2. CALCULATION SHEET
List of charges like base charge, fuel surcharge, green tax, delay and detention charges are maintained for each customer in calculation sheet. Expanding charge line gives additional details like validity of that charge line, resolution base, etc. The charges maintained using the below ways.
• Fixed amount – Charges for activities like loading, unloading etc. are assigned a fixed price and stored in the contract
• Rate table – By using rate tables, different charges are maintained for different routes, trucks etc. Scales are used to determine the basic freight charge of a given trip or to determine the rate line in the rate table.
• Conditions – The charges can also be calculated based on conditions. These conditions were used for calculating charges like fuel surcharge, detention etc.

8.1.3. TOUCHPOINT
In order to address the relay operating model, Touchpoints were introduced in Forwarding Agreement. It allows the user to include an intermediate city for a trip.

8.1.4. SERVICE PRODUCT CATALOG
The service product catalog is used for ad-hoc orders for which a contract (forwarding order) is not maintained. The scales for the rate table are only source city, destination city, trip type and truck type. It also contains an upper and lower possible limit for fixing the base freight cost, called as target and floor price.

8.2. ORDER MANAGEMENT
Order Management involves with the creation of sales orders in the TM system called ‘Forwarding Orders’, which form the root for a trip execution. The customer data for whom an order is created, is maintained in ECC system. The FWO contains information about the customer involved, source and destination locations, date and time of the trip requested, products transported in the truck, the type of truck used, charges levied on the customer for the trip, and multiple touch points (interim stops). There are different types of orders, based on the type of contract
• Contract order: In contract orders, the forwarding agreement needs to be maintained and the charges for the trip are picked from the FWA. The source, destination along with TAT (turnaround time) is fetched from the contract.
• Scheduled order: The scheduled order also contains a forwarding agreement like contract order. However, a schedule is created along with the contract, that creates orders based on schedule.
• Ad-hoc order: An order for a customer, who has not maintained an agreement.
• Leased order: The truck is hired for a given period irrelevant of the customer locations. Like truck rental than a door to door delivery. Odometer of the truck is used to charge the customer.

8.2.1. CREDIT LIMIT CHECK
Every time the forwarding order is saved, the order goes to Credit Limit Check. The total charges in the FWO is sent to ECC system, where the Credit Segment Data is maintained per customer in the transaction “BP”, under the role Credit Management. If the total cost of all orders for that customer crosses this limit, then the FWO goes into block due to Credit Limit check.
In order to achieve credit limit check, Master Data Synchronization (MDS) to create Business Partner in ECC was enabled. To achieve MDS configuration to copy Customer to BP in ECC was enabled

8.3. PLANNING
The optimizer functionality of SAP TM was configured to follow a 2-step optimization process where, the optimizer plans the Freight Unit considering the various incompatibilities and then the Scheduling is done to accommodate the various Touch points and Smart Hubs in the prescribed Route and the TAT.
• The stages, as per the default route are passed in the post optimization.
• In Planning cost settings, the non-delivery cost of the FU is being considered to prioritize the FU based on certain business rules
• FO Building Rule creates a new Freight Order when the Resource is empty

8.3.1. CREATION OF SINGLE FREIGHT ORDER FOR RESPECTIVE FORWARDING ORDER (FWO)
A Forwarding order has multiple stages, but a single freight order has to be created for optimization. This activity was carried out in three stages
• Pre-Optimization: Before passing the FU through the Optimizer, the code fetches only the first and last location of the complete Order and stores the rest in memory for later use. This temporary Order has only one stage.
• Optimization: The Optimizer plans the Order considering only a single stage and creates only one Freight Order. All incompatibilities are considered.
• Post-Optimization: Now the newly created Freight Order is filled with the required details stored in the memory while pre-optimization and the required stages are created using the stop sequences. The ZVSR_ROUTE process is repeated once again to fetch the required routes and retrigger scheduling.

8.3.2. DRY RUN MINIMIZATION
dry run of each vehicle had to be limited 150 km (a parametric value) to reduce cost. Since there was no provision in the Standard System to implement this, a custom development had to be implemented.
• The First Location of the Freight Unit is considered in the process.
• The Last Location of the Vehicle Resource is then checked.
• The distance between both the Locations is determined and then passed to the Optimizer which the eliminates any value above 150 km.

8.3.3. INCOMPATIBILITY MAPPING FOR OPTIMIZER
Certain trucks had to be allocated for specific routes such that the trucks, at any point, is distributed across the country and is available to cater to different orders. Some customers would always also prefer a certain vehicle allocated to their orders whenever it is available. To map these incompatibilities vehicle resources and incompatibility definitions were used.
• The Vehicle Resources required to be planned are stored as a variable.
• A custom table consists of the Start/End Transportation Zone alongside each Vehicle.
• The Start Location and End Location of the FU(s) are determined, and respective Start/End Transportation Zones are fetched.
• The optimizer uses the Incompatibility Definition to validate the Start/ End Transportation Zone of the Freight Unit with the Table maintained and returns the appropriate result.

8.4. FLEET MANAGEMENT
DHL SmarTrucking operation is carried out using trucks owned by DHL. The assets owned by DHL includes standard as well as temperature-controlled trucks. As the assets are owned by DHL, the responsibility of maintenance of the trucks is with DHL only. The sub-equipment of a truck needs to be monitored and serviced as well. This process is carried out using the sub-equipment screen that is used to attach sub-equipment to vehicle with position number along with proper validation.

8.4.1. CREATION OF SUB-EQUIPMENT
Custom screens were built to add new input fields like document numbers and their expiry dates respectively for Insurance, goods permit, national permit, fitness certificate, pollution certificate, road tax certificates for main equipment and sub-equipment.
8.4.2. PREVENTIVE MAINTENANCE
A schedule is maintained, common across a vehicle model and that is across the vehicle mater. This reduces the time for creating maintenance plan for each individual vehicle. The maintenance plan requires bilateral mapping i.e.; it has to be maintained across the vehicle and also inside the maintenance plan respectively
• Maintenance order creation: Automatic scheduling checkbox is made mandatory so that the scheduled start and end date are auto populated based on the basic start and end date entered by the user respectively. Auto release option is made possible as soon as the order is saved so that truck is blocked in TM for this scheduled time. Approval workflow option is also given to see who has approved the order. Capturing of costs is made mandatory in NAMC type orders.
• Empty trip creation: In order to plan the movement of truck to OEM locations an empty trip is created in TM to complete the maintenance tasks which has been scheduled in ECC. In case of delays/aberrations it must be updated in the maintenance order so that the vehicle downtime gets updated as blocked for planning.
• OEM location details: The OEM vendor list is provided in the maintenance order partner section so that the user just can select the vendor to which the truck had to go for maintenance.
• Schedule maintenance notification for fleet team: The fleet team needs to be periodically updated on the upcoming
o The list of vehicle and latest date of notification for scheduled maintenance must be push from standard ALV IW28 report. In “STVARV” parametric table needs to maintain group email details of fleet team on which mail will trigger.
o As per standard report (IW28) information pulled from ECC to TM system (Vehicle is planned for scheduled maintenance with description & date). These are mandatory fields: Vehicle, Notification date, Description of notification, “in execution” FOs details, source location, destination location, ETA Date/time.
o ECC- Notification Table Names: VIQMEL, Fields Names: QMNUM, EQUNR, QMTXT & AUSVN from which schedule related information getting pulled.
o A back job was set to trigger the email to fleet team on daily basis.
• Vehicle breakdown notification to fleet team: When a truck breaks down, the fleet team needs to be notified on this so that a maintenance order is created for the truck
o PPF is triggered after cancelation of Trip due to Vehicle breakdown reason code and this reason code is mandatory field.
o To trigger this email to Fleet Team, a group email ID is maintained in “STVARV” parametric table.

8.4.3. ECC-TM INTEGRATION

Maintenance Notification A custom report is used to create a Maintenance notification transaction document, this document is transferred to TM using a custom function module

Maintenance Order Based on Maintenance Notification, maintenance order will be generated in ECC. A custom report is used for maintenance order generation and this detail is transferred to TM using FM.
Odometer Validation A custom table is created to maintain latest odometer/Reefer reading in ECC.
Job Order Print A custom report is created to fill the details in a custom form ZTM_JOB_ORDER_FORM.

8.5. EXECUTION
The trip once planned and ready, the execution modules performs tasks like assigning driver and performing all the process for the truck to complete the assigned trip. The execution cockpit is the screen that users will use to see the trips in the zone that the user is assigned to. The logic behind making only relevant trips visible to respective intermediate hub lies in the concept of Responsible Hub. Every pin code in the country has been mapped to corresponding Transportation Zones and every Transportation Zone is mapped to corresponding Transshipment Locations or intermediate hubs. Every location in India has a corresponding responsible hub assigned to it. If a Freight Order has a touchpoint as any location, then that Freight Order will be visible in the transportation cockpit of the responsible hub of that location. The transportation cockpit contains the following buckets
• Out trips (Not Started, Ready for Execution, In Execution)
• In Trips (Ending trips, Not started)
• In transit trips (Incoming and Not Started)
• Cancelled/Completed trips
• Transferred trips (Trips for which the responsibilities have been transferred to another intermediate location).

8.5.1. PROCESS FLOW

8.5.2. DRIVER ASSIGNMENT IN COCKPIT
DHL’s operating model involves assigning two drivers per stage of the trip. According to standard SAP functionality, drivers for all stages need to be assigned prior to the commencement of the trip. However, due to the fast-paced business model and the need for flexibility, drivers may be required to be assigned to later stages after the trip has already started. In order to handle this scenario a custom development is done to assign two dummy drivers to each stage in the backend at the time of creation of the freight order, and later when the user assigns real drivers to the stages, then the dummy drivers are to be replaced by these drivers. In case the stage is to be assigned only one driver, the user has the option to check a box ‘No master defined’ and mention any name in driver description.
The expenses can be generated only after driver assignment has been done and once the expense sheets have been generated, the drivers cannot be changed. In most cases, same expenses are to be generated for multiple stages if the same drivers are continuing for those stages

8.5.3. EXPENSE DOCUMENT CREATION
These are generated to capture the expenses at a stage level. A custom button at the stage level in the cockpit generates expense documents in pairs for the selected stages.
• Outbound expense sheet: the amount of money given to driver and other trip related expenses made are captured
• Inbound expense sheet: reconciliation of the amount paid in outbound expense sheet is performed. The pair of expense sheets are linked and cancelling the outbound expense sheet will automatically cancel the inbound expense sheet as well.

8.5.4. INSPECTION CHECKLIST
To provide a comprehensive state of the vehicle to be deployed on the trip, an inspection checklist is a prerequisite step that needs to be completed before the trip begins execution. The details that are captured include cabin, chassis, container, accessories, vehicle documents, reefer units (in case of TCL vehicles) among others. The inspection checklist also contains details related to drivers along with documents related to any repairs, receipts, vehicle documents, etc. at the bottom. The attachment types are configured accordingly

8.5.5. READY FOR EXECUTION CHECKLIST
To ensures that before a trip begins execution, all necessary activities which include driver assignment, expense generation and inspection checklist have been duly completed. If any of these is pending, the Ready for Execution checklist will not be allowed to be saved. And without the Ready for Execution checklist completed, system will throw an error if ‘Ready for Transportation Execution’ is clicked.

8.5.6. TRIP SHEET
The trip sheet is a document given to the driver at the beginning of his trip. It contains the details about the order, vehicle, customer, drivers and the advance given to them, customer pickup and drop location addresses, details of all the touchpoints in the trip, the services requested by the customer as well as those added by the intermediate hubs.
Two buttons are provided at stage level
• Preview Trip sheet, which opens a PDF in the browser
• Print Trip sheet, which creates a copy of the trip sheet in the spool

8.5.7. LR AND SERVICES
To capture the Lorry Receipt details along with the Services a new custom tab was added in the freight order. It contains information about the indent and vehicle. The user needs to enter the E-way bill details and has the option to select whether the same is applicable or not depending on whether the products been transferred have a total value of greater than Rs. 50,000 or not. The E-way bill details are mandatory in case Yes is checked for E-way bill applicable. The Lorry Receipts table captures the different LRs that are applicable for the indent and the details such as their source/destination locations, which are mandatory, goods value, volume, weight, quantity, etc. The user is required to enter at least one Product and one Invoice against each LR whose entry is made. The Services section was developed to displays all the Services ordered by the customer. All the services whose information flows here from the indent are noneditable and cannot be deleted. Apart from these, the user can also enter new services here depending on requirement, but these unlike those from the indent can be edited and deleted as and when required.

8.5.8. PROOF OF DELIVERY
The POD is a document that is required to complete the trip. The document must be manually sent to the HQ to continue with the invoicing activity.
• POD cockpit was developed for the POD team at HQ and the Finance team to perform different activities using POD documents
o The POD HQ team: The team can view those freight orders whose current POD status is either Sent to HQ or Received at HQ. The only action available for them is Received at HQ
o The Finance team can view those freight orders whose current POD status is Received at HQ or Verified.

8.6. INVOICING

8.6.1. PROCESS FLOW

Once the trip for a given Forwarding Order is executed, the invoicing process begins. A Forwarding Settlement Document (FWSD) is created for one or many FWOs. An FWSD is a document that is sent to SAP ERP to request the creation of an invoice to be sent to a customer. It consists of the total charges pertaining to the FWOs along with details about the two parties involved in the invoice, the sales org. of DHL and the Bill-to-Party, which is basically the customer. The charges from each of the FWOs for the customer, selected to create FWSD are totaled and added for invoicing.
The settlement profile consists of certain conditions and settings which govern how the calculation of charges is done for the FWSD. Once the FWSD is created and saved, the invoice can then be previewed by clicking the Preview Invoice button. A PDF is then downloaded
Communication between ECC and TM system in this process happens through PI
• Inbound Interface in ECC:
CustomerFreightInvoiceRequestSUITERequest_In_V1
CustomerFreightInvoiceRequestSUITECancellationRequest_In_V1
• Outbound Interface from ECC:
CustomerFreightInvoiceRequestSUITEConfirmation_Out_V1
A BADI (Business Add-In) has been used for certain validations like whether the material is taxable or not, sales office, material type (dry or TCL) etc.
Based on the Invoice created in ECC, PDF form will be generated in ECC against the Billing document and this PDF document is transferred to TM Forwarding settlement with all the annexures. Communication between both the systems happens through Custom Function Module.

8.6.2. MAINTENANCE ORDER INVOICE POSTING
Posting the invoice document for expenses related to maintenance order for fleets. Finance related G/L accounts are updated accordingly. This process is performed using standard transaction code.

8.7. MANAGEMENT INFORMATION SYSTEM
The MIS provides complete details about the given document type, with the option to export an MS Excel report from the same. There are different types of MIS.

8.7.1. ORDER MIS
The order MIS consists of all the list of orders that are queried based on different parameters like
• Type of order
• Credit check status
• Order block
• Successful charge calculation
• Planned orders
• Indent register

8.7.2. TRIP MIS
It contains the list of all trips. Like Order MIS it contains queries based on different parameters
• Type of trips
• Type of trucks
• Intermediate hub report
• Execution report
• POD status

9. CONCLUSION
The Full Truck Load (FTL) transportation solution implementation for DHL eCommerce was analyzed completely on different business processes were streamlined to use technology and achieve seamless flow of information. With the technological solution along with the operation model DHL SmarTrucking was able to achieve 95% on-time delivery and 50% reduction in the in-transit time.

By Stephen Bright – Process Consultant