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:

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:

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

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.

The importance of feasibility studies in business intelligence

6 May 20093 Nov 2014 Peter James Thomas bi and the economic crisis, business, business intelligence, data warehousing, management information, project management, technology bi, feasibility study, information architecture, it strategy, methodology, success factors

Introduction

In a previous article, A more appropriate metaphor for business intelligence projects, I explained one complication of business intelligence projects. This is that the frequently applied IT metaphor of building is not very applicable to BI. Instead I suggested that BI projects had more in common with archaeological digs. I’m not going to revisit the reasons for the suitability of looking at BI this way here, take a look at the earlier piece if you need convincing, instead I’ll focus on what this means for project estimation.

When you are building up, estimation is easier because each new tier is dependent mostly on completion of the one below, something that the construction team has control over (note: for the sake of simplicity I’m going to ignore the general need to dig foundations for buildings). In this scenario, the initial design will take into account of facts such as the first tier needing to support all of the rest of the floors and that central shafts will be needed to provide access and deliver essential services such as water, electricity and of course network cables. A reductionist approach can be taken, with work broken into discrete tasks, each of which can be estimated with a certain degree of accuracy. The sum of each of these, plus some contingency, hopefully gives you a good feel for the overall project. It is however perhaps salutary to note that even when building up (both in construction and in IT) estimation can still sometimes go spectacularly awry.

When you are digging down, your speed is dependent on what you find. Your progress is dictated by things that are essentially hidden before work starts. If your path ahead (or downwards) is obscured until your have cleared enough earth to uncover the next layer, then each section may hold unexpected surprises and lead to unanticipated delays. While it may be possible to say things like, “well we need to dig down 20m and each metre should take us 10 days”, any given metre might actually take 20 days, or more. There are two issues here; first it is difficult to reduce the overall work into tasks, second it is harder to estimate each task accurately. The further below ground a phase of the dig is, the harder it will be to predict what will happen before ground is broken. Even with exploratory digs, or the use of scanning equipment, this can be very difficult to assess in advance. However it is to the concept of exploratory digs that this article is devoted.

Why a feasibility study is invaluable

At any point in the economic cycle, even more so in today’s circumstances, it is not ideal to tell your executive team that you have no idea how long a project will take, nor how much it might cost. Even with the most attractive of benefits to be potentially seized (and it is my firm belief that BI projects have a greater payback than many other types of IT projects), unless there is some overriding reason that work must commence, then your project is unlikely to gain a lot of support if it is thus characterised. So how to square the circle of providing estimates for BI projects that are accurate enough to present to project sponsors and will not subsequently leave you embarrassed by massive overruns?

It is in addressing this issue that BI feasibility studies have their greatest value. These can be thought of as analogous to the exploratory digs referred to above. Of course there are some questions to be answered here. By definition, a feasibility study cannot cover all of the ground that the real project needs to cover, choices will need to be made. For example, if there are likely to be 10 different data sources for your eventual warehouse, then should you pick one and look at it in some depth, or should you fleetingly examine all 10 areas? Extending our archaeological metaphor, should your exploratory dig be shallow and wide, or a deep and narrow borehole?

A centre-centric approach

In answering this question, it is probably worth considering the fact that not all data sources are alike. There is probably a hierarchy to them, both in terms of importance and in terms of architecture. No two organisations will be the same, but the following diagram may capture some of what I mean here:

Two ways of looking at a systems' hierarchy

The figure shows a couple of ways of looking at your data sources / systems. The one of the left is rather ERP-centric, the one on the right gives greater prominence to front-end systems supporting different lines of business, but wrapped by a common CRM system. There are many different diagrams that could be drawn in many different ways of course. My reason for using concentric circles is to stress that there is often a sense in which information flows from the outside systems (ones primarily focussed on customer interactions and capturing business transactions) to internal systems (focussed on either external or internal reporting, monitoring the effectiveness of processes, or delivering controls).

