Microsoft Power BI is being adopted by more and more organisations. Its popularity is based on its ease of adoption, ease of use and the ease of integration with other tools.
However there are pitfalls that users and businesses can stumble into on their journey with Power BI. These traps may lead to inefficient working practices, proliferation of data, and siloed development. All of these pitfalls are avoidable costs if a little planning is done, and you talk to some experts before starting out.
Microsoft Power BI is part of Office365, and is also the Power Platform group of tools. Easy integration with SharePoint, Teams and other consumer software makes it very appealing to use. Anyone who is competent with Excel, has access to data and can Google stuff, can start designing a Power BI solution. They don’t need the input of IT because all the components are already available to them.
However this leads to end-users creating complex routines that do not rely on robust, backed-up and monitored environments. Soon business critical processes are reported on using a combination of Excel, SharePoint, Power BI, Power Query and some blu-tac.
Untangling the processes that a well-intentioned user has put together in these tools is very difficult. At best, it works well for prototyping a solution, at worst it creates a headache for someone else in the business who has to try to unpick it all when something goes wrong.
Power BI can enter an organisation stealthily. The desktop tool comes free with Office365 licences and anyone with an account and local admin rights can download and install it.
This means that the first time IT might hear of its use is when someone boasts of their whizzy new reports that one of the bright sparks in their department put together one evening, and how it has revolutionised billing/complaints/HR etc. Without any planning and oversight, suddenly a new un-vetted tool is integral to a process that features in the top 5 of the company’s risk register!
Again, the ease of adoption makes it so tempting to use when an established tool is found wanting. But without input from the organisation’s strategic planning teams, Power BI can quickly become a wild-west, with different areas of the business using it in different ways.
Just because you can do something doesn’t mean that you should.
Just because you can connect Power BI to spreadsheets, it does not mean that spreadsheets equate to structured data.
Just because Power Query enables you to compile an ETL process, it does not mean that your PBIX file is a data warehouse.
Just because DAX allows you to create complex calculations with fine control of filters and contexts, it does not mean that you can skip properly modelling your data.
Just because non-IT staff who understand business process and business analysis are key to the success of a reporting project, it does not mean that they should architect the solution and develop it as well.
Your IT and analytics teams are trusted resources of knowledge, skills and experience. They should work together with the business to create a solution that is robust and scalable and does not turn out to be a dinosaur-disaster!
Once Power BI has snuck into your company, and is now busy integrating with your most important processes, you will find that the users who invited it in it are suddenly irreplaceable. The nature of a hastily Heath-Robinson-ed Power BI solution means that only those who built it can maintain it.
Perhaps someone has the data gateway installed on their personal laptop because no one has thought to ask IT to provide a server? Maybe the Excel files vital to the data refresh are on a personal drive. Perhaps the only person who bothered to learn M on their weekends is now on holiday.
No one in IT has the awareness of what’s been created, or where. Without oversight and documented processes, your organisation is suddenly reliant on individuals in unexpected places. These staff might also have skills that their peers do not, potentially making recruitment a nightmare if they choose to leave.
Excel is not a database. You wouldn’t believe how controversial that statement is in some places, but it is not a purpose built data-storage tool optimised for various automated access and query routines, with complex security, backup facilities and management tools.
Similarly Power Query is not an ETL tool. If you want to process millions of rows an hour, with complex cleansing routines, error capture, and slowly changing dimensions you use SQL Server Integration Services or SAP Data Services or one of many Azure tools.
The temptation is always to use the tools that are available immediately. But if you want to do the job properly then you need the proper tool.
Power BI is a fabulous data visualisation tool, intuitive for designers and consumers. It doesn’t do operational reports very well, you’d use Report Builder for that.
Power Query is great for tweaking the structures of ad-hoc data sources, and prototyping transformations, exploring data. It’s not robust enough for enterprise-wide projects around critical processes.
Understanding the limitations of Power BI is a key part of a successful project to implement it.
All of the above show problems with Microsoft Power BI, but with that there is one massive positive: it shows that users will use it. Adoption of BI products is a problem, the fact that Microsoft have overcome that is really powerful.
If you’ve fallen into one of these traps or fear you might soon, don’t despair! Come and talk to DSCallards about your data, your reporting requirements, your data warehouse – anything data related really. We’re friendly, and never do anything just because we can – we always pause to check we should, first.