> Each of the old IT staff in the old system you can replace with 3-5 SAP consultants.
Is this facetious, or unintentionally so? Do you mean you need to replace one in-house staff with between 3 and 5 and presumably very expensive consultants?
For the duration of the ERP project, SAP is not different to any other vendor in that regard, from preparation through hyoer care after go live, yes. Yes, you have 3-5 expensive SAP, or other ERP system, consultants sitting next one internal IT guy and another 3-5 internal business people with a very deep understanding of the business processes in question and solid basic knowledge about ERP systems. Otherwise you set yourself up for failure.
"'sitting next one internal IT guy and another 3-5 internal business people with a very deep understanding of the business processes in question and solid basic knowledge about ERP systems"'
Where do you think the customer is going to find that army of hyper competent experienced staff ideling around their premisess waiting for the day an SAP project drops?
Yes. I have been one of those. Where do you think the externals get the expertise needed that is particular to the business? We can be professional about it and try to point out the real exceses or answer generic questions, redress and inform on specific knowledge traps or consequences of answering choices placed in front of the customer, but in the end it is still a business that is running 'right-sized' being required to drop everything for a few years to assist an IT transitioning project?
Overloading the customer is one of the simplest ways to make sure ít is not your fault when things most often go south.
I think key part is "for duration of project". Savings, if successful, then come for the lifetime of erp.
One thing I've seen frequently is treating erp implementation as IT project. I'm a technical team member doing erp implementations for last 25 years (not sap) but I'll freely admit erp implementation is not about me or technology. It's primarily a business transformation project. You need those erp business process experts to guide and customize, AND you need thorough willingness to change your internal processes to fit the industry best practices you're buying. "successful erp project" empathically does not mean "installed it and it runs". It means thorough and detailed understanding of requirements, mapping to new processes, customization where absolutely positively necessary, substantial and organized and embraced business transformation, extensive training, and thorough testing including user acceptance testing.
If you think is erp as something you just install and life will be the same but magically better, you're gonna fail hard. Missed requirements and edge cases, and or significant internal resistance to change, are frequent challenges.
Because SAP is what most other companies in the sector use and because there are few alternatives. And because everyone else is m uses it, it must be good. Right? Right?!
Also, because leading employees usually have no idea about the intricacies of the "old" system and think it's easily replaceable with a solution from the shelf.
Yeah, I can't see any better argument against contracting an ERP package. This is exactly true, and those 3-5 way more expensive new developers you are hiring through a 3rd party won't create anything better than the original one that knew your company. (They are not temporary either, because the duration of the ERP project is forever.)
I work for a large telco in the tech support side. We had a bunch of internally-developed tools that were clumsy but worked and fitted our workflow.
We've been fed an off-the-shelf solution with modern tech like Angular and the like.
And even without the SAP burden the company is basically destroying our departament. I guess they don't care to lose us poor peasants but they're basically losing al know-how and one of the only two edges they have against competition.
I can't say I care too much at this point, but it's amazing how easy can companies destroy themselves for not caring about their employees.
This is intentional and part of the business model of most companies selling ERP solutions. They deliberately (or incompetently) make their product so overcomplicated that noone outside of their consultant team can make heads or tails of it. Then they can charge big bucks or consulting fees.
One of my first recruiting jobs was hiring ERP consultants (SAP, Siebel, PeopleSoft, Oracle) and even 15 years ago, these people were easily making $100/hr, and if you were specialized (esp. with the supply chain modules), you could get up to $200/hr. They rarely had programming skills outside of SQL and Linux understanding.
From experience, the factor is more like 5-10. Depending on the complexity of the existing solution, and depending on the wealth of custom implementations, of course.
SAP is better though as a set of libraries than a solution, and it's worth a lot precisely because it will fit whatever whacky process an organization has so that the org doesn't need to change itself while adopting the software.
The most obvious failure modes are going for the lowest bidders incentivizing them to deliver with a skeleton crew, trying to nickel and dime the budget cutting features or their scope or straight up coming at the table with no documentation of how orgs own internal processes actually work.
I know of no project failing because of sap or their consultant on its own without any of the above comorbidities.
I taught enterprise systems for a while and SAP's ethos is very much 'change your business processes to fit SAP, because if they don't fit SAP, they're probably wrong'. This is actual advice (in slightly different wording) that comes from their training materials.
It's probably both. If you fit the standard pattern you'll have an easy time to adopt. But they also support edge cases with extra work. A small company with many non-standard processes will need so much extra work that it's not worth it. Then it is cheaper to redesign the company and reshape the company processes.
I find it very difficult to fight for sensible defaults in a company when everybody only sees their area and has a very strong opinion about that. Only a strong force like the SAP transition can break up with those encrusted structures.
I mean compliance IMHO is their selling point: If you are working internationally you make sure that you correctly handle taxation/reporting or whatever to the standards. Other even trust you because you run SAP (which must be correct by definition). And because SAP is so big I think a lot of regulation/reporting requirements will be even done a way that it can be done with SAP. We are a university/research center hybrid and use SAP. As a state entity or funds are limited. Being in a 'nieche' with tons of strange accounting requirements, a very heterogeneous IT and without the money to get the reports/etc fixed quickly I can tell you how much hell SAP is on the other hand.
A few of old IT guys with no fucks to give and a few "up and out" junior devs working over time can whip up a one off abomination build out of LAMP stacks and CGI scrips with a little perl thrown in and an unusable set of websites to handle all the data entry and exit and it WILL ACTUALLY WORK. It will be clunky and the onboarding time will be comical but it will work.
That is a low bar. Your "lowest bidders" should at least be able to equal that. It just has to accomplish the business processes and do so within the software. It doesn't need to be fast, intuitive or look good doing it, it just needs to do it.
Funny considering in the 80/90s SAP sales/management was known for saying that you don't adapt SAP to fit your company, you adapt the company to fit SAP. There was another company (was it Baan or JDE? I think Baan as I had too many meetings at the time with those religious fruitcakes) that said they were better than SAP because you don't need to change your processes; you change the software.
