BI Governance Technique Paper v5

The full scope of services within Business Intelligence is not permissible for SEC audit clients and their
affiliates. Refer to Independence guidance in the BI Governance methodology on slides 9-11 of the guide. The activities are generally permitted for IFAC audit clients.
Business Intelligence
BI Governance Technique Paper

FOR INTERNAL USE ONLY
This document is intended for internal use only, not to be distributed to clients.
2005 KPMG International. KPMG International is a Swiss cooperative of which all KPMG firms are members. KPMG International provides no services to clients. Each member firm is a separate and independent legal entity and each describes itself as such. All rights reserved.
ABCD
Business Intelligence Governance Technique Paper Guidance Advisory For Internal Use Only
Table of Contents 1 Business Intelligence Governance Technique Paper 4

1.1 What is it?................................................................................................................4 1.2 Why and When to Use It?........................................................................................4 1.3 How to Use It?.........................................................................................................5
2 Overview of BI Governance 3 BI Governance Framework and its components
6 8
3.1 BI Strategy...............................................................................................................9 3.2 Management principles..........................................................................................10

3.2.1 Management principles for BI program steering and management.................................10 3.2.2. Management principles for subject matter management................................................12
3.3 Organizational structure.........................................................................................14

3.3.1 Board Level....................................................................................................................14 3.3.2 BI Governance Steering Committee...............................................................................15 3.3.1 BI User Community.........................................................................................................16 3.3.2 Surroundings / Partners....................................................................................................16 3.3.3 BI Manager......................................................................................................................16 3.3.4 BI Competency Center.....................................................................................................16 3.3.5 Small changes and big changes implementation teams....................................................17 3.3.5.1 Leadership roles........................................................................................................18 3.3.5.2 Business roles...........................................................................................................18 3.3.5.3 Technical roles..........................................................................................................19 3.3.6 Operations and support teams..........................................................................................20
3.4 Processes................................................................................................................20 3.5 Metrics ..................................................................................................................20

3.5.1 Metrics categorization.....................................................................................................21 3.5.2 Dimensions / Standpoints...............................................................................................22
3.6 Tools .....................................................................................................................24
4 Introducing BI Governance to the organization

4.1 Approaches to BI
Advisory Date This report contains 28 pages
26
Governance introduction...............................................................................26
Top-down approach.................................................................................................................26 Bottom-up approach................................................................................................................27
2009 KPMG International. KPMG International is a Swiss cooperative. Member firms of the KPMG network of independent firms are affiliated with KPMG International. All rights reserved. 2005 KPMG International. KPMG International is a Swiss cooperative of which all KPMG firms are members. KPMG International provides no services to clients. Each member firm is a separate and independent legal entity and each describes itself as such. All rights reserved.
ABCD
Combination of both................................................................................................................28
BI Governance Tips and tricks...................................................................................28
5. Related Tools and Methodologies
29
ABCD
1
1.1
Business Intelligence Governance Technique Paper

What is it?
Business Intelligence (BI) Governance is about steering a super tanker with a paddle. It is not straightforward and its benefits are not obvious at first sight. Governance has come to the spotlight after the horrible experiences of the BI programs and project management teams that are totally overloaded with BI development groups, leading to frustrated BI users and a loss of credibility for the BI solutions. BI Governance is a set of approaches, disciplines and actions put into place to help ensure that: The BI users expectations are set and met in the proper fashion. The BI users requirements are properly collected, managed, prioritized, communicated and met. The overall BI solution is led in the right direction, with solution architecture being flexible enough to absorb business changes and the resulting changes in or addition of new requirements. The BI solution should be built to support the long-term vision, not just fix the immediate issues. The projects are prioritized, arranged, managed and led in the proper manner delivering the expected results. A key point here is that clients should consider halting some related BI programs as priorities become clear or change over time. For major BI programs, this will free up client resources to help ensure success. Vision / strategy defining the goals of BI Governance and its approach Management principles a set of policies, guiding principles, methodologies, frameworks and standards to help manage the solution architecture and BI projects. Organization structure definition of roles and responsibilities needed to develop and maintain the current BI environment. Processes business-facing and management processes covering all aspects of communication with the BI community and the wider business; creation, approval, introduction and enforcement of management principles and polices Metrics the set of key performance indicators (KPIs) and measurements enabling monitoring of the BI environment and correct behavior of the BI organizational structure Tools tools and information technologies supporting BI governance, such as various repositories, workflow management, publication tools (intranet), etc.
To achieve these goals, BI Governance consists of six components:
1.2
Why and When to Use It?

This document can be used by KPMG professionals in the delivery of Business Intelligence and related projects. This technique paper provides the KPMG professional with insights and examples
ABCD
on the elements needed for effective governance of a BI program while in development and defines what should be in place as the program moves into the production phase.
1.3
How to Use It?

