Written by Rajat Agrawal, (Platinum Consultant, SAP America) and Rahul Ranjan (Senior Consultant, SAP America)
With all the hype and expectations, blockchain technology for multi-enterprise collaboration is still in its innovation stage. Companies ranging from startups to established technology players are working quietly and productively on the various aspects of this technology. Hyperledger Fabric, Multichain and Quorum are few such initiatives. SAP is a partner to such permissioned and enterprise grade blockchains and provides services for developers to integrate and build blockchain applications.
As organizations are looking beyond enterprise boundary to connect entire value chain for competitive advantage, they are realizing limitations of EDI. This brings technologies like distributed ledger, smart contracts (chain code) into focus to drive cross-company automation and collaboration. Developers and managers are exploring ongoing innovations in this space and evaluating the potential of blockchain technologies like Hyperledger Fabric, Multichain and Quorum. Most often, as they reach a high-level design or a working prototype, a realization starts coming in on much increased complexity, privacy concerns and high cost. A conclusion that has CIOs challenged on how to invest on business-to-business collaboration.
The answer most likely lies in applying blockchain principles to service increasing and changing business partners and to orchestrate process automation at the same time. With some experimentation on integration aspects between ERP and blockchain technology and utilizing just the components that solve business problems, a viable platform can be formed. It is expected that success of such unique use cases will prompt the members to expand the scope and scale the platform. Re-use of such use cases will bring broader participation and drive increased adoption.
EDI and limitations – A common scenario
Manufacturing scenarios include procurement of raw and semi-finished materials from different vendors followed by manufacturing operations, third-party storage and associated transportation. Let us review one such process to understand how few underlying transactions multiply and propagate across multiple organizations. The multitude of these transactions result in transactional overhead and delay in individual contract settlement.
In this scenario a vendor processing plant (company A) moves semi-finished product in bulk to an end-product manufacturing unit (Company B). The final product is moved to a third-party service provider (company C) where inventory is managed and sold to customers of company B. Stock movement involves transportation and the freight contract is with a transportation company (Company D). The transportation company acts as an aggregator and relays the individual shipments to different trucking companies to supply the trucks.
The interaction in this scenario is typically based on several Electronic Data Interchange (EDI) messages, a common framework for electronic communication between businesses. The connection is partner to partner and designed for each paper transaction between different organization pairs. Each EDI message is independent, an advantage when confidentiality is a key criterion, e.g. payment advice. However, it is not a mechanism to validate and orchestrate automation into the entire supply chain. EDI based architecture is therefore always filled with additional integration opportunities and pain points. Key improvement topics in the highlighted scenario are:
- Payment terms – For the stock move from processing plant to tolling unit, freight is paid after verification to transportation company first. Subsequently the transportation company makes the payment as per its contract to the trucking company which placed the truck. This cycle takes more than a month for settlement amount to reach the trucking company that incurred the transportation expense. Similarly, payments are made on a monthly cycle after the transactions are reconciled to tolling unit and warehousing service provider. Automation of payment chain with trusted underlying transactions can significantly cut down the lag in payment cycle.
- Inventory reconciliation – Inventory is reconciled for product between the inventory management system of processing unit, tolling unit and warehousing service provider. A manual exercise at month end which can involve a lot of effort on each side. A connected process chain across organizations can automate this key exercise and provide insights to improve inventory management.
- Invoice Matching – The chain of transactions lead to a pile of invoices to be reconciled with underlying transactions. A largely manual exercise involving workflows and reviews before an approval is set to make the payment.
- Process Agility – Lack of synchronization leaves the co-ordination manual filled with administrative overheads and failure points. An end to end connected process chain provides flexibility in dealing with frequent changes and improves response time. It reduces errors and associated delays – a key differentiator in customer service.
Blockchain Technology – Solution and Shortcomings
Hyperledger Fabric is one of the enterprise grade blockchain technology. It was conceived to provide the foundation for enterprise to enterprise data processing. The services on this open source platform come with a modular architecture and provide secure and trusted communication which is a key characteristic for enterprise use. The goal is to provide a single source of truth across enterprises – a key weakness highlighted in the above process.
Hyperledger Fabric platform provides the ability to define and build networks catering to the needs of a specific process. The architecture allows for scalability in the same manner it was built originally, via peer nodes. Being process specific, it is observed that it allows to scale initially but in-the-end leads to a bigger silo.
Peer nodes can be provisioned on SAP Cloud Platform or any other cloud platform of choice (E.g. Microsoft Azure) to drive collaboration and build further on top of it. SAP Blockchain Business Services can be used to replicate blockchain data from and to SAP HANA database. This provides seamless information for analytics with data inclusive of internal and blockchain transactions.
Scenario with Hyperledger Fabric
Let us review the logistics scenario described earlier with Hyperledger Fabric. There are seven organizations involved and below picture depicts a network view of the consortium and the transaction flow among all these parties.
Every transaction that is crossing an organization is making an entry into the distributed ledger, which becomes a permanent ledger record. The distributed ledger in such scenarios is de-centralized and each member on the network is pre-authorized and validates the applicable transactions on the network via consensus protocol.
The architecture model to map this scenario and interactions in the process lifecycle between the consortia of companies based on Hyperledger Fabric is represented below:
A logistics channel largely representing the product flow across the consortia is the main channel in this scenario. Accounting interactions based on pre-defined rules and agreements, also known as smart contracts or chain code are represented on a private channel. This channel holds sensitive and private information for a subset of organizations, e.g. pricing information for the transaction, tariff rates and product details. Another network is the tendering channel which is used by the transportation company to bid on the routes for product movement. It engages the various freight providers and is used to privately share bidding, tendering and settlement information.
The process beings with a manufacturing company placing an order with the vendor company. The order details are transmitted via logistics channel. The detailed information is encrypted and is shared using a secured digital certificate signed with a private key. This information is available only to vendor company which decrypts the received information using a public key. The vendor company in turn provides the acknowledgement and confirms the availability and estimated delivery date via the same logistics channel using its own digital certificate. This information will be available only to the manufacturing company and transportation company. The transportation company processes the details and transmits it to a tendering channel which is a different network. In this network, the various truck providers submit their bids and vehicle availability for each published route. Once the truck provider is confirmed on this channel, the transportation company submits this information back onto the logistics channel to inform the vendor company and the manufacturing company about the transportation detail.
In this scenario, the vendor company is responsible for the transportation to the manufacturing plant. As soon as the shipment is delivered and shipment confirmation is provided on the logistics channel by the manufacturing plant, it is verified by the vendor and trucking company. The trucking company may do so by first confirming it in the tendering channel so that it can be validated by all the concerned parties to become a part of immutable ledger. This is a key verification step which provides the potential for automated settlement on different channels. The logistics channel will execute the settlement for the product received via chain code. Similarly, the transportation and the vendor company will also execute their chain code to settle the freight charges. The process also extends to the tendering channel where a different chain code is processed to settle the truck charges between the tendering company and truck provider.
Complexity and Privacy Concerns
The reliance on distributed database increases the data footprint significantly. In a scalable blockchain platform, due to replication, data throughput can increase exponentially. In the example above, logistics channel (main channel) holds majority of transactional data. Availability of organization data outside, even though it is encrypted and secured, creates ongoing security and confidentiality concerns. The channels are defined based on partners and not based on the process. The logistics channel in the previous example may decide to introduce additional truck owners and remove few based on performance. This is not possible as the channel definition is based on partners.
A complex process wiring, potential for un-limited data growth and static partners hinders re-use of the construct for multiple use-cases. All of this together make it difficult to justify the investment, ownership and return-on-investment.
Focus on business value – finding the right technology balance
Cross company integration is not a matter of choice. Optimization across company boundaries and fully automated business processes are essential. Enterprise grade blockchain technology must be used, but success will be defined in consuming and integrating it the right way. Blockchain needs to be looked with a minimized distributed database. Immutability can be introduced in the underlying transactional asset by exploring the concept of Notarization and Tokenization to determine asset ownership. This allows storing only the hash of the document on a distributed database. And using a peer-to-peer network for sharing the actual documents.
The concept of decentralized consent management should be explored to make the data available via easier means (e.g. URL on internet) without replication thereby avoiding unlimited growth of data. It is a controlled and auditable way of sharing required granular data only vs providing entire data on the channel. It provides a controlled and auditable way to grant and revoke access for the data owner.
Smart contracts allow decentralized business rules and they can be used to define functionality through tokens. The approach should be to use smart contracts with notarized information to trigger processing logic within the ERP system thereby avoiding re-building and exposing the entire processing logic on an open infrastructure. E.g. Payment advice can continue to be transmitted via existing EDI framework and need not be exposed to smart contract.
The application of blockchain technology only at the intersection of cross-company processes will significantly increase transaction speed and throughput while lowering transactional cost. It also allows greater re-usability across use-cases.
Blockchain use case identification
Organizations evaluate their processes periodically, particularly as it relates to maintaining competitive advantage in the marketplace. Process improvements that involve interaction between multiple organizations become early candidates for building a blockchain platform. Volume of transactions, complexity of process and automation benefits are some of the key criteria to further shortlist the ideas and identify a viable candidate.
SAP Cloud Platform Blockchain Services allows development of blockchain scenarios. The development leverages enterprise grade blockchain technologies to map with the process requirement and build a blockchain which is integrated with SAP S/4HANA (Cloud or on-premise) landscape. Some amount of experimentation will be required as new business models and standards are built with this service. Organizations and consortiums taking the lead will tap the value first in reducing operational cost and increasing automation, and will define integration standards for others to follow.
