frank ritter reporting governance

© 2007 Wellesley Information Services. All rights reserved.

Best Practices for Reporting Governance and Change Control

Frank RitterDirector, Business Intelligence Solutions

2

What We’ll Cover …

• Reporting governance: What it is and why you need it• Assembling your reporting governance team• Getting your reporting governance off the ground• Your next step: Four steps to clean house• Wrap-up

3

Reporting Reality at Most Companies

• There is chaos and anarchy in the corporate reporting world, and it is about to blow up! Too many reports Too many reporting systems Too many report owners No report owners Inadequate corporate performance measures Bad data Difficult to get to data Impossible to get to data Same data in multiple reports

4

Reporting Survey Results

• Company survey (by Aloys Hosman) 20 reports

487 measurements 35,000 data points 89% manual entry

• Typical complaints “We can’t keep up with the quantity of reporting requests” “Reporting formats are ever-changing” “Clear definitions are missing” “We never get any feedback” “What is HQ doing with these reports?”

Caution

5

Reporting Survey Results (cont.)

Category Sample comments % of times mentioned

Data awareness, training, communication

Don’t know what data is available, or how the data was derived

76%

Data acquisition and sourcing

Data gaps exist, same data item calculated differently, data source not arriving in a timely fashion

65%

Data management No dedicated reporting team, incomplete business requirements, lack of data ownership, same data requested for multiple reports

71%

Data access Manual merge of data, lack of access controls, limited time to access existing data, feeds going to silo marts with limited access to other groups

80%

Data quality Incomplete, inaccurate master data, incomplete/incorrect hierarchies, no organized process to capture and track quality metrics

82%

System performance and architecture

Poor data retrieval performance, constraints due to poor cube design, poor ETL design

65%

6

What Are the Root Causes?

• Authority for initiating report requests is not centralized Everybody can request a report from everybody

• Uncoordinated acquisition of reporting tools Different systems in each business unit/region No cohesive reporting strategy Multiple reporting tools in one business unit Dominance of Excel spreadsheets

Issue

7

• Lack of upstream interest for downstream effort No feedback from the recipient

• Responsibility for creating reports is delegated downstream Often to new associates who …

Don’t know all of your systems yet Don’t yet know who to ask for the right advice Have the desire to “be creative,” and want to do a good job

What Are the Root Causes? (cont.)

Issue

8

Solution: Reporting Governance

• Reporting governance defines how information is managed in an organization A properly functioning governance model enables faster and

more accurate decision making by driving responsibility and accountability for good data into the business organization

• The goal: To build and maintain effective and efficient reporting

processes based on clean, easily accessible data• It is driven by the need for:

Reporting process simplification Higher levels of compliance Delivering better information faster, to the right person at the

right time, and in the right format

9

In This Session ...

• How to construct a reporting governance organization that “works”

• How to categorize, track, and manage your change control requests successfully, and in a more timely manner

• The importance of involving security and authorizations in your change control process

• Special considerations for regulated organizations

10



11

Your Reporting Governance Team Is Your Gatekeeper!

• Key responsibilities: Keep the house clean by controlling:

Data awareness, communication, and training Data acquisition, sourcing, and management Data access and quality System performance and architecture

Establish and govern the rules for reporting requirements Create/change a new report only if those rules are met Ask the question: “Why and what for?”

12

Reporting Governance Organization (Gatekeeper)

• Centralized governance organizations Can be one person or a team Should include Business and IT representatives

Business representatives to determine validity of request IT representatives to determine information delivery

mechanism, source systems, etc. Criteria to decide who should be involved:

Type of process to be supported (PTP/OTC/FI/HR) Required subject matter expertise Required technical/application expertise Might not always be someone from Finance

13

Reporting Governance Organization (Gatekeeper) (cont.)

• Decentralized/virtual governance organizations Can include a representative of each business unit Can include a representative of each major process stream Should include Business and IT representatives

Business representative to determine the request’s validity Why is this report or change needed, and does it

make sense? IT representative to determine the appropriate information

delivery mechanism How is this request best fulfilled? What system do I use?

Which InfoObject? How do I deliver it?

14

Four Types of Governance Organizations

1. Single Gatekeeper