This document should be used as a supplement to the KPMG the Business Intelligence toolkit. It brings together a variety of materials that can be used to support BI Governance engagements. This document is itemized and includes most components of a BI Governance environment. This technique paper should serve as a staring point or input for prioritization when determining what the necessary steps are. This Guidance document is for internal use only, and must not be distributed to the client or other non-KPMG entities.
ABCD
Overview of BI Governance
Business Intelligence solutions have been rapidly developed over the last few years as a result of a demand for better information by business units. However rapid development, immaturity of the area, and lack of resources for overall program management have frequently led to dissatisfaction by the business with the level of the support it receives from the BI team. In addition, the business is continually changing, and the BI group is often seen as being unresponsive and inflexible to respond to change. As a result, the business adapts and finds workarounds or alternate approaches for getting the analytic support it needs. These workarounds may result in loss of flexibility and increased complexity of the solution, further resulting in limited scaling capabilities and inefficient technologies. BI governance is one mechanism for addressing these issues and for changing the approach and attitude toward BI development and operations. BI Governance may be the answer to the following situations and issues organizations may face: Current situation Leading to
Silo-based approach; user requirements isolated Multiple requirements Multiple development efforts Lengthy delivery times Inflexible solution architecture (series of loosely linked data marts) Lengthy delivery times Solution cannot adapt to future requirements
Users dont understand data content in the same Users dont trust the solution way Users require redundant work Unclear BI development priorities and delivery terms Outputs dont meet the quality requirements Workarounds developed Disillusion / loss of credibility Workarounds developed Disillusion / loss of credibility Repeated requirements Loss of credibility Loss of credibility
Unclear data lineage Underestimated need for communication and PR
ABCD
The leading Business Intelligence solutions are business solution enabled with IT tools serving the business. In the same way, BI Governance has to consider both business requirements and IT requirements as it crosses the traditional dividing lines. The four major areas of focus are: 1. Stakeholders and key end user expectations This area is the most critical part of overall BI environment management as happy stakeholders are essential for the success of a BI program. Unfortunately, the value of communication with these users is often grossly underestimated. Setting expectations at an attainable level and subsequently meeting (or exceeding) these expectations in todays hectic and turbulent environment is a must. 2. Key requirements management As soon as expectations are set, the next step is to consider the requirements. Requirements should be carefully collected, checked against the existing solution, development plans and other requirements, stored in a requirements repository, and subsequently prioritized. During the requirements management lifecycle, well-timed, proper and straightforward communication with the requestor and other related parties has to be undertaken. It is also key that when all the requirements are laid out, the requirements are then reiterated to the client to illustrate what the implementation of the requirements will mean for them. This will reinforce, or in some cases reset, expectations. This also provides an indication of the complexity of the solution, and therefore the cost, effort and time involved. In this way, we need to challenge the client to verify the requirements are true requirements and not just a wish list. 3. Solution architecture management This heading contains a thorough list of things to keep an eye on. A BI solution should be as flexible as possible, allowing for future development of business requirements resulting from a changing business strategy and the natural evolution and maturity of the BI solution and its users. Consequently, the proper architecture has to be set up and managed to provide this flexibility. Additionally, the BI solution architecture needs to fit to Enterprise Architecture standards and approaches. Solution architecture management may therefore encompass everything from conceptual BI solution architecture to the naming conventions for database objects. 4. Change and project management As the BI solution is developed under program management standards, change management is crucial. It is especially crucial when the list of the requirements is longer than the BI development team and the BI solution development budget can handle. This is the right time for careful evaluation of every requirement, political discussions, prioritizations and appropriate communication with the stakeholders and key business users. Managing change and further BI solution development has been well known to be one of the biggest issues of current BI environments.
ABCD
BI Governance Framework and its components

BI Governance generally consists of six elements: Vision / strategy defining the ground rules for the BI Governance, its goals and approach. Management principles the true heart of BI Governance a set of policies, guiding principles, methodologies, frameworks and standards to help manage the solution architecture and BI projects. Organization structure definition of roles and responsibilities needed to develop and maintain the current BI environment. Processes business facing and management processes covering all aspects of communication with the BI community; creation, approval, introduction and enforcement of management principles. Metrics the set of KPIs and measurements enabling monitoring of the BI environment and correct behavior of the BI organizational structure. Tools tools and information technologies supporting the BI governance, such as various repositories, workflow management, publication tools (intranet), etc.
ABCD
Mapping these parts to the four focus areas mentioned in the chapter above will create the BI Governance framework:
<Process Name >
BI Strategy
<Function>
Manage Expectations
Communication strategy Education strategy
Executive Sponsor BI Steering Committee
Communication / PR Education Help desk / support
Usually soft metrics: Overall user satisfaction Percent of formal expectations met Solution reliability Rework
Standard means of communication in the organization
Manage Requirements
Demand management Business analysis
BI Steering Committee Program Manager Business Analyst Technical Analyst BI Architect Support team
Requirements gathering Requirements management Change management Solution design User Acceptance Testing
Soft metrics: Overall user satisfaction ... Hard metrics: Delivery times Percent of UAT issues by category Percent of requirements met ... Compliance with the standards Number of exceptions Percent of solution coverage by standards (plan vs. reality) Number of standards under development Standards quality and usability ...
End users repository Requirements repository
Manage Solution Architecture
Solution Architecture Technology Standards Reportin Standards Data Integration Strategy Data Access Strategy Data Quality Strategy Data Protection Strategy Meta Data Strategy Design Standards
...
BI Architect BICC
Solution design Change management RFI / Vendor selection Project management
Metadata repository CASE tools SLA
Manage Change / Projects
Demand management methodology Change management methodology Project management methodology
BI Steering Committee Program Manager Change Manager Project Manager
Program management Change management RFI / Vendor selection Project management Solution design
Number of requirements in the queue Time to deliver Number of requirements excluded by prioritization process End users satisfaction ...
Standard tools for change / project management support in the organization
Management principles
Organization structure
Processes
Metrics
Tools
3.1
BI Strategy
BI Strategy is the key document specifying the reason for the existence of the BI environment (vision and mission), expected results and benefits, solution form, solution roadmap, priorities, budgets, etc. The BI Strategy is described in [link to BI Strategy technical paper]. In many cases the
ABCD
BI strategy will have a business case attached to it spelling out the benefits as well as the costs to achieve the vision. [also consider the technique paper of BI Business Case build]. Another vital part of the BI Strategy is BI Governance definition specifying the scope of the BI environment governance activities and its sphere of authority. Strategic imperatives for BI Governance justification for BI Governance. BI Governance Scope:
Which processes and decisions in the organization are covered by BI Governance rules and policies Who has the authority within the BI organization to make changes to the rules, policies and processes Who in the larger business organization has to follow the rules and policies Processes for dealing with exceptions from the defined rules and policies
People responsible for the BI Governance strategy document administration, approval, etc.
3.2
Management principles
Management principles are the core component of BI Governance as they shape the behavior of everyone involved with the BI environment, from top management of the organization to the support personnel and solution vendors. Management principles can be split into two groups: Management principles for BI program steering and management (i.e., rules and procedures guiding the behavior of the people) Management principles for subject matter management (i.e., rules and procedures guiding the form and shape of the solution)
3.2.1 Management principles for BI program steering and management

