As data percolates to the top of the corporate structure, it passes through so many layers of processes and delays that it is oftentimes moot. Key Performance/Risk Indicators (KPI/KRIs) are, as the name suggests, vital to the operation of any institution. For these metrics to remain effective they must be reported on strategically to avoid the intricate Outlook rules our business users are weaving to handle the deluge of reporting they receive.
Our team (a BI team operating in a large bank) was tasked to overhaul a manual KPI/KRI reporting process that had a number of issues limiting the effectiveness of the end result. This manual process consumed human resources across several teams, was questionably accurate, metrics were obfuscated, and most offensive of all: too slow to be effective. Chief among the concerns was that there was no proof that the business was leveraging the results of this massive undertaking.
Having an existing QlikView environment, we looked for a product that would compliment our infrastructure. Specifically targeting the weaknesses of the existing process, we looked for a product that would allow for expedited and targeted alerting and accountability. We chose to introduce Metric Insights as a proof of concept to our business users, and it immediately began to add value. The proof of concept (POC) stage was so successful that we saw a chain reaction occur from our business manager straight to the top of the company. Originally brought in just to facilitate the automation for one department, as soon as the POC was shown to other managers within the organization demand grew to the point where I had audience with the CEO, COO, and CCO of the organization. This happened so quickly that we were nearly operating off of the POC prior to deploying the production environment.
The browser based alerting app sits on just about any data source (JDBC, Qlikview, Tableau, …) and efficiently pulls metadata from dashboards to populate metrics with relative ease. It has built in “social media” style commentary that allows users to create persistent comments on metrics or even data points on the metric itself. If for nothing else, the accountability this app provides was well worth our investment. Additionally, it is a powerful tool for strategically extending the reach and effectiveness of existing business intelligence initiatives within corporate environments.
Our project boils down to 3 stages:
Automation of manual metrics
The primary challenge here was to deconstruct existing processes and refine the logic so that we could stand behind the result of the metric. To do this we strove to create a simple, efficient, and transparent process for automating the metrics to remove human error from the equation. This often brought to light erroneous business logic that had been going unnoticed for years, or old business rules that no longer applied (archaic Crystal reports…).
Once we had automated the data collection in QlikView we brought the data into Metric Insights and created alerting rules around the specific metrics’ thresholds. We saw a quick adoption of Metric Insights after our first release. There was now accountability to maintain performing metrics with clear definitions and business logic.
Metric Data Exploration
Previously these metrics were only a simple count or percentage that the process owners aggregated for the purpose of the manual report. Some queries were being run by long forgotten processes created by employees that had long since left the organization; so nobody could attest to the underlying data. Not only does this reinforce the importance of the data being served up by Metric Insights, but is also shows the need for exploration behind the metric. To illustrate my point let’s use an example everybody is familiar with these days: network security. Data of this type comes from a third party vendor, is loaded into a Qlikview dashboard, and then aggregated via Metric Insights. Should an abnormal number of attempted intrusions occur in a month/week/day/hour Metric Insights would send an alert to the specified users. Those users would then have the ability to add commentary on the metric. To determine exactly what happened and why the pattern has emerged, the underlying Qlikview dashboard comes into play – what region did the intrusions originate from, how frequently has this happened, and has the vendor reported this occurring to other similar institutions?
Metric Insights stores useful user usage statistics in its MySQL database. While Metric Insights offers excellent usage alerting/reporting out of the box, Qlikview is a more appropriate option to create a more detailed dashboard. We have given key stakeholders in this project access to a usage dashboard in Qlikview that allows them to determine what metrics were viewed, last log in, and how often users are commenting. This will facilitate the behavioral implementation of Metric Insights as users who are not monitoring their metrics will no longer have anywhere to hide. Above all else, it will create accountability that business users are actively monitoring their metrics.
When an organization identifies indicators deemed critical to its survival, every step should be taken to create a simple and robust reporting solution around it. In this case, the team has leveraged Qlikview and Metric Insights to do just that. Before we started, thick stacks of paper containing obfuscated KRI’s were delivered to senior management offices. It was a chore; instead of being used to manage the business, they were sometimes just passed on to regulators. But in the first few weeks of our project, we witnessed a complete culture change: the realization of regular actions based on timely and accurate data.