Have done consulting for 15 years, understand your feelings. But I'd like to offer some alternative viewpoints.
Buying an off the shelve package also buys you an industry-standard business process. The idea is that part of value comes from the process that you have to shoe-horn into. Some integration is expected (and provided for) but if you have to modify heavily, You're Not Using It Correctly.
Also, using an OTS package means less development risk (not every IT dept has 10x developers coming out the wazoo) and it also means that you have a huge reservoir of skilled labour if you need it. Not just for development but also on the business side.
Finally, if you're a big, publicly owned company, you likely have many financial / reporting constraints. The scope of your non-negotiable requirements may be bigger than you imagine.
I've seen people implement SAP in a couple of months. It's possible. It's still expensive and clunky though :-)
> I've seen people implement SAP in a couple of months. It's possible. It's still expensive and clunky though :-)
Never worked with SAP, but still coming off my burn-out hangover from $OLD_JOB - worked to migrate the nexus of the firm's accounting systems from COBOL to MS Dynamics. Unto itself, I don't really have a problem with Dynamics - I do have a problem with MS and their piss-poor available materials on the topic. While I understand their business sells training and certifications, this does ass all for folks pulled in as a pinch hitter during a death march. Can scarcely fly out to Las Vegas for a week long vacation while I'm working 16 hour days to beat the clock on our last true COBOL coder's retirement date.
The greater issue I have in enterprise systems - often the consultant / contractor firms[0] involved in the process. The classic fly-out of classy sales-engineers replaced with low-rent off-shore coders for the actual work. Slick-as-shit documentation that does not match reality in even the simplest of cases. Counter-Party contacts that neither care nor hide their lack of caring for the outcome of the project. Pressing for aggressive timelines that do not meet reality
I would assume there is some correlation, however, between buying $ENTERPRISE_TOOL and an unwillingness to hold consultants feet to the fire on their own failings, structuring a contract that keeps them honest.
[0] - Not to state `ArnoVW is one, only stating a pattern I've run into all too often.
Thanks for the footnote =) And I concur. Outsourcing your IT replaces one type of work with another. If you can't manage your externalized projects, you're gonna get eaten alive by IT services suppliers.
In fact my line of work was managing 'complicated IT projects', generally involving formalizing things and chasing said suppliers (ie they outsourced the outsourcing)
You see, when your Foxpro guy retires in 10 years, either you've been training your new hires how to program Foxpro (a waste of time) or you'll pay a specialist to move all your business data and operation macros to a new platform (a waste of money).
SAP lets you stop kicking that can down the road by wasting your time and money today.
I’ve never seen a SAP install that wasn’t modified heavily, usually to the tune of millions of dollars of development - which can’t help but make me think that if nobody can use it “correctly”, then perhaps it can’t be used in its unmodified form.
In addition, a common occurrence seems to be businesses paying for extensive custom developments (such as an integration with a third party system), and footing the entire development cost - despite their “custom” development being 100% identical to that deployed at other businesses. They’re then trapped in a world where changing the URI for an API endpoint costs €150k.
Honestly, I see it as just being a big corrupt hole fuelled by interpersonal relationships rather than any actual rationale.
Buying an off the shelve package also buys you an industry-standard business process. The idea is that part of value comes from the process that you have to shoe-horn into. Some integration is expected (and provided for) but if you have to modify heavily, You're Not Using It Correctly.
Also, using an OTS package means less development risk (not every IT dept has 10x developers coming out the wazoo) and it also means that you have a huge reservoir of skilled labour if you need it. Not just for development but also on the business side.
Finally, if you're a big, publicly owned company, you likely have many financial / reporting constraints. The scope of your non-negotiable requirements may be bigger than you imagine.
I've seen people implement SAP in a couple of months. It's possible. It's still expensive and clunky though :-)