The CIO / IT Director Survey – Redux

linkedin CIO Magazine CIO Magazine forum

Back in January 2009, I started the process of using both this blog and to solicit feedback on the top issues facing CIOs and IT Directors. This was in preparation for a seminar I was helping a recruitment agency – Chase Zander – to run. I got a lot of very interesting feedback, some of it also from people e-mailing my directly. This was summarised in The Top Business Issues facing CIOs / IT Directors – Results.

I thought that it might be interesting to revisit this area and so am seeking your feedback, either in the comments section of this article below, or again via and, in particular as before, the magazine group.

I look forward to your thoughts.


A compliment returned by

Thomas Wailgum at

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

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

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

Thomas Wailgum at

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

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

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

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

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

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

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

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

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

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

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

Hercules and the Hydra - Antonio del Pollaiolo

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

As Mr Wailgum says in closing:

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

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


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

The Dictatorship of the Analysts

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

CIO Magazine

However the ripples continue to spread from the rock that Jim Davis threw into the Business Intelligence pond. The latest mini-tsunami is in an article on 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.

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

Thomas Wailgum at

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

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

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

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

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