/images/spacer.gif) |
 |
Tuesday, September 07, 2010
|
|
|
|
|
|
|
|
|
|
/images/common/spacer.gif) |
|
Blog Entries
|
/images/minimize-dark.gif) |
|
/images/common/spacer.gif) |
|
Aug
17
Written by:
host
8/17/2009 1:19 PM
What is your definition of BI? Does it encompass operational reporting or doesn't it? What is operational reporting anyway? In my day-to-day work I come across many definitions. Depending on who's asking and who's delivering the definition changes. The people that require information consider data supporting day-to-day business decisions as valid a part of BI as is data required for tactical and strategic decision making. All data that helps in making / reaching a decision sooner is valid in that respect. This goes for any type of decision, be it operational, tactical or strategic. Now guys from IT usually get goose-bumps when someone requires all detail and fast. The most common opinion is that the person who's asking doesn't have the foggiest about what he/she wants and thus requires everything. This isn't always true. Depending on your place in the organization you might require all details to do your day-to-day work. The selection in terms of dimension members or measures is probably very small due to your scope of responsibility, but the amount of data can still be large.
Capturing and storing detail data is what the data warehouse is purported to do. So why not report on it just the same? Why do only the guys at headquarters get to see the summaries and why cannot the guys at the floor get their worklists for the day from the same data? This is where I think it starts to get interesting. Sure enough the data warehouse has all details as it is the memory of the organization. But it is the latency of the data being loaded into the data warehouse that determines if you can report on it for the guys at the floor. This is where most organizations go wrong, although not consciously. Usually the requirement for an operational report follows the same load pattern as any tactical/strategic reporting requirement. This usually means data needs to be processed and stored several times before any user can see the data in some report or other. Processing time usually is far too long for the report to have the required benefit of supporting an operational decision. The moment just has been long gone when the operational report finally produces the required data after the load pattern has been executed.
An organization needs to be 'ready' for operational reporting from the BI environment. It requires a certain maturity to be able to match the latency required for operational reporting with the load patterns used for the data warehouse. Furthermore, your data warehouse architecture needs to be able to cope with the differing load patterns for operational reporting vs tactical / strategical reporting. For example you need an acquisition area that is able to cope with both batch and event based load patterns without compromising load efficiency. The same holds for the model underlying all this detail storage in the acquisition area. It requires speed in storage and at the same time should reliably reproduce the necessary data. I think the Data Vault is excellently suited to play the role of underlying model for operational reporting from your BI environment. It is guaranteed to load fast without any hassles. Not only can it provide for single application reporting but also for cross application operational reporting, because of the isolation of business keys from the rest of the data thus enabling easy combination. It can even deliver historic data when needed.
Tags:
|
|
|
|
|
/images/common/spacer.gif) | | /images/common/spacer.gif) |
|
|
|
|
/images/spacer.gif) |
|