Tuesday, May 1, 2012

A managers guide to understanding business intelligence. 7 steps to success.

 Data Analytics, Business Intelligence, operation analytics, reporting system and KPI’s. No matter what you call it, the idea is to understand your data and to leverage data to help make informed business decisions. The task can be and often is daunting but it is doable.
The seven steps.
1.       Process flow. First you need to have a general understanding of the business process flow. This can be a simple flow or complex but every process has a flow with inputs and out puts.
While working at BYU as an assistant network architect I had the opportunity to develop a five year network migration plan and researched and wrote the section on network monitoring and health. The first task in starting this process was to understand the underlying platform, its connectors and the inputs and outputs. To help with this I diagramed a large network map to visualize the various components and connectors. With any business process a map can and should be created to give insight into the flow of the process. Once the process has been mapped out the next step is to collect data.

2.       Questions. Understanding the questions you want to ask. In the last 20 years of working with business managers, systems and data the most crucial step is to know what to ask. You might think that you need to have the data, the reporting system, the analytics horse power and everything else in place before you can ask questions, but in-fact you would be wrong or at least very frustrated when you turn the system on the first time. Questions are key to any reporting and analytics system. Its so important that this started out as step 4 then I moved it to 3 and now its number 2. I am considering moving it to number 1. You need to write a list of questions you have about your processes. Make it a list of 50, then add on another 50 or more until you are satisfied. When you hand this list over to your developer or consultant they will look at you strangely and probably think, “this person is crazy, they want the imposable” but don’t worry. When you sit down with them in a room and walk through each one of the item, don’t spend more than a minute on each one, they will quickly understand what you want and their minds will start to turn. Note: if you don’t see the turning going on in their mind find someone else to work with, you have the wrong person. There are at least three very good reasons to write the list, it will help you define what you think you need, it will focus the developer and when you are all done if the system doesn’t have a way to answer question number 38 you can renegotiate.

3.       Collecting data is both easy and difficult. In today’s technologically rich world data is being collected every second. In fact, a large portion of the data collected today is thrown out, often the most important part of the data for any organization that wants to improve. Have you ever asked a question in a meeting and gotten the response “the system doesn’t track that information” or something to that effect. Often it’s not that the system can’t track the data but no one thought about adding in that 30 second change to the code that would have provided that critical missing piece of data. If fact, I was on a call the other day when I was discussing the possibility of collecting a piece of data to segment out certain customers and was told, that data is not stored in the reporting system. So while on the call, I pulled up the reporting database and looked at the data table and found that the column for collecting the data was actually in the database so I blurted out “the column is in the table”. The response was that during the development process someone decided not to add the code to populate the field. To fully leverage the collecting data stage, just say yes whenever someone says, “which pieced of data do you want to collect”. And please ignore the complaints about, “there is not enough storage”, “it will slow down the processing”, and the big one “it will take too much time to do the work”. It is true that it will take more time but when put it into perspective the time is minimal. It might add an additional eight hours of coding (probably only 15 minutes) but in the future that piece of data may help reduce labor hours 100 fold or more, probably more. The risk reward ratio can truly be fantastic. So collect the data.

4.       Short section on where to store the data. There are two types of data in my world, production data or transactional data stored in your production systems and reporting data. Reporting data should be stored on a separate server and should be formatted to optimize reporting.

5.       Getting to the data. The next step in the process is to pull some data. The availability of systems on the market to help you understand your data can be overwhelming but don’t be. You can spend $0 using a free database system and a free reporting system downloaded from the web (they actually work quite well) to tens of millions of dollars for a complex “over the top” system with every bell and whistle including the ERP, iPhone graphs and automated outbound reminder phone calls to customers. I’ve used both and many in between. Buy what you need. I have worked in small organizations with limited budgets where the business has hired someone with web programming and SQL query skills to write a series of reports to track daily performance and I have worked in an organization that had a team the size of a small company dedicated to supporting a multimillion dollar reporting package. In both cases the management team was only served when the system could answer the most pressing questions on that day.
 Note: SQL is the language used to pull data out of a database or in other words, the language used to ask the data questions and if written correctly, provide an answer.
 To get to the point pick a system that is affordable for you.

6.       Talent.  The system you buy is not as important as the people you hire to write the questions. If you have been in business long you probably already know this to be true. I would like to run through the list of available talent:

               Level i.            This is your basic level SQL programmer. They can pull a simple SQL statement out of a database and put it into Excel. Level i’s usually have no formal training but are great in a small organization. It may be a good idea to have mid level managers learn this skill.
              Level ii.            Advanced SQL programmers with training in one or more reporting applications. These guys are great at writing reports but require very good documentation in order to deliver what you expect. In the past few years India has trained a large number of Level ii resources.
            Level iii.            Advanced SQL programmers with training in multiple reporting platforms, custom programming skills and most importantly the ability to both understand the questions you need answered and how and where to pull the data themselves and how to direct others in pulling the data.
            Level iv.            This next level is a bit of a jump and many level iii’s don’t connect the dots to level iv but it is real. A Level iv can do and has done the previous levels but also has an understanding and the ability to use statistics to truly understand and answer your questions. The unfortunate thing is there are very few level iv’s in the market place. The good news is you can pair a level iii with a statistics major (maybe even an intern, maybe) and get a Level iv by grouping talent. You may be thinking to yourself, I can just stick with a level iii and we will be fine. I used to think so too. The issue is that I have seen more mistakes made by managers who interpret the data from a level iii incorrectly and as a result mis-spent countless hours and 100’s of thousands of dollars trying to fix the wrong thing. I’m not exaggerating, I have seen it time and again. The manager gets the data, says “a-ha!” look at that pink, there is way too much pink and its costing so much money but when a regression or sample-T test or whichever statistical measurement is appropriate its discovered that the real opportunity is with blue. There was a reason for the statistics class I took in my undergrad degree and a reason why it was included in my MBA curriculum at Kellogg. More importantly it is why Nielsen is able to generate over $5 billion a year in revenue. Statistics matter and if used correctly will produce results!
Get good talent.

The final step. Believe. Okay what does that mean? It means you and your management team and your employees all need to believe the data. Numbers don’t lie and contrary to popular belief, statistics don’t lie. If your team does not believe in the data you have wasted your time and your company’s money. Everyone needs some level of training to know how to use the system and to understand the data. Training has to be constant; a one-time push will not have the desired effect. In a typical installation I have to train every new hire and I have to retrain everyone else about once a year. It’s not that it’s hard to understand and the training doesn’t have to be long or intense, people just need to be reminded and helped through the process. You will find that people, trained or not, will come up with all kinds of ways to misuse the information or forget what this or that means. I chalk it up to being human, which is not a bad thing. Well trained employees will believe and they will use the data and they will find ways to become more efficient and your team will succeed.