One of the reasons I invest so much time and resources of our company in keeping current with the information technology is that good supply chain depends almost entirely on good information.
And, your information is only as good as the technology deployed to collect, collate, store, parse and reproduce the information on demand. It is no secret that most of our supply chain transformation projects are highly time intensive and heavily data driven.
We trust all participants in the supply chain, and we verify everything – from several angles. However, if you have been working in freight cost reduction for over 30 years like I have been, you know the reality on ground. But that raises a big question about the data.
A data scientist can only be as good as the data s/he has.
In most projects the data is woefully inadequate – even today in 2016.
Rather than talk about our current freight cost reduction projects, I will give an example from several years ago (for sake of propriety and confidentiality I will disguise some details).
When our team completed the initial 8 week diagnostic on that project for an industrial corporation with $1.3 Billion supply chain, it was clear that despite heavy investment in SAP, supply chain data was far from adequate. In fact for ocean shipping it was so inadequate that we had to employ temporary staff in to digitize a paper trail of transaction details in order to conduct our analysis.
I could probably spend another 5,000 words just writing about how difficult it was to get hold of the data, and then how difficult it was to verify the veracity of that SAP extracts. After all my team was sharing their travails with me on a daily basis.
We had signed a fixed price 10 week contract for completing the work.
We anticipated the usual data problems for the first week or 2. What we did not anticipate was a 5 week run around to get hold of the SAP extract, and then another 2 weeks to verify its veracity. As a result our team had to find additional resources, and time, to conduct a 6-7 week analysis in 3-4 weeks in order to meet the deadline for senior executive off-site meeting scheduled for the end of the diagnostic.
I asked the team to make full record of all the inadequacies they found in the SAP set-up so that we could provide recommendations on system upgrade to facilitate good supply chain planning, control and decision making. While this was not something our company worked on, and it was not even part of the project brief, it was going to be extremely useful for future SAP upgrades in the company.
The limits of any machine are only discovered when it is being used at its limits.
(Now that upgrade is a subject for another blog, at some other time). It was clear to all that SAP was set-up mainly for financial reporting purposes, and supply chain management was an afterthought to the transaction recording.
As a result, the system did a marvelous job of providing aggregate data on financial well-being of the organisation. It also facilitated adequate drilling-down of financial transactions. Yet linking those financial details to actual supply chain movements was less than adequate.
In fact, for ocean shipping, nearly 25 hand-over points in the transaction workflow were all aggregated into one single SAP transaction.
Our team diligently recorded all the issues with supply chain transaction processing that we found during our strategic diagnostics of supply chain. Several pages of tables similar to the one below were cross-checked, verified and created.
Not just that, an annex report with high level requirements for future upgrade of SAP was also created, even though this was not part of our original project brief. Unfortunately, I am disinclined to publicly share even sanitized version of a sample extract out of this report .
Privately, I might be able to share sanitized extracts in case your team is going through a process of making your SAP installation more user friendly to your digitized supply chain.
I chose this case example for several reasons.
Firstly, it has gone through a full cycle of business and information technology outcomes, which are now well known. On business side our supply chain transformation project was a massive success. In fact the global head of supply chain (who later became the CEO) wrote this in the foreword to one of my books:
When I engaged Vivek’s services for supply chain transformation in one of the companies I was heading, we expected the careful and methodical approach that he was famous for. Outsourcing was only one of the components of our supply chain, and at the time we did not think it was even a particularly important one.
I was already convinced that critical business turnaround can only be achieved by taking an end-to-end supply chain approach to this transformation. I was pleased to note that the original target set for 3 years was surpassed by almost 70% in just 18 months – providing graphic evidence of the full power of these ideas in action.
On the information technology side, the supply chain requirements were never fully translated into a usable system resource base.
I will not go into the reasons in this blog. SAP has since invested in Ariba – a procurement management software.
Unfortunately, the confusion between procurement and supply chain management continues to persist. A number of journalists, and even business professionals use the terms interchangeably. On the IT side the supply chain workflow still remains inadequately supported.
A few newer companies are starting to crop up, yet a great majority of them (to some degree) seem to be falling into the same traps that their predecessors fell into above.
In my next blog I will cover this in more detail. Meanwhile, share your experience with SAP, Ariba or other so called supply chain transaction processing software systems.
Not only will you add to the accumulated IP on supply chain system, but also you may earn a copy of the book quoted above.