A recording of me being interviewed by Brian Roger of SmartDataCollective.com

SmartDataCollective.com

I have been a featured blogger on SmartDataCollective.com almost as long as I have been a blogger. SDC.com is Social Media Today’s community site, focussed on all aspects of Business Intelligence, Data Warehousing and Analytics, with a pinch of social media thrown in to the mix.

Brian Roger, the SDC.com editor, was recently kind enough to interview me about my career in BI, the challenges I have faced and what has helped to overcome these. This interview is now available to listen to as part of their Podcast series – click on the image below to visit their site.

sdc-podcast

SmartDataCollective.com Intervew

I would be interested in feedback about any aspect of this piece, which I am grateful to Brian for arranging.
 


 
Social Media Today LLC helps global organizations create purpose-built B2B social communities designed to achieve specific, measurable corporate goals by engaging exactly the customers and prospects they most want to reach. Social Media Today helps large companies leverage the enormous power of social media to build deeper relationships with potential customers and other constituencies that influence the development of new business. They have found that their primary metrics of success are levels of engagement and business leads. One thousand people who come regularly and might buy an SAP, Oracle or Teradata system some day is better than a million people who definitely won’t.

Social Media Today LLC, is a battle-tested, nimble team of former journalists, online managers, and advertising professionals who have come together to make a new kind of media company. With their backgrounds, and passions for, business-to-business and public policy conversations, they have decided to focus their efforts in this area. To facilitate the types of convresations that they would like to see Social Media Today is assembling the world’s best bloggers and providing them with an independent “playground” to include their posts, to comment and rate posts, and to connect with each other. On their flagship site, SocialMediaToday.com, they have brought together many of the most intriguing and original bloggers on media and marketing, covering all aspects of what makes up the connective tissue of social media from a global perspective.
 

Chase Zander Forums – IT Director Report and Change Director Invitation

Following on from my series of posts about the inaugural Chase Zander IT Director Forum that I helped to organise earlier in the year, a report covering the event, which was held in Birmingham, has just been released by Chase Zander themselves.

Anyone interested in learning more about what goes on at these events is welcome to view the document, a PDF version of which may be downloaded here.
 


 
The next Chase Zander event is the Change Director Forum (attendance at which moved me to write the very first article on this blog: Business is from Mars and IT is from Venus). This will be held in London on the evening of 9th July 2009 at the following venue:

Address: St. Clement’s House
27 – 28 Clement’s Lane
London EC4N 7AE
Nearest tubes: Bank or Monument
Map: click here

 
Registration starts at 17:30 and the event itself kicks of at 18:15.

Details of the programme will be published nearer the date.

Attendance is free, but prior registration is required. Please mail Emily White at emily.white@chasezander.com or call her on 0870 997 9014.
 

Bogorad on the basics of Change Management – TechRepublic

TechRepublic linkedin

As always any LinkedIn.com links require you to be a member of the site and the group links require you to be a member of the group.

In recent weeks, I have posted two pieces relating how a discussion thread on the LinkedIn.com Chief Information Officer (CIO) Network group had led to an article on TechRepublic. The first of these was, The scope of IT’s responsibility when businesses go bad and the second, “Why taking a few punches on the financial crisis just might save IT” by Patrick Gray on TechRepublic.

This week, by way of variation, I present an article on TechRepublic that has led to heated debate on the LinkedIn.com Organizational Change Practitioners group. Today’s featured article is by one of my favourite bloggers, Ilya Bogorad and is entitled, Lessons in Leadership: How to instigate and manage change.

Metamorphosis II - Maurits Cornelis Escher (1898 - 1972)

The importance of change management in business intelligence projects and both IT and non-IT projects in general is of course a particular hobby-horse of mine and a subject I have written on extensively (a list of some of my more substantial change-related articles can be viewed here). I have been enormously encouraged by the number of influential IT bloggers who have made this very same connection in the last few months. Two examples are Maureen Clarry writing about BI and change on BeyeNetwork recently (my article about her piece can be read here) and Neil Raden (again on BeyeNetwork) who states:

[…] technology is never a solution to social problems, and interactions between human beings are inherently social. This is why performance management is a very complex discipline, not just the implementation of dashboard or scorecard technology. Luckily, the business community seems to be plugged into this concept in a way they never were in the old context of business intelligence. In this new context, organizations understand that measurement tools only imply remediation and that business intelligence is most often applied merely to inform people, not to catalyze change. In practice, such undertakings almost always lack a change management methodology or portfolio.

You can both read my reflections on Neil’s article and link to it here.

Ilya’s piece is about change in general, but clearly he brings both an IT and business sensibility to his writing. He identifies five main areas to consider:

  1. Do change for a good reason
  2. Set clear goals
  3. Establish responsibilities
  4. Use the right leverage
  5. Measure and adjust

There are enormous volumes of literature about change management available, some academic, some based on practical experience, the best combining elements of both. However it is sometimes useful to distil things down to some easily digestible and memorable elements. In his article, Ilya is effectively playing the role of a University professor teaching a first year class. Of course he pitches his messages at a level appropriate for the audience, but (as may be gauged from his other writings) Ilya’s insights are clearly based on a more substantial foundation of personal knowledge.

When I posted a link to Ilya’s article on the LinkedIn.com Organizational Change Practitioners group, it certainly elicited a large number of interesting responses (74 at the time of publishing this article). These came from a wide range of change professionals who are members. It would not be an overstatement to say that debate became somewhat heated at times. Ilya himself also made an appearance later on in the discussions.

