VSJ – April 2002 – Work in Progress

Allen Woods, MIAP, managing director of JIT Software Ltd and author of a range of organisation modelling and management software writes the second of three articles about a system requirements approach adopted by his company:

In the previous article I attempted to argue the case for IS/IT system designers and developers to use current ‘best practice’ business analysis techniques to enhance communication between system sponsors and themselves. In this second article I will describe, in overview, the business analysis techniques we encourage our clients to adopt.

Strategic Planning and Key Documents

The first things to identify and review are what we term the ‘key’ business documents. Broadly, they are the organisation ‘Charter’, a ‘Vision’ statement and finally a ‘Mission’ statement.

Many organisations will have some or all of these. The problems arise from what they are used for and what they describe. After careful consideration we believe the documents indicated should fulfil the following purposes:

The Charter: This describes why the organisation was formed and its core values, products and services. If you do not know your core values, then it is difficult to define aims and objectives that are relevant to the aspirations of the organisation as a whole.

The Vision: No mere statement of principle, this is a clear description of the long-term strategic aims and aspirations of organisation as a whole.

The Mission: Once again, this is not a statement of principle, but a clear description of short-term ‘tactical’ objectives.

In principle, these documents should be capable of being used throughout the hierarchy in such a way that organisation sub-elements can write their own ‘key’ documents, that can be related to those created by the next level up in the management chain. In effect, this provides a ‘top down’ approach to strategic planning.

Analysis Technique

The trick then is to adopt the tools that provide a means to identify the ‘Vision’ and ‘Mission’ in such a way that a coherent ‘top down’ approach can be applied. After careful research, we have identified one business analysis technique that is designed along the principles of ‘review to improve’ and can be adopted by any organisation. This technique is known as the ‘Business Excellence’ or European Foundation for Quality Management (EFQM) Model.

The EFQM model forces a holistic view of the description, analysis and review of how an organisation works. Briefly, the model is divided into two groups, ‘Results’ and ‘Enablers’, that, between them, are further divided into nine sections. In turn each section has a number of ‘analysis criteria’. For each analysis criterion, analysts have a number of questions that they can ask, which will direct any analysis effort.

A number of products should come out of EFQM analysis. They include:

A set of business objectives

A set of process models (which can be applied to, or drawn from, ISO 9000 documentation)

A set of performance measures

A view of how the whole organisation is doing

Because of the nature of EFQM analysis, and with the application of a technique called ‘RADAR’, which is a scoring method integral to the EFQM, it is possible to make valid comparisons with other similar organisations that are using the EFQM. In short, the EFQM is a benchmarking mechanism that can be used to determine effectiveness of performance.

Measuring and Reporting

Having applied an analysis technique and identified performance measures and benchmarks, analysts can then identify a suitable measuring technique and, from that, determine where raw data are to be collected and where those data are to be turned into management information.

The key performance measure identified through EFQM analysis and benchmarking can be defined as

The average level of performance a given resource is expected to meet given current operating conditions.’ Each indicator should also have tolerances so that they can be used to identify success or failure rather than just the average. To revisit my example from last month, if the resource is the axle production plant, and the performance measure is ten (axles per specified time interval), eight might represent failure.

Data to support these measures are collected at a point at which a measurable transaction occurs in any relevant process.

In terms of actually measuring indicators, a number of techniques may be applied – Activity Based Costing for example. The measurement technique used is on a ‘horses for courses’ basis, but what the EFQM should do is to draw those techniques under the umbrella of a broad-brush analysis scheme in much the same way as SSADM is a subset of PRINCE 2.

In terms of reporting, it makes sense for managers to have a mechanism that determines what they need to know in order to judge success or failure. A method of grouping performance measures and the data collected to support them is the Balanced Scorecard.

Invented by Harvard Professors Kaplan and Norton, the Balanced Scorecard is effectively a method of logically grouping performance measures into business perspectives. Traditionally (though not necessarily) a balanced scorecard is divided into four perspectives designed to give an indication of economics, effectiveness, efficiency and learning and growth (evolution). Each organisation element can have its own scorecard. Indeed, scorecards can be given to individuals if required. From the IS/IT designer’s viewpoint, a balanced scorecard is effectively a specification of where raw data, collected at the process level, are to be delivered as information. The Balanced Scorecard is recognised as a major advance in general business management of the past 20 years. According to Kaplan and Norton, a supporting IS/IT infrastructure is necessary to an effective scorecard system.

If the concept of the balanced scorecard is used in tandem with a ‘top down’ EFQM analysis effort then managers at all levels of an organisation should know what their targets and objectives are and how they will be measured. A cascade of scorecards will define the reporting chain from the shop floor, at the process level, to the boardroom as a scorecard.

Conclusions

In this article I have touched on an approach to co-ordinating a number of business analysis techniques that will benefit IS/IT designers in the following ways:

Provide a cohesive structure to general business planning

Provide a mechanism that defines a statement of requirement, though the medium of EFQM analysis and scorecards that by definition must meet expectations.

In the final article I will describe the information system architecture that should result.

You can contact Allen at Allenwoods@jit-software.com. Visit www.jit-software.com for more information.

Interesting project or development? Let us know at eo@iap.org.uk!

Comments are closed.