The business case for lean BI

In IT, the emphasis is always on cutting costs while maintaining responsiveness and quality of solutions. There is perhaps no more suitable approach than 'lean thinking' to help in this regard, especially in the area of BI.

The aim of lean thinking is to maximise end-customer value while minimising waste. In BI, where tangible value can sometimes be elusive, the work leading up to and including project initiation is a crucial focus area for achieving these two objectives. This is because the decision to initiate a project can be made within a short period of time and will have a comparatively large impact on the allocation of resources and value-add to the business.

A misaligned project results in significant waste of resources. Conversely, a realistic project that makes a sound business case (especially to non-BI enthusiasts) at least ensures that waste is not already inherent in the initiative before it even gets under way.

Fifteen years ago, an article in McKinsey Quarterly, entitled: 'How otherwise good managers spend too much on IT', highlighted the discrepancy between management approval of IT expenses and other areas of the business.

The article pointed out that in most areas of businesses today, executives know what questions to ask before approving capital spend on new initiatives. They are not swayed by off-the-cuff, ready-made answers, but scrutinise the business cases before approval. Yet, somehow, when IT (and, I may add, especially BI) is involved, this does not seem to be the case. One finds IT initiatives receiving management approval under a popular slogan or catchphrase, such as 'one version of the truth' or 'customer focus'. Quite often the problem and solution are actually defined in terms of each other, such as 'a gap was identified in master data management'.

Management in many organisations will baulk at giving the green light to such initiatives without asking a few basic questions. These will include: Who exactly are the beneficiaries and are they willing to spell out the benefits they will derive? Who is going to use what information and how will they benefit from it? It is not enough to throw around a phrase such as 'one version of the truth' without spelling out what the actual problem is caused by its absence, and how the costs involved in implementing a solution to the problem will be outweighed by the benefits. At the same time, it should not be sufficient to invoke mystical references to 'BI maturity'.

The argument that this work is difficult is no justification for just doing something.

Francois Marais is a senior consultant at Busii.

Next question is: Show me at least one other credible alternative solution to this problem that was rejected and on what grounds, or what happens if nothing is done. In the case of the old chestnut 'one version of the truth', the symptom sometimes is as simple as 'we have meetings where everyone arrives with different versions of the truth'. The first response to this situation is: 'Just all agree to get your data from one place before the meeting.' If this cannot be achieved, there is possibly a problem to be resolved before any IT implementation, and that is getting agreement among the various parties about what would indeed constitute this one version of the truth. Frequently, different areas of the business manage customers from different perspectives, and therefore understandably, have different definitions of the same business entity.

Given a stated business problem, it is incumbent on IT to analyse it and examine all possible alternatives in addressing the problem, and to accept that in some cases the solution may not be the latest fashionable technology. Indeed, the problem may well show up some organisational or process-related issues, long before RFPs for the latest BI technology go out.

This is the approach advocated by lean thinking. The architect of the Toyota Production System, Sakichi Toyoda, coined the phrase: “Ask why five times,” to encourage a focus on adding value as opposed to wasteful effort misdirected at some intermediate cause of the stated problem.

The benefit to the organisation after such a project is the opportunity to learn from the project - did the implementation actually meet its intended aim? If not, what was learnt? The single-minded application of technology often precludes such learning by allowing projects to be defined in circular terms, as in the case of the 'gap in master data management'.

Just because vendors relate their tools to a problem in general, it does not mean that every time there is a situation which can be superficially related to 'conflicting versions of the truth', or 'inaccurate information', the tool or technology will automatically resolve the problem. To a dispassionate observer, reasoning like 'we spend a lot of time reconciling data from disparate sources so we need an MDM tool' sounds suspiciously like the type of logic applied when expensive personal luxury items are bought.

Often, the initial investigation that leads up to the business case need not be a costly or lengthy exercise, but it is important in building a lean BI capacity. A senior resource needs to be assigned to this task, to prepare answers to the few questions above. The task involves interviewing stakeholders, investigating IT systems and maybe doing some research on available technologies. The emphasis is on root-cause understanding of the problem first, only then identifying possible solutions. Often an iterative process of problem analysis and solution identification is needed to arrive at the solution that will best meet traded-off stakeholder concerns.

However, the argument that this work is difficult is no justification for just doing something. That should not be well received as a business case. Frequently, ordinary project management is forgotten as soon as there is some urgency to a project. The 'just do it' approach has become a synonym for CMMI maturity level one, characterised by a chaotic environment dependent on the heroics of individuals. Besides, the more work needed to establish whether tangible benefits outweigh costs to solve a stated problem, the more unlikely it is that the initiative is feasible or desirable. It may be time to move on and consider projects where the business case is easier to make.

Many organisations perform these investigations as a matter of course and practise some common sense in approving BI initiatives. In these companies, more time and resources can consequently be devoted to building quality and real improvements into the BI environment than those who allow wasteful IT initiatives. They can then move on to considering some of the other aspects of lean BI, such as exploring ways to eliminate waste once in the BI project life cycle.