Mistakes were made: ERP screwups
tedium.co
tedium.co
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.
I loved the rigour of the thing, I trusted it.
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.
This is like, 3 factoids from wikipedia stretched out with filler sentences.
Feel proud that my BS detector is apparently functioning well!
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?"
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 recently also wrote my thoughts on what ERP is. Maybe its interesting to someone. https://www.integrated.ee/posts/the-erp-software/
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
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?
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.
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.
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.
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.
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?
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.
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.
So I will add this tip. Keep your user roles simple. Start with the principle of 'least privilege'. It is so much easier to add access than remove it.
And see if you can keep some of the key minimum editing in or your users will hate you forever. I've heard comments 5 YEARS later about this issue.
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.
The implementation was painful enough even so.
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.
> Go standard, don't customise, work the way the ERP wants
I've heard this quite a few times now and I think it's going to be critical. I'm keen to push for this as much as I can from our integration side.
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.
If you can still talk about it with a straight face afterwards, leave and go to work as an ERP implementation consultant!
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.
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.
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...
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.
You need to work the way your ERP works.
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.
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.
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.
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".
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.
Their real killer though was posting multi step financial transactions without issuing db transactions, so they should fail and leave you unbalanced!
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
https://www.zdnet.com/article/levi-strauss-sap-rollout-subst...
https://www.computerworld.com/article/2536212/waste-manageme...
Both $100MM+ boondoggles.
1: https://www.canadianbusiness.com/the-last-days-of-target-can...
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.
(1) ERP projects are typically large by their very nature
(2) SAP projects are always built in waterfall fashion
Seems like Fred Brooks’ original diagnosis would suffice here.
A minor correction: Xerox shut down its XDS computer division and sold it off to Honeywell in 1975, not 1971.