The Dictatorship of the Analysts

14 April 2009

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.
 

tweet this Tweet this article on twitter.com
Bookmark this article with:
Technorati | del.icio.us | digg | Reddit | NewsVine

 


A review of “The History of Business Intelligence” by Nic Smith

30 March 2009

Introduction

I had been aware of a short film about the history of Business Intelligence flitting its way around the Twitterverse, but had not made the time to take a look myself. That changed when the author, Nic Smith from Microsoft BI Solutions Marketing, contacted me asking my opinion about it.
 
 

 
 
Back in the day I was a regular Internet Movie Database reviewer, coming out of “retirement” recently to post some thoughts about Indiana Jones and the Kingdom of the Crystal Skull (see also A more appropriate metaphor for business intelligence projects). More recently, I have reviewed rock climbing DVDs, filmed rock-climbing shorts with my partner and have even written a piece aiming to apply Hollywood techniques to Marketing Change. Given this background, I thought that I would treat Nic’s work as art and review it accordingly. This article is the result.
 
 
The review

Nic’s film is epic in scope, his aim is to cover the entire sweep of not just business intelligence, but data and business systems as well. It is amazing that he manages to fit this War and Peace-like task into only 10 minutes 36 seconds. However lest the reader expects Bergman-esque earnestness, it is worth pointing out that the mood is enlivened by the type of pop-culture references that are likely to appeal to a 40-something geek like your reviewer.

I’ll try to avoid giving too much of the plot away, however Nic’s initial aim is to answer the following four questions about BI:

  1. Where have we been?
  2. Where are we now?
  3. Where are we going? and
  4. Why should you care?

 
 


  It is recommended that anyone wishing to avoid spoilers clicks here now!  


 
 
Having failed to get a satisfactory definition of BI from Wikipedia (I trod the same path looking for a definition of IT-Business Alignment in the presentation appearing here), the director embarks on a personal quest to find the answer himself. Along the way, he comes to the realisation that BI is about decisions and that people take these decisions. In trying to explore this area further, Nic takes a journey from the advent of databases in the late 1960s; through the creation of the business systems to populate them, and the silo-based reports they generated, in the 1970s; to the arrival of the data warehouse in the 1980s – a stage he tags BI 1.0.

As the profile and importance of BI increased during the 1990s and the amount of data, both structured and unstructured, increased exponentially – notably with the growth of the web – the number and type of BI tools also proliferated. Because of the variety of tools, their complexity and cost, the market then consolidated, with many of the BI tools finding new homes in the same organisations that had previously brought you business systems. The resulting menu of broad-based and functional BI platforms is Nic’s definition of BI 2.0.

Nevertheless, the director felt that there was still something not quite right in the world of BI; namely the single version of the truth was about as likely to be pinned down as a Snark. The problem in his mind was that people were still left out of the equation (Nic likes equations and includes lots of them in his film). This realisation in turn leads to the denouement in which Nic brings together all of the threads of his previous detective work to state that “BI is about providing the right data at the right time to the right people so that they can take the right decisions” (a definition I wholeheartedly endorse).

The film ends with a cliffhanger, presaging a new approach to BI that will enable collaboration and drive innovation. I suspect the resolution to this punctuated narrative will soon be playing at all good Microsoft multiplexes along with the other summer blockbusters.
 


 
Nic Smith joined the Microsoft team in December of 2006, bringing a deep knowledge base of the Business Intelligence space. Prior to joining Microsoft, Nic spent time with Business Objects, a pure play BI company, where he was responsible for the vision of BI and performance management. Nic also spent time with former BI company Crystal Decisions, where he helped bring an enterprise reporting BI platform to market. Nic brings a unique blend of market knowledge, brand development and a solution orientated focus as an evangelist for BI. In addition to his business initiatives, Nic is involved in elite athletic development for youth. He holds a Bachelors Degree in Marketing and Communications from Simon Fraser University in Vancouver, British Columbia.
 

tweet this Tweet this article on twitter.com
Bookmark this article with:
Technorati | del.icio.us | digg | Reddit | NewsVine

 


Neil Raden’s thoughts on Business Analytics vs Business Intelligence

30 March 2009

neil-raden

Industry luminary Neil Raden, founder of Hired Brains, has weighed into the ongoing debate about Business Analytics vs Business Intelligence on his Intelligent Enterprise blog. The discussions were spawned by comments made by Jim Davis, Chief Marketing Officer of SAS, at a the recent SAS Global Forum. Neil was in the audience when Jim spoke and both his initial reaction and considered thoughts are worth reading.