Some of the opinions expressed on this discussion thread are well-aligned with my own experiences in successfully driving change; others were very much at variance to this. What is beyond doubt are two things: more and more people are paying very close attention to change management and realising the pivotal role it has to play in business projects; there is also a rapidly growing body of theory about the subject (some of it informed by practical experience) which will hopefully eventually mature to the degree that parts of it can be useful to a broader audience change practitioners grappling with real business problems.
 


 
Other TechRepublic-related articles on this site inlcude: “Why taking a few punches on the financial crisis just might save IT” by Patrick Gray on TechRepublic and Ilya Bogorad on Talking Business.
 
Ilya Bogorad is the Principal of Bizvortex Consulting Group Inc, a management consulting company located in Toronto, Canada. Ilya specializes in building better IT organizations and can be reached at ibogorad@bizvortex.com or (905) 278 4753. Follow him on Twitter at twitter.com/bizvortex.
 

Jargon

Alice consulting with an industry expert

  `As I was saying, that seems to be done right — though I haven’t time to look it over thoroughly just now — and that shows that there are three hundred and sixty-four days when you might get un-birthday presents –‘

`Certainly,’ said Alice.

`And only one for birthday presents, you know. There’s glory for you!’

`I don’t know what you mean by “glory”,’ Alice said.

Humpty Dumpty smiled contemptuously. `Of course you don’t — till I tell you. I meant “there’s a nice knock-down argument for you!”‘

`But “glory” doesn’t mean “a nice knock-down argument”,’ Alice objected.

`When I use a word,’ Humpty Dumpty said, in rather a scornful tone, `it means just what I choose it to mean — neither more nor less.’

`The question is,’ said Alice, `whether you can make words mean so many different things.’

`The question is,’ said Humpty Dumpty, `which is to be master — that’s all.’

Through the Looking-Glass and what Alice found there, by Lewis Carroll

 

Yesterday I was moved to post the above section from one of my favourite books on the LinkedIn.com Organisational Change Practitioners forum. The precise thread was entitled, Commitment during Change (as ever you need to be a member of LinkedIn.com and thr group to access the preceding links). The context was an increasingly intricate discussion about what constituted a “burning platform”; if this was a good thing to be standing on, or not; and whether such a situation was likely to lead to a positive or negative reaction on behalf of those standing on it.

My first contribution to this section of the discussion was as follows (with some light editing):

A burning platform tends to suggest panic and an imperative to do something (anything) right now. Think about it; the burning bit and… well… being on a platform. I am not sure that this is the best metaphor for instilling commitment.

Commitment may be passionate, but it is more rational, more of an active choice as opposed to, “what do I have to do to get out of here, my toes are getting hot?”

Telling someone that they are on a burning platform will certainly get their attention – they may also be willing to listen to you if you have some suggestion that might help, but this does not sound like instilling commitment in them to me; more like instilling fear.

Commitment tends to suggest a belief on behalf of the committed that what they are being asked to do is right for them and necessary for the broader organisation (despite it potentially being difficult and/or painful).

Commitment is not fleeing a burning platform – that’s just a survival instinct. Instead commitment might be exhibited by a person deciding to return to a burning platform to rescue some one.

The Alice quote came after I had posted the above thoughts, but before the post that I wanted to focus on in this article. This was about professional jargon and was as follows (again lightly edited):

When I was studying Mathematics, the use of words to mean something other than their ordinary meaning became second nature. The uninitiated would never have guessed the recherché meanings we ascribed to everyday words such as “ring”, “field” or “group”.

Early in my IT career I went over to the dark side, quoting impenetrable acronyms with the best of them. However as my role became more part of the business, I had something of an epiphany. I realised that people were not really that impressed by jargon, that they were more likely to assume (sometimes correctly) that the jargon-user was trying to cover something up or sound clever, and that maybe there was a better way.

Nowadays I am sometimes guilty of using complicated English, but I hope that it is mostly just English (as opposed to English 2.0 – now with even more terminology and even less meaning). I will crave your indulgence about the bit of French above of course :-o.

I think that jargon is both useful and inescapable when communicating efficiently with fellow professionals in a field (no not the Maths meaning of “field”); in all other cases it is mostly a hindrance to being understood.

Now I am sure that an assidious reader would have no problem whatsoever in finding counter-examples to my call for plain-speaking about IT; they are probably sprinkled liberally throughout this blog. Maybe this is a case of doing what I say, rather than what I do. However, it is interesting the number of commentators who have suggested that it would help IT professionals to increase their standing with their colleagues if they dropped the technical jargon and learned to speak more like a business person (e.g. see my comments on Ilya Bogorad’s article about Talking Business).

While getting business people to terminate their love affair with their own version of jargon might be wishful thinking, it is pleasing to go beyond Ilya’s recommendation and contemplate a world where a spade is called a spade and not a terrain relocation appliance.

Sadly it is all too often the case that the number of words used in a business context is inversely proportional to the quantum of meaning that they convey. Perhaps it is time for professionals in all walks of life to take a lead from Humpty Dumpty and begin to better assert their mastery of vocabulary.
 

Using multiple business intelligence tools in an implementation – Part I

linkedin The Data Warehousing Institute The Data Warehousing Institute (TDWI™) 2.0

Introduction

This post follows on from a question that was asked on the LinkedIn.com Data Warehousing Institute (TDWI™) 2.0 group. Unfortunately the original thread is no longer available for whatever reason, but the gist of the question was whether anyone had experience with using a number of BI tools to cover different functions within an implementation. So the scenario might be: Tool A for dashboards, Tool B for OLAP, Tool C for Analytics, Tool D for formatted reports and even Tool E for visualisation.

In my initial response I admitted that I had not faced precisely this situation, but that I had worked with the set-up shown in the following diagram, which I felt was not that dissimilar:

An example of a multi-tier BI architecture with different tools
An example of a multi-tier BI architecture with different tools

Here there is no analytics tool (in the statistical modelling sense – Excel played that role) and no true visualisation (unless you count graphs in PowerPlay that is), but each of dashboards, OLAP cubes, formatted reports and simple list reports are present. The reason that this arrangement might not at first sight appear pertinent to the question asked on LinkedIn.com is that two of the layers (and three of the report technologies) are from one vendor; Cognos at the time, IBM-Cognos now. The reason that I felt that there was some relevance was that the Cognos products were from different major releases. The dashboard tool being from their Version 8 architecture and the OLAP cubes and formatted reports from their Version 7 architecture.
 
 
A little history

London Bridge circa 1600
London Bridge circa 1600

Maybe a note of explanation is necessary as clearly we did not plan to have this slight mismatch of technologies. We initially built out our BI infrastructure without a dashboard layer. Partly this was because dashboards weren’t as much of a hot topic for CEOs when we started. However, I also think it also makes sense to overlay dashboards on an established information architecture (something I cover in my earlier article, “All that glisters is not gold” – some thoughts on dashboards, which is also pertinent to these discussions).

When we started to think about adding icing to our BI cake, ReportStudio in Cognos 8 had just come out and we thought that it made sense to look at this; both to deliver dashboards and to assess its potential future role in our BI implementation. At that point, the initial Cognos 8 version of Analysis Studio wasn’t an attractive upgrade path for existing PowerPlay users and so we wanted to stay on PowerPlay 7.3 for a while longer.

The other thing that I should mention is that we had integrated an in-house developed web-based reporting tool with PowerPlay as the drill down tool. The reasons for this were a) we had already trained 750 users in this tool and it seemed sensible to leverage it and b) employing it meant that we didn’t have to buy an additional Cognos 7 product, such as Impromptu, to support this need. This hopefully explains the mild heterogeneity of our set up. I should probably also say that users could directly access any one of the BI tools to get at information and that they could navigate between them as shown by the arrows in the diagram.

I am sure that things have improved immensely in the Cognos toolset since back then, but at the time there was no truly seamless integration between ReportStudio and PowerPlay as they were on different architectures. This meant that we had to code the passing of parameters between the ReportStudio dashboard and PowerPlay cubes ourselves. Although there were some similarities between the two products, there were also some differences at the time and these, plus the custom integration we had to develop, meant that you could also view the two Cognos products as essentially separate tools. Add in here the additional custom integration of our in-house reporting application with PowerPlay and maybe you can begin to see why I felt that there were some similarities between our implementation and one using different vendors for each tool.

I am going to speak a bit about the benefits and disadvantages of having a single vendor approach later, but for now an obvious question is “did our set-up work?” The answer to this was a resounding yes. Though the IT work behind the scenes was maybe not the most elegant (though everything was eminently supportable), from the users’ perspective things were effectively seamless. To slightly pre-empt a later point, I think that the user experience is what really matters, more than what happens on the IT side of the house. Nevertheless let’s move on from some specifics to some general comments.
 
 
The advantages of a single vendor approach to BI

One-stop shopping
One-stop shopping

I think that it makes sense if I lay my cards on the table up-front. I am a paid up member of the BI standardisation club. I think that you only release the true potential of BI when you take a broad based approach and bring as many areas as you can into your warehouse (see my earlier article, Holistic vs Incremental approaches to BI, for my reasons for believing this).

Within the warehouse itself there should be a standardised approach to dimensions (business entities and the hierarchies they are built into should be the same everywhere – I’m sure this will please all my MDM friends out there) and to measures (what is the point if profitability is defined different ways in different reports?). It is almost clichéd nowadays to speak about “the single version of the truth”, but I have always been a proponent of this approach.

I also think that you should have the minimum number of BI tools. Here however the minimum is not necessarily always one. To misquote one of Württemberg’s most famous sons:

Everything should be made as simple as possible, but no simpler.

What he actually said was:

It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience.

but maybe the common rendition is itself paying tribute to the principle that he propounded. Let me pause to cover what are the main reasons quoted for adopting a single vendor approach in BI:

  1. Consistent look-and-feel: The tools will have a common look-and-feel, making it easier for people to use them and simplifying training.
  2. Better interoperability: Interoperability between the tools is out-of-the-box, saving on time and effort in developing and maintaining integration.
  3. Clarity in problem resolution: If something goes wrong with your implementation, you don’t get different vendors blaming each other for the problem.
  4. Simpler upgrades: You future proof your architecture, when one element has a new release, it is the vendor’s job to ensure it works with everything else, not yours.
  5. Less people needed: You don’t need to hire an expert for each different vendor tool, thereby reducing the size and cost of your BI team.
  6. Cheaper licensing: It should be cheaper to buy a bundled solution from one vendor and ongoing maintenance fees should also be less.