2. Business Intelligence Competency Center

3. Program/Project Management Office

4. Enterprise Information Management Groups

Building Block

15

1 – Single Gatekeeper

• Responsibility for reporting governance lies with a single person Data or metadata administrator BI architect Process Owner (Controller/Cost Center Manager)

• Most widely-used model today • Pros/cons

Pro: Relatively easy to implement Con: Limited focus on one function/department/application

16

2 – Business Intelligence Competency Center

• Tasked to establish, execute, and govern Business Intelligence (BI) throughout the enterprise

• Pros/cons Pro: Takes a holistic approach to BI

Defines strategies and processes Data management, sourcing, storage, reporting …

Covers organizational aspects Responsible for technology enablers and infrastructure

Con: More complex to implement as it constitutes a separate organizational unit

17

3 – Program/Project Management Office

• Tasked to establish, execute, and govern the project portfolio within an organization

• Reporting is part of project governance• Can be permanent or temporary • Pros/cons

Pro: Supports a structured, centralized approach to governance Con: More complex to implement as it constitutes a separate

organizational unit within the enterprise Con: Focus is typically more on IT project management, less

on overall governance outside the scope of the Project Management Office (PMO)

18

4 – Enterprise Information Management Groups

• Term coined in 2004 by Gartner, based on the trend to recognize information as an Enterprise asset

• Can be implemented as a Competency Center or a centralized group

• Creates the framework for all information management in an organization, including: Vision, Strategy, Organization, and Governance Processes, Reference Models, and Metrics

• Pros/cons Pro: Provides the most comprehensive governance, handling

all processes and tools related to reporting data Con: Complex to implement

19

Virtual Governance Organization Example

• Pharmaceutical company (regulated) Upgrade to SAP 4.7 and SAP BW 3.5 Identified one Gatekeeper (SAP BW architect) as the main

contact for all new report/query requests Virtual governance organization consists of:

Process Owners to review/approve new requests FDA validation representative IT Security/Authorizations

Used groupware and a document management system as centralized repository for all requests

20

Virtual Governance Organization Example (cont.)

• Telecommunications company Implemented SAP globally on one instance Virtual governance organization consisted of:

A global Gatekeeper for each major module Regional Gatekeeper as counterpart Global Process Owner and regional counterparts Regional IT Security/Authorizations Site IT support as primary point of contact for new requests

Use an in-house developed request tracking and approval system

21

Enterprise Governance

CIO/CFO

Example: Multi-Tier Governance Strategy

Application

DevelopmentNetwork and

Infrastructure

Data and

Reporting

Business and Technology TeamsBusiness and Technology TeamsBusiness and Technology Teams

Str

ate

gic

Go

ve

rnan

ce

Ta

ctic

al

Go

ve

rnan

ce

Go

ve

rnan

ce

Ex

ecu

tio

n

ACTION

22

But Governance Is Really Everyone’s Job

• Local information provider Provide the information used in reports Overall responsibility of upstream reporting on a topic Ensure alignment of master data with source systems and

standards definitions

• Corporate functional departments/users Users of the information Create new reporting requirements Provide feedback and promote efficient use of resources

23

But Governance Is Really Everyone’s Job (cont.)

• Information systems services provider Provides the enabling technology

• Information manager (Gatekeeper) Owner of the data tree Defines reporting systems specifications Decides how reporting requirements are best met

24


• Project team members Identify changes needed and complete the change request form

• Project Manager Receive change requests Approve, reject, or defer requests Assign priority to requests Review deliverables Owner of the change log

25


• Project administrator Log change requests in the change log Track change request statuses Maintains master record of all changes

• Assigned functional/technical project team members Investigate change requests and assess their impact on project

timeline, budget, schedule, and scope Develop specifications and execute the changes

• Steering Group Review and approve major reporting changes

26



27

The Reporting Governance Management Plan

• Objective: Manage each change request

During a project: Ensure scope is kept under control After the project: Keep your information management

house clean Ensure each change request is verified and approved

During a project: Responsibility of the reporting team After the project: Responsibility of the Gatekeeper

Enable orderly implementation of each approved change Allow the impact of all changes to be understood and managed

• But how?

28

