Just how does IT spend its time looking after ERP?
The results are in
Poll Results 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).
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.
Sponsored: DevOps and continuous delivery