In the world of business intelligence, the focus can easily be shifted from the important to the expedient. Such is the case with many business intelligence programs that start out recognizing a business focus but quickly shift to a more technical focus. The focus becomes the sun, and the rest of the project orbits around it. It becomes the prime mover for the decisions that are made and ultimately the measure by which the program judges its success. Following are some focuses, in order from healthiest to unhealthiest, that business intelligence programs fall into. As we progress through the focuses, you will notice the focus gets further and further away from the user.
Business Focus #1: Return on Investment ROI is the holy grail of focus for business intelligence. Those teams that focus on achieving it have learned what business intelligence is all about. Studies have shown that driving toward ROI highly correlates to self-reported program success scores. The focus on ROI just seems to encourage the development team to work backwards to doing the right things day in and day out for the ultimate arbiter of success - the bottom line. Ultimately, to claim this focus, a team must have a great handle on the succeeding focuses well. Business Focus #2: Data Usage Those programs that don t measure ROI or are too removed from business processes that drive ROI but still want a business-focused BI program focus on the usage of the data. The objective here is increasing numbers and complexity of usage. With this focus, user statistics such as logins and query bands are tracked however, little is understood about what the users ultimately do with the results. While undeniably an admirable goal, this focus restricts the team s ability to provide leadership to the business in the use of data. This reliance upon the user community to pick up the ball and find new uses for the data and for business intelligence can ultimately relegate the business intelligence team to that of a pure service provider. Business Focus #3: Data Gathering and Availability Under this focus, the business intelligence team becomes an internal data brokerage, serving up data for the organization s consumption. Users are not tracked because success is measured in the availability of the data. In these environments so removed from usage, it is often a struggle for the users to leverage the data. It is not unusual to find a host of downstream processes i.e., Excel, Access- operating to fix, clean and make this data usable. Users may have grass roots efforts underway to utilize each other s code. These environments often come about when there is high complexity in the data extraction and movement layer of the architecture. While it s an accomplishment to deliver the data in these environments, the team should not neglect the need to deliver business intelligence, which requires the accoutrements related to usage to be in place, such as governance, stewardship and a public relations program. User satisfaction with such programs begins to fade once they are left to deal with the limitations of delivered raw data. Technical Focus #1: Key Technical- Performance Indicators This is the technical counterpart to a business focus on data usage, but it is not as effective overall. There can be an especially large number of KPIs for the business intelligence program in the area of ETL. These are analogous to the metrics you might place in the operational meta data: up time, cycle end times, successful loads, clean data levels, etc. While important, they do not comprise the end game. Technical Focus #2: Adherence to a Guru Approach One of the ultimate disservices business intelligence teams can do is to spend their budget primarily making sure the architecture adheres to a book standard - as opposed to what works for the users. While popularized approaches are great, they create an artificial goal for team efforts, that is not correlated enough to the bottom line. While many finer points of architecture and methodology merit debate, the goal of any such debate should be a decision, not ongoing debate. Intervention is necessary to circumvent a downward spiral of the team focus into such territory. Often, when you throw a vendor approach into the mix, a three- or more- way debate emerges. The irony here is that the popularized approaches ultimately lack the required specificity to deal with all the aspects of the real-world situation your program is in. Original thinking is always required for success. Bron: www.dmreview.coma>