Neil’s blog article is titled From ‘BI’ to ‘Business Analytics,’ It’s All Fluff.
 


 
Neil Raden is an “industry influencer” – followed by technology providers, consultants and even industry analysts. His skill at devising information assets and decision services from mountains of data is the result of thirty years of intensive work. He is the founder of Hired Brains, a provider of consulting and implementation services in business intelligence and analytics to many Global 2000 companies. He began his career as a casualty actuary with AIG in New York before moving into predictive modeling services, software engineering and consulting, with experience in delivering environments for decision making in fields as diverse as health care to nuclear waste management to cosmetics marketing and many others in between. He is the co-author of the book Smart (Enough) Systems and is widely published in magazines and online media. He can be reached at nraden@hiredbrains.com.

I also have featured an earlier piece that Neil wrote for BeyeNETWORK in “Can You Really Manage What You Measure?” by Neil Raden. You can find Neil’s thoughts on a wide range of technology issues in many places on the web and they are always recommended reading. 

Other Intelligent Enterprise articles referenced on this blog may be viewed here.
 

tweet this Tweet this article on twitter.com
Bookmark this article with:
Technorati | del.icio.us | digg | Reddit | NewsVine

 


Business Analytics vs Business Intelligence

28 March 2009
  “Business intelligence is an over-used term that has had its day, and business analytics is now the differentiator that will allow customers to better forecast the future especially in this current economic climate.”  
  Jim Davis  
  SVP and Chief Marketing Officer, SAS Institute Inc.  

The above quote is courtesy of an article reported on Network World, the full piece may be viewed here.

Analytics vs Intelligence

In the same article, Mr Davis went on to add:

I don’t believe [BI is] where the future is, the future is in business analytics. Classic business intelligence questions, support reactive decision-making that doesn’t work in this economy because it can only provide historical information that can’t drive organizations forward. Business intelligence doesn’t make a difference to the top or bottom line, and is merely a productivity tool like e-mail.

The first thing to state is that the comments of this SVP put me more in mind of AVP, should we be anticipating a fight to the death between two remorseless and implacably adversarial foes? Maybe a little analysis of these comments about analytics is required. Let’s start with SAS Institute Inc. who describe themseleves thus on their web-site [with my emphasis]:

SAS is the leader in business analytics software and services, and the largest independent vendor in the business intelligence market.

It is also worth noting that the HTML title of sas.com is [again with my emphasis]:

SAS | Business Intelligence Software and Predictive Analytics

Is SAS’s CMO presaging a withdrawal from the BI market, or simply trashing part of the company’s business, it is hard to tell. But what are the differences between Business Intelligence and Business Analytics and are the two alternative approaches, or merely different facets of essentially the same thing?

To start with, let’s see what the font of all knowledge has to say about the subject:

Business Intelligence (BI) refers to skills, technologies, applications and practices used to help a business acquire a better understanding of its commercial context. Business intelligence may also refer to the collected information itself.

BI applications provide historical, current, and predictive views of business operations. Common functions of business intelligence applications are reporting, OLAP, analytics, data mining, business performance management, benchmarks, text mining, and predictive analytics.

http://en.wikipedia.org/wiki/Business_intelligence

and also:

Business Analytics is how organizations gather and interpret data in order to make better business decisions and to optimize business processes. [...]

Analytics are defined as the extensive use of data, statistical and quantitative analysis, explanatory and predictive modeling, and fact-based decision-making. [...] In businesses, analytics (alongside data access and reporting) represents a subset of business intelligence (BI).

http://en.wikipedia.org/wiki/Business_analytics

Rather amazingly for WikiPedia, I seem to have found two articles that are consistent with each other. Both state that business analytics is a subset of the wider area of business intelligence. Of course we are not in the scientific realm here (and WikiPedia is not a peer-reviewed journal) and the taxonomy of technologies and business tools is not set by some supranational body.

I tend to agree with the statement that business analytics is part of business intelligence, but it’s not an opinion that I hold religiously. If the reader feels that they are separate disciplines, I’m unlikely to argue vociferously with them. However if someone makes a wholly inane statement such as BI “can only provide historical information that can’t drive organizations forward”, then I may be a little more forthcoming.

Let’s employ the tried and test approach of reductio ad absurdum by initially accepting the statement:

  Business intelligence is valueless as it is only ever backward-looking because it relies upon historical information  

Where does a logical line of reasoning take us? Well what type of information does business analytics rely upon to work its magic? Presumably the answer is historical information, because unless you believe in fortune-telling, there really is no other kind of information. In the first assertion, we have that the reason for BI being valueless is its reliance on historical information. Therefore any other technology or approach that also relies upon historical information (the only kind of information as we have agreed) must be similarly compromised. We therefore arrive at a new conclusion:

  Business analytics is valueless as it is only ever backward-looking because it relies upon historical information  

