As discussed last month, many programs are attempting to calculate the business value or return on investment from their business intelligence programs. What are you going to do if upper management asks you, "We are funding $X million for business intelligence per year - what is the company getting out of it?" Are you going to get out those accounting books or find an ROI spreadsheet? Not so fast.
While the vendor mergers and purchases are trying to tell us that business intelligence (BI) is a discrete entity, I'm not so sure that it is. I don't think we really know yet. I still think it's arbitrary and worthy of clarification at each company - actually, for each ROI. It's too much of a moving target. You must bind your analysis. You should not encompass returns (or investments) that are going to find their way onto other (non-BI) project ROIs. That would be over- (or under-) stating the overall ROI to the corporation.
The response to upper management's question may be another question (or 2 or 3 or 50). However, the first question should be, "Is BI viewed as infrastructure or as a discrete application?"
If it is viewed as infrastructure, perhaps the question really should be, "What is the most efficient way to accomplish the objectives?" One way is through the use of a real, integrated BI infrastructure with a dedicated team and methodology to build it. Actually, if a company is acknowledging BI and asking for business value from it, this is probably the direction you are taking. In a company acknowledging BI and viewing it as infrastructure, the question is not one of ROI, it's one of total cost of ownership (TCO). The rewording of the original question then becomes, "Why should we continue to have a form of centralized BI versus just allowing what would happen otherwise - independent data marts for each business need?" Why consider the infrastructure part as BI versus allowing what would happen without BI? (Actually, the centralization and integration is a matter of degree - like a water faucet, not a light switch.)
BI is (usually) not a single application that would have a cash flow analysis technique (i.e., cumulative ROI, discounted ROI, average ROI, internal rate of return, net present value) for it. If you're asked to determine the ROI, you need to define the bounds.
Return on investment is about cash flow. In order to make return on investment calculations, you must take the investment and the returns down to cash flow. Neither defining investment nor returns is easy. Defining returns is very difficult and requires rigorous boundaries around the events being measured. Once you have the cash flow (in and out) over time, as well as your cost of money, placing them into formulas for the major ways of measuring return on investment is a relatively straightforward step.
The bounds you place around this important question can have serious consequences for your BI program. If you set the boundary too tight, BI may never be considered for its ultimate potential. If you consider only the basic reports that run from the data warehouse, will you also block any higher value applications from using the data layer of BI? In mature implementations, the data warehouse is useful for ad hoc query, reporting, feeding operational environments, data mining, feeding data marts, et cetera.
There is no such thing as commonly understood BI ROI. The key question is: How far do you go into the applications that use the BI in order to get the returns?
Perhaps a good place to start to address this issue is in defining BI. BI may not be what you think. Any agreed-upon definition is acceptable. Lack of a BI definition is unworkable, especially in the ROI process. BI is not necessarily how it was defined in an article, at a conference, by your competition, by your friend in BI at another company or by your office neighbor. If you're going to find ROI, you need discreteness of measurement. Additionally, ROI is a process, not a one-time event. Don't gear up for the big ROI calculation and forget about the follow-through.
Continue to innovate as a company. Sometimes ROI can be long-term in nature. Other times, you'll be able to pass some short-time ROI hurdles on the way to something with innovative, long-term ROI potential. Finally, ROI is not just for selling a project. It should be predictive in nature, which implies responsibility and measurement.
First, determine whether BI is an application or an infrastructure. Then, justify its use by demonstrating the efficiency of having a BI program and its lower total cost of ownership. Is BI an application with a discrete ROI? That could be a lot of cost burden to place on one application! Or, is BI a number of applications with discrete ROI? Then, take the sum of the returns and all the costs - IT and business - associated with attaining all the returns into your preferred ROI calculation, all the while making sure these applications are not being counted in other ROIs. The latter definition of BI recognizes BI for its ROI potential.
William McKnight brings process, organizational and architectural focus to building strategies and implementing master data management and data warehousing programs that have consistently, for many years, improved the productivity and performance for his clients including several global corporate giants. McKnight, award-winning consultant and author, can be reached at McKnight Consulting Group.
Be the first to comment on this post using the section below.