View source for SDD-442106-Project Bumblebee Logistics TS3 Solution OVERVIEW

<div class="noprint">
{{#vardefine:Client|STS}}
{{#vardefine:ClientName|Stapletons Tyre Services}}
{{#vardefine:System|Solution Design Overview}}
{{#vardefine:SystemCode|CTMS}}
{{#vardefine:Doc_Title|Project Bumblebee Logistics TS3 Solution OVERVIEW}}
{{#vardefine:Version|4.00}}
{{#vardefine:Date|16/10/2024}}
{{#vardefine:Reference|442106}}
{{#vardefine:Year|2024}}
</div>
{{Doc_Title
|Client={{#var:ClientName}}
|System={{#var:System}}
|Title={{#var:Doc_Title}}
|Reference=REQ {{#var:Reference}}
|Version={{#var:Version}}
|Date={{#var:Date}}
|Year={{#var:Year}}
}} 

<!-- TOC --> 
=Introduction=

The following is a summary of the expected TS3 processes once the work specified in the solution design is completed. This is companion document to the full solution design document version 3.7, as referenced in the appendices.


== Configuration ==

=== Access Control ===
The operation will configure users, groups and parameters to control the access and functionality of CTMS:

* Groups and access control, controlling which functions each group of users has access to.
* Users and parameters, controlling the users configured, their passwords, which group they belong to (and therefore which functions they have access to in the system), plus their defaults, such as:
** Depots they have access to (or all depots).
** Customers they have access to (or all customers).
** Carriers they have access to (or all carriers).
* System parameters, controlling the base functionality. This will be pre-configured by the Aptean implementation team.


=== Resources ===
For most standing data for the operation, this data can be uploaded through configurable CSV imports and then maintained within specific screens within CTMS.


Note that there will be no automatic import of vehicle availability from FleetCheck into Aptean systems.


The following resources will be configured within CTMS:

* Carriers - all the carriers in use by all the depots. This includes definition of whether they are 3rd party of home fleet, and whether the carrier will use FleXipod for execution of the trips. This can also include working hours directives.
* Carrier rate cards - as an optional configuration, carrier rate cards can be configured to calculate the trip cost per trip completed. This information would then be available for reporting and BI export.
* Vehicle Types, including capacity of the vehicles (for calculation of vehicle fill rates on delivery trips, not used when building trips)
* Vehicles - all the vehicles in use by the home fleet carriers for the depots. This can also include VOR information and resource availability information, to improve decision assistance when allocating resources to trips.
* Drivers - all the drivers in use by the home fleet carriers for the depots. This can also include shift creation/assignment and resource availability information, to improve decision assistance when allocating resources to trips. The drivers can also be assigned the vehicle types that they can use.
* Carrier Assignment - the assignment of vehicles and drivers to depot home fleets.
* DU Types - all collectables/deliverables, such as:
** M – Miscellaneous
** THOTEL – Tyre Hotel Tyres
** T – Tyres
** C – Consumables.
** The following are legacy types but are retained in the solution in case they are needed:
*** P – Parts
*** B – Batteries
* Delivery Types - the different types of collections and deliveries, and an indicator of whether orders of these types should attempt to automatically plan or not.


T and THOTEL DU types will be configured with an RPE (regular pallet equivalent) value of 1, whilst all other DU types will be configured with a value of 0, so that the system can easily display the number of tyres on each order in may screens, as well as calculate the vehicle fill rate depending on the numbers of tyres on orders on trips, versus the capacity of the vehicle.


=== Customers ===
Customers will be loaded through a customer onboarding interface, from CRM information through MuleSoft directly into CTMS. This will include:

* Customer, including the account type (CASH etc), a flag to determine if Casings can be collected, external reference for interface purposes, SIC code and Unitary Authority (for EWT document production in FleXipod).
* Customer Locations, including an external reference for interface purposes.


=== Locations ===
Customer locations will be created through the customer onboarding interface. Several other locations will also be maintained:

* Location Types
** RDC - Depot locations.
** BRANCH - Delivery locations.
** BILLING – Customer Head Office locations.
** CROSSDOCK - 3rd party cross-dock locations for 3PC processing.
* Load/Unload rates, including fixed times and per-DU times for loading and unloading. These rates can be changed against the location in CTMS after the location is created. The default will be 4 fixed minutes per location and 0.25 minutes per tyre.


The delivery locations may be configured with instructions that will be passed to the FleXipod device for the driver to see.


The Depot (RDC) locations will include Permit Number (for EWT document production in FleXipod) – this will be held and maintained in CTMS alone.


=== Countries and Non-working Days ===
Countries will be set up with non-working days, allowing for:

* Setting a non-working day for a country
* Setting a non-working day for specific depots instead of/as well as the country.
* Setting a non-working day for specific routes in a depot.
* Overriding the above non-working days with route effective days.


Specific bank holiday runs will be set up for holiday and with effective dates against them. This will be achieved through CSV upload of routes for this purpose.


=== Strategic Planning ===
Strategic planning will be completed within Paragon. The application will be used to sequence permanent customer locations onto runs with STS drop numbers.


The locations within Paragon will be manually maintained by the operation, not sent from CTMS to Paragon.


The strategic planning information will be stored within CTMS, imported from Paragon strategic planning. This includes

* Runs - fixed delivery routes with owning depot, start and end times, cut-off times, vehicle type (for fill rates), carrier (home fleet or 3PL).
* Drops - customer locations will store the run numbers on which a location can be delivered/collected, along with the STS drop number.


Routes will be created for:

* Radial Collection/Delivery runs operated by home fleet.
* 3PC collection/delivery runs.
* Desk Collection runs.


Users will be able to view, report on and change the route end times through CTMS.


Tactical planning uses the runs and drops above, plus the resources configured above to create trips on a particular scheduled day.


== Orders ==
Orders will be created in TyreMan and passed to CTMS through the CTMS Trip Order API interface. Transport orders may also be created manually within CTMS.


Deliveries will be received through the interface. Collections are not expected to be received through the interface in TS3. 

In the instance where a collection order is received through the interface, as long as that order has a run number and all expected information (see below) it will be successfully created and planned. If it does not have the correct information or a run number, it will be set as a status INVALID, which can be easily identified and filtered in the system.


The orders will include (not limited to) the following:

* Order Reference - an order reference common to TyreMan and MuleSoft.
* Customer.
* Location From.
* Location To.
* Additional References, such as TyreMan order, delivery point reference, etc.
* Delivery Type - There are many types of orders, defined by the delivery type.
* Run Number - the run number on which to plan the order.
* Deliverable/collectable products - the DU Type, product type, product code and description, quantity, total weight, line price and a unique item reference.
* Total price per order.
* Email address for tracking email.


The interface process will use the provided run number and the run configuration to calculate the order collection and delivery windows, based on the cut-off and run end times against the run. Note: If no run number is provided on an order through the interface, the order will be invalid.


Transport orders may be manually created, for the following purposes:

* Ad hoc tyre collections.
* Cheque collections.



== Planning ==
CTMS will plan orders in the following ways:

* Automatic
* Manual trip creation/manipulation.


Paragon tactical (on the day) planning will no longer be in use.


=== Automatic Planning ===
An automated scheduling engine will run to plan any non-INVALID order onto a trip. The process will:

* Plan orders (collections and deliveries) onto trips generated from the fixed run as specified against the order from TyreMan.
* The process will create
** DSK for desk collections
** RTE for radial delivery/collection runs operated by own fleet.
** 3PL for deliveries operated by 3rd party carriers.
* If an order is specified to be placed on a run, but that location does not have a drop number on that run in CTMS, the order will be planned last on the trip and marked with a high STS drop number (e.g. 998).
* If no run number is provided on an order, the order will not automatically plan.
* If an order cannot automatically plan onto the run provided (perhaps due to being planned onto a trip that has passed cut-off), the process will attempt to carry forward to the next available run for that location on that day.


=== Day End Processing ===
A Depot Sweep process (part of the scheduling engine) will run at several times during the day, in order to carry forward any unplanned orders to the next day's schedule

* At the end of day, any unscheduled orders will be carried forwards to the next working day's schedule. The order collection and delivery window will not be modified, in order to preserve OT/IF reporting requirements.
* Any DSK (Desk Collections) orders that have not been completed (debriefed) at end of day to carry forward to next day and planned automatically onto the next DSK collection trip.
* Reset any TotD orders and next day orders that remain unscheduled.


=== Waterfall Screen ===
The Waterfall screen in CTMS will be used to view the trips CTMS is building throughout the day prior to cut off time, with a view to identifying potential exceptions.


The operation identifies trips and orders requiring exception management in the following ways:

* Number of Drops – identifying trips that are too long.
* Number of Tyres – identifying vehicle busts.
* Trip End time – identifying trips that are too long and will not return to the depot in time.


The following fields are available in the screen to aid this identification:

* Count of Tyres delivered/collected,
* count of items,
* count of casings,
* Count of Tmps,
* Count of Drops,
* total weight and
* total volume (RPE)


The users can also use the following functionality in the Waterfall screen:

* Facility to see details through planning screen (drill-down from the waterfall screen into the planning screen showing the selected trip).
* Facility to run extracts directly from the Waterfall to see details of the selected trips.


=== Trip Manipulation ===
The planning screen will be used to manipulate trips when exceptions are identified.

* Manual Planning/Override - see the following paragraphs.
* % Fill - the vehicle fill percentage on departure.
* The trip list icon will identify any trips with warnings and the warnings can be seen on the tabs on the screen.
* Facility to see STS Drop Number (the planned drop number from strategic planning) and CTMS Stop Number (the sequence in which the orders are planned to be completed).
* See all orders that are unscheduled in the unscheduled order well, pre-filtered to the user's parameters (like planning region and depot) plus extensive filtering options.


From the planning screen, the users will be able to take manual planning/over-ride actions as follows:

* Splitting orders from a trip.
** Unschedule Order - drops to the unscheduled order well and will not be automatically re-scheduled.
** Transfer Order and select a trip to transfer to. The order will be added to the end of the selected trip if transferring. The Transfer lookup will include details of trips created and runs available to be moved onto with basic capacity, end time, last drop time and number of stops to aid in selecting a trip.
* Adding orders to a trip.
** Apply an unscheduled order from the well to an existing trip or create a new trip. Depending on the selected options, the order will be added to the trip.
* Merging Trips together.
* Moving an entire drop to another trip.
** Transfer Orders from the selected stop, select a trip to transfer to. The Transfer lookup will include details of trips created and runs available to be moved onto with basic capacity, end time, last drop time and number of stops to aid in selecting a trip.
* Adding a special trip.
** Create New Trip. When entered, add a route code and optional description e.g. GDSP01, “To Farnham” to help identifying trips for transferring orders if there are multiple specials. The screen will provide a lookup of existing run numbers that can be used, or manual entry.
* Adding unscheduled or partly scheduled orders to the trips.
** Any unplanned or partly planned orders for that depot and schedule will be visible within the order well at the bottom of the planning screen.
** The view is configurable to help identify orders.
** The order well has filter options in order to identify or find applicable orders. The order well will be automatically filtered to orders to be planned by the user’s configured depot and the current schedule, although this can be altered and many more criteria added.
* Changing the sequence of drops on a trip.
* Select a stop, and then use the up and down buttons to move the stop.
* Move to Schedule (Carry Forward orders manually)
** Planning screen – select single or multiple orders on the order well, right-click and select Move to Schedule. Then enter the schedule you want to carry the orders onto.
** The Depot Sweep will do this for you automatically at the end of day of the current schedule, but this option allows you to carry the orders forward manually, for example moving several days forward in one manoeuvre.
* Carry Forward - This shows a list of routes and trips for those routes on that day, plus some totals. The user selects one and the trip is created if not existing and adds the order. The existing Change Schedule option will also carry orders forward and try to automatically re-plan.
* Reset Auto-scheduling - a similar option for unscheduled orders in the order well, to force attempt automatic planning of any order that has failed planning once already.


Manual trip manipulation can occur before or after cut-off of the trips.


Manual trip manipulation can also occur after a trip has started. This can be used to add deliveries to a trip after it has departed (correcting short deliveries through driver error) or in the event of vehicle breakdown to change the driver/vehicle if required).


== Execution ==

=== Preparation for Execution ===
Resource Assignment can be completed from the Waterfall or Planning screens. Resource assignment can occur before cut-off of the trips.


If the shift and resource availability calendars have been created, then the screens can provide decision assistance as to which resources are available considering shifts, basic availability and booked holidays, showing the available resources, along with information on trips on which they are already planned. This will also consider which vehicle types the driver is configured to be able to use.


If the advanced capability is not required, then the drivers and vehicles can be selected from a list of available drivers and vehicles.


The available resources will be limited to those assigned to the selected carrier.


Once trips are resourced, they can be set to ACCEPTED status, which releases the trips out to FleXipod for execution - this can be also achieved through the Waterfall or Planning screens on multiple trips at the same time, so entire set of similar-departing trips can be released en mass.


Whenever an order is set to ACCEPTED status or the plan is changed after this point, messages will be sent to TyreMan

through MuleSoft to show the Trip Planned and the orders planned on it.



The sending of the trips to FleXipod will support:

* Sending the manifest with all orders and items planned on those orders.
* Sending of email and SMS details of contacts through to FleXipod, for Track My Driver notifications.
* Consolidation of orders (single job on FleXipod per location regardless of the number of orders being delivered/collected).
* Order collection and delivery products and quantities.
* Sequenced orders as per the plan, with planned times.
* Configuration of attributes to be passed to FleXipod per order, including but not limited to:
** Pay on delivery.
** Price (subject to SCR-CTMS-03557646-13, specified in section 3.2.1 above).
** Casing collections.
** Additional order/customer references.
** Total price.
* Configuration of attributes to be passed to FleXipod per deliverable line, including:
** Item ID
** Line description.
** Line price.
* Location and driver instructions.


Product picking and vehicle loading can be completed within TyreMan. When complete, a final despatch message will be sent to CTMS, detailing any shortages during this process.


=== Execution ===
The driver will inspect the vehicle using the FleetCheck application. Once complete, the driver can start the trip on their FleXipod application.


The application supports the following process:

* The driver will log into FleetCheck and log in.
* The driver checks the vehicle - the vehicle check undertaken will be dependent on the vehicle type, which is maintained in FleetCheck.
* The checks include service mileage, date and time.
* Checks are invoked on every fleet vehicle, including hire vehicles and HGVs.
* Any defects require the taking of photos to help identify the problem.
* Any defects are immediately highlighted within the FleetCheck console.
* Vehicles are marked as VOR until defects are resolved.
* Vehicles can be made VOR for maintenance.
* If defects are found, the vehicle will not be allowed to depart by the depot operational staff and the vehicle will have to be unloaded and reloaded.
* The last vehicle check is viewable within the FleetCheck application whilst the driver is out on the road, in case of a mobile inspection of the vehicle by the DVSA.


Note that a failure of a vehicle check will not prevent starting the route in FleXipod.


The FleXipod execution process includes the following:

* Accepting and starting the trip.
** An optional process at the start of the manifest can confirm whether the user has completed their vehicle defect checks cleanly in FleetCheck.
* Capturing start/arrival/completion times against each assigned job on the job list.
* Navigation using the locally configured mapping application such as Google Maps or Waze, including real-time road conditions.
* Ability to do jobs out of sequence (tracked).
* Capture collected/delivered products plus quantity and exceptions, with reason codes.
* Capture casings collected when the customer allows this.
* Capture cash collected where the customer requires this
* Ad hoc collection of tyres and cash.
* Capture customer signature and optionally capture photos of delivered/collected items.
* Capture of Route End information, including
** ODO reading
** Vehicle Fuelled/Fuel Card Usage in Litres
** Excess Tyres
** Driver/Customer Comments
** Total Break Taken
** Vehicle Washed
** AdBlue usage


Note: The FleXipod mobile device application does not allow viewing of EWT notes that may be generated as part of the POD Note/Completion Report.


As each job is actioned, the information is sent back to the FleXipod console and on to CTMS, which will automatically debrief the orders.


The transport team may also use FleXipod to send through messages directly to the driver in general, or against specific jobs, which are visible within the application.


Reason codes used for exceptions will be used by the operation to determine any follow-up actions, such as rebooking or re-entry of a new sales order for replacement items. This should handle the following exceptions:

* Failed Drop – the order may be rebooked in CTMS or a new SO may be raised, depending on the timing of the failed drop and availability of product in the warehouse.
* Customer Cancelled 
** Non-payment – this may either rebook for later/next day delivery, be cancelled and even have a new SO raised in the future, pending discussions with sales and the customer.
** Customer cancelled/Not required – no action required.
* Short Deliveries - a new SO will be raised.
* Short deliveries (driver error – product found on van) – the order may be rebooked in CTMS and reassigned to the driver for delivery.
* Over-deliveries - a manual collection transport job will be created in CTMS for the collection of the goods and TyreMan will intake the goods to correct stock levels.
* Excess tyres on van – no action.


Manual collections and rebooked orders will be created in the orders screen in CTMS and then scheduled (automatically by the scheduling engine and/or manually) as per normally received orders.


When an order is decided to be rebooked, the user can go directly to the order from the debrief screen in CTMS, where the order can be rebooked, changing any basic information such as the date, time, etc.


== Track and Trace ==
FleXipod contains Track My Driver functionality. This can be configured to send emails to end customer email addresses with an ETA and tracking links. 


The email address against the order will be set to CTMS as part of the order, and passed to FleXipod. When the trip is en route, if the orders (drops) have email addresses, these will be sent a tracking email, which is configurable. The format of this email is to be decided. Currently only a single tracking email at departure is required.



Tracking will be completed in the following ways for each operational area:

* Transport Operation – through FleXipod Admin Console and WEBFLEET.
* Customer Service Team/Sales Team – through Portal TTM or FleXipod Admin Console.
* End Customer – through customer service telephone.



As each job is actioned, the information is sent back to the FleXipod console. This information is visible to the operation, to aid in tracking the progress of the driver whilst completing the trip.


The device also regularly sends location updates to FleXipod, which it will use to update ETAs against the job


This information is also available to FleXipod Track My Driver, which then keeps the tracking link updated with the current information.


Track My Driver allows the following functionality:

* Advice of ETA/recalculated ETA.
* Job Status (e.g. in progress, completed).
* POD Download (when the job is completed).


The POD report is available from FleXipod through Track My Driver and through the FleXipod console. This includes:

* Cash and cheque payments,
* Ad-hoc cheque collections and casing collections.
* Collected/Delivered products and quantities.
* Signature
* Completion dates and times.
* Any photographs taken to support the payment process are also visible on the POD.
* Casings collected will drive the production of an EWT section of the POD report


WEBFLEET may also be used by the transport operation to track the location of the vehicle.


As each job is actioned, the information is sent back to the FleXipod console and on to CTMS, which will automatically debrief the orders. This will store the arrival and departure times, completed deliveries and quantity of items collected and delivered. The arrival and departure times can trigger execution events sent from CTMS through MuleSoft for arrival and departure times.


These events and debrief information are also passed on to the Calidus Portal TTM system, which provides a facility to see in-progress and completed transport deliveries, to help the operation see progress. A login to this system can also be provided to customers, customer service teams and sales teams. Customers can be limited to seeing just their own jobs, to aid in the customer self-servicing their own customer service requests.


== Debrief ==
As each job is actioned, the information is sent back to the FleXipod console and on to CTMS, which will automatically debrief the orders. This will store the arrival and departure times, completed deliveries and quantity of items collected and delivered, as well as any exception reason codes.


Debrief of the driver back in the depot will be run primarily from the information in the FleXipod admin console, using the Manifests view and sub-screens.


From the Manifests screen, the users will be able to filter by the driver, depot and date. The screen will display:

* Route – the manifest ID.
* Start Time/End Time
* Run (Attribute 1)
* Vehicle Type (Attribute 2)
* Drops
* Driver
* Status
* ETA Offset
* View button
* Map button

The user will be able to view any jobs completed out of sequence


From here, the user will be able to drill down and see any exceptions if more details are required:

* Drop Sequence
* Planned ETA
* Calculated ETA
* ETA Offset
* Planned ETD
* Calculated ETD
* ETD Offset
* Last Name
* Address Line 1
* PostCode
* Debriefed – a RAG status showing completion of the drop.
** Green Tick – completed.
** Amber Tick – partially completed.
** Red Tick – failed completely.
* Sent
* Attributes such as:
** Cash
** Cash Collected
** Casings Collected
** Ad Hoc Collections
** Ad Hoc Cash
* View button


Note that the following are only visible when drilling down into a job, not visible on this manifest drops list:

* Miles (ODO reading) – visible on Route Complete form.
* Failed drop comments – visible as reason codes against the items.
* Excess Tyres – visible on Route Complete form.


Once debrief is completed, the debriefing user can use the CTMS Debrief screen to update the trip to CONFIRMED status, to capture the debriefing user and the date/time debriefed.


== BI Reporting ==
There will be a nightly export from CTMS to the Stapletons data platform, including all standing and transactional data, showing:

* Trips:
** Planned and actual completion times.
** Vehicle and driver.
** Start and end times.
** Any manually captured debrief information.
* Orders:
** Products and quantities (planned, despatched/collected and delivered).
** Expected delivery times.
** Exceptions and reason codes.
** Any manually captured debrief information.
* Standing data, such as carriers, vehicles, drivers, DU types, transport movement types, locations, customers, reason codes.


MuleSoft will request additional data from FleXipod directly through the FleXipod API, including:

* Casings collected
* Cash collected
* Ad hoc collections
* Ad hoc cash
* Route completion data.

This will be passed onto the Stapletons data platform for further analysis.


== KPI Reporting ==
KPI reporting will be predominantly through the Stapletons data platform, including analysis of data from FleXipod, WEBFLEET and FleetCheck information if required by the operation.


CTMS contains exports and configurable exports that can be built from report levels. These can be used to summarise data and create extract reports for the operation. These are provided as-is with no changes specified to the standard reports, extracts or configurable extracts expected in this solution.

=Appendix A: Document References=
'''References'''

{| class="wikitable" width="100%" border="1"
|- bgcolor="lightgrey"
!'''Ref No'''!!'''Document Title & ID'''!!'''Version'''!!'''Date'''
|-
|SDDv3.07	||SDD-442106-Project Bumblebee Logistics TS3 Solution v3.07.docx	||3.07	||28/08/2024
|-
| - || - || - || -
|-
| - || - || - || -
|}

<!--
'''Glossary'''
{{CTMS_Glossary}}
-->

'''Document History'''
{| class="wikitable" width="100%" border="1"
|- bgcolor="lightgrey"
!'''Version'''!!'''Date'''!!'''Status'''!!'''Reason'''!!'''Initials'''
|-
|3.07	||28/08/2024	||Draft	||Initial version aligned with SDD.	||ANW
|-
|3.08	||06/09/2024	||Draft	||Revised from review with customer	||ANW
|-
|3.09	||27/09/2024	||Draft	||Revised from review with customer	||ANW
|}


'''Authorised By For Aptean'''
<table width="100%" border="0">
<tr><td><br />Murray Middleton</td><td><br />Project Manager</td><td>_____________________________</td></tr>
<tr><td><br />Tony Walker</td><td><br />Solution Designer</td><td>_____________________________</td></tr>
</table>


'''Authorised By For Customer'''
<table width="100%" border="0">
<tr><td><br />Matt Warren</td><td><br />Customer Representative</td><td>_____________________________</td></tr>
<tr><td><br />Campbell Strickland</td><td><br />Customer Representative</td><td>_____________________________</td></tr>
</table>


[[Category:{{#var:Client}} REQ]]
[[Category:{{#var:SystemCode}}]]