Building a Single Source of Truth for data in an Industrial OEM organization

Building a Single Source of Truth for data in an Industrial OEM organization

  • Organizations need a unified view of data across all functions to do reliable and effective  decision-making at scale.
  • Can an organization pick any one of the ERP or CRM systems and designate it as a single source of truth? Are there alternatives/better ways to do it?

Data is the new oil but to harness the power of the data it needs to be extracted  from various systems and needs cleaning, unification and enrichment. Creating a single source of truth from disparate data sources across an organization powers many critical use cases by bringing more accuracy and enabling execution at scale.

  • Enabling a rich, single view of a customer to drive a better customer experience. Segmenting the customer base on clean data drives better identification of at-risk and growth-potential customers.
  • Rich single view for vendors which drives better negotiations.
  • Other use cases which include
    • New equipment sales to existing customers
    • Aftermarket revenue opportunities both of prescriptive and predictive types
    • Pricing analytics for both suppliers and customers
    • Better insights to do inventory management

The effort to create a single source of truth is broadly categorized as Master Data Management (MDM).  We see the following major approaches that organizations are taking to create the source of truth.

Let’s look into the pros and cons of each.

Qualify one of the systems as the custodian for the single source of truth 

Some Industrials are making their CRM system as the master source of data and some pick ERP. Sometimes they have to pick one of the many CRMs or ERPs that are existing in their organization. 

Pros

  • A big portion of the data is already residing in the system and only additional data needs to be pulled in. 
  • A part of the organization is already comfortable with the system.

Cons

  • These systems are primarily workflow systems so there is bias inherent in the data with respect to the core workflow of the system.
  • Extending the  data model to cover other  business use cases requires extending the native data model of the system in ways that are not amenable to that system. CRM systems out of the box are not so good at handling historical transactional data in volume. Even capturing all the data points of an asset including analytics/AI view will stretch the data model in unknown ways which creates friction and worse may impact core workflows. For example, a data point for an Asset that is crucial for certain analytics –  making it mandatory for CRM workflows may create friction.
  • Total cost of ownership to enable this in one of the large workflow platforms (CRM, ERP, etc) can become an issue if it needs to be rolled out to the complete organization to cover different business use cases.
  • Ownership of data can become an issue in the longer run especially when there are new system integrations (driven by inevitable acquisition) or migrations to new systems.

Assemble all the data in a data-lake/warehouse 

In this approach, a data lake/warehouse is designated as the custodian of a single source of truth. Data from every source systems is pulled into the data-lake

Pros

  • Data is treated as first class citizen and does not carry a bias of serving a certain workflow.
  • Provides better ownership of data to the organization compared to leveraging one of the workflow systems.

Cons

  • The problem that we see today is data gets pulled from various systems and “dumped” into a data lake without any semantic processing or cleansing. Imagine multiple files, each representing one of the source system data. Data managed in this way is as good as data sitting in individual systems unless unification and proper linkages of various data points is established. Data would also need deduplication and enrichment. A data point having two conflicting values needs to be resolved otherwise the inference might just point in the wrong direction. This requires investment and continuous maintenance.  
  • A rich open data access layer is needed on top with filter capabilities so that various functions can pull the data as needed. Lack of that makes this investment sub-optimal or down the drain. This requires investment and continuous maintenance.  
  • Low investment upfront but high maintenance cost year on year as it now needs maintaining a specialized function/department whose job is to continuously evolve and maintain such a system.
  • Requires specialized skills in building large systems, writing connectors to various source systems, data science capabilities to put cleaning/deduplicating, analytics and other algorithms. Skills around devops and deployments are critical to maintain the system and you are now competing for resources with Silicon-Valley type startups.

Off the shelf data platforms

Multiple data platforms currently exist in the market that range from general purpose horizontal systems to purpose-built verticalized systems.The key to success here is to pick a system which is as close to the domain as possible. Horizontal systems are more open and cover a lot more use cases but may take a lot of time to get it right. Verticalized systems are very focused, but if it is missing your core use cases then that system is not a good choice. A vertical system close to your domain but having flexibility to adapt to a certain extent is an optimal choice.

Pros

  • Shorter implementation cycles enable early ROI as the systems have the required blocks already in place in terms of connectors to ingest the data. Data models validated across multiple customers with required flexibility to tweak that help in serving specific use cases.
  • These systems have well developed data access layers in terms of APIs, UI interfaces, mobile readiness  and other mechanisms to sync/propagate the data to other systems.
  • Maintenance and continuous development is handled by the vendor of the platform. Economies of scale and experience enable best practices to be adopted after evaluating use cases across the customer base.

Cons

  • Initial investment upfront and year on year subscription fees. A ROI analysis should be done with respect to building it internally and maintaining a team with incorporating the payroll and other development costs including infrastructure to deploy.

 

Summary

A single source of truth should be built intentionally and not as an afterthought around one of the workflow systems. Strategic buy-in is needed at the highest level as there is a significant up front investment. The ROI though will be multifold and will make decision-making reliable and effective in various business functions of the organization. The system should also be maintained on a continuous basis so that value from clean and unified data is delivered continuously. 

Are you trying to build a single source of truth for your Industrial Organization? Contact Us to learn how we can help you!

Scroll to Top