Category: Business intelligence

When did “tactical” become a dirty word?

A new report from Butler Group bemoans the “tactical” use of business intelligence tools on a piecemeal, departmental basis, calling for an enterprise-wide approach. However it rather misses the point about why this state of affairs exists. The author reckons “Business will only be able to improve its information services, and obtain real value from the ever-increasing data silos that it continues to generate, when it accepts the significant advantages to be gained from integrating and standardizing its approach to the management of its BI technology services.” Or, to paraphrase: why on earth are you deploying separate departmental solutions, you bunch of dimwits?”

As I have discussed previously on this blog. There are actually several reasons why most BI initiatives are departmental, often using different tools. It is not that the business people are a crowd of masochists. The first reason is that a lot of BI needs are legitimately local in nature, specific to a department or operating unit. It is dramatically easier for a department to set up a data mart that has just its own data, and stick on top of that a reporting tool like Business Objects or Cognos, than it is to wait for the IT department to build an enterprise warehouse, which takes 16 months on average to do, costs 72% of its build costs every year to support, and then usually struggles to keep up with changing business requirements.

So it is not a matter of “accepting the significant advantages” of an enterprise approach. Everyone accepts that such an approach would be preferable, but the IT industry has made it very, very difficult to actually deliver in this promise, and people naturally fall back on “tactical” (i.e. working) solutions when grandiose ones fail. Ideally you would like an enterprise data warehouse, deployed in a few months, that can deal with business change instantly, and can at the same time both take an enterprise view and respect local departmental business definitions and needs, which will differ from those of central office. The trouble is, most companies are not deploying data warehouses like this, but are still stuck in a “build” timewarp, despite the existence of multiple packaged data warehouses which can be deployed more rapidly, and in at least one case can deal with change properly. Until this mindset changes, get used to a world with plenty of “tactical” solutions.

Visuals for the few

There is a thoughtful article today by Stephen Few in the BI Network journal. In this he discusses the ways in which data can be presented to people, and gives a nice example of how a flashy graphic can be harder to interpret than a simple bar chart. There are some interesting follow-ups to this line of reasoning. Firstly, the vast majority of users of BI software have quite simple data display needs: they probably want to see a trend in data e.g. “are sales going up or down?” or answer a simple question like “what is the most profitable distributor?”. Since the vast majority of BI tool users have no background in data analysis or statistics, it is at best pointless and possible self-defeating to provide them with much in the way of statistical tools or elaborate graphical display capabilities. If they don’t understand statistical significance for example, then they may reach invalid conclusions by playing around with statistical tools.

This may explain why vendors who specialize in advanced data visualization never seem to really make it to any size. There are some very interesting technologies in this area e.g. Fractal Edge,(a technology that seems to me genuinely innovative) AVS, OpenDX and the tackily named The Brain. More established vendors would include SAS, who were one of the first vendors to really go in for sophisticated graphics and statistical tools, yet built up their considerable success mainly in other areas (e.g. they were about the only software that could make sense of an IBM mainframe dump, so became a standard in data centers; they have since diversified greatly). So, two decades after the graphical user interface became ubiquitous, why are there no billion dollar data visualization companies?

I think it is simply that there are not enough people out there whose jobs demand advanced data analysis tools. I have argued elsewhere that the vast majority of business users have no need whatever of ad hoc analytical BI tools. One can debate the exact proportion of business users who need something more than a report. I reckon perhaps 5% based on my experience on data warehouse projects, while I have seen an estimate of 15% from Forrester, so let’s say 10% isn’t far off. Then within this population, who want to at least see some analysis of data, what proportion are serious data analysts and what proportion would find a bar chart more than adequate? I don’t have any hard data here, but let’s go for 10% again as a guess. In such a case then only 1% of potential BI users actually need a sophisticated data visualization or statistical toolset. Indeed this figure may not be so far off, since in order to make serious use of such tools, some background in statistics is probably important, and relatively few people have this.

This would mean that, in a large organization of 10,000 people, there is actually only a market of 100 people for advanced data visualization or statistical tools (data mining tools being one example). Assuming that it is rare to be able to charge more than a few hundred dollars for a PC tool, then even at a thousand dollars a piece our mythical company would only be worth a maximum of USD 100k to a vendor, and that assumes that the vendor could track down every one of these advanced data users, and that every one of them buys the software, an unlikely situation.

If this reasoning stacks up, then while there will continue to be fascinating niche technologies serving aspects of data visualization, we are unlikely ever to see a true mass market for such tools. A picture may tell a thousand words, but there may not be many people in businesses needing to actually produce such pictures.