Five Components of a Successful Governance Plan

1. Classify your change and requests

2. Instate a systematic change control process

3. Track all change requests in a change request log

4. All changes must use a change request form

5. Define and broadcast conventions

29

• Helps identify the root cause of reporting issues, e.g.: Lack of flexibility of a reporting solution Governance for user-based reporting is too tight

• Types of changes and requests New custom development report Additional data fields on existing reports Report format corrections Changes in report delivery mechanism Data source change(s) Planned changes vs. unplanned changes (bug fixes)

1 – Classify Your Change and Requests

30

• Step 1: Submit change request Have one central repository for all change requests Can come from a user or a team member (during a project)

• Step 2: Complete change request form Should be done by the user, with assistance from a team

member or Gatekeeper• Step 3: Assess, approve, and log change request

Gatekeeper in line with reporting strategy, guidelines• Step 4: Implement change

Develop new report or modify existing report• Step 5: Follow up and close the change request

Confirm delivery with the requestor and close the request

2 – Instate a Systematic Change Control Process

31

Systematic, Change Control Process Flow Chart

Team Member Identifies Need For

Change

Preliminary Approval ?

Change Request Investigated

Budget Schedule

Scope Impact ?

Project Manager(s)

Review Impact Analysis - Budget,

Schedule, & Scope

Change Request Considered By

Steering Committee

Approved ?

Rejected ?

Deferred ?

Implement Change

Emergency* or Minor Change

?

Project Manager(s)

Assess Change Request

Yes

No Yes

No

No

Yes

Yes

No

No

Log As Future Effort

Yes

Log As Rejected Change Request

Yes

No

Team Member Completes

Change Request Form With

Description and Justification

Change Request Considered By

Project Manager(s)

Project Administrator Logs Change Requests,

Statuses, & Changes

Log As Implemented

Change

Log As Approved Change

Log As Rejected Change Request

* Emergency Change to be

reported to Steering

Committee ASAP

32

ValidationTeam

Process Team

StorageSP 105

Update SP105M &SP115M

ReleaseSP105M &SP115M

Create SP105

Sign & Submit

SP105M & SP115M

Create SP115

Approve &File

SP115

StorageSP 115

Create SP116

Sign &SubmitSP115

Update TD

N : 1

Collect URs

Initial Creation SP105M

InitialCreation SP115M

Approve &File

SP105M &SP115M

StorageSP 105M

StorageSP 115M

1 : 1

Provide UR & FR Sequence Numbers

Sign &File

SP105

Get ChangeControl Numberfrom Trackwise

Approve CCApprove &

FileSP116

StorageSP 116

Sign &SubmitSP116

1 : N

SP105M and SP115M already

exist

Validation Document Library

Changes to existing requirements

“Change” instead of “Create”

Example Document Flow

33

• Change request log All change requests/new requests should be documented in a

change request log Supports traceability Ensures accountability Should be owned by the Gatekeeper

3 – Track All Change Requests in a Change Request Log

34

Change Request Log Example

35

• Change request control form – General data Format:

Web-based, access through a portal Paper-based (mostly during a project/limited team) Semi-automated as part of a document management

system/library/groupware Change request priorities

Critical: Necessary to avoid adverse impact to operations Important: Necessary for current business objectives Desirable: Features that would be nice to have

4 – All Changes Must Use a Change Request Form

36

• Change request control form – General data (cont.) Impact analysis

Estimated development cost Estimated delivery date Summary of anticipated impact

Approval information Approver, assigned resources, date

4 – All Changes Must Use a Change Request Form (cont.)

37

Change Request Control Form Example

38

Change Request Control Form Example (cont.)

39

Change Request Control Form Example (cont.)

40

Detailed Report Specification Example

1. Contact information Date, requestor, organizational information Unique number of the change request for tracking

2. General report information Title, description, functional area FDA or external/internal control relevance Expected data volume Complexity Priority/timing of delivery Don't

Forget

41

• 3. Business benefit/reason for change Reason needed

New legal requirement New business requirement Substitute for lack of system functionality

A workaround exists? Describe what the workaround is, who created it, how long

this workaround takes Give a reason why the workaround needs to be replaced

now

Tip