This all seems to make perfect sense and each of the above points can be seen to be reducing the complexity and cost of your BI solution. Surely it is a no-brainer to adopt this approach? Well maybe. Let me offer some alternative perspectives on each item – none of these wholly negates the point, but I think it is nevertheless worth considering a different perspective before deciding what is best for your organisation.

  1. Consistent look-and-feel: It is not always 100% true that different tools from the same vendor have the same look-and-feel. This might be down to quality control at the vendor, it might be because the vendor has recently acquired part of their product set and not fully integrated it as yet, or – even more basically – it may be because different tools are intended to do different things. To pick one example from outside of BI that has frustrated me endlessly over the years: PowerPoint and Word seem to have very little in common, even in Office 2007. Hopefully different tools from the same vendor will be able to share the same metadata, but this is not always the case. Some research is probably required here before assuming this point is true. Also, picking up on the Bauhaus ethos of form dictating function, you probably don’t want to have your dashboard looking exactly like your OLAP cubes – it wouldn’t be a dashboard then would it? Additional user training will generally be required for each tier in your BI architecture and a single-vendor approach will at best reduce this somewhat.
  2. Better interoperability: I mention an problem with interoperability of the Cognos toolset above. This is is hopefully now a historical oddity, but I would be amazed if similar issues do not arise at least from time to time with most BI vendors. Cognos itself has now been acquired by IBM and I am sure everyone in the new organisation is doing a fine job of consolidating the product lines, but it would be incredible if there were not some mismatches that occur in the process. Even without acquisitions it is likely that elements of a vendor’s product set get slightly out of alignment from time to time.
  3. Clarity in problem resolution: This is hopefully a valid point, however it probably won’t stop your BI tool vendor from suggesting that it is your web-server software, or network topology, or database version that is causing the issue. Call me cynical if you wish, I prefer to think of myself as a seasoned IT professional!
  4. Simpler upgrades: Again this is also most likely to be a plus point, but problems can occur when only parts of a product set have upgrades. Also you may need to upgrade Tool A to the latest version to address a bug or to deliver desired functionality, but have equally valid reasons for keeping Tool B at the previous release. This can cause problems in a single supplier scenario precisely because the elements are likely to be more tightly coupled with each other, something that you may have a chance of being insulated against if you use tools from different vendors.
  5. Less people needed: While there might be half a point here, I think that this is mostly fallacious. The skills required to build an easy-to-use and impactful dashboard are not the same as building OLAP cubes. It may be that you have flexible and creative people who can do both (I have been thus blessed myself in the past in projects I ran), but this type of person would most likely be equally adept whatever tool they were using. Again there may be some efficiencies in sharing metadata, but it is important not to over-state these. You may well still need a dashboard person and an OLAP person, if you don’t then the person who can do both with probably not care about which vendor provides the tools.
  6. Cheaper licensing: Let’s think about this. How many vendors give you Tool B free when you purchase Tool A? Not many is the answer in my experience, they are commercial entities after all. It may be more economical to purchase bundles of products from a vendor, but also having more than one in the game may be an even better way of ensuring that cost are kept down. This is another area that requires further close examination before deciding what to do.

 
A more important consideration

Overall it is still likely that a single-vendor solution is cheaper than a multi-vendor one, but I hope that I have raised enough points to make you think that this is not guaranteed. Also the cost differential may not be as substantial as might be thought initially. You should certainly explore both approaches and figure out what works best for you. However there is another overriding point to consider here, the one I alluded to earlier; your users. The most important thing is that your users have the best experience and that whatever tools you employ are the ones that will deliver this. If you can do this while sticking to a single vendor then great. However if your users will be better served by different tools in different tiers, then this should be your approach, regardless of whether it makes things a bit more complicated for your team.

Of course there may be some additional costs associated with such an approach, but I doubt that this issue is insuperable. One comparison that it may help to keep in mind is that the per user cost of many BI tools is similar to desktop productivity tools such as Office. The main expense of BI programmes is not the tools that you use to deliver information, but all the work that goes on behind the scenes to ensure that it is the right information, at the right time and with the appropriate degree of accuracy. The big chunks of BI project costs are located in the four pillars that I consistently refer to:

  1. Understand the important business decisions and what figures are necessary to support these.
  2. Understand the data available in the organisation, how it relates to other data and to business decisions.
  3. Transform the data to provide information answering business questions.
  4. Focus on embedding the use of information in the corporate DNA.

The cost of the BI tools themselves are only a minor part of the above (see also, BI implementations are like icebergs). Of course any savings made on tools may make funds available for other parts of the project. It is however important not to cut your nose off to spite your face here. Picking right tools for the job, be they from one vendor or two (or even three at a push) will be much more important to the overall payback of your project than saving a few nickels and dimes by sticking to a one-vendor strategy just for the sake of it.
 


 
Continue reading about this area in: Using multiple business intelligence tools in an implementation – Part II
 

Maureen Clarry stresses the need for change skills in business intelligence on BeyeNetwork

The article

beyenetwork2

Maureen Clarry begins her latest BeyeNETWORK article, Leading Change in Business Intelligence, by stating:

If there was a standard list of core competencies for leaders of business intelligence (BI) initiatives, the ability to manage complex change should be near the top of the list.

I strongly concur with Maureen’s observation and indeed the confluence of BI and change management is a major theme of this blog; as well as the title of one of my articles on the subject. Maureen clearly makes the case that “business intelligence is central to supporting […] organizational changes” and then spends some time on Prosci’s ADKAR model for leading change; bringing this deftly back into the BI sphere. Her closing thoughts are that such a framework can help a lot in driving the success of a BI project.
 
 
My reflections

I find it immensely encouraging that an increasing number of BI professionals and consultants are acknowledging the major role that change plays in our industry and in the success of our projects. In fact it is hard to find some one who has run a truly successful BI project without paying a lot of attention to how better information will drive different behaviour – if it fails to do this, then “why bother?” as Maureen succinctly puts it.

Without describing it as anything so grand as a framework, I have put together a trilogy of articles on the subject of driving cultural transformation via BI. These are as follows:

Marketing Change
Education and cultural transformation
Sustaining Cultural Change

However the good news about many BI professionals and consultants embracing change management as a necessary discipline does not seem to have filtered through to all quarters of the IT world. Many people in senior roles still seem to see BI as just another technology area. This observation is born out of the multitude of BI management roles that request an intimate knowledge of specific technology stacks. These tend to make only a passing reference to experience of the industry in question and only very infrequently mention the change management aspects of BI at all.

