Despite the critical role reports play in an organization, I have noticed that reporting governance is an area that is not given due importance. As a result, the inventory of reports tends to balloon uncontrollably, along with a proliferation in the use of applications and tools used to generate them. This makes it hard to maintain any kind of process around report creation, enhancements, and management.

To manage reports properly, you need to implement a set of sound governance procedures. The following set of six best practices is based on my experience managing reporting projects and advising companies on reporting governance. While some might sound like common sense, I am often astounded to see how frequently they are not followed.

1. Maintain a Comprehensive Reports Inventory

This is especially important if you are implementing an SAP system and you find out that the enterprise has a lot of reports that are not tracked. Tracking is a tedious exercise and usually takes a significant amount of time. It involves interviewing key users in various departments and often using your best judgment to get answers to tricky questions about report attributes. The attributes you should try to gather are:

• The department in which a report is run
• The source (e.g., a legacy system, ERP system, data warehouse system, or desktop application)
• The owner
• The nature of the report (e.g., operational, analytical, or tactical)
• Whether it’s currently used
• How frequently it is run

Figure 1 displays a reports inventory template that I frequently use. Of course, a template can be a lot more detailed than this. Depending on the magnitude of the effort involved, you can split the project into a few phases. The inventory shown in Figure 1 could then be the result of Phase 1, with subsequent phases going into a greater level of detail.

Figure 1

Basic reports inventory template

2. Establish a Reports Governance Council

Companies with strong reporting governance have a reports council or committee populated with key representatives of the departments that consume these reports and representatives from the IT organization. Such a council has well-documented procedures on change management, approval, testing, transport, and delivery of reports. The reports council meets on a periodic basis. During these meetings, all new reporting requests and enhancements to existing reports are reviewed and approved or rejected and sent back for additional information. The concept of a reports council is still new to most organizations and is more of a leading practice than a common one. But there are ample reasons for it to become a common practice.

I recommend the following policies and procedures to maximize the effectiveness of a reports governance council: 

• Requests for new reports and enhancements to existing reports should be made in the correct format and be accompanied by as much information as possible (e.g., purpose of the report or change, estimated time and effort to build it, and frequency)  
• The council should set a threshold for time and effort for each request that determines whether it could be developed without passing through the reports council vetting process. This is especially true for queries (as opposed to reports) that end users develop, such as SAP NetWeaver Business Warehouse (BW) queries or SAP Queries. For queries that take a limited time and effort to design, going through the council vetting process can become an exercise in bureaucracy. 
• Ensure that the request (if it’s for a new report) clearly identifies the security requirements. You don’t want a report that was meant for a certain segment of users to become available to all users because security was never considered and therefore never implemented.

3. Maintain a Robust Change Request Process

Many organizations unwittingly amass a mountain of requests because of a lightweight or non-existent change request process. It often contains duplicates, minor variations of the same query or report in the form of multiple queries or reports, and reports that were created for one-time use. With a robust change request process, you can avoid many of these problems. You should use a reports change request form that obtains all the necessary details. Questions such as the following are of special importance:

• “What is the purpose of this change?”
• “What is the impact of not making this change?”
• “What are the possible workarounds?”

While a lot of organizations tend to take the path of least resistance and use a paper-based change request management process, the inefficiencies inherent in this method can quickly catch up with them. It is important to use some application — home-grown or common off-the-shelf (COTS) — that helps automate and track this process. As organizations become smarter with such applications and processes, they can introduce a workflow that routes requests to the relevant approvers automatically. In turn, these approvers take actions to trigger a response (e.g., in the form of an email notification) that goes to the next group.

Regardless of whether you follow a manual paper-based process or an automated one, there should be a clear audit trail of the change life cycle. This includes clear sign-off requirements at every step of the approval process. This is not only important from your organization’s governance perspective but also from a Sarbanes-Oxley segregation of duties (SoD) or IT audit standpoint.

4. Plan Security for Reports

With the growth in popularity of end user-focused tools and technologies (e.g., dashboards, portals, and mobile solutions), it is easy to forget the importance of building security into your reporting solutions. While it is great to have information available at your fingertips that can give you a competitive advantage, certain traditional regulatory needs have not changed. Here are four of the considerations around planning for security for your reports and queries:

• Who are the consumers of your reports and queries?
• What are the data access needs of your consumers? It is reasonable to expect that different consumers of the same report have different data access needs. This should be determined up front. As an example, consider a cost center report that is used by various cost center managers in an organization. A typical security requirement could be that the manager of cost center A should not have the ability to view the data of cost center B, which is managed by a different manager.
• There is a common (and misconceived) notion that all results of reports or queries deployed on a portal or mobile device should be accessible to all users. In fact, the security requirements for reports or queries deployed on a portal or mobile device should be identical to those deployed on traditional media (e.g., SAP GUI).
• No report should be deployed without a thorough test of its security design. This security testing needs to include both positive and negative testing. Positive testing is the test that organizations commonly carry out. For example, if you need user 1 to have access to profit center hierarchies A and B, then positive testing affirms this. On the other hand, the test that companies do not frequently perform is ensuring that user 1 does not have access to any other hierarchy. This kind of negative testing should be done.