Under this section all the documents for BI program steering and single project management may be found: Communication strategy [Link to Communication strategy paper] the set of fundamentals, approaches and techniques for communicating all relevant information to the organization, mainly to its business users. The communication strategy typically covers:

Solution content and intent the way the solution can and may be used. Solution development roadmap the milestones and features of the solution in the increments to be delivered (including mapping to the user requirements). Time to deliver logged and approved user requirements, and the status of these requirements.
10
ABCD
Information about training, participation in testing, systems demonstrations, presentations and social events. POSITIVE COMMUNICATION (often missed) information about successes and celebration. Examples include project delivery, solution recovery, number of users threshold reaching, etc. Unpopular information, such as solution outages, delays in projects, etc.
Education strategy [Link to Education strategy paper] the approach to education and training for end users, analysts, operators / administrators and development teams at all levels, but in two main classifications:
Business users How to use the solution what is the content, what it should be used for, what it should not be used for, etc. How to use the tools training on software used. How to operate and administer the solution (when to run ETL jobs, when and how to backup and restore, etc.). How to develop the solution (training on the methodologies and standards).
Technical users
Change management / Demand management methodology [Link to Change management methodology paper] one of the most important policies in the Business Intelligence environment. Specifying, it is how the requirements are collected, stored, consolidated, approved, prioritized, assigned to projects and delivered. Usually, the end users requirements arise from two sources:
New business requirement based on new business fact. A change to an existing report which cannot be done by the user is still a new requirement. Error reported using trouble ticketing environment for the BI solution (help desk, user support, etc.). Minor changes changes required less than a certain amount of effort and funds the threshold will change from organization to organization (but the limits have to be specified in the Change management policy). Major changes changes exceeding the defined thresholds.
Usually, the requirements may be split into the following categories:
Based on these categories, the set of activities and decisions to be made prior implementing the requirements may differ. It is also worth point out here that the BI Competency Center (BICC) will need to review and prioritize and challenge the changes requested as they may impact the integrity of the data model, which is owned by the BICC. More information about change management can be found in [Change management technical paper].
11
ABCD
Project management methodology [Link to Project management methodology paper] may be the organizations standard methodology for running projects or may be a specific BI methodology. In both cases, templates for BI-specific tasks should be part of the methodology (mainly ETL design and testing, data mining design and testing, report specification, etc.). Business analysis methodology [Link to Business analysis paper] similar to project methodology, it may be the organization-wide toolkit for performing business analysis or it may be a special BI-focused document. It should definitely support multidimensional analysis and thinking.
3.2.2. Management principles for subject matter management

