The Quantitative Supply Chain is more about a journey than an end in itself. Yet, at the same time, the supply chain leadership that engages their company in carrying out a Quantitative Supply Chain initiative requires visibility when it comes to the project timeline. While positive returns can be obtained in a couple of months, it frequently takes up to two years to unlock the full potential of Quantitative Supply Chain. In the following piece, we provide an overview of a typical timeline associated with a Quantitative Supply Chain initiative for a mid-market company. For large companies, timelines should be expected to be twice as long.
When a Quantitative Supply Chain initiative is carried out at Lokad, it is executed by one of Lokad's Supply Chain Scientists operating remotely for the most part. In this case, the data crunching is performed directly on Lokad's software platform. This is the perspective that we adopt below. The two parties mentioned are Lokad and the client.
Representatives from both parties introduce themselves to each other and schedule weekly meetings. These weekly meetings will last right until the Production
phase is reached. The Supply Chain Scientist presents the different phases of implementation and the various deliverables that can be expected by the client. The rest of the call is dedicated to reviewing various supply chain details and IT characteristics of the integration. After the call, a summary documenting the project's organizational aspects is produced and sent over to the client.
Shortly after the kickoff meeting, the Supply Chain Scientist produces the data specifications required for the implementation of the project. These specifications are reviewed and validated together with the client. In particular, this document shall define the data to be extracted from the client's IT systems. As a rule of thumb, the extraction should stay as close as possible to the original data as it exists in the client's IT systems.
1st Data upload
After validating the specifications, the first set of data is uploaded on Lokad’s servers by the client. Generally, at this stage, the upload is not yet carried out via an automated process as several attempts are usually required to establish a consensus on the fine print of data specification.
Validating the data
The Supply Chain Scientist performs an in-depth investigation of the client's dataset content. In particular, sanity checks are introduced to monitor the quality of the data according to multiple metrics. The goal is to make sure that 1) the dataset is properly refreshed by the upload process, 2) the dataset correctly reflects the reality of the business and 3) the dataset is coherent and complete enough for supply chain optimization purposes.
In terms of deliverables , during this phase the Supply Chain Scientist provides the client with various dashboards that assess the health
of the data . These dashboards can be used by the client even for purposes that go beyond the Quantitative Supply Chain initiative itself - as part of their internal data quality assurance process for example.
6 weeks following the initial kickoff, a meeting is set up to evaluate the project completion status. The objective of this "audit" is to address, as early as possible, the problems that may be experienced during the implementation, especially those that could delay the production phase. At Lokad, this "audit" consists of an exchange between the Supply Chain Scientist and the client, based on a checklist that is communicated to the client in advance by the Supply Chain Scientist, right after the kick-off meeting.
Once both parties validate the overall quality of the dataset that has been uploaded so far, the client implements an automated process that transfers their dataset to Lokad on a regular basis - ideally daily. At the same time, on Lokad's side, the data health logic - with its multiple checks - is scheduled to be refreshed after every upload.
Setting up the optimization
From this point on, the Supply Chain Scientist has all the necessary ingredients for implementing the optimization of decisions which have been agreed on with the client previously. Therefore, he implements scripts to generate different quantitative outputs: operational purchase suggestions, dispatch suggestions, etc. The figures produced by these scripts can be visualized in dashboard form. At this stage, these dashboards represent only a preliminary version of the final dashboards and need to be revised together with the client.
Feedback & fine-tuning
The client's requests to make some kind of alteration or "tweak" the different outputs usually lead to some fine-tuning of the scripts written by the Supply Chain Scientist. There are many parameters and methods that can be adopted to adequately align the characteristics of the supply chain being optimized with the optimization logic. When the methodology itself is of strategic importance to the client, this is explicitly discussed between the client and the Supply Chain Scientist.
After several rounds of fine-tuning and revision, the client reaches a stage when he comes to trust the logic implemented by the Supply Chain Scientist. At this point, the client can start using the service in production, that is, he can directly execute the supply chain decisions as originally computed by the software. When the client validates that the solution is production-ready, the Supply Chain Scientist delivers a documentation which ensures the maintainability of the solution.
Support & maintenance
The solution is operational and is used by the client while the Supply Chain Scientist monitors the smooth daily execution of the data pipeline. Calls are regularly organized between the client and the Supply Chain Scientist to verify that the optimization delivers the expected degree of supply chain performance. Moreover, supply chains are not static, thus, business or IT changes, small or big, need to be reviewed: a new warehouse, shift of the market, new process, etc. The Supply Chain Scientist proposes suitable modifications to accommodate these different changes. Checkpoint calls are scheduled with an agreed-upon frequency, typically monthly.