Do ERP projects ever end? In some organisations, the ERP system represents the biggest single entity within the IT environment. This is particularly the case in industries such as manufacturing, distribution and others that are heavily manpower- or goods-centric. Even if ERP in itself doesn’t account for a lot of the infrastructure per se, it is one of …
A bad SAP implementation almost destroyed the company. Drained £10 million out of the coffers before they completely restarted. Took another couple of years to get it workable.
In the background was the old 'legacy' system, trundling along with a single guy doing updates for the whole system. Was eventually turned off, for most things, but still runs some others that it's too expensive to get SAP to do.
One of the IT devs who was moved over to SAP basis has a whiteboard that the whole department can see, including directors. He wrote SAP IS SHIT in big black letters. No one has challenged him, and it's still there 18 months later.
As things are today, customers know that a package has been sent out of the warehouse before the business does, as they have received it before SAP has been updated by the external warehousing system, again too expensive on the SAP side to integrate it properly.
SAP, jack of all trades and fecking useless at all of 'em.
Blame the business for not implementing it correctly, probabaly due to:
A crap business case.
Crap initial business requirements.
Crap business blueprinting / process analysis.
Crap requirements transformation.
Crap delivery management.
Crap business and IT transformation.
Crap stakeholder management.
Don't forget : SAP itself is just a piece of software. It will only ever do what you tell it to do.
You are absolutely correct, the things you listed are responsible for 99.9% of implementation failures.
A crap business case.
Crap initial business requirements.
Crap business blueprinting / process analysis.
Crap requirements transformation.
Crap delivery management.
Crap business and IT transformation.
Crap stakeholder management.
Don't forget : SAP itself is just a piece of software. It will only ever do what you tell it to do.
ERP projects do end, and it is the responsibility of the stakeholders and programme/project management to make sure that the project is correctly scoped, that all deliverables are set out and defined in full, and that all changes are correctly managed so that this end point is clearly visible and achievable.
Following on from this though, 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 it's manipulation.
Having been involved in many large scale ERP projects it amazes me how many fail due to bad planning, lack of understanding of the solution and benefits; and more importantly - bad management of 3rd party suppliers who generally do most of the development work (I could name names... but won't).
The key here on costs is that any project timeline should by necessity be defined as "finite" with these, and all subsequent ongoing support costs accounted for and set out over a 5-10 year period in the business case to be measured at regular intervals post implementation.
Amazing also how many senior managers assist the failure of these sorts of projects by not listening to those specialists that they employ as they think it makes them look weak.
Stated very simply above I agree - in reality It's never that easy though is it?
We have been running on AS/400, iSeries and now Sustem i for over 20 years. We current run Mapics/XA on it. Mostly we swap the tapes in/out every day. Once a year we do a DR test which sees a complete system delivered in Goods-In. 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!!!!!
We've had to put the DR into place twice and we have got back up in 10 hours from the initial call. This kind of stuff is critcal.
We tried to replace this with Peoplesoft a little while ago. We ended up with around 36 servers running all the apps !!!! We've never performed a successful DR test as it's running Windows and is an absolute pain to restore (if at all). This set up is managed by 15 staff in out head office and we have had more downtime on Peoplesoft in 1 year than we had on the AS/400 over 20 years !!!!!
I've just read the comment above. Guess what we are installing now? Yep you guessed it.... SAP.
Oh dear. Let me keep Mapics/AS/400 please. It just works. Not sexy, but works.
The answer is "Yes"
3 decades ago it was *known* by smart operators that you understood the company systems and requirements *before* you went shopping for a new package and made sure any candidates you picked could *provably* handle those core tasks at *least* as well as your existing set up.
Other classic lies "It's so simple your staff won't need training" and "data migration will be no trouble at all."
Ideally if the best package for the business (not the consultant/supplier) ran on different hardware you planned a hardware migration.
Those who don't know history will repeat it. Again and again.
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 idea is you set milestones of benefit delivery, which benefit recipients and delivery teams should be held jointly responsible.
Your initial question, do ERP PRojects ever end, is therefore rather misleading. The question should be, do ERP projects deliver tangible benefits and the answer is yes if you do it right and they should keep doing so for the lifetime of the business. The trick, of course, is to select the right system, or skillsets, to ensure you deliver quick and tangible wins, with a roadmap for practical evolution of those benefits from point A to infinity.
"Data migration will be no problem" HA!!!!
There are outfits who specialize in this sort of thing. I suspect your management has been convinced it's such a small problem you won't need them. In the UK IIRC there used to be an outfit called PMPL who did this but i don't know they still exist.
The only positive advice I give is *always* do the data cleaning *before* the migration. IMHO it *never* gets done afterward and a fair proportion of ongoing troubles can be traced to out-of-date or just plain wrong data. Plus it might give staff a chance to re-acquaint themselves with just what is held in all those files.
Apologies if you know this. Waiting until after the data has gone over is *always* seductive. I also know the endless amounts of staff time are consumed when it's not cleaned before.
The worst part of what I wrote is none of it is particularly secret. People know it, they just seem to *act* on their knowledge.
Good luck. Any system which can give serious benefit to a business is always going to need serious commitment to install.
Yeah, we're (read: "I'm") currently in the cleansing stage at the moment. As a relatively small firm, especially with costs spiralling out of control for the core software (hmm, yeah, did we not mention it doesn't do that out of the box? I'm sure we can get something put together for you for a small consideration...." - they remind me of cowboy builders "you want DOORS, do you? Well, that's going to add...") an external firm to handle migration is a luxury we can't afford (and tnh, don't need. It's a PitA, but certainly not insurmountable).
Or at least they shouldn't.
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 (as mentioned previously) not implemented at all.
Most ERP systems have more functionality than the organisation requires, or in some cases the organisation just doesn't have the skills to use some of the package, so these areas will be reimplemented as experience within the organisation grows. This is especially true of SMEs where ERP skills may be lacking prior to the initial implementation, but post implementation, as people learn more about the system or as new recruits bring experience into the organisation then new areas of functionality can be exploited.
There is also an element of ERP customers not using the systems as the designers intended, so in order to implement in a "we've always done it this way" environment, the initial implementation is heavily customised; and later on as the benefits of "best practise", as embodied by whatever ERP system is in place, are realised, the customisations are removed and areas of the system are reimplemented. This was especially true in the rush to implement before "Y2K".
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.
At least, this is my experience working as an ERP consultant between 1992 and 2002.
Anon to protect the guilty!
In my experience, the primary cause for system implementation failure is lack of understanding (and investment) relating to the problem that needs to be solved.
Companies like to think they are buying a solution to their problem and ERP sales people are keen to take the money. The "problem" may not be lack of an ERP system but lack of process.
This is a classic example of automating something that is not understood. In any company, the process should be well understood and tested before it is automated with an ERP system.
My company ensure that a customer commits to up-front consultancy to enable all parties to be clear about the project and systems. We loose opportunities this way but at least we do not end up with unsuccessful projects. It is a hard sell to many customers as they do not expect to pay for what they may consider as pre-sales. We also have learned to be very tough on customers who will try to persuade us that they know their own systems, if they cannot write it down, they are not ready for an ERP system.
Regarding the point about never ending projects, a good relationship between supplier and customer should go on in to perpetuity. This is not failing to finish but working on refinements and updates. The fundamental rule is that if the requirement does not change, the system should not have to. In practice, most businesses will change and adapt elements of their processes in line with new suppliers, new products or projects, even legislation and regulatory changes.
An implementation project ends. ERP however, like many other ICT-issues has no definite end.
It is a big mistake to turn everything into limited-scope projects. Corporate use of ICT in general must be handled as an on-going process. This and IT-staffs lack of knowledge of the field in which their technology is applied are the 2 dominating causes of failure in corporate ICT.
the markets & business change continuously, ERP has to keep up
we avoid the low-level hassles by using a highly customisable hosted ERP - Netsuite - and concentrate on the business logic. we also avoid the external systems, reporting etc that can slow down changes and complicate things - if netsuite doesn't do it, do we really need it?
disclaimer: we liked netsuite so much, we now resell it
"It is a big mistake to turn everything into limited-scope projects."
Not so. Or at least, you can have an unlimited-scope *project *, but the deliverables at each milestone, the milestone dates themselves, and the amount to be paid to the consultant at each milestone, must be so strictly limited that neither the customer nor the consultant can dispute them. Failure to fix these three are the direct cause of every cost overrun in existence.
Sure, the customer may then think up new features and ask "how much would it cost to do this?" Or the consultant may propose a bunch of new features, with a price tag on each one, and the customer can decide if they want any of them.
Been working on installing SAP for a couple of years now. In some respects, it is actually working. But I don't like the GUI as it is outdated, and many processes are just stupidly complex (particularly for Basis).
The cost has been much higher than originally agreed and the consultants were bloody useless. We have learnt far more ourselves through external training and resources than we got from them - and it's been proven by a new consultant that a lot of what they did was simply wrong. Hopefully, we will eventually get shot of the garbage that was part of the original install and end up with something that does the job.
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. SAP is a classic example of that premise and failures occur as many organisations (and people) don't understand the difference.
Anon as I like my job (mostly)
"SAP = Shut up And Pay "
Nice.
"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. "
An excellent point. Applies at least as much to govt. IT projects as private.
You have to wonder what senior managers are thinking when they green light one of these. "We want radical improvements in costs, service delivery, timescales etc."But "We don't want much change in how we work."
On SAP in particular I have 2 impressions of it.
1) It's very powerful and will allow you to do *almost* anything you want if you can work out *how*.
2) SAP consultant quality is *highly* variable.
But those are only *impressions*.
"2) SAP consultant quality is *highly* variable."
Sadly, this is true. In my experience, consultants multiply like rabbits in the fat years only for the more dodgy ones to be weeded out every time there is a recession. Which suggests that the average quality today is probably higher than it was a couple of years ago and will probably go higher still for the next year or so before it starts to drop again.
Oh, and they are definitely business projects not IT projects. Ignore that fact at your peril.
Fremma
(who has survived three recessions he can remember in his 14 years as an SAP consultant and therefore by this logic is probably one of the better ones:-))
How is ERP implementation projects any different from other projects that try to implement such broad capabilities using best of breed software? I read above how people are use just aix/as400 and wonder if the operating system really provided all the business logic they needed? It appears this company was able to run their business without adding any business logic to the system at all. And everything automatically communicated with everything else with no effort, by anyone. And then the company never, ever changed a single thing...so no IT work was ever required again. Good Lord, where do these people work? What industry survives at such a stand still pace?
"I read above how people are use just aix/as400 and wonder if the operating system really provided all the business logic they needed?"
No.
It's simply that given the substantial investment to do this smaller firms put in a new system and leave it. They cannot afford (or in some cases do not consider it a priority) to update it every five minutes. they then rely on it being flexible enough to accommodate things like tax rate changes by variable or file changes without programming.
There's a difference between possible and good.
BTW AIX is an IBM Unix which runs on what were called the RS/6000 min computer series. AS400 runs OS400. these days same basis core hardware but *very* different OS look and feel.
Installing, updating and maintaing ERP systems is fundamental to many business' operations.
However; they tend to treat it very casually as "it's just software".
Migration and updates are frequently without a full assessment of requirements, resources and objectives, let alone a plan for how to dealwith possible failures. It is a lack of Engineering.
I'm in the muddle (no typo) of an upgrade project where the project manager apparently doesn't have a plan or schedule. At least not one visible to the key players in the project. The project manager's only plan seems to be for eventual blame attribution.
Failing to plan is planning to fail.
The ERP system can only ever be as good as the forethought and diligence put into its selection, implementation and maintenance. Any business that relies on an ERP system must invest a great deal of attention into that system.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