In contrast to the first group of management principles, this set of principles helps the development and operational teams to build the solution, keep the solution running and support it in a timely and proper manner. Solution Architecture the foundation for the BI solution. Defines the conceptual and logical architecture, all components which will eventually be used (if there is an approved business reason for them) and the approach to overall architecture management. It may be in different forms and levels of detail. An example of solution architecture can be seen in [link to BI architecture document]. Technology Standards [Link to Technology Standards paper] either as a standalone document or part of the Solution architecture document, technology standards define the hardware and software components which will be used for the BI solution. Reporting Standards [Link to Reporting Standards paper] as the solutions outputs are the visible part of the BI environment, reporting standards should be defined in order to ensure a uniform look and way of usage of all the reports (ad-hoc, standard, operational, OLAP or integrated into other solutions / platforms). These standards include:
Standard graphical design colors, object placement, required objects (such as date of report, user / business unit, purpose, confidentiality statment), etc. Standard use of the reports how to generate the report, refresh report data, how to pivot, filter, etc.). Error reporting who to contact if the report is broken or data is incorrect. Limits on report validity policy for copying the report and changing the values.
Data Integration Strategy (a. k. a. Integration Framework) [Link to Data Integration Strategy paper] a relatively broad document, it covers everything from guidelines on which integration techniques to use for data movement from primary systems to the BI environment, data movement among the single components of the BI solution, and the ETL and mapping standards. It includes the data conversion strategy as well. Metadata Strategy [Link to Metadata Strategy] experience shows that Metadata Strategy is getting more and more attention as companies struggle with good and common understandings of BI solution content. Metadata strategy defines the approach to both the
12
ABCD
technical and business metadata how to collect, consolidate, approve, store, share, use and decommission metadata. This document may be part of an overall Metadata Strategy for the organization-wide Data Management policy. Data Quality Strategy [Link to Data Quality Strategy paper] similar to the previous management principle, Data Quality Strategy has become an important part of the BI environment and overall organization-wide Data Management activities, as it reaches far beyond BI. BI solutions simply bring data quality issues to the attention of end users, as their outputs are only as good as the data contained therein. Data Quality strategy should include the standard steps and actions needed to be taken for typical data quality issues / errors, communication lines for error reporting and standard procedures for mitigation of errors. Data Quality issues are broader than BI governance, and are therefore addressed at the Integrated Information Management layer of the KPMG BI Framework [link to relevant documents]. Within BI governance, data quality issues are addressed through the change control processes as well as through the on going monitoring function performed by the BI Competency Center. Data Protection Strategy [Link to ILM technical paper] this management principle deals with all aspects of data security:
Confidentiality the access to data is granted only to authorized persons (solved conceptually with Data Access Strategy (see below) and on the physical level by assigning the user and system access rights). Integrity the data modification process is fully controlled allowing only the authorized changes to be made (solved with Solution architecture / Data Integration policies and rules for changing incorrect data, as well as with data access controls). Availability the data is available where and when it is needed, i.e., physical access to the data. Security how secure is the data (commonly solved by having a detailed Disaster Recovery Plan in place).
Data Access Strategy [Link to Data Access Strategy paper] sometimes perceived as a part of Data Protection Strategy, it is defined for logical groupings of users and logical groupings of information. It usually consists of matrices defining basic principles for access rules. The matrices typically define:
Access rights to the output interface components (some users may work just with the predefined reports, some users may create new reports using standard OLAP environment, some users are allowed to write and run database queries against the BI/DWH databases, etc.). Areas of information a group of users may or may not access. Level of aggregation or detail for the information a group of users may or may not access (e.g., see the results of their own department vs. seeing the results of the company).
13
ABCD
Design Standards one of the most detailed management principles, its purpose is to help ensure that the solution design will remain consistent across all components. It defines all the design standards, naming conventions etc. for all BI solution components.
3.3
Organizational structure
The organizations structure, defined under BI Governance, enables managing of the BI environments development as a program (an overall steering committee, including all the typical aspects financial, time, people and other resources) as well as secures the daily operation of the BI solution (in the Business as Usual mode) and running of future BI development projects. Organizational structures may have any number of forms and the roles may have different names. However from the conceptual and leading-practice standpoint the structure should be as the following:
Board Level - CxO
Marketing Finance LoB 1 LoB 2
Program sponsor
Surroundings / Partners Enterprise Architecture

Marketing
BI Governance Steering Committee
End User
End User
End User
Finance
LOB 1
LOB 2
...
SME
SME
SME
Data Management / Data Governance