Now presumably this is not the point that Mr Davis was trying to make. It is safe to say that he would probably disagree with this conclusion. Therefore his original statement must be false: Q.E.D.

Maybe the marketing terms business intelligence and business analytics (together with Enterprise Performance Management, Executive Information Systems and Decision Support Systems) should be consigned to the scrap heap and replaced by the simpler Management Information.

All areas of the somewhat splintered discipline that I work in use the past to influence the future, be that via predictive modelling or looking at whether last week’s sales figures are up or down. Pigeon-holing one element or another as backward-looking and another as forward-looking doesn’t even make much marketing sense, let alone being a tenable intellectual position to take. I think it is not unreasonable to expect more cogent commentary from the people at SAS than Mr Davis’ recent statements.
 

 
Continue reading about this area in: A business intelligence parable and The Apologists.
 

tweet this Tweet this article on twitter.com
Bookmark this article with:
Technorati | del.icio.us | digg | Reddit | NewsVine

 


The specific benefits of business intelligence in Insurance

24 March 2009

Introduction

Insurance

Insurance – specifically Property Casualty Insurance – is the industry that I have worked within for the last twelve years. During this time, I managed teams spanning IT, Finance and Operations. However the successes that I am most proud of have been in the related fields of Business Intelligence and Cultural Transformation that appear in the title of this blog.

I have described various aspects of this work elsewhere, for example in The EMIR Project and my collection of articles on Cultural Transformation. I have also written about the general benefits of good Business Intelligence for any organisation. This article focuses on the business benefits of BI that are specific to the Insurance industry.
 
 
Of pigs and men

  Insure /insho′or/ v.tr. 1 secure the payment of a sum of money in the event of loss or damage to property, life a person etc. (O.E.D.)  

Insurance is all about risk; evaluating risk, transferring risk, reducing risk. The essentials of the industry can be appreciated via a rather colourful fable provided in Success in Insurance (S.R. Diacon and R.L. Carter). This tale was originally told by someone at The Association of British Insurers:

Once upon a time there were 11 men; each of them owned a pig.

Unexpectedly one of the pigs died. The owner could not afford £90 for a new pig and so he had to leave the country and go to work in the town instead. The remaining 10 men went to see a wise man. ‘It could happen to any of us,’ they said. ‘What can we do?’

‘Could you each afford £10 for a new pig if your pig died?’ asked the wise man. They all agreed that they could manage that. ‘Very well,’ said the wise man. ‘If you each give me £10, I’ll buy you a pig if yours dies this year.’ They all agreed.

That year one pig did die. The price of pigs had gone up to £95 by now, but the wise man replaced the pig, so none of the men suffered and the wise man had £5 left for the trouble and risk he had taken.

 
 
Pricing Insurance products

Pricing

Of course in the above example, there were two crucial factors for the wise man. First the outcome that only one pig actually died; if instead there had been two pig-related fatalities, the perhaps less-wise man would have been out-of-pocket by £90. Second, the related issue of him setting the price of the pig Insurance policy at £10; if it had been set at £9 he would again have suffered a loss. It is clear that it takes a wise man to make accurate predictions about future events and charge accordingly. In essence this is one thing that makes Insurance different to many other areas of business.

If you work in manufacturing, your job will of course have many challenges, but determining how much it costs to make one of your products should not be one of them. The constituent costs are mostly known and relatively easy to add up. They might include things such as: raw materials and parts; factory space and machinery; energy; staff salaries and benefits; marketing and advertising; and distribution. Knowing these amounts, it should be possible to price a product in such a way that revenue from sales normally exceeds costs of production.

In Insurance a very large part of the cost of production is, by definition, not known at the point at which prices are set. This is the amount that will eventually be paid out in claims; how many new pigs will need to be bought in the example above. If you consider areas such as asbestosis, it can immediately be seen that the cost of Insurance policies may be spread over many years or even decades. The only way to predict the eventual costs of an Insurance product with any degree of confidence, and thereby set its price, is to rely upon historical information to make informed predictions about future claims activity.

By itself, this aspect of Insurance places enormous emphasis on the availability of quality information to drive decisions, but there are other aspects of Insurance that reinforce this basic need.
 
 
Distribution strategy

Insurance Broker

In most areas of commerce the issue of how you get your product to market is a very important one. In Insurance, there are a range of questions in this area. Do you work with brokers or direct with customers? Do you partner with a third party – e.g. a bank, a supermarket or an association – to reach their customers?

Even for Insurance companies that mostly or exclusively work with brokers, which brokers? The broker community is diverse ranging from the large multinational brokers; to middle-sized organisations, that are nevertheless players in a given country or line of business; and to small independent brokers, with a given specialism or access to a niche market. Which segment should an Insurance company operate with, or should it deal with all sectors, but in different ways?

