> That said, this refusal is not new; my parents worked for a bank that was trying to adopt some IBM technologies in the 1980s, and they said that IBM couldn't accommodate the bank's requirements.
That misunderstanding is something that causes a lot of grief in SAP introductions.
When working with large enterprise software, customization is your enemy - and every time you have to customize something there, you should ask yourself if you shouldn't re-think your business processes instead. Often enough IBM, SAP or whatever have considerably more experience than you.
Ironically at my company, our custom software made us too flexible. There was too many crazy left field demands that weren't really that useful.
So when it came time to think about next steps. There was real appeal in being able to say, "No it's not supported in xyz software we just adopted". This prevents us from looking like the bad guy who's just getting in the way and should be laid off because we didn't want to spend 2 months implementing a hair brained idea that would only give us a net return of like four or five thousand dollars.
And that customization kills you over time. Heck, a big reason a lot of banks and other big enterprises eventually move over to one of the big vendors is because they've built up a hodgepodge of now unmaintainable crap that nobody can touch.
This is also why Salesforce was so successful and why it killed on-prem enterprise deployments in a lot of places. No longer a ton of different essentially unique versions to manage that make it nearly impossible to upgrade. Salesforce obviously supports customization but in a much more controlled fashion than was common at the time, and it's why it won out over Seibel Systems in the early 00s.
1: It locks you into a vendor. The vendor strongly encourages customisation for this reason (and for other reasons that are mostly against a business' interests)
2: onboarding staff is expensive because they need to learn your unique systems. If you're using a package/service off the shelf you can often advertise for people with knowledge of the package/service e.g. AWS versus inhouse e.g. known payroll system versus custom.
3: internal costs to upgrade. With stock standard systems your upgrades are cheap because the costs are amortised across many companies e.g. mobile app development in 2010's. With custom systems you pay for everything. The costs are often invisible e.g. horrific Mobile support (watching friends fight desktop websites on mobile is painful). Another cost is that internal development teams are often shit and certainly can never compete with Darwinian best-available-on-market software.
4: shitty custom internal systems. Sometimes the customisation provides business benefits but we have all worked with crappy internal systems where the benefits versus costs were slim.
Two examples of bad customisation requests:
A) HR systems in small companies. For some reason HR managers demand fractally complex systems and they all want different things so developing common features is really hard.
B) larger customers with demanding internal rules/regulations e.g. a client asking us to conform our UI to their UI standard. No way it was worth it for us or for them. Plus dealing with their UI despots would have been hell. I think their internal software teams decided to build inhouse instead (I bet the outcome was shit).
We got one of our largest and definitely most complex customers not long ago. Being rather small, we pushed hard against any customization that we didn't feel was necessary due to business demands, and asked them to follow the way we'd successfully used with our many other customers.
After the went live and the dust had settled, they thanked us and said they were glad we had pushed back. It had forced them to rethink how they worked but the result was much better and more optimized processes.
> every time you have to customize something there, you should ask yourself if you shouldn't re-think your business processes instead
I've heard this as "the best flavor is vanilla". It referred to a hospital aligning healthcare business processes with industry-standard software workflows.
That misunderstanding is something that causes a lot of grief in SAP introductions.
When working with large enterprise software, customization is your enemy - and every time you have to customize something there, you should ask yourself if you shouldn't re-think your business processes instead. Often enough IBM, SAP or whatever have considerably more experience than you.