There may be several layers through which information percolates to the centre; indeed the bands of systems and databases might be as numerous as rings in an onion. The point is that there generally is such a logical centre. Data is often lost on its journey to this centre by either aggregation, or by elements simply not being transferred (e.g. the name of a salesperson is not often recorded on revenue entries in a General Ledger). Nevertheless the innermost segment of the onion is often the most complex, with sometimes arcane rules governing how data is consolidated and transformed on its way to its final destination.

The centre in both of the above diagrams is financial and this is not atypical if what we are considering is an all-pervasive BI system aimed at measuring most, if not all, elements of an organisation’s activity (the most valuable type of BI system in my opinion). Even if your BI project is not all-pervasive (or at least the first phase is more specific), then the argument that there is a centre will probably still hold, however the centre may not be financial in this case.

My suggestion is that this central source of data (of course there may be more than one) is what should be the greatest focus of your feasibility study. There are several reasons for this, some technical, some project marketing-related:

As mentioned above, the centre is often the toughest nut to crack. If you can gain at least some appreciation of how it works and how it may be related to other, more peripheral systems, then this is a big advance for the project. Many of the archaeological uncertainties referred to above will be located in the central data store. Other data sources are likely to be simpler and thus you can be more confident about approaching these and estimating the work required.
A partial understanding of the centre is often going to be totally insufficient. This is because your central analyses will often have to reconcile precisely to other reports, such as those generated by your ERP system. As managers are often measured by these financial scorecards, if you BI system does not give the same total, it will have no credibility and will not be used by these people.
Because of its very nature, an understanding of the centre will require at least passing acquaintance with the other systems that feed data to it. While you will not want to spend as much time on analysing these other systems during the feasibility study, working out some elements of how they interact will be helpful for the main project.
One output from your feasibility study should be a prototype. While this will not be very close to the finished article and may contain data that is both unreconciled and partial (e.g. for just one country or line of business), it should give project sponsors some idea of what they can expect from the eventual system. If this prototype deals with data from the centre then it is likely to be of pertinence to a wide range of managers.
Strongly related to the last point, and in particular if the centre consists of financial data, then providing tools to analyse this is likely to be something that you will want to do early on in the main project. This is both because this is likely to offer a lot of business value and because, if done well, this will be a great advert for the rest of your project. If this is a key project deliverable, then learning as much as possible about the centre during the feasibility study is very important.
Finally what you are looking to build with your BI system is an information architecture. If you are doing this, then it makes sense to start in the middle and work your way outwards. This will offer a framework off of which other elements of your BI system can be hung. The danger with starting on the outside and working inwards is that you can end up with the situation illustrated below.

A possible result of building from the outside in to the center — A possible result of building from the outside in to the centre

Recommendations

So my recommendation is that your feasibility study is mostly a narrow, deep dig, focussed on the central data source. If time allows it would be beneficial to supplement this with a more cursory examination of some of the data sources that feed the centre, particularly as this may be necessary to better understand the centre and because it will help you to get a better idea about your overall information architecture. You do not need to figure out every single thing about the central data source, but whatever you can find out will improve the accuracy of your estimate and save you time later. If you include other data sources in a deep / wide hybrid, then these can initially be studied in much less detail as they are often simpler and the assumption is that they will support later deliveries.

The idea of a prototype was mentioned above. This is something that is very important to produce in a feasibility study. Even if we take to one side the undeniable PR value of a prototype, producing one will allow you to go through the entire build process. Even if you do this with hand-crafted transformation of data (rather than ETL) and only a simplistic and incomplete approach to the measures and dimensions you support, you will at least have gone through each of the technical stages required in the eventual live system. This will help to shake out any issues, highlight areas that will require further attention and assist in sizing databases. A prototype can also be used to begin to investigate system and network performance, things that will influence your system topology and thereby project costs. A better appreciation of all of these areas will help you greatly when it comes to making good estimates.