The way to determine an effective broker strategy is again through information about how these relationships have performed and in which ways they are trending. Sharing elements of this type of high-quality information with brokers (of course just about the business placed with them) is also a good way to deepen business relationships and positions the Insurer as a company that really understands the risks that it is underwriting.
 
 
Changing risks

The changing face of risk

The changing face of risk

At the beginning of this article I stated that Insurance is all about risk. As in the pig fable, it is about policy holders reducing their risk by transferring this to an Insurance company that pools these with other risks. External factors can impinge on this risk transfer. Hurricane season is is always a time of concern for Insurance companies with US property exposures, but over the last few years we have had our share of weather-related problems in Europe as well. The area of climate change is one that directly impinges upon Insurers and better understanding its potential impact is a major challenge for them.

With markets, companies, supply-chains and even labour becoming more global, Insurance programmes increasingly cover multiple countries and Insurance companies need to be present in more places (generally a policy covering risks in a country has to be written by a company – or subsidiary – based in that country). This means that Insurance professionals can depend less on first-hand experience of risks that may be on the other side of the world and instead need reliable and consistent information about trends in books of business.

The increasingly global aspect of Insurance also brings into focus different legal and regulatory regimes, which both directly impinge on Insurers and change the profile of risks faced by their customers. As we are experiencing in the current economic crisis, legal and regulatory regimes can sometimes change rapidly, altering exposures and impacting on pricing.

The present economic situation affects Insurance in the same ways that it does all companies, but there are also some specific Insurance challenges. First of all, with the value of companies declining in most markets, there is likely to be an uptick in litigation, leading to an increase in claims against Directors and Officers policies. Also falling property values mean that less Insurance is required to cover houses and factories, leading to a contraction in the market. Declining returns in equity and fixed income markets mean that one element of Insurance income – the return on premiums invested in the period between them being received and any claims being paid out – has become much less.

So shifts in climate, legal and regulatory regimes and economic conditions all present challenges in how risk is managed; further stressing the importance of excellent business intelligence in Insurnace.
 
 
The Insurance Cycle

If this litany of problems was not enough to convince the reader of the necessity of good information in Insurance, there is one further issue which makes managing all of the above issues even more complex. This is the fact that Insurance is a cyclical industry.

An example of The Insurance Cycle

An example of The Insurance Cycle

The above chart (which I put together based on data from Tillinghast) shows the performance of the London Marine Insurance market as a whole between 1985 to 2002. If you picked any other market in any other location, you would get a similar sinusoidal curve, though there might well be phase differences as the cycles for different types of Insurance are not all in lock-step.

To help readers without a background in Insurance, the ratio displayed is essentially a measure of the amount of money going out of an Insurance Company (mostly its operating expenses plus claims) divided by the amount of money coming in (mostly Insurance premiums). This is called the combined ratio. A combined ratio less than 100% broadly indicates a profit and one above 100% broadly indicates a loss.

It may be seen that the London Marine market as a whole has swung from profit to loss, to profit, to loss and back to profit over these 18 years. This article won’t cover the drivers of this phenomenon in any detail, but one factor is that when profits are being made, more capital is sucked into the market, which increases capacity, drives down costs and eventually erodes profitability. As with many things in life rather than stopping at break-even, this process overshoots resulting in losses and the withdrawal of capital. Prices then rise and profitability returns, starting a new cycle.

Given this environmental background to the Insurance business, it is obvious that it is very important to an Insurance company to work out its whereabouts in the cycle at any time. It is particularly crucial to anticipate turning points because this is when corporate strategies may need to change very rapidly. There may be a great opportunity for defence to change to attack, alternatively a previously expansionary strategy may need to be reined in order to weather a more trying business climate.

In order to make predictions about the future direction of the cycle, there is no substitute for having good information and using this to make sound analyses.
 
 
Summary

I hope that the article has managed to convey some of the special challenges faced by Insurance companies and why many of these dramatically increase the value of good business intelligence.

Essentially Insurance is all about making good decisions. Should I underwrite this newly presented risk? Should I renew an existing policy or not? What price should I set for a policy? When should I walk away from business? When should I aggressively expand? All of these decisions are wholly dependent on having high-quality information and because of this business intelligence can have an even greater leverage in Insurance than in other areas of industry.

Given this it is not unreasonable to state in closing that while good information is essential to any organisation, it is the very lifeblood of an Insurance company. My experience is that Business Intelligence offers the best way to meet these pressing business needs.
 


 
You can read more about my thoughts on Business Intelligence and Insurance in:

  1. Using historical data to justify BI investments – Part I
  2. Using historical data to justify BI investments – Part II
  3. Using historical data to justify BI investments – Part III

