3 ms·
That's one way of viewing them and I think quite valid. Another lens is that they have a product that can be customized to meet almost any need, but as a result
by FooHentai 6y ago
That's one way of viewing them and I think quite valid. Another lens is that they have a product that can be customized to meet almost any need, but as a result what you get out of the box, or with a poor implementation, is severely lacking. This also drives what you observe - Having an extremely flexible framework rather than a finished product in your sales offering means your salespeople get to run amok promising the absolute earth. Of course SAP can do what you need... it can do anything*
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.
- ta988 6y agoIs there an alternative for companies of that scale?
- FooHentai 6y agoPossibly not, but the hazards of software procurement bite bigger at that kind of scale, and it's an under-studied science with not enough assurance of quality outcomes. I'm sure that 'x percent of IT projects fail' metric has improved at least somewhat in the last couple of decades but it's still fraught with pitfalls. Not uncommon to end up with an end result only as good as, or even potentially worse, than the one you were rushing away from. Better the devil you know, and all that. 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.
- ta988 6y agoThanks for the detailed answer. I hadn't thought about the shift from procurement to later in the life of the product.
- rurban 6y agoSure. Make it yourself. Very easy. In several of my companies we would create our own business layer, without the SAP bullshit. 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.