BI Manager
BI User Community
BI Support Team
Small Changes Project Team
Big Changes Project team
BI Competency Center
BI Department
3.3.1
Board Level
As a BI initiative is organization-wide and affects almost everyone in the organization, the program should be overseen by top-level management. This does not usually mean placing a heavy load on top management, but they are essential for oversight of the BI environment and to help ensure buyin from the lower levels of management. This involves the following: a) Approving and promoting the BI Strategy in the organization. b) Deciding on and assigning budget for both development activities and operations (on yearly basis). c) Serving as the last escalation point for issues that are unmanageable at the BI Steering Committee level. Another critical level of sponsorship is assigning a board member as the overall BI environment (or program) sponsor. This means that there is one escalation point for BI related issues and business
14
ABCD
has a clear indication of the importance placed on BI. It would seem that an IT executive is a logical choice to be such a sponsor. However, this is often counter-productive as BI is then seen as an IT project instead of a business initiative. It is better to have the Chief Operating Officer take on this role or even the Chief Finance Officer. The reason for this is that BI is only successful when it is driven by the business and aligns with the overall business strategy, not simply IT.
3.3.2
BI Governance Steering Committee
The BI Steering committee is composed of key business unit representatives, and it serves as the main decision making body for the BI environment. The BI Governance Steering Committee approves / renders decisions mainly on the following: a) At the program management level: a. Preliminary approval of the BI Strategy and all relevant documents, such as the BI Roadmap and BI Business Case, before it is finally approved by board-level sponsorship (depends on the particular organizations culture). b. Approves all management principles. c. Approves the BI organizational structure, roles, descriptions, and capacities and appoints people to the roles (depends on the organization structure model). d. Approves set of metrics and KPIs resulting from the BI roles and processes and approves the targets for the given period. e. Decides on engagement of internal people and external suppliers for the specific types of work to be done within the BI environment. b) At the project / day-to-day operations level: a. Determines the priority of user requests (or groups of user requests), assigns them to the particular project, and thereby indirectly determines the time frame of implementation for significant change requests. The Steering committee should not get bogged down in minute details, nor should small change requests require Steering committee approval. b. Decides on how the budget assigned by the board level for given time period will be spent. Decides on project scopes, starts and single project budgets. c. Decides on the supplier of a project in case of initial stage projects or big projects, the BI Governance Steering Committee decides who will deliver the services (what will be delivered internally and by which department and/or whether and which external provider to use). The BI Governance Steering Committee is also responsible for centralized communication to the BI community and its surroundings. For the areas of program / project management, the BI Governance Steering Committee may use the services of an organizational Project Management Office (if possible) or have a dedicated (usually not full-time) program manager.
15
ABCD
3.3.1
BI User Community
The BI User Community consists of end users and their representatives for the BI solution development sessions. These subject matter experts (SMP's) should have the knowledge of the existing BI solution as well as the knowledge of the operations of the business unit they represent. They have to know the BI user requirements and priorities, and they are responsible for the consolidation of these requirements (within the group of users the SME represents). The SME will communicate any BI-related information to the group they represent.
3.3.2
Surroundings / Partners
Enterprise Architecture department partnering mainly at the expert level, exchanging the management principles, guidelines, standards and knowledge on both formal and informal levels. A businesss IT department needs to be involved here the BI team should not recreate the IT skills and policies already in the organization. Instead, the BI group needs the skill set to understand the IT world as well as the requirements of the business users. Data Management initiative has two touch points: the first is at the Steering Committee level as both of these programs have to be managed in mutual conformity; the second one is at the expert level similarly to the Enterprise Architecture department.
The major partners for the BI organizational units are:
BI partners
Enterprise Architecture Enterprise Data Management
Steering Committee level
No cooperation usually necessary Management principles alignment Knowledge exchange
Aligned steering
Expert level
Management principles alignment Knowledge exchange
3.3.3
BI Manager
The BI Manager is the manager of the BI department and is usually responsible for leading the department on an ongoing basis. He/she usually covers the support team and implementation teams for both small and big changes to the BI Environment and BICC. The BI Manager may also play the role of change manager assessing the required changes and deciding on their classification into big or small changes.
3.3.4
BI Competency Center
It is the know-how department of the program. (See also the BICC Technique Paper)
16
ABCD
The BI Competency Center (BICC) is usually comprised of specialist on BI solution architecture (both business and IT), experts on BI problems as a whole, data management specialist and the organizations line of business specialist as well (functional bodies). The responsibilities of the BICC include: a) Preparation of all guiding documents, starting with the BI strategy and going to the lowest level of management principles. After preparation, it hands over the documents for preapproval or approval by the BI Governance Steering Committee. b) Definition of the metrics for monitoring the BI environment, including feasibility of the calculations and their reliability; setting the recommended target values for approval. c) Preparation of the specialist part of the marketing and communication materials. d) Creation of training materials. e) Serving as a training center for all newcomers. f) Serving as specialist support for BI implementation projects (explaining the management principles) as well as for the support teams. g) Participation in the solution design and acceptance testing as an authority of management principles / standards compliance. h) Expert communication with other Competency Center and Enterprise Architecture (or similar) departments; helping ensure that the organization-wide standards are considered by all relevant BI management principles and vice-versa.
3.3.5
Small changes and big changes implementation teams
These teams deliver particular changes to the BI environment as appropriate for their team. Similar to the support team, they may or may not be part of the BI department. The structure of the team roles and the involvement of external vendors depend on organizational decisions as well as on internal team abilities. It is also determined by type of the project output and the solution architecture. The following list is a highlight of the most-used roles and their responsibilities in BI projects (there may be multiple roles exercised by one person and vice-versa).
17
ABCD
BI Implementation Team Roles
Project Manager / Team Leader
Business Solution Architect
Technical Solution Architect Tool Specialists / Administrators Data Integration Developer
Business Analyst
Data Mining Specialist
Data Profiler
Report Developer
Data Mapper
Tester
Trainer
3.3.5.1
Leadership roles
Project Manager responsible for overall project delivery within a given time, budget and other resources constraints and with the expected quality of output. Facilitates multilateral communication with project output stakeholders, implementation team and line managers of the team (vendor management in the case of external vendor or line managers of team members in case of internal team). Team Leader responsible to the Project Manager, assigns tasks to team members, monitors the development and results. There may be none, one or multiple team leaders on the project, depending on project scope and size.
3.3.5.2
Business roles
Business Solution Architect business professional responsible for satisfaction of business users, and thus responsible for the appropriate solution design from the business point of view and for the feasibility of such solution development. He/she typically drafts the concepts of the solution and lets the Business Analysts do the detailed design. Usually he/she is also lead analysts overseeing the work done by Business Analysts. Business Analyst business professional responsible for current status analysis, gathering the detailed requirements for the to-be solution and the gap analysis. Responsible also for the detailed to-be solution components design (such as detailed database logical model design, business rules for data
18
ABCD
integration design, detailed report design, etc.). Last but not least, responsible for User Acceptance Testing support. Usually, Business Analysts also deal with Data Quality issues. Data Mining Specialist business professional with specific knowledge of the knowledge engineering and statistical methods used for the Data Mining solutions. Usually able to deliver the whole Data Mining piece (without final end-user interface in the case of integrating the results into some specific applications such as intranet or other organization software) including the requirements for the underlying data. Data Profiler specific business analyst responsible for detailed source data analysis in order to prove the feasibility of using the data for the intended purposes. Usually uses specific GUI tools so the detailed knowledge of database query language is not necessary, but technical knowledge of the underlying data structures can definitely help. Data Mapper person who translates the business design, logical data model design and business rules into technical mapping rules, serving as a clear and unambiguous input for the data integration developers.
3.3.5.3
Technical roles
Technical Solution Architect experienced architect with knowledge of the technologies used and current technical environment; responsible for the technical solution design in accordance to valid technical standards in the organization and business solution designed by Business Solution Architect. The Technical Solution Architect is also a partner with the Business Solution Architect in the solution feasibility checks and discussions. He or she is also typically responsible for the physical data model design of all relevant database components (otherwise it is the responsibility of the database specialist). Tool Specialists / Administrators technical professionals responsible for the correct setup of the technologies used. They cover all technical components used from data integration tools, through databases, reporting and analytical platforms, Data Mining tools to presentation layer tools, metadata management tools, Data Quality management tools and any other possible tools included. Data Integration Developer sometimes referred to the ETL developer or EAI developer, technical professional responsible for developing the data manipulation code among all relevant solution components. Also responsible for unit testing of the code produced, and eventually for the peer review of the code of others (if this technique is used). Report Developer person responsible for all types of report development (ad-hoc, standard, dynamic, OLAP, etc.) and integration of the outputs with the presentation layer components as well. Responsible for specific analytical objects development if needed (universes, etc.). Also responsible for unit testing
19
ABCD
of the code produced, and eventually for the peer review of the code of others (if this technique is used). Tester team members for various types of testing apart from unit tests and User Acceptance Tests support. Usually responsible for integration and stress testing. Trainer provides the user community with all relevant types of training. It is important that this training is delivered just in time to help maximize its usefulness and effectiveness.
3.3.6
Operations and support teams