Having understood quite a lot about your most complex data source and a little about other ones and produced a prototype both as a sales tool and to get experience of the whole build process, you should have all the main ingredients for making a credible presentation to your project sponsors. In this it is very important to stress the uncertainties inherent in BI and manage expectations around these. However you should also be very confident in stating that you have done all that can be done to mitigate the impact of these. This approach, of course supported by a compelling business case, will position you very well to pitch your overall BI project.

Bank Holiday weekend, followed by a busy week

5 May 2009 Peter James Thomas site update

Monday 4th May was a public holiday in the UK and I seem to have been up-to-my-eyes so far this week. After a quiet week blogging last week, normal service should be resumed in the new few days.

Peter

Integration of this blog with twitter.com

30 Apr 20093 Nov 2014 Peter James Thomas business, site update, technology

I have been using twitter.com to a greater degree over the last few months and thought that it would make sense to better integrate my blog with this site.

Accordingly all posts (save a few that are simply site updates) now have a link at the bottom, between the main text and the bookmarks, enabling readers to directly “tweet” the piece. This appears next to the blue twitter.com bird as follows:

	Tweet this article on twitter.com

If you click on this link, you will be taken to your twitter.com page with a new tweet already filled out for you, complete with a shortened link to the relevant article. Of course you can edit this before you post it if you like.

If you are one of the 0.5% of people who are not already on twitter.com, then you will be asked whether you would like to sign up before you can post the article.

I have got some great ideas from twitter.com and met some interesting people. Hopefully this small improvement will help readers to also have similarly positive experiences.

I am proud to announce that this blog is now 100% tweetable!

Peter

A compliment returned by CIO.com

29 Apr 20093 Nov 2014 Peter James Thomas business, erp, general, technology cio.com, information technology, thomas wailgum

On Monday, I featured CIO.com ERP article written by editor Thomas Wailgum. I just learnt that he has returned the compliment in a later piece: What Netbook Fans and Frustrated ERP Customers Have in Common.

It is really interesting to see how responsive to blogosphere comments the professionals are nowadays. The speed of interaction seems to be getting quicker all the time as well.

Two pictures paint a thousand words…

29 Apr 20093 Nov 2014 Peter James Thomas business, it business alignment, technology business projects, information technology, it business alignment, it strategy, success factors

versus

Which is more likely to lead to sustained success?

See also: Business is from Mars and IT is from Venus and The scope of IT’s responsibility when businesses go bad.

Note: I have just had it pointed out to me that I missed out HR from the above diagrams. I hope that none of the HR professionals who read this blog will be too offended by my oversight.

A second note to people who subscribe to this site via e-mail

28 Apr 2009 Peter James Thomas site update

Oops!

The latest e-mail containing content from the site (specifically The scope of IT’s responsibility when businesses go bad and “Why do CFOs and CEOs hate IT? – ERP” – Thomas Wailgum at CIO.com) has none of the images loading.

I’m not sure what the reason for this is at present, but I will attempt to sort it out in FeedBurner for tomorrow’s mail shot. In the meantime, please accept my apologies for this new glitch with the e-mail service.

Peter

“Why do CFOs and CEOs hate IT? – ERP” – Thomas Wailgum at CIO.com

27 Apr 20093 Nov 2014 Peter James Thomas business, erp, international projects, project management, technology cio.com, it projects, thomas wailgum

This is my second article in response to pieces by Thomas Wailgum at CIO.com (you can read the first one here). In Thomas’ latest piece, entitled Why CFOs and CEOs Hate IT: ERP, he touches on an area of which I have lengthy experience, ERP.

I spent the first eight years of my career working for a a software house, whose central product was in what we now call the ERP space. The big boys at Oracle Financials (then without PeopleSoft and J.D. Edwards in-train) were one of our main rivals and I had the pleasure of being involved in several bids where the little guys prevailed against their more renowned competition.

