“Gartner sees a big discrepancy between BI expectations and realities” – Intelligent Enterprise

Doug Henschen
 
Doug Henschen at Intelligent Enterprise reports from the Gartner Business Intelligence Summit in Washington D.C., explaining that Gartner analysts John Van Decker and Kurt Schlegel cited five reasons why BI projects do not live up to expectations (article link here):
 

  1. No IT-Business Partnership – “We have to get away from thinking of it as a vendor-customer relationship,” said Schlegel.
  2. No Link to Corporate Strategy – BI team have to listen to the executives and develop metrics and measures that are aligned with their goals.
  3. No connection to the Process – “BI has been overtly disconnected for too long,” Schlegel proclaimed. It’s not enough to deliver the right information to the right users. You have to insert those insights into the processes and interfaces that business users live in every day.”
  4. No Governance or Too Much – It has to be just the right amount of governance. BI grew up departmentally, so it’s all too common to have many silos of BI. At the other extreme, some companies are so uptight about data standards that companies can’t get their data into the warehouse.
  5. No Skills – Business users often lack skills, chimed in Van Decker, citing the one area where the business side was said to be falling short. “Most companies have very sophisticated capabilities available that folks just aren’t taking advantage of,” he said, pointing to corporate performance management (CPM) software as a leading example.

 
I come close to the situation of words failing me when I read a list like this (though not close enough to prevent me penning an article of course). I appreciate that maybe a public seminar is not the easiest place to provide deep insights (I present a lot myself), but the commentary against each of the problem areas seems odd to me. I’m not sure that these are really the five reasons for BI continuing to disappoint in some organisations, while it continues to delight in others, but here are my thoughts on each headline.
 

  1. No IT-Business Partnership – We have to stop talking about IT and Business as if they were two parties trying to negotiate a cease-fire. IT is a business department, it carries out business projects. It would be ridiculous to say that there needs to be a Sales-Business Partnership, it should be equally so with IT. I expand on this theme in the very first article on this blog.
  2. No Link to Corporate Strategy – There should not be a link to Corporate Strategy, BI does not exist as a separate entity that requires linkage. Instead BI work should be an expression of Corporate Strategy (as should any IT project), what else is it an expression of? This is not about listening to executives (though that is important) it is about IT being part of the senior management team of an organisation and not some semi-detached entity, focussed only on the beauty of its own navel. I give some indication of how to go about ensuring that this is the case in two articles, one focussed on a European environment and one spanning four continents.
  3. No connection to the Process – I agree that embedding good BI in a coporoate culture requires effort (indeed I have written a series of articles on the subject, starting with this one), however I struggle to see how any BI team could fail to realise this and pay the area due attention. If this is truly a reason for failure, then it is because of a lack of basic project and change management skills in BI teams.
  4. No Governance or Too Much – I’m not sure that achieving the Goldilocks approach to Governance is the issue here. BI’s impact on an organisation is directly proportional to how pervasive it is. This means that silos of BI reduce value and the walls need to be knocked in. Does this have to be all in one go? of course not, there are always benefits in a balance between incremental progress and paradigm shifts. Any organisation who has gatekeepers who refuse access to the warehouse because of and overly rigid approach to data standards is going to have problems. Equally where systems are developed with little thought to the information that they provide and data is simply thrown over the wall to the BI team, this is going to destroy value. As ever, there needs to be a sensible balance struck, one that yields the greatest business benefit for the lowest cost.
  5. No Skills – “Business users often lack skills”, this seems both incredibly patronising (are only IT people smart enough to get it?) and also a poor excuse for BI teams not paying enough attention to education (see point 3. above). If business people truly lack the skills to use good BI, then they are probably unfit to be in business as the tools are pretty intuitive (if not over-engineered by an approach that is too technology-focussed). More likely, training has been poor, or the BI deliveries have failed to be tailored to answering questions that the business wants to ask.

 
In summary, I don’t have five reasons for BI failing to live up to expectations, I have one. I firmly believe that BI done well is both the easiest of IT systems to sell to people and has one of the highest paybacks of any IT initiative. BI done badly (at the design, development, implementation or follow-up stages) will fail.

