Delivering Bespoke Replenishment Management System

How Elevation successfully delivered a new bespoke Replenishment Management System for Wickes on time and to budget.

The Replenishment Management System (RMS) was a bespoke purchase order manager to receive Purchase Order proposals from Blue Yonder, and ad-hoc orders created in a required PO creation application, and sending each type of order to the respective downstream systems:

Vendor to Store Orders (Direct To Store)
Vendor to Distribution Centre orders
Distribution Centre to Store Orders

The problem

As part of the separation from the parent company - Travis Perkins - Wickes needed to build out their IT systems. A key part of that process was building a purchase order management system. Elevation was made responsible for collaborating with the business product owner, project manager and enterprise architects to scope out the system, putting together an accurate roadmap plan and then deliver it within the agreed timeline and cost.

Delivery approach

Scoping

Utilising a tried and tested approach to delivery, Elevation’s first step was to strategically decompose the system into features and then into epics to properly scope and size. Our team of solution architects and development experts collaborated with Wickes' business product owner and architects. Together, we aimed to gain a deeper understanding of the system, negotiate the scope at a high level, agree on a technical approach, and produce estimates for each epic.

Creating the delivery plan

The team at Elevation created a delivery plan using our lightweight implementation of the Scaled Agile Framework. To estimate the size of each epic, we used comparative relative estimation in 'epic points', which could then be converted to story points. We accounted for dependencies and our known velocity while building the delivery plan. Additionally, we included a regular release cadence and ensured that the necessary elements, such as transition to support, documentation, and test strategy, were included in our definition of done.

Discovery

After agreeing on a plan, we moved on to the next level of detail - discovery. Since Elevation followed the Agile approach, we only conducted discovery for each epic a sprint or two before it was set to go into development. In these workshops, we aimed to address any questions related to requirements or technical approaches. We worked closely with Wickes' architect and product owner to understand and document the requirements using the Behaviour Driven Development approach, which involves specifying the requirements through the Gherkin syntax (Given/When/Then).

Technical planning and build

We completed the discovery process for each epic and wrote individual user stories for it in technical planning workshops. These user stories were then ready for development in upcoming sprints. We also reviewed our low-level estimations against the high-level ones and consulted the project manager if there were any changes. With this process completed, the team started development with the support of technical leads and technical consultants who ensured good technical governance.

Releasing and service introduction

During development, we scheduled regular demos where the developers would walk the stakeholders through each feature and incorporate any feedback.

In preparation for each release, we:

Documented the solution.
Completed a knowledge transfer to the support team.
Completed security assessments.
Completed performance testing.
Prepared a detailed release runbook with rollback plans.

Having successfully released the solution and transitioned it into BAU, we then iterated through this process to scope out and deliver each subsequent version.

The technical solution

The Replenishment Management System (RMS) was utilised to provide a tactical purchase order manager to receive Purchase Order proposals from Blue Yonder, ad-hoc orders created in a required PO creation application, and to send each type of order to the respective downstream systems:

Vendor to Store Orders (known as Direct To Store (DTS) orders)
Vendor to DC Orders (known as Distribution Centre (DC) orders)
DC to Store Orders (known as Pick Requests, and Store Orders depending on the system)

The current systems that RMS was planned to replace included Blue Yonder, used as a substitute for iReplen. Blue Yonder sends out orders to DCS or Manugistics, which are then passed on to Back Office, Universe, and Calidus. The Phase 1 landscape of the project Brain is illustrated in the diagram.

Overall design pattern: The Hub

The hub pattern is a design approach where the Replenishment Management Service acts as the central coordinator of data flows between systems. This is because the process of order processing is essentially a workflow process, and the Replenishment Order progresses through different stages based on this workflow.

The Replenishment Order's centralised view offers clear visibility into the ordering process's efficiency and the current state of a specific replenishment order within that process. It also enables the capture of information regarding the fulfilment and delivery's success and comparing it with the original request, thereby monitoring the Supply Chain process's performance.