Operations team consists of administrators and data integration tool operators making sure the solution is up and running, the data loads are completed on time, the users have appropriate access to the reports and the data, etc. This is specifically related to the technology that is being deployed as part of the solution. This is not part of the BI organization but it should be in place for the BI environment to function. Support team typically forms help-desk / first line support, gathering users complaints, requirements for further developments, requirements for granting the access, etc. This is specifically related to the technology that is being deployed as part of the solution. This is not part of the BI organization but it should be in place for the BI environment to function.
Operations and support teams support the solution operation and end users.
3.4
Processes
BI management processes are defined by the management principles described in chapter 3.3 above.
3.5
Metrics
In order to help manage, control and defend the BI environment as a whole, a set of metrics has to be developed to monitor the BI solution design, development and operations, BI Governance function and behavior of the people involved. These metrics may be organized and created using different systems and they may exist in different formats, depending on the organization and its culture: Key Performance Indicators (KPIs) of the BI roles Key Goals Indicators (KGIs) of BI processes Service Level agreements (SLAs) for BI services and BI solution Organization-specific metrics
The aim of the system of metrics is not only to reveal the issues and areas of non-compliance, but also to help ensure that:
20
ABCD
People responsible for the BI environment understand its status and anticipate its progress. Errors are identified as early as possible. Areas of non-compliance can be addressed by training or other activities. Expectations for continuous improvement are set and met.
The areas of monitoring are obviously similar to the areas of BI Governance focus we defined at the beginning of this document; however, monitoring of BI Governance is added: Setting and meeting end users expectations Managing and meeting end user requirements Following the management principles of solution architecture Running projects Managing the BI environment in a proper way
There are thousands of metrics which may be used to monitor the BI environment and any number of dimensions/standpoints you may measure the BI environment by. The following sections provide a set of ideas on how to approach monitoring.
3.5.1
Metrics categorization
The first categorization of metrics is between quantifiable and non-quantifiable. Quantifiable metrics are such metrics you may easily determine a value for and/or get automatically from the BI solution tool or related tools. Examples include totals, averages, percentages, etc. Specific metrics include the number of user requirements, number of applications, database size, number of reports, etc. Non-quantifiable metrics describe more quality or statuses and are either not directly measurable (and have to be somehow translated to numbers) or their value is not easily obtained. The classic example is user satisfaction, where you need to convert in to user satisfaction index and in order to get the numeric value you either force users to assess the reality by using range of numbers or you have an expert system converting the users nonnumeric answers to numbers.
When categorizing metrics in the BI Governance area, the result is a matrix similar to the following:
21
ABCD
BI Governance Metrics Space
Quantifiable metrics
Non-quantifiable metrics
Setting up and meeting end user sastisfaction
SLA timescale compliance
User satisfaction index Existence of communication ...
Managing and meeting end user requirements
Number of requirements in queue Number of requirements met on time ... Management principles compliance Number of training sessions held ...
User satisfaction index Number of complaints ...
Following the management principles of solution architecture
Existence of the management environment (principles etc .) ,
Running the projects
Standard project measures
Standard project measures
Managing the BI environment in a proper way
Percent of required budget received Number of users / active users Number of system outages ...
Existence of BI Governance environment ...
3.5.2
Dimensions / Standpoints
When monitoring the BI environment, you may develop a number of dimensions by which you want to measure performance. Significant importance is usually given to the following: BI Governance areas of interests already mentioned at the beginning of this chapter, you may want to monitor:
Setting up and meeting end users expectations who are the key users, how are the key users satisfied, how is the bi-directional communication is set up. Managing and meeting end user requirements how the requirements are gathered, analyzed, consolidated, managed, prioritized, assigned to the projects, and communicated back to users. Following the management principles of solution architecture and measuring the architecture itself how the architecture is flexible, open, supporting further development and changing business conditions, what tools and technologies are
22
ABCD
used, which standards are planned or in place, how the standards are followed, how the exceptions are managed, how big the solution is, how big the space for further development is (reaching the limits of storage space and ETL job time window), how stable the environment is, etc.
Running the projects using standard management monitoring number of projects, their status, resource allocations (time, material, budget, people), issues monitoring and escalation procedures, project methodology used and project compliance to that methodology, etc. Managing the BI environment in a proper way existence of a BI strategy, governance bodies, management principles, financial measures (Return on Investment (ROI), Total Cost of Ownership (TCO)), vendor management process, etc.
BI Solution architecture components This is the performance measurement of the technology and tools that are used. Points to monitor include:
Source system parameters important for the BI solution their numbers, platforms, data extract availability, reliability, source data quality, interface description existence and quality, etc. Data integration Extract, Transform and Load (ETL), Enterprise Application Integration (EAI), and other data movement tool parameters numbers, platforms, run frequency, amount of data transmitted, metadata and/or descriptions, data quality, reliability, etc. Data storage structure of the databases and platforms numbers, size, data format, data aging, etc. Analytic applications types of analytical tools used (reports, OLAP, Data Mining) size of analytic databases, usage, types and usage of Data Mining tools, aging of the models, quality, reliability, etc. Presentation tools reports types, numbers, refresh periods, number and history/profile of accesses, reports reliability, quality, usefulness; consistency; understanding, etc. Organizational units using the BI products number of users, frequency used, amount of relevant data, etc. And there may be many others
Organization-specific components
For all measures, a standard definition should be used in order to avoid confusion. Below is a sample of how a measure should be defined:
Metric Metric Name ID Description / Purpose Business owner Name of the metric Identification of the metric (unique ID in the whole metrics system) Description and purpose of the metric Name of the person with overall responsibility for maintaining the
23
ABCD
metric Metric steward Name of the person responsible for factual metric calculation Management Related to business areasBusiness areas in which the metric may be used Related to processes Processes in which the metric may be used Units in which the metric is expressed Units (e.g., percent, pieces, 000s) Data Type Data type of the metric discrete / continuous The way the metric value is obtained (e.g., calculation, specialist Measurement Measurement method estimates, organization records, interviews with the top management, independent research, etc.) Calculation method Calculation method / formula The whole range of acceptable values and interpretation of the Values range values (if needed) Identification of the parent metric (i.e. higher level metric in the Predecessors metrics tree) Identification of child metrics (i.e., lower level metrics from which Successors the current value of the metric is calculated) Definition of metrics relevance to particular dimensions for Related to dimensions Multireporting purposes ( applicable only for detailed metrics) dimensional Aggregation (Metrics The aggregation method when drilling up in the Metrics Hierarchy space Hierarchy) dimension Aggregation (Data The aggregation method when drilling up in the Data Storage Storage) dimension Aggregations (other The aggregation method when drilling up in the dimension hierarchy dimensions) (e.g., none / sum / average / minimum / count)
3.6
Tools
The tools used for BI Governance should support its main function to steer the complicated environment with as much elegance and effectiveness as possible. As described above, the BI Governance is mainly about: Setting up the rules of the game. Setting up the organizational structure in order to help manage, control and enforce the rules. Setting up the monitoring system in order to help enable the organizational structure to work effectively. Document management system in any form, enabling effective work with the documents forming the management principles. Workflow management system enabling effective communication. Sets of different repositories in any form, storing information about the BI solution, its single components, roles and responsibilities, projects, etc. The typical repositories may be:
Therefore the main tools used for BI Governance are:
List of management principles and other important documents (such as BI Strategy).

