One of the greatest pains companies face when they go through Mergers and Acquisitions (M&A) or have multiple instances of source of records for master data is post-merger activities like:
- How to integrate data, both transactional and master data
- How to make sure the Parent Company Financial SLA does not change (period close)
- How to make sure the reporting is right and seamless for the Parent Company so actions can be taken promptly
- How much to spend on effective data integration.
- How to make sure there is seamless experience for the employees who joined the Parent Company (HR, Payroll, etc)
- How to ensure the most valuable asset data, is secure and follows all Privacy regulations when integrating
- How to ensure the current single source of truth is still acting like one after the Acquisition
- How to quickly take advantage of the Parent Company's sales now that they have a new Customer base
Now that we have covered some major issues or pain points, how do Companies handle these issues traditionally?
- Quickly put together the Mergers and Acquisitions Team
- Struggling to figure out what and how it needs to be integrated
- How does my Financial Close affect me? Should we fully integrate or just integrate General Ledger Balances
- Parent Company has good intentions to provide a seamless experience to the Employees, but it does not happen quickly and ends up using multiple tools by the Company
- Spend money to integrate data using traditional point-to-point integrations
End up creating Tech Debt in most cases
If every single problem with Mergers and Acquisitions ends up being a pain point that cannot be resolved, why not address some of the Master Data issues using Blockchain?
Blockchain enables new ways of sharing data across a network of organizations. It can act as a type of database that helps businesses create a new, trusted architecture where they can more reliably and securely share data with different partners and keep track of it.
Types of Blockchains
-
Public Blockchains: They allow anyone to participate as users, miners, developers, or community members. All transactions that take place on public blockchains are fully transparent. It is hard to shut them down for use. Examples are Bitcoin and Ethereum.
-
Private Blockchains: Centralized within one organization or company that controls the rights to view and create transactions. Participation in consensus is permission-based—either every node can join, or only a select few. It is internal to the company and limited to known entities. Example: IBM Blockchain.
-
Federated Blockchains: Federated Blockchains operate under the leadership of a group. This does not allow any person with access to the Internet to participate in the process of verifying transactions. Consensus-based. Known Entities only. Examples are Insurance or Banks.
Blockchain vs Database
With traditional databases, creating unique integrations with each of these organizations is costly and not scalable. With blockchain, every time a node or company is added to the network, it is a uniform process for everyone and
makes it less costly. This is because instead of building integrations, you are just adding nodes or companies that can easily access the database with their keys.
The entire blockchain network serves as a mechanism to automatically verify instead of putting the power in the hands of a central administrator. This leaves little room for error. Once data is saved, it can not be modified, and it becomes immutable. That provides a level of trust that a traditional database does not offer.
Master Data Management on Permissioned Blockchain
- Need a consistent data framework for heavy and commonly used Data
- Need multiple Sources of Record (SSOR); Application/Entity
- Need multiple Entities Involved via Enrollment Certificates
- Need multiple users/applications need access (credentials)
- Need entities need to be governed by Rules or Access
- Logging of changes required enables Transparency & Auditability
- Cannot be Publicly Accessible
- Use Cases for Master data like Customers, Suppliers, Employees, etc.
- Eliminates complex reconciliation between Mergers and Acquisitions
- Mergers and Acquisitions have the option to choose to keep a local copy or use one of the existing copies
Sample Implementation Flow
This is one potential high-level implementation approach, and there could be other ways to handle minor details using blockchain. The goal here is simply to illustrate an idea. As everyone knows, taking an idea to implementation involves creating the blockchain itself (arguably the easiest part), but we also need to take the following considerations into account:
- What verification rules govern the creation of Master Data?
- Who can consume in read-only vs the creator of data?
- Whether or not Acquisitions of enough capability or computing power to handle their own copy of data or just use one of the existing nodes
- How does it change for the Historical data, especially if we are creating a unique blockchain identifier?
- How can we turn our applications and integrations to start reading from Blockchain?
Thanks in advance for your thoughts and feedback.