tweet this Tweet this article on twitter.com
Bookmark this article with:
Technorati | del.icio.us | digg | Reddit | NewsVine

 


Short-term “Trouble for Big Business Intelligence Vendors” may lead to longer-term advantage

23 March 2009
linkedin Chief Information Officer (CIO) Network

This post is another that highlights responses I have made on various LinkedIn.com forums. In this case, a news article was posted on the Chief Information Officer (CIO) Network group (as ever you need to be a member of LinkedIn.com and the group to view the original thread).

The news article itself linked to a piece / podcast on The IT-Finance Connection entitled: Big BI Vendors Facing Big Challenges. In this Nigel Pendse, author of the anual BI Survey, was interviewed by IT-Finance Connection about his latest publication and his thoughts about the BI market in general.

Nigel speaks about issues that he sees related to the consolidation of BI vendors. In his opinion this has led to the big players paying more attention to integrating acquisitions and rationalising product lines instead of focusing on customer needs. In one passage, he says:

Within product development, the main theme moved from innovation to integration. So, instead of delivering previously promised product enhancements to existing customers, product releases came out late and the highlights were the new connections to other products owned by the vendor, but which were probably not used by the existing customers. In other words, product development was driven by the priorities of the vendor, not the customer.

Whilst there is undoubtedly truth in Nigel’s observations, I have a slightly different slant on them, which I offered in my comments:

It is my very strong opinion that what the users of BI need to derive value is not the BI vendors “delivering previously promised product enhancements” but using the already enormously extensive capabilities of their existing BI tools better. BI should not be a technology-driven area, the biggest benefits come from BI departments getting to know their users’ needs better and focusing on these rather than the latest snazzy tool.

If this does happen, it may mean less than brilliant news for the BI vendors’ sales in the short-term, but successful BI implementations are going to be a better advert for them than some snazzy BI n.0 feature. The former is more likely to drive revenues for them in the medium term as companies build on successes and expand the scope of their existing BI systems.

See also: BI implementations are like icebergs

While some people see large potential downsides in the acquisition of such companies as BusinessObjects, Hyperion and Cognos by large, non-BI companies, you could argue that their new owners are the sort of organisations that will aim to use BI to drive real-world business success. Who knows whether they will be successful, but if they are and this is at the expense of technological innovation, then I think that this is a reasonable sacrifice.

As to whose vision of the future is right, I guess only time will tell.
 

tweet this Tweet this article on twitter.com
Bookmark this article with:
Technorati | del.icio.us | digg | Reddit | NewsVine

 


A more appropriate metaphor for business intelligence projects

18 March 2009
A traditional metaphor for IT projects

A traditional metaphor for IT projects

IT people are familiar with a number of metaphors for their projects. The most typical relates to building; IT projects are compared to erecting a skyscraper. The IT literature is suffused with language derived from this metaphor. We build systems. We develop blueprints for them. We design architectures (two-for-one there). This analogy has some strength and there are indeed superficial similarities between the two areas. However, as with most metaphors, if over-extended their applicability often breaks down. I recall one CEO in particular who was obsessed by the “building team” moving on to the next “site”; regardless of the current one requiring further work and dedicated maintenance. One of his predecessors often referred to wanting a “diesel submarine” built, as opposed to a “nuclear one”. Before I fall into the same trap of over-exploiting the metaphor, let’s move hurriedly on.

As I mention above, aside from the occasional misapplication, the building analogy works reasonably well for many IT projects; does it also work for business intelligence? I think that there are some problems in applying the metaphor. Building tends to follow a waterfall project plan (as do many IT projects). Of course there may be some iterations, even many of them, but the idea is that the project is made up of discrete base-level tasks whose duration can be estimated with a degree of accuracy. Examples of such a task might include writing a functional specification, developing a specific code module, or performing integration testing between two sub-systems. Adding up all the base-level tasks and the rates of the people involved gets you a cost estimate. Working out the dependencies between the base-level tasks gets you an overall duration estimate.

The problem with BI projects is that some of the base-level tasks are a bit different. An example might be: develop an understanding of a legacy data table, how it relates to other legacy data sets and to more modern systems (this sits under area two of my model of BI development – see BI implementations are like icebergs). This is not an exercise that is very easy to estimate in advance. Indeed it may not be possible to produce an adequate estimate until a substantial amount of work has been done. Even at a late stage in the task, something may be discovered which expands the work required dramatically; surprises may lurk round every corner.

Why is this? Well with legacy data, the people who developed the system may have done so many years ago. Since then, they may have left the company or moved on to other areas, taking their knowledge with them. Their place may have been taken by successive tranches of new staff. Perhaps poor initial documentation meant that later workers did not fully understand the full nature of the system, but nevertheless did their best to build upon it. Perhaps the documentation was good at first, but has not been kept up-to-date and now describes a system that no longer exists.