24
ABCD
List of roles and responsibilities within BI environment. Repository of end users. Repository of end user requirements. Business dictionary. Overview repository of BI solution components and their content (if possible). Repository of BI outputs reports, extracts, interfaces to other systems, etc. Repository of OLAP cubes, Data Marts, etc. Metadata repository (technical).
25
ABCD
Introducing BI Governance to the organization

Introducing BI Governance is neither straightforward nor an easy task. Although it brings benefits and may appear to be natural and essential part of the whole BI environment, it is not easy to put the ideas into practice and make the overall concept work. The reasons for that are different, but the most common are: Company culture Natural resistance of people to change A culture of lack of resources for governance activities lets spend it wisely and create five more reports
4.1
Approaches to BI Governance introduction

The particular way of introduction and implementation of BI Governance programs differs from company to company and may use any of the three classical approaches: Top-down Bottom-up Mixture of the two previous approaches
Top-down approach
This approach may be used in organization with a strong management culture. Essentially, all the BI Governance components are prepared, then announced and established. The advantage of this approach is as follows: All management principles, organizational support and metrics are prepared concurrently and support each other in the most effective way. In an appropriate company culture where people will follow the rules, this the most effective way of introducing new policies and measures. It is easier to maintain a standard approach if driven top-down. There are not that many organizations where this approach can be used as it may require a significant time investment from management. BI Governance requires buy-in and adherence from all levels of an organization. This is difficult to obtain when significant portions of an organization are left out of the design of the BI Governance program.
The drawbacks / risks of this approach are as follows:
26
ABCD
Bottom-up approach
This approach may be used in organization where there is a strong reliance on customs and tradition or where the people are reluctant to make big changes. The main features of this approach are as follows: Build the BI Governance on existing management principles check what components of the current policies, standards and informal leading-practices may apply and use them.
As it is used, start to formalize it always find the opinion makers and ask them for their support; the reasoning for formalization is something like we are already using it and writing it down will help others to follow along. When formalizing current status, make sure you continue along the current road be sure your policies dont go against each other. If you need to introduce something brand new or change the existing procedures, always prepare good reasoning; ideally pilot it somewhere and then use the pilot as a demonstration of its value.
When finished (or when at least significant progress has been made), start working on the supporting organizational structure find the people you need to involve in the BI program and try to persuade them to join. Create informal bodies as much as possible, but sooner or later you will need to formalize the structures.
When creating the formalized bodies, always use the standard organization change procedures valid for the company its the only way to reach your goals. Support the job with the tools, people will then find out their jobs and responsibilities on their own. Draft KPIs in order to better explain the goals of governance roles, but let the organization work for a while without formalized measurement; give the people time to adapt to the new positions; fine tune the job descriptions and make sure everybody understands his/her purpose and goals.
Gradually start measuring success, and move the environment to a business as usual mode. It is applicable and demonstrates some success in the majority of organizations. It helps enable tailoring the BI Governance to the organizations specific culture. It takes a long time. It may create a non-consolidated environment with opposing forces. It often leads to non-standardized approaches. The credibility of the BI environment may be lost before the BI governance program is completely in place.
27
The advantages of this approach are as follows:
The drawbacks/risks of the approach are as follows:
ABCD
Combination of both
In most cases a combination of the two extreme approaches is the best approach. You may combine the experience and existing status with the conceptual standpoint and support of the top management when creating the major building blocks of the BI Governance System. The advantages of this approach are as follows: It leads to success in the majority of organizations in a reasonable time frame. It is simpler and more effective to do certain changes directly and with the support of top management. It results in a tailored and well-balanced steering system. The amount of standardization can be driven centrally. The approach can be tailored to the individual company culture. There will always be resistance to change and lack of funding for governance activities. Additional time should be spent planning and communicating which components will be handled by which approach, or risk some components getting forgotten.
The drawbacks / risks of this approach are as follows:
BI Governance Tips and tricks

