Organizations are increasingly taking the initiative to embrace alignment and transparency in key performance indicators (KPI) and reporting. The heightened level of activity in this area is due to a multitude of drivers ranging from the implementation of a new reporting tool to ongoing concerns over the accuracy of existing KPIs and data. After all, only KPIs that are understood across the enterprise and supported by trusted data can deliver critical insights that can help businesses take informed decisions.

In this paper, we will highlight a process that can address common challenges with recalibrating the KPIs and reporting across the enterprise in a data-driven world.

Common challenges in reporting

Operational reporting is the lifeblood of nearly all organizations. When issues are encountered with the data that makes up the reports, the feedback from users can be very vocal and far-reaching.  Worse yet, this type of negative feedback will quickly erode the confidence of the user base in the data and reporting, and often is the catalyst for the emergence of shadow IT and reporting teams. This, in turn, can further transmogrify the issue as these teams create new unique KPIs and metrics over time for their specific area(s).  Several common challenges reported by stakeholders can include

1.       Data errors – Errors that find their way into production reports are among the largest concerns of any user base. Such errors can emerge from any number of factors; a failed ETL, delays in receiving external data, changes to source file structures. The critical information contained in these reports are used to perform jobs, make recommendations, perform sensitive strategic analysis, and when this information is incorrect or perceived to be incorrect, the business is negatively impacted.
2.       Time required to research and address errors - Nearly equally frustrating to the consumers of the reports and KPIs can be the amount of time required to research and address reported errors. Users report an error to their IT partners and then the waiting game begins, often with no estimate of the time required to fix the issue or worse yet, an update that the data is fit to be used. If a pattern of this begins to emerge within the user community, stigmatism can emerge that their IT partners may not have adequate technical skills to fully support the needs of the business.
3.       Time required to create new reports or KPIs – Another common point of frustration with user communities revolves around the amount of time that is required to make seemingly straightforward changes to existing or create new reports and/or KPIs. This issue can be symptomatic of several challenges with the enterprise data or architecture that may be beyond the control of the front-line support teams. However, in many instances, the reporting teams do not provide insights into the underlying processes that need to occur to correct the issue, or even broad time estimates for the amount of time required to operationalize the requested changes or new reports. This can further serve to negatively impact perceptions of the reporting teams.
4.       Report timing – Another common challenge with corporate reporting capabilities revolves around the data refresh schedule for the reports. The challenge with the data refresh process is brought to light in instances where reports contained commingled data from difference sources that are on different update schedules.  If users are unaware of when key data is updated or if the process is managed incorrectly, previously reported KPIs may vary over time or even within the same day. For example, if a review meeting is scheduled at the end of the day and a user prints the materials in the morning, prior to refreshing of its underlying data, and another attendee runs the same report later in the day, the potential exists for deviation between the two data pulls and confusion around data accuracy will ensue.

One practical solution is to ensure that reports document when source data is most recently refreshed, the definitions of key KPIs contained in the reports and explain how changes to historical data is handled in an appendix or footnotes of each report.

While all the issues defined above create significant impediments to report and KPI adoption as well as lessen confidence in enterprise data and reporting capabilities, a larger issue may be in play. The potential exists that many of the challenges related to reporting may be attributable to an absence of a consensus on the definitions of even the most common enterprise KPIs or worse yet, on how to measure the performance of the business.

Such scenarios arise when the reporting and analytics functions have not been actively managed and the various functional areas of the business have been required to develop their own analytics and reporting capabilities.  To be clear, this article is not a condemnation of embedded reporting and analytics teams but rather is being put forward to call out the potential risks when each business area creates its own team with no enterprise coordination.

A top-down approach to defining and managing KPIs

Aligning reporting and analytics functions is never an easy endeavor and leaders who bravely take on this challenge must clearly articulate the need to do so and their course of action or risk sending unintended ripples throughout the impacted areas of the business. This alarm can be triggered as owners over the respective areas may become naturally territorial at the perceived risk of losing a capability that provides them with the levers for managing their business and that they, in all likelihood, were required to develop over a number of years.