5. Implement Strong Data Governance Procedures

Some companies feel that reports and data governance are the same thing. There are some similarities but there are lots of differences. Reports are only as good as the quality of the data. If data in your source systems is inconsistent, unreliable, or erroneous, there is very little that your reports can do. Strong data governance benefits your entire organization, and reporting is just one of the areas that benefits. Some practices that I have recommended to organizations are as follows:

• Get a complete understanding of the data in your organization, the various categories (e.g., master, transactional, and configuration data), and what kind of data falls into each of these categories
• Assign ownership to each distinct group of data. For example, take the case of customer master data. There should be one final owner of customer master data who is held accountable for its quality, consistency, and accuracy. This person should be the approver and reviewer for all changes made to customer master data.
• Ensure that clean data goes into your systems. For master data, it is important that data is entered in the correct format. Make sure that this is documented and that users are familiar with the correct formats. This helps reduce duplicates in the system. Duplicate master data (i.e., the existence of the same master data in a mix of formats, such as mixed upper- and lower-case letters) has wreaked havoc on reporting in many organizations. Also, if data is being extracted from a variety of sources, it is likely that it is coming in a variety of formats. Data cleansing, scrubbing, and harmonization become even more important. Make sure that these activities are carried out on a regular basis.
• Maintaining high data quality is a perennial process, not a one-time effort. Some organizations tend to treat this as an activity closely tied to data conversion during an SAP implementation. Once they are live with the SAP system, they do not actively involve themselves in the maintenance of high data quality. In this regard, it is important to follow a set of data standards and taxonomies that are consistent across your enterprise.
• If you are serious about data governance, you should not just put in a strategy and never monitor it. You should review periodically how well your data governance policies and procedures are working.
• In many organizations running SAP systems, it has become customary to use the Master Data Management (MDM) module as the panacea to all master data-related problems. Unfortunately, that’s not true. If you do not have a good master data management and governance framework, MDM may not be the magic bullet you are looking for.
• Plan for data growth and understand the implications this can potentially have on system performance. This is especially critical for reports. As businesses grow, data volumes multiply. Queries you run off your data warehouse (e.g., SAP NetWeaver BW) take longer to run ultimately slowing down the decision-making process. Closely related to data growth is the need for a data archiving strategy, which a lot of organizations do not have.
• In the same way that IT organizations have functional, solution, and technical architects, it is important to have data architects and, if possible, a data management team. This is not a new silo I’m suggesting organizations should create; your data management team can fit very well into your SAP center of excellence or your support organization.

6. Be Detailed and Complete in Your Documentation

Documentation is generally considered optional — not mandatory as it should be. I have lost count of the number of SAP projects I have been involved with wherein I have seen inadequate documentation. Economics is generally responsible for this situation, as companies prefer to have their SAP consultants focus their time on configuration and development rather than on documentation. The end result of such a myopic approach is that when your consulting team departs, the maintenance organization is ill-equipped to solve problems. This ultimately leads to a higher total cost of ownership (TCO). Most often, the maintenance costs are much higher than the savings realized in bypassing documentation in the early stages. Also, knowledge transfer that is not accompanied by adequate documentation is not effective. Therefore I cannot emphasize enough the importance of detailed documentation.

Here are four recommendations for documentation based on my experience on many reporting projects:

• For any report or query, you need to document the requirements and specifications, technical design, test cases and scripts, configuration guides, and end-user guides
• There should be a designated sign-off person or group of persons from your organization’s maintenance team or SAP center of excellence for each category of document
• You should document in the source code of a report or query that requires a programming language (e.g., ABAP) or routines such as Visual Basic Access (VBA) macros in SAP Business Explorer Analyzer. Inadequate comments and explanations in key areas of the code can cause maintenance nightmares. One of the biggest pains in software applications is deciphering and debugging code that is not yours. Therefore, your technical resources (e.g., developers) should review whether the documentation in the report programs and routines is satisfactory.
• If an SAP implementation is going live and your implementation or consulting partner is rolling off, user guides, manuals, and all specification documents should be handed off to the SAP center of excellence or maintenance organization as part of the knowledge transfer process. Here, you can leverage the Project Management Institute’s (PMI’s) Book of Knowledge (PMBOK) Closing Process Group. Basically, you should consider the project closed only after you are ready to sign off. This sign-off process should include a review of the documents that have been turned over. If they are not of acceptable standards, you should not sign off.

Anurag Barua

Anurag Barua is an independent SAP advisor. He has 23 years of experience in conceiving, designing, managing, and implementing complex software solutions, including more than 17 years of experience with SAP applications. He has been associated with several SAP implementations in various capacities. His core SAP competencies include FI and Controlling FI/CO, logistics, SAP BW, SAP BusinessObjects, Enterprise Performance Management, SAP Solution Manager, Governance, Risk, and Compliance (GRC), and project management. He is a frequent speaker at SAPinsider conferences and contributes to several publications. He holds a BS in computer science and an MBA in finance. He is a PMI-certified PMP, a Certified Scrum Master (CSM), and is ITIL V3F certified.

You may contact the author at Anurag.barua@gmail.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.