As many of us who follow the distributed ledger space closely know, the market has grown accustomed to blockchain-based supply chain builds. This is for good reason, be it that while a portion of manufacturers are vertically integrated, many aren’t and instead seek a more secure solution to mitigate their reliance on a number of procurement and value chain actors fulfilling certain functions. Blockchain has entered the stage in the past few years as a way of bringing accountability to the chain-of-custody for raw materials and finished goods as value transfers through the supply chain. This nascent technology has spurred a race for pioneering, with corporate giants like IBM and Walmart taking it upon themselves to craft up proprietary versions, blockchain supply chain firms arising to deliver custom-fit solutions to enterprise, and even SaaS products hitting the stage through established blockchain names and supply chain tycoons alike.
Despite all of the movement on the product side, companies can find themselves in a bit of a standstill when it comes to assessing the return on investment from a blockchain-based solution. Nobody likes a money pit, and we’ll be the first to admit that if a blockchain solution doesn’t provide a clear value proposition: don’t implement it. On the other hand, there is an abundance to explore in the distributed ledger space when it comes to consensus mechanisms, data structures, encryption standards and the like, of which researching them can evoke new creative ways to implement a seemingly black-and-white solution. Whatever consideration stage you might find yourself at, we’ve drawn up a few tips to consider when deciding upon how to implement your supply chain solution.
Train your Employees
In spite of all of the hullabaloo surrounding the merits of distributed ledger technology, there seems to be little focus from the product or customer side on training employees about the practical conventions and actions required for implementation in the enterprise. Across a broad range of employees with varying levels of technical expertise, tailored training guides ensure that devices procuring data are all properly maintained and that supervisors are able to mitigate the user error of their employees upon the immutable ledger. The contracting of third-party services for assuring a certain level of distributed ledger subject matter expertise in midsized to large organizations will be critical for long-term upkeep and maintenance.
Have Multiple Ledgers
In the all-too common sensationalism from media outlets reporting, one implicit assumption that has pervaded the space is that blockchain needs to be a replacement for your current network’s data layer. In reality, the distributed ledger data layer can serve to complement your existing data layer through the use of a “one-submission, two-records” model.
Consider the instance of a supply chain where management has decided that they want to add an additional data layer to their system for greater security between their shipping dock and warehouse. Traditionally, the company has always had their NFC telemetry devices automatically detect a shipment of parts coming into the dock and transfer that information to the warehouse staff who would then offload the palettes of parts and organize them to desired locations within the warehouse. Because this company is a large proponent of automation and streamlining warehouse processes, Internet-of-Things devices, Robotic Process Automation, and Artificial Intelligence supplies a lot of the legwork in manually moving palettes, where the human laborers have more of an oversight role.
One day, a data breach from an outside, unknown attacker transpires that has management worried that many of the Internet-of-Things devices may have been compromised. In replacing the devices, management has decided that they want a blockchain solution implemented that records that data exactly as it is initially procured without worry that the data will be altered retroactively.
The problem with this, management soon realizes, is that if an IoT device or machine malfunctions, incorrect data will be locked in place that will have to have corrections appended later (as with blockchains you cannot amend the data). Given the lack of proper block querying solutions available, management realizes that the internal audit department will have a very tough time actually going back to review hundreds of thousands of database fields, in the blockchain itself, showing real-time warehouse telemetry data. With this in mind, management has opted in for a one-submission, two-record model, where every time an IoT device submits data, a record of that data is sent to the blockchain, as well as a record sent to the company’s traditional database. This provides the company’s audit department easy filtering and review of IoT data so that they can make corrections as needed within the company’s traditional database, that they can submit to management to which management can append to the blockchain.
In this situation, multiple ledgers provided both the data procurement roles and auditing roles to function unabated and concurrently, providing data oversight without having to stop the real-time retrieval of IoT data. While depending on the rate of the data flows, a singular blockchain solution might not be viable, and may require additional chained-blockchains or otherwise an implementation using a data structure with higher throughput, the point is that multiple ledgers can provide support for complementary, interdependent processes in a way that a singular ledger may not.
Couple Your Refund Policy with an Encryption Time-Lock
Anybody who has ever bought or sold a product in the developed world has an understanding that a sound refund policy is a key enabler for continual commerce. With product manufacturing of widgets often times outsourced to countries where labor is cheap, quality can sometimes vary between different foreign suppliers of parts. As parts break unexpectedly for the consumer, it is common for the consumer to expect reparations for unmet quality over a short duration of time. This expectation of an exception outside of the traditional transaction workflow directly contradicts the nature of a blockchain, which heralds immutability of data: which in this case refers to the fact that through the sale, the company’s product supply was decremented by one and that their revenue was incremented by x.
To account for the occasional product return, companies that have implemented a distributed ledger to record transaction data should only have the data embedded onto the ledger if it is finalized or otherwise willing to be appended. In the event that the company doesn’t want an “append” policy, and wants to just stick with a policy whereby the data that is shown is the correct version, the company should seek to match the end of the time frame permissible for refunds with when the data is locked onto the distributed ledger. For instance, if the refund policy is 30 days, the sales data will officially be locked into the distributed ledger once the thirty days from the transaction has elapsed. Once this occurs, the sales data cannot be changed, but has no reason to be changed, given that the refund grace period has ended.
Maintain Open Dialogue With Your Channel Partners About Distributed Ledger Technology
One of the biggest hangups for companies looking at integrating a full-scale blockchain supply chain build is the uncertainty about whether their supply chain partners would be on board for replacing the current operation with one that includes a blockchain-based data layer. Because set-ups involving collaboration from multiple different organizations are prone to deadlock, typically one organization is in charge of organizing the network while other participants maintain additional nodes. While the conversation about transforming supply chain partners into network participants can be a tricky conversation to have with your channel partners, it’s recommended that the conversation is had at the early stages where your company is exploring distributed ledger implementations. As time goes on and the benefits of a federated network between supply chain partners becomes more clearcut, the increased exposure of the value proposition to the supply chain partners may sway them toward considering a joint venture implementation.
Devon Rusinek is a research analyst at TxMQ’s Disruptive Technologies Group. He enjoys studying and commenting upon topics within the distributed ledger space including tokenization, micropayments, and supply chain management. LinkedIn Twitter