A good strategy for data visualization vendors would be to avoid trying to be mass market tools and find industry niches where clever graphics really do add a lot of value. For example a tool which improved a stock market trader’s view of the market would presumably be worth a lot more than a thousand dollars. The same would be true of a geophysicist working for an oil company. A good example of a targeted strategy of this kind can be seen in Spotfire, who have carved out a strong niche primarily on the life sciences industry, and seem to be thriving on it.

Does BI stand for Business Indigestion?

The business intelligence/data warehouse market is generally perceived to be in glowing health, with steady rather than wild growth predicted by most analysts e.g. 8% growth a year was a recent IDC figure. However there are many separate sub-segments here: data quality. ETL, data warehouse platforms, appliances, analytic tools, BI tools, data mining etc, and not all are in the same state. I have written before on how most people in a large company do not need, or indeed want a BI tool, something that people selling enterprise licenses for BI tools do not want to hear. In the late 1990s a lot of large companies went crazy with their IT budgets, and purchased huge blocks of BI tool licenses that often ended up as “shelfware”. Some consolidation in this sub-industry followed, with Brio being bought by Hyperion and Business Objects buying Crystal. However at some point I wonder whether gravity will reassert itself and companies will realize that only 5% of their staff actually need BI tools, while probably they already own many more than this, often from different vendors (a survey I conducted in Shell in 1992 counted 27 separate BI vendor products in use, and that was just within one company). The conventional wisdom is still the “democratization of BI”, with powerful BI tools spreading throughout a corporation, but I believe this vision is fundamentally wrong. Technology companies seem to struggle to grasp that just because they build something clever, it doesn’t mean people will buy it unless they actually perceive value from it. If one day I see a shelf-stacker in a supermarket puzzling over the latest shelf-stacking patterns on his BI tool I will admit I am utterly wrong about this.

But not today. Early signs of inflated expectations falling to earth appear in the latest results from Cognos, who have developed an enviable reputation in recent years but seem likely to end the quarter 19% down year over year in revenue terms, and 6% down over the previous quarter, and only three deals over one million dollars in the quarter. License revenue down 32% year over year cannot bode well for any software company, though with operating margins of 18% Cognos is clearly still doing pretty well on the profitability front (all those yummy maintenance revenues). There may have been some company-specific problems e.g. its latest software version 8 seemingly has yet to set the world alight. However it will be very interesting to see whether this is actually something deeper, with corporate buyers making better use of what they already have. Hyperion appears to be in rude health, but its products are mostly rather higher up the value chain (financial consolidation, budgeting) and it is unclear how sales of Brio are actually going. One interesting thing I noticed recently was one of our major customers (a household name) switching away from BI vendors and standardizing on the Microsoft tools (Analysis Services, Excel, Reporting Services etc) which have been steadily creeping up in terms of functionality. Since most users use only a tiny fraction of the features in a BI tool anyway, piling on yet extra features to stay ahead of Microsoft may not actually work. This may be an isolated case, but perhaps the cracks are starting to appear in the BI edifice?

Overcoming (some of) the BI barriers

A new survey from from Gartner has some interesting findings. Business intelligence in its broadest sense has moved from #10 in CIO priorities to #2, quite a jump. Spending in this area is set to rise sharply, with companies on average spending 5-10% of their overall software budgets on BI, but with some sectors such as finance spending 16% of their software budgets on business intelligence (more can be found in research note G00129236 for those of you who are Gartner clients). This is obviously good news for vendors in the space, but it seems to me that CIOs have been very slow to grasp that providing business insight is surely a high priority for their customers. Once the Y2k madness was over and everyone had rushed in their shiny new ERP, CRM and supply chain systems, just what else was it that CIOs should be doing rather than exploiting the wealth of information now being captured by these systems? CIOs are increasingly under pressure to deliver value to their companies, and what better way to do this than by providing improved insight into the performance of the company’s operations? Surely there is more bang for the buck for a CIO here than in fiddling with new middleware or upgrading the network, activities in which most business people have little interest and regard as “business as usual”. Anyway, the penny now seems to be dropping, so given it is finally on their radar CIOs should also consider what will stop them delivering this value, with its inherent career-enhancing kudos.

The main barriers to adoption of business intelligence, in Gartner’s view, are:

  • a lack of skills
  • difficulty in getting business intelligence out of enterprise applications (e.g. ERP)
  • perceived high cost of ownership
  • resistance due to some managers viewing enterprise-wide transparency as a threat to their personal power

I recently wrote on this last point. Let’s consider the others.

