It’s hard to believe it was almost 4 years ago when COVID-19 was declared a pandemic by the World Health Organization. I can remember hearing the horrible news stories about how despite the heroic efforts of our healthcare providers thousands of people were dying because they couldn’t get access to life saving medicines and medical devices - the hospitals didn’t even have enough personal protective equipment to keep our doctors and nurses safe. The reality of an inadequate supply chain was a major contributor the largest public health crisis of our generation. It affected all of us - I’m pretty sure my family is still using the toilet paper we stock piled during the pandemic…
COVID put a spotlight on a systemic pervasive issue with our pharmaceutical supply chain - but the issue is far from new. Back in 2013 the US FDA passed the Drug Supply Chain Safety Act (DSCSA) which put into law requirements around track-and-trace; given the rapid “digitization” of supply chain this the mandate should have been pretty easy - it’s just a matter of data standards and interfaces right? 10 years later only portions of DSCSA are even enforceable... This is not due to lack of effort! Tremendous strides have been made in untangling a decades old, complex, multi-tiered supply chain. It’s just that these attempts have fallen short.
I will admit that this post is a bit lengthy and opinionated, but I think that in order to appreciate the magnitude of change that is needed we have to dig a bit deeper into root cause.
The public health issues due to “lack of transparency” in pharmaceutical supply chain have been documented and discussed at length in recent years. The fact that many government agencies are still citing “Supply chain visibility, monitoring, and data sharing processes and platforms” as a topic that requires research and innovation is conviction enough that current approaches are not working. To be clear, it is not for lack of approaches, many software platforms solve this issue quite well, it is lack of adoption that prevents them from scaling; but I would argue that lack of adoption is driven by poor approach. Any solution that is counting on pressure from business partners or regulators to drive it’s acceptance is approaching the issue from a point of compliance and is incentivizing participation via the “stick” vs. the “carrot”- they will never be sustainable.
For the purposes of this post I would rather frame the question of “why did it get like this” as opposed to “how bad is the issue”, because in understanding the why we can perhaps identify the core changes that are needed to correct the problem. This will result (I hope) in a series of foundational methods/techniques that work well all of the time (”always get the little things right”) and transcend any particular system or platform.
So here we go from the ground up… fundamentally supply chain is the exchange of assets in return for payment. As complex as our supply chains can be today, they all revolve around facilitating this basic transaction. The “chain” part of supply chain implies that it is a series of transactions that are required to produce and distribute a product. At the edges of a supply chain the exchange of the physical good and payment can take place simultaneously.
Think about a farmer selling a harvested wheat crop to a granary on one end of the supply supply spectrum and a hungry person buying a loaf of bread at a bakery - and lets assume these are both cash transactions paid on the spot with no returns for simplicity sake. This is a simple example of settlement - meaning that one good (wheat or bread) was exchanged for another (money) and there are no residual commitments; the transaction was settled, we are both in agreement with the outcome, lets move on… But as we work our way either downstream or upstream from the ends of the supply chain the quantities of product and the aggregate amounts paid for them begin to increase dramatically (the value of all the grain in the granary is far greater than the value of the individual harvest - the value of all the flour at the bakery is much higher than the price of one loaf of bread) and this aggregation / disaggregation gives rise to a split in the fundamental transaction.
If the granary is able to sell their entire stock to a miller it is very unlikely they will be paid the moment the grain leaves their silos, the miller will may only want to pay upon receipt and inspection of the grain; and even then they may ask for a delay in payment (I had a client once who demanded 120 day payment terms!). As soon as this happens the exchange of the product and the payment are no longer asynchronous – there is a separation between the financial ownership and the physical custody. This results in two interrelated, but separate transactions that require settlement, and this seemingly small rift allows for a vast complexity of buying and selling arrangements. This should be intuitive to the reader - there is noting new in this centuries old process, but what is interesting is how we evolved systems to address this. Lynn Aldren’s recent book “Broken Money” does a fantastic job of explaining the monetary side of this evolution.
But on the supply chain side we should look more closely at the computer systems in manufacturing enterprises. They were used for financial accounting long before they were used for managing inventory. As manufacturers required more supplies, they developed procurement processes to facilitate purchasing and to manage their costs. On the other side of the house as customers purchased more products, they developed sales processes to manage their revenues - the monetary system was (and still is) the primary driver of their development. Inventory management was (and mostly still is) an input or output of procurement and sales. ERPs developed to bridge this gap (Enterprise Resource Planning where the resource is many forms of capital - materials, human, knowledge, money, etc) to create efficiencies within the individual organization, but not across organizations. Granted if the organization is big enough it may seem like the ERP is controlling an entire supply chain, but it is always internally focused in the end - the jurisdiction of the ERP stops at the boundaries of the enterprise. But supply chain by definition is bigger than any one enterprise so to make this process more efficient they developed ways to connect their procurement and sales systems with their suppliers and customers. If those supplier and customers happen to be running the same ERP software this is a bit easier (much to the software providers benefit), and although the proliferation of standard Application Programming Interfaces (APIs) and data standards have made things much better as well, it is still complex and clunky - and in some cases completely broken. Yet these procurement and sales based interfaces are the best we have and we rely on them today to connect our incredibly complex supply chains.
All of that is to say that, interfaces between trading partners exist for the primary purpose of settling payments, the transfer of physical inventory is not usually settled, it is just an input or an output (IMO this isn’t a bad thing - a single ERP or system can never/should never govern an entire supply chain).
In addition to the maintenance, complexity, and reconciliation challenges inherent in this web of interfaces (I like the term API spaghetti) there is another nuanced issue. Payments are fungible where inventory is not. If company A pays company B $6 US dollars for a product, that $6 is (eventually) debited from company A and credited to company B. There is no requirement (or reason) to determine if company B used that same $6, or a fraction of it, to buy something from company C. But this is not the case for inventory, even if the individual units of inventory themselves are interchangeable (i.e., one screw in a box of 100) they are identifiable at some level – unit, lot/batch, product, etc.). So, to transfer this type of knowledge between trading partners the EDI 867 Product Transfer and Resale Report was designed explicitly to pass along product information. And there is a bit of handshake between the trading partners if they use a corresponding EDI 997 Functional Acknowledgment to show the EDI was received and in good format - but that receipt does not guarantee that the inventory was moved out of one system and into another we still have to rely on a separate system of checks and controls to keep the information in the digital records in sync with the physical movements of inventory. This manifests itself in the form of something like this:
Seller: “Upon shipment of x units of product y in relation to order z, I will debit x units of product y from my inventory system”
and
Buyer: “Upon receipt of x units of product y in relation to order z, I will credit x units of product y to my inventory system (in which I may or may not refer to this product as product y)
These statements are only made for the sake of the buyers’ and sellers’ internal inventory management systems which they use for their internal planning. They are only as strong as their internal processes and controls - they are not settlements. Further, just as with the payment, the history of transfers related to that particular product is not inherently tied to the product record, it is buried in the paper trail of the procurement process - and that paper trail usually breaks each time the product is transferred.
The core issue at the bottom of all of this is the lack of a way to “settle inventory transfers” and a way to “log and share a history of those transfers” between trading partners.
Of course, the above description is over generalized and as I mentioned these are not new issues; there are many solutions either available or under development that aim to address inventory settlement - often rolled up into solutions for “supply chain visibility” or “track-and-trace” in response to the current description of the problem.
Lets also establish up front the fact that inventory settlements between training partners are confidential transactions. Meaning that anyone not involved in the transaction should not be able to infer any information about it. It might be OK for it to be known that two entities are trading partners (in pharma we have the concept of Authorized Trading Partners already established) but which products, how many, and how often are trade secrets. If a competitor were able to get that information there would be many opportunities to arbitrage the supply chain.