In such a program, several key parameters must be communicated at the onset. Foremost among the rationale that will be laid out should be that the these efforts are being extended to better manage, measure and analyze the performance of the business and the intent is to not take away any of the unique KPIs, data sets or reports that have been created across the business. This is not to suggest that change will not occur but rather the capabilities that the business has come to rely on will not be lost.

The starting point: Time for pre-planning

Executive oversight will be critical to the overall success of this program as it will touch multiple areas of the business, span across multiple quarters and require regular coordination across impacted areas of the business. Ownership, versus sponsorship, for this type of initiative is inherent due to a level of involvement that will eclipse a simple acknowledgement of the program in a project kickoff email or slide but will require some level of time commitment and potentially making several unpopular decisions throughout the project. 

It is also important at this stage to consider who will assist you in running this program. Initially you should consider identifying a strong senior project manager and later with the help of the team look for strong business analysts, data analysts, data governance support, change management team input and visualization / report designers to assist with the creation of any new reports that will be created as a result of these efforts.

As the executive sponsor, once you have committed to this undertaking you will need to allocate sufficient time to gather the KPIs that you are measured against and identify what additional KPIs are needed to give you visibility into each area of your business.  This pre-planning will pay dividends throughout the duration of this program and serve as the bedrock for your alignment strategy. Any oversights in this stage may create significant rework and additional planning iterations in the future.

Not every operational area may need to participate in this program. This should be determined by the previous exercise of determining the KPIs that are in-scope at the executive level.  Loosely defined, operational leaders who own the processes that drive the various KPIs should most definitely be involved.  Outside of the owners of these KPIs, it is good to create awareness but their participation in not critical.

It is also to consider at the onset how many levels in your organization that you would like to drive this change. The answer varies by company and typically centers on the size of your company, how systems-based data is, and how complex the organizational structure is.  A good rule of thumb to follow is that the any data that is embedded in an executive level report be addressed directly through this process.  Ownership should then be handed off the respective area leaders to oversee the process at the lower levels of the organization.

With an understanding of what KPIs are needed at your level, it is time to introduce the project to all the relevant functional leaders reporting to you and reinforce that there is an expectation that they will support the program and that their focused participation is required. Typically, this group comprises the project steering committee, which receives regular updates on the milestones and assists with removing any barriers that the project team encounters.  More importantly, the active participation by each of your leaders will help promote project ownership and heighten adoption within their teams.

Deconstructing enterprise KPIs

Once your team has been updated and enterprise KPIs identified, it is time to initiate one of the most critical stages of the program. This is achieved, in part, through a series of discussions or workshops with the steering committee members, internal data SMEs, and other team members with a deep understanding of reporting across the respective business areas.

The KPIs that are defined at this stage will cascade throughout the various operational areas where they apply. From a governance perspective, these KPIs will be ‘locked’ and supersede similar KPIs that will be discovered across the operational areas as well as lower levels of the organization. 

Each KPI must undergo a rigorous review that encompasses:

• Calculation Confirmation – We need to establish exactly how each KPI will be calculated.  What is the definition to be used for the KPI. This seeming straightforward step can have unexpected nuances if your company has multiple reporting teams. KPI definitions can vary from group to group and even report to report in seemingly well-run organizations.
• Source System Identification – With alignment achieved on how to define each KPI, we now need to look at the individual components of each calculation. To achieve this, we need to determine what the source system of record will be for each input. The importance of this step should be underscored as multiple systems may contain very similar data.  It is important to weigh the pros and cons of each system and its data before making a final determination. This step will also enable the team to complete the mapping and cataloging for each KPI as well as firm up any program documentation.
• KPI Refresh Cycle - One additional step that should be addressed at this stage is to determine how frequent each KPI should be updated. To achieve this, it is important to understand any dependencies that may with the various data sources.  Typically, this will occur with financial or external data sources that are provided based off a set schedule.

As the enterprise KPIs are finalized, work will then move to defining the KPIs within each of the operational areas in a similar manner.

Working horizontally across the organization

The next step will be to address each business area following the same process as previously described.  As we address the various operational areas, unique KPIs will emerge. The goal of this exercise is not to blindly rationalize any new area-specific metrics but rather to ensure that the critical enterprise KPIs are cascading throughout the enterprise correctly.

