The good news is also the bad news. End users are smarter than ever. Many of them have co-opted BI by acquiring their own tools and have funded their own skill development to create specific functionality. As BI is increasingly adopted across organizations, it has become a free-for-all of brand-new silos, unmanaged data, duplicate work efforts and poor data quality, all of which lead to misaligned business decisions. Translation: We're spending too much time and money getting information and not using it cohesively. In response, many BI teams have chosen to launch a center of excellence as a way of refocusing attention on the unique nature of BI projects and the processes that come with them. But such a big project can easily backfire and lead to more chaos. We need to know when the time is right for a BI COE.
Failure to Launch: How Not to Start Your COE
When I asked Craig, the CIO at a regional bank, why he'd decided to launch a BI COE, he explained that, after working for two years as a formal team, the BI developers had practically disappeared. The initial business process management dashboard had been a high-profile success, but users had reverted back to Excel spreadsheets for most of their reporting, enlisting developers only when new query creation proved too complex. Meeting fatigue had become part of the culture, and users didn't want to be proactively engaged in business requirements discussions, however strategic. BI had become commoditized.
Craig's hope was that by announcing a BI COE, his user community would take him and his team more seriously. "I thought the COE concept would give us street cred," he admitted. It had the opposite effect. Immediately, business users began asking why the BI team was getting more funding when they hadn't delivered anything in more than six months.
And it was true. Since the dashboard project's success, BI team members had been focusing their time on infrastructure and platform issues. Data model enhancements and regular data loading activities were absorbing most of the resources. Users weren't seeing value, so Craig's emails advocating a COE seemed self-serving. Craig hoped his COE idea would get attention, but cynical email replies and eye-rolling weren't the kind of attention he wanted.
Craig's users brought their old resentments to the COE discussion. "It's rearranging deck chairs on the Titanic," a segment manager in marketing remarked. "We don't know what these guys are doing - and neither do they. Why should we be the ones to fund a COE when we have no idea what's in their pipeline - and have absolutely no input into it? It's a funding grab if you ask me." Ouch.
I've seen other failed COEs at companies that used high-profile problems - such as an enterprise resource planning system's problems acquiring data or management's desire to standardize on reporting tools - as a pretext for starting a COE. The results have been equally fruitless. In reality, the situations that justify a COE are few and very easy to spot.
When the COE Makes Sense
As real as Craig's problem was, announcing a COE wasn't the answer. Craig needed to re-enlist users in a structured process with clear rules of engagement and begin to quantify the value of work tasks to prove that his team was deserving of continued funding. He needed to deploy BI applications that business users would use and establish structure and BI-specific development processes. Only then would a COE make sense.
And that's the problem with many existing (and increasingly defunct) COEs: They begin prematurely, before stakeholders perceive value. A COE will only become sanctioned if its stakeholders recognize a bona fide need for it. There are three predominant drivers of successful and sustainable COEs:
- BI projects often compete for funding with other IT projects that are seen as operationally critical. The executive steering committee at a catalog retailer constantly placed BI at the bottom of the funding list. "When funding came down to either BI or a new merchandise management system, we'd lose," said one director of BI, "and we lost most of the time." The director set out to educate the steering committee about why BI development was different, and how it could enable strategic goals like customer retention and promotions effectiveness. With the caveat that cost recovery was an end goal, the steering committee agreed to fund BI as a separate group with its own organizational structure and governance process.
- The data warehouse has become a shared resource across organizations, and the economies of scale justify a central development organization. Alternative, piecemeal and siloed efforts at data management and BI have become not only costly, but also risky, as different versions of data proliferate across the company. A COE not only ensures a deliberate approach to funding and deploying BI, but an ongoing investment in BI-specific tools, skills and data.
- Business operations become dependent on BI. When a company relies on its data warehouse or BI infrastructure for business-critical capabilities such as inventory management or financial reporting, the company should invest in a COE. It has become more common to see that certain high-profile business functions or processes can't run without BI, in which case you've established BI as a business-critical platform that justifies its own skill sets and budget.
Without the ability to prove efficiencies, cost savings or revenue generation, the nascent idea of a COE becomes a solution looking for a problem. The risk is that prematurely or casually launching a COE raises stakeholder expectations around delivery and know-how, making the inevitable fall even more painful.
Be the first to comment on this post using the section below.