I don't work with SAP, but I've been working with Microsoft's ERP(Dynamics NAV/Business Central) my whole professional career(almost 5 years).

When it comes to shipping, manufacturing, HR, supply, sales, planning, quality assurance etc... every big company is going to have a million edge cases which are impossible to cover with the standard functionality of an ERP. And most importantly - hundreds, or maybe thousands of employees that have gotten used to working a certain way.

When you try to make your process fit to a standard ERP functionality you are fighting two dragons:

1) Working your way around edge cases - with the right consultants/developers this doesn't have to be a big pain.

2) Getting your employees to change the way they have been working for years, or even decades. And in addition giving them an overwhelming UI - I've never seen this work as planned. This is also probably the reason the company your mother works for had so many pains.

On the other hand, if you try to make the ERP fit to your processes, there's only one dragon you need to slay - extending the ERP's functionality.

I can only speak for Microsoft's ERP, but everything that is impossible or hard to extended within the ERP itself can easily be extended through an outside application. And by doing so, you can probably even make the employees job easier by keeping the process the same, but giving him an UI that isn't overwhelming.

That depends. I’ve seen a lot of adaptation to processes that are legitimately & measurably better in time & accuracy ignored in favor of costly customizations out of nothing more than “not created here” syndrome. If a customer doesn’t like that then an off the shelf product is the worst choice they can make unless they are prepared to hire a significant in house dev team.

Otherwise, if you have been adapting your current business processes to deal with the limitations of a legacy system first deployed in the early 80's then there's an excellent chance that at least some of those things can be done more easily in a more modern system. (Though SAP may not always be the best place for that to actually be the case).

Correct. This is the problem my company solves. We are ERP consultants/dev's who also know web development. Through the years we've made 50+ web apps to extend Microsoft's ERP, most of which can be used in most companies with similar needs with slight modifications.

And, of course you don't blindly follow a process. There's always some improvements to be made to the process before developing an app for it.

EDIT: Drastically changing workflows for employees within huge companies will ultimately almost always cost you more... It all depends on the company of course, but we have to generalize a bit.

Every. Single. Customization. You make, which makes so much sense to seemingly eagerly satisfy the user during implementation, will be a massive pain, forever, with every patch and upgrade and new functionality released by vendor in perpetuity, and will inevitably cause performance and failure issues eventually. And will only be getting more expensive and painful to maintain exponentially over many years.

Yes, you should customize erp for your very specific edge cases that you a absolutely need. But:

A) number of processes Bob from accounting or Fatima from HR believe are absolutely crucial and immutable and special and unicorn and mandatory, is way way higher than processes which actually are special and must be preserved. Personal inertia is huge. More often than not, special ways of doing things which are not your core business are an unnecessary cost, whether through erp or not.

This may seem like I'm a traditional grognard IT head who disregards users and their needs, but it's quite the opposite so let me clarify with

B) The threshold of customization at which erp no longer makes sense is in fact very very low.

If you actually, really properly are a special snowflake of a company and your convoluted hr or finance or pay processes are your key immutable competitive advantage, then don't get an erp. Other name for erp is cots, commercial off the shelf, which strongly hints as to how its meant to be used. With erp, customizations should be fought tooth and nail on every level,and that's a largely accepted industry wisdom.

I haven't, but some of my colleagues have been in the space for 20+ years.

>Every. Single. Customization. You make, which makes so much sense to seemingly eagerly satisfy the user during implementation, will be a massive pain, forever, with every patch and upgrade and new functionality released by vendor in perpetuity, and will inevitably cause performance and failure issues eventually. And will only be getting more expensive and painful to maintain exponentially over many years.

Wrong. Upgrades almost never break your customizations, because in the ERP space backwards compatibility is verry much a thing with the exception of a few extreme cases now and then. I've migrated customizations from a 2004 version of NAV to a 2022 version of Business Central - even the name of the software changed, and the language in which it is written, but the customizations were almost plug and play after running the code migration tool provided by Microsoft.

>A) number of processes Bob from accounting or Fatima from HR believe are absolutely crucial and immutable and special and unicorn and mandatory, is way way higher than processes which actually are special and must be preserved.

I never said employees wishes should be blindly followed, you still have to do the consulting part of the job...

>B) The threshold of customization at which erp no longer makes sense is in fact very very low. >If you actually, really properly are a special snowflake of a company and your convoluted hr or finance or pay processes are your key immutable competitive advantage, then don't get an erp. Other name for erp is cots, commercial off the shelf, which strongly hints as to how its meant to be used. With erp, customizations should be fought tooth and nail on every level,and that's a largely accepted industry wisdom.

Wrong. The benefit you get on the accounting side, and the all data being in one place side(reporting) outweighs almost any customization that needs to be done - because, good luck making those 2 things from scratch. And good luck living without those 2 things if you're a mid/big company.