By definition, legacy systems will have been around for some time and layers of changes will have accumulated on top of each other. Maybe, as a company has expanded, new data has been interfaced to the system from different business units and territories; perhaps each of these cases has its own dedicated interface code, each subtly different from those of other systems. Even where people exist in an organisation who preserve an “oral tradition” about the system, handed down to them over generations; these people may not appreciate how their data interacts with other data – even if the person who looks after another legacy system sits in the adjacent cubicle.

Waterfall Project Plan (intentionally blurred somewhat)

Although these challenges can also occur when trying to understand the data in more modern systems, they are particularly acute with older ones. For a start, the people who designed these systems are more likely to be around. Also legacy systems often sit at the centre of a Byzantine web of inter-connections, batch-processes, over-night jobs and the occasional more modern service. It can be a real mess and this is a situation with which any data analyst with a reasonable amount of experience will be very familiar.

The difficulty of estimating the duration of tasks such as properly analysing legacy data makes overall estimation of BI projects more of an art than a science. Of course techniques such as time-boxing tasks can be applied, but these are not always 100% appropriate. A 75% analysed data source (even assuming that the estimate that only 25% work is left is accurate) is not an analysed data source. Leaving dark corners of knowledge is likely to be reflected in BI cubes and reports that do not reconcile back to their sources. Probably the best way to deal with this problem is to be extremely open about the challenges up-front with executive sponsors and when submitting estimates. It helps to also stress the level of uncertainty in progress reports. The more honest you are initially, the better you will be able to explain any overruns and the more likely it is that you will be believed.

These types of issues mean that the – hopefully more orderly – process of constructing a building is not a fully accurate way to describe a BI project. That is unless the metaphor is extended to include an occurance that is all too common during construction in The City of London. Given the age of Londinium, whenever ground is broken on a new project, it is more likely than not that a mediaeval, Anglo-Saxon or Roman site is unearthed (often all three). These finds, while of enormous interest to academics, can result in projects being put on hold (sometimes for years) while the dig is fully assessed, artefacts are carefully removed and catalogued by experts and so on. Sometimes the remains are of such importance that a structure preserving and protecting them (and even allowing public viewing) has to be made part of the design of the foundations of new building. Many office blocks in The City have such viewing galleries in their basements. Such eventualities can create massive and unexpected overruns in central London building projects.

So this leads me to suggest a different metaphor for BI projects. Major elements of them are much more like archaeological digs than traditional building. The extent and importance of a dig is very difficult to ascertain before work starts and both may change during the course of a project. It is not atypical that an older site is discovered underneath an initial dig, doubling the amount of work required.

So, my belief is that BI professionals should not be likened to architects or structural engineers. Instead the epithet of archaeologist is much more appropriate. And if the fedora fits, wear it!

Fortune and glory in BI?

Fortune and glory in BI?


 


 
Apologies for the initial typo’ in the article heading, which persists in the perma-link. Of course I have the odd error scattered around the place, but in a heading! Maybe I need to employ a proof-reader.
 

tweet this Tweet this article on twitter.com
Bookmark this article with:
Technorati | del.icio.us | digg | Reddit | NewsVine

 


Is outsourcing business intelligence a good idea?

14 March 2009

Outsourcing
 
Introduction

The phrase IT outsourcing tends to provoke strong reactions. People either embrace it as a universal panacea capable of addressing any business problem, or recoil in horror at the very sound of it. Just for a change, I am somewhere in the middle; to me it is another tool at the disposal of businesses which can either be used wisely or poorly (much like IT itself you might say). As always the difference between the two extremes comes down to how well the project is led. Regardless of this, there are some benefits and some disbenefits associated with IT outsourcing and this article will explore the case for applying outsourcing to business intelligence.
 
 
Benefits of general IT outsourcing

Before I plunge into the world of BI, it is perhaps worth revisiting the general reasons for IT outsourcing, some of the most regularly quoted are as follows:

1. Reduction in costs

The provider of outsourcing (I’m just going to say “the provider” from now on to save typing) can carry out the same tasks at a cheaper cost to the client organisation (while still presumably turning a profit). There can be a number of bases for this; the one that generally comes to mind is wage arbitrage between different economies. However, it could also be that the provider has economies of scale; for instance, less people being required to run the consolidated data centres of several companies, than is required to run each separately. Also the provider may have staff who are more productive than at the client.

2. Ability to scale-up and scale down resource