The skills one is the easiest: “organizations lack the analytical skills, causing them to have difficulty using the tools.” The answer is that most people in a business simply do not need a sophisticated analytical tool. It is not their job to be creating whizzy charts or mining through data – most business managers just need a regular report telling them their key performance information e.g. production throughput, sales figures etc. This requires at most Excel, and probably not even that. As I have argued elsewhere, the answer to BI vendors selling you thousand of copies of their software is simple: just say no, to quote Nancy Reagan. In my experience perhaps 5%-10% of end users of data warehouse applications actually need true ad hoc analytic capability – the rest need a report or at most an Excel pivot table. Putting a complex, powerful but unfamiliar tool on business people’s desks and then wondering why usage rates are low is a self-inflicted problem.

The second barrier is the dffifcult in getting BI linked to enterprise applications. This is a real issue, with the big application vendors either providing weak capability or, where they do, tying it too heavily to their own data structures. While there is a place for operational reporting, enterprise-wide performance management requires information from a wide range of sources, some of it in spreadsheets and external data. Obsessed with trying to broaden their own footprint, application vendors seem unable to let go and realize that customers have a diverse set of applications and are not going to simply ditch everything they have from everyone else. The answer here is to adopt an enterprise data warehouse approach that is separate from the application vendors and neutral to the applications. Leave the operational reporting to the app vendors if you must, but at the enterprise level you need something that is truly application-neutral. Cutting this link, and using app vendors analytic tools for what they are good at, rather than trying to shoe-horn them into roles they were never designed for, will save you a lot of pain and suffering here.

The third issue is cost of ownership, and here too the issue is very real. Recent work by The Data Warehouse institute (TDWI) shows that data warehouses have very high cost of maintenance and support. Indeed according to major TDWI survey, the annual support costs are 72% of the implementation costs, on average. For people used to traditional “15% of build” costs this may seem outlandish, but it is not. The reason that maintenance costs are often around 15% of build costs for transaction systems is that this is roughly the amount of code that is impacted by change each year. Most transaction systems are operating in a specific area of the business that does not change radically every week, so much of the application code is stable. By contrast, a data warehouse (by definition) takes as sources many different transaction systems, and every one of these is subject to change. So if you had a data warehouse with six sources, each of which had a 15% degree of change per year, then your warehouse is subject to a 6 * 15% = 90% level of change stress. Of course this is too simplistic, but you can see the general idea: with many sources, each undergoing some change, the warehouse encounters more change issues than any specific transaction system. Hence custom-built data warehouses do indeed have these very high lavels of maintenance costs. There is not a lot to be done about this unless you use a data warehouse design specifically built to address this issue, but unfortunately the mainstream approaches (3NF, star schema, snowflake schema) do not.

So to summary, you can take steps to circumvent at least three of Gartner’s four barriers. The fourth one involves tackling human nature, which is a more difficult problem that software design or architecture.

Do we really all need Business Intelligence tools?

An article I read in in DM Review today highlights Forrester Research saying that “25 percent and 40 percent of all enterprise users” would eventually use BI software. I’m not quite sure what they are smoking over at Forrester, but this seems to me like another of those lessons in the danger of extrapolating. You know the kind of thing: “if this product growth of x% continues, within ten years everyone on the planet will have an iPod/Skype connection/blog/whatever.” The flaw with such thinking is that there is a natural limit to the number of people that will ever want a particular thing. In the case of enterprise software that number is, I would suggest, much lower than commonly supposed. This is for the simple reason that most people are not paid to do ad hoc analysis of data in their jobs. Sure, some finance and marketing analysts spend their days doing this, but how many powerful BI tools does the average sales rep/bank clerk/shelf stacker really need? I’m thinking none at all, since their job is to sell things or do whatever it is that bank clerks do, not be musing on the performance of their company’s products or its customer segmentation.

In my experience of implementing large data warehouse systems at large corporations, there are remarkably few people who need anything more than a canned report, or just possibly a regular Excel pivot table. A salesman needs to work out his commission, a support manager needs to track the calls coming in that week, but these are for the most part regular events, needing a regular report. In a large data warehouse application that has 1,000 end users of the reports produced from it, the number of people setting up these reports and doing ad hoc analysis may well be just 10 i.e. around 1% of the total. Once you get past management and the people paid to answer management’s questions, there are just not that many people whose job it is to ponder interesting trends, or explore large data sets for a living. For this reason a lot of companies end up procuring a lot more “seats” of BI software than they really need. In one case I am intimately familiar with, even after five years of rolling out a leading BI product, the penetration rate was always much lower than I had expected, and never went as high as 5%, and much of this usage was not for genuine “BI” usage.

