Business Trends
Use Case: Blockchain to Eliminate Reconciliation
Hello! My name is Rudy Subramanian, a Cloud Platform Solution Engineer at SAP, and also a blockchain SME and emerging technology enthusiast. Prior to joining SAP, I worked in investment banking and held finance roles in the healthcare and utilities industries.
Recently, one of our Consumer Products (CPG) customers came to us with some reconciliation issues in their supply chain, given their complex and matrixed ecosystem of bottlers, distributors, national retail chains and other business partners.
In this document, we will understand how that customer worked together with SAP to develop a blockchain-based solution to alleviate problems with distributor delivery reporting.
Find an illustration of the business process below:
Foodservice distributors buy fountain products in bulk from syrup plants and receive into their warehouse inventory. Subsequently, they deliver these fountain products (in addition to other dry goods and products) to customer stores (a restaurant, a hotel, etc.).
Today our CPG customer pays the distributor for reporting the store delivery order information back to them. A third-party company processes the distributor’s data and subsequently sends the information to our CPG customer, where it is consolidated with all sales information into a very large database. This database is leveraged by our CPG customer’s account teams and financial analysts to assess business performance, reconcile against contractual terms, etc.
There are several opportunities for improvement:
- Reduced payments to distributors for sending data
- Reduced processing costs
- More accurate information, with reduced reconciliation effort
The trading partners (distributors and end customers) can be incentivized to participate as well. The industry primarily runs on trade promotions, so the CPG ‘settles’ based on secondary sales data. Data aggregation, necessary for this process, currently takes months, so the promise of faster settlements should incentivize participation. Furthermore, (food and drink) product traceability is becoming increasingly important for end customers.
In less than 4 weeks a small, dedicated team from SAP worked with our customer, to understand their business process and build out a functional proof-of-concept utilizing the SAP Cloud Platform Hyperledger Blockchain Service.
It is important to understand that while a blockchain-based ERP might be possible years in the future, blockchain today can only be implemented as a complimentary technology to enterprise software systems. ERP is still the most efficient way to run your business operations internally. However, blockchain technology can be implemented to enhance trust and security when interfacing with external entities in a given business process. In this case, we are enhancing our customer’s core ERP (ECC/S4) system with a blockchain solution deployed on the SAP Cloud Platform. And thus, native integration to enterprise systems becomes crucial to a successful blockchain implementation.
Keeping this principle in mind, with our proof-of-concept, we were able to demonstrate:
- How Hyperledger channels can be utilized to maintain appropriate data privacy between all ecosystem participants.
- How a federated master data, through integration, (with the full master data maintained in MDG or Informatica) can be maintained on the blockchain to create a single source of truth for all appropriate product and store location information.
- Smart contract validation against the federated master data ensuring there are no data entry errors regarding product or location.
- Native S4 integration, showing how the post good issue (PGI) process within ERP can trigger a blockchain transaction. This means that no additional UI build is required, nor additional training or steps for the customer’s employees. Blockchain can be implemented quickly, with minimal effort, to work seamlessly in the background with no effect on the front office, by enhancing the digital core.
- Smart contract validation against previous delivery information stored on the blockchain to greatly reduce reconciliation problems. For example, secondary deliveries are validated against primary deliveries to determine if appropriate inventory is available.
- UI5-based analytics tables that read data directly from the blockchain to display the most up-to-date, error-free data for human consumption.
The HANA blockchain service can also be utilized to import blockchain data into the HANA platform for more advanced analysis. We are currently working to develop this use-case further, as multi-party reconciliations are problematic in many different industries.
I will continue to stay up-to-date on the state of blockchain, both in general and specifically in public sector, and you can expect future blog posts from me regarding new developments within this space, both from a technical and business perspective. Please reach out to me with any questions or new ideas!
Hi Rudy,
by Hyperledger channel i'm assuming you are referring to fabric channels and by S4 integration you mean swapping level/couchDB with HANA database. what is your chaincode SDK: go, nodejs, java or some other programming environment?
imho, this solution will never eliminate the need for reconciliations but rather make the reconciliation process more complicated by adding complex security requirements for reconciling the data on and off the blockchain.
Thanks, greg
Hi Greg,
Hope that helps!
R
Hi Rudy,
thank you for replying with the details as sometimes it's hard to get responses and/or confirmations from blog posts. in any event, if we were to continue with fabric, were you using fabric-ca out of the box or was it modified or even better was SAP id incorporated somewhere along the way? i'm assuming that if HANA was not in the mix, then you ended up persisting on LevelDB or CouchDB, but were not including postgres anywhere in your POC landscape. I hope this clarifies both security and databases a little bit more.
Thanks again, gm
Hi Rudy,
gr8 blog, never worked in this industry so a bit lame with the process. Any help on the following is appreciated:
Whose master data here is set onto Blockchain, CPG Manufacturer or Distributor(am guessing this one) and depending on the answer does it not complicate reconciliation further. Also, Why would the supplier be interested in the store information and why would the Distributor reveal its store/customer base, unless the whole supply chain works on profit sharing basis..
What would be the approach to handling failed transaction submissions from GI in S4 and also reversals and returns wherever applicable in S4.
Regards,
Sitakant
Hi Sitakant,
Let me try to address as best I can -
The master data is maintained by the appropriate entity - product SKU, etc. by CPG, store locations by the distributor or end customer. Remember when I say 'master data,' that it is simply a partial federated master data to validate transactions posted to the blockchain.
The industry works primarily on trade promotions, so the CPG 'settles' based on the secondary sales data. The CPG also needs this information for their account teams. There is a big delay in settlement because data aggregation is required and takes a long time. Faster settlement should incentivize network participation. Remember that this data aggregation is already taking place, except a third party provides this service for a fee.
I am primarily a Cloud Platform SE. I am neither an expert on this industry, nor S4 processes, so if you need more detail, we can touch base with the appropriate colleagues. Also please keep in mind, that this is just a PoC. As discussions become more serious, I am sure we will have additional insights.
Hope that helps!
R
Thanks for that explanation Rudy. Did have a bit of read and the use case makes sense now 🙂
Regards,
Sitakant.