IT system tails and operational dogs

I won’t stray into political discussions about funding for local government in England. But one of the most striking aspects of Birmingham City Council’s recent financial problems was a (very) large cost overrun associated with an IT project.

The total cost of the enterprise resource planning (ERP) project has increased fivefold – from around £20 million to an estimated £100 million. (However, this hefty IT bill was just one contributing factor in the council’s financial crisis.)

IT: supporting service or product?

It’s worth noting that although IT is now an essential part of modern life, it’s still often used as more of a supporting service than as a ‘product’ in its own right, i.e.

• Online shopping, banking and travel may all heavily use IT, but their real products are the goods delivered, money managed and transport provided.
• Even services that seem to be pure IT – such as social media, news, streaming – are really just using IT as a different way to provide well-established services (communication, entertainment).

Local government in England is no different. Homes, schools, social care, transport: these are the services authorities like Birmingham actually provide. IT is just a way to help them deliver those services.

But while IT may indeed be just a supporting service, its effects – good or bad – can be significant. Birmingham’s situation is a reminder of just what a tangible impact a seemingly simple support service can have on an organisation.

And large IT projects are rarely simple.

Managing complexity in IT projects

Leaving aside any aspects of overall governance, an organisation’s complexity will inevitably be reflected in its systems and processes.

As one of the largest local authorities in Europe, Birmingham’s requirements would inevitably be more complicated than those of a smaller, more rural council.

One way to manage this complexity is to adopt – rather than adapt – an IT system. And that might mean accepting that organisational processes may need to be changed to meet the functionality of that system. This was the approach Birmingham initially intended to use for its ERP system implementation.

Despite having a feeling of ‘the tail wagging the dog’ (i.e. systems shouldn’t define processes but instead reflect them), there’s also some rationale to it. Organisations are rarely as different as they might first appear or like to think, and so using a standard system for common processes has a lot of merit. And if the organisation can be adapted to fit a system’s functionality where there are differences, then so much the better.

But while this approach might be valid, it requires that:

• The organisation has defined its processes or, more realistically, that it understands its processes.
• Potential suppliers have defined their systems in terms of the processes they support.
• The two definitions are comparable.

But these definitions can rarely be defined accurately by something as simple as a functionality checklist, although they’re often covered as such, especially by suppliers eager to have their systems adopted.

Detail differences will always be present in the functionality associated with specific processes and systems. Comparing on that basis will be prone to false failures, indicating an incompatibility where none really exists. Indeed, there’s no harm in those differences and they may even suggest better ways of working.

The drawbacks of checklists in the system selection process

But differences in the activities and processes themselves can be far more significant. Changing the search terms used in an activity might require only a small adjustment but removing or adding a processing step can be much more disruptive.

Yet these process differences can often be disguised or omitted entirely by checklists concentrating only on details.

Irrespective of the details of functionality, it’s important for an organisation to know its operations are, or could be, the same as those supported by a proposed system.

To make that comparison, you don’t need a simple checklist covering detailed but perhaps irrelevant functionality. Instead, you need cohesive, high-level descriptions of both organisational operations and system functionality.

Often, this is seen as needing to define a data model for the required system, and suppliers can also concentrate on describing their systems in this way (for example, ‘you can collect this data associated with a customer’).

What are your operational requirements?

But just identifying data without a context for its use is both difficult and almost as error prone as concentrating on functional details. Data – and indeed the functions that manipulate it – are subsidiary concepts to the interactions that led to them. So, it’s no wonder that trying to start with them is hard and inaccurate.

To provide this context, interaction models that define the results of activities and processes performed should instead be the primary concepts considered when defining operational requirements. Once those interactions are clear, the data and associated, detailed functionality models will emerge from them.

These models can then be compared against the corresponding models of potential systems. And if those system models don’t exist, that could be a sign of trouble to come.

Working in this way means candidate systems can be quickly and reliably compared against operational processes, before any great expenses are incurred. And that means you can rule them in/out early in the selection process, or that any non-standard/custom requirements are clearly identified.

Quantiv’s NumberWorks method is specifically designed to support this approach. It allows a simple yet comprehensive operational model to be created. And that in turn enables candidate system functionality to be assessed in the light of well-targeted operational requirements.

In short, this approach ensures the operational dog wags the system tail.

Help with ERP system selection

Want to discover how NumberWorks can help your ERP selection process – and improve how your organisation runs? Contact the Quantiv team on 0161 927 4000 or email: info@quantiv.com