> I don't work with SAP ..

Yeah.. that's just it. Your experience doesn't matter. Adjusting your business to fit SAP nearly as much as an unspoken requirement. It's not just a smart bit of wisdom people throw around. It's literally what you have to do if you want to have any hope of implementing SAP successfully, because it is such a colossal, messy charlie-foxtrot that there is no hope otherwise. Not even SAP's own people understand their own mess.

I think it's really a case of a self-fulfilling prophecy, of a sort. They are the biggest in the business, so people go with them, which makes them bigger, which attracts people.. and so on. It probably helps(SAP) that they also decades worth of man-hours implementing all sorts of insane business logic(like for accounting, as you mentioned, which is something you definitely don't want to get wrong) where other players are likely to be behind.

Adapting Dynamics ERP to business process is a challenge of its own, and not every company can do it. At least it's possible in Dynamics, SAP is a mess - most customers I know with SAP have to use external software and import/export for significant customization.

But then, did you really gain anything by using an ERP instead of just a dumb database, which would have worked just as well as backed for those applications?

Is this facetious, or unintentionally so? Do you mean you need to replace one in-house staff with between 3 and 5 and presumably very expensive consultants?

Where do you think the customer is going to find that army of hyper competent experienced staff ideling around their premisess waiting for the day an SAP project drops?

Overloading the customer is one of the simplest ways to make sure ít is not your fault when things most often go south.

One thing I've seen frequently is treating erp implementation as IT project. I'm a technical team member doing erp implementations for last 25 years (not sap) but I'll freely admit erp implementation is not about me or technology. It's primarily a business transformation project. You need those erp business process experts to guide and customize, AND you need thorough willingness to change your internal processes to fit the industry best practices you're buying. "successful erp project" empathically does not mean "installed it and it runs". It means thorough and detailed understanding of requirements, mapping to new processes, customization where absolutely positively necessary, substantial and organized and embraced business transformation, extensive training, and thorough testing including user acceptance testing.

If you think is erp as something you just install and life will be the same but magically better, you're gonna fail hard. Missed requirements and edge cases, and or significant internal resistance to change, are frequent challenges.

Also, because leading employees usually have no idea about the intricacies of the "old" system and think it's easily replaceable with a solution from the shelf.

We've been fed an off-the-shelf solution with modern tech like Angular and the like.

And even without the SAP burden the company is basically destroying our departament. I guess they don't care to lose us poor peasants but they're basically losing al know-how and one of the only two edges they have against competition.

I can't say I care too much at this point, but it's amazing how easy can companies destroy themselves for not caring about their employees.

The most obvious failure modes are going for the lowest bidders incentivizing them to deliver with a skeleton crew, trying to nickel and dime the budget cutting features or their scope or straight up coming at the table with no documentation of how orgs own internal processes actually work.

I know of no project failing because of sap or their consultant on its own without any of the above comorbidities.

I find it very difficult to fight for sensible defaults in a company when everybody only sees their area and has a very strong opinion about that. Only a strong force like the SAP transition can break up with those encrusted structures.

After seven years and 500 million euro spent, the project was cancelled and they went back to using their old inventory system.

So, in this case, customising SAP to fit the company's processes wasn't worth it even for a rather large company like Lidl.

If memory serves well, Liqui Molly had similar, but cheaper, experiences with Microsoft.

That is a low bar. Your "lowest bidders" should at least be able to equal that. It just has to accomplish the business processes and do so within the software. It doesn't need to be fast, intuitive or look good doing it, it just needs to do it.

Funny considering in the 80/90s SAP sales/management was known for saying that you don't adapt SAP to fit your company, you adapt the company to fit SAP. There was another company (was it Baan or JDE? I think Baan as I had too many meetings at the time with those religious fruitcakes) that said they were better than SAP because you don't need to change your processes; you change the software.

Baan still exists as Infor ERP Ln

Whether it is worth it depends a lot and is hard to say. It will certainly demotivate many employees who are used to the old way, but might lead to streamlining (partially due to software, but norendue to analysis) and more insights (with risk of then optimizing the wrong metric)

In my experience, what demotivate them is that a lot of the features in the marketing materials for these types of products are lies and they are filled with bugs. The executive who chose the product typically don't use it so they think it's a great tool. When you report major problems or workflows that makes no sense, they brush it off like it's just small details that need to be ironed out in the future because aren't the ones dealing directly with them on a daily basis.

The exec get sold on an AI feature and it's the intern who is then forced to deal with a search bar that take 2 minutes instead of 0.5s to search and gives you vastly inferior results.

It's been one year of this BS and it's clear no one cares or listens to our complains, so we just pretend to work and execs are angry because of KPIs, clients complain, etc.

