Self Service BI is here! With Power BI, you no longer need a traditional data warehouses.  Blue is the new Black and White is the new Gold! 

In my last blog post, we discussed how data visualization is just the last phase of the business intelligence process.  I sought to emphasize the value of a data warehouse in conjunction with the sexy visualization tools.  Power BI is upsetting the market because some  fear (and others purport) that it completely supplant a data warehouse.  Let's be clear.  No tool is going to replace the need for a conformed, sanitized, and policed data warehouse (a data warehouse takes the current and historical data from your ERP and restructures it for reporting and analytic purposes in a database separate from your transactional systems).

Now, for clarity of language, let’s agree to condense the definition of Business Intelligence, to “a data analysis process aimed at boosting business performance by helping stakeholders make more informed decisions” (thank you Bing search engine).  Having agreed on BI’s definition, let’s now expand our paradigm of BI tools to encompass models suitable for an individual, a small team, or an entire Enterprise.  

Hopefully everyone is still onboard with our definition of BI and the purpose of a data warehouse; here, however is where some part ways.  Because emerging tools like Power BI can create cube structures fed directly by an ERP, controversy arises as to whether we still need a data warehouse.   While I fully endorse and look forward to more companies leveraging Power BI as a presentation tool, I do not believe that an exclusively Power BI solution will replace the data warehouse for Corporate and Team BI.  Let’s back up and discuss.

 In traditional BI, whenever possible, we separate the transactional system (your ERP—whether NAV, GP, AX, Quickbooks, Sage) from the reporting environment.  You may have heard names like Inmon or Kimball, tabular versus multidimensional, and star versus snowflake schema bandied about when discussing data warehousing, cubes and your reporting environment.  Where your ERP may have data entry problems, incorrect status changes, or even truncate historical data (when you migrate or upgrade your ERP systems), the purpose of a data warehouse is to create a policed structure that measures and holds all historically relevant company activity and then gives the ability to present said measurements across a series of structured dimensions (like Customer, Vendor, or Date).  

Some cost conscious business owners having invested in an ERP may balk at investing in a separate reporting solution.  “Shouldn’t reporting just come with NAV?”  Yes, and no.  Actually … mostly no.  Just as there’s an industry around recording your company’s transactions, there’s an equally robust industry around extracting and presenting that data.  Some clients want a standalone front-end application like Targit; others need access via mobile devices and web pages; while some analysts just want their data in Excel.  Furthermore, in order to create a consolidated view of a customer or your service offerings, it’s valuable to integrate data from CRM, Helpdesk software and custom CSVs generated by online sources or machines off the manufacturing line.

Admittedly, for ease of reportability, I’ve seen companies integrate these external datasources directly into their ERP, but a hybrid ERP/data warehouse solution often yields subpar results.  “The system only works if customer number in the ERP matches the account number in CRM”, “there’s no system for handling what to do if the customer information changes in CRM but doesn’t update NAV” or vice versa.  We haven’t even begun discussing how to match Tech Support tickets with an invoice line or SLA in your ERP, and you can forget about cost allocation!   

Please, stop asking your ERP to be a Unicorn and a Dragon at the same time. The ERP should capture transactions; your Data Warehouse should be your reporting solution!  And no new-fangled tool should unify those inherently disparate needs.    

It is worth noting that not every reporting request requires a data warehouse.  At the Personal (or trendily named Self-Service) level, an employee on the purchasing team may need a tool that can project demand based on scheduled production and then calculate shortages based on Inventory On Hand and Inventory on Production Orders.  Alternatively, you may have already seen a Power BI demo based on basic sales analytics.  None of this simple analysis requires a data warehouse, but as data volume or sources increase, the need for an alternative to direct queries to the ERP emerges.   

Welcome back from the holidays!

I wish I could say I put all work behind me, but instead I spent some time working on a few projects I've had on the burner, including exploring how Power Pivot and Power View might affect our work with Jet Enterprise and 'formal' BI projects.

Through blogs and interactions with customers and partners, we're hearing murmurs questioning whether data warehouses can be replaced by Excel's Power BI family.  In this blog I demonstrate that since Power Pivot can recreate a lot of the functionality that Jet Enterprise's dimensional projects leverage, instead of fearing or demonizing the disruptive potential of Power Pivot, we can welcome it into our workflow.  This tool can empower business analysts to prototype the cube customizations they desire, as well as act as a stop gap for analysis and reporting while cube customizations are implemented.