Top-level components

The solution for RMS therefore comprises the following top-level components:

C01 - RMS Service

Main orchestration service that handles the end-to-end aspects of workflows for integration and processing Purchase Orders beyond proposal stage and up to delivery/receipting and closure.

C02.1 - Downloader App

The app to allow secure downloading of the SPAs to the user and ensuring appropriate protection of security credentials and tokens. This component may not be required.

C02.2 - PO API

API for querying and amending Purchase Orders, and for creating and validating Ad-hoc Purchase Orders and Store Replenishment Orders - used by the Apps.

C02.3 - PO Amendment App

The SPA to view and amend/resubmit purchase orders (to suppliers) that have been issued, but cannot be fulfilled by those suppliers for whatever reason.

C02.4 - PO Ad-Hoc Creation App

The SPA to create new Replenishment Orders replacing functionality within DCS for DTS orders, and new functionality for DC or Store Pick Orders that are not covered by Blue Yonder. It is likely this will be combined with C03a into the one Replenishment Order App.

C03 - Reference Data Adapter

Interface point for key retail reference data, preferably via the respective Product/Location/Supplier/Range microservices, or obtaining a feed from other sources if needed (e.g. PMM).

C04 - Blue Yonder Adapter

The adapter to integrate with Blue Yonder to receive Vendor and Store orders, and to send back Scheduled Receipts (as open orders) and In-Transit Orders.

C05 - Calidus Adapter

The Adapter to integrate with Calidus to send Purchase Order and Store Order notifications - for receipting Vendor to DC Purchase Orders, and providing Pick Requests for DC to Store Replenishment Orders, and to receive the DC dispatches of Pick Requests to Store orders, and notify receipting of Vendor to DC orders delivered by suppliers.

C06 - Back Office Adapter

The Adapter integrates with Back Office to send Purchase Orders for Direct to Store (DTS) deliveries, or for DC to Store replenishment orders for receipting against, and for providing Receipts for DTS orders, or for scheduled receipts for partial DC to Store deliveries.

C07 - True Commerce Adapter

The Adapter to pass Vendor to DC Purchase Orders, and Vendor to Store (DTS) Purchase Orders via the True Commerce EDI gateway. This will either do the EDI conversion or more preferable pass this to a new interface that will convert the simple PO model into the EDI (Tradacoms) format. To be confirmed for the output formats.

C08 - Maesrk Adapter

The Adapter to pass international Purchase Orders to Maersk to arrange for shipping from the off-shore suppliers to the UK.

C09 - Receiving Service Adaptor

Adapter to interface with the Receipt Service to store and provide a query to the receipts aligned with purchase orders.

C10 - Finance System Adaptor

Currently not in scope.

C11 - Reporting System Adapter

To the data lake or data warehouse for analysis and reporting - currently not in scope

End-to-end flows: Order processing

The purpose of centralising the mechanism for the different end-to-end flows was to follow a process orchestration pattern, by which the activities within a process are controlled within a central workflow service. This helped to improve the visibility of processes, and allowed for monitoring and corrective action to be performed to rollback or reattempt failed workflows.

Each workflow is a process, and each replenishment order is passed to that process as a piece of work - also referred to as a process instance that passes into the workflow service, which manages the progress of that process instance as goes from one action to another. That process is defined as a workflow and modelled in this case as a BPMN2 model.

Results

Delivery enabled the successful demerger from Travis Perkins.
Allowed the successful decommissioning of legacy systems.
Completed on time and to budget.
Delivered 56 epics (consisting of 1,255 story points of effort)

Conclusion

The project was deemed an overwhelming success and the success of the programme was acknowledged at the highest levels within Wickes. Several additional phases of development followed and it continues to be a stable, reliable, and scalable key tool within Wickes’ distribution software portfolio.

Are you looking for an innovative solution to your IT delivery nightmare?

Let’s talk - Leave us your details and a member of the team will be in touch to discuss more.

I’m happy to be contacted by Elevation and to be added to a mailing list.