The issue is basically a simple one: just how good is your BI team? If a BI implementation fails to deliver significant business value, then instead of looking for scape-goats, the BI team should purchase a mirror and start using it.
 


 
Continue reading about this area in: Some reasons why IT projects fail
 
 
Doug Henschen joined Intelligent Enterprise as Editor in 2004 and was named Editor-in-Chief in January 2007. He has specialized in covering the intersection of business intelligence, performance management, business process management and rules management technologies within enterprise applications and architectures. He previously served as Editor-in-Chief of Transform Magazine, which covered content management and business process management challenges.

I comment on another Intelligent Enterprise article, this one by Cindi Howson, here.
 

Trends in Business Intelligence

trends

This year, as in every year since the phrase “Business Intelligence” first came to prominence, there have been a rash of predictions about what will happen with the area in 2009. I have linked to and commented on some of these myself on this blog. This article is my take on the area. I should however explain that there is a twist. These are not the trends that I expect to see in 2009, just my thoughts on what ought to be trends in BI over the next few years. I cannot claim to have any prescience about whether they will come to pass, but I will be encouraged if they do.
 

  1. A more holistic approach to BI in organisations that have already invested
  2. Operational BI
  3. Consolidation of the number of BI platforms with organisations
  4. An increase in the prevalence of BI competency centres
  5. BI teams being jointly owned and managed by business divisions and IT
  6. Data from central warehouses being served to front-end applications
  7. BI data being used to automate some business decisions
  8. Further emphasis on predictive analytics
  9. BI having an increasing role in compliance and risk management
  10. Incorporation of external data into BI platforms
  11. Provision of BI to business partners and/or customers
  12. The most creative users of BI employing it to thrive, even in the current climate

 
1. A more holistic approach to BI in organisations that have already invested

Often BI solutions have started in a single area. Typically – given its direct link to better managing overall performance – this has been around analysing an organisation’s financial results, though implementations starting in the sales and even operational arenas are also not uncommon. BI systems tend to add more value as they bring in more information, particularly where a high-level phenomenon – e.g. a decrease in expenditure – can be attributed to lower level ones – e.g. greater repeat business (business acquisition being more expensive than repeat business in most industries), plus enhanced productivity, plus reduced staff turnover (resulting in lower recruitment and training costs). To do this, BI needs to widen its scope to take on new data sources and combine them in creative ways. Where BI platforms have already added value, there will be pressure from users to expand them to deliver even more utility and provide more sophisticated insights. This in turn will require BI practitioners to take a more holistic view of the area and to develop roadmaps explaining how new data sources will be brought on stream and what business value will result from this.
 
 
2. Operational BI

I think that there is a particular argument for BI to make a greater contribution in the area of operational management, particularly tying this to overall performance. Often BI implementations have focussed on the more stately world of monthly (or weekly) results and steered clear of the daily or hourly demands of operational information. The BI projects that I have seen in the Operational sphere have been more focussed at producing weekly status reports or year-to-date trend analyses. Related to BI platforms expanding to new areas, I see increasing demand for information about the internal effectiveness of an organisation; quickly identifying bottlenecks or areas of inefficiency and tracking efforts to address these. Supporting this type of reporting will often require BI practitioners to rethink their architectures which are often set up to refresh on longer timeframes. This may in turn require the warehouse to support multiple environments with different periodicities.
 
 
3. Consolidation of the number of BI platforms with organisations

It is all too common for organisations to have separate BI implementations. Maybe the ERP system comes with some shrink-wrapped cubes, as does the CRM system. Perhaps Finance have invested in some budget analysis tools and different business units have started dabbling in predictive modelling (see 8. below). Maybe certain power users or numerate departments have their own, much cherished databases. Clearly this approach is sub-optimal. If it was ever acceptable to have such an ad hoc approach to the area, the current economic climate means that there is no longer room for a multitude of platforms, each supported by their own ETL, servers, IT teams and (hopefully) training programmes. While transitional costs may make it impractical for some organisations to move to a single platform in the short term, the reductions in licensing, internal support, data centre and training costs that come from standardising BI tools are compelling. This is to say nothing about reducing the level of confusion in users faced with multiple reporting and analysis systems, each with their own terminology, vagaries of functionality and often un-reconciled to each other. Arguments about certain BI tools being best of breed for particular tasks were never wholly convincing, with the breadth of functionality offered by all of the major players today, any of them will be at least good enough for all but the most exacting of applications.
 
 
4. An increase in the prevalence of BI competency centres

