What you've said is absolutely true, but it's mostly a feature, not a bug. Once you get big enough to need SAP, it's actually useful to put your business processes on a standardized platform. It's painful, always mind bendingly expensive and often fails. But few companies want to be innovative in their business processes. It's actually better to move to "the standard" since it makes processes more understandable across different ginormacorps, which is useful for the upper management sorts that tend to move between them. There's virtually no competitive advantage to having unique business processes. There are many folks that even will say that that's the advantage of moving to SAP is it makes the internal mechanics of the company work a lot like every other giant company.
Telling that losing your uniqueness and being like “everyone else” will actually become your competitive advantage is something that only SAP can come up with.
If you already grew big, you won't grow bigger by adopting SAP. You can stagnate at best, as shown a million times in the real world. Companies that still want to grow just don't use SAP. Period.
This is pretty much never the case, and more often than not the company is successful despite those process, not because of.
Many processes evolve on an ad-hoc and as-needed basis, with some tweaks here and there over time as the company grows and staff turns. You eventually reach a point when no one can remember how a process came to be, or why Sarah has to export four files from three web interfaces and copy/paste data across two Excel files to send to John over in accounting that was just trained last week on how to use this file to true up actuals.
There's only so many ways a company can track inventory, or manage purchase orders, or calculate product costs, or represent sales order and invoices. An ERP acknowledges that a vast majority of businesses operate with the same set of industry-specific operational primitives, and businesses have learned that it's both more time-and-cost effective to adapt your business to the expectations of the ERP than the other way around.
In the rare case you're doing something novel, you can still build your bespoke solution on top of those existing ERP primitives without having to re-invent how the numbers come together so your company can spit out the three financial statements.
SAP does not need to touch the "unique" detailed processes that makes a company great, nor it's culture. But if you e.g. manufacture a product, the design process can still be relatively unique to your company, but most often, the manufacturing processes should follow the high-level blueprint of manufacturing companies.
If its the former, than conforming to SAP is giving up what made you good. But if its the latter, then conforming to SAP is just making the basics more standard and easier to maintain.
No executive wakes up and things ‘this is a great day to pour 500M down the drain’.
Standardise the mundane (with an ERP, with minimal customisation) business processes so your company can focus on innovating where they have true competitive advantage. This is the recipe for a successful ERP implementation.
Either is SAP though so, who knows.
> There's virtually no competitive advantage to having unique business processes.
Take "Time Accounting" for example. I'm not referring to tracking hourly employee hours for payroll, I'm referring to tracking salary employee "project time." Every past salaried position I've had at a company with more than 90 employees had its own custom time tracking software[1]. The first company to do this was a multi-national telecom that I worked for. It was done so that each project could be broken out into its stages and the portion of the employees' salary could be itemized among "Capital Expenses" and "Operational Expenses". This was so important to the company that it warranted a massive development effort along with a corporate initiative to get 100% of time reporting in "on time." They did this as you'd expect a huge company would -- fail to hand in a time sheet on time a few weeks in a row and you'd get dinged more for that mistake than anything else.
The second and third companies ended up "accidentally developing time tracking software" specifically because there was competitive advantages to improving "Resource Planning". It was most helpful to my last employer. Their businesses was creating new products (often hardware/software combinations) for companies. This involved hiring a large number of people specialized in things that had limited cross-over. Resource Planning was predicting when what skills at what level would be available. This, necessarily, involved tracking what time was spent on projects in the past to improve those predictions and ultimately ballooned into a full time management and accounting application for the business (they sold "our time" to customers at the end of the day so it helped them to plan what to charge).
I'm curious -- from your perspective, is it that the competitive advantage is lost "because the tools that everyone is stuck with won't work" if you stray too far from "standardized" or is there another advantage to this standardization?
[0] Unique business processes and marketing are frequently the difference between the #1 and #2 company in a given space.
[1] In one case (about 250 employee global company), the company wrote it as a concept for a future product but once it was available, the existing solution was tossed primarily because the business side really liked the flexibility. In another it grew out of a pet project and became entrenched. At the remaining two, a decision was made to develop something from the ground up.
Specially with the tools that exist in open source. Amazing databases, data modeling systems, libraries to integrate into literally everything.
It think the bigger problem might actually be to define the process you want to implement. What are the specifications, what of your existing system is actually needed and what isn't. Rather then the actual implementation of those processes in some digital process.
I have a friend who work himself up from worker in a warehouse to team leader and now SAP something something manager. And from the story he tells me I am mostly constantly confused. The whole environment feels incredibly foreign.
Build a inventory planning and tracking system for a company that operates in every country in the world and has to issue and receive invoices, customs documents, waybills etc in hundreds of formats, currencies, languages and accounting standards.
And you are right that the biggest problem is definining processes and data types. Whatever waybill system a 100-head HN Rust and JS crack commando comes up with, you can rest assured that there's some authority somewhere that wants an item displayed differently, so you either patch this and many other edge cases until your codes becomes an unworkable spaghetti, or you go back to the drawing board countless times and ship nothing, or you outsource it to SAP and the likes who have spent decades coming up with a working solution (even if it's not that elegant).
You really don't just need 100 programs but you need 30 people defining the processes and 200 configuration experts.
This really seems like something the world would profit from creating a huge amount of open libraries for all this stuff. There are so many old apis in all these old systems. I work in banking and when switching company and then you re-implement the same shitty format again.
You would obviously need some people who have done ERP systems experience, not just 100 random developers.
I think, at least I have heard, that Tesla does its own internal system, would be interesting to see how many people they have working on that if its true.
Posters in this thread are so clueless it hurts to read.
But also, SAP has a lot of accounting and legal process knowledge baked in that is reusable even if you customize everything about it. That's what "mildly competent" developers are missing.
Essentially, they used SAP as a framework.
Adding "respectfully" is a no-op. We need you to be respectful, not just use that word.
This is not Wikipedia.
> Respectfully, the way you affirm such a thing with such certainty gives me the feeling that you might be pretty far left on the Dunning-Kruger graph on this topic right now.
No, writing "Respectfully" at the beginning of your comment doesn't make you respectful. You are just one of those people who want to show they are smarter than anyone else without adding anything useful to the discussion. Hide your insults better next time. Or better, don't insult at all. Or even better, shut the fuck up.
I found this hilarious.
That's maybe one or two words away from a literal conversation in a huge meeting with dozens of high-level IT staff overseeing an org with 30K staff and a petabyte of existing Microsoft Office documents.
Boggles the mind that some people think this way, but they do.
Like... imagine an electrician wiring a new office building having a debate about which frequency and voltage to use. "Don't make assumptions!"
Imagine what wiring an office building would be like if all the wires, circuit breakers and tools could only be bought from a single vendor. Boggles the mind.
"Why stick to the status quo?"
As GP comment said, there has been innovation in the electrical engineering space that maintains backward compatibility.
So if Open/LibreOffice could actual deal well with MS Office formats, for example, whilst removing the annoying bits (cost, telemetery, UI[0]), then yes, it might be wise to move on from the status quo.
[0] in practice I don't think the OpenOffice UI is better than the MS Office, but in theory some people could prefer it
(but it is in academia)
> Lidl based its inventory management system on purchase prices. The standard SAP for retail software uses retail prices, and fearing the group could lose a competitive edge by compromising, Lidl declined to change, so the software was instead adapted.
https://www.henricodolfing.com/2020/05/case-study-lidl-sap-d...
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?
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.
Telling SAP that you want them to change their ways to accommodate your brilliant idea is akin to a layman telling a brain surgeon how he wants his surgery done.
1) Your company processes MUST adapt to SAP processes.
That's it.
You can try customising SAP to fit your processes, but you will just waste time and hundreds of millions of money and then you will fail.
Lidl spent almost a decade and 500M€ on its SAP project, but didn't follow rule #1: https://www.henricodolfing.com/2020/05/case-study-lidl-sap-d...