The origin of every business intelligence (BI) team is quite simple. A company starts doing business and then recognizes it needs to track how it's doing. So business unit heads hire analysts who create a bevy of reports using whatever low-cost tools they can find, usually Excel and Access. Although managers get answers to their questions, it comes at a high cost: analysts spend more time integrating data than analyzing it and create a bevy of redundant data silos that are costly to maintain and prevent executives from getting a single, integrated view of the business. When the CEO can't get an answer to a simple question, such as "How many customers do we have?" or the CFO sees a red balance sheet caused by a proliferation of redundant people and systems, they take action.
Usually, executives decide to move reporting, analysis and data management out of the business units and into a shared corporate service. By centralizing the BI function, executives pull BI-related professionals out of the business units and put them onto an enterprise BI team that is charged with building an enterprise data warehouse and creating all reports and dashboards for business units. The goal of the new group is to align the business with uniform data and deliver cost savings through economies of scale. This reorganization swings the pendulum from a decentralized approach to managing BI to a centralized one.
All goes well until business units start to grumble that the new corporate BI team isn't meeting their information needs in a timely manner. Whereas in the past, a business person could initiate a project by talking with an analyst in the next cubicle, now she needs to submit a proposal to the corporate BI team, participate in a scoping process, and then wait for the BI team to decide whether or not to do the project. And this is all before a single line of code gets written. Once a project finally starts, the BI team takes longer to build the solution because it's now a step removed from the business unit and doesn't know its processes, data or people well enough to work efficiently or effectively. Given these circumstances, some business unit heads decide they can't wait for corporate BI to meet their needs and hire analysts to build reports for their group, effectively replacing the ones that the corporate BI team "stole" from them.
Finding the Middle
By swinging from one end of the organizational spectrum to the other--from decentralized to centralized--the BI program becomes a bottleneck for getting things done. At this point, some executives throw up their hands and slash the BI budget or outsource it. Yet enlightened executives seek counsel to find a more nuanced way to structure the BI program so that it marries the best of both worlds. In essence, they find a middle ground that I call this a federated BI organizationthat delivers both the nimbleness and agility of a decentralized approach and the standards and consistency of a centralized approach. (See figure below.)
A federated BI team maintains a unified BI architecture that delivers consistent, accurate, timely, and relevant data that makes the CEO happy. And it delivers economies of scale that makes the CFO happy. Moreover, because a federated BI organization embeds BI professionals in the divisions, it delivers BI solutions quickly, which makes business unit heads happy. Finally, through cross-training and support provided by collocated BI professionals, business analysts finally become proficient with self-service BI tools, which makes them happy.
So there is a lot to like with a federated BI organization, and very little to dislike. In essence, this approach creates a common charter that impels the business and IT to collaborate at a deep and more productive level. The only real challenge is managing the web of matrixed relationships and co-managed teams that maintain the proper balance between business and IT. We'll discuss these relationships in a future blog post.
Posted October 17, 2013 10:39 AM
Permalink | No Comments |