Taxes are enough to make most people’s heads spin, especially as they try to navigate the changes from one year to the next. Hopefully, you’ve never had to make significant adjustments to your taxes, but if you have, you know how maddening it can be.
In an organization, Business Intelligence is the same. Creating custom reports requires an intricate approach. Making sense of those reports requires a trained set of eyes. Just as painful as when there are changes to taxes, when the underlying system, or the data feeding those custom reports changes, it can be a struggle to make sense of what needs to be adjusted. Because Business Intelligence touches nearly everyone in the organization, it’s easy to assume it’s on the top of everyone’s mind. The reality is, it’s not.
During a technology transformation project, teams are so laser-focused on figuring out the business processes, building the applications, and setting up the data that they frequently put off reports until the end. You do not need reports on Day 1 of a new tech product release, so reporting specifics languishes on the to-do list. But, if you’ve ever had to scramble to produce last-minute management reports during the first week after go-live on a tech project, then you know why this can be an excruciating experience. It’s prudent to put reports up front and center in your discovery and design phase to save yourself and your teams a lot of pain in the long run. Doing so accomplishes three things:
(1) Identify the web of stakeholders who will be impacted by reporting changes so you can proactively manage those change impacts and prevent unnecessary escalations after go-live;
(2) Clarify and shape the future state organization design by exposing the matrix of report producers and consumers across the organization; and
(3) Identify additional key requirements that would have otherwise gotten missed across process, data, and security.
Reporting is Never As Easy As You Would Like
Historically, reporting tended to be an afterthought. Instead, the development teams and engineers focus on their new application’s processes, features, and user experience. After building the system and making data available, teams consider the process for addressing reporting requirements. Even then, they often decide to do more testing and put off reporting for another month!
Here’s the critical thing to remember — management reports are never as simple as you’d like. In most cases, the way that an end report gets to an executive always involves a few shadow Excel files and heroic analysts doing accounting voodoo and data massaging. The higher up the ladder the report goes, the more massaging and secret sauce is applied. What starts on the screen of an analyst isn’t what gets hand-delivered to the C-Suite. There’s so much more to creating these reports than what the system produces. Excel magic, reductions in extra data, joins from multiple sources, and much more nuanced curation is required to eliminate the excess and offer richer insights.
When you accept that fact, it’s clear that reports involve so much more than a simple system output. It’s not a click it and forget it type approach.
There’s Always Another Source
You can appreciate why it’s a mistake to wait until the end of your technology project to look at the business intelligence processes. You might not realize what’s needed from a system, external sources, and shadow processes. These elements are required to create accurate reports used by direct and indirect consumers. Likewise, more can break when pulling together different data sources into a report or consolidating multiple reports depending on the need.
Ask yourself these questions as you start your reporting assessment:
- Who are the end consumers of this report?
- How many sources are needed to generate the data required for the report?
- How many levels of consolidation, curation, or massaging does this report need to go through before reaching the end consumer?
In answering those questions, you’ll better understand what systems need to work together, what datasets you’ll need to integrate, and what people you need to interview, all of which will answer why it’s a mistake to wait until the end to assess reporting.
Small Ripples Can Create Big Waves
When the key performance numbers change, it can cause a lot of key decision-makers to get nervous.
Consider this example. During a supply chain technology upgrade, a team adopted the leading industry practice for KPIs, and moved away from Line Item Fill Rate (LIFR) to On Time In Full (OTIF). Even though they adjusted the spirit of the long-term organizational gain, they did so without thoroughly evaluating the impact on all franchises worldwide. During late-stage testing, a panicked group of overseas stakeholders raised the alarm. The change would result in a drop in their fulfillment KPI from 99% to below 80%. This drop is a death knell to those franchise leaders as customer satisfaction is the primary measure of performance — and thus started the late-night panicked phone calls and escalations.
So what went wrong? The underlying performance of customer service and logistics was not going to worsen. If anything, the new technology would improve their speed and efficiency. What would change, however, was the what and how the same set of actions are measured. Once the executives understood the nature of the change, they were able to update management reports and educate stakeholders about how to bridge the old world to the new. Still, had there been an appropriate assessment of the impact up-front and early communication to align all the impacted stakeholders, everyone’s lives would’ve been a little easier. The moral of the story is this: if your project will be affecting operational KPIs, it’s a good idea to fully understand the possible ramifications of those changes early on to avoid 11th-hour surprises.
The Good, The Bad, And The Ugly
It is a foundational fact that key performance reports are vital to enable daily critical business decisions. Let’s call these “the good” reports. But it is also an uncomfortable truth that many reports have no value. Every new report starts as an excellent idea to serve some purpose. But there’s always another idea, and then another. It’s ongoing and never-ending. Our love of information compels us to let all flowers bloom and generate all the insights. Pretty soon, however, this garden of analytics becomes overrun with weeds. Dozens, if not hundreds, of random reports get diligently generated but never used. These are “the bad” reports, which, if eliminated, would have no one notice or care.
Now what’s worse is, as the analytics entropy reaches its peak stage, multiple duplicative and even contradictory reports from parallel sources or using different mapping logic begin to increase throughout the organization. Now decision-making is not enabled but impaired. Contradictory information requires tedious reconciliation or judgment calls to trust one report versus another one. Different groups use different reports about the same content and arrive at different conclusions due to lacking a single source of truth. We can call this last set of reports “the ugly” because they are not just ignored, which is a nuisance but harmless, but instead are actively in use, leading to error, conflict, or lack of trust in the underlying data.
A good habit in any major transformation project is doing spring cleaning to streamline business processes, reduce redundant tech tools, and clean up the data. Reporting should be no different! First, take stock of how many reports are truly needed now and which ones you can eliminate. More importantly, understand where reporting has become “ugly” and is causing tension, harm, or extraneous cleanup work. Because this exercise can be protracted and involve managing a few stakeholders through the change, it’s important to start early and give yourself enough time to do it right.
Project Intelligence For Business Intelligence
Starting a transformation project always involves a fair amount of uncertainty. Experienced practitioners know to invest in discovery and contingency planning early on to prepare for surprises. In the same spirit of scouting the terrain ahead, invest in understanding reporting changes early, lest you manage late-stage scope creep and upset stakeholders.
Share: