Click to learn more about author Germán Viera.

Click to read 5 Pitfalls to Avoid from Real Stories of Analytics Projects (Part 1)

Where Do Real Companies Fail?

Every time an organization embraces the task of generating added value from their data efforts a great buzz darkens the scenario; mainly because of the lack of right guidance, but other factors also influence this mysticism about working with data and generating the proper information for the difference decision processes.

1.   Not Having the Correct Questions

The main objective of every Business Analytics project is to provide actionable insights. This means, provide quick answers to common questions during the decision process. In order to provide actionable insights, there must be an area of action, and even in a higher order, there must be correct questions to answer. When an Analytics Project wants to be deployed the management team which pretends to use the insights needs to provide the “questions” they want to be answered, be it by strictly mapping a question to an indicator, or by showcasing the kind of reasoning they want to shorten with the tool.

Last year we arrived at an organization where the management wanted a “Dashboard” with “actionable” insights over KPI’s. The main problem was that they did not have “actionable” metrics over their business as they were not an organization managed by KPI’s. They knew they wanted to see sales, stocks, sales people performance, and other information they gathered today, but never realised that the questions they needed to answer were based not in current numbers but in the comparison against different dimensions (sales over time, sales against last period, stock of store at certain point of time, sales vs stock ratio variation, etc.)

2.   Think That BI is Creating Reports

Business Intelligence is not “creating reports”. Creating reports is one of the edges of Business Intelligence. We’ve seen several BI Projects which its only motivation was to implement a tool that allowed the creation of traditional “reports” faster or “more eye candy” that can be exported to Excel to be later “analyzed” by the user. The implementation ended up being tables, with drill downs and ups that could have been implemented with traditional reporting tools accessing transactional data. IT areas ended up creating and maintaining multi-dimensional models that are only a copy of a transactional model, and used for the creation of table reports.

Before starting a BI Project, all stakeholders need to understand that BI Tools are created for analyzing data, that the value of the tools is the ability to create Measures that can be drilled up and down through hierarchies and that can be sliced through dimensions. The tool should provide insights for decision processes and not just a repository for crude data that can be navigated in a fashionable way. Analysts should detect patterns, and convert them into new metrics that will automatically provide alerts before any analysis is needed. BI Tools need to trigger action, not just provide information.

3.   Not Understanding the Data Process

The main pitfall in the implementation of real Business Analytics Projects is the lack of understanding of the data process within the sponsoring stakeholders. Last year we arrived to a retail firm (clothing) where the management team was analyzing different Self-Service BI Tools (Power BI, Tableau, Qlik). They were extremely optimistic in the usage of the tools and the added value they could provide to their decision process. They tried the tools individually, within their own environment, with “partial” data sources extracted from the corporate reports. The sales team and they internally sold the idea.

During the presales activities, we detected that the company had several stages of their business that were partially systematized and there was constant error generation by human hands. Their internal systems were not synced, and most of the reporting efforts to the management team were handled through handmade Excel reporting. So, there was a huge GAP between the real maturity of the data process in the organization and the perception of management of what they could do with data. We started the pre-sales process aiming for a Self-service BI deployment and we ended up working on data cleanup and basic reporting automation practices.

4.   Machine Learning Requires Human Design and Supervision

One of our first Machine Learning pre-sales started through a colleague lead that referenced us to a retail company. When we arrived, we met with the CEO and CIO of the company. They were amused about the Machine Learning Buzz and the products in the market. They have assisted to several conventions (MSFT and IBM to be more specific) and had seen the maturity of the products and some cases studies. As soon as the conversation started, their perception was that consultants (us) installed the Machine Learning Product, and that the product installed started to crawl through the data and provide valuable insights to the managers to apply to their business. (What?)

When we explained the REAL meaning of Machine Learning, how the tools really work, how training, scoring, comparison and usage of statistical models work, the scenario started to change. As intelligent people, they realized that they were sold smoke, that really working with data is a serious job, that it requires specific skills and knowledge and that it will require a specialized team, now and onwards.