But seriously, we can't do it anymore. Their idea is that with this new software everything will be taken care automatically and so they won't have to educate employees anymore and technical knowledge will no longer be needed, and we'll become you regular brainless contact center but magically better because we have such good software!

I hope I can get out soon.

By the way, edge cases, if if they work in a legacy system, are a thing to get rid of during a SAP / ERP implementation. Most people see ERP systems as IT projects and fail. ERP projects are at least as much business reengineering projects as they are IT projects.

Second part is actually correct - you have to change your way into how SAP works, its just a typical crappy legacy rigid mammoth software that requires overpriced army of devs/analysts, not much more. If it would be marketed that way, they would go bankrupt very quickly because no company willingly wants to do that, and certainly not at that cost.

But anytime some c-suite manager picks up SAP, you can be sure there were some nice meetings done in ultra luxurious places and more often than not some bribes went that way, in one form or another. This is the way, if your system sucks so much it destroys companies

The drive to ERP is understandable. The issue is that homegrown solutions suck too - most businesses aren't IT companies and can't properly maintain a custom solutions. Using a third party makes sense, and allows you to hire outside devs with experience. SAP is however usually not the best solution...

Anyone who's ever worked with ERP software knows the entire system pushes you to do the reverse - adapt the business to the ERP. Going against that flow is possible, but expensive. This is especially the case with SAP which was always even more difficult and expensive to customize.

Unfortunately I don't think this is realistic scenario because when you start a company you probably don't have time/money or need for SAP or anything like that.

Here are things upper management doesn't consider:

* Picking the same ERP solution everyone else in your industry uses means you have zero competitive advantage now. Homegrown solutions with teams staffed to run them could give you an advantage.

* You need to pay expensive consultants to do things with ERP. If you want any customizations they will be a bottleneck for all future updates, possibly having to bring in expensive consultants every time you need to upgrade.

* The culture shift for employees is usually negative across the board. The IT people supporting it, the end users inside the company, basically the choice implies that management doesn't value its people or their thoughts on how to do their work.

* Vendor lock in. Switching from one ERP to another isn't likely to happen. They can raise their licensing/cloud costs when contracts are up and your company is likely stuck.

It would be like interacting with other people who knew based on the average of everyone on Earth as opposed to dealing with the person you knew based on their own personality.

But it's easy to manage based on these kinds of broad generalities and, as the saying at least once went, no one gets fired for choosing IBM.

"Successfully lead SAP implementation bla bla bla saving bla bla bla streamlining bla bla bla"

The pointy-haired bosses of our nightmares are real.

I used to be a consultant for a big non-SAP workflow product. Had a long time employee quit specifically because of how bad the product was. That was not an easy thing to explain away.

The complexity of the task is eventually discovered in production.

I’m amazed that this is what happens every. Single. Time. And yet we plow ahead with this kind of projects like we have no idea it’s the usual outcome.

A couple years and millions over budget later, we rediscover this axiom. I really don’t get it. And try to warn about this, you’re labeled as not a team player or whatever and paint crosshairs on your back for the next round of layoffs. It’s just soul sucking.

The details about the day-to-day operations disappear quickly as you move up the hierarchy.

My boss recently had a meeting with a large customer of us, we deliver a product used heavily by one of their departments. Here's roughly how that went down:

My boss: "Well, what about when you do orders of type X?"

Manager: "Oh we don't do those"

My boss: "Really?"

My boss brings up the order list and filters on type X, finds at least one entered each day by user ABC

Manager: "Oh... so that's what she does"

So that information was lost in just one level.

This is why we try our best to get the actual users involved when discussing requirements with a customer. I don't think I've ever experienced a project where at least one of the users haven't brought up some edge case the manager wasn't aware of or had completely forgotten.

On the flip side, the projects where the users are left out of it until it goes live never goes well. We'll get it fixed eventually, but there's always pain for far longer than necessary.

Trying to do those two is a clear signal of incompetence.

General Marshall, Eisenhower's superior also delegated broadly, while making key decisions as to the timing of the invasion, which units would be involved, and making sure all the disparate organizations involved were used to the best effect. Again, delegating broadly, as a good commander should.

This goes on and on up to Roosevelt himself, the Commander in Chief at the time. Does he know jack about the tide tables on Omaha beach? The range of a German 105mm howitzer? Of course not. Yet he clearly mandated the important decisions.

All three of these leaders were clearly EXTREMELY competent.

Most of my work right now is trying to eke information out of customers about their ERP system so we can get it connected via EDI or to their Ecommerce system (shopify whatever).

So we go live, with a whole process revolving how payments are accepted - and then within an hour there's a problem. Nobody mentioned that certain customers have a different payment workflow!