Of course there are counterexamples, but the main exceptions to this trend seem to be where BI is part of a more business focused area, maybe Strategic Change, or the Change Management Office. Here it would be surprising if change management skills were not stressed. When BI is part of IT it seems that the list of requirements tends to be very technology focussed.

In an earlier article, BI implementations are like icebergs I argued that, in BI projects, the technology – at least in the shape of front-end slice-and-dice tools – is not nearly as important as understanding the key business questions that need to be answered and the data available to answer them with. In “All that glisters is not gold” – some thoughts on dashboards, I made similar points about this aspect of BI technology.

I am not alone in holding these opinions, many of the BI consultants and experienced BI managers that I speak to feel the same way. Given this, why is there the disconnect that I refer to above? It is a reasonable assumption that when a company is looking to set up a new BI department within IT, it is the CIO who sets the tone. Does this lead us inescapably to the the conclusion that many CIOs just don’t get BI?

I hope that this is not the case, but I see increasing evidence that there may be a problem. I suppose the sliver lining to this cloud is that, while such attitudes exist, they will lead to opportunities for more enlightened outfits, such as the one fronted by Maureen Clarry. However it would be even better to see the ideas that Maureen espouses moving into the mainstream thinking of corporate IT.
 


 
Maureen Clarry is the Founder and President/CEO of CONNECT: The Knowledge Network, a consulting firm that specializes in helping IT people and organizations to achieve their strategic potential in business. CONNECT was recognized as the 2000 South Metro Denver Small Business of the Year and has been listed in the Top 25 Women-Owned Businesses and the Top 150 Privately Owned Businesses in Colorado. Maureen also participates on the Data Warehousing Advisory Board for The Daniels College of Business at the University of Denver and was recognized by the Denver Business Journal as one of Denver’s Top Women Business Leaders in 2004. She has been on the faculty of The Data Warehousing Institute since 1997, has spoken at numerous other seminars, and has published several articles and white papers. Maureen regularly consults and teaches on organizational and leadership issues related to information technology, business intelligence and business.
 

Business Intelligence Competency Centres

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:

Centre of a Sphere

  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:

  1. 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).
  2. 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.
  3. 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.
  4. 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:

Motar board

  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?):

  1. Understand the important business decisions and what figures are necessary to support these.
  2. Understand the data available in the organisation, how it relates to other data and to business decisions.
  3. Transform the data to provide information answering business questions.
  4. 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.
 

The scope of IT’s responsibility when businesses go bad

linkedin Chief Information Officer (CIO) Network

This article is another relating to a discussion on LinkedIn.com. As with my earlier piece, Short-term “Trouble for Big Business Intelligence Vendors” may lead to longer-term advantage, this was posted on the Chief Information Officer (CIO) Network group

The thread was initiated by Patrick Gray and was entitled: Is IT partially to blame for the financial crisis? (as ever you need to be a member of LinkedIn.com and the group to view this).

Business Failure

Patrick asked:

Information is one of the key components of any IT organization (I would personally argue it’s more important than the technology aspect). Two facts disturb me when one looks at IT’s role in the financial crisis:

1) We in IT have been pushing data warehouse and business intelligence technology for years, saying these technologies should allow for “proactive” decision making at all levels of an organization, and an ability to spot trends and changes in a business’ underlying financial health.

2) The finance industry is usually spends more on IT than any other industry.

This being the case, if BI actually does what we’ve pitched it to do, shouldn’t one of these fancy analytical tools spotted the underlying roots of the financial crisis in at least one major bank? Is IT partially culpable for either not looking at the right data, or selling a bill of goods in terms of the “intelligence” aspect of BI?

I have written elsewhere on LinkedIn.com about business intelligence’s role in the financial crisis. My general take is that if the people who were committing organisations to collateralised debt obligations and other even more esoteric assent-backed securities were unable (or unwilling) to understand precisely the nature of the exposure that they were taking on, then how could this be reflected in BI systems. Good BI systems reflect business realities and risk is one of those realities. However if risk is as ill-understood as it appears to have been in many financial organisations, then it is difficult to see how BI (or indeed it’s sister area of business analytics) could have shed light where the layers of cobwebs were so dense.

So far, so orthodox, but Patrick’s question got me thinking along a different line, one that is more closely related to the ideas that I propounded in Business is from Mars and IT is from Venus last year. I started wondering, ‘is it just too easy for IT to say, “the business people did not understand the risks, so how were we expected to?”?’ (I think I have that punctuation right, but would welcome corrections from any experts reading this). This rather amorphous feeling was given some substance when I read some of the other responses.

However, I don’t want to focus too much on any one comment. My approach will be instead to take a more personal angle and describe some of the thoughts that the comments provoked in me (I am using “provoked” here in a positive sense, maybe “inspired” would have been a better choice of word). If you want to read my comments with the full context, then please click on the link above. What I am going to do here is to present some excerpts from each of my two lengthier contributions. The first of these is as follows (please note that I have also corrected a couple of typos and grammatical infelicities):

Rather than being defensive, and as a BI professional I would probably have every right to be so, I think that Patrick has at least half a point. If some organisations had avoided problems (or mitigated their impact) through the use of good BI (note the adjective) in the current climate, then BI people (me included) would rush to say how much we had contributed. I have certainly done this when the BI systems that I have implemented helped an organisation to swing from record losses to record profits.