Later in my career, I was a player in a global selection process involving Oracle, PeopleSoft (then a separate company) and SAP and in laying the foundations for a US/European PeopleSoft implementation. Many years later again, after I had recorded a number of successes in another of my core areas, business intelligence, I was asked to add Financial IT once more to my portfolio. In this capacity, I oversaw the implementation of (by this time) Oracle PeopleSoft Financials in Denmark, Italy and then Australia, Hong Kong, Labuan and Singapore.

So, in one way or another, ERP and I have been around the block a few times. Given this, I could identify with some of Thomas’ observations. Many of these can be summed up in the phrase “an ERP system is for life, not just for Christmas.” Here are a few of Thomas’ thoughts:

A typical company in the CFO survey will spend an average of $1.2 million each year (each year!) to maintain, modify and update its ERP system.

ERP systems have become a noose around companies’ necks which tighten as the business changes every year, each customization gets made to the system and costs continue to spiral upward.

In some ways, ERP implementation is just like any other IT project and is difficult to get right for exactly the same reasons. But, as Thomas points out, some things that make ERP stand out are the massive initial outlays, the continuing cost of modifying what you originally thought you needed and the sheer size and complexity of most modern ERP systems.

You can think of your average ERP system from one of the large vendors as analogous to Microsoft Word. Because Word has to appeal to a lot of different users, with different needs and specialisms, it is chock-full of every single feature that anyone could ever need. However, no single person ever uses more than a fraction of these. I think of myself as a reasonably advanced Word user, but I would bet that I utilise no more than 10% of its capabilities. All of the functionality can make it tough for an entry-level user to employ Word in a basic way to do basic things (or if we are talking about Word 2007, it makes it tough for even an expert user to figure out how to do stuff). The same criticism can be applied to ERP systems. Because they include so much functionality for different companies in different industries, it can sometimes be difficult to configure them to do something as simple as entering and paying an invoice. Difficult that is without an army of consultants.

The way to avoid complexities and to get ERP implemented on time and budget is to ignore its broader capabilities and deploy as plain vanilla a version as you can get away with. Flexibility and the ability to customise might be very seductive at sales time, but they are the worst enemy of implementation and are certain to chew up resource, time and money. Instead the secret is to focus on the ways in which Finance in your organisation is the same as it most other organisations. Once you have this sorted out and a basically successful system in place, you can then think about bells and whistles. Of course by this time, you will probably be focused on upgrading to the latest version of your ERP system, but let’s put this unpleasant thought to one side for the purposes of this discussion.

But this begs another question, which Thomas covers more eloquently that I could. Plain vanilla ERP implementations, where you essentially adapt what your organisation does to the system’s standard functionality, mean that:

[…] employees who actually have to use the ERP system day in, day out will not only dislike the fact that you’re changing their technology interface, but now you’re going to allow the technology system to dictate to them how they should perform their job, with the new business processes.

However, even if we can suppress this second inconvenient truth about ERP, a further one arises – the area is indeed hydra-like. If the best practice for ERP implementations is to customise them as little as possible – shortening projects, reducing costs and simplifying upgrades – then why is there such a large price tag for all of the bells and whistles that it is impractical to actually use?

As Mr Wailgum says in closing:

But, perhaps, [CEOs and CFOs] have been making these decisions without knowing all the facts about the long-term costs associated with ERP systems, that the upfront “sticker price” is almost meaningless.

Which brings us right back to why CFOs and CEOs hate IT.

Starting in 1987 with CIO magazine, CIO’s portfolio of properties has grown to provide technology and business leaders with insight and analysis on information technology trends and a keen understanding of IT’s role in achieving business goals. The magazine and website have received more than 160 awards to date, including two Grand Neal Awards from the Jesse H. Neal National Business Journalism Awards and two National Magazine of the Year awards from the American Society of Publication Editors.

The scope of IT’s responsibility when businesses go bad

27 Apr 20093 Nov 2014 Peter James Thomas bi and the economic crisis, business, business analytics, business intelligence, change management, cultural transformation, it business alignment, technology bi, business analytics, business intelligence, credit crunch, economic crisis, information technology, it business alignment, it strategy, jim anderson, management information


		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