Just how does IT spend its time looking after ERP?

Enterprise Resource Planning (ERP) packages providing functionality to support core business processes in an integrated manner are a prominent feature in a lot of IT environments. But what kind of burden do they place on the IT department?

Some of us who have been in the business for a while can remember the days when these things were relatively self-contained and almost part of the furniture, and one Reg reader reminded us of these days with the comment:

We have been running on AS/400, iSeries and now System i, for over 20 years. We currently run Mapics/XA on it. Mostly all we do is swap the tapes in/out every day. Once a year we do a DR test. The latest save is then put in the drive. The test system then boots off the tape and installs the entire machine. Departments then sign off to say that all is ok and the test is done. This is all managed by 1 person!

While it’s nice to hear that some people still have a relatively easy time with ERP, however, the more typical reality of today’s multi-tiered, web-enabled, open systems-based implementations in a complex IT landscape and fast moving business environment is quite different, as summed up by an alternative viewpoint from another reader:

The post ‘go-live’ day-to-day management of this ERP system is generally a large overhead from the view of change requests, upgrades and follow-on projects and usually requires a significant investment in support staff and infrastructure to support the environment landscape and its manipulation.

With this in mind, we polled those in the readership with experience of implementing and looking after ERP systems on what is involved from an IT perspective. The 72 respondents that participated in this study were firstly asked to provide an indication of which activities consumed the most time and resources. What’s clear from the feedback is that much of the effort is concerned with the ongoing evolution and maintenance of the system from a functional rather than a platform or data management perspective (Figure 1).

Figure 1

Of course some of this activity could be dependent on where you are in the implementation cycle. You would expect, for example, quite a bit of continued enhancement and tuning of the initial implementation for a significant period after go-live, and the following reader comment provides one possible reason for this:

In any large implementation, there are bound to have been some areas of the implementation that were glossed over, done in a ‘quick and dirty manner’ or even not implemented at all.

There is also the factor of the business getting to know what the system can do and finding out how the designs falling out of all of those pre-implementation workshops actually work in practice. It is therefore not uncommon to see a steady stream of change requests as users gain experience, identifying gaps that need to be plugged and areas where things can be improved.

But should we expect this kind of activity to settle down over time?

This is something we were able to look at as one of the questions we asked in the poll was how long the ERP system concerned had been in place. Almost exactly a third of respondents had implementations that were less than three years old, the point after which we might consider a system to be relatively bedded in and mature. This gave us the opportunity to compare activity between relatively new and more established environments, and while some differences can be seen, it’s pretty clear that change is ongoing throughout the lifetime of ERP (Figure 2).

Figure 2

Some of the most prominent differences, as we can see, are towards the bottom of the chart and the activities here are more concerned with underlying platform related activity. Mature systems seem to involve more work here, but this may be as a result of older hardware, platform software and management frameworks needing more effort to keep running. Newer implementations are more likely to be based on modern architectures that are inherently easier to manage with the latest generation of admin tools.

By the same token, the additional effort required to maintain interfaces that is apparent in older setups is in part down to a lot of the original integration work having being done before the latest developments in open standards and APIs had been embraced by ERP vendors, making things inherently more difficult to change and maintain.

Coming back to business functionality, however, we can see from the activities towards the top of Figure 2 that ERP systems are essentially living entities that are constantly evolving. This is something acknowledged by readers through comments such as:

ERP projects should never end, that’s the whole point of ERP ultimately – a continuous search for perfect automation and you could – and to my mind should – argue that if it ever ends you’re not doing it right.

The markets & business change continuously, ERP has to keep up.

With this in mind, it is interesting to look at the parts of the system that are typically the most dynamic from a business functionality perspective (Figure 3).

Figure 3

The overall size of each bar indicates the number of installations that have the functionality listed in place, but whether you look at this, or the composition of the bars which reflects the degree of ongoing change, the obvious area that stands out is reporting, analytics and business intelligence. This is consistent with feedback from the end of last year on unlocking additional value from ERP and CRM (see here. Businesses are increasingly wising up to the fact that the information gathered in these systems is an incredibly valuable asset.

The difficulty though, for older systems with more limited embedded reporting and BI capability in particular, is that this area can consume a lot of time and resources just working around the practical challenges:

Don’t forget the reporting systems bolted onto the ERP along with other integrations, making changes is a total nightmare.

The other important observation from Figure 3 is the way in which functions relating to externally facing parts of the business are often the most dynamic – sales, supply chain, procurement, supplier management, and so on. Together with finance and accounting, which is subject to a lot of regulatory and tax related change, this highlights that outside factors, ie the dynamics of what’s going on in the big wide world, constantly impact the ERP environment.

This need for constant change, and the previous emphasis on business functionality, is reflected in factors which are likely to influence an ERP replacement decision (Figure 4).

Figure 4

In addition to the lack of business flexibility, limitations with respect to IT level flexibility and openness, which also appear quite prominently here, can be another driver for replacement. Having said all this, a decision to replace is clearly not one that will be taken lightly, and when we look at the potential impediments, the reasons are pretty obvious (Figure 5).

Figure 5

Given these challenges, it is interesting that some recommend more of a continuous re-implementation approach in which parts of the system that are drifting from alignment with business requirements are selectively revisited when necessary:

To be honest, the continual re-implementation is a good thing! Organisations are able to continuously improve their use of the ERP system and can vastly improve the implementation over time. Also, the business environment is continually changing, and organisations evolve to cope; most ERP systems will probably have the required functionality to support these changes, so extending the implementation of the current ERP system is normally a cheaper option than a new ERP system.

One of the considerations here is clearly whether the underlying package is still current from a core architecture and functionality perspective.

The whole discussion around whether to replace or upgrade, and the criteria that are important if you do decide to go down the replacement route, is something we will be picking up in subsequent articles and polls during our ongoing workshop.

In the meantime, there was one comment that came back from a reader that we felt was particularly apt when thinking about anything to do with ERP:

Installing an ERP system is not an IT project – it is a business project. Anyone that doesn’t understand the difference is doomed to failure. Yes there is an IT project as part of it, but that part is very small.

Nevertheless, IT is always going to be part of the equation, and we appreciate the time of those who participated in our poll to help us understand that dimension a little better.

Dale Vile

Click here for more posts from this author

Dale is a co-founder of Freeform Dynamics, and today runs the company. As part of this, he oversees the organisation’s industry coverage and research agenda, which tracks technology trends and developments, along with IT-related buying behaviour among mainstream enterprises, SMBs and public sector organisations.