Back to the drawing board, except we're already live.

This happens again and again.

This is what big corp suppliers like IBM, Oracle or SAP thrive on. CEOs and executives not actually knowing the intricacies of their company, and underestimating the risk of creating a very expensive second system effect.

The fact is the higher you go the concerns separate. I think the army motto was "go 2 levels up". You're a grunt, you need to know what your platoon and your company are up too and what the goals are so that if you can't follow the plan directly, you can still hit the objective. This is good because no plan army or business, survives reality without changing.

In the same way, you can only go so many levels down.

The short answer is that a sales guy in a nice suit took some execs out for steaks and more than a couple cocktails.

The long answer is that management, these days, is trained to outsource everything while still being clueless about what the people they're replacing actually do.

If the software needs to change due to industry changes or regulations or something like that, it will probably be a lot more expensive to implement it yourself compared to using an off-the-shelf tool developed by a company who's sole purpose it is to respond to those kind of changes.

If your company is small or at least in a field with lots of competition sure. I work in a >100person company that encounters loads of regulatory changes due to food safety and lots of international trade and 2 people developing is good enough. The part doing the accounting and such is largely outsourced to an ERP but is honestly simpler yet just as costly if not more.

What's more things go wrong. That's a given and the absolute best way to deal with it is with someone as close to the processes as possible. you don't want to be calling vendors that are generally absent to see in which part the software lies. Even for industrial equipment that is a lot more single process it is kind of accepted that we people on the ground need to know a good bunch to troubleshoot ourselves rather than paying someone to come over. After all if we wait for that we get a bottleneck that has dozens of people twiddling their thumbs.

It’s infuriating as anybody below senior management can see right through it

This happens because the people working below senior management are usually not slick talkers and many people in senior management do not understand IT. So a savvy salesman who knows the right words can convince the guys at the top to do what he (its almost always a he) says.

Is this the story of every migration, every rewrite though?

A system completely broken forever is something only the upper management can create.

The real problems are

1) organization staff on the implementation who don’t actually know enough edge cases etc. This can be through poor requirements gathering ir because the power users are considered too important to take off their normal work and the company is too cheap to hire enough temp staffing to cover their absence.

2) A bad “fit-gap” analysis the maps old system functions to the new system to find the gaps. This is the vendor/partner (consultants) job so that’s on them. Failing here sets the project up for failure or major cost overruns or just years of people pissed if that they can’t do what they need to do. It also breeds shadow systems and work arounds that make knowledge transfer after staff departures vastly more difficult.

3) vendor/consultants looking to maximize $$ by either sandbagging hours of work with unnecessary things like customizations that are just not needed. I’ve seen plenty of examples where vanilla functionality is much faster than the old system but “that’s not how we do it here” . The vendor doesn’t care to push back because they’re getting paid for the extra work, and when the customer runs out if its 1,000 hour block of custom dev time and still has essential work undone the customer has no choice but to pay up or suffer. Meanwhile the vendor has every email and change request order signed off in their records where the customer approved the work so they just shrug their shoulders.

4) A general unwillingness by the customer to actually pay the $ required to do these things right. There seems to be a sense in higher level leadership that “it’s software, how hard is it to install software?” and have no clue and don’t care to hear it until the sky is falling that there’s a lot more to it.

There’s more too, but I’ve been on a few of these and never seen one that didn’t include some combination of the above. They absolutely can go smoothly with a minimal amount of the above but it takes real work and a dedicated procurement & vetting process just to find the right outside implementation partner (going with the vendor itself is sometimes okay, sometime not. I wouldn’t touch Oracle Consulting ever ever.)

Even then it will not always be as smooth as using a legacy erp with roots in the early 80’s that has been customized for decades. But that sort of tech debt is massive. New functionality can be a nightmare, causing more tech debt and raising maintenance costs non linearly. If it needs regular updates for things like federal compliance (tax systems or other regulated areas) a vendor might when it finally EOL’s a system it first released before you were born still provide those updates to remaining customers of their legacy product to give extra time to transition but then you need to either role your own dev team to do it or pay outside consultants to do so: Retirees from places like SAP often make a nice bit of extra income doing dev work like this.

TLDR: Too late, you already read this far.

And what is the take-home-message here? Should they have stayed with their (admittedly not good enough) internally developed system? Should they have gone for an Oracle solution (plagued with its own set of anecdotal catastrophes)?

Often times it's very difficult to correctly specify a system. This is one of the problems with lock files and why some people have gone over to docker for development.

IMO, the people to blame are management, who needed to appropriately staff the transition for enough time to get it right.

> Should they have stayed with their (admittedly not good enough) internally developed system?

What evidence is there that it wasn't good enough? Sometimes management gets sold on a "better" system, only to find out that it isn't actually better.