This story first appeared in the Quarter 3/2019 edition of CSCMP's Supply Chain Quarterly, a journal of thought leadership for the supply chain management profession and a sister publication to AGiLE Business Media's DC Velocity.
Blockchain absolutely seems like the technology innovation supply chain has been waiting for. Why? Well, supply chains are heavily distributed and heterogeneous. No single company "has a supply chain." Instead, everyone is a member of a highly complex and ever-evolving supply chain network.
In this type of network, you are highly dependent on others: your customers and suppliers, your warehouse and logistics providers, your transport carriers, your brokers and trade banks, your contract manufacturers, your channel partners and distributors. The orchestration of supply chain planning and execution activities across all those partners is paramount, and sharing information effectively is the lubricant that creates a well-oiled supply chain. Currently, however, that orchestration and information sharing is primarily done through emails, spreadsheets, and messaging. Why? Because data is scattered everywhere. It's caged in the silos of each partner's systems, redundant and in different representations. Everyone is looking at their own "truth," and data integration between partners is feared like the plague because it is so complex. Collaboration across company boundaries is therefore the undisputed number-one unsolved business problem in supply chain.
What could be a more fitting solution for this task than "distributed ledger" blockchain technology? After all, the promise of blockchain is to provide "immutable truth" across a vast network of "nodes" and to enable the sharing of data freely but securely with only those with rights to it. With blockchains, business partners will be able to execute "smart contracts" independent of any third-party authority or technology vendor and use "tokens" to pay for the infrastructure and distribute value as an incentive for participation. Wow! Seems perfect, doesn't it? I am not being sarcastic. This is exactly how I felt, and still in many ways feel today, when thinking about how perfectly suited blockchain is to solving supply chain problems.
If you feel a big "but" coming, you are right. It turns out that before we can even begin to implement blockchain and realize its tremendous value for the supply chain, there are obstacles we must overcome in three key areas: data quality, technology complexity, and adoption model.
IMMUTABILITY DOES NOT EQUAL DATA QUALITY
In the world of multiparty coordination, data quality—or having data that is accurate, complete, and timely—is a very hot topic. That's because it is important but very difficult to achieve. Technology that provides "immutable truth" seems like the perfect solution to this problem, but it really isn't. All "immutable truth" means is that once data is committed to the ledger, it can't be changed. For example, if a manufacturer first records the country of origin of a product as Bangladesh on an electronic certificate, it can't later change that to U.S.—nor could anybody else who might benefit from that change.
However, the vast majority of data-quality issues in supply chain are not someone changing data. Unfortunately, it's much more basic than that. Most problems are about data being entered incorrectly in the first place or coming in way too late. Or else they are about data being misunderstood or simply not being there at all. Unfortunately, blockchain does very little, if anything, to address these issues. That's not a knock on blockchain; it wasn't designed to solve those problems.
Furthermore, while immutable truth is mostly a good thing, it can sometimes cause problems. Why? Well, given the complexity and nature of supply chains, things invariably do go wrong, and bad data does enter supply chain systems. For example, a supplier might enter the wrong country of origin, which subsequently holds up a letter-of-credit payment and thus shipment of the goods. Or a logistics provider might perform a major system upgrade, and all of a sudden, all incoming advance shipment notices (ASNs) have the product weights wrong. This type of stuff happens every day, and fixing the issues across the entire supply chain is painful. Now imagine how difficult it will be when you have thousands of those bad data points being immutable.
In other words, don't undertake a blockchain project because you think it will address data-quality challenges. It won't. Instead, carefully design the points where data enters the distributed ledger and consider how to deal with the inevitable case of bad data.
RUBE GOLDBERG, ANYONE?
The cartoonist Rube Goldberg was famous for his drawings depicting complicated gadgets performing simple tasks in convoluted ways. For some applications, blockchain technology might end up being a "Rube Goldberg device" because it's too complex of a solution for the problem the supply chain is trying to solve. This really has two aspects; let's look at the first: code stability.
Blockchains are not just distributed ledgers but distributed apps. The same code is running on hundreds of servers, or "nodes," which are storing equivalent copies of data and talking to each other to commit new transactions and keep data in sync (via what's called a consensus mechanism). It is an amazing and intricate organism.
But that complexity makes it horribly difficult to upgrade and maintain. Let's say the latest software build our development team committed has introduced a priority-one defect that is negatively affecting our customers' operations so that they can't ship orders to their customers. What now? In a centralized system, we would gather the development team together, quickly create and test a fix, and deploy it to the production system. Done.
But how does one deploy that fix to hundreds of nodes? In blockchain speak that requires "consensus." The majority of nodes have to agree to deploy it before the fix can become the latest version. Anyone deploying code to a public-scale, mission-critical system knows how hard that is even if it is centralized.
Now imagine having to deploy an upgrade to a blockchain system, which would require gaining consensus from entities outside of your control. This sounds like a nightmare! Consider further: What if that priority-one defect only affected 30% of all customers, while the majority benefited (say, an error in volume discount math unfairly favors the supplier)? Are we now stuck? Who has the ability to fix this?
Invoking the Rube Goldberg analogy might be a bit unfair. But in all supply chain software I've ever seen, the one constant was the rate of change of the code—developers are constantly churning out new modules, new features and functions, and new defect fixes. And that seems all the more difficult in a blockchain context.
So, from a standpoint of practicability, blockchain solutions are best suited for those supply chain problems requiring fairly narrow and well-understood functionality that is not likely to change much over time.
DATA DISTRIBUTION SOLVES WHICH PROBLEM?
This is the second aspect of why blockchain can amount to a Rube Goldberg device. Today's supply chain systems infrastructure is highly distributed. Each company runs its own information technology (IT) systems. Each has its own data representation. Your purchase order out of your SAP system is my sales order in my Infor system. My carrier's legacy operating system has a data record for the same shipment that sits in my Oracle transportation management system. The distributed nature of the system landscape is one of the main reasons why it's so difficult to collaborate across the supply chain. In fact, business network-based cloud solutions like GT Nexus and E2open were specifically created to move a shared dataset "into the middle" and allow all partners to see and interact—in their respective roles—with it.
So, if distribution is the problem, why all the excitement about blockchain's "distributed ledger"? Well, it's because this is a different type of distribution. It is not the kind we have today, the kind where I have my data, you have yours, and we both have a different version of the data with no inherent synchronization. Instead, distributed ledgers are the kind of distribution where everybody (every node, technically) has all of the data. Furthermore, all of the data conforms to a single representation, all data stores are inherently synchronized in real time, and a "private key" ensures data security (I see mine, you yours). So, although "distributed," blockchain solves the orchestration problem.
Computationally, however, that is a horribly inefficient approach. The centralized cloud-based business network solution is actually far more efficient. If that's true, when would you choose a distributed ledger solution over a centralized one? Blockchain shines when supply chains want to avoid dependence on a third-party authority or system host.
Let's look at an example to illustrate. Let's imagine there was a Facebook for supply chain: "Supplybook," a privately owned company that hosts a giant centralized system, ubiquitously used by practically all companies to run their supply chains, place orders, execute shipments, keep inventory records, and plan production. We use it to "share data" with each other about orders, shipments, and payment. And since it's a centralized network, your purchase order is literally my sales order, one data record we co-own. You change it, I see it. The solution is not without its own issues, but when it comes to orchestration and collaboration, it is the ultimate approach. Except, how do we feel about Supplybook's power in the market, its ability to abuse that power, and our dependence on its service? Not so good, right? And that is what a distributed ledger is designed to avoid. In theory, it provides all the same advantages without the third-party risk.
Depending on the specific supply chain problem, companies may be willing to give up control to a "Supplybook." But in others, companies may be inclined to adopt a more complex blockchain solution if it prevents one entity from having so much power and control.
STARTING A FIRE IN 100 PLACES AT ONCE
As an investor in business software, I meet a lot of visionary people with great ideas. Most of the time, their pitches describe a steady-state, at-scale, to-be scenario. Those can be very compelling. However, often when I follow up with "But how do you get there?" I get a far less compelling answer.
Indeed, I personally think that one of the least discussed (but most important) topics in the area of blockchain for supply chain is this: What is the adoption model? Selling business software is hard, and the more people you have to sell it to, the harder it gets. I would rate convincing a single user to adopt a solution as a one-star level of difficulty. Convincing an entire company to adopt: two-star level of difficulty. Convincing an entire supply chain to adopt: three stars.
Now, I argue that supply chain blockchain is at least **ital{four} stars in difficulty. That's because of the distributed nature of blockchain. Let's go back to "Supplybook." Here we have a group of entrepreneurs with a vision and a clear financial motivation to achieve adoption. They raise capital by selling venture capitalists on the ultimate value, hire top sales professionals, win early customers who "bring" their supply chain partners along—which attracts more capital, more sellers, and more customers. Ultimately, a flywheel effect sets in: Supplybook is successful and goes public. But wait, wasn't one of the benefits of blockchain the fact that there was no Supplybook? But if there is no central third party, no entrepreneurs who stand to benefit from the fruits of their hard labor, who will do all the work and why? That's why I give it four stars.
From what I see in the market, there seem to be two workable adoption models. Both share the four-star level of difficulty. I'll call one "industry-led" and one "entrepreneurial." In the industry-led model, a set of key industry participants come together in a consortium of sorts. Often, they recruit an established technology company as a partner. But the effort is primarily driven by the industry participants, and they are responsible for adoption.
The IBM Food Trust initiative is probably the best example of that. The IBM Food Trust is focused on improving visibility and accountability across the food supply chain. It seeks to provide a shared record of food provenance, transaction data, processing details, and more. Participants include companies all along the food supply chain, such as growers, processors, wholesalers, distributors, manufacturers, and retailers.
IBM develops the technology, hosts it on its own Hyperledger platform, and charges participants a subscription fee. But the trust is governed by an advisory council made up of representative companies. Interestingly, the industry-led governance model alone is what prevents a Supplybook-style control situation, not the technology. What "blockchain" really does here is act as a catalyst, a rallying cry that brings industry players together to unite behind a shared technology initiative. And that's a hugely valuable thing!
The entrepreneurial model is more akin to classic startups. A group of founders with a vision builds an early solution; hosts it on a public blockchain platform, like Ethereum; hires salespeople; and wins early customers. Initially, the entrepreneurs own and manage all the blockchain nodes themselves to keep things simple and innovation cycles quick. But the solution is engineered to allow them over time to "release" more and more—and ultimately a majority—of the nodes to be hosted by third parties that the entrepreneurs have no control over. This will establish trust among all the blockchain participants that this isn't going to become a Supplybook, that no one company has access to all the data and control over the entity.
The tricky part in this model is funding and monetization. Without control over the solution, entrepreneurs can't set pricing. Without that control, valuation of the entity is questionable. And unless the resulting entity has a clear path to an exit (like an initial public offering or sale), entrepreneurs might be disinclined to put in all the hard work. Similarly, venture funding will be harder to obtain with an uncertain financial upside. So, all the benefits the users of the entity seek ("no Supplybook") make adoption all the harder. Again, four stars in difficulty.
The takeaway here is that adoption is crucial to the success of any technology, and it is particularly important to figure out a workable model for blockchain from the start.
WHERE TO GET STARTED?
So, what does all this mean? To me, it means that blockchain is a fascinating technology that does hold a lot of promise, particularly in solving those tricky multi-enterprise supply chain problems. But it also means one needs to truly appreciate how it is different from other technologies and how and where to apply it. Otherwise, its successes will be few and far between.
As an investor, when evaluating blockchain-based startups, I look for some patterns:
- Is there a reason why a simpler, centralized model would be unacceptable? If your problem can be solved using a simpler system, do it. But if you are leery of creating undue reliance on a third party, blockchain may be a good solution. However, you should only resort to blockchain if the centralized model clearly is "dead on arrival."
- Are the business problems that the solution solves centered on intercompany processes? Blockchain is best suited for processes and problems involving multiple parties, such as improving food traceability. That's where you'll tend to get a payoff from the effort required for setting up a blockchain system.
- Does the solution involve simple, well-defined, highly transactional processes with few or no variations? Developing a blockchain for complex processes with variants across geographies and verticals will be tough. You need something simple. Think of Bitcoin: A sends money to B. That's it. It doesn't change. That's the type of situation you need.
- Is there a stable, broadly accepted data standard? Getting all of the business partners to adopt blockchain will be easier if they already send and receive the same data. The fewer different data standards for that transaction, the better.
- How much data does each transaction require? In blockchain, all nodes hold all data. The more data that is held in the system, the more expensive and slower it will be, and the more likely "off-chain" data stores will be needed, which opens up a whole new set of challenges.
- Does the solution have a fairly distributed value proposition for all business partners? Again, this comes down to getting partner adoption. If only one party benefits from the solution, why would the others adopt and comply with it? Brute force rarely works well as a form of persuasion. If all parties naturally benefit, then adoption will go viral.
If the supply chain business problem you're trying to solve exhibits these characteristics, then blockchain is probably right for you. It is an exciting technology, and the journey ahead will likely be more successful in the end.
