Key to a good BI system is the removal of the dependency upon operational systems in management decision making process and the transformation of data into information.
With this thought in mind, a BI implementation has a far greater chance of success if it is a business led, rather than an IT led project. BI exists to answer business management questions not support the core business activity and as such the questions are often loosely defined and evolutionary in nature.
BI systems should be designed with a different mind set to operational systems from the outset. The role of a typical operational system is to process large numbers of small data transactions, maintaining the integrity of data as it is built up. In contrast a BI system typically processes a small number of requests for very large amount of data.
The mistake that is often made is assuming that operational systems will support the additional overhead of BI users, this will simply not work in the long term for the following reasons:
-
The architectural design of the transactional system is at odds with that of a BI or Data Warehouse system.
-
The information is not easily accessible to business users outside of the operational system.
-
The Databases are usually technically biased and difficult for business users to understand properly.
-
The usage profile of the business user will typically have a severe negative effect upon the performance of the operational system.
-
It is difficult to ensure consistency of information on volatile database, reports or analysis may be inconsistent if the data is being updated whilst analysis is being undertaken.
-
The information required to satisfy business queries is often held in multiple disparate operational systems and databases and it may be difficult to relate data from one system to another accurately.
By far the best approach to BI is to implement a separate system that is designed from the outset to support consolidated reporting and information analysis activities such as data mining. To achieve this it is typical to build a system that comprises the following components:
A Dimensional BI Database Model
A BI database schema incorporating a dimensional data modeling techniques rather than a normalised database model typically found in operational systems. Dimensional data models concentrate on facts (number of units sold, value of sales etc.) and dimensions (date of sale, location of sale, product type, customer age etc.) Facts and dimensions are often combined and aggregated to give meaningful performance information about an organisation. For example if we combine the quantity of units sold with the date of sale and the product type we can easily understand how many products of each type were sold on any particular day.
Dimensional data models are often more simplistic in structure than normalised relational models and are often referred to as star or snowflake schemas because when represented diagrammatically they resemble a star or snowflake structure. The following diagram illustrates a typical dimensional data model:
The fact table is at the centre of the star and the dimension tables link around the outside, In this example the granularity of the fact table is at an individual sale level, but it could easily be created as an aggregate table for all sales of a particular product, at specific store, on any given day. With such a structure, the reporting queries become much more simplified than when using a full blown relational model. The number of relationships that a query must satisfy in order to be fulfilled is reduced and using aggregated data tables can help further with the simplicity and speed of data queries. If you know that most of your analysts are going to be interested in dealing with analysing data associated with the total sales of a product for a given time period, It is far more efficient to aggregate the data up front than have the aggregation repeated for each user query.
Data Extraction, Load and Transformation (ETL) Tools
ETL tools are software components that extract data from different data sources, transform it into consolidated homogeneous information and load it into the BI database. They allow this process to be automated and scheduled to run at times that are convenient with operational restrictions and the availability demands of BI users. Common ETL tools include Informatica, DataSstage and Ab Initio. In-house developed ETL tools using scripted and procedural SQL are also common, especially if the transformation process is esoteric or exceptionally complex.
BI Presentation and Analysis Tools
BI presentation and analysis tools translate the BI database schema into a business view of information allowing business users to access information using business terms rather than esoteric database table and field names. The database translation is often referred to as the semantic layer or metadata (data about data). BI tools typically support standard reporting and data analysis activities often referred to as on-line analytical processing (OLAP) and Data Mining. The leading BI tools include BusinessObjects, Cognos and MicroStrategy.
Customer Relationship Management (CRM) tools
CRM is a combination of contact and lifetime management software, customer profiling analysis and targeted marketing
activities that use BI information and the results of information analysis to provide customer targeted marketing campaigns. The results of campaigns are then fed back into the BI loop to further assess and influence customer behaviour.
For more in depth BI information register to access our free registered user information area.
If you think that your business growth would benefit from a successful BI implementation and would like to know more about what we can do for you, contact us and let Beacon guide you.
.
.
|