If this is partly as a result of the previous three trends, it also has some drivers all of its own. Even in multinational organisations with highly devolved structures and local accountability, most of the management information that is needed to run businesses will be relatively consistent from country to country and business unit to business unit. Perhaps the sources will vary, but the business transactions that they support are surprisingly consistent. Many organisations are waking up to this fact and pulling BI provision into the centre. There are obvious benefits to this in terms of cost savings, not reinventing the wheel, increasing the consistency of reporting and enabling corporate roll-ups. However, my own feeling is that the best organisations will supplement a strong central resource with a (probably much smaller) virtual component located close to business needs who can better respond to these in a timely manner, but within an overall information architecture. This hybrid approach offers the best of both worlds.
 
 
5. BI teams being jointly owned and managed by business divisions and IT

It is an oft-repeated aphorism that all IT projects are business projects. While clearly true in theory, there are enough counterexamples to suggest that practise is rather different. However, BI projects have often stayed much closer to this maxim than other IT efforts. This is because BI systems serve no purpose unless they are closely entwined with business goals. Natural selection should weed out any non-business-focussed BI projects eventually; even in the sleepiest of organisations. It is likely that this close relationship will deepen. Whilst many aspects of BI are firmly in the IT arena (managing the regular refresh of multiple terabytes of data effectively clearly being one), I see a joint stewardship of the area developing. By this I mean something deeper than business oversight or steering committees. It is also different to business BI liaison managers being appointed – these roles often have the unintended consequence of isolating IT from its customers. What I see emerging in more enlightened organisations is true co-ownership of BI with business and IT management closely collaborating to run the area.
 
 
6. Data from central warehouses being served to front-end applications

Of course it is not uncommon for transaction processing systems to have buttons or links that call up a given report. What I am talking about here is a closer coupling, one that does not require users to leave their current system and where information from the warehouse is presented in a seamless manner to users. While such information will have all the BI benefits of being reconciled, consistent and accurate, its provenance will increasingly become invisible to the user (who shouldn’t really have to worry where figures come from so long as they are accurate). This is an area in which web-services have some real potential to leverage the investments that organisations have made in warehouses.
 
 
7. BI data being used to automate some business decisions

Stepping a little further along the path from the previous point, even before users of front-end systems have a need to review information about a transaction, it may well be that the information itself has been what determines whether a human is involved or not. Already some organisations perform triage on business transactions. Ones that meet all of a number of requirements get processed automatically. Ones that meet some of them, but not all, may get routed to junior staff, whose role is to determine whether they require further review or can proceed. Finally, those with a major variance to requirements may get sent straight to more senior staff. This approach means that a larger volume of business can be handled and that expensive senior resource is only applied where it is necessary. Of course a prerequisite to this type of approach is having reliable information on which to perform the triage.
 
 
8. Further emphasis on predictive analytics

While the best BI implementations encourage users to extrapolate from past figures to estimate future ones, the degree to which the analytical skills of the user plays a part varies from implementation to implementation. Here by analytics I mean the use of larger data sets to identify trends or exceptions, mostly at a portfolio level. Again, having invested in developing data warehouses, it makes sense to utilise the many and sophisticated tools that are available to carry out advanced statistical analysis on these; the aim being to deduce trends that would be beyond even the most skilled of human analysts. A by-product of successful BI implementations is that they often free the more numerate of people in organisations from the burden of repetitive number crunching and allow them to focus on more added-value work such as this.
 
 
9. BI having an increasing role in compliance and risk management

Sometimes BI projects may have had their genesis in these areas. However, even when this is not the case a pleasing result of having consolidated much of the organisation’s data in one place is that this then forms a valuable resource for compliance and risk management. Indeed, taking an external perspective, regulators tend to view the existence of an enterprise data warehouse as a sign that an organisation takes managing its risks seriously. Although business managers and risk managers may have slightly different (though hopefully complementary) perspectives and want to answer different types of questions, the data that they need to do this is not that dissimilar. Producing compliance suites from a well-designed warehouse is probably not one of the more taxing BI problems. Again expansion in this area is a further example of point 1. in action.
 
 
10. Incorporation of external data into BI platforms

