Collated Insights & a way to resolve current BI problems

In my previous blog I highlighted problems that exist because of current approach to Business Intelligence (BI). Read Problems with current BI ecosystem.

In this article I will talk about the approach I took on working around those problem and deliver a better user experience. I'll start with the design thought that was adopted in search of a better BI solution. Like any business scenario, solution design always starts with defining a problem or opportunity statement. Because BI is a universal need, this search of problem statement didn't need any soul searching. This omnipresent problem statement from BI professional perspective is:

How to support better business decision making using technology, applications and best practices with collection, integration, analysis, and presentation of business information?

From here on, it takes shape of an interview or interrogation.

1. How are business decisions taken?

2. What information do business users need to make decision?

3. How frequently do they refer to facts?

4. How should information be delivered for most effective consumption?

5. What methods or analysis should be applied to data to simplify the judgement process?

Some of the answers were evident while others needed counselling from expert users. Because my focus is on IT Service Management within my organization, these answers were to be applied to a large organization divided into various IT Services managing different IT businesses. One thing that clearly stood out in the search of answers was need of standard set of metrics and KPIs. The purpose of BI is to measure performance of metrics/KPIs against goals, describe their attributes and diagnose their behaviour. Well groomed metrics are a bedrock of an effective BI process.

Design Paradigm

I treat BI like any other physical product or service. It requires input, processing and is delivered as product with an aim of reaching maximum consumer base. The best model to sell any product to maximum number of consumers is e-Commerce model. Make products available through a catalog and let people chose what they want. For maximum satisfaction, make products configurable so that consumers can chose the customizations as per their need. This customization ensures that while users don't have to bother about how products were built, they retain control on how it is consumed. We live in an era of heightened consciousness hence providing transparency about the processing mechanism adds to the value.

By now you would have already made the connection that I decided to offer BI in an e-Commerce model. I call this combination of e-Commerce and BI as "Collated Insights". In Collated Insights world; Metrics/KPIs are offered as products from a catalog of metrics where they are neatly categorized by business processes for easy search. All a consumer has to do is select required metrics. Once selected, these metrics start showing in a pre-configured dashboard template such as a card based view that shows absolute numerical values and a graph over a time scale. Before I start explaining about how my team achieved this, lets spend some time understanding philosophy of Collated Insights.
Collated Insights is a way of analysis that can be distributed and reproduced on demand. As the name signifies - it follows a methodology of collecting and combining insights. This methodology has two primary components - collate and deliver.

Collate
This is the most important of the two processes. In this process, focus is on collecting, compiling and codifying the organizational metrics. It should ideally be done by someone who has good understanding of the business and inclination for continual improvement. Metrics must be properly designed, understood and collected; otherwise they can lead to a trust deficit in them which can be very dangerous. Metrics should be comprehended in their business context with a very clear understanding of what metrics are used for improvement vs performance. Wherever possible, metrics should be defined tops down i.e. start with business measures such as profit, turnover etc. and follow the trail to operational metrics. It is paramount to establish a metrics registry that is enduring and available for reference. This process is akin to establishing a business vision and architecture where rationale and implications should be clearly marked out. A good metric is one that can be tied to an action. Clearly detail metric attributes such as data source, unit, access requirements, thresholds, targets, boundary conditions etc. Each metric must have associated measures which are used to value these metrics. As an example a Time To Resolve (TTR) for support tickets is a metric which can have possible measures such as Total TTR, Mean TTR, TTR percentile etc.
Here's a template for building metrics:

Metric Name: Time to Resolve (TTR) Incidents
Description: This KPI indicates the total amount of time taken (in hours) to resolve incidents.
Source DB Server :
Source Database Name :
Source Database Table :
Column : DurationMinutes
YTD Field (time attribute by which duration is calculated): Incident Resolved Date
Unit: Hours
Measures:
a) Total TTR
Measure Description: This measure is calculated as the sum of total time (in hours) spent in resolving incidents.
Formula: SUM(DurationMinutes)/24
Conditions: <boundary conditions e.g. SQL where clause statements>

b) Mean TTR
Measure Description: This measure is calculated as the average of total time (in hours) spent in resolving incidents.
Formula: AVERAGE(DurationMinutes)/24
Conditions: <boundary conditions e.g. SQL where clause statements>

Deliver
This is where technology plays the major role. Emphasis needs to be given on the way these collated metrics and their associated measures are delivered. BI and analytics is used for business transformation hence ensure it covers three important aspects of people, process and technology. The underlying delivery mechanism should have following attributes:
a) People (Adaptive)
        Easy to Use/Intuitive
        No specialized skill required
b) Process (Excellence)
        Codified
        Single Version of truth
        Fast Response
c) Technology (Leadership)
        Cutting Edge
        Scalable

While Collated Insights shares many aspects with traditional BI approach, the differentiating factor is how metrics are delivered. A well designed Collated Insights solution reduces the time to market, cost and trust deficit in the organizational BI ecosystem. In the next and final blog I'll explain the architecture that was used to deliver it.

