Again, as I noted elsewhere in the thread, I worked in R&D at SAP for 4 years (16 years ago), but I have no deep love for it. But I do have some understanding of where it fits in the landscape.
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.
I have to disagree here strongly. You are just saying, that a company that became big enough, so it can afford SAP, should drop their way of doing business, drop the processes that made it big in the first place and go through a painful and expensive process where it will become just another SAP shop, with zero competitive advantage.
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.
> drop the processes that made it big in the first place
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.
Not the OP, but my feeling is that you use standardised processes when they are not your core. For example, if you produce a widget using various raw materials, is the way you pay your staff delivering any competitive advantage? Or the MRP process you use to re-order engineering spares? Probably not - standardise those. Implement unique processes where they differentiate you from your competition. Standardise everything else.
Sorry, but that's just not borne out by data: almost all of the Fortune 500 companies use SAP (something like 80-90%; probably the rest use Oracle, which isn't significantly less painful to move to).
A company I once worked at was taken private by a private equity firm. One of the first initiatives this firm kicks off upon closing an acquisition is moving the company to Oracle for ERP. It can take years and many millions of dollars (as it did in this case--the company was built around an in-house sales and order system), but it's part of their playbook. I have no idea if it's truly worth the cost, but that equity firm surely believes so.
That needs some nuances. There are some processes that are just well-known by research to be standardized - like supply-chain, regardless if JIT-style or forecasted stockkeeping.
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.
Is it the business processes that make a company successful, or is it the product, employees and business culture that make a company successful?
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.
Successful companies are rarely leading their industry because they have competitive advantages across their HR or Accounting or CRM or Inventory or manufacturing (etc etc) processes. Large company requirements are typically the same or very similar across industries for these standard business processes. It makes sense to standardise on your ERP for these. The typical problems come when companies think they are special and start to customise.
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.
Lidl is a private and entirely family-owned business. They tend to have more idiosyncratic business processes compared to public companies. That might partially explain why they struggled with SAP so much.
> There's virtually no competitive advantage to having unique business processes.
I'm not intending to take this sentence out of the context of the rest of your post (on its own, I don't think you agree with that[0]), but I think even in context of "specific to resource planning" there are many competitive advantages that companies pursue.
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.
I've known one place that did bend SAP to their will, and they were stuck on a soon to lose support version despite having almost 100 SAP developers on staff (almost half their entire IT)
With 100 mildly competent developers on staff (although not with SAP developers) a company can develop in house everything they need to run a business in a period of time that is shorter than what is needed for a typical "SAP adjustment".
It really boggles the mind. What can be so complex that you can not do it in 300 person years of development time plus the cost of SAP.
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.
> It really boggles the mind. What can be so complex that you can not do it in 300 person years of development time plus the cost of SAP.
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).
Its a fair point the amount of differences of the external world really does force an absurd amount of configuration complexity on your system however well you do on your internal processes.
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.
Yeah because developing business practices from scratch for a giant company is a coding problem so 100 developers should solve it... probably as difficult as making the next Uber for rikshas, right?
Posters in this thread are so clueless it hurts to read.
For one, it's similar to the "nobody ever got fired for picking IBM" saying. Especially in Germany. As far as I remember, one of the managers involved was former SAP too.
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.
> 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.
Please don't respond to such a comment by breaking the site guidelines yourself. That only makes everything worse, and "shut the fuck up" is the kind of thing we ban accounts for. Please don't post like this again.
Saying that you seem to be a novice in a certain field is not an insult. I myself don't know much about SAP and that's fine. But I don't have the pretention of saying with confidence that all the customers of a $100B+ company are idiots for paying millions when they could hire 100 developers for a year and be done with it.
Reminds me of large government departments where some idiot in the IT architecture team says: "Woah there buddy! Why do you think it's safe to assume that Microsoft Office is what we're going to use? What if we decide to use Open Office?"
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!"
Pretty amazing that some people still believe that choice exists rather than submitting to the monopoly. That's a petabyte of files locked into a proprietary format. The smart thing to do is bow down to the monopoly. Only an idiot would try to shift the balance of power back to the users.
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.
There have been tons of innovation in the field of electrical engineering since the standard voltages and frequencies were fixed. New installations are made to a better standard than older ones, while still maintaining interoperability. They don't blindly stick to the status quo without ever questioning if there's a more cost-efficient option like big-corp IT departments tend to do.
So if you were building a 40-storey high rise office building and the sparky you hired decided to install electrical outlets that were all 400 Volts and 30 Hz, you'd be fine with that?
I think a better analogy would if the sparky decided to use a new type of wire with better conduction than standard copper.
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
My first job out of college in the late 90s was in a large division of a larger company (about 80k employees at the time) that was being spun off in the hopes of selling it. As they were going to be made a stand-alone company they needed their own ERP etc and went with SAP. After two years and $50M the dotcom crash killed any chance of selling the new company and it was absorbed back into the mother ship and SAP was thrown away.
> 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.
That article says Lidl/Schwarz has abandonded SAP and gone back to their custom system. That surprises me because I have a friend who does SAP consulting for them.
No, as in the article mentioned, there is so much configuration that you can do. It has it's own programming language, and nowadays a lot is processed in the backend. It helps a lot when implementing new things on top. It provides for you already an entity model, and you can easily add your own tables (which most customers do). Migration to a new schema is my favorite part that I miss when I develop in other systems. For everything there is a tool that grew many years and is really battle tested.
You can customise it, but you do need to stay within limits.
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.
This. SAP has no restrictions on how much you customise it - you can customise and extend to your heart's content. The problems come during upgrade - SAP has very mature tooling to manage upgrades but a customer who has veered too far from standard will need to rework their customisations to fit the new version.
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.
It's the same reason why Jira is so popular. CIOs recommend it to each other, because nobody wants to admit they made a mistake and that it wasn't as easy to integrate in the end after all. It's like getting a nose surgery and telling all your friends to get one as well. In most cases people look worse afterwards.
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.
Jira is perfectly fine, especially if you self-host it so you're not limited by the crappy Atlassian cloud server capacity.
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.
No, Jira is popular because it's flexible. You can customize Jira to fit any process. That flexibility comes with a price tag, which is performance. SAP is a complete opposite, a truly inflexible “my way or highway” type of system.
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.
That may be true for certain industries, but a lot of shops work on CRUD apps and use Jira in its fairly stock configuration. Linear or something like that could do the same job for them just fine.
> Why is SAP still in business? Is it solely customer misinformation?
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.
I once consulted for a place that had one seperate ERP for each acquisition or merger they’d had in the past few decades. They all had projects in progress to decommission/merge them back down to one, but they were never able to turn a single one of them off.
The competition is generally worse. I tell it as someone who saw few different products offered by the competition. This doesn't mean that SAP is good. Also this doesn't mean that there isn't space for someone who could do it better by starting with a clean state (what sounds easy, but is actually very, very hard to pull off).
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.
> table and column names are German abbreviations too).
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.
Going away from SQL Tables based storage to RDF type store (that can model graphs) with a powerful scheme validation system seem like it would make sense given the insane complexity of the data models involved.
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 has changed its architecture from "old" SAP R3 / ECC to "new" SAP HANA. The "new" HANA is not that new -> it was made few years ago, but when it first came out it was quite undercooked. In addition due to the nature of ERPs, it takes often few years to upgrade from one version to another.
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.
Isn't it the most rational thing to assume that a company that is extremely experienced and successful at analyzing business processes and digitalising them will know better than any newcomer with less resources and less experience who operates mainly on "we're disrupting for the sake of it" swagger?
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...