As we move to address the operational areas, we must do so with two additional considerations in mind.

First, it is unlikely that the project will have the capacity to address all operational areas at once. This will then require some prioritization to determine the cadence for addressing each area. There are multiple approaches that can be applied for determining the order with some of the more common approaches including; address the smaller areas first to establish some program momentum, identify the areas with the greatest overlap with the enterprise KPIs, select an area with the strong reporting and data teams, etc. What is important is that a schedule is defined and the various teams are aware of the upcoming effort that will be required to support the project.

Secondly, as we begin to address other areas of the business, we need to be cognizant of those KPIs that have already been defined at high levels of the organization. Recall that these KPIs are considered to be ‘locked’ and their definition and naming convention will be of a higher priority than those discovered in other areas of the business. To address this point, KPIs that have similar naming conventions or have similar definitions should be identified, reviewed, and updated if needed, to avoid confusion. For example, at the enterprise level, we may have validated a KPI called operating margin.  What we discover when we look at the manufacturing area is that a similar operating margin KPI exists, however when reviewing the definition, we find that different source systems are used that contains addition business logic and results in a slightly different calculation. In such an instance, the source systems will need to be updated to align to the enterprise calculation or the naming convention for the manufacturing version will need to be revised.

The same process of collecting, analyzing, mapping and cataloging each KPI will be followed for every identified area. Once complete, this second level of the business will then be considered ‘locked’ and supersede those discovered in lower levels of the organization.

Drilling vertically into each area

Once all the identified business areas have been addressed, the focus will center on the various groups in those areas. For example, continuing the manufacturing example, once top-level manufacturing KPIs have been addressed, the process will be repeated for areas such as, production, quality, inventory shipping, depending how your organization is structured.

It is important to note that as we drill vertically through the various levels of the enterprise, each level will again have its own set of specific KPIs that are used to monitor those areas but will not require upward visibility. For example, the COO will have interest in monitoring overall manufacturing efficiency, however, the details on the downtime of specific machinery within a manufacturing site may be too granular. That said, those details would be crucial for driving efficiency to the head of manufacturing or a plant. These operational level KPIs, will then need to undergo the same vetting scrutiny and cataloging for each area, as did the enterprise KPIs.

Once the data and reporting efforts have been completed for the identified areas, we are not yet complete. We must ensure that consumers of the reports and KPIs are aware of the recent changes to the KPIs.  Several processes must also be established to ensure that the efforts that have been extended to cleanse the data, KPI and reporting capabilities remain pristine.

Establishing a change management program to ensure adoption

A change management program is needed to support users during this period of transition. This is especially true as users are required to acclimate themselves to new data, tools, processes and KPIs. The change management program should be used to create awareness throughout the user community of pending changes. 

Information provided by the program should pulse information on key dates, directions on where to obtain new tools and the retirement schedule for legacy tools, data sets and reports. The information provided by the Change Management team should also work closely with the project team to create visibility around the impacted and newly defined KPIs.

Building a process to review existing reports and create new reports

Once the reports containing the KPIs have been operationalized, governance and review processes must be implemented to ensure sustainability of the reporting function. This process will enable reporting teams to maintain a control over the existing reports, KPIs and data as well as the development of new reports and future data acquisitions.

This can be accomplished through the creation of a data and reporting committee. This group should comprise of stakeholders from all operational areas who have at least a working knowledge of the reports and KPIs for their area. This committee will be responsible for establishing a regular review cycle of existing reports, enable revisions to existing reports and work with the business on the creation of new reports as well as the acquisition of new data sets when required. 

Effective KPI management

An effort to align KPIs across an organization require significant effort, planning and coordination. While each project ultimately encounters unique challenges as the team works through various levels of the organization, having a framework defined at the onset of the program will greatly lessen impediments. Additionally, defining processes to inform data consumers and protect the data integrity post-project will help ensure ongoing integrity of the newly defined KPIs and reports.

There are plenty of ways your enterprise can benefit from adopting a top-down approach to KPI management. To know more about our approach, reach out to our experts at ask.analytics@wipro.com