Well if we are happy to do this, then we have to take some responsibility when things don’t go so well. It worries me when IT people say that non-IT managers are accountable for the business and IT is just accountable for IT. Surely in a well-functioning organisation, IT is one department that shares responsibility for business success with all the other front-line and service departments.

I have seen it argued with respect to failed financial institutions that IT can only provide information and that other executives take decisions. Well if this is the case, then I question how well the information has been designed to meet business needs and to drive decisions. To me this is evidence of bad BI (note the adjective again).

There are some specific mitigating factors for IT within the current climate, including poor internal (non-IT) governance and the fact that even the people who were writing some financial instruments did not understand the potential liabilities that the we taking on. If this is the case, then how can such risk be rolled up meaningfully? However these factors do not fully exculpate IT in my opinion. I am not suggesting for a second that IT take prime responsibility, but to claim no responsibility whatsoever is invidious.

So yes either poor information, or a lack of information (both of which are IT’s fault – as well as that of non-IT business folk) are a contributory factors to the current problems.

Also, while IT managers see themselves as responsible only for some collateral department, semi-detached from the rest of the business, we will see poor IT and poor information continuing to contribute to business failure.

This is the second passage:

[…]

I just wonder how it is that IT people at such firms can say that any failures are 100% nothing to do with them, as opposed to say 1% responsibility, or something of that nature.

Part of the role of professionals working in BI is to change the organisation so that numerical decision making (backed up of course by many other things, including experience and judgement) becomes part of the DNA. We are to blame for this not being the case in many organisations and can’t simply throw our hands up and say “wasn’t me”.

[…]

I will freely admit that there was a large dose of Devil’s Advocate in my two responses. As I have stated at the beginning of this piece, I am not so masochistic to believe that IT caused the current financial crisis, however I do not think that IT can be fully absolved of all blame.

My concerns about IT’s role relate to the situation that I see in some companies where IT is a department set apart, rather than being a central part of the overall business. In this type of circumstance (which is perhaps more common than anyone would like to think), the success of the IT and the non-IT parts of the business are decoupled.

Under these arrangements, it would be feasible for IT to be successful and the business to suffer major losses, or for the business to post record profits while IT fails to deliver projects. Of couse such decoupling can happen in other areas; for example Product A could have a stellar year, while Product B fails miserably – the same could happen with countries or regions. However there is something else here, a sense that IT can sometimes be an organisation within an organisation, in a way that other service departments generally are not.

Rather than expanding further on this concept here, I recommend you read Jim Anderson’s excellent article Here’s What’s Really Wrong With IT And How To Fix It on his blog, The Business of IT. I think that there is a good deal of alignment between Jim and I on this issue; indeed I was very encouraged to find his blog and see that his views were not a million miles from my own.

I would also like to thank Patrick for posting his initial question. It’s good when on-line forums lead you to take an alternative perspective on things.
 


 
Continue reading about this area in: Two pictures paint a thousand words… and “Why taking a few punches on the financial crisis just might save IT” by Patrick Gray on TechRepublic.

Also check out Jill Dyché’s article: Dear IT: A Letter from Your Business Users
 

Recipes for success?

I should acknowledge that I am indebted to a conversation that I had with John Collins on his blog, Views from the Bridge, for some of the themes I discuss in this article.
 
Recipe for Success?
 
Introduction

Towards the end of a recent article on perseverance I referred to people’s desire to find recipes for success. Here’s what I said:

Sometimes we want to find a magic recipe for success, or – to mix the metaphor – a silver bullet. We want to discover a series of defined steps to take that, if repeated religiously, will guarantee that we get to the desired goal each and every time. That’s why articles entitled “The 5 ways to […]” and “My top tips for […]” are so well-read on the web.

As well as my examples of internet top tips (see any number of articles claiming to tell you how to use twitter successfully to get the idea), this phenomenon is also a major factor behind the enduring popularity of celebrity business books. As far as I can see, these fall into two categories.
 
 
1. The Ex-CEO

This is where the extremely successful and well-known Mr Brown (and sadly it is still mostly Mr, rather than Ms Brown), now retired but previously President and CEO of Big Company Inc., writes (or more likely has some one ghost-write) a memoir explaining the secrets of his success. While the book may dwell on their upbringing, education, role models, or character-forming events in their lives, much of the work will probably focus on them just being much smarter, more risk-taking, or having greater insight than the competition (most likely all of these). Of course there may well be some interesting tit-bits amongst the reams of self-aggrandisement, but it is worth questioning just how applicable these might be to your own situation.

Are the things that Mr Brown ascribes his success to really what led to his glittering career? Are there perhaps other factors that are not captured in the memoir, but which, if absent in another organisation, would render implementing Mr Brown’s explicit recommendations valueless? Did Mr Brown’s greatest achievements actually have a big slice of luck attached to them (stumbling upon a market or a product by accident, a major competitor losing their way, events beyond anyone’s control shaping matters and so on)? Would the things that Big Company Inc. did under Mr Brown’s esteemed leadership actually work in another company, in a different market or country and with a distinctive business culture?

Put it this way, if you work in Financial Services, would copying what worked in Retail be a good idea? Alternatively, if two companies are both in Retail, does it make sense for a less successful company to slavishly adopt the strategy of the market leader – wouldn’t it be more sensible if they tried to develop a different strategy in order to differentiate their brand?

Of course there is always value in learning from the mistakes and successes of others, but surely there is a limit to how useful a business memoir can be in forming a business strategy.
 
 
2. The Academic Expert

Here Professor Green (probably still male), has a long and distinguished career in academia, reading and deconstructing the memoirs of Mr Brown and his peers, identifying common themes between them, doing primary research and constructing recherché models of business strategy development and execution. If there is a new management fad out there, Professor Green is sure to know about it – in fact it may well be based on an article of his that appeared in HBR.

