ERP disaster zone: The mostly costly failures of the past decade Enterprise resource planning projects are notoriously difficult to get right. While everyone wants the latest tech, that is less than half the challenge, and whether organisations choose Oracle, SAP, Infor, or IFS, they face a dilemma. Either they customise the software to fit their processes, creating a tangled mess of wares …
On a smaller scale a former employer dictated that we would replace our existing ERP systems with SAP. A Dutch sister company would be the pilot (despite the fact they had a bespoke warehouse system that they insisted on replicating and didn't do manufacturing which we would need). The last I heard the bill had exceeded EUR3M for customisations alone and was still climbing. A change in corporate structure meant the UK company were no longer part of the same division and could carry on with our existing system which wasn't perfect but worked.
Take an off-the-shelf solution and you're going to customize it. Sorry, no company is going to change its structure to fit a program, whatever the promises are.
Make your own ERP and you foot the entire bill all the way, plus whatever changes need to be made to fit the changes of the company. And you have no support from anyone, you have to make do with the resources you have in-house. Good for whoever is in charge of the programming, not so good for the company in the long run.
I can't see that there's a good choice there. Maybe it's better to go with individual products that do one thing well, and arrange for software to tie them loosely together. Might seem clunky, but it is modular so easier and cheaper to deal with. Maybe.
" the point of ERP is so you draw from best practices"
Except that there are hundreds of different industry types, and even within those types, what many firms do can be subtly different. Buying off-the-shelf ERP components and then customising them can work if your business isn't that different, but if customisation level required is high, leads to disaster. If your business is more particular, better develop your own software in-house (of course that leads to other problems)
I agree with whoever posted above that the best is a modular system. Even in the biggest ERPs like SAP, Oracle etc, there are modules for finance, accounting, supply chain, manufacturing, etc etc that talk to each other. No reason each of these cannot come from different suppliers, or be built in-house. Building custom interfaces, while a pain, is a lot easier than building a whole custom component or heavily customising a whole module.
Why not both?
The last place I worked at moved from Sage 500 to SAP. They took a middle approach, changing business processes to align with the defaults in SAP where it was easy and made sense, and getting customisation where the business processes couldn't be changed.
Of course, it still went wildly over budget, but the move was mandated by head office so they picked up the bill.
I was only on the periphery of the project, but I did finally get some budget to go buy a proper VM system out of it :)
'the move was mandated by head office so they picked up the bill'
No. Just no.
Head office may not have tortured the subsidiaries managers over this but extra money went out of the enterprise that could have been spent on something else. Head office did not pick up the bill - the whole enterprise did.
"Of course, it still went wildly over budget..."
all ERP systems go wildly over budget. That's not necessarily because the implementations were botched or too complex, more likely the vendors have a good idea of the real price required and know the customer would baulk if quoted the real amount. So vendors quote a low initial cost plus rate for work, knowing full well that the work required will be much more than what they are saying in their unbelievably optimistic estimate.
"Good for whoever is in charge of the programming, not so good for the company in the long run."
Citation needed. How many problems are avoided, how much spending is never even planned when you have a more-or-less fixed cost inhouse pool of expertise to draw on?
Developing something inhouse sounds bad but does have several key benefits. One is the design reflects the company's methods and organization. It is tailored to the needs of the company, A very import but overlooked benefit when done right is the business was able to set the detailed requirements and the code fulfills those requirements. A hidden benefit is the inhouse IT staff knows the code and knows what they can do to modify in the future.
Third party 'solutions' often do not fit the company's needs and no amount of 'shimming' or 'tweaking' is going to fix that problem.
Many companies don't want to have a software development department, and they can be wholly right.
Yet, there is a problem with software expectations - which is mostly unique to software. Too many expect it to allow them to work exactly in their old ways.
They are ready to accept changes in other sectors - i.e. manufacturing processes - especially when it impacts low-level white collars or blue collars, but never when the changes impact higher levels (and their assistants, who often hold a lot of real power, as they perform most of their work).
We've all read about executive wanted printed emails when email was introduced - a funny example but it does shows some people mindset, "get the new system, but I want to work as I always did"
So the very people in charge of change decisions are those most resistant to real changes.
PS: we're using a system designed two mergers and three company reorganizations ago....
A bit of column A and a bit of column B.
You look at your processes vs industry best practice (ideally the base ERP will align with these too). You decide what can be changed vs what can't and customise around that. Once you can put a price on "doing it the way we've always done it" you quickly figure out what is important.
Met a guy about 15 years ago who was an SAP consultant. After spending 10k Euros on an SAP training course, his consulting rate was 1k Euros per day. Basically, after going through the 'orientation phase' of your first project, it's full steam ahead on the gravy train. I did seriously consider it but it means dealing with accountants and management people. I shudder to think what his day rate must be now...
Back in the mid 00's I was just a lowly technical work stream lead on a CRM & ISU programme for a large UK energy company. The external R/3 functional consultant assigned by SAP UK to advise and oversee Wipro on the end to end implementation used to turn up in a Lamborghini.
He definitely knew his stuff though, despite being a bit of a twat.
Careful with turning up in a flash car - some clients can get quite pissy about that kind of thing.
My dad used to contract in construction, and he'd commute in an old Corsa. Somebody hit it when it was parked one day, and when it was in the shop getting fixed he started turning up in his Aston Martin DB9. The management on site were very, very not happy...
Went back to his Corsa once it was fixed, mind. Much cheaper to run!
On a similar note, the wife of a garage owner I knew was a social worker.
She was ordered to change her car by the management, it was an old Rolls Royce bought for less money than a new focus at the time. but it conveyed the “wrong image”.
Me I use a 30 year old BMW or a kit car depending on what I feel like on the day, but I could go out and buy a new car if inclined to without too much bother.
There are so many projects aimed at "increasing productivity" or "reduce costs" that fell short.
In one global DC I worked for, we had a very tuned HP VPO monitoring tool. Years of tuning the thresholds for this and that system lead it to be almost perfect. Only a TRUE incident would spit a warning/error. The whole teams were articulated around those in terms of procedures, habits etc ...
Then, some smart ass (promoted ever since to the rank of CIO) came with a 1+ million USD project to "do it better" to "increase productivity" of the support teams.
Consultants came, knowing nothing of the tuning, did reset everything to default, came up with some nice docs, totally off rail vs. the business and promptly fucked off once money had run out.
They basically has destroyed our tool, which so far, was permanently spitting nonsense, hundreds of times per day, killing off any productivity: false positive on-call calls, issues not noticed etc ...
Adding insult to injury, we were all ordered to fill up forms to testify we were more productive !
https://www.theregister.co.uk/2008/07/10/levis_erp_costs/
98% drop in net income thanks to introducing SAP.
... three things that I encounter:
1. People not actually knowing / aware what they are asking and what work it will entail and how far away it is from best practice / industry standards / reality. (Therefore requiring MUCH more work to implement.)
2. Lack of clear definition of the targets or that one is not committed to the targets set and keeps changing them.
3. The third reason I encounter for projects (ERP or other) to fail / get into trouble / cost overruns is because the people who set the targets that have to be fulfilled often do not even have to work with the system, which causes it's own train of trouble. They try their best, I do not doubt that, but in the end they seldomly really know what they are talking about.
Been there, did that, left before I got the T-shirt and before I got to be the scapegoat.
At my last job, one of my secondary duties was "IT guy". We were much smaller than the examples from TFA, but still counted on our MRP system pretty heavily. New general manager came in and decided we needed a system change.
I wasn't involved in the selection of the software, which was fine by me, I wasn't a primary user (I was case #3 from the above, I knew it, and I wanted to stay out of the way). It became aparent I would be the lead on implementation. I was fine with the nuts and bolts of setting up VMs, installing SQL server, etc, but then the project stalled. When the status changed from "we're researching customization options" to "AC needs to tell us how to structure inventory part numbers", I realized a double-decker bus called the MRP-express was headed my way, and powers that be were ready to push me to the pavement. Made an unexpected job offer much easier to accept.
Anon, because I'm probably still the scapegoat, just now it's because I abandoned them.
But I was at Symantec when they bought Veritas and had to get both companies on the same version of Oracle ERP. Ugh. Once the upgrade started, we had customers who bought software, but couldn't get license keys, purchase order requests disappearing in the system, headcounts disappearing and reappearing in the HR component... I repeat--ugh.
I used to work for a BigCorp multinational manufacturing firm, lets call it International Widget. 20 years ago, they were a ManMan house, and the powers that be decided on Oracle ERP after much KT analysis. The first deployment of Oracle ERP involved extensive customizations to match the corporate business process model, took at least two years longer than planned, and was really clunky and hard to use. They skipped a major release or two due to the difficulties of integrating all the customizations, and when they couldn't put it off much longer, the next major release, they reworked the company business processes to match the Oracle ERP models, and it went MUCH easier and worked MUCH better.
anon because well, yeah.
I used to sell ERP solutions as a VAR. We sold the one from that company the Moderatrix would ban if you included a dollar sign in the name and another one that was invested in by Larry Ellison back when he was screaming that cloud was just water vapor while hedging his bets with a SaaS solution that eventually got borged into the mothership. In most cases, the problems come down to:
Customer
Poorly defined process replicated into new system to continue poorly defined results.
I want the full blown best case scenario scope at the skeleton install price from that developer guy out of Chennai that responded to our RFP! (Okay! Let's just sign this document for time and materials... what's that you say? Over budget? Never heard of it, btw, here's this week's invoice)
Integrator
I gotz the certification yesterday. I can haz architect title?
What is this documentation you speak of? I'm too busy implementing our own special version of customized Ragu(tm) and Bolognese(tm) code for you.
This post has been deleted by its author
.....as when THE BUSINESS changes during the implementation. Examples:
- Centralised business decides on multiple spin-offs (not known when the ERP contract was signed)
- Business takes over (or is taken over by) another business (not known when the ERP contract was signed)
- Legislation is passed which affects core business processes (not known when the ERP contract was signed)
*
The moral of all these stories is simple -- try to make project durations shorter (say, shorter than multiple years).
*
Note that when the project takes multiple years and these unforeseen changes occur, it's not unknown for a software vendor to breath a huge sigh of relief, bank their fees, and bail out!!!! I wonder how much COMPLETELY RISK FREE profits have been booked this way.
I don't expect El Reg to investigate and itemize every ERP or related enterprise system implementation failure, but I could name another dozen or so without much effort. Twenty years ago Hershey's was one of the major dust-ups that was frequently listed, partly because its go-live happened to coincide with the Halloween ordering cycle. ERP implementation failure is even the subject of academic research "Critical Failure Factors in ERP Implementation" is one paper I have in my files. Many public sector failures don't see the light of day unless they cause monumental losses, including the "trash it and start again variety".
Capsa at the University of Cambridge was pretty big at the time. As an end user I used to hate it
It boggles the mind!
I used to subscribe to a US IT trade rag called Digital Review. In the early 00s, I, along with many other fellow IT veterans at a large firm in Canada, always enthusiastically supported change. It meant newer, bigger, faster - more fun to be had. So it had been from the Honeywell mainframe and VAX days onward. We were not accustomed to failure. We rolled our own.
Then came ERP along with the concept of the out-sourcing of some of its key elements. Where it made "sense", of course.
A few years in, the people who made the promises were in denial, and the old wise ones were thinking "I told you so." We had missed dates (years, really), skyrocketing costs, unexpected challenges, and shifting scopes, to name but some of the horrors.
Around that time, a new DR issue landed on my desk. I flipped pages to get to the cover story on ERP project success rates, and there it was. One image that pretty well summed up my thoughts about our ERP.
It was a full-page picture of a pig wearing lipstick. I forget the article title, but it had the word ERP written above the pig's head in big bold-face letters. I quickly tore out the page, and before I could stop myself, I had pinned it up on the wall in my cubicle. The most amazing thing was that no-one ever told me to take it down.
The problem is there is no universal best practice for all industries and companies.
The ERP vendors try to square the circle by selling highly configurable systems.
This introduces a second worse problem. You end up coding a system via weird
and wonderful config files effectively programming in strange and rather c**p
languages.
The other side effect is you than need "flexible" data models. Which means
a set of tables which hold the schema you actually use will all the performance hit
that that implies.
In most cases it would be cheaper and better to code a bespoke system
in a proper programing language with a proper data base schema.
True.
But PHB's never bother spending time on studying past, when they could going toward (their) bright shiny future.
I've worked for various companies who were industry leaders in their sectors.
A bespoke SW system was often a key part of that. It let them play a tighter game than their competitors. OTOH you have all the support costs of a one of a kind bespoke system and a PITA if it's badly documented and the Subject Matter Expert (or "Archie the archive as I like to think of them generically) retires or gets hit by a bus.
Here's the thing.
If you want to leverage the benefits of a standard OTS you've got to
1) Do a detailed mapping of your business processes (not just the software bits, all the peripheral stuff). How it really works.
2) What you want to keep of them and what you want to change (and to what?)
3) Map as much of that onto your chosen ERP using configuration settings (which you'll need to document and update as needed) which you should be able to transfer to later versions (because it will go end of life and you will be without support, which is one of the reasons you went for an external solution in the first place, wasn't it)
4) That leaves the nub of processes you want to retain but your chosen ERP won't handle (possibly because it was chosen for you by some PHB in an office far far away....). Now you have to write actual code, and document it to allow it to be ported when the next (inevitable) upgrade happens without fuss.
I've never done this. The reason is simple. It needs a better person than I am, leading a better team than I've ever worked with, to pull it off.
For those who are doing this I will wish you good luck.
You're going to need it.
Should just one consultant honestly warn of the cost of implementing an ERP, maybe companies would take their risk more seriously. Maybe they would plan better. Maybe they would select their software and their consultants with a better eye on the danger ahead. Maybe they would train for what they'll encounter and form strategy and tactics for countering the enemy when it attacks. (It will.)
But consultants paint the brightest, most optimistic, most unrealistic picture of something that has never happened in the history of ERP implementation and they lull their marks into buying software and services that will end up costing three to four times (if things go well) of what the mark believes it should cost.
Maybe if this happened there would be 0.125 the number of ERP projects, too. (That's about the number of projects that might actually succeed if given the truth up front.)
If you believe in unicorns, if you see heart-shaped clouds and see honey dripping from sun's rays, then, by all means, jump into your next ERP implementation and trust everything the consultant says.
If you're in recovery, value truth, realize that we live in a corrupt world with questionable marketing and sales practices, then go into every ERP decision as if you were dealing with Mephistopheles hisself. Cuz you just might be.
It's not all on "those consultants;" people choose who they ask for advice.
I've had clients ask for something and I honestly tell them "Don't do it. It doesn't work that way and you won't like the results." Sometimes we talk about their other options. Sometimes they hold on to their dream, and shop for someone else who will sell it to them.
This is not unique to IT, of course. I've had managers do the same internally. And we probably all know someone who shops for doctors who will agree with their (diagnosis/feelings/need for addictive meds).
Retired now, after 40 years in the industry. The same mistakes keep on robbing business of funds.
Lesson One - Never believe the vendor
Lesson Two - Use what you have
Lesson Three - Go to One.
I cannot get why organisations still have not understood the ERP, CRM etc. etc. will do nothing to make the business better. Only hard work and brainpower will do that.
It is unbelievable how large organisations continue to be rorted by vendors who know less about business principles than any half competent commercial organisation.
As they came THIS close to going under (they needed to Get Smart)
For large companies, ERP systems are ALWAYS going to be a failure. Common cloud apps from vendors will ALWAYS be a failure.
ALL systems should be developed in-house. WHY? The BIGGEST reason not mentioned is this:
>>>>>>>>>>>>>> IT is to be used for a STRATEGIC advantage <<<<<<<<<<<<<<<<<<<<
If EVERYONE used the same crappy ERP or cloud Application, even with customization, it does NOT give you the flexibility to run your business to succeed where others have failed. Without innovation, all other things being equal, you will be forced to compete on price, which drives margins super thin, and ANY shock to the system can put a company under quite easily.
With the exception of PAYROLL, and to extent basic accounting packages (which will still need to be fed with advanced systems), IT should give a competitive and strategic advantage and not follow others.
Let us take a few industries for example:
1) Reinsurance - insurance for insurance companies. Yes, you could go with packages built for Reinsurance, but they are VERY inflexible, and you can no longer write innovative policies without a custom system.
2) Finance - there are so many areas that custom finance will give a superior advantage in many forms of financial products.
3) Online Giants - Amazon - E-Bay - Google - all use proprietary systems and look at their success rate.
I could go on and on with the titans of industry that developed their own strategic applications in-house but it would be pages long. Maybe if you used Oracle Financials, SAP, etc for BASIC accounting GL functions it would work - but at what cost? It still is cheaper to build in-house (and not out source).
Yes and no.
One pattern has been an OTS account package fed by a bespoke LoB system that supports (at a deep level) the core business.
Accounts are well understood and the OTS package will be kept up (or should be, as it's one of the reasons you buy them) with the relevant legal requirements.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