I have spoken above about the remit of BI systems expanding internally and becoming more consistent geographically. A further trend in expansion is to meld internal information with that from external providers. The type of external information would range from industry to industry, but might include market data, information about specific companies or individuals (e.g. credit scores, where the use of these is admissible). For example, in insurance, where I have spent the last twelve years of my career, incorporating information from externally produced flood, or windstorm models is often a priority.
 
 
11. Provision of BI to business partners and/or customers

Sometimes one objective of BI implementations is to better understand the relationships with business partners and customers. I have seen this develop to the degree where output from BI systems is mailed to such counterparties. A logical extension of this is to allow such organisations direct access to “their information”. Of course as with any e-commerce initiative, there would have be to strict controls on what is viewed and who can view it, but these are problems that are regularly addressed in other areas of IT and the tools to do this are readily available.
 
 
12. The most creative users of BI employing it to thrive, even in the current climate

There have been many articles (including ones written by me) which have spoken about good BI being a great defence in times of economic stress. I would go beyond this and state that the real BI pioneers will take advantage of these capabilities to capture markets from their less well-informed competitors and to steer a course away from areas of business that may bring other less-foresighted organisations down. I look forward to seeing case studies bearing this out appear over the next few years.
 

“Businesses Are Still Crazy for BI After All These Years” – CIO.com

Thomas Wailgum at CIO.com

Thomas Wailgum has written an article at CIO.com in which he talks about continuing demand for BI, but adds that this, in turn, suggests that in many organisations BI has yet to deliver on its promise. As Thomas puts it:

“I see pent-up enterprise-wide frustration, aimed squarely at IT and CIOs for failing to give the business what it needs and deserves”

He sees the fundamental problem as being fragmented systems and stand-alone BI applications. This sounds like challenges that I have faced before. I agree that BI only realises it potential when a more strategic and wide-ranging approach is taken. Something I refer to in many places on this blog, but possibly most directly in Holistic vs Incremental approaches to BI.

My basic point is that while it is sensible to take a pragmatic, incremental approach to implementing BI (collecting successes as you go and building momentum), this needs to be within the framework of a more encompassing vision for what the eventual BI system will be like and do.

I don’t believe that you can do BI by halves and remain somewhat sceptical about the claims of some of the newer BI products to do away with the necessary hard work.
 

“All that glisters is not gold” – some thoughts on dashboards

Fool's gold

Yesterday I was tweeting quotes from Poe and blogging lines attributed to Heraclitus. Today I’m moving on to Shakespeare. Kudos to anyone posting a comment pointing out the second quote that appears later in the text.
 
 
Introduction

Dashboards are all the rage at present. The basic idea is that they provide a way to quickly see what is happening, without getting lost in a sea of numbers. There are lots of different technologies out there that can help with dashboards. These range from parts of the product suites of all the main BI vendors, through boutique products dedicated to the area, all the way to simply using Java to write your own.

A lot of effort needs to go into how a dashboard is presented. The information really does need to leap off the screen, it is important that it looks professional. People are used to seeing well-designed sites on the web and if your corporate dashboard looks like it is only one step removed from Excel charts, you may have a problem. While engaging a design firm to help craft a dashboard might be overkill, it helps to get some graphic design input. I have been lucky enough over the years to have had people on my teams with experience in this area. They have mostly been hobbyists, but they had enough flair and enough of an aesthetic taste to make a difference.

However, echoing my comments on BI tools in general, I think an attractive looking dashboard is really only the icing on the cake. The cake itself has two main other ingredients:

  1. The actual figures that it presents (and how well they have been chosen) and
  2. The Information Architecture that underpins them

I’ll now consider the importance of these two areas.
 
 
Choosing the KPIs

Filtering out the KPIs

The acronym KPI is bandied about with enormous vigour in the BI community. Sometimes what the ‘K’ stands for can get a bit lost in the cacophony. Stepping back from dashboards for a few minutes, I want to focus on the measures that you have in your general business intelligence applications such as analysis cubes. Things like: sales revenue, units sold, growth, head count, profit and so on.