The nature of business is such that sometimes all hands are required on the IT deck and at others there is spare capacity (this is something I address in my two articles on Problems associated with the IT cycle and Mitigating problems with the IT cycle). Now IT departments are normally quite good at finding (hopefully) useful things for people to do, but the issue remains. The promise of an outsourcing arrangement is that the tap of resource can be adjusted to meet demand without having to either fire and rehire staff, or rely on bringing in expensive contract resource. It is often hoped that this feature of outsourcing will also help to speed IT products to market.

3. Making IT provision a contractual relationship

An arrangement with a provider, depending on how the contract is drafted, can make the provision of IT services subject to penalties and claw-backs when service levels drop below those that have been agreed. While there are clearly some sanctions that can be applied to underperformance by internal IT departments, the financial benefit to the organisation is likely to be less (unless your CIO is a multi-billionaire of course). Companies are used to these contractual relationships, they are often the lifeblood of business, and it is a more familiar way of dealing with issues for them.

4. Access to skills

The nature of IT is that it does tend to evolve, sometimes quickly, sometimes slowly. For organisations this means keeping their IT people’s skills up to date though courses, or continually looking to bring people with new skills into an organisation (such people generally not being the cheapest). The idea with an outsourcing arrangement is that these issues become the headache of the provider, not the client. This area can be particularly pertinent when there is a technology change or a significant upgrade; these are times at which the prospect of being shot of IT worries may seem very attractive. The effort and cost of, as it were, upgrading your in-house IT staff may seem prohibitive in these circumstances.

5. Focus on core competencies

This has been a business mantra for many years, why should a company engaged in a wholly separate area of human endeavour want to become experts in building and supporting complex IT systems, when they can get a specialist organisation to do this for them? This moves towards the idea of a lean, or even virtual, organisation.

6. Failure of in-house IT

It is sad to have to add this item, but it is often the implicit (and sometimes even the explicit) driver of a desire to outsource. CEOs, COOs or CFOs may be so fed up with the performance of their IT people that they feel that surely someone else could not be worse. There is an adage that you don’t outsource a problem, but this is often honoured more in breech than observance.

I am sure that there are other advantages, claimed or real, for IT outsourcing, but the above list at least covers many of the normal arguments. At this stage a fully-balanced article would probably present arguments against IT outsourcing. However, my objective here is not to provide a critique of IT outsourcing in general, but to see whether the above benefits apply to business intelligence. Because of this, and I should stress purely for the purposes of this article, I am going to accept that all of the above gains are both realisable and desirable for general IT. There will therefore you will find no comments here about arbitrage (of its very nature) resulting in differentials of pricing closing over time.

The only benefit that I am going to rule out is the final one; addressing failed IT departments. Applying outsourcing in these cases is only likely to make things worse, and probably more expensive. Far better in my opinion to work out why IT is failing (most typically due to poor leadership it has to be said, see also my article: Some reasons why IT projects fail) and draw up plans for addressing this. If outsourcing is a strong element of this, then so be it, but thinking that it will resolve this type of issue is probably naive in most circumstances.

So, as always seems to be the case in these types of articles, we have five potential benefits against which to assess outsourcing BI. Before I look at each in turn, I wanted to make some general observations.
 
 
Things that are different about BI

The main fly in the ointment with respect to outsourcing business intelligence is the fact that good BI is reliant upon four things (see also BI implementations are like icebergs):

A. An in-depth understanding of business requirements, developed by close collaboration with a wide range of business managers. In particular, what is necessary is understanding what questions the business wants to ask and why (see Scaling-up Performance Management and Developing an international BI strategy)
B. An extensive appreciation of the data available in different business systems, its accuracy and how data in different places is related to each other.
C. Developing creative ways of transforming the available data into the required information and presenting this in an easy-to-understand and use manner.
D. A focus on change management that includes business-focussed marketing, training and follow-up to ensure that the work carried out in the first three areas results in actual business adoption and thereby the creation of value (see my collection of articles focussed on cultural transformation).

With the possible exception of item C., which is more technical, the above are best carried out in a symbiotic relationship with the business. Ideally what develops is a true IT / business hybrid team, where, though people have clear roles, the differences between these blur into each other. In turn, building thus type of team is predicated on developing strong relationships between the IT and business members and establishing high levels of trust and respect.

Also with item C., this is not precisely a stand-alone activity. It is one best carried out collaboratively by technically-aware business analysts and business-aware data analysts, ETL programmers and OLAP designers. Once again, distinctions blur somewhat during this work and a different type of hybrid team appears.

I have tried to illustrate the way that these tasks and teams should overlap in the following diagram.

bi-venn-w300

Clearly it is not impossible to achieve what I have described above in an outsourced environment, but it seems that it might be rather tougher to do this. One key point is that the type of skills that are necessary for success in BI are cross-over business / IT skills and these are generally less easy to buy off the shelf. Another is that the type of intellectual property that a BI team will build up (basically extensive knowledge of what makes the organisation tick) is precisely the sort that you would want to retain within an organisation.

