A web search on “Digital Supply Chain Transformation” returns around 126 million results – a substantial body of knowledge to guide organisations on digital transformations. Despite these resources, evidence suggests that up to 53% of these efforts don’t achieve their objectives.
Digital supply chain transformations are not just IT projects
No matter how tempting it is to expect technology to solve our woes, but unfortunately, the software is just an enabler. The funny part with software implementation is that it’s amazingly easy to get lost in the myriad requirements of data, interfaces, as well as skills and labour deficits, etc. Amid the chaos, sometimes the central question about why you began a transformation journey gets lost.
Transformations start with business cases
It could be anything ranging from increasing productivity to enhanced customer engagement. As you would assume, the IT team should be at the forefront of the technology implementation effort. However, the leadership team should continually track the digital implementation, confirming appropriate links back to the business case.
Still, there is a bigger “so what” question out there, and the digital supply chain transformation team should never shy away from asking it. “How does this huge (and hugely expensive) effort help us achieve [insert overriding business objective here]”.
Make sure you can answer questions such as “How is the inventory management software implementation helping the organisation reduce slow-moving SKU safety-stock levels?” “Will this allow us to use freed capacity to stock higher levels of fast-moving SKUs and better serve customer demand?” Regular tracing of the path between your implementation use cases and your concrete business objectives – ensuring they remain connected – will keep the overall effort on track. Be sure to stay abreast of and manage stakeholders’ expectations.
Attempting to achieve every conceivable goal may not be a fruitful strategy
At Chainalytics, we see hundreds of requests for proposal (RFPs) every year. We’ve determined, upon closer scrutiny, that only 20% of the requested functionalities are tangible differentiators that track back to specific business use cases. The remaining are just “good to have” features. Essentially, just another example of Pareto’s law.
The leadership team should conduct a thorough examination of all business use cases included in the digital supply chain transformation project. Classify these by urgency and the required organizational maturity level. The Moscow Prioritisation Matrix will help organise which business use cases should be part of the transformation journey.
This categorisation will help you determine the amount (and scope) of the work and focus on the important criteria. In addition, the must-have business use cases must link to concrete business KPIs. Monitor these KPIs through defined software data outputs. Here is an example:
| Business Challenge | The product portfolio has vast length and width, and it is increasingly difficult for sales to focus on individual SKUs. This results in inaccurate forecasts and sub-par customer service levels. |
| KPI to be Monitored | Achieve 90% CSL for fast-moving products and 80% CSL for slow-moving products |
| KPI Measuring Tech | Product segmentation software accurately categorises the product portfolio so that sales can focus on fast-moving and slow-moving items accordingly. |
A broader agreement on overarching objectives
Transformation projects cut across divisions of an organisation. As different departments often chase different KPIs, and it is imperative to sensitise the core team (which should ideally represent all stakeholders) to the larger objectives of the transformation project. For example, the finance department may insist on a working capital reduction that will translate directly into a drop in inventory levels. However, if a higher objective of the digital supply chain transformation project is improving customer service, the planning solution will most probably recommend increasing the inventory at certain buffer points to meet that aim. Here, it is better that all stakeholders agree on optimising the inventory levels – not merely raising or lowering them.
Most importantly, all involved need to understand that, while spirited discussions before making decisions are necessary, a firm commitment once you arrive at a determination is essential.
Select your partner(s) wisely
A digital supply chain transformation begins with two phases – selection of software and choosing a service integrator. Customarily, this approach places the project in the hands of a project leader selected from the ranks of in-house senior executives. However, the level of investment a digital transformation requires is significant. So, we insist on an additional phase where we choose a trusted advising partner.
| Select Industry Advisor | Selection of an industry advisor with extensive experience on similar transformation projects. |
| Software Selection | Industry advisor guides the organisation in linking business KPIs with corresponding software capabilities. |
| Integrator Selection | The industry advisor ensures that software vendors understand that the transformation is not only a software implementation. It must enable the resolution of business challenges via the capabilities of the application. |
It is ideal if the service integrator – Chainalytics, in this case – offers the services of an industry advisor. This ensures timely implementation follows a thorough planning process. Always keep this in mind: your organisation’s business use cases are unique. Force-fitting of “similar implementation” may not work in your situation. The industry advisor will be your friend, philosopher, and guide. They will mentor, coach, and otherwise prepare your team for the project at hand.
Crawl, walk, and then run – the implementation
Don’t rush through this part. You’ll want to give your team time to understand the software ecosystem and the connection between its functional capabilities and the recognised business use cases. Spend as much time as is necessary in the blueprinting phase. Identify your data sources and confirm their accuracy. Familiarise yourself with the underlying technical challenges. In the long run, a successful implementation that took somewhat longer than expected will be more valuable than an on-schedule but ultimately incomplete implementation that was rushed to completion.