What Not to do on a BI Project Series – #1 UI Replacement Projects
With so much effort put on what you should be doping on a BI project, I thought I’d take the opposing tact and talk about some of the things you should really try to avoid doing. So I’m going to be putting together a series of posts on this topic, taken from presentations I’ve delivered such as “The 7 Deadly Sins of BI”. These will be some of the more common ones that I’ve experienced over the years implementing OBI projects – ones that I run across all too often. As such it is far from an exhaustive list – I’m sure in the comments section you can add a few of your own! Plus, some of the topics you may disagree with, so let me have it.
I’m starting with what I like to call UI Replacement Projects as this one as this is far and away the most common one. A UI Replacement Project happens when your project’s goal is to take a report or two from a legacy system and put it into OBI. You aren’t going to invest any time in redefining how the report works, what its metrics are, its format, etc. You are simply trying to get it off of the old system and into the new one. Thus, all you are really doing is changing the User Interface of a report.
Think about that for a second: Is that why you bought OBI? Do you think that is what Business Intelligence is all about? Isn’t OBI a little too expensive to just re-host existing reports in a Web environment?
To be fair, there are some benefits to doing these types of projects:
- Automation – Frequently a lot of manual work can be eliminated by simply doing proper ETL and building a report that everyone can have access to. Although automation of manual processes is a good thing, it is only a side benefit of BI and not its main goal.
- Political – Whoever is sponsoring the BI project frequently has to fight internal struggles to prove that what is under their control, namely the OBI system, is the best system and all others should be replaced with OBI (read: the sponsor’s power grows). This sometimes means going after low-hanging fruit with a large audience. If the legacy system can be sunset, a great victory can be claimed and you will get to do more OBI!
- 1st Step into the BI World – For both business users as well as IT, doing this as a first project can provide for a migration from the old way of doing business to the new way. It allows IT a practice repetition on the software and its challenges better preparing them for future deployments.
- Proof of Concept This is common to get OBI in the door by proving to people it can do the kinds of reports you want it to do. This is very common with the BI Apps. But remember what is done during a POC is not always good BI practice – it’s there to show capability and effort.
If these benefits are highly important to you then by all means start your OBI experience off with a migration. However, know that what you are deploying is not the way you should be thinking about you BI environment, and that report migration is merely a starter project.
Let’s get into the main issues with these types of projects:
- Same Junk, Different Tool The primary issue with report migration is the replication of the old way of doing business with a new tool. Nothing has changed except for the mechanism you are providing information in. Instead of an emailed-BO or Excel file, users are now seeing the exact same thing in a browser. The goal of these types of projects is to reproduce the old reports exactly as is, sometimes even with their errors and always with their weakness as they pertain to their user communities. The old reports commonly are good as far as reports go, but terrible as far as BI goes. Large financial dumps like a daily flash report have way too much extra information in them, and are really just dumps of raw data in a certain format. No BI scrubbing has been performed to ask users what are they looking for in those reports and why. A BI environment should provide exactly what a user is looking for without them having to scan through a large data dump or download to excel to perform additional analysis.
- No Flexibility Doing this misses a great opportunity to provide a flexible and powerful BI environment. The real value of BI comes from the rigorous definition, standardization and presentation of information that is useful to a user in the context of the tasks they are performing. By focusing on a report, you are not putting the effort into designing for a flexible ad-hoc environment on top of which any number of reports and analysis can be preformed. The implementation design will be to that report only, and making similar analysis and report will require significantly more work to augment the models used for a specific report. Thus, your ability to adapt to the business’s changing needs is greatly reduced, and at greater cost.
- Greater Maintenance Costs Sometimes to deliver a report from an old system in OBI requires a lot of extra work that breaks best practices or sends you down dead-end design paths that are un-maintainable. One-off tables that no other query will use are common, as are report specific aggregates. After a while your Data Mart and your OBI Repository are a complete mess and you can forget about deploying any ad-hoc reporting solution as you just can’t be sure it will work right for scenarios outside of a certain report’s.
- Too Format Focused It also places too much focus on the old format of information display and misses out on many powerful mechanisms and techniques available in a BI tool. OBI is not a UI development language – it has limitations in what it can do and how it can do it (sometimes very big limitations). Plus it really begins to annoy users when they start to find out that they can’t get their report in the exact same format as they’re getting it right now – they begin to have a poor outlook on OBI as a tool.
Instead, use a good BI methodology where you start with a clean sheet of paper and ask about what kinds of information they need to have in order to do their jobs better than they are today. Have them think “outside the report” in other words.
To sum it all up, ask yourself if are you paving cowpaths? Or trying to put a saddle on a car? If so you are now in the UI business and not the BI business.
For a slightly different perspective on a very similar topic, check out a prior post called Using Report Specs for Requirements. Much of the information in there applies directly to UI Replacement Projects.