Reimagining IT systems – for the better

When I see how organisations approach their IT system implementations, I often think, “There has to be a better way.”

In many situations, while it’s clear IT could make a considerable difference to their operations, the prospect of going through the whole process can seem daunting. First there are the perils of choosing the supplier/system, and then there’s the potential pitfalls of deployment.

This is especially true when enterprise resource planning (ERP) systems are involved. While such applications are usually highly functional, this breadth of capability can often be the source of problems, for example:

• When trying to make a selection, it’s almost impossible to decide between multiple applications that fit some, but not all, your requirements.
• Once a choice has been made, understanding how to fit specific organisational processes into the pre-defined functionality of that system can be frustrating. Compromises, or even complete changes, may need to be made to operational activities to accommodate the application’s functionality.
• Implementation projects can often become bogged-down in endless configuration, with changes in one part of the application causing problems in another.

What about customised applications?

Using smaller, more targeted, or customised, applications for dedicated functionality can be just as frustrating. These may allow for better matches to specific requirements, but the different applications can often fail to connect easily with each other.

And in some cases it can almost feel as if applications are actively refusing to cooperate. They might seem to be building walls around their own functionality, and yet trying to take control of functions in other areas (a sort of operational ‘land-grab’).

It’s these two extremes that suggest the need for a better way – an ‘antidote’.

Reimagining IT

As is often the case when things converge around extremes, the antidote lies in a combination of the best of the two extremes.

So, the answer isn’t a complete rejection of the original ideas, but more a reimagining:

• Using multiple specialist applications provides better matching against existing processes than using a single large system with predefined functionality.
• But the large system ensures the different processes work well together, so those specialist applications can’t just hide data or use ad hoc mechanisms to send it to other favoured applications. Instead, they need to expose their data in such a way that any other application could use it without pre-registration.

But with this approach, the organisation must understand its processes, and in particular how the individual activities within those processes interact.

In turn, the IT solution architecture supporting the approach needs a mechanism to allow applications used within those processes to communicate information about those activities. So, ‘producer’ applications must control how information is exposed, while ‘consumer’ applications control how information is used.

And the individual applications within the solution must not only conform to the solution architecture but actively embrace it.

The right analysis

An appropriate analysis method will help an organisation to understand its processes. But the method is not simply about describing organisational operations in infinite detail.

Instead, what’s required is something that highlights (ideally only) those aspects of an organisation’s operations that will be most useful in defining the points at which different applications should interact. And these points often also correspond to the points where organisational performance is monitored.

In effect, this means analysis of this sort is useful both to support IT integration and in monitoring operations.

(As an aside, you could argue this lack of understanding leads to problems with traditional ERP projects and buying the wrong dedicated applications.)

Cohesive integration

A cohesive integration platform will help because of its well-defined boundaries and the fact it only operates within those boundaries. It doesn’t need to encourage implementation within the platform of functionality that should be implemented elsewhere (usually in the producer or consumer system).

It’s worth noting the terminology here. ‘Producer’ indicates it’s the responsibility of those applications to decide what data should be exposed, while ‘consumer’ suggests it’s the responsibility of those applications to decide how data should be used. Neither should assume the other’s responsibilities. And the integration application should only be responsible for allowing the data to be exchanged; it shouldn’t be responsible for interpreting the data.

When using this approach, information can be shared among applications, while significantly limiting functional dependencies. So, publishers don’t need to demand how consumers will use their information, and consumers place no obligations on publishers of information. And that means producers and consumers have minimal dependency on each other, while information is exposed as widely as possible.

By defining the scope and responsibilities of the applications and by describing the way in which they should interact, benchmarks can be established to help select possible applications.

NumberWorks and NumberCloud

Quantiv’s NumberWorks method is specifically designed to highlight these aspects of an organisation’s operations. But what’s important isn’t the specific method, but rather the information gathered by it.

Likewise, our NumberCloud service is designed to support a cohesive model of information exchange. But again, what’s important are the principles not the specific product.

And taken together, perhaps they constitute a better way to approach solution design – the antidote to ERP struggles.

Talk to our team on 0161 927 4000 or email: info@quantiv.com