I recently got a job in the ERP industry(SAP), though my purpose is essentially to do stuff that is not SAP related.
I don't think it should surprise anyone that SAP makes mistakes and/or that ERP systems are hard to implement. SAP in particular is an absolute monstrosity. I don't just mean in terms of size either. I can't help but think about that Nietzsche quote about the abyss.
SAPs systems should become textbook examples of tech debt left to accumulate, of what happens when systems are allowed to grow in whatever direction is useful at the time without any thought for the future or proper design.
This isn't very surprising either since I can't imagine that there is any group of human beings on Earth that is capable of understanding SAPs systems to the point where they could extend it safely.
SAP also takes the NIH syndrome and makes it a core value. Everything they make is worse than that other technology that accomplishes the same. See UI5 - it's like they traveled back in time and hired a CS freshman in the late 90s to develop it.
When they don't have the expertise to create a copy from scratch, they just use the competitors' solutions and wrap that in their own marketing. They want you to only use SAP stuff.
The figures mentioned in the article about how important SAP is to the world's economy and logistics should scare the living shit out of anyone.
You are conflating SAP the company with SAP the ERP with SAP the NetWeaver/ABAP platform.
From my experience the actual platform, while certainly showing its age, is surprisingly well designed and still very much relevant, despite SAP the company doing its best to replace it with something “modern”/“nosql”/“bigdata”/buzzword-of-the-day. I think that it would do good to many web-oriented developers to study how SAP/ABAP works, because it follows the web-style request/response + background tasks architecture since it’s inception. One interesting thing is that the low-level network protocol used by NetWeaver is ugly undocumented binary thing that you are supposed to use through binary blob, but API of said binary blob has very much the “POST random JSON somewhere and get JSON back” feeling.
For the ERP itself there are many people downthread saying exactly same thing: the ERP works and is well thought-out. And almost always breaks horribly when you start to customize it to match your random ad-hoc business processes.
Companies adopting ERP (almost) invariably overestimate the costs of bringing their business processes in line with the software and underestimate the costs of bringing the software in line with their business processes.
On the other hand SAP is still by far my favourite ERP as a finance user. Interfaces that look like the green-screen dumb-terminals of the past are fantastically productive for data entry. Tab tab F9
Haha - so true. The first versions of some of the financial packages built on salesforce and elsewhere - so SLOW. Click, wait, dropdown -> wait for it to populate with the 1,500 items when devs probably only tested with 5 etc etc, then click, wait, click, wait. All much better now of course, but the early years were terrible.
PC based POS systems in India are apparently DOS or Foxpro apps on modern Windows. Tally, ERP giant, has an interface from 1995. That's how they remained productive while the world regressed to the mouse.
I'm not usually one to complain about the quality of an article, but this one seemed to be almost completely devoid of actual content. I was hoping for some actual analysis of why the projects mentioned failed, and instead didn't really get anything more than a brief explanation of what ERP and SAP are, and the fact they sometimes don't work out.
To be fair, the site that published the story is called "Tedium", their tagline is "the dull side of the internet", and at the end of the story it says "Your time was just wasted by Andrew Egan".
So they are completely upfront about it, and they deliver what they promise.
I don't think I've ever heard of an ERP implementation that wasn't an absolute clusterfuck. My impression is that while most folks from the integrators know their segment of the product pretty well, they don't have deep technical skills in a general sense or know much about other modules of the product. Also that the salespeople know almost nothing about the product and promise that it can do things it cannot. The customer eventually figures this out and ends up ripping out and re-implement tools from other vendors.
It's a common joke for senior technology leaders at industrial companies to ask eachother "so what was the first ERP implementation you got fired for?"
I find it impossible to believe that an ERP implementation can ever "go smoothly".
At best, even if the system does what it does perfectly, it's still a classic "diffusion of innovation" (1) problem where you have multiple stakeholders with wildly varying levels of acceptance. This is always challenging. As those of you who make a living at this stuff recommend, it's better to go 100% with the ERP's way and not customize. Well, that can be extremely difficult or impossible in an environment filled with stubborn beancounter/battle-axe personalities.
Most importantly, however, the people who make the purchasing and sign-off decisions ARE NOT the ones who use the thing. There are going to be problems and those problems will not usually bubble back up to the consultant/vendor. People will just have their noses pushed to the grindstone until the job gets done-- never mind the tedium, never mind the countless little mistakes. New people don't get trained, they just get put in front of the the thing to hunt and peck through it, sometimes with the assistance of a surly veteran of the system, sometimes with no one to help them. There are thousands upon thousands of people sitting in cubicles right now using Oracle EBS with it's horrible grey java applet UI and ridiculous inscrutable query functionality. They've been sitting there suffering it since the 90's. Who listens to their screams? Not Oracle, not exec that bought the thing! Or maybe they're silent and they've resigned themselves to their fate?
> I find it impossible to believe that an ERP implementation can ever "go smoothly".
ERP implementations are like kitchen remodels. Even when they go mostly right, you hate the people doing the work because they've messed up the thing that's at the center of your home, made you eat take-out for weeks, and dust has gone everywhere.
My clients are all ripping that crap out because nobody uses them correctly anyway. Most of the data in those systems is so error-ridden they're almost dangerous to use. Newer cloud-based systems offer a much more intuitive UI, which ultimately reduces bad data.
Oracle and SAP are basically bad words at this point: you don't say them if you want to get hired.
This is not necessarily true. I find accounts people who have grown up with these systems find Netsuite (a cloud system) slow, cumbersome and unintuitive. Fast repetitive data entry always seems faster in desktop clients. We are talking about professional full- time users, the initial easier learning curve soon loses its advantage once you have learnt the keystrokes.
As for data integrity, I worked in very large SAP implementations without data integrity issues despite thousands of users. I have worked with cloud systems that are full of rubbish.
I have been on one that was pretty flawless. SAP at the time, with full costing/ manufacturing, multi-currency, multi- country. I should write a blog about that, shouldn't I? I only recall two minor faults.
I been on the system implementor side of the ERP for long time and done many ERP projects(SAP). I have also never seen ERP implementation that has gone smoothly and everybody involed has been 100% happy. I think implementing ERP is 98% change management project and 2% IT project or something like that.
On the tech strategy side, we're moving everyone we can off of traditional ERPs and into cloud-based systems. Salesforce is largely taking their place as the CRM, with purpose-built solutions (often leveraging cloud-based ML models) for downstream functions. All the consulting companies have process maps, which are honestly where most of the value of traditional ERP comes in.
TCO factoring in implementation costs is a fraction of a traditional ERP and is far easier to keep up to date. Most ERP implementations still have a lag of a month or so before data is consistent.
Cloud ERPs stay up to day whether you are ready for the change or not, it is not all rosy when they break important things at critical times of year. Traditional ERPs often don't get upgraded because there is no need. It is simply not worth the testing for the new 'features'. Lots of managers value the stability.
TCO is certainly not necessarily less, it is common for a company to move onto an ERP and stick with it for a decade or so. One off licensing can be much cheaper over this period than some cloud systems. I saw a system where TCO of was cheaper with the trad system after only 4 years.
Cloud based ML models are a bit buzz-wordy for my tastes
> "so what was the first ERP implementation you got fired for?"
At my last job we underwent a transition from one ERP to another. Halfway through it my boss resigned and we got somebody new, mostly on the basis of his experience doing the same at another company. I heard a rumor later that this other company had nearly gone bankrupt because of the roughness of their transition. Things weren't looking good for ours either when I left.
Having been through a few ERP projects (on the buying side) I'd say the scale runs from 'painful' to 'disastrous'.
One large ERP project I worked on barely made it past the kick off meeting.... a number of us escalated that we were not happy with the implementation partner so our boss (bravely) recommended that the entire project get canned - which it did.
I’m a software engineer and likely to be involved in implementing an ERP at the company I work for.
Ignoring whether or not we should (we’ll put a lot of thought into this), does anyone have any tips on what to do or avoid to make a project like this a success?
I have spent a lot of my career fixing botched implementations. And I have seen it go perfectly...
Write your requirements for the system in plain English bullet points. Give this to vendors.
Write a plan of what you would like to see on the demo. Btw you want to see the boring stuff, not the colourful charts. Book a whole day. Take a person from purchasing, accounts, sales. Get them to create a sku and a supplier, get them to buy it. Get them to receipt it, get them to show the accountant how that affected the ledgers. Move it sell it, collect the cash etc. Now you know something about whether it will fit and whether you rate the vendor.
Could the company afford it costing twice what you planned? If not then maybe ERP is not for you.
You need a test system.
Allocate a lead person for every department. Let's call them the power user.
At key check points the vendor should want you to do testing. Write a test plan for end to end transactions like my demo example. Get your power users to do the test, this gives you buy-in, sign off and critically, job specific user training.
Allocate a huge sum of money for user training. Trainers are expensive. Job specific training is the only thing of value. There are often several ways to do something, only train in the one you have chosen.
The trainers need to be on-site for all of go-live week. Budget for this.
Don't train too early
Go standard, don't customise, work the way the ERP wants
On a phone but this feels like it would make a blog post!
My one addition -> focus not on the new things the system will do for you (which is what the bosses are into) but focus on what will change / be lost compared to the system you are using.
Oh, we can't edit transactions anymore ever? OUCH. Everyone edits all the time.
People should not be able to edit transactions. Mistakes should be revised with a separate (correcting) transaction, for auditing and integrity purposes.
I don't think you've worked with ERPs or auditors. This is how Netsuite and Oracle actually work, and the two combined own more than half of the ERP market.
The time for editing a transaction is before it gets committed to the ledger. In Netsuite, this is accomplished by requiring (or allowing businesses to set a requirement) for entries to be reviewed and approved before posting.
Having the transaction log lets auditors audit the process by which the company generates its financials, and to identify where mistakes were made (if any). It's invaluable to both auditors and their clients, and its saves thousands of man-hours to be able to do this.
ERPs that allow editing maintain a transaction log of edits.
What users like about editing is they can run reporting for LOB's, then edit based on feedback / coding / miscoding, then rerun reports that are clean from a detail perspective without 100's of in/out offsetting entries you get when folks have to post reversing entries to back out errors. It's actually easier to review for correctness if you don't have to wade through 100's of junk entries that are reversed out.
Different systems allow edits in different ways. Some are journals under the hood with the initial and reversing entry marked to hide visibility for non audit situations. Others maintain a log of edits, the date and time and items edited.
All of this can be turned off at a permission level. Generally no line staff can edit, and closing a period to all edits is up at the top. And even when users can edit, they are always locked out as periods close.
Yes - auditors do flip out if you edit into a closed period (understandably because they have to re-audit it). Users have gotten that confused with auditors not liking changes in periods that are not closed - actually - auditors want users to prepare the most accurate financials possible to submit in as simple a format as possible. Editing often allows that.
Anyways, netsuite allows users to delete reversing journals from the original entry, oracle allows editing GL distributions on a posted entry (and uses an audit log for this) because if you had to deal only with reversing entries to fix stuff or had to reverse reversing entries to fix stuff it would drive everyone crazy.
Years ago I sat through presentations by three or so consulting companies proposing to manage an implementation of Peoplesoft. At the end, I reviewed the notes, and found that all of them essentially said, "We're going to fit your processes in Peoplesoft's way of doing things."
You want to make an ERP vendor (better: the ERP implementation consultants) sales rep nearly slip into a coma thinking about the giant boat they're going to buy with the commission check? Tell them "we're a special snowflake company with our own magical business processes, and we need you to adapt your software to our business. Because we know more about business than you."
You probably don't. And even if you do, adapting your business processes to how the ERP does it will probably make things like inter-operating with other vendors and managing compliance much easier.
Try to adapt the business processes to the ERP, instead of adapting the ERP to the custom business processes.
While I don't have hard data on this (and it would be hard to establish causality anyway), most of the ERP implementation failures I've witnessed and know about stem from line of business people who firmly believe their company's processes - e.g. collection, billing, etc - are very special and unique, when it is very rarely the case; and when it is, it shouldn't be, the process is likely overly complex due to inertia or lack of will/skills to improve or just legacy. Then, the customizations that need to be implemented to support the "special and unique processes" are so complex that the project's schedule and budget inevitably explode...
ERP implementations could actually be seen as a great opportunity to revisit, optimize and document current processes before the ERP is implemented...
I've been working in this field for nearly 15 years, and what you said is the exact opposite of reality, in my experience.
Number one rule of change management is: keep the number and amount of changes to a minimum. Successful projects involve changing only one thing at a time: medium (where), process (how) or goal/mission (why). If you find that the process is not optimal, or maybe even total nonsense, optimizing/fixing that needs to be a separate, pre-requisite project that is started and finished before you even start to think about the software project.
If that's not an option, then we can talk about the number two rule: it is much, much harder to get people — especially large groups of people — to change the way they do things, than to implement software to make it fit the way those people are used to operating, no matter how dumb and convoluted their process is. The reason is simple: software is predictable and does not have an agenda. In contrast, people are unpredictable, and each has their own agenda.
All I can say is that trying to force this is, by a large margin, the primary reason why major software projects fail. Software is meant to aid, not dictate, how people work.
You don't have to take my word for it. Just look at the industry. Companies like Salesforce have become enormously successful because their products are configurable and customizable to a crazy extent, and you can make them fit into virtually any business process.
In the case of SAP, the whole point of it is to dictate how your business should work for core undifferentiated processes. You’re buying the software BECAUSE it has business processes baked into it.
For core competencies where you do something differently from everyone else competitively, then SAP really has limited value except as a point of integration. Though I have seen some companies build entirely custom processes in ABAP for techno-religious reasons.
I view large software packages like ERP systems as different from a tool. You're adopting the metaphors of the system. Sometimes those metaphors are flexible enough to accommodate some of the nuance of the origination you're in, but sometimes you strain them too much or more likely misunderstand what the system is really doing.
People who advocate for letting the ERP dictate the rules are using the phrase as a shorthand for, "If you want to customize the hell out of it you probably shouldn't use it".
Agreed. If the ERP is not customizable to your company, then the employees will find ways to work outside of the ERP.
Then you end up with teams having their own Dropbox and a bunch of custom Excel templates. Worse yet, employees waste 20-30% of their time manually converting their custom process into the ERP.
Then if a key employee leaves, suddenly people wonder why the ERP isn’t correctly working anymore, without realizing that person was the glue, binding the actual custom process with the mandated ERP.
My experience is that customisation gets turned off eventually, it always breaks something. Either that or it just doesn't get used. Companies are much more similar than they would like to admit. If an ERP is not going to work for you 95% out-of-the-box you should probably find something with a better fit.
I totally agree. Main mistake is customizing the ERP to the company. I also noticed that what usually goes smoothly is the accounting. I believe that the reason for that is that accounting - at least in italy - is a quite standardized process and rarely companies have a special kind of accounting, so there's no need to customize it and screw it up.
That’s probably because accounting typically gets “massaged” later on with systems that are more focused on specific tasks (consolidation, reporting, analytics etc). I work in that space... numbers are typically extracted from SAP as soon as possible then handled elsewhere in whichever tool actual accountants prefer (well, all accountants would rather do everything in Excel, if they could, but beyond that they do have preferences. Sometimes the preference is whatever their boss decides to use while on a golf course with the vendor, but hey, whatchagonnado).
There are two types of companies where ERP implementations go well.
Type 1: Companies with rock solid documentation for completely defined and logical processes and procedures. Said documentation is given to vendor and implemented. Success!
Type 2: Companies that acknowledge that all existing processes are stupid and/or wrong. Admit their failings, and implement the vendors default system 100% - changing to match the vendor way.
Everyone else is a delicate snowflake with processes that cannot possible change, and they pay through the nose to hammer the vendors software into submission. Was with a fortune 300 company that spent $90 million on business process redesign around the development of a new ERP system. Killed the project after two years when the first manufacturing plant to start using it pointed out how it was fundamentally broken and would slow production by 30%. Everyone associated with the program was fired.
I cannot agree with this comment more! If your org is not a type 1 or type 2, don't roll out an ERP change. Get to 1 or 2, then do it. You're just asking for pain and will lose a lot of great employees who refuse to go through that pain with your org.
I maintained a home-grown corporate ERP for ten years.
The most important takeaway from that job applies universally. Business software must reflect business processes. If there are no processes, how do you know that your software is going to enable people to do their jobs?
Every business unit, every department, everything everywhere needs business processes that are documented. Those documents need to be maintained as the processes naturally change to reflect changing business needs. Those process changes need to be reflected in the software you're going to be working with.
If your company does not have the corporate will to establish and maintain processes and back the steps needed to keep those processes in step with reality, then any attempt to establish an ERP - whether homegrown or adopted from a vendor - will fail. Likewise, trying to maintain an existing ERP without corporate backing for process management can be incredibly painful.
Directly related, go with a vendor if you possibly can. As others have said, your business processes are usually not unique. There are adequate SaaS and FLOSS-with-support/FLOSS-with-premium-bits options available, and you as the implementer should give them a huge amount of weight compared to huge monolithic scary things like SAP.
1. The ERP software is exactly the same for everyone, but some companies thrive on it, some companies go broke on it. You and your partners are the difference.
2. Ideally your business will use commodity software for things that aren't a competitive advantage (e.g. general ledger), and custom software where you need an edge. Choose carefully.
3. If you choose COTS (commercial off the shelf software) understand how the vendor makes money from you and what you are willing to pay for. They want a constant stream of maintenance money from you, plus some discounted licenses. They will want you to upgrade regularly. Look ahead and think about how often you want to upgrade.
4. Powerpoints always work great. Actual software, not so much. Don't trust presentations.
5. A lot of ERP consultants live inside the bubble. Try to find some that understand mainstream tech and aren't zealots.
Some management-type probably told the end users it will make their life easier and they are going to want you to include new features from day one. Do not do this. It will kill you.
Like most everyone else said, it’s very important that you adapt the business processes to the software. That’s your first goal. Your second is to go-live with something that is embarrassingly bare-bones.
Once you’re live you should start to hold meetings about what to enhance but don’t make any big changes yet. Give your users some minor cosmetic changes or very low hanging fruit while the system proves itself.
Once you’ve been live a quarter or two—ideally the end of a fiscal year—then you can go to town making substantive changes.
How do you draw the line with this? Embarrassing that nobody can use it yet but at least there's momentum? Or embarrassing that it consolidated 3 things but everything else is still done by hand (Excel)?
For e-commerce, the needs seem to grow exponentially for the following questions:
1. What are my gross sales?
2. What are my refunds?
3. What are my net sales?
4. What are my product margins including landed & fixed cost?
This seems to be the barebones to be useful, or to convince people to go through all the trouble to even get started.
In between all of that you discover the real work. Some of your orders are gratis (PR marketing), so they need to post to a different subledger. Some orders use gift cards, and now you've opened the can of worms around deferred revenue. Some of those gift cards weren't backed by cash transactions, but marketing used the system that way to apply discounts.
You start doing backorders. Revenue can't be recognized until a product is delivered, but you only know when it was placed or shipped. You use three different shipping providers. One is a same-day provider that emails invoices.
Oh yeah, you also do "Try Before You Buy" and have inventory in customers hands before you've charged a payment provider (only auth'd). Now you've got an accounting scenario that requires a consultant.
Inventory becomes important. Suddenly you go from simple beginning/end of period (week/month) balances to purchase orders, receipt of goods, and 3PL/EDI integrations. Invoices are in EUR and entered that way, so now forex is needed.
Millions of dollars of inventory can be on the move from factory to warehouse, so now you need to account for that. Logistics team (if you have one) needs to do data entry when things ex-factory.
And of course to even get to complain about that you first need to convince someone to enter purchase orders and invoices in at a SKU level, and train them how to lookup HS codes for tariffs. Enter landed cost and another can of worms.
It feels like Alice in Wonderland, and things just get more batshit crazy complex the further you go. And of course
- Make sure business stakeholders have realistic expectations about deployment, data migration, cost of working in parallel if another system exists, etc
- stay away from customizations when possible. Each ERP comes with its own way of doing things. It's sometimes best to adjust the business to the ERP than the other way around :)
To echo this point: in my experience, a lot of businesses seem to believe that their internal processes are unique for a reason and offer some competitive advantage instead of being that way because somebody made a decision years ago and that decision stuck.
The more you customize your ERP, the worse off you are. The fastest, cheapest code is the code that's not written in the first place. The maintenance cost and difficulty upgrading down the road are many multiples of the sunk cost.
My company paid over the years over 1 billion dollars to SAP and the amount is increasing as the time goes by. What I learned in ~ 6 years in the IT areas using SAP is that the quality of the design and the quality of the implementation are critical for success, while a very strict change management process can keep it alive. Mediocre consultants doing the implementation are one of the biggest problem; SAP is not that hard, but definitely not simple, a few good architects are critical, getting unqualified consultants by the dozen is bad and moving code to production without very thorogh testing will kill it (no CI/CD, it's not a game to play it with bug fixes coming on a daily basis).
I'd recommend not getting involved in the 'technology' used to customize ERP products - this tend to be 'eccentric' at best. Personally I'd try and stay on the right side of a sensible API or database structure if you can find one.
don't make a table called Transactions that everything needs to go through to balance. It will create a bottleneck that slows _everything_ down (I'm looking at you Axapta/Dynamics AX - at least older versions, dunno if they ever fixed it).
I found this article super-difficult to read (due to the weird layout), but as far as I can tell they didn't mention Levi Strauss & Co and Waste Management, which is weirder than the layout.
Note to self: in this article, “ERP” means “Enterprise a Resource Planning” but uses it as a synonym for “SAP”. There was no Erotic Role Play involved.
One thing that rings true in both worlds is that any system should be exactly as large and complicated as it absolutely needs to be, but no more.
The article's actual title is "sMistakes [sic] Were Made". I can't tell if it is trying to be ironic or if a mistake was made. The article's URL has no extra s: "mistakes-were-made".
I don't think it should surprise anyone that SAP makes mistakes and/or that ERP systems are hard to implement. SAP in particular is an absolute monstrosity. I don't just mean in terms of size either. I can't help but think about that Nietzsche quote about the abyss.
SAPs systems should become textbook examples of tech debt left to accumulate, of what happens when systems are allowed to grow in whatever direction is useful at the time without any thought for the future or proper design. This isn't very surprising either since I can't imagine that there is any group of human beings on Earth that is capable of understanding SAPs systems to the point where they could extend it safely.
SAP also takes the NIH syndrome and makes it a core value. Everything they make is worse than that other technology that accomplishes the same. See UI5 - it's like they traveled back in time and hired a CS freshman in the late 90s to develop it.
When they don't have the expertise to create a copy from scratch, they just use the competitors' solutions and wrap that in their own marketing. They want you to only use SAP stuff.
The figures mentioned in the article about how important SAP is to the world's economy and logistics should scare the living shit out of anyone.