[Note: If you don’t like BI buzzwords, please feel free to read “figures”, or “numbers” where ever you see “measures”. I may attempt to provide my own definitions of some of these terms in the future as the Wikipedia entries aren’t always that illuminating.]

When you have built a Data Mart for a particular subject area and are looking to develop one or more cubes based on this, you may well have a myriad of measures to select from. In some of the earliest prototype cubes that my teams built, we made the mistake of having too many measures. The same observation equally applied to the number of dimensions (things that you want to slice and dice the measures by, e.g. geography, line of business, product, customer etc.). Having too many measures and dimensions led to a cube that was cumbersome, difficult to navigate and where the business purpose was less that crystal clear. These are all cardinal sins, but the last is the worst as I have referred to elsewhere. The clear objective is to cut down on both the figures and the business attributes that you want to look at them by. We set a rule (which we did break a couple of times for specialist applications) of generally having no more than ten measures and ten dimensions in a cube and ideally having less.

Well this all sounds great, the problem – and the reason for this diversion away from dashboards – is which measures do you keep and which do you drop. Here there is no real alternative to lots of discussions with business partners, building multiple prototypes to test out different combinations and, ultimately, accepting that you might make some mis-steps in your first release and need to revisit the area after it has been “shaken down” by real business use. I won’t delve into this particular process any deeper now. Suffice it to say that choosing which measures to include in a cube it is both an area that is important to get right and one in which it is all to easy to make mistakes.

So, retuning to our main discussion, if picking measures at the level of an analysis cube is hard, just how hard is it to pick KPIs for a dashboard. I recall a conversation with the CEO of a large organisation in which he basically told me to just pick the six most important figure and put them on a dashboard (with the clear implication that sooner would be rather better than later). After I had explained that the view of the CEO in this area was of paramount importance and that his input on which figures to use would be very valuable, we began to talk about what should be in and what should be out. After a period of going round in circles, I at least managed to convey the fact that this was not a trivial decision.

What you want with the KPIs on a dashboard is that they are genuinely key and that you can actually tell something from graphing them. The exercise in determining which figures to use and how to present them was a lengthy one, but very worthwhile. You need to rigorously apply the “so what?” test – what action will people take based on the trends and indicators that are presented to them. In the end we went for simplicity, with a focus on growth.

There was a map showing how each country was doing against plan; colour-coded red, amber and green according to their results. There were graphs comparing revenue to budget by month and the cumulative position and there was a break-down by business unit. The only to elements of interaction were to filter for a region or country and a business unit or line of business. Any further analysis required pulling up an underlying cube (actually we integrated the cube with the dashboard so that context was maintained moving from one to the other – this was not so easy as the dashboard and cube tools, while from the same vendor, were on two different major release numbers).

There were many iterations of the dashboard, but the one we eventually went live with received general acclaim. I’m not sure what we could have done differently to shorten the process.
 
 
Where does the data come from?

A dashboard without an underlying Information Architecture
A dashboard without an underlying Information Architecture

The same range of dashboard tools that I mention in the introduction are of course mostly capable of sourcing their data from pretty much anywhere. If the goal is to build a dashboard, then maybe it is tempting to do this as quickly as possible, based on whatever data sources are to hand (as in the diagram above). This is probably the quickest way to produce a dashboard, but it is unlikely to produce something that is used much, tells people anything useful, or adds any value. Why do I say this?

Well the problem with this approach is that all you are doing is reflecting what is likely to be a somewhat fragmented (and maybe even chaotic) set of information tools. Out of your sources, is there a unique place to go to get a definitive value for measure A? Do the various different sources hold data in the same way and calculate values using the same formulae? Do sources overlap (either duplicating data, or function), if so, which ones do you use? Do different sources get refreshed with the same frequency and do they treat currency the same way? Are customers and products defined consistently everywhere?

A dashboad underpinned by a proper Information Architecture
A dashboad underpinned by a proper Information Architecture

Leaving issues like these unresolved is a sure way to perpetuate a poor state of information. They are best addressed by establishing a wider information architecture (a simplified diagram of which appears above). I am not going to go into all of the benefits of such an approach, if readers would like more information, then please browse through the rest of this blog and the links to other resources that it contains (maybe this post would be a good place to start). What I will state is that a dashboard will only add value if it is part of an overall consistent approach to information, something that best practice indicates requires an Information Architecture. Anything else is simply going to be a pretty picture, signifying nothing.
 
 
Summary