Well there is certainly some value in trying to tease out commonalities between successful companies, but this is probably a lot harder than it might seem. While there may be some recurring themes, maybe many of our champions of business are one offs, successful for reasons other than their business models or strategies. In fact they may well be as unique as the people who lead them. Maybe there is no equivalent of the standard model of quantum mechanics (to say nothing of a deeper grand unified theory) that underpins business success – perhaps the science of business is different from the more reductionist sciences, such as physics. Maybe there isn’t a formula for business success; perhaps it is more like Darwinian natural selection (I’ll come back to this idea later).

Whichever way you look at it, again there is probably a limit to how much insight you can glean from this type of book.
 
 
Other genres

Of course this phenomenon extends into many other areas of human activity. As a youth I can remember only too well poring over cricket manuals in an (ultimately fruitless) attempt to improve my batting or wicket-keeping. My father, at the age of 72, still does the same with golf manuals.

The endless array of cooking books also in the same category and where would we be without the panoply of self-help books such as The Seven Habits of Annoyingly Organised People? All of which goes to show that reliance on recipes for success is a deeply ingrained human trait.
 
 
Recipes for success in IT

Having established that people like turning to both “My top tips for […]” and “Mr Brown’s Glittering Career” (available at all good booksellers) how does this aspect of human nature impinge on one of my main areas of endeavour, IT?

Well it has a major impact in my opinion. In fact it is difficult to think of an area of life more obsessed with frameworks, blue-prints, road-maps, procedures, best practices and methodologies (to say nothing of ontologies and taxonomies). All of these are intended to take the risk out of activities – well at least to provide the people following them with the ability to say “well I did what the methodology told me to do”. Of course IT projects and IT development are very complex things and standards of design, coding and behaviour of systems are of paramount importance; but it still seems that IT people have a more visceral relationship with the above-stated areas than would be dictated solely by ticking the necessary boxes.

Nevertheless, having been personally responsible for instigating a thoroughgoing process of standardisation and quality control in a software house (and thereby obtaining an ISO accreditation), it would be churlish of me to argue that that there is no benefit in rigorously applying methodologies in IT.

When it comes to some aspects of project management and to change management in particular, some of the scepticism that I exhibited about celebrity business books returns. It’s not so much that a methodology or even a list of items to tick is not valuable, but that it cannot be an end in itself. The important thing is the thinking that goes into drawing up what you need to do and how you are going to do it, not the method that you use to record these and monitor progress. Sometimes these crucial ingredients get lost. Indeed there does seem to be an entire class of people who focus just on managing lists, rather than the ideas behind them, or the people actually doing the work.
 
 
The benefits of a Darwinian approach

Charles Darwin

I raised the idea of a Darwinian approach to business strategy earlier in this article. There do seem to be some crossovers with how we observe businesses in operation. We are familiar with the image of companies competing with each other for limited resources (our wallets, mine being very limited at present). We understand the pressure that organisations are under to come up with better, cheaper, more functional and sexier products (that are now carbon neutral and ethically-sourced as well).

The language of business is suffused by jungle analogies. The adaptation of Tennyson’s “Nature, red in tooth and claw” to capitalism being just one of the most well-known examples. The companies that are best at this game survive and thrive, those that are not fail and are forgotten. Companies in more mature markets are even often referred to as dinosaurs or fossils. The idea of never-ending refinement and progress pushing on is an essential part of business.

However, perhaps this evolutionary approach, so evident at the macro-level can also work on a micro-scale. Maybe, rather than relying on the thoughts of Mr Brown or Professor Green, a better approach would be come up with some ideas of our own, test them, discard the bad ones and nurture the less bad ones. In time, with appropriate development and alteration, the less bad may become good and then even great (hang on, I seem to have found my way back to business books with that phrase!).

To me, such an approach is more likely to result in something novel and valuable. Following a recipe for success can only ever be as good as the recipe itself. Thinking for yourself can transcend these limitations and I would argue that the downside is no greater than attempting to ape someone else’s ideas. In both cases the worst that can happen is only extinction.
 
 
Disclaimer – sort of

Of course this article has a degree of self reference. Relying upon your own intellect (hopefully refined and improved by other people’s input) is of course another recipe for success. However I hope it is a less proscriptive one. I recommend giving it a try.
 


 
Continue reading about this area in: Synthesis.
 

The Dictatorship of the Analysts

Lest it be thought that I am wholly obsessed by the Business Intelligence vs Business Analytics issue (and to be honest I have a whole lot of other ideas for articles that I would rather be working on), I should point out that this piece is not focussed on SAS. In my last correspondence with that organisation (which was in public and may be viewed here) I agreed with Gaurav Verma’s suggestion that SAS customers be left to make up their own minds about the issue.

CIO Magazine

However the ripples continue to spread from the rock that Jim Davis threw into the Business Intelligence pond. The latest mini-tsunami is in an article on CIO.com by Scott Staples, President and Co-CEO of IT Services at MindTree. [Incidentally, I’d love to tell you more about MindTree’s expertise in the area of Business Intelligence, but unfortunately I can’t get their web-site’s menu to work in either Chrome or IE8; I hope that you have better luck.]

Scott’s full article is entitled Analytics: Unlocking Value in Business Intelligence (BI) Initiatives. In this, amongst other claims, Scott states the following:

To turn data into information, companies need a three-step process:

  1. Data Warehouse (DW)—companies need a place for data to reside and rules on how the data should be structured.
  2. Business Intelligence—companies need a way to slice and dice the data and generate reports.
  3. Analytics—companies need to extract the data, analyze trends, uncover opportunities, find new customer segments, and so forth.

