From Silos to Consolidation

From an enterprise applications perspective, most businesses continue to wrestle with the complexities of siloed data. It's the modern-day equivalent of Hercules’ battle with the many-headed serpent Hydra, with less blood-letting.

Valuable information resides in multiple systems, typically with zero integration. Who or what is the custodian of ‘one version of the truth’?  This burden of ownership usually lies with the finance department, which often has no direct control over key data sources, such as CRM.

And staying with our beleaguered finance colleagues for a moment, their efforts extracting and reconciling data from disparate channels often go unseen. Picture this; hours of toil have been devoted to the board’s ad-hoc request for a report for March. This is casually followed by the request to ‘run off’ the same report for February. Cue dark eye circles and even darker mutterings.

An Adaptive Technology Model offers the opportunity to not only transform a business, but to enrich the roles its employees play in its success. For example, your management accountant spends less time looking in the rear-view mirror and adds more value as a forward-looking analyst.

Rob Jones, IT Lab’s Director of Enterprise Applications commented: “You have the data, you can look at the lifeblood of the business, the sales, the trends. I encounter clients lurching from one-month end to the next, just collating and reporting the data. Having very little time to sit back and ask: What’s it telling me?"

Application Programming Interfaces – APIs, are your keys to data integration but as Rob Jones cautions: “The most glaring pitfall is people thinking that the data integration challenge is purely mechanical, moving data from A to B. If you ignore the business process alignment and the quality of that data, you’re fanning the flames.”

How to Create a Common Data Model 

So, what should organisations consider before demolishing the walls of their silos? Data Integration begins with one objective in mind: the creation of a Common Data Model (CDM).

The CDM approach is built on breaking down systems and their databases into consistent and agreed formats. Rob Jones: “The idea is that there’s an agreed format for some of these key pieces of data. By pre-aligning your data, you're creating the architecture or framework which allows you to create the connections. If you fall in line with the Common Data Model, you’ve already gone a long way towards an integration framework.”

Rob Jones’ advice is pragmatic:

  • Start by mapping your data to create a master data taxonomy. Categorise your existing data sets and check the terms of reference. Are they consistent or inconsistent? Could they be open to interpretation or are they universally clear and understood?
  • Review the quality of your data. As our integration expert advises: “In terms of value, data quality and a single version of the truth are the holy grail. You want your data to drive, to be predictive. You can’t base that on faulty intelligence. When you're bringing data into your ERP system there’s a risk that you’re going to pollute rather than integrate it.”
  • Align your system and people processes. For example:
    • An apparently simple classification could have nuances. Is a ‘customer’ someone with an ongoing service contract or someone who made a one-off purchase 18 months ago?
    • What checks and balances are currently in place? Rob Jones: “The more integrated a model you have, the more control you need at various points. There can be too much comfort drawn from the fact that because data is flowing between systems electronically it’s assumed to be correct. You need that control mechanism, whether it’s about basic access, or what we call a reconciliation culture.”
    • Is the same information entered manually more than once? For many businesses, this behaviour is the costly and inefficient norm.
    • Which system has primacy over the data? Rob Jones: “For example, CRM has ownership of address details, but you don’t want it to drive a customer’s credit limit, which should be controlled by the finance team.”

Rob Jones continues: “Creating the connections between systems to achieve data integration should be done in the context of the business process itself. It’s defining these processes and controls. Deciding which system owns what data, writing a rule. It’s not simply pouring data from one system into another.

"What we’re trying to achieve is the business logic of the recipient system and applying that logic to the software as if it had been entered manually, so all fields are completed and compliant with the existing data architecture. Even basic things, such as importing a sales invoice transaction - it’s making sure the customer is real. It sounds ludicrous, but I’ve seen examples where sales have been imported into a system and the customers don’t exist."

Whilst the people and system alignment exercise demands a solid investment in time, the long-term benefits will be ten-fold. Rob Jones: “Ultimately, you're aspiring to a much greater degree of automation, where the processes become relatively mechanical. You're looking to achieve a management by exception approach to the anomalies. It shouldn’t be a human burden; the system can control that. The human burden then diminishes.”

  • Align your data - your disparate information needs to fit together. For example, scrutinise how information is currently captured in your CRM and ERP systems and compare mundane things such as:
    • Fields - e.g. date formats (particularly relevant for businesses operating internationally), field names, how many characters are permitted, which fields are mandatory.
    • Currencies – your French office records euros, your UK office records pounds sterling. How will the exchange rate be factored in, how it will be updated?
  • Ask a fundamental question – does this data truly need to be integrated? Will integration help automate reporting? Will it save duplication of effort by eliminating the need to re-key the same information? If there are no clear advantages, don’t burn time on it.
  • Consider the degree of granularity you need. For example, a retailer has 12 branches and records its transactions in its EPOS system. The retailer wants this information in its ERP system, but does it need to integrate every single transaction from a dozen branches? It may be that the consolidated figures for each branch are all that’s required. Again, consider the previous point.

Our next blog on this Adaptive Technology Model enabler will share other common pitfalls to avoid and guidance on Application Programming Interfaces.

Click here to explore our Adaptive Technology Model Hub and discover other rich resources.

Written by Christine Ellis