So my advice to those seeking to build their first dashboard has three parts. First of all, keep it simple and identify a small group of measures and dimensions, which are highly pertinent to the core of the business and susceptible to graphical presentation. Second, dashboards are not a short-cut to management information Nirvana, they only really work when they are the final layer in a proper approach to information that spans all areas of the organisation. Finally, and partly driven by the first two observations, if you are in charge of building a dashboard, make sure that the plans you draw up reflect the complexity of the task and that you manage expectations accordingly.
 

The confluence of BI and change management

y =x^3 + 2x^2 - x + 1

The tag-line of this blog brings together business intelligence and cultural transformation. While one driver for this is that I have led BI projects that had explicit goals of cultural transformation, I think that there is a deeper connection to be explored here.

In other articles (notably “Can You Really Manage What You Measure?” by Neil Raden and Actionable Information), I discuss my experience that BI only adds value if:

  1. The information it provides answers pertinent business questions, and
  2. The answers to these questions lead to people taking action.

This means that any successful BI implementation has to consider such messy and difficult things as changing how people behave. This is where the link with change management arises.

Now of course you can argue that change management is an indispensible discipline for any business project (my strong opinion is that any IT project is a type of business project) and this is clearly true. However the parameters within which a new transaction processing system has to operate are different. Here if a person does not use the system, then work does not get done. Either it is impossible to carry out your job without the system (maybe only the system generates the necessary documentation), or not using the system to record transactions is a breech in compliance (keeping paper copies in your drawer).

BI systems are not like this. People chose to use them because they judge that they either make their business life easier, or they help to improve their decision-making (hopefully both). If someone doesn’t want to use a BI system, then they won’t and can probably get on with other parts of their job. The reason that change management is even more important in BI projects is that the element of compliance (or even coercion) is absent. If you want people to use the system and behave differently as a result, then you need to think about how best to influence them in these directions.

I have written elsewhere about the importance of marketing, education and follow-up in these areas. It also is important to explicitly recognise that a BI practitioner needs to be fully engaged in change management if they are to be successful.

A final thought also worth considering is that, as the BI industry matures and focus turns more to making it work in a business context than the latest flashy dashboard technology, it is likely that one of the things that will differentiate the best users of BI is how well they manage the necessary and desirable change that it drives.

πυρὸς θάνατος ἀέρι γένεσις, καὶ ἀέρος θάνατος ὕδατι γένεσις

 

A list of potential DW/BI pitfalls – by someone who has clearly been there

pitfall

Browsing through my WordPress Tag Surfer today (a really nice feature by the way), I came across an interesting list of problems that can occur in a data warehousing / business intelligence project, together with suggestions for managing these. A link appears below:

Eight Reasons why Data Warehouse and, subsequently, Business Intelligence efforts fail

The author, Raphael Klebanov, has clearly lived the data warehousing process and a lot of what he says chimes closely with my own experience.

Some of his themes around business engagement, the alignment of BI delivery with business needs and the importance of education are echoed throughout my own writing. This article is definitely worth a read in my opinion.
 


 
Yes I know the illustraion ages me.
 

A common-sense approach to BI from Information Management

information-management

I am not sure whether it is the economic crisis focusing minds, or if there has been a turning point in the maturity of BI, but there seem to have been quite a few common-sense articles about the area recently. One I have just read is by Fei Luo at Information Management. The article may be read here.

Much of what Fei has to say chimes with my own experience of successfully driving change using BI in organisations. In particular, the observations about business involvement, having a strategy, regular business communication and the importance of training are all well-made. I would go even further saying that good BI projects must have a proper business / IT partnership at their centre; one that goes beyond business involvement and becomes business commitment.

My further thoughts about some of the themes raised by Fei Luo’s article can be viewed in the following blog posts:

Business involvement:
Having a strategy:
Business communication:
The importance of training:

I was pleased to see these areas being drawn together in a single, cogent article.
 


 
Fei Luo is vice president of information services at City National Bank, a public bank headquartered in California. Fei Luo can be reached at Fei.Luo@cnb.com.
 

