By IsaiX | April 25, 2008
This article written by: Rhimou Moubarek and Coen Crijns
Business Performance Management (BPM) is a methodology that focusses on organizing, automating and analyzing business processes, metrics, and systems that drive business performance. Based on an organization’s strategy, performance areas are identified for which management information is needed. Subsequently, Key Performance Indicators (KPI’s) are defined in order to measure present results and to prescribe actions needed to reach targets.
Performance areas (or ‘themes’) and KPI’s form the basis for constructing specific performance reports and dashboards in a reporting application. This article focuses on the process of building reports for a performance theme, and the complexities that arise between Business Analysts and IT specialists in a large-scale business performance management program; the choice of software vendor and/or application is out of scope of this article.
In a large-scale business performance management program several performance themes are in scope at the same time. To manage this program and to standardize report building for each theme, certain process steps, milestones, and tasks are defined. A model that can be used to summarize these steps is the Deloitte BI (Business Intelligence) Business Cycle (see figure below).

In the BI business cycle, Phases I and partly phase V are often business driven, while phases II through IV are frequently technology driven. In large-scale performance management programmes, different project members are frequently responsible for completing either business driven (the “Business Analyst Team”) or IT driven (the “IT team”) process steps and tasks. This split in Business Analyst and IT teams is made to maximize the competencies of project team members and acquire economies of scale. However, assigning project members to either the IT team or to the Business Analyst team also has its limitations.
An issue with splitting up in a Business Analyst team and an IT-team is that the tasks mentioned in phase I are often completely conducted by the Business Analyst team and no IT members are completely involved. User requirements and goals regarding functionalities may be hard to meet because of technical restrictions of an IT application. These technical restrictions (both front-end and back-end IT) may become clear in later phases, for example when prototypes are built (in phase IV!). If an IT team member is involved in phase I, the Business Cycle of a performance report can be shortened because technical limitations of functional requirements are addressed in an early stage which also means that the expectations of the business can be managed.
Another common flaw is that a Functional Design (phase III) is presented (because the Business Analyst team is mistakenly assumed responsible for creating the Functional Design) while the tasks in phase II, source and data analysis, have not yet been conducted. Many end-user requirements could not be met based on the current sources. This sometimes means that large parts of a Functional Design will not be realized, and eventually this must be communicated to users. Consequently, a new Functional Design has to be created. This delays the completion of a performance report and users may become less eager for the end deliverables.
In conclusion, all phases of the Deloitte BI Business Cycle should be conducted by a heterogeneous team consisting of both Business Analysts and IT specialists working collaboratively. Although the steps between phases in the Business Cycle are reciprocal, the phases themselves should never be reshuffled.
Topics: Coach Technology® Blog | No Comments »
Comments