Of course this is not what the salesmen of BI vendors want to hear, but it is something that IT and procurement departments should be aware of.

Real Time BI – get real

I permitted myself a wry smile when I first heard the hype about “real time” business intelligence, which is hyped again this week . The vision sounds appealing enough: as soon as someone in Brazil types in a new sales order, the ultra-swish business intelligence system in central office knows and reacts immediately. Those who have worked in large corporations will be entertained by the naivety of this, since most large companies would be grateful just to know who their most profitable global accounts are.

The mismatch between fantasy and reality is driven by two factors. The first is that business rules and structures (general ledgers, product classification, asset hierarchies, etc) are not in fact uniform, but are spread out among many disparate transaction system implementations – one survey found that the average Global 2000 company has 38 different sources of product master data alone. Yes, this is after all that money spent in ERP. Large companies typically have dozens or even hundreds of separate ERP implementations, each with a subtly different set of business structures from the next (plus the few hundred other systems they still have around). The second problem is that the landscape of business structures is itself in constant flux, as groups reorganize, subsidiaries are sold or new companies acquired.

Today’s business intelligence and data warehouse products try to sweep this reality under the carpet, producing tools to convert the source data into a lowest common denominator consistent set that can be loaded into a central data warehouse. This simplification is understandable, but means that local variations are lost, and many types of analyses are not possible. Worse, if the business structures change in the source systems, then the data warehouses and reports built on top of them are undermined, with any changes to the structure of the data warehouse taking typically months to bring about. In these intervening months, what happens to the “real time” business intelligence?

The problem comes down to fundamental truth: databases do not like having their structure changed. Adding data is fine, but something which affects the structure of a database (a major reorganization will usually do the trick) will cause pain. If you doubt this, ask a CFO how long it will take him or her to integrate an acquisition just enough to be able to run the management accounts as one combined entity. For some companies acquisitions are a way of life, with several undertaken a year. Such companies are always chasing their tail in terms of trying to get a complete picture of their business performance. This is not just inconvenient but also costly: one company built a large and well-used conventional data warehouse, costing USD 4 million to build. When they properly accounted for all aspects of maintenance, including business user time (which few companies do) they found it was costing USD 3.7 million per year to maintain. There was nothing wrong with the warehouse design; they were operating in a volatile business environment, with 80% of the maintenance cost caused by dealing with business change.

What is needed, and generally what the industry has failed to deliver, are technology solutions that are comfortable dealing with business change: “smarter” software. Today few IT systems can cope with a change in the structure of the data coming into the system without significant rework. The reason for this is in the heart of the way that databases are designed. They are usually implemented to reflect how the business is structured today, with relatively little regard to how to deal with future, possibly, unpredictable, change. Introductory courses on data modeling show “department” and “employee” with a “one-many” relationship between them i.e. a department can have many employees, but a person can be only in one department (and must be in one department). This is easy to understand and typical of the way data models are built up, yet even this most basic model is flawed. I have myself been in between departments for a time, and at another time was briefly part of two departments simultaneously. Hence the simple model works most of the time, but not all of the time: it is not resilient to exceptional cases, and IT systems built on this model will break and need maintenance to cope when such special cases arise. This is a trivial example, but it underlies the way in which systems, both custom built and packaged, are generally built today. Of course it is hard (and expensive) to cater for future and hence somewhat unknown change, but without greater “software IQ” we will be forever patching our systems and discovering that each package upgrade is a surprisingly costly process. If you are the CFO of a large company, and you know that it takes years to integrate the IT systems of an acquired company, and yet you are making several acquisitions each year, then getting a complete view of the business performance of your corporation requires teams of analysts with Excel spreadsheets, the modern equivalent of slaughtering a goat and gazing at its entrails for hidden meaning.

Some techniques in software are emerging that tackle the problem in a more future-oriented way, but these are the exception today. Unfortunately the vendor community finds it easier to sell appealing dreams than to build software to actually deliver them. “Real-time business intelligence” comes from the same stable as those who brought you the paperless office and executive information systems (remember those?) where the chief executive just touches a screen and the company instantly reacts. Back in reality, where it takes months to reflect a reorganization in the IT systems, and many months more just to upgrade a core ERP system to a new version, “real time” business intelligence remains a pipe dream. As long as people design data models and databases the traditional way, you can forget about true “real-time” business intelligence across an enterprise: the real world gets in the way. It is interesting that the only actual customer quoted in the techworld article, Dr Steve Lerner of Merial, had concluded that weekly data was plenty: “The consensus among the business users was that there was no way they were prepared to make business decisions based on sales other than on a weekly basis”.