BI Governance Technique Paper v5

© 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.

Advisory

Date

This report contains 28 pages

Business Intelligence

BI GovernanceTechnique Paper

FOR INTERNAL USE ONLYThis document is intended for internal use only,

not to be distributed to clients.

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 GovernanceTechnique Paper Guidance

AdvisoryFor Internal Use Only

Table of Contents

1 Business Intelligence Governance Technique Paper 31.1 What is it? 31.2 Why and When to Use It? 31.3 How to Use It? 4

2 Overview of BI Governance 5

3 BI Governance Framework and its components 73.1 BI Strategy 83.2 Management principles 9

3.2.1 Management principles for BI program steering and management 93.2.2. Management principles for subject matter management 11

3.3 Organizational structure 133.3.1 Board Level 133.3.2 BI Governance Steering Committee 143.3.3 BI User Community 143.3.4 Surroundings / Partners 153.3.5 BI Manager 153.3.6 BI Competency Center 153.3.7 Small changes and big changes implementation teams 16

3.3.7.1 Leadership roles 173.3.7.2 Business roles 173.3.7.3 Technical roles 17

3.3.8 Operations and support teams 183.4 Processes 193.5 Metrics 19

3.5.1 Metrics categorization 193.5.2 Dimensions / Standpoints 20

3.6 Tools 22

4 Introducing BI Governance to the organization 244.1 Approaches to BI Governance introduction 24

Top-down approach 24Bottom-up approach 25Combination of both 26

BI Governance Tips and tricks 26

5. Related Methodologies 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.

2

ABCD




1 Business Intelligence Governance Technique Paper

1.1 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 user’s expectations are set and met in the proper fashion.

The BI user’s 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.

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

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.

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


3

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.


4

ABCD




2 Overview of BI GovernanceBusiness 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 don’t understand data content in the same way

Users don’t trust the solution

Users require redundant work

Unclear BI development priorities and delivery terms

Workarounds developed

Disillusion / loss of credibility

Outputs don’t meet the quality requirements Workarounds developed

Disillusion / loss of credibility

Repeated requirements

Unclear data lineage Loss of credibility

Underestimated need for communication and PR

Loss of credibility


5

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 today’s 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.


6

ABCD




3 BI Governance Framework and its componentsBI 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.


7

ABCD




Mapping these parts to the four focus areas mentioned in the chapter above will create the BI Governance framework:

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


8

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.

Information about training, participation in testing, systems demonstrations, presentations and social events.


9

ABCD




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.

Technical users

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).

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.).

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

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.

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].

Project management methodology [Link to Project management methodology paper] – may be the organization’s 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


10

ABCD




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 solution’s 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 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.


11

ABCD




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).

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.


12

ABCD




3.3 Organizational structure

The organization’s structure, defined under BI Governance, enables managing of the BI environment’s 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:

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 buy-in 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 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.


13

ABCD




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 organization’s 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.

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


14

ABCD




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

The major partners for the BI organizational units are:

Enterprise Architecture department – partnering mainly at the expert level, exchanging the management principles, guidelines, standards and knowledge on both formal and informal levels. A business’s 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.

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 CenterIt is the know-how department of the program. (See also the BICC Technique Paper)

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 organization’s line of business specialist as well (functional bodies).

The responsibilities of the BICC include:


15

ABCD




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 pre-approval 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).


16

ABCD




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 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.


17

ABCD




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 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 and support teams support the solution operation and end users.

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


18

ABCD




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.

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:

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.


19

ABCD




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’ non-numeric answers to numbers.

When categorizing metrics in the BI Governance area, the result is a matrix similar to the following:


20

ABCD




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 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.


21

ABCD




Presentation tools – reports – types, numbers, refresh periods, number and history/profile of accesses, reports reliability, quality, usefulness; consistency; understanding, etc.

Organization-specific components

Organizational units using the BI products – number of users, frequency used, amount of relevant data, etc.

And there may be many others

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:

MetricName Name of the metricID Identification of the metric (unique ID in the whole metrics system)Description / Purpose Description and purpose of the metric

Metric Management

Business ownerName of the person with overall responsibility for maintaining the metric

Metric steward Name of the person responsible for factual metric calculationRelated to business areasBusiness areas in which the metric may be usedRelated to processes Processes in which the metric may be used

Measurement

UnitsUnits in which the metric is expressed (e.g., percent, pieces, 000’s)

Data Type Data type of the metric – discrete / continuous

Measurement methodThe way the metric value is obtained (e.g., calculation, specialist estimates, organization records, interviews with the top management, independent research, etc.)

Calculation method Calculation method / formula

Values rangeThe whole range of acceptable values and interpretation of the values (if needed)

Multi-dimensional space

PredecessorsIdentification of the parent metric (i.e. higher level metric in the metrics tree)

SuccessorsIdentification of child metrics (i.e., lower level metrics from which the current value of the metric is calculated)

Related to dimensionsDefinition of metric’s relevance to particular dimensions for reporting purposes ( applicable only for detailed metrics)

Aggregation (Metrics Hierarchy)

The aggregation method when drilling up in the Metrics Hierarchy dimension

Aggregation (Data Storage)

The aggregation method when drilling up in the Data Storage dimension

Aggregations (other dimensions)

The aggregation method when drilling up in the dimension hierarchy (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:


22

ABCD




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.

Therefore the main tools used for BI Governance are:

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:

List of management principles and other important documents (such as BI Strategy).

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).


23

ABCD




4 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 – let’s 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.

The drawbacks / risks of this approach are as follows:

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.


24

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 don’t 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 – it’s 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.

The advantages of this approach are as follows:

It is applicable and demonstrates some success in the majority of organizations.

It helps enable tailoring the BI Governance to the organization’s specific culture.

The drawbacks/risks of the approach are as follows:

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.


25

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.

The drawbacks / risks of this approach are as follows:

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.

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 – it’s the most important part of business life.

Never forget it’s about changing people’s 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.


26

ABCD




5. Related Tools and Methodologies

Tool / Methodology Relation to [Technique Paper Title]


27

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.


28

ABCD

Documents

BI Governance Technique Paper v5