Data-driven, AI Powered, Supply chain Part-2:
The concept of Supply-chain Network, TOC & the importance of Information Supply-chain
Theory of Constraints & The ‘Goal’.
I did hear about the Theory of Constraints(TOC) off and on through late 90s, but I didn’t pay much attention till that fateful evening in Malaysia. One of the i2 guys had one too many and ended up lecturing me on how TOC was going to change the world. Ken Sharma, one of the two partners who set up i2 worked for Goldratt Institute before he joined hands with Sanjiv Sidhu.
I bought Eli Goldratt’s book ‘The Goal’ on the way back to the Airport, and I was immediately hooked. The simplicity and the logic in the model were real, and the book was a great read…more like a fast-paced thriller than a dull business book.
Over the next couple of years, I read every book and every article published on the Theory of Constraints. While I moved on to run Middleware (Enterprise Application Integration) practice, and then into Pharma & Life-sciences vertical, I still kept hearing about TOC from some of my close friends and erstwhile colleagues who switched over to TOC consulting.
Gradually the market for TOC started picking up in India, especially after the introduction of “viable vision”. The concept caught the imagination of every aspirational CEO; after all who can resist the chance to turn the company’s topline into its bottom line, JUST in four years?
The viability of the ‘Viable Vision’.
In simple terms, a company implementing TOC can aim for converting its current top-line $ number into its’ bottom-line $ number in four years. Seems incredible, but Goldratt believed it is a perfectly ‘viable vision’ for a company to have. He used to conduct one-day workshops exclusively for the CEOs / CxOs to explain why such a vision is viable. Goldratt was so convincing, many CEOs wanted to try it out. Besides, Goldratt was willing to share the risk; he would take the majority of his fees if, and only if, the company manages to achieve its stated goal.
While there were a few big successes, there were many more disappointments. I would assume a ‘lack of commitment from the top management’ must be one of the key underlying reasons for failures. Over a period of time, TOC consultants stopped talking about ‘viable vision’, but they continue to get engaged especially by growth-oriented companies of medium size. The goals being set for the TOC projects still continue to be challenging, but definitely not as ambitious as in the case of ‘viable vision’.
Why do TOC projects fail?
Strictly speaking, TOC projects do not ‘completely’ fail. However, they can fail to deliver the intended value. They do produce results, but the scale and value delivered may depend on how exactly you have designed and implemented your project. In an overwhelming majority of cases, the ‘vision’ for converting your topline number into your bottom line, in four years or less, may turn out to be ‘not viable’.
There is a fair amount of academic criticism of TOC. Some claim there is nothing new in TOC (Steyn H., 2000), it has heavily borrowed from pre-existing concepts, some claim it is the same as the theory proposed by Wolfgang Mewes (1963), it does not work for product mix decisions, etc… The majority of the academics seem to suggest Prof. Goldratt’s work does not have the necessary ‘rigor’ to be called a serious academic theory. Goldratt published a paper titled “Standing on the shoulders of Giants” (Goldratt, 2009) acknowledging different preexisting concepts and people who inspired TOC.
While there is no consensus on why implementations fail, many consultants attribute the failure to the following reasons:
a. Limited Scope definition & Lack of commitment from Top Management… Typically cases where the managements are extra-cautious, end-up choosing a small sub-process for a pilot which is inherently unsuitable for TOC implementation or to demonstrate its value conclusively.
b. The key constraint identified is NOT the ‘real key’ constraint.
c. Customer was not able to handle the business disruption through the ‘period of pain’ and ended up going back to his old process model.
My own Experiments with TOC & SCO
I spent a good part of the last three decades in consulting and working for services companies. I tried the concept of TOC as the COO of a large digital content services KPO for one of its divisions. I was often told ‘Theory of Constraints’ is meant only for manufacturing companies. But I reasoned if Goldratt can apply TOC for the marketing department, sure it has to work for services companies as well. Besides, off and on, I kept hearing about TOC concepts being applied to non-manufacturing sectors e.g., healthcare.
The whole experience was fascinating.., The division was badly run for years and had just lost the confidence (& 3/4th of business) of its largest client. The morale was low, and my boss (and the MD) privately confessed to me that he ran out of ideas. I was asked to drive the business personally and to do what I can to bring it back on track. There was already enough confusion in the system and people, so I did not mention anywhere that I was driving a TOC implementation so as not to confuse them further. Since bringing the business back on track was a bigger priority for me, I wanted to simultaneously try TOC and Service-chain Optimization (called SCO, as a concept less popular than TOC) together…Further, I always believed creating a ‘seamless, granular, and drill-down visibility into the entire value chain’ is the most important fix. So building visibility into the supply chain (service-chain in this case) was my biggest priority.
The division consisted of many sub-divisions called clusters; and I quickly discovered, each cluster followed its own process and their own reporting formats. So, in lieu of a standard due diligence, I asked all the teams in the division to create a ‘daily status report’ (DSR) — a report that clearly lists out every job as it progresses through different stages of the workflow… I mandated a ‘standard reporting format’ that evolved and became more and more granular over a period of time. I ensured that all the granular elements (pertaining to different clusters) on different pages, added up to the overall division’s reporting numbers on a front page (that we called At-a-glance) as an ‘Executive-Summary’ for the top management. (We used Excel with small macros. )
In my mind, the daily status report was meant to be a ‘digital twin’ that reflects the true status of each of the jobs in each of the workflow stages, across the complete value chain. While the digital twin was not enabling the ‘collecting and monitoring the data’ in real-time, the 6–12 hours lag was acceptable for us to start with.
I created a Program Management Office (PMO), to collect, collate and monitor the daily-status-report from different clusters. The PMO head used to share the DSR with the clients-teams every day without fail.
And every day, I used to have a daily status meeting with all the cluster heads and the team leads, where I would run through every job that is delayed or likely to be delayed. It was easy enough to discover which particular stage in the workflow was a bottleneck, or likely to become a bottleneck. A quick ramping-up of the capacity in critical stages of the workflow fixed the bottlenecks to a large extent. Besides the bottlenecks, the other teething problems involved ‘communication’ or the lack of it. Information and instructions, between the clients and the delivery teams, were being lost in the translation, leading to rework in critical workflow stages, constraining the capacity further. Then to my surprise, I discovered a similar communication drop was happening between different stages in the internal workflow. The missing-data, and the back and forth for the clarifications, were the root cause of bottlenecks in most cases.
We started creating a space within the daily status report for all the critical pieces of data and information that need to be exchanged between different stages of the internal workflow and with the clients’ teams. We created a color code to alert the client on the ‘missing pieces of information’ so as to ensure they clarify on a priority.
Soon with the workflow bottlenecks fixed, and with smoother information flow, the teething delivery issues that crippled the division a few months back started disappearing. Simultaneously, customers began to recognize the significant and welcome improvements in delivery and started diverting more and more business from different vendors back to our company. We started creating a separate section within the daily status report for the client to list out the new business that is likely to come our way. The advanced information helped the clusters to plan and ramp up their capacities in anticipation of the business.
Within nine months, the division had become the most efficient (and most profitable) business unit in the company. The top-line run-rate ($ sales per month) of the division more than tripled by the end of the 9th month. The concept of daily status reports was subsequently rolled out to other divisions with similar quantum of success.
Here are my key learnings from the experiment:
1. The enterprise value-chain is not one unitary chain, but a complex network, or an interlinked web of multiple supply-chains.
a. Every Physical-goods supply-chain has a Services supply-chain supporting it, a set-of people providing services to ensure the physical goods supply-chain functions well.
For e.g.: You need people to make documents like way bills, receiving reports, invoices, etc., at every stage in supply-chain… the efficiency and speed of the Services supply-chain can affect the speed and efficiency of the Physical goods supply-chain. For e.g.: any delay in creating the GST-Invoices can hold the truck from leaving the factory premises.
b. Every Physical-goods supply-chain has a Cash-flow supply-chain supporting the value exchange each time the title to the goods changes from one entity to the other or each time a legal bailment is created…. A Cash-flow supply chain that pays for every service that is delivered to enable the Physical goods supply chain. For e.g.: Any delay in releasing the payment for one or more of the services such as transport, can hold the physical goods supply-chain to a grinding halt.
c. Every Physical goods supply-chain is supported by a Data supply-chain / Information supply-chain… Information that gets passed on from one workflow stage to the next either in the form of a physical document (like a GST Invoice, or a Waybill), or as a ‘digital document’ (For e.g.: SAP uses a format called IDoc (Internal Document) to send out data pertaining to a unique transaction for exchanging information with external applications)
d. For a Supply-chain to function well at full capacity, highest possible throughput, the multiple layers of supply-chains need to work in tandem, perfectly in equilibrium. Any bottlenecks in Cash-flow Supply-chain, Information-Supply-chain, or Internal Services Supply-chain will definitely create bottlenecks in Physical-goods Supply-chain.
2. Creating ‘seamless, drill-down visibility into supply-chain’ is the most important first step for any supply-chain engagement — irrespective of the industry segment. The rule is as important for the Physical goods supply-chain in the manufacturing sector, as it is for, Service-chain in the services industry.
The ideal mode of supply-chain visibility should be in the form of a ‘Digital Supply-chain Twin’ (e.g.: Similar to a SCADA system) that reflects the ‘instant truth’ of every job at every stage of the supply-chain. Instant truth means instant exchange of information between the Physical-goods Supply-chain and the Digital Twin.
3. TOC implementations in the manufacturing sector, that focus purely on the ‘constraints’ within the Physical-goods Supply-chain, and ignore the constraints in the ‘Services Supply-chain, Cash-flow Supply-chain, and Information Supply-chain,… are scripted for failure.
In the case of Services-companies, the efficiency and effectiveness of the Service-chain would depend on the efficiency & effectiveness of the layers of the Cash-flow Supply-chain and the Information Supply-chain supporting it. The Information Supply-chain is far more important in services companies.
4. The series of ‘in-process buffers’ created to ease the constraints (in the workflow) in a typical TOC implementation, would mean incremental work-in-process inventory, which in turn means incremental working-capital, and can lead to incremental stress in the Cash-flow Supply-chain.
There are numerous articles on how ‘improving the throughput’ in one workflow stage could create incremental stress and a bottleneck in the subsequent workflow stages downstream.
5. Maximizing the organizational ‘throughput’ in a TOC implementation, needs to be done without upsetting the delicate balance, or the ‘equilibrium’ between different interdependent layers of supply-chains (of physical goods, internal services, and information).
Data-driven Supply-chain
And that brings me to the next big question…
What if every decision at every stage in the workflow is driven by ‘data’… 100% relevant and sufficient data that can support the decisions that drive the supply chain?
How exactly do you recognize and list what supply-chain decisions are being made at each stage of the supply chain? And to add to the complexity, each of such decisions in the physical-goods-supply-chain may influence the vitals of the cash-flow supply-chain, or the demand on the services-supply-chain.
In the case study I mentioned above, we did go through real granular data on every work-flow-stage, for every job, and more importantly, institutionalized a method to generate and utilize such data to make ‘service-chain decisions’. In our case, the data was a priority, and hence we had a deliberate strategy to identify and source the data that supports decisions at every workflow stage.
But I am not sure if a typical TOC implementation ‘prioritizes the data that supports supply-chain decisions’. I am also not sure if TOC implementations take into account the concept of interdependent multiple layers of supply chains, and the bottlenecks that may occur in Cash-flow and Information-supply-chains that in turn affect the Physical goods-supply-chain (Note: Information = Data + Insights)
So how exactly does one go about building a data-driven supply chain? Most articles and books I came across have only dealt with generic directions. …Not useful for someone looking for specific directions for building a ‘digital-supply-chain’.
The following response (picture on the right) has been generated by Open-AI Chat. Surprisingly, this generative AI does a better job than most articles. It does mention “identifying process bottlenecks” in the very first step.
READ EARLIER
PART-1: https://krishnapera.medium.com/roadmap-for-a-data-driven-ai-powered-supply-chain-19180ef1d0be
READ NEXT
PART-3: https://krishnapera.medium.com/data-driven-ai-powered-supply-chain-part-3-c01cad9cb7f2
