When they didn't get the decision they wanted, they quickly escalated to exec and director level, and the exec of a major shareholder to try and get the decision overturned.
It wasn't an especially pleasant experience personally, because obviously it involved a lot of very personal attacks by a vendor, but at the same time it was fascinating to watch how they networked from the top down to try to get the decision that they wanted, and run roughshod over the SMEs and process.
Some years later one of the sales team sent me a "Virtualisation for Dummies" book and told me I could learn something from it.
It's made me always work to get Oracle and CA products replaced wherever I have a voice as a result. They may have scored one small $500k deal at that previous employer. I've often found I'm not alone in my dislike for these companies for their shady sales practices, and at least for Oracle enough of us worked together to lose them an 8-figure deal by showing we could do something different for far less once.
Open source created modern Oracle. I worked for a company built around Informix, and that database engine was one of the largest expenses of the company. I think we paid like $40k/socket in 2000. Today, you use an open source database to build your product.
So Oracle had to start selling integrated solutions. They do evil shit like pay higher commissions for salespeople to cross-sell their colleagues. So the Oracle Financials guy gets paid more to sell Identity crap than the identity guy. So the sales idiots form all sorts of weird alliances and kill each other.
Thing is, the vendor simply happened to build upon Oracle. If the software supported DB2, or more likely, supported a migration path from Oracle to DB2, I suspect we would have gone with that.
On another hand...
A lot of "Oracle required" software uses a ton of Oracle-specific stored procedures and other components, in fact, I have encountered an MRP software package that was written entirely inside Oracle database. All PL/SQL, with some bits of embedded Java.
The main issue is probably just that SAP is not as litigious as Oracle.
First, the width of the app window is fixed and cannot be resized. And some wide columns are fixed in place too, meaning that I can only see three columns at the time (out of 30) and therefore I am constantly scrolling left and right. On top of that, every time the window loses focus it does a weird 2-3 seconds refresh when you come back. As a result, we all write everything in Notepad first and only open SAP when we know we won't need to click away anymore.
Every single cell in that "spreadsheet" can do at least 50 things, but I have never managed to get them to do what I need. If I need the specific code of my position I copy-paste it from last month because that cell's search function has never returned anything useful. But if I check last month's data I lose the data of this month that I didn't save (plus the weird refresh thing happens here too). And if I save something it's there forever and cannot be edited. As a result, if I don't have my employee and workplace codes at hand at the beginning it's faster to throw the partial data away and start all over.
Some fields auto-complete, but I'm not sure under which circumstances. A colleague found that double clicking in a specific cell triggers this, but none of us knows why this specific cell.
This is a single app I use exactly once a month. Imagine having to use something like this every day. Even worse, imagine testing this app and saying "yes, this expensive, slow, uncomfortable app is exactly what my company needs, and I'm glad to know that you expect me to adapt to it instead of the other way around".
SAP apps are internal and very sensitive to changes, so usually they don’t get priority, but at least you can thank that using such an old app designed for old windows terminal still works. It should just be replaced, but SAP usually leaves that decision to customers and this delays the change a lot
Note that after that training, the employee will need his notes to complete the task every single time, and will only complete the task rapidly after several years of experience with the software (and undocumented tips from older coworkers).
Maybe they have some nicer ones somewhere else but the ones I have used have been buggy, slow, painful messes- I get the strong feeling that SAP is a sales first organisation and engineering is a necessary byproduct.
So therein lies the issue - Evaluating a fully customizable software product that will be critical to your business is very difficult to do before it is actually crafted into what you have in mind. So the procurement and implementation processes are often an uphill battle against magical thinking where people are imagining a certain wonderful outcome but without careful, critical attention what you'll end up with is a heap of shit.
I have a policy of not working for organizations that have either oracle or SAP in the core of their environment, unless my purpose in coming onboard is to move them off it. This limits me in many ways, but I know from experience I'm avoiding a significant amount of pure bullshit, enough to make it worth the rule.
*if you're willing to fund an as-yet-unknowable level of customization effort to reach your organization's particular nirvana.
tl;dr the future SAP has sold to Google may indeed look better than the Oracle reality they're currently living, but it doesn't necessarily follow that their SAP reality will be any good. Such are the perils of procurement.
Regarding altenatives at that scale, I've not been involved in a project at that kind of scale, biggest SAP implementation I was involved in was ~10k employees and Alphabet is sitting at ~130k right now. I don't want to dive too much into speculation, perhaps Google will get a good outcome with this approach and since they're coming from a bad place with Oracle the future might still be crap but perhaps just a bit less so.
The biggest issue with procurement of SAP and it's ilk is it shifts a fundamental burden from procurement to implementation. With a defined software/SaaS solution that's ready to go out of the box, you get to answer a lot of the yes/no functional questions at procurement stage. It can do it or it can't do it and you get to decide how important that is to you. With SAP, every requirement is answered with 'it can do that' with the massive asterix that to make it do what you need it's all going to need to be customized to do so. That opens you up to a lot of risk IMO.
It's cheaper, it's faster, it doesn't need training and cheat cards, it's self explanatory, and you can maintain it by yourself. Plus you know it inside out. Plus you can add much better features, like graphical reports on top of it easier.
The other part is; SAP supports things forever. You can run their old buggy DB from 2003 in 2021 with paid support. Bug-for-bug compatible on Windows Server 2019 probably too. That has a lot of value for a lot of SAP customers.
I would also remind that SAP (and DTAG) built the german corona tracing app, which was delivery in about 2 months, open source under Apache2.0 and very privacy aware. And well within budget no less.
It's the same with SAP.
To run a simple non-official query, you would need to aquire a timeslot on Friday evening running over all 100.000 records, because the thing will run for half an hour. Not kidding.
I talked to the sales agent why they don't add indices to their database, and he answered "we don't need explicit indices. Our system is so advanced, it does auto-indexing". Lol. They really believe their own bullshit. Looks like their idea of a JOIN are 3 nested for loops.