It’s rare these days to find clients who haven’t already decided on a standard BI platform. Most of the new BI tool discussions we get into with clients are with companies who’ve decided that it’s time to broaden their horizons beyond Microsoft.
The dirty little secret in most companies is that the BI reporting team has morphed into a de-facto enterprise reporting team. Why is this?
When it comes to reporting, there’s a difference between the BI team and the rest of IT. The fact is that BI teams are successful not because of the infrastructure technologies, but because of the technologies in front of the users: the actual BI tool. To the end user, data visualization and access are much more important than database management and storage infrastructure. So when a new operational system is introduced, users expect the same functionality, look and feel as their other reports.
An insurance company we’re working with is replacing its operational systems. The company’s management has already decided not to use the vendor’s reports—they’re too limited and brittle. They expect these reports to dovetail into the company’s information portal and work alongside their BI reporting. Companies are refreshing their operational platforms every seven to ten years. It’s now 2009, and the last time they refreshed their operational systems was in reaction to Y2K. It’s once again time to revisit those operational systems.
If you look at the challenges BI tool vendors are facing, there is limited growth in data warehousing. Most companies have standardized their BI tool suite. Absent disruptive technology or new functionality, there’s limited growth opportunity for BI tools in the data warehousing space.
But for every data warehouse or data mart within a company, there are likely dozens of operational systems that users need access to. The opportunity for BI vendors now is delivering operational information to business users. This isn’t about complex analytics or advanced computation. This is the retrieval of operational information from where it lives.
Photo by jakeliefer (via Flickr)
Could we also say that BI teams are seen as successful because of their BI tool, but will be seen as unsuccessful if they forget about the hygiene issues of data quality, database management and storage infrastructure? Herzberg’s theory about motivation suggests that the factors causing satisfaction are different from those causing dissatisfaction, and the opposite of satisfaction is not dissatisfaction, but rather no satisfaction.
In this example the data visualization, with its sex and sizzle, is a motivating factor and is seen as career enhancing for both the executive and BI team. However, it behooves them to pay serious attention to the factors that originally enabled the data visualization behind the scenes, because if those disappear, so does the satisfaction.
Now, how do we go about making data quality seem sexy?
Posted by: DQStudent | June 09, 2009 at 10:06 AM
Evan, your comments are spot-on. In many circumstances the big data warehouse is still required. Nonetheless, users need to get to data much sooner than the 6+ months it can take to put that data into a DW and built the related query environment. Part of the answer could lie with tools like QlikView which can hook directly up to data sources and deliver analytics quickly. They won't be as complete and the data might not be as clean but, they do get important information into users hands quickly, while the DW is being built in the background.
Posted by: Benjamin Taub | June 10, 2009 at 07:10 AM
Great set of thoughts.
We often find that the success metrics of a BI environment is very different than the traditional IT project. Success isn't based on functional delivery or completion -- it's all about data usability.
All too often folks gravitate towards creating requirements that are nothing more than data element lists and report examples. In reality, what's also needed are the usage scenarios that reflect how the data will be used. This allows IT to understand the needs relating to data timeliness, accuracy, integrity, etc.
With a more robust set of requirements, the technology team could likely identify less complicated solutions (such as the operational reporting).
Which brings us to an issue that's consistent across most BI environments: collecting business requirements. Sounds like I need to offer a few remarks about the different types of requirements in the BI world...
...another day, another blog....
E
Posted by: evan levy | June 11, 2009 at 01:21 PM