I would suggest that if an organisation wants to outsource BI, then they should start that way. Once a BI team has gone through tasks A. to D. above then I can’t see how it would be cost-effective to subsequently outsource. The transfer of knowledge would take too long and be too costly.

To provide some context to this let me share some non-confidential details of a study I performed recently comparing the efficiency of a well-established BI team in a developed country with a less mature BI team in a lower-cost location. Rather than considering relative costs, I looked at relative productivity. A simple way to do this is to get quotes for carrying out a certain type of work from both teams (though I also applied some other techniques, which I won’t go into here). My main finding was that the ostensibly high cost team was more than twice as productive as the allegedly low-cost team. Just to be clear, if the “high-cost” team quoted $X for a piece of work, the “low-cost” team quoted over $2X,because they required much more resource and/or time to carry out the same work.

So, in what follows, I will assume that a decision is taken to outsource at the inception of a project. With this assumption and the previous background, let’s go back and look at the five benefits of outsourcing from the beginning.
 
 
Matching the benefits to BI

1. Reduction in costs

It will take external BI resource at least as long as internal BI resource to understand business requirements and available data. In fact internal staff probably have something of an advantage as they should already have an appreciation of what the organisation does and how IT systems support this. The external resource also has the disadvantage of it probably being more difficult for them to build business relationships, this can be exacerbated if there are personnel changes during the project; something that is perhaps more likely to happen with an external provider. If the provider is located in another country, then this raises even more challenges and inefficiencies (and leads to travel expense).

It will take an external BI team at least as long as an internal one to dig into the available data and how the various systems inter-relate. Again, having some familiarity with the existing systems’ landscape would be an advantage for an in-house team.

If an external team can get to the position where they understand the business needs and the available data really well in a reasonable period of time, then they could possibly have an advantage in the arena of transforming data into information. Something that may mitigate this however is that fact that most BI development is iterative and that a rolling set of prototypes needs to be reviewed closely with the business. This element introduces the same challenges as were apparent with defining business requirements above.

Similar arguments as were made about the business requirements phase apply to deployment and follow-up.

2. Ability to scale-up and scale down resource

While it may be possible (subject to contract) to scale-down resource with a provider (though perhaps tougher to get them back when you need them), scaling-up is just as hard as it is in-house at it means more staff at the provider going through the learning curve about the organisations business needs and data.

4. Access to skills

This is the crux of the matter. The skills in question are not Java programming (or even Cobol), they are business knowledge. ETL and OLAP skills are important, but only if they are applied by people who understand what they are doing and to what purpose. These skills are not just lying around in the market place; they are acquired through hard work and dedication.

3. Making IT provision a contractual relationship

Clearly this is a benefit of outsourcing. However, given that the contract is there for when things go awry, it is worth asking the question “are things more or less likely to go wrong with a provider?”

5. Focus on core competencies

While it is quite easy to argue that building e-commerce systems is not necessarily a core competency, good BI is about understanding what is necessary to best run the business. If that is not a core competency of any organisation, then I struggle to think of what would be.
 
 
Summary

My main argument is that BI is different to general IT projects (an assertion to which I will return in a forthcoming article). Having successfully run both, I am confident in this statement. I also think that you need different types of people with different skills in BI projects. These facts, plus the closeness of business / IT relationships which are necessary in the area mean that outsourcing is less likely to be effective. I am sure that an outsourcing arrangement can work well for some organisations in some circumstances, but I would argue strongly against it being best practise for most organisations most of the time.
 


 
After penning this article, a further problem with outsourcing business intelligence came to my mind; security. On part of most BI systems is a facility to analyse the organisation’s results. Ideally the BI system will have these figures in place very soon after the end of a financial closing. Such data is market sensitive and there may be concerns with trusting an external provider with both producing this and ensuring that it remains confidential until market announcements are made. I am not suggesting that providers are unethical, just that companies may not wish to take a chance in this area.
 
I should also credit a thread on the LinkedIn.com EPM – Business Intelligence group, which got me thinking about this area (as ever, you need to be a member of LinkedIn.com and the group to view this)
 

tweet this Tweet this article on twitter.com
Bookmark this article with:
Technorati | del.icio.us | digg | Reddit | NewsVine

 


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

11 March 2009

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.
 

tweet this Tweet this article on twitter.com
Bookmark this article with:
Technorati | del.icio.us | digg | Reddit | NewsVine

 


Trends in Business Intelligence

9 March 2009

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.
 

tweet this Tweet this article on twitter.com
Bookmark this article with:
Technorati | del.icio.us | digg | Reddit | NewsVine

 


Follow

Get every new post delivered to your Inbox.

Join 3,026 other followers