3.4 Definition of Business Intelligence Systems

This book is about designing and implementing BI systems. But how exactly do we define a BI system?

Most common definitions of business intelligence are quite broad, such as: "The use of data to increase profits and competitiveness".

With this definition you may wonder "is a calculator a BI system"?

We need to restrict ourselves to discussing systems, which aim to make business intelligence processes more efficient by using an architecture and providing functionality that ensures attainment of the previously described benefits of business intelligence.

By contrast we shall use the term business intelligence to describe collection and utilization of data for improving business performance in a broad sense. I.e. it is both the methods, processes and technologies.

Let us define more accurately what we mean by a Business Intelligence System.

The minimal requirements adhere closely to the most important benefits of business intelligence described in the previous chapter.

Let's quickly revise the benefits:

• Reduce labor costs
• Reduce information bottlenecks
• Make data actionable
• Better decisions
• Faster decisions
• Align the organizations towards its business objectives
• New insights

To ensure that these goals are met we shall define the following minimal requirements for a Business Intelligence System as follows:

1. Subject-oriented
2. Unified, centrally managed subject definitions and targets
3. System guided data interaction and exploration
4. Automated data collection and distribution
5. System supported data documentation and validation

These requirements are explained in more detail below.

3.4.2 Subject-oriented

All data in the BI system must be interfaced using natural terms corresponding to the organization's business' reality. For example, users of the BI system must be able to access data in the BI system using natural terms such as "Customer" and "Sales amount" rather than for example table and field names in the database.

3.4.3 Unified, centrally managed subject definitions and targets

All definitions of business terms and KPIs must exist in one version only and they must be managed from a central point to avoid redundant definitions, reports referring to outdated definitions etc. This requirement implies that application of data and definition of data must be separated by the system into a so-called semantic layer.

3.4.4 System guided data interaction and exploration

Interaction with data and data exploration are two vital features of a BI system that allow users to answer questions fast and autonomously. Many tools offer ways to manipulate data, but it is important to notice the term guided interaction/exploration. A system can only guide the user if it has some knowledge about the data. As an example of what is not meant by guided, consider a query designer: It lets the user draw relations between tables and fields in a database in order to manipulate the output. Since it is up to the user to understand the meaning of tables of fields to obtain the correct results, we do not consider this to be guided interaction/exploration, even if the query designer is implemented using a so-called Guide or Wizard.

As mentioned above, the system must have an understanding of data to truly guide the user. Such an understanding can be implemented using a data model. The two pre-dominant data model frameworks are:

1. Relational datamodels
2. Multi-dimensional datamodels

In today's world, relational datamodels are a de facto standard for modelling operational system databases whereas multi-dimensional datamodels have become a de facto standard for analytical reporting systems.

The strength of a relation datamodel is that it allows definition of almost any relation between physical data whereas a multi-dimensional datamodel (MDD) is more limited.

The strength of a MDD is that it is more explicit (less abstract) about the relations it represents, which makes it easier to learn by most people and it also helps systems in guiding users through data interaction and exploration more naturally.

Throughout this book we shall limit ourselves to discussing MDDs as the foundation that enables system guided data interaction and exploration.

3.4.5 Automated data collection and distribution

In order to achieve the benefits of reduced labour costs and faster decisions, all data collection must be automated. Please notice, that if the BI system extracts its data directly from the operational systems then the requirement of automated data collection is implicitly met.

Data collection includes any pre-processing of data that is required for generating the reports. If all processing is performed on the fly when reports are opened, and if this processing does not make report generation slow, then this requirement is implicitly met.
Automatic data distribution refers to reports and other outputs that are generated autonomously by the BI system based on schedules and events and then propagated directly to relevant recipients.

3.4.6 System supported data documentation and validation

Would you use a report if you didn't trust or understand the data it shows?
Stupid question - of course not.

But nevertheless, most business users are fed with reports with no documentation. When data is presented undocumented it is the root of many problems:

• The users don't understand the contents of the report and as a result they don't use it
• Users think they understand the contents and use the report. But they make the wrong decisions from time to time because the data is not what they think it is.
• When data looks wrong, one needs to investigate and validate it. But if there is no documentation of how and when the data was collected and aggregated then it can be impossible for the user to validate the results. As a result the user will resort to other sources of data.

From the above we see that if users do not trust or understand the data they see in reports, then it is impossible to enforce the requirement that subject definitions must be unified and centrally managed. The BI system can only centrally manage data definitions if users actually use the BI system. And if users don't understand the system's data definitions then one can hardly claim that the definitions are "managed".

As a minimum, the BI system must support documentation and validation these ways:

1. Allow and encourange system designers to write good, readable descriptions on all system objects.
2. Give users easy access to object descriptions, e.g. directly inside the reports they view
3. Allow users to perform so-called "drill-through" operations on data to see the source transactions. If the reports use replicated data (e.g. a datawarehouse, cube etc.) then the drill-through operation must also show the user when the displayed source transactions were replicated from the source system(s).

Some important points need to be made here in order to fully understand the implications of the above requirements. If documentation must be provided on every business term in the BI system, then it must be a requirement that those terms are actually implemented and interpreted as objects by the BI system. This is an important aspect because many reports are programmed, i.e. they are generated using SQL, JavaScript, C++, Visual Basic, Pascal - or more commonly, some vendor-specific programming language inside the ERP system. Converting program code to user documentation is difficult and the result is not good. By contrast, a model is usually composed of objects that can be easily described individually by system designers, and since the logic is based on a model it is also far easier for the system to convert object definitions into human language descriptions.

Because a modelled reporting approach has the above important and distinct advantages over a programmed reporting approach, we shall require a BISS system to be model-based.

The BI model must contain these parts:

1. Datamodel. A set of subject definitions and interrelations that describe the name, purpose, construction and inter-relation of all relevant business data terms. E.g. "Customer", "Item group", "Sales Amount" etc. This part corresponds to a MDD and its components, Dimensions and Metrics.
2. Rule model. A set of rules that describe thresholds of KPIs, potential business actions and business events. For example a rule can describe under which threshold a KPI - say Profit Margin Percent - is not acceptable and what the user could/should do about it. Rules can be associated with highlighting information such as colors and icons plus a descriptive text that is displayed in the viewing context, i.e. inside reports.
3. Process model. The process model relates reports to users and reports with other reports. The process model ensures relevance by giving each user access to exactly the data that user needs in any context, not less and not more. For example, the process model describes which report/dashboard must be opened automatically when the user connects to the system. And it describes how data in one report can be linked to other reports.

3.4.7 Conclusion

In this chapter we have made a distinction between business intelligence as an overall concept of business processes and business intelligence systems as computer software applications that support the processes of business intelligence.

LEAN Business Intelligence >>