The problem nobody wants to admit is that any competitor to SAP will just become SAP. SAP grew to what it is because it was made to fit everybody's workflow to make sales to businesses wanting ERPs.
Business is a wild world of so many ways to structure the org down from workflows to departments which is basically the only thing that differentiates a large majority of businesses these days.
Sure, you could enforce a single cookie cutter approach for everyone, but then, how is corp A any different B anymore when everything is identical besides the people itself, heck their costs should equalize as they should in theory have the same workflow optimizations and inefficiencies.
"The problem nobody wants to admit is that any competitor to SAP will just become SAP."
This is an entire category of software. Closer to most of our homes, see "bug tracking software", "web frameworks" (frontend or backend), or "programming languages". Countless examples of someone getting frustrated and starting a "lightweight alternative", gets lots of attention, gets lots of customers who find various issues and features get added to address them, and before you know it, 5-10 years later, the "lightweight alternative" has become the monster the next generation of "lightweight alternatives" are being started up against.
I'm actually at the point where I consider advertising something as a "lightweight alternative" to be nearly a strike against one of those things; it likely means the author doesn't understand how the previous things got to where they are and are just going to follow them down the same road. If you've got a coherent story on how to address that, talk directly to that.
Of course, if you're a new bug tracker/framework/language author, you'd probably rather get the numbers you can get from advertising "lightweight!" rather than the smaller numbers you'll get from advertising "we're going to contain complexity by an aggressive modularization system based on the principles of ...".
I think the big difference is that you can re-implement your website in a new web framework, open source it, and then get traction, etc. You can also do this with ETL frameworks (i.e. Airflow) too. Disruptive software is easier here as developers can run this new framework in parallel, or even as a side project to test it, provide feedback, or even help implement changes upstream. If something goes wrong, it usually has minor consequences. Something like an accounting system has challenges as it involves historic records and data, but at least you can test inputted data and results. With an ERP system, it touches the physical world so if a shipment is sent to the wrong place or doesn't happen, etc. the cost could likely be a much larger headache to deal with IMO.
It's easy to roll your eyes when you hear "disruption" because it's often used as a meaningless buzzword, but it describes a very real dynamic where "lightweight" products can disrupt outcompete heavyweight products in a large chunk of the market (https://en.wikipedia.org/wiki/Disruptive_innovation). There are good business reasons that the products became heavyweight, but it leaves an opening where a smaller product can steal a chunk of the competitors.
JSON disrupted XML. There really are ways it's strictly less capable.
The majority of these projects are created to explore an idea, they are not meant to get big. They work well for small companies or niche customer bases. When the public and investors show up with demand to be big and cash is the author supposed to turn it down?
The amount of good money thrown after bad on Kickstarter shows the money has no idea what it's investing in.
And let's not forget Hershey's disaster which they blamed on SAP and their implementation partners, mentioned here with 14 other ERP failures (yes, SAP is predominant, but there are other offenders as well...; article Oct 2019)
SAP projects don't fail because the software doesn't work. They fail when business and IT leadership are weak or don't understand what it takes to get these projects done, or they are doing them for the wrong reasons.
> By using Target’s existing technology, employees in >
Canada could draw on the large amount of expertise in
the U.S. That plan had shortcomings as well. The
technology was not set up to deal with a foreign
country, and it would have to be customized to take
into account the Canadian dollar and even French-
language characters. Those changes would take time
which Target did not have.
Given Target's original system didn't have a multi-currency approach or use UTF8, my guess is the implementer (in this case Target) is also part of the problem.
It is hard to disrupt this type of software as migration involves migrating data, which is hard, in addition to changing a lot of employee workflows. Potentially, if something like 3D printing of metal parts took off, it could mean a new type of ERP system would be necessary, allowing for a new player to come in.
It was Target's fault for not having fully grasp their OWN requirements (I was following this case when it exploded in the media). They just blamed SAP because their mistake cost $1Bn and it looks stupid if they did admit it.
That's not really the impression I got from the article at all. There were many factors that contributed to that debacle, but SAP seems fairly far down the list.
https://www.canadianbusiness.com/the-last-days-of-target-can...
Seems to me SAP is ripe for disruption, but it would be a very challenging throne to unseat.