42

4. Detailed functional description Introduce the functionality needed in the context of the

business process Example: This report will provide the ability to track

forecast accuracy at the brand level by month Requirements

Example: This report will include absolute percentage error, forecast sales in units, and actual sales in units

Sort and summarize by month, with subtotals by brand


43

4. Detailed functional description (cont.) Assumption

Example: Forecast and actual quantities are loaded in units (each), each month by EOD 1 of the closing cycle

Dependencies Example: Forecast is entered manually through BPS

Planning Layout xyz Actual sales, receipts, and adjustments are updated from

SAP via interface abc


44

5. Sample Attach a sample report, print screen, or mock layout

6. Technical Specification A detailed description of:

Field controls, screen validations, calculations Selection and sort criteria, delivery options Aggregation levels Drill-down requirements, radio buttons, checkboxes Data sources, interfaces, batch-jobs Programming method


45

Naming Convention Example

Document: Example:

User Requirement UR-MM-01

UR-MM-02

Functional Requirement

Transaction

FR-MM01-MM01

Functional Requirement

Custom code

FR-MM4050-01

Functional Specification IT-FS-MM4050 v01

Design Specification IT-DS-MM4050 v01

46

• Regulatory environments require a more stringent control of all changes to your system Typically, dedicated validation resources are involved Full documentation of all changes Traceability of all changes through naming conventions Over 20 individual documents required in the initial

set-up/documentation of a Part 11 relevant system Responsibility and accountability ensured through a tight

review and approval process with many signatures Decide your validation approach wisely at the beginning of the

project to optimize documentation requirements

FDA Compliance Considerations

Tip

47

FDA Compliance Considerations (cont.)

User requirements document Functional requirements

document Technical design document GMP Risk Assessment/Report Audit trail list of tables Audit trail report Change trace matrix Integration test plan Integration test report

Computer application access matrix Operational qualification report Traceability matrix Training notifications/records

for users Training report Performance qualification report Quality review report Signature log Validation summary report

• Validation-relevant documents

48

Lessons Learned

• Start small. Don’t try to boil the ocean. Identify a key area to focus on first

• Make sure to embed security in your change control process Have one person be the point person in your governance team

that is responsible for security/authorizations

• Keep it simple and flexible Don’t overcomplicate the process by adding too many approval

and/or review layers. Governance should govern and ensure compliance, quality, and speed, not hinder the information flow.

49



50

Four Steps to Clean House

• Step 1: Create a reporting database Establish a database of all reports going to Headquarter

Start small Focus on one area/department/function Use company organizational charts and process flow

diagrams to define the scope of your analysis Identify the metrics on each report

Build a list of data points Identify dimensions

Build the reporting database Document quantitative information Document qualitative information

Solution

51

Four Steps to Clean House (cont.)

• Reporting database example:

52

Four Steps to Clean House (cont.)

• Step 2: Eliminate duplicates Identify identical data points and dimensions Identify identical source systems

• Step 3: Identify similarities Not all reporting requirements must use a unique data point Identify which ones can be substituted Don’t lose data quality, however

• Step 4: Build a data tree and eliminate redundancies Identify data that can be derived or calculated Create all reports based on this single source of the truth

Warning

53

Data Tree Example

Sales Volume

Product Dimension

Time Dimension

Geographic Dimension

By product category

By product group

By product brand

By product

By year

By quarter

By month

By week

By sales region

By sales territory

By sales org.

54



55

Resources

• Aloys Hosman – 5-part series on Information Logistics www.aloyshosman.com/2006/04/02/information-logistics-part-1-

its-a-mess/, April 2006

• B-eye Network Duffie Brunson, “The Many Moving Parts of

Governance,” August 22, 2006 www.b-eye-network.com/view/3284

56

7 Key Points to Take Home

• Reporting governance is a necessity, not a luxury• Clean data and ownership is half of the battle• Create a governance model by starting slowly. Don’t try

to do it all at once.• Identify the right organizational model for your

governance model• Create a nimble, but effective, change control process• Don’t forget to involve security/authorization people in

the change control process• Remember Part 11 documentation requirements

57

Your Turn!

How to contact me:Frank Ritter

[email protected]