5.   Big Data is Not a Lot of Data

Another common mistake in the Business Analytics space is the belief that because there is a large amount of data, new Big Data approaches need to be deployed. Of course, the confusion is at the non-technical level, or inexperienced technical level. This confusion might lead to the sponsoring of projects that do not have a real reason to exist. We arrived to a prospect that intended to consolidate all its system structured data sources into a cluster of NoSQL databases, and the IT area was planning to design a clustered server farms to deploy Spark MapReduce to generate metrics for reporting and analysis.

The project looked titanic, it required several really specialized skills not only at the data level, but also at tooling level and infrastructure. When we started to get involved in the project we were told that the corporate direction was to implement Big Data and use non-traditional techniques, because the data “was big”. After getting involved with their data sources, we identified several traditional SQL databases for ERP, CRM, Ecommerce, WMS, and an SAP deployment for their production data.

We did a volumetry analysis, and of course, there was a lot of data…. but nothing that could not be integrated in a well-designed SQL Data Warehouse with a simple Snowflake schema and processed with traditional multidimensional models as cubes, tabulars or just queries to the Data Warehouse (using fast storage techniques as column store index). After we delivered our conclusion to the CIO, the project changed to a traditional BI project, with well-known tools, corporate friendly, and with manageable complexities.

The Big Data term should be used only for data that cannot be processed in any way without the assistance of computational help. If you have a lot of data, but you can consolidate it, integrate it and analyze it with interactive tools, then, you do not need Big Data.

Five Areas Where Real BI Projects Tend to Fail
Images Source: SlideModel.com

Which is the Solution That Works?

The answer is simple, but not very useful: “it depends”. Every organization is a world itself and there are several solutions to the same problem. I will describe how we dealt with each of the five mentioned pitfalls in order to help reader have at least one option when facing it.

1. Questions Action: Make sure the deployed solution answers what final users need to know. This is a complex task, as I mentioned before, the core of the problem is not in the technology, but in the organization management style. My suggestion would be to carry out a business consultancy with the business stakeholders in order to understand which are the questions arose in their decision process. Help the management team to build objectives and metrics around them that will help monitor their performance through data, and make sure the monitoring and alerts can be deployed in the final solution. In this way managers will be able to answer questions quickly and take decisions without further analysis.

2. Reports Action: Make a test drive with the final user. Before even starting an Analytics Project, make sure that the final user is aware that the focus of this endeavour is not to show current information in a more “eye candy” way, or with the ability of new devices. Explain that the focus is to consolidate information and make it accessible through different dimensions at the same time without the need of traversing hundreds of rows. If the users consistently request deeper and deeper drills of crude transactional data, and huge tables as visualizations to export to Excel, certainly you should recommend a reporting solution instead.

3. Data Process Action: Always do a GAP Analysis over the data process during pre-sales. If you spot that there is a GAP within the data processing flow, this should be tackled first and deployed even before any analytics efforts are started. Creating a Data Warehouse or multi-dimensional model in this scenario would be like garbage in/garbage out.

4. Machine Learning Action: Before selling a Machine Learning solution, execute a proof of concept (POC) with real data and simple algorithms. A simple scoring over a very well-known variable will help stakeholders understand the efforts behind selecting, populating, testing, scoring a ML model and its predictive outcome. Most of the times, outcomes will be “probabilistic”, and stakeholders will also need to understand this. If there is no ground for such a POC, then for sure there will be no possibility for anything more complex.

5. Big Data Action: Review the major data sources of the required solution. If most of them (90%) are structured data sources, forget about Big Data. This means it can be handled through a traditional BI solution. Big Data’s main characteristic is that handling data is difficult, so if data is structured, it means that at least a basic handling is being done.

Conclusion

I expect you can make use of the tips and spot the pattern across your projects. Knowing this will help you in the kickoff and will set appropriate expectations within your customers.