Ed Sperling highlights the importance of the CIO understanding the business

forbes-sperlin

I was interested to read an article by Ed Sperling at Forbes.com. In this Ed states that:

In order to understand the flow of information, CIOs need to be intimately familiar with the direction of the business. This way, they can automate pieces of that business where it will do the most good. That can’t be done without a good understanding of how information moves through an organization, and the movement of information can’t be fully understood without understanding the business units.

It will come as no surprise to anyone who has read my earlier article about spurious distinctions between business and IT (Business is from Mars and IT is from Venus) that I strongly endorse this sentiment. Maybe the fact that mainstream commentators are talking about IT in business terms is indicative of IT beginning to come of age.
 


 
Ed Sperling is editor in chief of System-Level Design; and a contributing writer at Forbes.com.
 

Developing an international BI strategy

linkedin Business Intelligence Professionals

Introduction

I am again indebted to a question raised on the LinkedIn.com Business Intelligence Professionals group for this article. The specific thread may be viewed here and the question was the beguilingly simple “How to understand BI requirements in an organisation?”
 
 
Background

The span of my International responsibilities
The span of my international responsibilities

I have previously written about some aspects of successfully achieving this in a European environment, but thought that it would be interesting to add my thoughts about doing the same thing more recently on a wider international scale.

[A note here, in common with many US-based companies, “international” means all non-US markets; in my case: Asia Pacific, Europe, Canada and Latin America. By way of contrast “global” means international plus the US domestic market, i.e. all operations.]

By way of providing some context, in previous years I had successfully built and deployed an Information Architecture for the European operations of a multinational Insurance organisation and extended components of this to our Latin American subsidiaries. I had also deployed the same corporation’s financial system to its Asia Pacific business. My track-record in adding value through BI and my exposure to two major projects in the international arena led to me being asked to build on the European technology assets to develop a management information strategy for the four international regions. This article is about how I succeeded in doing this.

Consistent with the general approach that I laid out in an earlier article, my two first objectives were to understand the needs of the various business groups across the four international regions and to form a high-level picture of the IT architecture in these areas. Although I pursued these twin goals in tandem, it was the business piece that I placed most emphasis on initially. It is this area that I will have most to say about here.
 
 
Understanding the business

The way that I approached my goal of learning about the international business was not novel in any aspect except possibly its scale. As you would expect, I did it by speaking to business managers from different countries and business units in each of Asia Pacific, Canada, Europe (I revisited the European requirements to make sure I was not neglecting these), Latin America and people with international or global responsibilities.

The countries whose MI requirements I had to establish
The countries whose MI requirements I had to establish

Some of these interviews were face-to-face, but – given the geographic spread of my correspondents – the bulk of them were over the ‘phone. The many time-zones involved provided another challenge. I am based in the UK and it was not atypical to be on the ‘phone talking to Australia or Singapore at 6am my time; pick up on some European meetings during the morning; talk to Canada, Latin America and the US parent during the afternoon and evening; and be back on the ‘phone to Australia at midnight. There were a lot of these 14-hour plus days!

One thing that I was surprised by in the process was how well it worked being on the ‘phone. Although I sometimes find it a lot easier to be speaking in person, being able to pick up on visual cues and so one, using the telephone both allowed me to listen vary carefully to what was being said and to take detailed notes; it is tough taking detailed notes while maintaining eye-contact of course. I structured the interviews to explore the following areas:

  1. An overview of the manager’s markets, products, structure, strategy, growth areas and any pressing business challenges
  2. Their thoughts on the general IT infrastructure available to them; looking beyond what some people might view as the world of management information
  3. The extent and quality of their current MI, including local and corporate reporting systems and even any Access databases and spread-sheets; here I placed particular emphasis on any major gaps
  4. What their vision was for improved MI facilities; an ideal state for MI if you will

This proved to be a successful approach and I learnt a remarkable amount about the differences between countries and markets. I normally allowed 30 minutes for these calls, suggesting in my introductory e-mail that if people were pressed for time, 15 might suffice. No call was ever less than half-an-hour long, most of them expanded to be an hour or more, such was the interest generated by my line of questioning.
 
 
The scale of the work