Always try to reuse as much as possible (especially for management principles), but be sure the material / habit you want to reuse will help the case. Clients also like the fact that they can reuse or add to existing structures. This normally helps the business case for governance. Never underestimate the politics its the most important part of business life. Never forget its about changing peoples minds it always takes time and induces a reaction. Therefore the need for change management and clear communication is key. Never forget to have a final status and framework in mind when moving small steps ahead.
28
ABCD
5. Related Tools and Methodologies

Tool / Methodology Relation to [Technique Paper Title]
29
ABCD
2009 KPMG International. KPMG International is a Swiss cooperative. Member firms of the KPMG network of independent firms are affiliated with KPMG International. KPMG International provides no client services. No member firm has any authority to obligate or bind KPMG International or any other member firm vis--vis third parties, nor does KPMG International have any such authority to obligate or bind any member firm.
30

BI Governance Technique Paper v5

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

BI Governance Technique Paper v5

Hochgeladen von

Copyright:

Verfügbare Formate

The full scope of services within Business Intelligence is not permissible for SEC audit clients and their

BI Governance Technique Paper

Table of Contents 1 Business Intelligence Governance Technique Paper 4

2 Overview of BI Governance 3 BI Governance Framework and its components

3.1 BI Strategy...............................................................................................................9 3.2 Management principles..........................................................................................10

3.3 Organizational structure.........................................................................................14

3.4 Processes................................................................................................................20 3.5 Metrics ..................................................................................................................20

3.6 Tools .....................................................................................................................24

4 Introducing BI Governance to the organization

BI Governance Tips and tricks...................................................................................28

5. Related Tools and Methodologies

Business Intelligence Governance Technique Paper

To achieve these goals, BI Governance consists of six components:

Why and When to Use It?

How to Use It?

Unclear data lineage Underestimated need for communication and PR

BI Governance Framework and its components

Communication strategy Education strategy

Executive Sponsor BI Steering Committee

Communication / PR Education Help desk / support

Standard means of communication in the organization

Demand management Business analysis

End users repository Requirements repository

Manage Solution Architecture

Solution design Change management RFI / Vendor selection Project management

Metadata repository CASE tools SLA

Manage Change / Projects

Demand management methodology Change management methodology Project management methodology

BI Steering Committee Program Manager Change Manager Project Manager

Standard tools for change / project management support in the organization

3.2.1 Management principles for BI program steering and management

Usually, the requirements may be split into the following categories:

3.2.2. Management principles for subject matter management

Surroundings / Partners Enterprise Architecture

BI Governance Steering Committee

Data Management / Data Governance

Small Changes Project Team

Big Changes Project team

BI Governance Steering Committee

The major partners for the BI organizational units are:

Steering Committee level

No cooperation usually necessary Management principles alignment Knowledge exchange

Management principles alignment Knowledge exchange

Small changes and big changes implementation teams

BI Implementation Team Roles

Project Manager / Team Leader

Business Solution Architect

Technical Solution Architect Tool Specialists / Administrators Data Integration Developer

Data Mining Specialist

Operations and support teams

BI Governance Metrics Space

Setting up and meeting end user sastisfaction

SLA timescale compliance

User satisfaction index Existence of communication ...

Managing and meeting end user requirements

User satisfaction index Number of complaints ...

Following the management principles of solution architecture

Existence of the management environment (principles etc .) ,

Running the projects

Standard project measures

Standard project measures

Managing the BI environment in a proper way

Existence of BI Governance environment ...