If you go too far, a SAP version upgrade is no longer a drop-in operation, but rather a year long project of porting all your changes to the new version.
If you stay as vanilla as possible, upgrades are a lot easier.
Many many customers have been burned by this over the years - being too trigger happy and customising/building their own extensions rather than using the out-the-box functionality. Packaged software exists for a reason, don't use it like a PaaS to built your own solutions.
SAP is now pushing customers to "keep the core clean" and stick to standard as much as possible, which is definitely a move in the right direction.
s/SAP/Debian/g
s/mature/so-so/
s/customer/sucker/It's funny to see people here defending SAP, because the way I see even the smaller shops that did bend to SAP's will ended up with much of the same problems but with less much to address them and on top of that, much like other enterprise grade ERPs they had to spend a lot of money on infrastructure to process only a few RPS while struggling with high availability.
BUT the problem is that Jira is infinitely configurable. Add 20+ projects with 20+ project managers/leads who want to do things Their Way and you've got a clusterfuck on your hands. Every project has different terminology, different workflows and different ways of handling the same types of projects.
What Jira needs is a single (benevolent) dictator who is the gatekeeper of adding new workflows, tags etc. Then it works.
One very large video game studio has tons of automation for Jira. Imagine someone deciding to add new weapon. The automation creates 100s of tasks for concept artists, 3d artists, animators, sound artists, software developers with complex dependencies better those. Most importantly, automation creates multiple QA steps for each element of completed work.
The same exists for levels, enemies, quests and tons of other elements.
I would not be surprised if a lot of studios had similar workflows.
The lock-in is huger than huge. I don't think a single company on earth managed the art of locking in customers as well as SAP. Does anyone ever drop SAP? I don't know: the cases have to be exceptionally rare.
It's a racket. Highway robbery. This kind of behavior brings in a lot of revenues.
I personally do think the sale to the customer is complete and total misinformation. And once you've fallen for it, there's no way out.
Very hard to throw/replace ERP. It might happen but it‘ll take decades for global SAP installed base to shrink seriously.
> Is it solely customer misinformation?
SAP (and other „enterprise sales“ players) sold to CIO with „account relationships“. Then software is shoved down the throat of business users.
First you should know that the market for ERP systems is very wide. There are LOTS of various companies that offer their ERP systems. Also a lot of those "ERP" systems are "enterprise resource planning" in name only. The smaller ones often are focused on one thing only: bookkeeping, warehousing, invoicing, purchase management, salary calculation. Often they started as something that does one thing (usually: bookkeeping) and then more and more stuff was added on top -> as requested by customers. There was this old theory, that at some point each peace of popular software becomes so big that it can handle email. And guess what, SAP can send emails too. Tons of those other ERP systems can send email too. Different thing is if they really should.
The smaller ERP solutions often dont scale well (they cannot handle too many "things" e.g. millions of invoices, millions inventory SKUs, 20 different countries..) or are too simple / not flexible enough to actually customize. With those smaller systems, you can understand them (e.g. the whole system has few thousand tables), but this comes at the surprising cost of lower flexibility, because in order to handle the complicated business cases you have to recreate the complicated logic as well. SAP was used by so many big companies that a lot of the complicated logic is already there in its 'standard' (and as others pointed out: if you want your life easy, you should adjust your company to the standard, instead of trying to customize). Different thing is that you need a consultant to even know that those features exist. And as you can imagine SAP is so big that even the consultants can only focus on a certain part. [also I personally knew a situation where consultants wrote a custom extension for something that was available in standard -> they didn't know standard SAP standard well enough..]
I kind of disagree that a typical configuration of SAP has 20 000 tables. The ones I knew usually had 50 000+ and those were just few "modules". Using SAP terminology you have modules like FI (finance: bookkeeping), CO (controlling - financial reporting), FI-AA (asset accounting -> think list of assets the company owns), SD (sales & distribtion - e.g. issuing invoices). There are lots of those modules and usually the consultants know "their" module + the finance module. Because at the end the FI (finance) and CO (controlling) modules are always on the top -> you want to register the things that happen in financial ledgers and make some reports out of it.
For example: the consultant that sets up invoicing for you will know SD module (to set up the actual layout of invoices - how it looks like when you print it, the process flow etc) and FI (to help you configure that the invoices land on correct sales accounts). Someone else sets up the PM (plant management) module. Someone else handles access rights / authorization (small ERP systems often struggle at this part - and often "everyone can see everything" what is a big no-no in times of GDPR and just batshit insane when we think about corporate espionage).
A lot of complication with SAP comes from the fact that it can do things as per laws of different countries (please note: not necessarily out of the box, usually you need configurations and external add-ons). For example if you want the taxes calculated by the system for USA, Germany, Poland and Japan - then SAP can do it for you. The system (after painful configuration) will calculate the sales tax / VAT tax and also provide data to calculate CIT (I am not sure if any company calculates corporate income tax out of the box, I always saw an expert from SAP to some data/warehouse and a magic Excel file on top). Also laws change all the time, so system has to change all the time.
Even the basic stuff gets complicated once you need to handle it at scale + for many countries e.g. you want to issue the invoice, you need to use the correct tax type (e.g. VAT in Europe), the correct tax rate (e.g. like 50++ rates per each country), then you need to handle things like invoice corrections, exchange rates, handling exchange rate differences, withholding tax. And it is like this with >everything<. Every business activity that can be handled can be cancelled/reversed, what makes the logic of everything convoluted (e.g. when you reverse the invoice 3 weeks after it happened you need to use the correct exchange rate as per each country's law), because the bigger the company the more probable is that they will do something that shouldnt happen. SAP can handle this at scale.
Other thing is that there is a big moat. The process of setting up any ERP system takes at least months and generally years. The article explained it quite well. You need to migrate data to the system, check if it works, see if can handle your cases, train the users (the training part often is ignored, so lots of features are not used). Often the companies also dont have anyone to help with customization AFTER the migration, what is another big problem. It is public knowledge that more than 50% of ERP implementations fail.
There is also some degree of economy of scale. People who used SAP at one company have it easier to use at another. Although devil is in the configuration details. But at least they dont need to relearn the interface (that is awful in most ERP systems).
In a typical big company at some point you need to have your own in-house ERP administrators, who outsource parts of requirements to external sources and deal with the easier stuff on its own. The smaller systems are often inflexible for that - source code is not available. Different thing is if you want to handle the SAP source code with comments in German (yes, that's how it looks in some places; table and column names are German abbreviations too).
Speaking about incumbents: I read that there is some "magic" open ERP system (forgot its name - maybe it was OpenERP), that has just under 20 tables that supposedly can handle everything, but I never looked much into it. Perhaps 20 tables with 1000+ columns each (maybe still better than 50 000 tables with 10 columns each).
And to end it: ERP systems are like elephants. Once you set it up and it "kind of" works, then you dont want to touch it. You dont want another few years spent putting lots of effort on your tooling. You want to deal with actual core business part of the business. The article also pointed it out -> the quote that in some markets being able to implement the ERP better than the competition is the competitive edge is quite true. There are lots of companies with very very bad ERP, or multiple systems that dont talk with each other. What makes reporting hell. (not that reporting in SAP is easy) And without good reporting, the decisions are taken too late, or not at all.
This was the craziest part of doing SAP development. (I'll admit this is an America-centric viewpoint.) But the codes to get to various screens were (to me) totally random. e.g. to create a purchase order, the code is ME21N. Only after 6 months, did my German boss let me in on the secret that all the codes "made sense" if you knew the German phrase for "purchase order" or whatever.
I guess it's fair for the world having to deal with .cfg .txt .exe and all the other English that's essential for modern computing.
But the table and column names are literal german abbreviations. E.g. table AUFK - "SAP Order master data" is named after "Auftrag" (=order).
Column "AUFART" = auftrag art = order type. And often more
When you go into the actual ABAP code of some transactions, it can have comments in German, made by programmers many years ago.
I have done work with some subsystems like you would also find in SAP and usually I found the SQL Databases weren't that amazing at modeling what I wanted.
But I don't know enough of how these systems work. Does every location or subsystem have its own db that get some compared in the software layer or is there usually a single source of truth db somewhere?
SAP HANA basically sits on a custom server and (as far as I know) just uses a column database. The hardware is setup/customized by SAP. Perhaps they want to squeeze some margin here too. The conspiracy theory is that it is not for speed, but to spy on their clients. Or that they dont want to deal with customers mis-configuring their servers.
As for the table structure, then most stuff sits in just big tables. I dont know if the system shards them internally; from user point the tables are just one entity, not divided by anything. You can query them without having to glue anything. For example the table AUFK has order data for all orders, in all entities, in all years. (on a side note: many other ERP systems make separate tables for each year, what is a pain in the butt for reporting, but also allows to shard the data easier). SAP also has this concept of "MANDANT" which is kind of abstract concept of access rights, that can be compared to entity, but it is not really a financial entity (there is a field for that too). Perhaps internally the databse somehow shards the data on MANDANT level, but from user perspective you just see one big table.
And boy, some of those tables are big that you only extract deltas to your business warehouse.
>Does every location or subsystem have its own db that get some compared in the software layer or is there usually a single source of truth db somewhere?
The idea of SAP ERP (and I'd argue the idea of most ERP systems) is the ERP system is your source of truth. All its subsystems sit on one database, that (if you stay within standard) shouldnt ever break.
Many companies have other systems that "feed" data to SAP -> e.g. you do some inventory planning in some super-nice stuff, but the actual "bookkeeping" (source of truth, orders, financials) is in SAP.
So you are paying hundreds of millions to get a canned, pre-packaged, inflexible solution?
Why is SAP still in business? Is it solely customer misinformation?