BI Leadership

5 Things I Wish I’d Known about Business Intelligence

Do you ever wish you had a time machine? What would you go back and tell your younger self if you did? Thinking back over my career as a Business Analyst, BI Analyst, BI Manager, and my journey into BI Solutions Engineering, there are several things I wish I had known. At the top of the list is how to get even the most non-technical people self-service to BI so that I could’ve provided the value I was hired to create (instead of building report after report). 
Think about all the valuable data your company has stored… everywhere. How many true decision-makers inside your organization have the information they need to make critical business decisions on a daily basis? 25%? If that seems low, you might be surprised once you really start asking. But why is that?
Over the last 10 years, I’ve helped 100+ companies in the SMB market roll out reporting, BI, and advanced analytics. I want to share a few lessons learned and save you from some potential pitfalls. More importantly, I want to share lessons I’ve learned from other, much larger organization’s mistakes. For this conversation, I’ll focus on my experience in Supply Chain (specifically manufacturing, distribution, and retail), so we can learn how to unlock all that data stored in ERP, CRM, WMS, and DW and turn it into actual, usable information. 
Here are 5 basic lessons that would’ve saved me so much heartache, had I only known what I know now.

If you are a business intelligence practitioner, my experience may sound familiar. I started as a business analyst delivering reports in the olden days of Crystal, Business Objects, and SAP. Olden days I don’t miss at all. As I grew into a Sr. Analyst and Manager, the complexity grew too. MS Dynamics ERP, Salesforce, Esri GIS maps, and budgets in Excel. 100+ sales reps that needed better reports that a team of DBA’s, OLAP guys, SSRS specialists, and BI analysts were all struggling to keep up. 
Fast forward 5 years and along came more modern BI tools in the form of Qlik, Microstrategy, and Tableau. Prettier reports, but the problem remained. Constant requests, backlogs for days, pressure from the executives. So why did we continue to struggle after buying better reporting tools? I’ll start with the most obvious problems first.

Data is everywhere

Purchase orders, financials, and day-to-day operations in the ERP system. Sales pipeline, account management, and marketing in your CRM tool. Inventory and shipping in WMS. Forecasts in Demand Planning software. The list goes on and on. The logical journey for all this data led us to the Data Warehouse. In its simplest definition, a data warehouse is the single location for all data needed for reporting and analytics. 

Have a strategy and work towards it.

You don’t need hundreds of thousands of dollars and a seven-figure solution like Teradata to create a data warehouse. Even the basic license of SQL Server provides the foundation for extracting data from multiple sources, transforming raw data into cleansed and staged tables, and creating a data warehouse schema as a foundation. You just need a strategy. Ralph Kimball wrote a great book called The Data Warehouse Toolkit with some very insightful knowledge about creating and maintaining a data warehouse. Read it.
Let’s just assume all the data is in our data warehouse.  Now we simply have to get it back out. The next problem? It’s not so simple after all. Reports, dashboards, and advanced analytics-there are more vendors out there than you can count. So why is BI adoption still so low?

Not all users are analysts

Dimension? Measure? Attribute? You might as well be speaking another language. Turns out, you are. The rest of the organization speaks normal business language, they don’t think in terms of metadata, database schemas, or ETL logic. They have no clue what JDE looks like behind the scenes and why should they?

Learn to use the language of the business.

A hard lesson learned in my earlier years was the stark difference between what end users see in the software and what IT sees in the database. JDE has the F0005: User Defined Codes (UDC) and Dynamics AX has the AOT to help store enumerations, friendly labels, and translations between business and database but you need an expert in most cases to combine the two. Although much of this happens in ETL or data modelling, too often reporting tools are attached directly to the production database. When at all possible, ensure the language used in reports matches the exact same language business users see everyday in the ERP, CRM, etc.

You are not a mind reader

You know when someone gives you a request, so you spend hours creating the report just to hear “that’s not what I meant. I need…?” This problem always reminds me of the telephone game we used to play as kids where 10 people stand in line, the first person whispers into the next and a phrase is sent down the line just to have the last person call out the phrase that was absolutely, completely, utterly wrong. Remember that one? Yeah, that still happens in the BI world every day, except people don't laugh when the request gets misconstrued. Another one I love to hate is the request for a report that, because of your backlog, takes a few days to deliver just in time to hear “oh, I don’t need that anymore…”

Your time is valuable too, get clarification before wasting your time.

You can easily waste your time building something that is incorrect or unneeded, so check in with your end users often and get clarification. You were most likely hired to do more than build report after report. Spend some time with your end users, understand their business, then work on providing the information they need to make better decisions. Do this well and you will quickly become their trusted advisor/subject matter expert with a clear path to promotion.

Growing companies have growing needs

As your business grows, your business systems become more complex and are always in a constant state of flux. For example, Microsoft Dynamics needs upgrading so you spend a year evaluating SAP, Netsuite, and Oracle EBS. Salesforce is a mess—and don’t even get me started on data quality. Inventory and customer delivery becomes a problem, so a big supply chain software gets implemented. Sales Reps need better forecasting. Predictive analytics is all the rage, so you learn about R algorithms and the difference between arima and exponential smoothing. 
You’re getting smarter but your users still have the same requests as 10 years ago… How do you grow with your enterprise while meeting those legacy, expanding demands at the same time?

You don’t need a prettier dashboard, you need a better answer.

IT can too often get caught in the trap of having to maintain and deliver accurate/secure/governed data AND create reports. If you can get the reporting function off your plate, you might actually have time to actually fix your data quality problem. A great example was that time in my career as a Business Analyst where I was tasked with creating weekly reports for distribution to several senior managers. Every single Monday, all day long I formatted, cleansed, fixed, and massaged data so it was presentable. Looking back, it felt like putting a band-aid on a different hole in the ship. The data problem wasn’t being fixed, it was being avoided. It was mind-numbing, soul-wrenching work. 
It wasn’t until I stepped up and finally asked for/almost demanded permission to fix the problem that a change was made. I wish I would’ve done it sooner, that is a year of my life I’d love to get back. Rather than wasting your time building the 5th iteration of the same report, think about the value you can deliver by bridging data from several business tools and combining sales, forecasts, manufacturing schedules, and inventory levels to actually help the S&OP team balance supply with future demand.

There is only one of you

Self service has become a term that is thrown around a BI trade show more than a baseball at the last Padre’s game. Side note and a word of caution: Most BI tools are built for BI analysts, not the end user. Vendors can say self-service all they want to, but you will know whether it’s true the minute you put it in front of your end users. 

Work smarter, not harder. 

If you are going to put the data in the hands of the end user, it has to be: 

  1. Easy and Fast. Users like familiar, think: web sites, Google searches, and smartphone apps.
  2. Pertinent- the data they need to make decisions (and only the data they need). It’s ok to start small and grow into it. Don’t overload them with unneeded complexity.
  3. Secure- preferably synced with AD so you don’t have to maintain security twice.
  4. Easily understandable- in the language of the end-user.
  5. Flexible- end users all have different needs, don’t waste your time building rigid drill-paths.

The reality is that the BI world of old does not line up with expectations of the users’ everyday lives. You don’t log into Weather Underground to slice, dice and drill into a 7-day forecast cube, you jump on Google and ask. Question - answer. Information gathered - decision made.
Although some of these points may seem rudimentary, they would have been sage advice for a younger me. If I could go back, I would have reminded myself to ask clarifying questions when needed, fix the problem at its root cause where possible, and spend more time with the business users. I would have ultimately come out smarter on the other side, been viewed as an expert in my field, and advanced faster in my career. Hopefully they do the same for you.