I had initially targeted speaking to around 40-50 managers, but quickly came to realise that – given the diversity of the organisation’s operations – I would need to talk to more people to get an accurate picture. As things worked out, I ended up interviewing precisely 100 managers. I started to try to describe the range of people that I talked to and quickly came to the conclusion that a picture paints a thousand words. The following exhibit provides a breakdown by geographic span of responsibility and area of the business:

The distribution of managers that I interviewed
The distribution of managers that I interviewed

The paper covering their detailed feedback from this exercise expanded to over 400 pages; each line of which was reviewed, sometimes amended, and signed-off by the people interviewed. Such a sign-off process certainly increases the duration of the work, but it is indispensable in my opinion. If you are inaccurate or incomplete in your understanding of the business, then you are building on foundations of sand. Of course, as well as using this exhaustive process to document business requirements, it was also a great opportunity to begin to establish relationships and also to gently start the process of marketing some of my ideas about MI.

It is clearly inappropriate for me to share my detailed findings about the business issues that the organisation was dealing with, however I will make one observation, which I think is probably replicated in many companies. When I spoke to managers at different levels within the organisation, they all cited similar strategies, challenges and priorities. This fact was testament to good communication between different tiers, however widely separated by geography, and also to a shared sense of purpose. What was however notable was that people at different levels gave varying emphasis to the issues. If a global leader prioritised areas as 1-2-3-4, it was not unusual that a manager at the country level instead ranked the same areas as 1-4-3-2. Perhaps this is not so surprising.
 
 
Understanding the systems

In parallel I also worked with the CIOs of each region and with members of their departments to understand the systems that different business units used and how they were interrelated. In doing this, it was helpful to already have the business perspective on these systems and I was able to provide general feedback about IT in each territory which was valuable to my colleagues. In this type of work (as indeed can be the case when thinking about different markets and products from the business perspective) it is sometimes easy to be overwhelmed by the differences. Instead, I made myself focus on teasing out the similarities. There ended up being many more of these that I had anticipated. In this work I relied to a great extent on my experience of consolidating data from three different underwriting systems (plus many other back-end systems) as part of my previous work in Europe.
 
 
Forming and validating a strategy

With this substantial background in both the business needs and the IT landscape, I was able to develop a management information strategy that focused on what was held in common across business units and departments, whilst still recognising the need to meet certain market-specific requirements. The lengthy hours of research that I had put in proved to be worthwhile when I presented my ideas back to many of the same group that I had interviewed and received their backing and approval.
 
 
Some final thoughts

While it was undeniably interesting and even fun to learn so much about the diverse operations of a large international organisation, the process was undeniably lengthy sometimes even arduous. It took six months from conception of the project to delivering detailed findings, recommendations and plans to the international senior management team (of course I also presented interim findings and draft recommendations several times over this period).

It remains my firm belief that this type of exercise is mandatory if you are really serious about adding value with BI. I can see no way to short-cut the process without substantially compromising on your deliverables and the value that they are intended to unlock. If you do not understand the business and its needs, it is nigh on impossible to deliver the information that they require to take decisions. In some areas of life, you just have to put in the hard work. Establishing the requirements for BI in a large international organisation is certainly one of these areas.
 

Cindi Howson at Intelligent Enterprise on using BI to beat the downturn

cindi-howson-w250

Another interesting article, this time by Cindi Howson at Intelligent Enterprise. In this Cindi speaks about Four Business Intelligence Resolutions for 2009:

  1. Using BI to beat the downturn
  2. Developing a BI Strategy and Standardising
  3. Training Users, and
  4. Investing in yourself

I found some interesting parallels between Cindi’s thinking and my own. For item one, see the “BI and the Economic Crisis” category. For item two Holistic vs Incremental approaches to BI is possibly pertinent. Finally, I echo some of Cindi’s themes from item three in Education and cultural transformation.
 


 
Cindi Howson is the founder of BIScorecard, a Web site for in-depth BI product reviews. She has been using, implementing and evaluating business intelligence tools for more than 15 years. She is the author of Successful Business Intelligence: Secrets to Making BI a Killer App and Business Objects XI R2: The Complete Reference. She teaches for The Data Warehousing Institute (TDWI) and is a frequent speaker at industry events.