Ralph Kimball in his newest book, “The Kimball Group Reader”, is a compilation of the articles that the Kimball Group has published since the original article in 1995. They have spent over 15 years working and gaining experience with Business Intelligence / Data Warehouse Courses. I selected one of his articles in his book to summarize because it is the heart of gathering requirements for a Business Intelligence / Data Warehouse Project.
The requirements for many Business Intelligence / Data Warehousing Projects are gathered by interviewing the business user and looking at his existing reports or his transactional system. By looking at the existing reports or the current transactional system it leads many times to inadequate or incomplete business requirements. Many of the existing reports were developed and built by someone usually using at tool such as Microsoft Excel to report on the existing transactional system. Also in many cases the transactional system may be used by different departments that use the same system to run different but similar business processes.
The article says that the Dimensional Model for the Business Intelligence / Data Warehouse Project should be built on the business process and not on the different usage of the transactional system or the reports built from the transactional system. One of Kimball’s core concepts is to identify the business process for the dimensional data model. The article says that a business process is “an event or activity that generates or collects metrics. These metrics are performance measures for the organization. Business Analytics inevitably want to scrutinize and evaluate these metrics by a seemingly limitless combination of filters and constraints. As dimensional modelers, it is our job to present these metrics in an easy-to-understand structure that responds quickly to unpredictable inquiries.”
The article points our common characteristics and patterns when identifying the business process for dimensional modeling. They are:
1.) Business processes are usually supported by an operational system.
2.) Business processes generate or collect unique measurements with unique granularity and dimensionality used to gauge organizational performance. Sometimes the metrics are a direct result from the business process. Other times, the measures are derivations.
3.) Business processes are frequently expressed as action verbs with their associated dimensions as nouns describing who, what, where, when, why, and how associated with the process.
4.) Business processes are usually triggered by an input and result in an output that needs to be monitored.
5.) Analysts sometimes want to drill across business processes, looking at the results of one process along the results of another. Drilling across is certainly viable if the dimensions to both processes are conformed.
Some of the major conclusions of the article are:
1.) Determining the core business processes is critical to establishing your overall framework of the dimensional models.
2.) The easiest way to determine these processes is by listing to the business users
3.) A dashboard is not a business process; it presents the results of numerous individual business processes.
4.) Technical considerations are very important for a Business Intelligence / Data Warehousing Project, but if the proper business requirements are not captured and modeled the success rate for the project is very low.
OracleBIBlog Search
Friday, April 2, 2010
Identifying Business Processes:
Posted by
Ed Martin
at
Friday, April 02, 2010
Subscribe to:
Post Comments (Atom)
0 comments:
Post a Comment