Most companies fail to add the third step to their DW and BI initiatives and hence fall short on converting data into information.

He goes on to say:

[…] instead of companies just talking about their DW and BI strategies, they must now accept analytics as a core component of business intelligence. This change in mindset will solve the dilemma of data ≠ information:

Current Mindset: DW + BI = Data

Future Mindset: DW + (BI + Analytics) = Information

Now in many ways I agree with a lot of what Scott says, it is indeed mostly common sense. My quibble comes with his definitions of BI and Analytics above. To summarise, he essentially says “BI is about slicing and dicing data and generating reports” and “Analytics is about extracting data, analysing trends, uncovering opportunities and finding new customer segments”. To me Scott has really just described two aspects of exactly the same thing, namely Business Intelligence. What is slicing and dicing for if not to achieve the aims ascribed above to Analytics?

Let me again – and for the sake of this argument only – accept the assertion that Analytics is wholly separate from BI (rather than a subset). As I have stated before this is not entirely in accordance with my own views, but I am not religious about this issue of definition and can happily live with other people’s take on it. I suppose that one way of thinking about this separation is to call the bits of BI that are not Analytics by the older name of OLAP (possibly ignoring what the ‘A’ stands for, but I digress). However, even proponents of the essential separateness of BI and Analytics tend to adopt different definitions to Scott.

To me what differentiates Analytics from other parts of BI is statistics. Applying advanced (or indeed relatively simple) statistical methods to structured, reliable data (such as one would hope to find in data warehouses more often than not) would clearly be the province of Analytics. Thus seeking to find attributes of customers (e.g. how reliably they pay their bills, or what areas they live in) or events in their relationships with an organisation (e.g. whether a customer service problem arose and how it was dealt with) that are correlated with retention/repeat business would be Analytics.

Maybe discerning deeply hidden trends in data would also fall into this camp, but what about the rather simpler “analysing trends” that Scott ascribes to Analytics? Well isn’t that just another type of slice and dice that he firmly puts in the BI camp?

Trend analysis in a multidimensional environment is simply using time as one of the dimensions that you are slicing and dicing your measures by. If you want to extrapolate from data, albeit in a visual (and possibly non-rigorous manner) to estimate future figures, then often a simple graph will suffice (something that virtually all BI tools will provide). If you want to remove the impact of outlying values in order to establish a simple correlation, then most BI tools will let you filter, or apply bands (for example excluding large events that would otherwise skew results and mask underlying trends).

Of course it is maybe a little more difficult to do something like eliminating seasonality from figures in these tools, but then this is pretty straightforward to do in Excel if it is an occasional need (and most BI tools support one-click downloading to Excel). If such adjustments are a more regular requirement, then seasonally adjusted measures can be created in the Data Mart with little difficulty. Then pretty standard BI facilities can be used to do some basic analysis.

Of course paid-up statisticians may be crying foul at such loose analysis, of course correlation does not imply causation, but here we are talking about generally rather simple measures such as sales, not the life expectancy of a population, or the GDP of a country. We are also talking about trends that most business people will already have a good feeling for, not phenomena requiring the application of stochastic time series to model them.

So, unlike Scott, I would place “back-of-an-envelop” and graphical-based analysis of figures very firmly in the BI camp. To me proper Analytics is more about applying rigorous statistical methods to data in order to either generate hypotheses, or validate them. It tends to be the province of specialists, whereas BI (under the definition that I am currently using where it is synonymous with OLAP) is carried out profitably by a wider range of business managers.

So is an absence of Analytics – now using my statistically-based definition – a major problem in “converting data into information” as Scott claims? I would answer with a very firm “no”. If we take information as being that which is generated and consumed by a wide range of managers in an organisation, then if this is wrong then the problem is much earlier on and most likely centred on how the data warehousing and BI parts have been implemented (or indeed in a failure to manage the concomitant behavioural change). I covered what I believe are often the reasons that BI projects fail to live up to their promise in my response to a Gartner report. This earlier article may be viewed here.

In fact I think that what happens is that when broader BI projects fail in an organisation, people fall back on two things: a) their own data (Excel and Access) and b) the information developed by the same statistical experts who are the logical users of Analytic tools. The latter is characterised by a reliance on Finance, or Marketing reports produced by highly numerate people with Accounting qualifications or MBAs, but which are often unconnected to business manager’s day-to-day experiences. The phrase “democratisation of information” has been used in relation to BI. Where BI fails, or does not exist, then the situation I have just described is maybe instead the dictatorship of the analysts.

I have chosen the word “dictatorship” with all of its negative connotations advisedly. I do not think that the situations that I have described above is a great position for a company to be in. The solution is not more Analytics, which simply entrenches the position of the experts to the detriment of the wider business community, but getting the more mass-market disciplines of the BI (again as defined above) and data warehousing pieces right and then focussing on managing the related organisational change. In the world of business information, as in the broader context, more democracy is indeed the antidote to dictatorship.

I have penned some of my ideas about how to give your BI projects the greatest chance of success in many places on this blog. But for those interested, I suggest maybe starting with: Scaling-up Performance Management, “All that glisters is not gold” – some thoughts on dashboards, The confluence of BI and change management and indeed the other blog articles (both here and elsewhere) that these three pieces link to.

Also for those with less time available, and although the article is obviously focussed on a specific issue, the first few sections of Is outsourcing business intelligence a good idea? pull together many of these themes and may be a useful place to start.

If your organisation is serious about adding value via the better use of information, my recommendation is to think hard about these areas rather than leaping into Analytics just because it is the latest IT plat du jour.