Problems with current BI ecosystem

What is it that first comes to your mind when you hear decision support system and business intelligence. To an enterprise knowledge worker, these are synonymous with dashboards and reports. With increasing hype and commoditization of data processing, pivoting and visualization tools;  BI and insights applications have penetrated well into many enterprises. Among these applications, there are three primary market segments - 1) generic BI platforms such as Microsoft BI platform, Microstrategy etc., 2) Industry specific BI platforms such as Salesforce Wave Analytics etc. and 3) Visual Insights Platforms such as Tableau, QlikView etc…

A BI ecosystem in an enterprise typically works in a bi-modal approach; where an enterprise BI team hosts BI platforms while businesses use these platforms to build reports and dashboards for their analysis. For most parts this is an excellent modus operandi except for the fact that it overlooks an important BI need. In any organization where business units standardize their structure, processes and activities; this bi-modal approach to BI becomes inefficient, because same business unit services end up building silo'ed solutions for common BI needs owing to similar processes and activities. A good example of this case scenario is IT service management. In IT Service Management, IT performance is tracked via process indicators for processes such as incident management, change management etc which are delivered through enterprise ITSM tools. This common business structure leads to common metrics and underlying data. To meet these common BI needs, organizations build management dashboards that are used by executives for performance tracking while service operations teams build their own reports for ad-hoc analysis.

This bi-modal BI approach for common business structure leads to following issues:

1. Same metrics when delivered by different business services end up delivering different results due to difference of understanding, biases, lack of codification and overlooking of data quality issues.

2. Duplicate development cost and delay

3. Unequal performance comparison

In fact, with every organizational restructuring, these BI needs re-emerge leading to perpetual BI development of similar order. Additionally standard BI ecosystem still suffers with three major problems:

1. High development cost and turnaround time on canned BI reporting

2. Data understanding and reporting skills required for self-service reporting

3. BI Reporting & Advanced Analytics are more or less still two separate silos

Let’s understand these issues in more detail.

1. High development cost and turnaround time on canned BI reporting

Let’s first understand how a BI report [dashboard] is developed. 

• Identify business process metrics to be monitored
• Identify data sources
• Identify data elements
• Build datasets
• Build data models (optional)
• Develop report template
• Bind report to data elements from datasets/models  

This is a standard approach to build a report or dashboard with few possible variations. This process may take from weeks to a few quarters based on data quality and report complexity. Now if a business needs to have multiple reports or dashboards – this whole process is repeated times the number of reports required, notwithstanding same metrics appearing in multiple reports. Not only is there a repetition of the process but also the datasets get cast in a particular fashion owing to the reporting style. The next time there is change in data schema, the risk looms large on potential report breakage. 

 

2. Data understanding and reporting skills required for self-service reporting

While Self-Service reporting addresses the cost and TTM issues, it brings in fresh set of requirements to be fulfilled. Self-service reporting requires business people to be in constant know of data models, data elements and reporting tools. Against canned reporting - Self-service reporting demands a discipline by users to share the results with all concerned stakeholders, so that everybody is aware of results. However in practice it’s hardly achievable; not to mention different business units might want to see results in their own way. When this discipline is not maintained and every business unit builds their own self-service report – a problem of “multiple versions of truth” arrives due to the fact that different users have their own interpretations of how a metric is calculated and boundary conditions are to be observed.

 

3. BI Reporting & Advanced Analytics are more or less still two separate silos

While Advanced Analytics has the ability to deal with abstract information, BI reporting requires a structured data approach. Usually Advanced analytics results are shown using BI reporting but if a demand arises to return to analytics to calculate the results on the fly, it becomes a challenge next to impossible. Let’s understand it by an example. 

Suppose we want to understand how a service is performing on “Time to Resolve (TTR)” with respect to the incidents that it is responsible for. The standard way would be to monitor average which is simple to calculate and report. However average is not an accurate indicator for a large range of data values. The right way is to understand the distribution of TTR and determine what percentage of incidents is causing how much TTR. The simplest way to do this is through percentiles/quartiles. However most standard BI reporting solutions are not capable enough to provide percentiles. They might deliver for the overall volume but they can’t really perform, once slicing and dicing comes into the picture. BI reporting’s inability to work in sync with advanced analytics solutions puts them in silos.

 

These problems are more of a legacy design flaw rather than technical roadblocks. BI vendors mostly focus on reporting and dashboards than on advanced analytics because advanced analytics is very domain specific and use case centric. The existing BI solutions try to expose data to end users because all domain specific metrics are not pertinent and tend to change for different industries.

At first these issues may seem like universal problems with no known solution, but the fact is; these are the problems associated with the current approach to BI. These issues are resolved when an alternative approach to BI is considered. In the next blog I'll explain how I fixed these issues and delivered better results that scores well on every drawback that current BI ecosystem has.