Case Study: A Win On Dashboard Software

Background

Company Y measures its logistics performance via several key performance indicators, or KPIs. These KPIs measure truckload utilization, on-time delivery, customer order fill rate (quantity shipped divided by quantity ordered) and several other metrics, by manufacturing plant, distribution center, brand, customer, sales region, channel of business and total company.

For many years, the raw data for these KPI reports came from several different software systems. People would extract data from these systems into Excel spreadsheets, where calculations were done, merged with other data, charted to show trends, and then emailed to managers and other users of the reports. Sound familiar? The process was time-consuming, manual and fraught with errors and redundancy. People in different parts of the company, for example, were all calculating and publishing customer order fill rate every day, week and month, duplicating efforts. Also, not everyone came up with the same calculated metric, although they should have, since everyone used the same underlying data.

The situation seemed to call for a rationalization of the process and some type of IT project, right? Maybe. In the summer of 2009 Company Y first turned to the same idea many companies think of – a centralized data warehouse. A data warehouse could capture all of the transaction data from the system of record – In this case SAP – and provide the same data to everyone in the company via a variety of queries and reports.

To build a data warehouse, and then enable reports and queries of the data based on user preferences is no small effort. Just to determine the design of the warehouse is a huge undertaking. For example, common data definitions have to be established (what is a ”customer” — the warehouse that orders the product, the entity that pays the invoice or the buying entity that places the order?). Also, different parts of the company must agree on relationships between the data. For example, each customer must be “attached” to a sales region, a sales manager and a price list.

Company Y could have pursued this data warehouse route, and probably with a lot of time and money would have been successful. But Company Y didn’t have that kind of time or money, so it sought a different solution.

By 2009 dashboard products had been on the market several years. These types of applications can take data from disparate systems, join that data according to user definitions, and display it in numeric, table or graphical format according to user-selected views. The result is something like an Excel spreadsheet with pivot tables, except that all the tables are already built and the data links are set up to run in the background. Company Y wanted a “dashboard” that would display the important KPIs every day. The dashboard would be the single version of the truth company-wide.

Company Y looked at solutions offered by the top-tier business intelligence (BI) and dashboard software providers, such as SAS, Microsoft, Information Builders and Cognos. All of these companies provided sophisticated BI environments that were overkill for what Company Y needed, so Company Y considered applications from smaller and newer firms that offered a simpler and less complex approach.

In a decision I would characterize as a smart IT investment, Company Y chose software from Qliktech Inc., a company whose marketing message is: “Traditional BI solutions have become bloated, complex software stacks, leaving users confused and frustrated. For 18 years, QlikTech has focused on simplifying decision making for business users across organizations.”

Qliktech’s flagship product, Qlikview, is basically a front-end aggregator of disparate data sources with graphical display capabilities such as charts and color-coded alerts. It is simple and intuitive for the user, and users can be trained to develop new dashboards on their own. Company Y purchased a server license and negotiated a one-time per user license. The combined cost was orders of magnitude less than building a data warehouse.

Company Y didn’t have to build a formal data warehouse because Qlikview could access data from Excel files, tables in a database or Microsoft Access. Company Y had already been capturing data from its core SAP transaction system for basic sales and cost reporting. The company stored this data in existing tables in an Oracle database. It was relatively simple to refresh the data in Qlikview each day from these tables.

Company Y continued to expand its use of Qlikview. Three years later, the company is using Qlikview for sales reporting, promotional funds spending, nearly all of its supply chain KPIs, transportation cost monitoring, some demand forecasting metrics, finished product inventory flow monitoring, and raw materials inventory management. More than 200 people use one or more of some 60 active dashboards.

Users give high marks to the application because all the data sourcing and calculations are done automatically every day, and they can slice the information in several different ways without running pivot tables or macros in Excel. Management is happy with the relatively low cost and high flexibility of the solution. Some users have learned to program their own dashboards; one user has developed a dashboard that runs macros automatically to create a day’s worth of purchase orders in SAP.

Key Points

Company Y avoided a huge expense and many months or even years of development work by choosing a relatively simple application. The company was smart enough to learn first what solutions the market offered, and knew that costs should be kept to a minimum because the returns were “soft” – administrative time saved by existing staff, not a true reduction in head count or labor cost.

Over the past three years Company Y has spent a fraction of the cost of a data warehouse yet equipped users with a robust set of dashboards that are used regularly to manage the business. The Qlikview dashboards at Company Y are in fact the single source of some important metrics. Moreover, the dashboards are centrally located so users who want to develop a new set of analytics can first peruse the 60 active dashboards to see if any of them fit their needs.

Company Y also made use of its existing data architecture, which, although not in any sense a data warehouse, had taken years to build. The data capture – the hardest part about implementing applications for analytics – was already done. The company didn’t have to re-invent its methods of retrieving and storing transactional data.

The project was also a success because it had a limited scope that satisfied the main business need, and was strategically wise because the low investment didn’t lock the company into a specific solution whose payback might have been years into the future.