> If you are getting into SAP and "adapting it to your needs" then you will almost certainly fail.
This is a tricky topic. If you're getting into SAP and you're not adapting it to your needs, you're almost certainly doing something wrong.
The trick is that it _has_ to be a "meet in the middle" kind of situation, where SAP wants to be used in a certain fashion, but also allows a certain amount of leeway — any non-trivial implementation project will involve both tweaking the knobs SAP provides to fit the customer, and developing bespoke components for those scenarios that SAP either doesn't cover at all, or doesn't handle the way you'd like.
Absolutely. The bar we always tried to hit was whether the process we were being asked to change was represented a fundamental way in which this company was intentionally different from other large companies, or whether it was just the way it was before they saw what the SAP version looked like.
90% of back-office stuff is exactly the same between very large companies no matter the industry or history, but that is very hard to get across to the career accounting manager who designed those processes and now is having SAP shoved down their throats.
Secretly, I always suspected that one reason for bringing in SAP was that the senior executives recognized how inefficient their backoffice was but weren't willing to force huge process changes and create ill-will for barely marginal benefits, so they hired SAP to come in and be the bad guy to argue about it for them. Then they can say "Yeah man, SAP sucks, soooo inflexible, I argued against it but what are you gonna do, changing it is really expensive, I guess we'll just have to do it their way" and message boards fill up with complaints about how inflexible and expensive SAP is. Funny how that works!
> Then they can say "Yeah man, SAP sucks, soooo inflexible, I argued against it but what are you gonna do, changing it is really expensive, I guess we'll just have to do it their way" and message boards fill up with complaints about how inflexible and expensive SAP is. Funny how that works!
Scapegoat as a Service. I wonder just how common this is in practice.
I think it depends what adapting means. People often (and I guess LIDL fell for that too) just think they can adapt everything to their needs and that really is not possible. A lot of processes benefit more from changing the processes than the SAP implementation of those processes. IMHO.
This is a tricky topic. If you're getting into SAP and you're not adapting it to your needs, you're almost certainly doing something wrong.
The trick is that it _has_ to be a "meet in the middle" kind of situation, where SAP wants to be used in a certain fashion, but also allows a certain amount of leeway — any non-trivial implementation project will involve both tweaking the knobs SAP provides to fit the customer, and developing bespoke components for those scenarios that SAP either doesn't cover at all, or doesn't handle the way you'd like.