In science fiction movies and television everyone speaks English.
Often, there is a convenient poetic device called something like the “Universal Translator” that enables beings from wildly different backgrounds to communicate. Human Being H can speak to Vulcan V. Through some magic, H hears English and V hears Vulcan.
How boring would shows like Star Trek be without this gadget? Conversations would take forever if they took place at all. It would be impossible to have an in-depth discussion. There would be no inter-planetary cooperation. Different species would be stuck in their own worlds, resigned to progressing at their own pace.
Instead, in these shows, science and technology spread like wildfire. Races leapfrog to a condition in which there are no economic constraints. Virtue is the only true currency.
Different planets that can work together to exchange ideas and techniques are “interoperable.” Earth can benefit from what Vulcan knows. They share value without the need for some third party to intermediate. Progress is instantaneous and widespread.
What Is Interoperability?
In a military context, some tanks have phones located on the exterior in the back.
The phone enables the infantry to operate in company with armor. Soldiers outside can coordinate their activities with the tank crews inside, exchanging information about shifting battle conditions. With this ability to communicate, both the infantry and the crewmen can be more effective than they would be on their own.
Of course, we’re not soldiers. We are interested in making widgets and getting them to market as efficiently as possible. Supply chains help companies acquire the goods and services they need to assemble their products and to distribute them once they’re ready. Procurement is the first mile of the supply chain: figuring out what inputs we want to purchase, from whom, and at what price.
Logistics refers to moving things from point A to point B, potentially storing them along the way. It is a downstream function in the supply chain but the logic is just as relevant.
For a simplified example, a widget manufacturer must ship his final product from his plant to the customer’s factory across the country. This might involve one local truck picking up the load from his plant, storing it in a facility just outside of town, adding it to a large load in a truck operated by a national firm, trucking it across the country, dropping it at a storage facility in the customer’s town, and delivering it to the customer.
There is the manufacturer, the customer, local trucking companies (in each city), the national trucker, and a freight forwarder, at least. All of these entities have different technologies. These groups have their own roles, business models, and technologies, but they must suss out a way to cooperate. The widget manufacturer needs to engage these various organizations and track the package as it travels across the country, i.e., as its data changes state across diverse technology platforms.
Here is one definition of interoperability then:
“… interoperability means that independent companies can share information and work together.”
The various players form a system. If they can collaborate, the system can reduce costs and shorten cycles. The goal here is to ensure that the information each possesses individually finds it way into the hands of entities that can use it to improve outcomes for all.
Here is another definition:
“… interoperability refers to the ability of independent … networks to mutually conduct operations and business with one another, in order to use functionality of other networks, or to execute operations for others …”
Fleshing out the concept, we have multiple networks of counterparties.
Using another military analogy, consider the Standing NATO Maritime Group 1.
This is a force made up of ships from different NATO navies. Each national navy is its own network. Ships within a navy have the same standard operating procedures (business model) and technologies for communicating with one another. SNMG1 is a network of networks. It is a group of ships from different navies that must interact with one another for a common purpose. The communications protocols must enable the transmission of data across disparate systems in a physically demanding environment in pursuit of a common objective.
This is true interoperability.
Imagine now that we have a construction project that involves multiple players including architects, engineers, construction managers, design consultants, manufacturers and material distributors, suppliers of major plant and equipment, systems companies such as HVAC specialists, construction companies, etc.
Perhaps the engineers, architects, and designers exist in one network, while the manufacturers would be in another and everyone else in a third. Even that is simplistic. But a building project can benefit from interoperability. They all need to have a dynamic picture of the constituent parts of the task. This translates to sharing data and functions for interacting with it.
Operators aspire to visibility that is challenging to obtain. But what they covet is interoperability.
Procurement visibility is the ability to peer into this chain of suppliers and to understand the risks at each level and the links between consecutive levels. Individual links can fail, surprising those at the top and imposing cascading complexity across the chain. Interoperability in a procurement context means that there are myriad links between and across levels. People at every link communicate with and understand every other link. There are fewer surprises. When failures arrive, the consequences may be less complex. Entities at all levels communicate with one another to reduce downside risk, lower costs, and accelerate timelines.
Why do companies have different systems?
To extend our construction analogy, companies have different needs based on the problems they solve and the resources they employ. We would expect architects and developers to have similar systems. We wouldn’t expect an architect to have the same system as a small HVAC operator working on site every day in the same way that we wouldn’t expect a policeman to use the same communications technology as a subway operator.
Why Don’t We See Interoperability in Practice?
There is a free-rider problem. Consider three people: Alice, Bob, and Charlie. Perhaps each of them is investing in the same company, so they decide to compare notes. Alice is diligent and she knows everything there is to know about the company’s business model, its financial statements, the quality of its management team, and its product. Bob worked in the same industry as the target company for years and is now an investor, so he has a nuanced understanding of the company’s competitors. Charlie has done some work, but he is not as up to speed as the others. There are gains from trade between Alice and Bob. Alice can learn about things she didn’t know, enhancing her investment picture. Bob can improve his understanding of the risk-reward tradeoff, too. However, when it comes to Charlie, neither Alice nor Bob learn anything they didn’t know already; it is Charlie who benefits disproportionately. In this case, we say that Charlie is the free-rider. He is better off for being part of this study group, but he adds no value on this particular trade.
Alice doesn’t know what Bob and Charlie know until they have the conversation. It could be that she’ll be better off for it, or not.
In the procurement context, some buyers may be more informed than others similarly. They may not gain anything by sharing their knowledge if they are speaking with a Charlie. Or they may be better off if they happen to speak with an Alice or a Bob.
All of this starts to wash out as Alice, Bob, and Charlie discuss more and different trades.
Let’s say one of the reasons Charlie doesn’t have much to contribute on trade A is because he has been spending much of his time on trade B. It could be the case that he can add tremendous value for Alice and Bob on B, even as Alice and Bob teach Charlie about A.
If Charlie makes a great trade in situation A, in part because of Alice’s help, she sees no apparent benefit. He doesn’t share his profits with her.
However, the correct logic is for Alice to think that it is in her interest to help Charlie today because he may help her tomorrow on some other opportunity. Everyone brings something to the table, just not at the same time.
This leads to a second problem: the legacy approach. One reason procurement groups from different organizations may not share information or opinions about a particular category is that, well, they never have. There is a procedural inertia that discourages doing things in a different way, as if to say, “If this is such a great idea, why hasn’t it been done before?” Every innovation has to confront this complacency.
What’s worse, people may be stuck using legacy systems that lack the ability to share data with other systems easily. If it’s even possible to bolt on this functionality, it may be expensive.
Security is the third biggest obstacle. How does Alice know that Bob and Charlie can maintain the confidentiality of her data when she shares it with them? What’s to stop Charlie from sharing Alice’s data with one of her primary competitors, giving them insight to a critical thought process? How can she control who sees the data and when they see it?
Apathy is the fourth and biggest cultural obstacle to this kind of transformation. Nobody begrudges the Chief Financial Officer tools such as enterprise resource planning tools; it is understood to be vital for the performance of her function. It is beyond question that the sales and marketing department needs a customer relationship management system and that the engineers need design and testing tools.
Too often, though, procurement doesn’t get the respect it deserves. People expect the role to make do with email and spreadsheets or legacy systems. Or leadership argues that it is too central an administrative procedure to contemplate transforming. Muddling through is the default. It would be like asking someone running a marathon to undergo heart surgery. Is it really necessary? Right now?
One way to inspire a sense of urgency is crisis. Recent years have had no shortage of travails: trade disruptions, Pandemics, war.
Heart surgery is necessary when you’ve had a heart attack. Another reason for having heart surgery is when you’ve been diagnosed with a bad buildup of cholesterol in your arteries.
A core driver such as tight timelines or the need to incorporate social procurement into your standing processes can inspire a real sense of urgency. If your boss tells you that you need to deliver a critical procurement project or a division will miss its revenue target in two quarters, but you’re four quarters behind, then you’ll be more open to alternative ways of making things happen.
Perhaps you don’t need open heart surgery.
If you can de-risk transformation with less invasive treatments such as stents, then that makes it easier to implement change. In a procurement context, you start out small and build your network gradually. Networks don’t appear overnight; they build exponentially. That is, they emerge slowly, slowly, then quickly.
Distributed Ledger Technology Overcomes These Obstacles
How can we overcome these four obstacles in an enterprise procurement context: the free-rider problem, organizational inertia, security, and apathy?
The solution is to engage people with trusted, proven innovation. The power of novelty is the spoonful of sugar that helps the medicine go down.
In this case, the sweetener is a particular type of distributed ledger technology: a system for verifying, storing, and sharing synchronized data across multiple users. It must bring reliability, scalability, and security, but in a way that lets the user control transparency, all while permitting integration with existing and future enterprise applications. Done properly, this leads to the organic emergence of networks within the organization and across organizations. It cannot rely upon cryptocurrency; such an arrangement is expensive and fraught. The model solution must be parsimonious in its execution. Ideally, it can handle a massive stream of transactions continuously, not in blocks, making it more compatible with existing technology architectures. Doing this brings the benefits of interoperability: lower downside risk, faster spend cycles, and reduced costs. This is what the Known distributed ledger technology provides when used with EdgeworthBox’s sourcing approach.
Interoperability Is Feasible and Affordable
Interoperability is familiar, at least conceptually, if not practically, in logistics. It is a much less prominent feature in procurement despite the promise of significant benefits. There are a number of cultural and organizational obstacles. The marriage of a distributed ledger technology such as Known to a compatible procurement system like EdgeworthBox overcomes these challenges to deliver significant value.