Why do I have all this stuff?
As I looked around my garage last weekend in search of an appropriate tool to tackle a “small” plumbing repair, I found myself sorting through a number of tools (and other junk) that seem to do generally the same thing. I had to ask myself, “Why do I have all these wrench sets, screw drivers, drills, etc.” I’m not really a tool guy. In fact, I’m not very handy, and I would generally consider myself “mechanically declined.”
As I continued to dig around, my mind began to wander. I started to think about recent conversations I’ve had with IT Directors and CIOs about business intelligence tools. These business conversations basically centered on rationalizing the current collection of tools that they own to deliver reporting, analysis, scorecards, dashboards and other related capabilities to business folks across the organization.
Much like the tools in my garage, their BI tools were acquired over time from a variety of sources. Some of the tools were bought directly by the IT department; others came embedded with another software product. In some cases, business departments purchased them directly; in others they showed up as part of the acquisition of another company. The tool vendors themselves may have introduced additional tools as part of the overall vendor consolidation going on in this space. In any case, the result is a pile of tools that generally:
- Require different skills for development, use and overall support
- Contain overlap in information delivery capability (reporting, analysis, scorecards, etc.)
- Need hardware infrastructure and maintenance procedures
- Require an annual maintenance fee of 15 – 25% of the original purchase
What I am going to do about it?
Organizations address (or ignore) the situation in a variety of ways. In one recent discussion, an IT leader told me he was in the process of moving from IBM/Cognos to Microsoft. In his situation, the IBM/Cognos suite was brought into his shop with his ERP software, and the organization had not done extensive additional development using the tools. His reasoning for moving to Microsoft was not so much a feature/function decision but largely boiled down to:
- License cost – Cognos is a suite of applications that must each be licensed separately. Microsoft capabilities are all embedded within SQL Server, SharePoint and Office (Excel). Future Cognos development implied additional cost per seat while SQL Server and SharePoint licenses were already purchased.
- Resource availability – Although the Microsoft tools require some specific business intelligence skills, his general pool of current developers had base-level skills in the Microsoft environment.
- Excel integration – Many business users are very comfortable using Excel for business intelligence activities. Microsoft Excel connects seamlessly to Analysis Services and continues to be a focal point for the addition of business intelligence functionality.
- SharePoint integration – Dashboards, scorecards and analytics are available in the PerformancePoint services component of SharePoint. Business intelligence solutions containing these components, along with Reporting Services, Excel Services and PowerPivot could be seamlessly integrated within the SharePoint environments that already existed in the organization.
Some Guiding Principles & Final Thoughts
Every situation is different when it comes to addressing capability overlap and tool redundancy. I’ve seen organizations move in every possible direction amongst the main tool vendors. However, I believe several key principles should be applied in all cases:
- Standardize based on capability – Information can be delivered in a variety of methods (dashboards, scorecards, analysis, reports) to a variety of users. Tool consolidation efforts should focus on information delivery method and creating a SINGLE vendor solution to support each mode. Ideally, a single vendor could support all modes, but there may be cases when another vendor is introduced to meet a specific use case. As Gartner and others point out, IBM, SAP, Microsoft and Oracle are companies, not business intelligence strategies.
- Avoid the “Big Bang” – If you have a large installed base of reports built in multiple tools (e.g., Crystal Reports, Reporting Services), it may not be cost justifiable to convert all reports from one environment to the other. Ultimately, these conversion efforts make more sense in the context of a major redesign or upgrade of one of the applications.
- It’s not “one to one” – Look for opportunities to retire and consolidate reports and cubes rather than simply creating them again in a new platform. Redundant reports are especially common in organizations and it certainly does not make sense to simply recreate duplicates in a new environment.
As for the tools in my garage, so far I’m living with redundancy. I am, however, guarding against the addition of any new tools that don’t provide a distinctly new capability. Maybe later this spring I’ll go through and start the rationalization and consolidation process.
NOTE: This blog was originally posted on March 16, 2011 by Steve Molsberry