Introduction
The subject of this article ought to be reasonably evident from its title. However there is perhaps some room for misinterpretation around even this. Despite the recent furore about definitions, most reasonable people should be comfortable with a definition of business intelligence. My take on this is that BI is simply using information to drive better business decisions. In this definition, the active verb “drive” and the subject “business decisions” are the key elements; something that is often forgotten in a rush for technological fripperies.
The central issue
Having hopefully addressed of the “BI” piece of the BICC acronym, let’s focus on the “CC” part. I’ll do this in reverse order, first of all considering what is meant by “centre”. As ever I will first refer to my trusted Oxford English Dictionary for help. In a discipline, such as IT, which is often accused of mangling language and even occasionally using it to obscure more than to clarify, a back-to-basics approach to words can sometimes yield unexpected insights.
| centre / séntər / n. & v. (US center) 3 a a place or group of buildings forming a central point in a district, city, etc., or a main area for an activity (shopping centre, town centre). (O.E.D.) |
Ignoring the rather inexcusable use of the derived adjective “central” in the definition of the noun “centre”, then it is probably the “main area for an activity” sense that is meant to be conveyed in the final “C” of BICC. However, there is also perhaps some illumination to be had in considering another meaning of the word:
| n. 1 a the middle point, esp. of a line, circle or sphere, equidistant from the ends, or from any point on the circumference or surface. (O.E.D.) |
As well as appealing to the mathematician in me, this meaning gives the sense that a BICC is physically central geographically, or metaphorically central with respect to business units. Of course this doesn’t meant than a BICC needs to be at the precise centre of gravity of an organisation, with each branch contributing a “weight” calculated by its number of staff, or revenue; but it does suggest that the competency centre is located at a specific point, not dispersed through the organisation.
Of course, not all organisations have multiple locations. The simplest may not have multiple business units either. However, there is a sense by which “centre” means that a BICC should straddle whatever diversity there is an organisation. If it is in multiple countries, then the BICC will be located in one of these, but serve the needs of the others. If a company has several different divisions, or business units, or product streams; then again the BICC should be a discrete area that supports all of them. Often what will make most sense is for the BICC to be located within an organisation’s Head Office function. There are a number of reasons for this:
- Head Office similarly straddles geographies and business units and so is presumably located in a place that makes sense to do this from (maybe in an organisation’s major market, certainly close to a transport hub if the organisation is multinational, and so on).
- If a BICC is to properly fulfil the first two letters of its abbreviation, then it will help if it is collocated with business decision-makers. Head Office is one place than many of these are found, including generally the CEO, the CFO, the Head of Marketing and Business Unit Managers. Of course key decision makers will also be spread throughout the organisation (think of Regional and Country Managers), but it is not possible to physically collocate with all of these.
- Another key manager who is hopefully located in Head Office is the CIO (though this is dispiritingly not always the case, with some CIOs confined to IT ghettos, far from the rest of the executive team and with a corresponding level of influence). Whilst business issues are pre-eminent in BI, of course there is a major technological dimension and a need to collaborate closely with those charged with running the organisation’s IT infrastructure and those responsible for care and feeding of source data systems.
- If a BI system is to truly achieve its potential, then it must become all pervasive; including a wide range of information from profitability, to sales, to human resources statistics, to expense numbers. This means that it needs to sit at the centre of a web of different systems: ERP, CRM, line of business systems, HR systems etc. Often the most convenient place to do this from will be Head Office.
Thusfar, I haven’t commented on the business benefits of a BICC. Instead I have confined myself to explaining what people mean by the second “C” in the name and why this might be convenient. Rather than making this an even longer piece, I am going to cover both the benefits and disadvantages of a BICC in a follow-on article. Instead let’s now move on to considering the first “C”: Competency.
Compos centris
Returning to our initial theme of generating insights via an examination of the meaning of words in a non-IT context, let’s start with another dictionary definition:
competence /kómpit’nss/ n. (also competency /kómpitənsi/) 1 (often foll. by for, or to + infin.) ability; the state of being competent.
|
| and given the recursive reliance of the above on the definition of competent… |
| |
competent /kómpit’nt/ adj. 1 a (usu. foll. by to + infin.) properly qualified or skilled (not competent to drive); adequately capable, satisfactory. b effective (a competent bastman*). |
(O.E.D.) |
| ||||
* People who are not fully conversant with the mysteries of cricket may substitute “batter” here.
To me the important thing to highlight here is that, while it is to be hoped that a BICC will continue to become more competent once it is up and running, in order to successfully establish such a centre, a high degree of existing competence is a prerequisite. It is not enough to simply designate some floor space and allocate a number of people to your BICC, what you need is at least a core of seasoned professionals who have experience of delivering transformational information and know how to set about doing it.
There are many skills that will be necessary in such a group. These match the four main pillars of a BI implementation (I cover these in more depth in several places on the blog, including BI implementations are like icebergs and the middle section of Is outsourcing business intelligence a good idea?):
- Understand the important business decisions and what figures are necessary to support these.
- Understand the data available in the organisation, how it relates to other data and to business decisions.
- Transform the data to provide information answering business questions.
- Focus on embedding the use of information in the corporate DNA.
So a successful BICC must include: people with strong analytical skills and an understanding of general business practices; high-calibre designers; reliable and conscientious ETL and general programmers; experts in the care, feeding and design of databases; excellent quality assurance professionals; resource conversant with both whatever front-end tools you are using to deliver information and general web programming; staff with skills in technical project management; people who can both design and deliver training programmes; help desk personnel; and last, but by no means least, change managers.
Of course if your BI project is big enough, then you may be able to afford to have people dedicated to each of these roles. If resources are tighter (and where is this not the case nowadays?) then it is better to have people who can wear more than one hat: business analysts who can also design; BI programmers who will also take support calls; project managers who will also run training classes; and so on. This approach saves money and also helps to deal with the inevitable peaks and troughs of resource requirements at different stages in a project. I would recommend setting things up this way (or looking to stretch your people’s abilities into new areas) even if you have the luxury of a budget that would allow a more discrete approach. The challenge of course is going to be finding and retaining such multi-faceted staff.
Also, it hopefully goes without saying that BI is a very business-focussed area and some BICCs will explicitly include business people in them. Even if you do not go this far, then the BICC will have to form a strong partnership with key business stakeholders, often spread across multiple territories. The skill to manage this effectively is in itself a major requirement of the leading personnel of the centre.
Given all of the above, the best way to staff a BICC is with members of a team who have already been successful with a BI project within your organisation; maybe one that was confined to a given geographic region or business unit. If you have no such team, then starting with a BICC is probably a bridge too far. Instead my recommendation would be to build up some competency via a smaller BI project. Alternatively, if you have more than one successful BI team (and, despite the manifold difficulties in getting BI right, such things are not entirely unheard of) then maybe blending these together makes sense. This is unless there is some overriding reason not to (e.g. vastly different team cultures or methodologies. In this case, picking a “winner” may be a better course of action.
Such a team will already have the skills outlined above in abundance (else they could never have been successful). It is also likely that whatever information was needed in their region or business unit will be at least part of what is needed at the broader level of a BICC. Given that there are many examples of BI projects not delivering or consuming vastly more resource than anticipated, then leveraging those exceptional people who have managed to swim against this tide is eminently sensible. Such battle-hardened professionals will know what pitfalls to avoid, which areas are most important to concentrate on and can use their existing products to advertise the benefits of a wider system. If you have such people at the core of your BICC, then it will be easier to integrate new joiners and quickly shepherd them up the learning curve (something that can be particularly long in BI due to the many different aspects of the work).
Of course having been successful in one business unit or region is not enough to guarantee success on a larger scale. I spoke about some of the challenges of doing this in an earlier article, Developing an international BI strategy. Another issue that is likely to raise its head is the political dimension, in particular where different business units or regions already have a management information strategy at some stage of development. This is another area that I will also cover in more detail in a forthcoming piece.
Conclusions
It seems that simply musing on the normal meanings of the words “competency” and “centre” has led us into some useful discussions. As mentioned above, at least two other blog postings will expand upon areas that have been highlighted in this piece. For now what I believe we have learned so far is:
- BICCs should (by definition) straddle multiple geographies and/or business units.
- There are sound reasons for collocating the BICC with Head Office.
- There is need for a wide range of skills in your BICC, both business-focussed and technical.
- At least the core of your BICC should be made up of competent (and experienced) BI professionals .
More thoughts on the benefits and disadvantages of business intelligence competency centres and also the politcs that they have to negotiate will appear on this blog in future weeks.
This view of BICC sounds impressive and emcompases the promotion of 360 degree BI culture in an Enterprise.
I have a question related to BICC. How do you see the two components of BI (IT and Business know how) interacting with each other in case of organizations where they do claim having a BICC but in reality they have split the BI into two distinct functional areas as Data Warehouse (residing at IT side) and BI(the Information delivery,analysis and related business part residing at Business Side specifically with CMO)?
Thanks and Regards,
Hi Shahid,
Thank you for your comments.
On the question that you pose, I have seen a few organisations recently where “BI” (I’m using inverted commas because it is really only part of BI in my opinion) is within a change management function and the data warehouse is within IT. This is not how I have set things up myself in the past. My BI projects and competency centres have been within IT, but in extremely close collaboration with business and service units (depending on which Data Mart is being focussed on). This had the advantage of simplicity – if there was a problem with BI then I was the only person responsible for this and I couldn’t blame anyone else.
Although I have a lot of change management experience, and have always prided myself on taking a business approach to all technology matters, it would be silly of me to deny that I am an IT person by background. Maybe I set things up this way because it is what I am used to. Certainly when I have spoken to companies with the type of split that you have mentioned, it has seemed a little odd, maybe even artificial to me.
However, I’m sure that this approach can work. Perhaps it is simply to do with the culture of an organisation and where IT sees itself as fitting into the picture. I have heard people saying “change should be a business function, not and IT one” and in these cases, a dedicated CMO within the business is often the result. Also some IT departments may not see change as a core competency.
I suppose I take a different view. IT managers can have change management skills (in fact most of the best IT managers would count this as an important skill set) and business managers can have them as well. However if, in a given business, IT is less change focussed and more just looks after the technology, a CMO might make sense. If change management skills are less prevalent in the business, but IT is good at this, then it makes sense to have this aspect of BI in the IT department as well. I think that what counts most is what works for a given organisation, based on their culture and the skills of its managers. I don’t think that there is a right or wrong way of doing this.
Having said this, in the organisations that I know where CMO/BI and IT/DW are separate, the CMO/BI people seem to often complain about “getting those IT people to change the DW” and how long it takes and “how little ‘those guys’ understand the business pressures we face’”. This worries me.
I guess what has happened is that a wall has been erected. Whether it is necessary to have such a wall is dependent on the attributes of an organisation that I mention above, but it does undeniably reduce IT accountability and responsiveness and gives both CMO/BI and IT/DW “sides” (and it can be as adversarial as that) another set of people to blame for their own failings. In general I don’t think that this is a good thing, unless there is some overriding reason for separating essentially related areas.
To me clear lines of accountability always trump some theoretically sound separation of duties in an organisation. But then maybe I am just too much of a pragmatist.
Peter
[…] on this topic.Powered by WP Greet BoxAs usual, it is about People, Process & Technology. Here, on his blog, Peter Thomas discusses the merits of Business Intelligence Competency Centres […]
Hi Peter,
Thank you for quick and comprehensive response. Just one elaboration on CMO. CMO-Chief Marketing Officer and not Change Management Officer in our case. Secondly, since, BI function has been put under CMO, the CFO and CTO are still geting all their BI & related information reporting/analysis from Data Warehouse and not from BI–which is reporting to CMO.
Whats your view in this case?
Regards,
Shahid.
Hi again Shahid,
Too many acronyms with the same letters! I have a hard enough time distinguishing Chief Information and Chief Investment Officers.
Marketing is certainly one of the areas that sometimes is the genesis of BI projects. I have worked very closely and very well with senior marketing managers on helping to instil a strong sales culture using BI.
Having said that, it is generally my strong opinion that BI works best when it covers many aspects of what an operation does (see this earlier article on the subject). Given this, marketing would seem to be an odd place for it to reside in the long term.
Of course I make these comments with no firsthand knowledge of your organisation and there may be some very good reason specific to you why the CMO is the best person to guide BI.
All the best
Peter
Hi Peter
I really enjoyed your article and from my opinion and perspective of a BICC, hit the nail on the head.
My experience around BICC’s and BI in general have allowed me to realise some important points and especially relating to the comments/questions from Shahid I have the following to offer.
The DW in IT and BI/BICC in business debacle has reference. In my opinion, this is never a good setup. These should always be combined and whether the combination is in IT, as in your case and because you are perhaps more comfortable with it, or in the business is not really the issue. The issue is that it should be combined and consist of the skills that you have so wonderfully laid out. These skills mentioned are critical in my opinion for successful BI. What I have seen when the two areas are split between IT and business is that IT get inundated with requests for changes to such a degree that they become frustrated and make comments like “business does not know what they want” etc. Then they design methods and procedures to handle this chaos. Then they have priority listings of jobs to be done, ticket or event numbers to track jobs, call centres to handle requests etc. At the end of the day the IT guys stand back and say “Job well done. We are now organised. We have processes in place. This is our average delivery time, amount of requests handled etc etc” and pat themselves on the back. And business then complain that they cannot get changes done as quick as what they would like. And this is perhaps one of the secrets of BI: agility. A new request or change, especially coming from a group like the BICC with the skill sets described by you, will usually be valid and required and not a waste of time. Something in business triggered the change or request and an answer is required.
So with the two groups split, this is what I find usually happens. The Warehouse cannot move at the pace required by a good BICC. If these are combined this issue disappears and allows the BICC to be agile.
I am not sure if you are in agreement with this or not, but this is merely my experience.
Regards
Thomas Arpin
Hi Thomas,
Very Interesting comments by you on question that I raised to Peter.
Can, we two discuss further on this? my contact address is sh_bangash@yahoo.com
Thomas,
Thank you for your comments, with which I 100% agree. Where the BI team sits is in no way as important as it actually being a team.
Peter
[…] intelligence project at many places on this blog, most recently in the middle of my piece on Business Intelligence Competency Centres. While of course it is imperative to understand the available data (what would be the […]
Hi Peter,
Indeed, an interesting article you wrote.
I have some remarks, though. I agree that a BICC should include the Data Warehouse part as well, but if it suppose to contain also all business areas of an organisation, this can become a bottleneck in its own way.
Therefore, would you rather not favour a BICC that only delivers central BI projects and provides standards and guidelines but leaves the really domain specific BI solutions to the local BI teams within the business areas?
My second remark concerns your own job description. I’ve also worked on the creation of a BICC. Although it was all initiated by declaring one BI tool standard, we ended up dealing mostly with people and processes aspects than discussing about that standard or a BI technical issue. My personal experience is indeed that creating a BICC is more about change management (not the ITIL term!) than about the tools standards and BI architecture one wants to impose. Starting from a change management perspective has far better results than the rather technical BI architectural perspective.
Hans,
Apologies, I have had replying to your comments on my to-do-list for a while now.
I like the virtual BICC model, with a central team as the core, but supplemented by embedded BI people in strategic locations (or business units). The second group of people ensure responsiveness to local needs, but within the consistent framework laid out by the central group. It is sort of a hub and spoke arrangement I guess.
We are 100% in the same place on the need for change skills in a BI and BICC context.
Thanks for your comments.
Peter
[…] Business Intelligence Competency Centres […]
[…] dynamics of modern information provision. Maybe also the, by now somewhat venerable, concept of a Business Intelligence Competency Centre, a unified team combining the best and brightest from many fields, is an idea whose time has come. […]