In a quickly changing world where most companies consider the concept of “business as usual” to be a relic from the past, many BI managers experience that it can be difficult to keep up with the constant changes in the company and the surrounding world.
As a BI function, we would like to be able to provide a “corporate memory” system that can support decision-makers at all company levels to take the right informed decisions at all times – which is namely the BI function’s “raison d’etre”.
However, the dream of an ultimate Enterprise Data Warehouse (EDW), where all data are continuously harmonised and where it is possible to provide information at CXO level across all corporate dimensions at all times and where such information can consistently be displayed at each operational level remains a vision for most. Companies themselves admit that this vision does not necessarily need to turn into reality. This admission notwithstanding, many BI functions are facing challenges with finding benchmarks in their business that could help them identify and prioritise the right BI initiatives for the EDW build-up.
Let me illustrate the problem with a classic example: We would like to offer the CFO the option to view the company’s turnover in a dashboard divided by sales regions, customer segments and product groups and, ultimately, unfold it completely all the way down to individual customers and customer attributes. If each product group is delivered by independent divisions within the company that run different implementations of underlying ERP systems, this will typically lead to non-harmonised master data with duplicates and different formats.
The simplified example illustrates an everyday problem for the BI and EDW mindset. The ambition is naturally to have one and only customer number for the same customer. Can this problem be solved in BI? The answer is a definite “Yes”. Should the problem be tackled in a BI system? Maybe, but this comes at a price and should be matched to the real needs of the business. However, we cannot determine, based on a number of individually identified business needs, what the overall strategy for the EDW data architecture should look like.
It is important to emphasise that the problem, as a rule, cannot be viewed in isolation within BI’s framework as the strategy regarding data architectures and data governance should be system-wide. However, practice indicates that the BI function often “inherits” the architecture that already exists in the source systems and that it is rarely capable of affecting this architecture. In the best case, the BI function will take part in the team as data experts working with general data governance and can affect the area in this way.
The question is if we can find anchorage in the company’s structure that offers a degree of sturdiness that can withstand the constant changes we experience. An anchorage we can use as a basis for formulating the part of the BI strategy that deals with data architecture and with how the BI function utilises its mandate for impacting the company’s practice in the area of data governance.
One suggestion would be to borrow help from Enterprise Architecture (EA), a discipline that has been getting more and more corporate attention in recent years. Companies that are good at running EA tend to make IT an active integrated part of their operations to a much higher extent than “passive” service providers. The most important job of an EA architect is to contribute with a holistic view of the company. The elements in EA are “EA = Strategy + Business + Technology”.
More specifically, the company’s Operating Model can be the benchmark that sets the direction for the BI’s data architecture and the BI function’s data governance priorities.
Ross & Weill from MIT Sloan School of Management describe 4 different Operating Models where each company can be mapped in just one model.
The model describes the degree of Business Process Integration (data standardisation) vertically and Business Process Standardisation (process harmonisation) horizontally and operates with the following four Operating Models:
- Unification: Companies characterised as “single businesses” with global standardised business processes and high degree of data sharing
- Data in source systems: Typically standardised formats, global master data
- Company types: Danske Bank
- Coordination: Companies characterised by several unique business units with unique business processes per unit, but with a high degree of sharing of standardised data
- Data in source systems: Typically standardised formats, global master data (+unique facilities)
- Company types: The public authorities.
- Replication: Companies characterised by a unique business area and by global standardised business processes, but where each business unit acts autonomously independently of each other and thereby has little need for data sharing.
- Data in source systems: Typically standardised technical formats because of the joint ERP systems (possibly with local performance standards), local duplicates of master data
- Company types: Typically franchises, McDonald’s, 7-Eleven, Søstrene Grenes
- Diversification: Companies characterised by several unique business units with unique business processes per area and with limited sharing of data
- Data in source systems: Typically non-standardised formats, local duplicates of master data
- Company types: Conglomerates such as Maersk, Stadil Group
The model is an abstraction that describes an ideal situation for the degree of process and data harmonisation the company categorised in the individual Operating Model should strive for. It is worth noting that the company can be mapped in one Operating Model (as-is), but can work strategically towards a different one, e.g. in connection with Mergers & Acquisitions (to-be), a change that would, by its very nature, lead to a radical transformation of the company.
Even if an Operating Model is a strong simplification, it nevertheless tells us something absolutely fundamental about our company, which we can use in BI strategy contexts. The following characteristics can often only be inferred if you understand the company’s Operating Model and can thereby build a “starting point” for further analysis.
- What is the state of the data in the source systems?
- What reporting levels does the company have and to what extent is it necessary to be able to view data vertically vs. horizontally?
- Which data should be standardised?
- Where should the data be standardised, ERP vs. BI?
- Which role should the BI function assume with regard to data governance?
The models are, as mentioned, a simplified abstraction that in no way reflects the real complexity that exists in companies. The above examples are therefore also strongly simplified examples of how an Operating Model can be a benchmark for the strategy for building the data architecture in BI and BI’s access to data governance. The Unification and Coordination models are relatively uncomplicated with regard to the “single-source” EDW mindset. It is, in particular, the Diversification and, to a smaller extent, also the Replication models that really challenge you to reconsider your data architecture.
There will quite certainly be other options for interpretation than the ones I have presented here – the most important purpose of this article is not to present a ready solution catalogue but, much the reverse, to inspire you to use the EA discipline to make more sense of your company and, ultimately, to be able to take more qualified decisions about elements in the BI strategy.
It is never wrong to be ambitious in your approach to a problem, but you should always be aware that everything has a price – including the vision of the perfect Enterprise Data Warehouse. However, the focal point for most companies is not to build perfect systems but to have as much “return on investment” as possible, which has also been the intention of this article. The generated value is not perfect, but neither is BI’s job to make it perfect. It is simply important that the limitations in BI are known and accepted within the Company.