ERP industry is so hard(painful) that I wouldnt want to work in it unless they paid top of the top
Good luck competing in that industry
> basic installation of SAP has 20,000 database tables, 3,000 of which are configuration tables. In those tables, there are ~8,000 configuration decisions you need before even getting started.
Microsoft at one point wanted to become a full featured IT department for companies. From managing their infrastructures, active directory, issuing laptops, but also providing basic erp, kind of salesforce like. I am not sure where they went with that but it certainly an idea that has merit. A small or medium size company should probably outsource its IT department except for the parts that are specific to their business.
ERP are the mother of all vendor lockin for large companies. Not only you need to configure it, but you need to integrate it with the thousands of internal systems.
> but also providing basic erp, kind of salesforce like. I am not sure where they went with that but it certainly an idea that has merit
Microsoft has a suite of ERP software – Microsoft Dynamics. They got it by acquiring a bunch of companies – Great Plains, Navision, Solomon, Axapta. Originally on-premise, now they encourage SaaS but some of it is still available on-premise for those who prefer that. Generally focuses on the small-to-medium enterprise sector, although they've been trying to make inroads on larger enterprises; but large enterprises are still dominated by SAP, Oracle, Salesforce, etc.
My little pet theory is that the old "Do as you told" buisness-culture is to blame for germanys inability to produce great software. Software needs developers with agency, who refuse "idiotic" tasks and fight back to improve the product.
Know an israeli who complained about "endless arguing" in israeli software projects, while not recognicing the strength of that.
If its not fought over, all things are developed, all things become meh, teams exaust themselves doing all the things and the product fails, internally unoppossed, but externally years to late, bloated and mediocre to the core.
> My little pet theory is that the old "Do as you told" buisness-culture is to blame for germanys inability to produce great software. Software needs developers with agency, who refuse "idiotic" tasks and fight back to improve the product.
This I have experienced first hand where this junior product manager who wrote some ticket whose requirements when got challenged says "it's mentioned here so you have to do it and you don't have to challenge it". I lost it and I said, "everything needs to be challenged, we are not just going to follow it like a machine". I did apologize to him for my tone. But it bothered me so much.
Its really tough to change that mindset though, once it takes hold, its so deeply ingrained. ("Ober sticht unter").
Basically the whole education system needs to push discussions more, were you have to argue a point, proof you are right and stick to your guns. Something regarding this is going right in some education systems and cultures, and fails utterly in others. Its a education to lead, instead of education to be led.
On the other hand you could argue too many people that stick to their guns are wrong and this too would be a failure of the education system. The scientific method is what we all need to learn and appreciate: form theories, find evidence for but also against that theory to test your thesis. Improve and refine on this basis or drop a disproved thesis.
it's a pretty good field to compete in when the rest of your economy is large or middle scale industry. There's no point for Germany to built "great consumer software tm" in an economy that isn't consumer centric (or so small to largely compete in foreign markets from the beginning).
I worked for a software company in Aachen for a while that supplied software for local manufacturing and this is necessarily "meh" and largely consists of doing as your told and building to specification because that's what industry-adjacent work is like. Doesn't mean it's not good software.
But thats the point. Doing as you are told, often includes reimplementation after remimplementation in germany, not improving upon pre existing software. Not resisting useless usecases, you already know are doomed by experience, but are specified anyway. 5 versions of the same object, collected on a usb and even copied back down (remote) from customer machines.
Exampletime:
A thousand versions of a cylinder valve controller software for a plc floating around a machine builder.
Instead of writting one for each version of statefullness and interfaces to encapsulate the different usecases. (Can be done with TC3) shared by all collagues via Git.
IOpenCloseable {} and that then can be used for example for a drive home routine
DrivePointHome()
{
foreach (IOpenCloseable cylinder in allElementsInHomestateInOpeningOrder)
{
cylinder.open()
wait(cylinder.isOpen())
}
}
And there you have it. Configuration instead of programming. Reusability instead of Recreating. Testability (https://tcunit.org/).
It could all be done. It is done, good, elsewhere on the planet, daily.
In my last career we fought this mentality, to exaustion.
Now im out of it, im just waiting for someone with the mindset to swoop in, disrupt and clean that space out with the effectiveness of good software. There really is no reason to employ half a million electricians to program subpar software when you can have it better for cheap.
Complacency, top heavy companies with aged decision makers and the immense difficulties and bureaucracy and risk to personal assets that come with founding a company in Germany are largely to blame.
Software is seen as a necessary evil in Germany, not as the main focus for profit. You can directly see this in most medium to large companies which sell ERP or management software (like Scheer) pay their sales reps a lot more than their developers, even though the latter produce their value.
I saw a lot of SF projects budgeted and staffed in roughly the same way as you would SAP.
SF started with CRM and has been expanding to ERP, SAP is the other way around. Both are mainly Cloud/Platform-based offerings today, both feature multi-month certifications, high rates for contractors and lots of effort administering/configuring/customizing.
I expect in a couple of years they either turn out exactly the same or swallow each other.
We need to look at ERP software in positive light. Fab guy here, there is another beast like this that runs the whole fab. It's made by Applied Materials, called FAB300. It connects to inventory systems, SAP & finance, all the fab tools and process data, automation control through interfaces like SECS/GEM, monitors fab output and wafer starts, material systems and movement of wafers, recipe management, copy exact audits, etc.
ERP/MRP systems are complicated because businesses and factory management is complicated. The fact that we have such pieces of software is a testament that however shitty you think they are, at least we have them. They run real businesses and fabs in prod. They bring revenue and are responsible for running multi-billion dollars of turnover. Whole nation states depend on them. That's kind of amazing.
Idk, I have much respect for SAP and such as I grow older. I feel like if I were to design such a thing with 10k engineers at my disposal, it'd be much worse. It can certainly improve, of course.
I always wondered, why wouldn't an in-house developed lean, ERP system would not trump a behemoth like SAP. A few reasons seem plausible.
- No one gets fired for hiring SAP
- Getting an in-house software developer team that can develop an easily extensible / modifiable ERP system is neigh impossible
It is one of my dream to build an alternative ERP system. But it looks like sub-ERP functions (payroll, HR, etc) have been tackled by many companies and they are wildly successful.
> But it looks like sub-ERP functions (payroll, HR, etc) have been tackled by many companies and they are wildly successful.
That's true but TBH, even those that are wildly successful aren't actually that great. I've implemented Workday as a replacement for the user-facing portions of SAP's HR and while it looks good, it's nowhere near as flexible. There's a lot of stuff I would expect to be available in Workday and just isn't. That surprised me as Workday is pretty much the HR market leader.
TLDR; Opportunities are there for new companies to do ERP better. It's not easy though...
Not just developers, but lawyers, accountants, analysts... I think you grossly underestimate complexity of this thing.
We implemented relatively simple income tax reform a few decade ago in small EU jurisdiction. But law makers were very vague in some important details, and there were about 8 different interpretations. We had to implement, run and support all 8 versions for couple of years, until they decided on final interpretation. Non compliance would be fine of couple of million euro.
And that was tiny country of 5 million people with clean newly written laws. Not babylon with 300 years of baggage like US.
The main reason is a third one: You need to have smart and capable business process owners to work with you the right things to build and what to ignore. Most software projects fail because you're giving inadequate or the wrong scope.
> I wouldnt want to work in it unless they paid top of the top
Anecdotally I knew a few people in the mid nineties that did SAP work and they were paid multiples of everyone else, literally hundreds of thousands of dollars a year. Since then lots has been outsourced and offshored so its the opposite, but for a few glory years before dotcom boom it was definitely the place to be.
2)
Because ERP is immensely complicated, and encompasses features that would be useful for almost anyone coordinating any organization, and ERP systems are really hard to change, so they have acquired a user base with lots of zeroes and a thick moat to keep them in.
Though they have many competitors. A consultant who works on integrating SAP told me once that what gave them a competitive edge is that they let 3rd party consultants integrate SAP while others insist on in house consultants. That means that 3rd party consultant have a clear preference when it is time to advise the client on which system they should pick. That was 20y ago, not sure if it is still the case.
Indeed, to SAP the "partner ecosystem" is a big thing. I think they realised early on that if they were to succeed, their success would be driven by consultants with "business expertise" who were recommending SAP as "best of breed".
Of course, the reality is that many of those consultants who are being charged to customers at eyewatering rates just finished the training course last week and are now "senior".
Don't know if it's still the same, but I suspect it will be - another insidious part of the 3rd party consultant relationship is (was) that customers would hire one of the big 5 to help them evaluate and select ERP systems. And that consultancy would also be in a consortium with one of the suppliers (usually SAP), to do the implementation. Isn't that a conflict of interest you would ask? Oh no, the two parts of the consultancy are behind strict Chinese walls, and the evaluation was strictly independent of the bid team. But surprisingly, the vendor they were in bed with always won the contract.
As a sales rep with Oracle, I declined to bid on a project. I offered the CFO to write the name of the winning consortium in a sealed envelope, that he could open when the selection was announced.
A guy I interviewed a little while ago observed that SMB SaaS software always tends to become an ERP system on a long enough timeline. It can’t be categorically true but it seemed like a very astute generalization.
Ah yes, I remember when Lidl tried to integrate SAP in 2015. No one really knows why and after already having spent €500,000,000 in 2016 they pulled the plug and just dropped the project because obviously it wasn't done at that point and they still would have to pay more to finish it. The initial offer never went public but I overheard someone once saying it was like €75,000,000 "only" ... They went back to further develop their own ERP system which is still in use today as far as I know.
The issue there was that Lidl did not adapt to SAP.
They tried to adapt the SAP system to Lidl. Everyone tells you that this is a really bad idea. Everyone.
You would think so, but all of the large consulting firms (Accenture, Deloitte, etc) are driven by billing and people wanting to climb the corporate ladder. What the customer needs comes a distant second. Many projects are staffed with 90-95% juniors or people who have no industry knowledge.
I've worked alongside consultants from Accenture, Deloitte, IBM, etc over the years and, while many of them are very competent, I would /never/ engage one of those large system integrators (SIs) on any project I was involved in. There are many excellent individuals working for those companies, but the companies themselves are terrible and you will struggle to get any of the excellent people involved during your implementation. The experts will appear during the early stages of the consulting sales cycle but will be nowhere to be seen during the implementation.
Unfortunately this is the dirty little secret of SAP implementations. Many SAP customers think "I'll pay top dollar and get a good SI" but they end up getting the latest round of juniors doing the implementation. Seen it many a time.
fully agree, think what you're saying is a misread of my comment. GP said "literally everyone says this thing is bad." My comment was "Well, clearly there were people not telling them [or else they'd probably have stopped short of $500,000,000 in expenditures]".
Your comment is a mechanistic explanation of the failure mode, which again, I quite agree with. I worked at PwC for a couple of years; quite corrupt incentive structures and quite a dysfunctional organization because of it.
Yes, fair point - I didn't explain myself clearly (I've been commenting too much in this thread as it is!). My thinking is that why would they speak up? Lidl has deep pockets so the thinking was probably "another $5/10/20 million will get the project over the line". Not looking at the project and saying "we've billed you so much already, we've delivered something that's not fit for purpose so we'll absorb some of that and get something that works".
For all its faults, SAP is the market leader ERP. Without knowing anything more than what I've read in the general press, I'm fairly confident that the implementation could have been a success.
To be honest, I had so many SAP implementations in my career, and it was most likely not that one. Everybody adapts the software to the real existing business processes. Especially in Germany we are not yet there yet, that tech people can tell business people how to work. I think that Lidl most likely did the upfront design approach instead of building a reliable MVP, and moving forward from that. You have to integrate then a lot more with the old system, but more space to move forward and agile. Funny because it mimics a German military concept of Führen mit Auftrag ("mission type tactics").
Implementing SAP in retail has its own challenges. The large number of products ("articles") sold, locations ("sites"), handling POS data etc.
My first ever SAP implementation was for a large retailer and the project was cancelled (they later implemented SAP ~10 years later after the product matured somewhat) and another project 8 years later was also cancelled. Only two SAP projects I've been involved in that have been cancelled and both were retail (and using IS-Retail, SAP's solution for retail industries).
> Data processing – an outdated term whose lasting legacy is
Automatic Data Processing, Inc’s name – is what we’d call IT today.
Ha!
"This International Standard does not specify — the mechanism by which C programs are transformed for use by a data-processing system;" [ISO C, every version]
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.
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.
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.
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.
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.
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 exp...
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.
> 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.
> 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.
> 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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
> 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.
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.
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.
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.
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.
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!"
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
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.
Indeed it is. Even when using other development tools (eg, ABAP in Eclipse or the third-party addons for VS Code), the code is still stored in the database and executed from there by the ABAP VM. There's no such thing as "offline development" with SAP ABAP, although people are working on it...
Former SAP employee here.
The ERP market is ridiculously complex. Legislation, TAX, complex organisational structures and a million things to get wrong.
One of SAPs hidden superpowers in my opinion was and probably still is ABAP and the GUI Builder. The combination of the two enabled consultants to create dynamic internal applications with little effort smoothly integrated into the whole system. So they were doing low-code way before it was a thing in our industry. As you can see the blog authors (retool) try to achieve something similar 40 years later and it is still a challenge.
Whenever I read about SAP (which I hate, so don't mistake this for an objective take) it reminds me of the discussion about self-hosting your email: "Oh, no, it's too complicated, you are better off paying someone else to do it for you". The problem being, I host my own email and it works fine, which makes me suspicious of the common takes about ERP too.
Now, I get it, once you have to deal with taxes and payroll in multiple countries it gets messy, but why wouldn't you consider that a core part of your business worth investing into? You may not be paying with accountant salaries, but you are still paying with yearly contracts you can never get away from and with a horrible user experience for every employee that has to interact with it (oh, P69, how much I hate you).
Some people dream of being a superhero. I dream of being one day big enough to have an SAP salesman come to me so I can tell them "no".
>> Now, I get it, once you have to deal with taxes and payroll in multiple countries it gets messy, but why wouldn't you consider that a core part of your business worth investing into?
It may work using an open source model. However you don't really want to invest into non-core business(es). It takes away money, talent and energy that you would better put into doing what you do best.
I've experienced this first hand developing an invoice system(not my core business). I still use it but if I were to do it again I would develop only the functionality that I was missing in the commercial offering and try an integration. Time spent on the none core business is time wasted.
> However you don't really want to invest into non-core business(es)
The problem is who gets to decide what is "core" to your business?
Look at airlines, once the McKinsey types were let loose it turned out none of the stuff we think is core is needed at an airline; no need for in-house staff, catering, baggage handling, check-in, maintenance or even [owning] any actual aircraft. So much easier to operate without all that stuff to look after!
Taken to the extreme presuambly one would end up with nothing but an airline's name and trademarks, a handful of overpaid management types, and maybe a bunch of lawyers to look after all the outsourcing/subcontracting and licencing deals.
> Time spent on the none core business is time wasted.
Except there are many businesses that have and are doing very nicely precisely because they ignored what would labeled as non-core activity by many. Take Apple for example, where would it be if it had stuck to making Macs? Or more recently spent billions moving to their own chips. What about Amazon?
Truth is more subtle. And with SAP, it's easy to understand both why businesses buy it - and at the same time - why most competent software developers believe if they were given the same investment they could do better.
Apple is a bad example - they make computers, that is their core business. From chips (ok, they don't own any chip fabs, iirc they used to have their own manufacturing but later outsourced to China, but they do design) up to software, plus marketing and distribution (which is always where the money is - eg Nike makes boatloads selling shoes while the sweatshop workers are paid pennies). The iPhone? It's a computer with access to cellular networks. The iPad? It's a computer. Everything Apple has made since OS X in ~2000 is a Unix computer. Even, if I'm not mistaken, watchOS and tvOS are Unix based.
It's like when Mercedes/BMW et al started making SUVs after years of making sedans and coupés. It's a different form factor, but still the same basic product.
"but why wouldn't you consider that a core part of your business worth investing into"
Yes, that's true, and every organization of any size (one sufficiently large enough to implement SAP) will have experts in those domains. The problem is that implementing them in software is a large task - definitely not impossible, or even extremely difficult (it's just CRUD on a grand scale), but you need software that can change quickly when new legislation is implemented, etc. Painful, and the reason why so many do implement a COTS ERP. Hell, even Google run SAP S/4HANA these days (they migrated off Oracle ERP AFAIK).
So, full disclosure, I worked 4 years in SAP's LinuxLab (ending 16 years ago). I also hated interacting with their interfaces, but I do understand why they exist:
Comparison with hosting your own email is like a dozen orders of magnitude off in complexity. SAP really only makes sense for ginormous corporations, but up in that range, Oracle's ERP is the only real competition. Just the kernel of SAP is on the order of 100 million lines of code, and that's not counting the even more hundreds of millions of lines of business logic.
It'd be more like saying, "I'm going to reinvent email, write all clients, servers, and try to get everyone to adopt it." Except that would still be a few orders of magnitude off.
SAP has modules that handle regulatory issues in virtually every country in the world. There's so much business complexity that's encoded into its systems that it's literally hard for mere mortals to grasp.
I mean I'm pretty confident that if SAP was rebuilt from scratch today, one could reimplement its core functionality within a tenth or less of that amount of code you mentioned.
But there's literally decades of use cases and experience contained in that code. That's one major issue with people thinking about rewriting software, they vastly underestimate the amount of things in there.
I mean on the surface SAP is just a database with a UI and some business rules - 99% of software is - but that in itself is so often underestimated.
(Source: anecdotal, I underestimated 'just' a configuration interface, except that it had hundreds of models and thousands of fields. In hindsight I should've looked for an off-the-shelf data management thing where all I would have had to do was configure the fields and validation rules and some rough layout. Instead I tried to build it in naive Go, sqlite, a REST API and a React/bootstrap front-end. It's a great solution IMO, but not if you're a solo developer working on a domain that big).
Almost all software could be rewritten to be more concise. But SAP's actually too big to have one architect get an overview of everything and then conceive of an optimal solution. Anything with its level of complexity will have to have evolved to get to that point.
And if you managed to get it down to only 10% of its current size, it'd still be several times larger than the Linux kernel.
SAP makes copious amounts of money, so naturally people have tried to replace it. So far, they have not succeeded.
As an example of this, I was at a large government department that was in the middle of a mainframe operating system upgrade project. Not the hardware! The applications were also largely staying as-is. Their budget was two billion dollars, which just blew my mind.
I was chatting with a member of the small army of project managers involved, and I was trying to explain to him that for that kind of money I'll build them a whole new mainframe from sand. Silicon, circuitry, operating system, applications, everything.
For two billion dollars you could literally afford to build a dedicated foundry just to stamp out the sheetmetal for the case and still have 1.9 billion left over for everything else.
>Now, I get it, once you have to deal with taxes and payroll in multiple countries it gets messy, but why wouldn't you consider that a core part of your business worth investing into?
Because it's a complex legal issue that isn't in the competency of most companies, getting it wrong has consequences. Since most companies have similar legal requirements, there's enough scale for a large 3rd party. Also, some countries require the local IRS-alike to approve your software if you wish to file certain tax reports. Bad UX pales compared to these requirements.
for anyone wondering, erpnext.com is a good "alternative" and it is very active on github with lots of people working on it each and every day.
they have hosted plans as well as allowing users to selfhost and only pay for "support and customization" for anyone needing which works out pretty well for many....
SAP is well and good but you have good alternatives
If anyone thinks about going for odoo - which I did for a customer - do yourself a favor and try anything else. Here's why:
The developer experience is terrible, simple template changes need a your modules to be "upgraded" which means every change takes several seconds at least.
The quality of the app ecosystem is so bad you almost can't install any non-core apps if you want to be able to maintain your project. And apps are incredibly expensive (250€ for a GDPR compliant cookie banner).
Most apps have quite few downloads so you don't know if you get what you're paying for.
The documentation is partially non-existing and you're supposed to read odoo's code to know how things works - which is true, but quite time consuming.
If you google technical questions you find odoo forum entries (which could be ok) that often contain just links to youtube videos or simply bad and out-of-date answers.
These issues are just the tip of the iceberg. I honestly wonder how people working on/with odoo deal with this.
Things literally take multiples of the time they should and the whole process is a PITA.
Funny sidenote:
If you google odoo developer experience and try to find what others have to say about this, you get their conferences since they're called "odoo developer experience".
Thanks for the great report! I also encountered it at a client's place but didn't have to dig in too deeply, which I count myself lucky for after reading this :-D
I have been pretty impressed with with what erpnext has achieved till date.
Underdog IMHO.
I think that its founder should consider scaling installed base more.
I am an SAP developer since kind of forever, my first job after university (since 2009). First I hated it, but the deeper I am entrenched, the more I see why you choose SAP: Because there really is no alternative. The data model is so complex because it is growing iteratively since the 80s. Hacker News is valuing businesses that adjust to the customer instead of going for some kind of purity. Another complexity especially now is the different paradigm changes in between. ABAP, the programming language of SAP, is quite nice nowadays. CDSViews are a great invention, and so on. There's really a lot of innovation buried in the bad documentation, it's getting better. In summary as bad as it is, I don't see an alternative for all of the backoffice work. SAP is really flexible and supports a lot of different processes. A thing that makes it so costly is a lot of time culture, no small releases, MVP, and so on. But you can be agile with SAP, especially if you move to the cloud.
There are two versions, the on-premise landscape and the cloud version. The on-premise version makes sense sometimes. You can even deploy SAP platform to cloud foundry.
Indeed, for a long time it seemed like SAP didn't "get" cloud. Having to sign long contracts and speak to an account executive to get access to their cloud platform (rebranded every few months, now "Business Technology Platform", BTP) was the way they did things. Contrast with Google, Amazon, etc.
I've not yet used S/4HANA Cloud (only the on-premise version), but it looks to me like it's just a hosted version of standard S/4HANA but with various restrictions on what you can customise etc. No real elasticity, cloud scaling, etc. SAP ERP has been multi-tenant since at least R/3 in 1992 (I never used R/2) so "Cloud ERP" smells to me like "we host it for you and call it cloud".
This is a genuine question, I don't mean to rip on you: Why is everything SAP I've used terrible? From payroll, employee/student management to industrial control systems - the UX is horrible and it seems so brittle that you're happy if you're out of there as quickly as possible. I've had to reach out to my school's IT multiple times over the years since random parts of the SAP tool they used break.
I remember SAP circa 2003. The only think that used XMLHttpRequest (AJAX aka dynamic html) was Outlook web frontend, and SAP web UI. GMail that widely popularized dynamic html did not even existed yet.
"SAP developers" can mean two different groups of people. The developers who build SAP, and the developers who build the custom stuff that clients need. The former can be quite innovative, but the situation with the latter is pretty damn grim (and I say this having worked in the industry, and my dad still works on it)
> It's actually terminal software, that's translated into a GUI from a text interface on the fly
I am intrigued - you mean terminal output is actually parsed, and a GUI view is then generated from it?
E: this would certainly explain the issue of listboxes only having the currently shown items loaded (described by another commenter) - everytime you scroll, the terminal output has to be produced + parsed again
Historically, yes. It was basically like translating an ncurses (semi-GUI command line thing) into a UI. There were attempts to move away from that model, but at least when I worked for SAP, most actual deployments were still text-to-UI. It was basically a way of slapping some varnish on what was fundamentally an old-school mainframe system.
It's the same today - S/4HANA is still accessible from the GUI and DIAG is still used. Web applications (which SAP is pushing customers towards) are freed from this, of course (they talk native http to the SAP application server).
Remember that back in the late 90s SAP had a native GUI that ran on Windows, OS/2 and Unix (Motif-based) and each had their own native controls (a native Windows listbox is implemented differently from a Motif one, for example). Developers would develop a UI in ABAP with platform-independent controls and that UI would be sent over the wire to the client as DIAG and the client would translate that into the native control and data, etc for the end user.
Agreed! SAP's GUI is generally terrible for occasional users (luckily most have now been moved to web-based applications, of varying levels of user friendliness), but in the hands of experienced back office staff it works well. Not pretty, but very functional and with shortcuts for everything.
> the issue of listboxes only having the currently shown items loaded
I challenged this design decision when Fiori was introduced and the thing is that statistically the lists are either small or huge. When they're huge, they got touched in less than 10% cases, so by not loading the whole content you save a lot.
I'm not actually sure, because I feel like most of the things people do with SAP are very repetitive. Their UIs are mind-bendingly bad, but you mostly learn to do the 3 things you have to do all of the time, and then do them over and over again. I'm not sure how much having a nicer UI would make that easier.
It's absolutely not something you just randomly explore. I think that's a more interesting question: what sort of empowerment of employees could you create if the UI wasn't so terrible?
But SAP's moat is elsewhere. You put up with its terribleness because nothing else can do what it does. Beating SAP would require you to reach that, and do something else, part of which could be a nicer UI.
No, because the training is about the core functionalities of those ERP systems, what action triggers what and so on. Training is not about how the UI works, this knowledge is gained on the job.
Every business software is at least as complex as the business process it models. That's the thing you training for.
Every detail of the business process is now explicit. Employees have to be forced to work according to actual process. You need quite a bunch training for that. Then employees will find shortcuts to make their own job a bit faster/easier, which will fuck up some cases. You need even more training for that and possibly some redesigns. And all you get from that is depression
a) Engineering: Nobody will rewrite 20 year old views just to improve the UX. In many cases, nobody even dares to touch the 20 years old spaghetti code.
b) Sales: The buyer is not the user. The buyer (playing golf with a sales rep) doesn't give a damn about the actual productivity of what he is buying.
c) Management: There is a solid economical rationale in not giving a fcuk about UX. Over the years, SAP outcompeted and absorbed many competitors that were more interested in UX than golf. Golf won every single time. Nobody at the top understands or cares about UX because it does not bring more revenue, it is a cost.
I hate how bad UX has become the standard due to management/executive negligence, and there is so little the actual users can do about it. Even small players tend to neglect UX because of the financial incentives.
I find smaller companies can have a more direct connection to their users, so the outcome is usually better UX. The disconnect from the user in enterprise software regularly results in poor UX, and the incentives to improve it just don't make their way to the people who need to hear them.
I don't see why you'd split the two. Actual good functionality is UX. Lack of good functionality implies the user has a bad experience given the intended goal.
Big players tend to do the minimum, either attracting with shiny red herrings or barely doing anything at all. Both are bad UX.
From talking to actual end users though I am convinced there is no universally good UX. Someone will not understand it no matter how perfect you think it is.
Now I favor ugly but robust UX for business applications. The user doesn't have to love it, it's their job to use it. It just has to be efficient and comprehensive, not pretty
> The buyer is not the user. The buyer (playing golf with a sales rep) doesn't give a damn about the actual productivity of what he is buying
I see this trotted out a lot but are all large companies really that oblivious? Do none of the decision makers talk with the people that work for them? Surely those executives aren't so divorced from reality and common sense that they don't see a problem when people complain that things don't work or if they do, it takes an order of magnitude more time and effort?
Surely there must be some other explanation for the proliferation of these systems other than "execs dumb and bad"?
It’s not “execs dumb and bad,” it’s that execs have different priorities than you think they do, which I think is partially dandare’s point.
Executives at a large company are divorced from your reality at your level of the job.
Incidentally, that’s part of the fun of working at smaller companies, though the variance is higher there’s also the potential to work more closely with good earnest executives who also want the company to succeed.
that's a problem and we're going to have to fix it
>it takes an order of magnitude more time and effort
that's not a problem
the fact that Jane the accounting drone has to do twice the amount of work, or has to hire an intern to help her out, or even wants to quit because the job is so awful now is not a problem
it's a rounding error in the overall cost of implementing an ERP system
a new screen with some new data to show for the exec is worth 20 Jane's and her opinions on the new system
you can't even call the new system unethical or fraudulent because 10 people other then Jane can now stop using broken excel sheets to organize their work
This sounds about right to me. In particular, it tends to partiton the organization into (A) the people whose job it is to plug away at the ERP system (orders, invoices, tickets, etc), and (B) the people who actually do whatever it is that the company does.
(C) - License costs can also play into this partitioning.
Then you hope (and work to ensure) that the benefit achieved for B, by having consistent org-wide information systems to work from, is enough to cover the overheads of A and C.
The simplest explanation is a mis-alignment in incentives.
Executives want to have successful projects to show to their value to an organization. But usually the board members are unable to comprehend the details of a project. So the herd mentality kicks in. The CTO will seek approval for SAP and provide Gartner magic quadrant BS to give the board a level of comfort.
Now whether SAP is the right tool, or if it inconveniences users doesn't matter a whit to the CTO. All that matters is budget and timeline. The CTO wants to be able to speak to the board and say that the project timeline was met and under budget. All else is a complete non-factor.
I am so thankful to be working in an organisation which is reshaping its delivery teams into product teams. Our users are customers and if they want a better UX, they get a better UX.
They wrote you can be agile if you move to the cloud. Did you try that?
I jest. But that's kind of the point. SAP is terrible by the nature of the beast. It's a closed off system with specialised developers who require all sorts of expensive certifications. That doesn't make for good developers, that makes for pigeon-holed developers who don't have a lot of competition.
A terrible SAP developer with all the certifications to their name would probably still find plenty of work, because the expectations are low to begin with, as proven by SAP being held in low regard across the industry.
To me, needing expensive certifications to prove your worth (as if...) is a big red flag. I'm a developer who has 20+ years of experience, I recently worked for Apple and other Fortune top 50 companies, I went from startups to enormous companies.
Nowhere did I need certifications. And my past experience was never enough to land a job. I'd have to prove myself in every job application. That's tiresome and feels extremely unnecessary, but it requires me (and my peers) to stay sharp.
Of course, none of the above is very black and white. There are certified developers who are amazing, and there are open-source developers who keep themselves relevant who actually suck at what they do.
But I'd argue that the SAP group of developers have far more developers who aren't very good and grow complacent, oftentimes because of their certifications. That, combined with a closed-off system, bad documentation, a lack of online support, and a much smaller community, will MORE often lead to software that is of lower quality.
I think you don't see the full picture here. The developers working for SAP usually don't need any certifications. They are regular computer scientists/physicists/mathematicians etc. who write code / design systems.
There are of course the certified consultants that work for clients of SAP. I can however understand why they need certifications. It's probably impossible to configure these systems without some kind of special education in them.
And as for the quality of SAP devs.. I work for SAP and I have met many very qualified developers at the company. Far more than I anticipated before joining the company. Quite a few have been poached by Google et al but that is another topic.
I think they were talking about "front end" SAP devs that are hired to work on custom solutions by a client. Not the core devs that actually work for SAP on building the product itself.
The UI isn’t just terrible, it’s hostile to the user. The rare times I am forced to interact with it I feel like I’m using software that was meant for some other purpose. I’ve worked in the industry for 25 years, I’ve never come across worse UI.
My favourite bit of the SAP UI is whenever you scroll a listbox, it goes back to the server to load the rest of the list. It only has data for the exact 5 items it's showing; the other 1 above or 3 below each need a server hit. And it forgets the data it loaded before.
It isn't use for you as a user, it is meant to run your company. You are not the user, you are the one feeding data into the system. And that is actually perfectly fine in case of ERP systems.
Why did AWS, a group probably fairly technical savy and a direct competitor to its vendor, take so long [1] to migrate from Oracle?
Why does Google, as of today, have job openings for SAP in its Rev Rec division [2], and more widely in areas touching [3] “ SAP ERP domains (e.g. Finance, Revenue/Cost Management, Billing, Materials Management, Sourcing, Procurement and/or Inventory Management)”?
Granted you could say, and I believe in one of the many google “corporate biography” books Eric Schmidt allegedly worked through this same problem: hey is an ERP a product for us? A core competency? Should we build it? [Seems HN discussed this in 2021 already, 4]
Conversely, given the wide ranging scope of random things Google has built and how naively simple accounting and something like a fixed asset ledger looks at first glance…why did they never do it? Surely not because building 7 conflicting chat tools was a priority.
My guess (as a non developer) would be it’s crazy hard to build SAP. From personal experience even QB Online has a daunting level of “backwards compatible” complexity [5] in its data scheme even coming from an accounting background. The API keeps versioning up incrementally and you’ll find gems like “XYZ local French Tax” and other accumulated baggage. As an anecdote, using arguably a knowledgeable vendor, as of a year ago it wasn’t possible to populate a full simple profit and loss statement via Fivetrans ETL tool [6], even though they did a phenomenal job in mapping out the ERD compared to anything else that existed imho [7]. CDATA let you run SQL queries, but the complexity of scripting some of the reports was much more fragile. The community even built a DBT layer [8] and given how cumbersome it was to generate even just the “Revenue” line on the P&L out of a simple non-enterprise tool like QBO, SAP seems 1000x harder.
That’s probably why everything in-market, post-sales cycle is garbage. But hey, someone in a dorm room might be working on replacing SAP right now :)
Note: this excludes versioning, which I believe Workday does every six months, which is also a bunch of work twice a year.
I think ERPs are a basket case category generally. I've worked with SAP for a few years (or more accurately work hard to keep it out of scope for what I do) in my day job. I've also worked for a company providing ERP stuff for SMEs (mostly S).
Anyway SAP/ERPs aren't code for running your business. They're code for running code to run your business. Now you have all the shortcuts SAP made to get stuff out the door, and on top of that you've got all the layers of shortcuts your business has made to get things out the door too. Therefore lots of nasty difficult complexity.
And finally I've seen evidence that in SAP people treat it like the fundamental abstraction layer is the spreadsheet[1]. So like in unix everything is a file, in SAP everything is a spreadsheet. This is a nasty complicated fundamental abstraction without the natural elegance of Unix's one.
[1] Maybe it really is, maybe it isn't but that's how a large chunk of the ABAP code I've seen treats it.
I kinda feel like SAP is the ultimate in checkbox checking. If you ask every department what they need, and write it all down, then find the product that matches all the checkboxes, SAP is it.
SAP checks most of the boxes of almost all industries you need to run a modern business. Some specifc domains better than others, sure, but none are actually bad or unusable. And all tjose functions are integrated with each other. That alone is tremendous value.
Some weaknesses I see with SAP compared to dedicated solutions are in logistics and warehouse management, process industries (e.g. continious chemicals production, SAP is way better for discrete products and still it works just fine for the pricess industry), aerospace MRO (SAPs aerospace and defence package is more geared towards production) and eCommerce (eCommerce as a business is not that complex).
Basically, if you are a manufacturing company SAP is easily among the best solutions out there. Added benefit of using an ERP that litterally everone else is usong as well: you have a way larger pool of people to recruit from that know the system. The less market pebetration an ERP has, the harder it is to get people who prwviously worked with it. That means higher training efforts, more need for external cobsultants and performance issues until your emoloyees adapted to whatever ERP you have.
I think part of it is the problem space to be honest. SAP basically gets used to glue all the fiddly bits of organisations together and I don't know that there is an approach to that set of problems that doesn't get tangled up in corner cases.
With a lot of the nice looking web based apps we're used to looking at, the UX and the target domain evolve together and if there isn't an elegant way of doing a particular operation then there's going to be pressure to drop that operation entirely. SAP deployments always have to do everything in the organisation so complicated corner cases either get dropped (bad) or end up with suboptimal interfaces (also not great!).
It definitively is neither pretty, discoverable nor intuitive, but in the hands of experienced power users (who have spent a lot of time learning the UI), it works really well. I have seen people (who have used the system probably for > 10 years) dig the most arcane information out in seconds, navigating through about ten different views without ever touching a mouse.
It's a UI from another era, but if you take the time to learn it properly, it can be very efficient.
Speaking of purity, the first thing Hacker News would do is try to run SAP on a Kubernetes cluster, refactor crucial bits in Rust and shard the database into sqlite3.db files on per user basis. We'd also recommend you restructure your office for a more open space, bring down the cubicles and make sure the conference rooms are glasswalled and have funny names. Bringing pets to work is mandatory.
And ironically, the end result would be worse and more complicated, but the people that worked on it would get to write a blog and put it on their CV about it, and move on elsewhere without having to live with their own decisions.
> We'd also recommend you restructure your office for a more open space, bring down the cubicles and make sure the conference rooms are glasswalled and have funny names.
This is so true! As the author of a (small) ERP/MRP SaaS, I am often amused when I read HN and observe the thundering herds of fashion followers — today it's Kubernetes and Rust, Postgres and sqlite have a longer lifespan, but tomorrow it's going to be something else entirely, and you necessarily need to use those :-)
I am always thinking about Vinge's "A Deepness in the Sky" and computer archeology: there is an accumulation of the code base and at some point most code will be some kind of legacy.
It is not feasible to rewrite it in the fancy language/technology du jour - huge waste of resources for things which already work fine and at the moment you are done you have to start again, since the IT-pendulum is traveling in the opposite direction.
We, as an industry are really bad at working with legacy code, but for a lot of us it may be the main task if we endure this line of work for some decades more.
Same here, all the hip trends of the day, and then back to the same Java, .NET and C++ that I have been touching for several decades, Boring Technology™.
Yep. If I ever read an article/post about my competition using Kubernetes to run microservices, I'll be quite happy, because it will mean I don't have to worry about them.
I think there's a bigger issue at play that at some point I want to write on.
Small problems benefit from small tools. Large problems benefit from large tools. However, small problems grow and your bet as a small problem is that your tools will grow with you.
In practice, they usually do. If they don't, you end up extending the tool or rewriting it in a larger tool.
So, our tools start small, and small companies use small tools, and the ecosystems grow together. Then, the successful ecosystems end up the next large problem toolkit.
As you're a small ERP SaaS, you're banking on growing with your customers, I presume. And you can make an argument to start on the large tools at the cost of initial velocity, but that's your tradeoff.
I really think the innovation that needs to happen is a system that has a prescribed growth path. Retool/Excel/similar that can compile to a simple app that can adapt to more complex patterns as the need comes.
>, but the deeper I am entrenched, the more I see why you choose SAP: Because there really is no alternative. The data model is so complex because it is growing iteratively since the 80s.
Yes, the scope of ERP and SAP is so immense that even other software companies that have competency in the business of programming also buy SAP licenses instead of coding their own home-grown ERP system.
E.g. Microsoft, Apple, Amazon, Google all run SAP.
Microsoft even has their own ERP software (Dynamics GP acquired from Great Plains Software) and yet they run SAP. Microsoft sells Dynamics GP to mid-tier businesses but they don't use it internally for the consolidated financial accounting of their complex
multinational business.
And in an interview about Google's early days, one of the employees recommended that they install ERP system like SAP and co-founder Sergei Brin was skeptical saying "Why would they need to buy that when their programmers could just code it themselves?!?" Well, Google did eventually buy Oracle Financials ERP and then eventually switched to SAP: https://www.google.com/search?q=google+migrates+oracle+finan...
If you're a brand new YC startup, you're not going to need a complex behemoth like SAP ERP. Maybe Quickbooks or some SaaS service for accounting & HR/Payroll is all you need. However, if the business grows enough (i.e. multinational), you'd be wasting money by paying your own staff programmers to re-invent what SAP already does. Just pay the millions in SAP licenses. It's expensive but still cheaper than trying to do it yourself.
This should be the SAP tagline. I swear I've heard this since I started working with SAP in maybe 2009(?) as well - I had a brief stint as an ABAP developer.
I am a project manager and a SAP user. First I hated it. And the more I used it, the more I hated it. It's like a really, really uncomfortable chair, strong, but designed with zero attention to ergonomics.
After participating in the hiring of an SAP developer I realized -- financially speaking, anyway -- that I picked the wrong thing to specialize in.
The first time we brought in someone truly experienced in SAP development, we paid him more than any other developer on staff[0]. I appreciate the different take on SAP. Can I ask -- is it still as lucrative to be an SAP developer?
[0] This was a global multi-national telecom who ran an in-house developed audio conferencing service (written entirely in C++, interacting with a lot of hardware) ... the skillset of some of our devs was incredible, which made this all the more surprising.
SAP developers aren't paid because they're more talented than other developers, they're paid because the niche in which they're deeply embedded extracts extreme business value.
It may take just as much talent to write interfaces for obscure audio hardware and deal with janky bluetooth edge cases, but that doesn't mint the same $$$$ as a SAP guru who refactors a business process to be more efficient.
Depends what you're comparing it to. Even in Germany it's a niche skill set, that has a higher payment than the average Java guy, but with enough skills you can get paid the same for any specialization, e.g. security, cloud-computing. I changed to solution architect recently, which is a bit removed from SAP work itself.
> ABAP, the programming language of SAP, is quite nice nowadays
I took a brief look at the ABAP wikipedia article and this insanity [1] stood out to me.
I think after a decade of SAP you are too brain-washed to give an objective opinion anymore.
For a regular software developer, ABAP is pure insanity. But it has powerful data manipulation procedures, it's easy to just create and manipulate all your data tables in any way you want.
Wow. That is pretty insane. I hope there is a tooling to surface a warning when it detects this.
But lots of domain specific languages have idiosyncrasies. The Apex language used to program Salesforce is a half-implemented clone of Java from a decade ago. And they didn't cherry pick the best parts.
Some companies will be forever scarred by the past trend to create an entirely new programming language for their product when an existing one could‘ve been entirely sufficient
maybe this one: https://open.sap.com/courses/abap1 In general open.sap.com is the site where you can learn stuff. but depending on your customer's stack it might be different.
Hey, I worked for SAP for ten years and I don't agree with you. ABAP is still ugly with all its improvements, version control system and developer experience is awful. CDS views are great until they aren't, then we had this newest feature where you build apps with metadata on top of CDS views and that's where I decided that it's not a software development anymore.
I do see how Fiori launchpad is a great thing, how HANA is extremely powerful if you know what you're doing. At the same time I couldn't stand the corporate culture, QA processes and etc anymore. There're innovations and innovative teams but for the most things SAP is doing, software development is not the core competency.
Fun fact: I work with Datapath now (if you know what it is then you get an irony)
In effect, SAP is like a franchise system for running certain industries.
SAP sells you a software system that includes ready-made workflows and battle-tested instruction manuals. Plus they can synchronize your purchasing and sales departments with everyone else that also uses their software. So if you want to start a small company working with the big car manufacturers, you buy SAP and suddenly you can send quotes in precisely the format that VW expects, because you and VW now both use the SAP specification. In that regard, signing up for SAP is quite similar to signing up to be a Subways location.
I've worked as SAP consultant and Developer for around 10 years. Past couple of years Ive moved to Microsoft ERP's and enjoy them better since theres more SMB's using Microsoft products which makes work more variable.
(This was 20y ago) None, they wanted to go into knowledge management and we should be key to build this up + social tools, but I didnt want to leave Berlin
/or fly twice a week to SAP HQ which was the requirement.
Welcome to my world:) I'm a software dev and always worked in or around sap (~13years).
Sap's secret sauce was understanding that different companies have mostly the same needs. All have employees that need paying and maybe shifts to be tracked. All generate invoices. All buy stuff from suppliers, etc. So they built different solutions (HR/FI/etc.) For those needs. All running on the same technical platform with its own programming language: ABAP. All domain code is ABAP and everything is readable, you can even debug code that SAP wrote years ago but (generally) you're not allowed to change it. And it's full of comments in German so good luck :)
For medium to large companies it's a no brainer to use SAP so most do. For example Sap keeps the client's systems compliant with new laws. Say some country changes laws on how employees pay taxes, sap updates the code or tells their clients what's needed to update the systems.
Companies that have been around for a few years, most likely they already have SAP so makes no sense to shift to something else.
SAP's ERP code is also quite generic. Tons of configurations are possible in any module. E.g. you may have employees but no shifts. Or maybe you have 200 different shift patterns across many factories to configure. Configuration is so complex it's a well paid profession in itself: the functional consultant.
When that config is not enough to implement the requirements then developers can modify the system. Either changing existing ABAP code, or building new ABAP programs or (more commonly nowadays) just building webapps with the normal tools (react/node.js/java etc) in the cloud and using sap ERP as a backend to read/write data to. This last one sums up my day to day.
ABAP is interesting though. Syntactically it looks like COBOL and that you've gone back 40years plus most of the DB tables/columns/data types have seemingly random names like WERKS or DMBTR. They make sense in German after you've shortened the German meaning to 5chars :). So ABAP code looks very cryptic at first sight.
But semantically the language is ok. It is strongly typed, has some nice features for working with finance programs (e.g. fixed point arithmetic) and an OO model that feels familiar to anyone that knows Java (e.g. single inheritance).
This needs to be higher up. Big points that SAP has going:
* Compliance
* Standard Processes
* Interoperability between companies (a lot of purchasing runs automatically through some sort of SAP Software)
What mostly fails in my experience is the customization. Everybody thinks their process is super special and important and needs 100 escape hatches. But if you ask them to draw their process on a whiteboard, they couldn't do it for one single process without drawing 100 question marks.
That is where SAP shines: The whole thing is so bureaucratic, coming from Germany, which is something you will need after your company has grown beyond a certain size.
Excellent content strategy by Retool team to write about SAP. Retool is for every organisation who do not think of SAP but get the fast internal tools ready to be deployed.
SAP is successful because they've spent over 50 years learning how businesses work and somewhat successfully implemented reasonably configurable processes within their software. You need to handle MRP? Check. Multi-country payroll with complete integration to finance? Check. Even things as esoteric as downstream oil production (think ARAMCO). Check.
I'm not sure why in the early days they were more succesful than the competitors (JD Edwards, BAAN, etc) - all of the others were doing something similar but SAP overtook them all. Perhaps it was because the system was very flexible - if you needed to enhance the SAP-delivered functionality or build your own to integrated with SAP, they delivered tooling to do so (very crude in the early days, a lot better now).
Related to this is that almost all application souce is available to customers (not open source, but available to view and modify if required). For those who've never worked with SAP, the majority of the application code in their on-premise systems is written in a proprietary COBOL-like 4GL called ABAP. One of SAP's key differentiators in the early years was that customers had access to all of this code and, with the required access, could extend/modify as needed. A masterstroke IMHO.
Source: I've worked as an SAP consultant for 20+ years (including a fair number of those working for SAP) and I'm no fan of any of their products. For the number of extremely intelligent people who work there (and I mean that sincerely - a lot of their employees are /extremely/ smart and forward thinking), the code quality and quality control of their products is abysmal. It's like the majority of the code is written by people who did a training course last week and they /love/ overengineering things, reinventing the wheel or backing the wrong horse. SAP went all in on Silverlight at one point and these days they love OData, which NO-ONE really uses. It also took them years and years to officially support a browser other than IE.
At times they have done some pretty forward-thinking things though. In the late 80s they adopted three-tier before most (R/3, the first three-tier release came out in 1992) and they cleverly have a very portable application. Back in the days of the Unix wars SAP ran on pretty much every OS and all the major databases (heck, Microsoft had to convince them to port to NT and SQL Server, primarily so that Microsoft could run SAP on NT in their own back office).
Rambling a bit here but SAP still pays my bills (and fairly well at that), but I'm no fan and I'm always looking for a way out. Unfortunately, for me the situation is like many SAP customers - once you've checked in, it's hard to leave (apologies to The Eagles).
I think the mistake with SAP, as with that other article about a modelling pyramid at Ikea, is assuming that it is possible to create one system to rule them all without it being extremely inefficient and expensive.
It mirrors a dysfunctional business run on command-and-control rather than, like AWS, you have a large set of loosely affiliated teams and although you risk some duplication, it makes for much more agile work.
Imagine you have a supplier who supplies "products" but your system calls them "items", SAP would say that you have to standardise the nomenclature. Agile says, let them call them whatever works for them and lets build small systems with just the interfaces we need.
Sure, the senior management don't get their dashboards but it is still possible to get metrics from disparate systems and form pretty basic cashflow and inventory reports.
This seems like an easy way for money and stuff to start going "missing".
One has to remember that many large companies don't have an in-house set of software engineers to kludge things together, or a set of people to audit and make sure problems aren't accumulating silently somewhere because of some bug or some vendor changing their API or whatever. Even if they did, the supposedly "agile" solution proposed here just sounds rather fragile. You even see this in codebases that are built on a "microservices" mindset -- you start getting weird emergent patterns in internal dependencies that start bogging things down.
For a smaller or even medium-sized business, sure, maybe a custom solution works. But it looks like for the scale of organization SAP works on, it seems difficult for an individual to even understand all the components of that organization, let alone build something maintainable for themselves and their eventual replacements.
I think part of the problem is driven by the desire to create a slick UI and wizards. These systems then underperform. I wonder if you could instead expose more of the underlying computer science stuff to the user. Give them an interface to push transactions. And a set of widgets to pull data. Keep every operation seperate and discrete even when part of a process. And let documentation and training teach the business process.
I used to think this, but then I started interacting with actual end users (normal, non-engineering people). There are 2 main problems with exposing more barebones stuff to non-engineers:
1) Problem solving (thinking about how to compose the raw primitives) takes a lot of creativity. Most normal people only know what end outcome they want, not how to engineer their way there*. The reason wizards are so common is because they address this exact need. Wizards try to figure out what you want to do via a series of questions (and then do it for you) rather than have you come up with how to do it yourself. They are so common because when designed correctly they work very well!
2) Understanding errors is also very hard. Just because something didn't fail doesn't mean it worked correctly. Sure, anyone can file a transaction into a database, but they can just as easily file an incorrect one either by mistake or due to inadequate understanding. The complexity of the systems are their to catch problems before they become problems.
Sure, sometimes there will be corner cases that aren't accounted for by the existing system. And these will be frustrating. But taking away both the end users' guide and also removing their guardrails just so they can maybe solve the problem themselves is not generally a great idea.
*: This is not meant to disparage the normal users, but different people just have different interests and goals. Not everyone should be forced to know exactly how a machine works just to operate it.
702 comments
[ 3.1 ms ] story [ 544 ms ] threadGood luck competing in that industry
> basic installation of SAP has 20,000 database tables, 3,000 of which are configuration tables. In those tables, there are ~8,000 configuration decisions you need before even getting started.
Gotta be fun :)
ERP are the mother of all vendor lockin for large companies. Not only you need to configure it, but you need to integrate it with the thousands of internal systems.
Microsoft has a suite of ERP software – Microsoft Dynamics. They got it by acquiring a bunch of companies – Great Plains, Navision, Solomon, Axapta. Originally on-premise, now they encourage SaaS but some of it is still available on-premise for those who prefer that. Generally focuses on the small-to-medium enterprise sector, although they've been trying to make inroads on larger enterprises; but large enterprises are still dominated by SAP, Oracle, Salesforce, etc.
[ ] Digital Bureaucracy
[ ] All of the above
[ ] None of the above
My little pet theory is that the old "Do as you told" buisness-culture is to blame for germanys inability to produce great software. Software needs developers with agency, who refuse "idiotic" tasks and fight back to improve the product.
Know an israeli who complained about "endless arguing" in israeli software projects, while not recognicing the strength of that.
If its not fought over, all things are developed, all things become meh, teams exaust themselves doing all the things and the product fails, internally unoppossed, but externally years to late, bloated and mediocre to the core.
Still happy that SAP exists.
This I have experienced first hand where this junior product manager who wrote some ticket whose requirements when got challenged says "it's mentioned here so you have to do it and you don't have to challenge it". I lost it and I said, "everything needs to be challenged, we are not just going to follow it like a machine". I did apologize to him for my tone. But it bothered me so much.
Basically the whole education system needs to push discussions more, were you have to argue a point, proof you are right and stick to your guns. Something regarding this is going right in some education systems and cultures, and fails utterly in others. Its a education to lead, instead of education to be led.
As a Skat player, this is only true in Null, the game you actively try to "lose". Fitting, I guess?
I worked for a software company in Aachen for a while that supplied software for local manufacturing and this is necessarily "meh" and largely consists of doing as your told and building to specification because that's what industry-adjacent work is like. Doesn't mean it's not good software.
Exampletime:
A thousand versions of a cylinder valve controller software for a plc floating around a machine builder.
Instead of writting one for each version of statefullness and interfaces to encapsulate the different usecases. (Can be done with TC3) shared by all collagues via Git.
IOpenCloseable {} and that then can be used for example for a drive home routine
DrivePointHome() {
}And there you have it. Configuration instead of programming. Reusability instead of Recreating. Testability (https://tcunit.org/).
It could all be done. It is done, good, elsewhere on the planet, daily.
In my last career we fought this mentality, to exaustion.
Now im out of it, im just waiting for someone with the mindset to swoop in, disrupt and clean that space out with the effectiveness of good software. There really is no reason to employ half a million electricians to program subpar software when you can have it better for cheap.
Software is seen as a necessary evil in Germany, not as the main focus for profit. You can directly see this in most medium to large companies which sell ERP or management software (like Scheer) pay their sales reps a lot more than their developers, even though the latter produce their value.
But most companies are realizing their use case is not that complex and that in reality you don't need all those config options
Then you go with Salesforce or something else saving you one zero or maybe two even
SF started with CRM and has been expanding to ERP, SAP is the other way around. Both are mainly Cloud/Platform-based offerings today, both feature multi-month certifications, high rates for contractors and lots of effort administering/configuring/customizing.
I expect in a couple of years they either turn out exactly the same or swallow each other.
ERP/MRP systems are complicated because businesses and factory management is complicated. The fact that we have such pieces of software is a testament that however shitty you think they are, at least we have them. They run real businesses and fabs in prod. They bring revenue and are responsible for running multi-billion dollars of turnover. Whole nation states depend on them. That's kind of amazing.
Idk, I have much respect for SAP and such as I grow older. I feel like if I were to design such a thing with 10k engineers at my disposal, it'd be much worse. It can certainly improve, of course.
That's true but TBH, even those that are wildly successful aren't actually that great. I've implemented Workday as a replacement for the user-facing portions of SAP's HR and while it looks good, it's nowhere near as flexible. There's a lot of stuff I would expect to be available in Workday and just isn't. That surprised me as Workday is pretty much the HR market leader.
TLDR; Opportunities are there for new companies to do ERP better. It's not easy though...
We implemented relatively simple income tax reform a few decade ago in small EU jurisdiction. But law makers were very vague in some important details, and there were about 8 different interpretations. We had to implement, run and support all 8 versions for couple of years, until they decided on final interpretation. Non compliance would be fine of couple of million euro.
And that was tiny country of 5 million people with clean newly written laws. Not babylon with 300 years of baggage like US.
Anecdotally I knew a few people in the mid nineties that did SAP work and they were paid multiples of everyone else, literally hundreds of thousands of dollars a year. Since then lots has been outsourced and offshored so its the opposite, but for a few glory years before dotcom boom it was definitely the place to be.
1) They do Enterprise Resources Planning.
2) Because ERP is immensely complicated, and encompasses features that would be useful for almost anyone coordinating any organization, and ERP systems are really hard to change, so they have acquired a user base with lots of zeroes and a thick moat to keep them in.
the few consultants that I know that work with these two seems to be paid more than generalist consultants.
3rd party were working closely with customers and helped them maintaining the stuff
Of course, the reality is that many of those consultants who are being charged to customers at eyewatering rates just finished the training course last week and are now "senior".
I've worked alongside consultants from Accenture, Deloitte, IBM, etc over the years and, while many of them are very competent, I would /never/ engage one of those large system integrators (SIs) on any project I was involved in. There are many excellent individuals working for those companies, but the companies themselves are terrible and you will struggle to get any of the excellent people involved during your implementation. The experts will appear during the early stages of the consulting sales cycle but will be nowhere to be seen during the implementation.
Unfortunately this is the dirty little secret of SAP implementations. Many SAP customers think "I'll pay top dollar and get a good SI" but they end up getting the latest round of juniors doing the implementation. Seen it many a time.
Your comment is a mechanistic explanation of the failure mode, which again, I quite agree with. I worked at PwC for a couple of years; quite corrupt incentive structures and quite a dysfunctional organization because of it.
For all its faults, SAP is the market leader ERP. Without knowing anything more than what I've read in the general press, I'm fairly confident that the implementation could have been a success.
My first ever SAP implementation was for a large retailer and the project was cancelled (they later implemented SAP ~10 years later after the product matured somewhat) and another project 8 years later was also cancelled. Only two SAP projects I've been involved in that have been cancelled and both were retail (and using IS-Retail, SAP's solution for retail industries).
Ha!
"This International Standard does not specify — the mechanism by which C programs are transformed for use by a data-processing system;" [ISO C, every version]
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...
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?
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.
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.
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.
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.
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.
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 exp...
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.
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.
https://www.se80.co.uk/saptables/a/aufk/aufk.htm
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.
> 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...
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.
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.
https://news.ycombinator.com/newsguidelines.html
Adding "respectfully" is a no-op. We need you to be respectful, not just use that word.
https://news.ycombinator.com/newsguidelines.html
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.
Posters in this thread are so clueless it hurts to read.
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.
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.
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.
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.
No executive wakes up and things ‘this is a great day to pour 500M down the drain’.
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.
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.
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 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!"
"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)
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.
Technology wise, it's weird. It reminds me a bit of Lotus Notes, in that everything including the screen layouts are stored in the database.
Now, I get it, once you have to deal with taxes and payroll in multiple countries it gets messy, but why wouldn't you consider that a core part of your business worth investing into? You may not be paying with accountant salaries, but you are still paying with yearly contracts you can never get away from and with a horrible user experience for every employee that has to interact with it (oh, P69, how much I hate you).
Some people dream of being a superhero. I dream of being one day big enough to have an SAP salesman come to me so I can tell them "no".
It may work using an open source model. However you don't really want to invest into non-core business(es). It takes away money, talent and energy that you would better put into doing what you do best.
I've experienced this first hand developing an invoice system(not my core business). I still use it but if I were to do it again I would develop only the functionality that I was missing in the commercial offering and try an integration. Time spent on the none core business is time wasted.
The problem is who gets to decide what is "core" to your business?
Look at airlines, once the McKinsey types were let loose it turned out none of the stuff we think is core is needed at an airline; no need for in-house staff, catering, baggage handling, check-in, maintenance or even [owning] any actual aircraft. So much easier to operate without all that stuff to look after!
Taken to the extreme presuambly one would end up with nothing but an airline's name and trademarks, a handful of overpaid management types, and maybe a bunch of lawyers to look after all the outsourcing/subcontracting and licencing deals.
But only if there are someone who can and would provide you with all that stuff.
> Taken to the extreme presuambly one would end up with nothing but
This is the premise of 'The 4-hour Workweek'. It was a quite entertaining read.
Except there are many businesses that have and are doing very nicely precisely because they ignored what would labeled as non-core activity by many. Take Apple for example, where would it be if it had stuck to making Macs? Or more recently spent billions moving to their own chips. What about Amazon?
Truth is more subtle. And with SAP, it's easy to understand both why businesses buy it - and at the same time - why most competent software developers believe if they were given the same investment they could do better.
It's like when Mercedes/BMW et al started making SUVs after years of making sedans and coupés. It's a different form factor, but still the same basic product.
Yes, that's true, and every organization of any size (one sufficiently large enough to implement SAP) will have experts in those domains. The problem is that implementing them in software is a large task - definitely not impossible, or even extremely difficult (it's just CRUD on a grand scale), but you need software that can change quickly when new legislation is implemented, etc. Painful, and the reason why so many do implement a COTS ERP. Hell, even Google run SAP S/4HANA these days (they migrated off Oracle ERP AFAIK).
Comparison with hosting your own email is like a dozen orders of magnitude off in complexity. SAP really only makes sense for ginormous corporations, but up in that range, Oracle's ERP is the only real competition. Just the kernel of SAP is on the order of 100 million lines of code, and that's not counting the even more hundreds of millions of lines of business logic.
It'd be more like saying, "I'm going to reinvent email, write all clients, servers, and try to get everyone to adopt it." Except that would still be a few orders of magnitude off.
SAP has modules that handle regulatory issues in virtually every country in the world. There's so much business complexity that's encoded into its systems that it's literally hard for mere mortals to grasp.
But there's literally decades of use cases and experience contained in that code. That's one major issue with people thinking about rewriting software, they vastly underestimate the amount of things in there.
I mean on the surface SAP is just a database with a UI and some business rules - 99% of software is - but that in itself is so often underestimated.
(Source: anecdotal, I underestimated 'just' a configuration interface, except that it had hundreds of models and thousands of fields. In hindsight I should've looked for an off-the-shelf data management thing where all I would have had to do was configure the fields and validation rules and some rough layout. Instead I tried to build it in naive Go, sqlite, a REST API and a React/bootstrap front-end. It's a great solution IMO, but not if you're a solo developer working on a domain that big).
And if you managed to get it down to only 10% of its current size, it'd still be several times larger than the Linux kernel.
SAP makes copious amounts of money, so naturally people have tried to replace it. So far, they have not succeeded.
I think we've established from the various "I give up hosting my own email" articles posted on HN that this is basically down to luck.
I was chatting with a member of the small army of project managers involved, and I was trying to explain to him that for that kind of money I'll build them a whole new mainframe from sand. Silicon, circuitry, operating system, applications, everything.
For two billion dollars you could literally afford to build a dedicated foundry just to stamp out the sheetmetal for the case and still have 1.9 billion left over for everything else.
Because it's a complex legal issue that isn't in the competency of most companies, getting it wrong has consequences. Since most companies have similar legal requirements, there's enough scale for a large 3rd party. Also, some countries require the local IRS-alike to approve your software if you wish to file certain tax reports. Bad UX pales compared to these requirements.
they have hosted plans as well as allowing users to selfhost and only pay for "support and customization" for anyone needing which works out pretty well for many....
SAP is well and good but you have good alternatives
The developer experience is terrible, simple template changes need a your modules to be "upgraded" which means every change takes several seconds at least.
The quality of the app ecosystem is so bad you almost can't install any non-core apps if you want to be able to maintain your project. And apps are incredibly expensive (250€ for a GDPR compliant cookie banner). Most apps have quite few downloads so you don't know if you get what you're paying for.
The documentation is partially non-existing and you're supposed to read odoo's code to know how things works - which is true, but quite time consuming.
If you google technical questions you find odoo forum entries (which could be ok) that often contain just links to youtube videos or simply bad and out-of-date answers.
Here's a link to a forum post (full disclaimer - of me) about some of the things that kept me from getting things done with odoo: https://www.odoo.com/de_DE/forum/hilfe-1/rant-developing-wit...
These issues are just the tip of the iceberg. I honestly wonder how people working on/with odoo deal with this. Things literally take multiples of the time they should and the whole process is a PITA.
Funny sidenote: If you google odoo developer experience and try to find what others have to say about this, you get their conferences since they're called "odoo developer experience".
Does SAP even have ERP in the „real“ cloud?
How common is „three system landscape“ in cloud, like S4HANA? Elastic scaling? No. TCO footprint of an new tenant? Sigh.
I've not yet used S/4HANA Cloud (only the on-premise version), but it looks to me like it's just a hosted version of standard S/4HANA but with various restrictions on what you can customise etc. No real elasticity, cloud scaling, etc. SAP ERP has been multi-tenant since at least R/3 in 1992 (I never used R/2) so "Cloud ERP" smells to me like "we host it for you and call it cloud".
Yes, I am rather cynical at times.
I remember SAP circa 2003. The only think that used XMLHttpRequest (AJAX aka dynamic html) was Outlook web frontend, and SAP web UI. GMail that widely popularized dynamic html did not even existed yet.
Two main reasons:
- It's actually terminal software, that's translated into a GUI from a text interface on the fly.
- The people that buy SAP never have to use SAP. Its interface is not a selling point.
I am intrigued - you mean terminal output is actually parsed, and a GUI view is then generated from it?
E: this would certainly explain the issue of listboxes only having the currently shown items loaded (described by another commenter) - everytime you scroll, the terminal output has to be produced + parsed again
Remember that back in the late 90s SAP had a native GUI that ran on Windows, OS/2 and Unix (Motif-based) and each had their own native controls (a native Windows listbox is implemented differently from a Motif one, for example). Developers would develop a UI in ABAP with platform-independent controls and that UI would be sent over the wire to the client as DIAG and the client would translate that into the native control and data, etc for the end user.
I challenged this design decision when Fiori was introduced and the thing is that statistically the lists are either small or huge. When they're huge, they got touched in less than 10% cases, so by not loading the whole content you save a lot.
It's absolutely not something you just randomly explore. I think that's a more interesting question: what sort of empowerment of employees could you create if the UI wasn't so terrible?
But SAP's moat is elsewhere. You put up with its terribleness because nothing else can do what it does. Beating SAP would require you to reach that, and do something else, part of which could be a nicer UI.
Every detail of the business process is now explicit. Employees have to be forced to work according to actual process. You need quite a bunch training for that. Then employees will find shortcuts to make their own job a bit faster/easier, which will fuck up some cases. You need even more training for that and possibly some redesigns. And all you get from that is depression
a) Engineering: Nobody will rewrite 20 year old views just to improve the UX. In many cases, nobody even dares to touch the 20 years old spaghetti code.
b) Sales: The buyer is not the user. The buyer (playing golf with a sales rep) doesn't give a damn about the actual productivity of what he is buying.
c) Management: There is a solid economical rationale in not giving a fcuk about UX. Over the years, SAP outcompeted and absorbed many competitors that were more interested in UX than golf. Golf won every single time. Nobody at the top understands or cares about UX because it does not bring more revenue, it is a cost.
Source: I am an ex SAP.
Big players tend to do the minimum, either attracting with shiny red herrings or barely doing anything at all. Both are bad UX.
Now I favor ugly but robust UX for business applications. The user doesn't have to love it, it's their job to use it. It just has to be efficient and comprehensive, not pretty
I see this trotted out a lot but are all large companies really that oblivious? Do none of the decision makers talk with the people that work for them? Surely those executives aren't so divorced from reality and common sense that they don't see a problem when people complain that things don't work or if they do, it takes an order of magnitude more time and effort?
Surely there must be some other explanation for the proliferation of these systems other than "execs dumb and bad"?
Executives at a large company are divorced from your reality at your level of the job.
Incidentally, that’s part of the fun of working at smaller companies, though the variance is higher there’s also the potential to work more closely with good earnest executives who also want the company to succeed.
>people complain that things don't work
that's a problem and we're going to have to fix it
>it takes an order of magnitude more time and effort
that's not a problem
the fact that Jane the accounting drone has to do twice the amount of work, or has to hire an intern to help her out, or even wants to quit because the job is so awful now is not a problem
it's a rounding error in the overall cost of implementing an ERP system
a new screen with some new data to show for the exec is worth 20 Jane's and her opinions on the new system
you can't even call the new system unethical or fraudulent because 10 people other then Jane can now stop using broken excel sheets to organize their work
basically Jane is collateral damage
This sounds about right to me. In particular, it tends to partiton the organization into (A) the people whose job it is to plug away at the ERP system (orders, invoices, tickets, etc), and (B) the people who actually do whatever it is that the company does.
(C) - License costs can also play into this partitioning.
Then you hope (and work to ensure) that the benefit achieved for B, by having consistent org-wide information systems to work from, is enough to cover the overheads of A and C.
In many cases, no. In part because the people that do the operational work aren't the same people who work for the decision maker.
Executives want to have successful projects to show to their value to an organization. But usually the board members are unable to comprehend the details of a project. So the herd mentality kicks in. The CTO will seek approval for SAP and provide Gartner magic quadrant BS to give the board a level of comfort.
Now whether SAP is the right tool, or if it inconveniences users doesn't matter a whit to the CTO. All that matters is budget and timeline. The CTO wants to be able to speak to the board and say that the project timeline was met and under budget. All else is a complete non-factor.
This is the crux of why enterprise software sucks: the user is not the buyer.
I jest. But that's kind of the point. SAP is terrible by the nature of the beast. It's a closed off system with specialised developers who require all sorts of expensive certifications. That doesn't make for good developers, that makes for pigeon-holed developers who don't have a lot of competition.
A terrible SAP developer with all the certifications to their name would probably still find plenty of work, because the expectations are low to begin with, as proven by SAP being held in low regard across the industry.
To me, needing expensive certifications to prove your worth (as if...) is a big red flag. I'm a developer who has 20+ years of experience, I recently worked for Apple and other Fortune top 50 companies, I went from startups to enormous companies.
Nowhere did I need certifications. And my past experience was never enough to land a job. I'd have to prove myself in every job application. That's tiresome and feels extremely unnecessary, but it requires me (and my peers) to stay sharp.
Of course, none of the above is very black and white. There are certified developers who are amazing, and there are open-source developers who keep themselves relevant who actually suck at what they do.
But I'd argue that the SAP group of developers have far more developers who aren't very good and grow complacent, oftentimes because of their certifications. That, combined with a closed-off system, bad documentation, a lack of online support, and a much smaller community, will MORE often lead to software that is of lower quality.
There are of course the certified consultants that work for clients of SAP. I can however understand why they need certifications. It's probably impossible to configure these systems without some kind of special education in them.
And as for the quality of SAP devs.. I work for SAP and I have met many very qualified developers at the company. Far more than I anticipated before joining the company. Quite a few have been poached by Google et al but that is another topic.
Why did AWS, a group probably fairly technical savy and a direct competitor to its vendor, take so long [1] to migrate from Oracle?
Why does Google, as of today, have job openings for SAP in its Rev Rec division [2], and more widely in areas touching [3] “ SAP ERP domains (e.g. Finance, Revenue/Cost Management, Billing, Materials Management, Sourcing, Procurement and/or Inventory Management)”?
Granted you could say, and I believe in one of the many google “corporate biography” books Eric Schmidt allegedly worked through this same problem: hey is an ERP a product for us? A core competency? Should we build it? [Seems HN discussed this in 2021 already, 4]
Conversely, given the wide ranging scope of random things Google has built and how naively simple accounting and something like a fixed asset ledger looks at first glance…why did they never do it? Surely not because building 7 conflicting chat tools was a priority.
My guess (as a non developer) would be it’s crazy hard to build SAP. From personal experience even QB Online has a daunting level of “backwards compatible” complexity [5] in its data scheme even coming from an accounting background. The API keeps versioning up incrementally and you’ll find gems like “XYZ local French Tax” and other accumulated baggage. As an anecdote, using arguably a knowledgeable vendor, as of a year ago it wasn’t possible to populate a full simple profit and loss statement via Fivetrans ETL tool [6], even though they did a phenomenal job in mapping out the ERD compared to anything else that existed imho [7]. CDATA let you run SQL queries, but the complexity of scripting some of the reports was much more fragile. The community even built a DBT layer [8] and given how cumbersome it was to generate even just the “Revenue” line on the P&L out of a simple non-enterprise tool like QBO, SAP seems 1000x harder.
That’s probably why everything in-market, post-sales cycle is garbage. But hey, someone in a dorm room might be working on replacing SAP right now :)
Note: this excludes versioning, which I believe Workday does every six months, which is also a bunch of work twice a year.
1. https://aws.amazon.com/blogs/aws/migration-complete-amazons-...
2. https://careers.google.com/jobs/results/142858723165905606-r...
3. https://careers.google.com/jobs/results/118792275728704198-s...
4. https://news.ycombinator.com/item?id=26706991
5.(imprecise but good starting point) https://developer.intuit.com/app/developer/qbo/docs/api/acco...
6. https://fivetran.com/docs/applications/quickbooks
7. https://docs.google.com/presentation/u/0/d/1u0dnyq5L_rcEgR2_...
8. singingfish ↗ I think ERPs are a basket case category generally. I've worked with SAP for a few years (or more accurately work hard to keep it out of scope for what I do) in my day job. I've also worked for a company providing ERP stuff for SMEs (mostly S). Aeolun ↗ I kinda feel like SAP is the ultimate in checkbox checking. If you ask every department what they need, and write it all down, then find the product that matches all the checkboxes, SAP is it. hef19898 ↗ SAP checks most of the boxes of almost all industries you need to run a modern business. Some specifc domains better than others, sure, but none are actually bad or unusable. And all tjose functions are integrated with each other. That alone is tremendous value. Aeolun ↗ > Some specifc domains better than others, sure, but none are actually bad or unusable. hef19898 ↗ Some weaknesses I see with SAP compared to dedicated solutions are in logistics and warehouse management, process industries (e.g. continious chemicals production, SAP is way better for discrete products and still it works just fine for the pricess industry), aerospace MRO (SAPs aerospace and defence package is more geared towards production) and eCommerce (eCommerce as a business is not that complex). Mvandenbergh ↗ I think part of it is the problem space to be honest. SAP basically gets used to glue all the fiddly bits of organisations together and I don't know that there is an approach to that set of problems that doesn't get tangled up in corner cases. cgeier ↗ I would disagree that the UX is horrible. mrmaloke ↗ I would disagree with your disagreement and instead argue that the UX is indeed horrible.
Anyway SAP/ERPs aren't code for running your business. They're code for running code to run your business. Now you have all the shortcuts SAP made to get stuff out the door, and on top of that you've got all the layers of shortcuts your business has made to get things out the door too. Therefore lots of nasty difficult complexity.
And finally I've seen evidence that in SAP people treat it like the fundamental abstraction layer is the spreadsheet[1]. So like in unix everything is a file, in SAP everything is a spreadsheet. This is a nasty complicated fundamental abstraction without the natural elegance of Unix's one.
[1] Maybe it really is, maybe it isn't but that's how a large chunk of the ABAP code I've seen treats it.
I’m fairly certain most of them are bad. You don’t make an everything monster and have things be good. They’re likely at best adequate.
Basically, if you are a manufacturing company SAP is easily among the best solutions out there. Added benefit of using an ERP that litterally everone else is usong as well: you have a way larger pool of people to recruit from that know the system. The less market pebetration an ERP has, the harder it is to get people who prwviously worked with it. That means higher training efforts, more need for external cobsultants and performance issues until your emoloyees adapted to whatever ERP you have.
With a lot of the nice looking web based apps we're used to looking at, the UX and the target domain evolve together and if there isn't an elegant way of doing a particular operation then there's going to be pressure to drop that operation entirely. SAP deployments always have to do everything in the organisation so complicated corner cases either get dropped (bad) or end up with suboptimal interfaces (also not great!).
It definitively is neither pretty, discoverable nor intuitive, but in the hands of experienced power users (who have spent a lot of time learning the UI), it works really well. I have seen people (who have used the system probably for > 10 years) dig the most arcane information out in seconds, navigating through about ten different views without ever touching a mouse.
It's a UI from another era, but if you take the time to learn it properly, it can be very efficient.
SAP is very inconsistent across different views. It's not about learning a different concept, but memorizing each little detail.
On some forms you need to press <enter> to get to the next one. Sometimes it's clicking a button. Another time it's <F3>.
You can become a pro in SAP UIs, of course. But it's tedious and your knowledge applies nowhere else.
Also you can re-write everything in Rust https://blogs.sap.com/2020/07/23/learning-rust-with-cap-part...
But other than that, I haven't found time to continue with that project. But you can check out my YouTube channel for future endeavours: https://www.youtube.com/channel/UCFU7a7OMYfcpjtIpu2j47_Q
https://github.com/NTBBloodBath/doom-nvim
https://spacevim.org/
Already happening: https://apphaus.sap.com/location/heidelberg
It is not feasible to rewrite it in the fancy language/technology du jour - huge waste of resources for things which already work fine and at the moment you are done you have to start again, since the IT-pendulum is traveling in the opposite direction.
We, as an industry are really bad at working with legacy code, but for a lot of us it may be the main task if we endure this line of work for some decades more.
Small problems benefit from small tools. Large problems benefit from large tools. However, small problems grow and your bet as a small problem is that your tools will grow with you.
In practice, they usually do. If they don't, you end up extending the tool or rewriting it in a larger tool.
So, our tools start small, and small companies use small tools, and the ecosystems grow together. Then, the successful ecosystems end up the next large problem toolkit.
As you're a small ERP SaaS, you're banking on growing with your customers, I presume. And you can make an argument to start on the large tools at the cost of initial velocity, but that's your tradeoff.
I really think the innovation that needs to happen is a system that has a prescribed growth path. Retool/Excel/similar that can compile to a simple app that can adapt to more complex patterns as the need comes.
on't forget rewriting all the scripts in Zig of course.
Yes, the scope of ERP and SAP is so immense that even other software companies that have competency in the business of programming also buy SAP licenses instead of coding their own home-grown ERP system.
E.g. Microsoft, Apple, Amazon, Google all run SAP.
Microsoft even has their own ERP software (Dynamics GP acquired from Great Plains Software) and yet they run SAP. Microsoft sells Dynamics GP to mid-tier businesses but they don't use it internally for the consolidated financial accounting of their complex multinational business.
And in an interview about Google's early days, one of the employees recommended that they install ERP system like SAP and co-founder Sergei Brin was skeptical saying "Why would they need to buy that when their programmers could just code it themselves?!?" Well, Google did eventually buy Oracle Financials ERP and then eventually switched to SAP: https://www.google.com/search?q=google+migrates+oracle+finan...
If you're a brand new YC startup, you're not going to need a complex behemoth like SAP ERP. Maybe Quickbooks or some SaaS service for accounting & HR/Payroll is all you need. However, if the business grows enough (i.e. multinational), you'd be wasting money by paying your own staff programmers to re-invent what SAP already does. Just pay the millions in SAP licenses. It's expensive but still cheaper than trying to do it yourself.
This should be the SAP tagline. I swear I've heard this since I started working with SAP in maybe 2009(?) as well - I had a brief stint as an ABAP developer.
The first time we brought in someone truly experienced in SAP development, we paid him more than any other developer on staff[0]. I appreciate the different take on SAP. Can I ask -- is it still as lucrative to be an SAP developer?
[0] This was a global multi-national telecom who ran an in-house developed audio conferencing service (written entirely in C++, interacting with a lot of hardware) ... the skillset of some of our devs was incredible, which made this all the more surprising.
It may take just as much talent to write interfaces for obscure audio hardware and deal with janky bluetooth edge cases, but that doesn't mint the same $$$$ as a SAP guru who refactors a business process to be more efficient.
I took a brief look at the ABAP wikipedia article and this insanity [1] stood out to me. I think after a decade of SAP you are too brain-washed to give an objective opinion anymore.
[1] https://en.wikipedia.org/wiki/ABAP#Spaces
But lots of domain specific languages have idiosyncrasies. The Apex language used to program Salesforce is a half-implemented clone of Java from a decade ago. And they didn't cherry pick the best parts.
I do see how Fiori launchpad is a great thing, how HANA is extremely powerful if you know what you're doing. At the same time I couldn't stand the corporate culture, QA processes and etc anymore. There're innovations and innovative teams but for the most things SAP is doing, software development is not the core competency.
Fun fact: I work with Datapath now (if you know what it is then you get an irony)
SAP sells you a software system that includes ready-made workflows and battle-tested instruction manuals. Plus they can synchronize your purchasing and sales departments with everyone else that also uses their software. So if you want to start a small company working with the big car manufacturers, you buy SAP and suddenly you can send quotes in precisely the format that VW expects, because you and VW now both use the SAP specification. In that regard, signing up for SAP is quite similar to signing up to be a Subways location.
But I've written my thoughts about what ERP is:
https://www.integrated.ee/posts/the-erp-software/
You need to get some certifications?
Sap's secret sauce was understanding that different companies have mostly the same needs. All have employees that need paying and maybe shifts to be tracked. All generate invoices. All buy stuff from suppliers, etc. So they built different solutions (HR/FI/etc.) For those needs. All running on the same technical platform with its own programming language: ABAP. All domain code is ABAP and everything is readable, you can even debug code that SAP wrote years ago but (generally) you're not allowed to change it. And it's full of comments in German so good luck :)
For medium to large companies it's a no brainer to use SAP so most do. For example Sap keeps the client's systems compliant with new laws. Say some country changes laws on how employees pay taxes, sap updates the code or tells their clients what's needed to update the systems.
Companies that have been around for a few years, most likely they already have SAP so makes no sense to shift to something else.
SAP's ERP code is also quite generic. Tons of configurations are possible in any module. E.g. you may have employees but no shifts. Or maybe you have 200 different shift patterns across many factories to configure. Configuration is so complex it's a well paid profession in itself: the functional consultant.
When that config is not enough to implement the requirements then developers can modify the system. Either changing existing ABAP code, or building new ABAP programs or (more commonly nowadays) just building webapps with the normal tools (react/node.js/java etc) in the cloud and using sap ERP as a backend to read/write data to. This last one sums up my day to day.
ABAP is interesting though. Syntactically it looks like COBOL and that you've gone back 40years plus most of the DB tables/columns/data types have seemingly random names like WERKS or DMBTR. They make sense in German after you've shortened the German meaning to 5chars :). So ABAP code looks very cryptic at first sight.
But semantically the language is ok. It is strongly typed, has some nice features for working with finance programs (e.g. fixed point arithmetic) and an OO model that feels familiar to anyone that knows Java (e.g. single inheritance).
* Compliance * Standard Processes * Interoperability between companies (a lot of purchasing runs automatically through some sort of SAP Software)
What mostly fails in my experience is the customization. Everybody thinks their process is super special and important and needs 100 escape hatches. But if you ask them to draw their process on a whiteboard, they couldn't do it for one single process without drawing 100 question marks.
That is where SAP shines: The whole thing is so bureaucratic, coming from Germany, which is something you will need after your company has grown beyond a certain size.
I'm not sure why in the early days they were more succesful than the competitors (JD Edwards, BAAN, etc) - all of the others were doing something similar but SAP overtook them all. Perhaps it was because the system was very flexible - if you needed to enhance the SAP-delivered functionality or build your own to integrated with SAP, they delivered tooling to do so (very crude in the early days, a lot better now).
Related to this is that almost all application souce is available to customers (not open source, but available to view and modify if required). For those who've never worked with SAP, the majority of the application code in their on-premise systems is written in a proprietary COBOL-like 4GL called ABAP. One of SAP's key differentiators in the early years was that customers had access to all of this code and, with the required access, could extend/modify as needed. A masterstroke IMHO.
Source: I've worked as an SAP consultant for 20+ years (including a fair number of those working for SAP) and I'm no fan of any of their products. For the number of extremely intelligent people who work there (and I mean that sincerely - a lot of their employees are /extremely/ smart and forward thinking), the code quality and quality control of their products is abysmal. It's like the majority of the code is written by people who did a training course last week and they /love/ overengineering things, reinventing the wheel or backing the wrong horse. SAP went all in on Silverlight at one point and these days they love OData, which NO-ONE really uses. It also took them years and years to officially support a browser other than IE.
At times they have done some pretty forward-thinking things though. In the late 80s they adopted three-tier before most (R/3, the first three-tier release came out in 1992) and they cleverly have a very portable application. Back in the days of the Unix wars SAP ran on pretty much every OS and all the major databases (heck, Microsoft had to convince them to port to NT and SQL Server, primarily so that Microsoft could run SAP on NT in their own back office).
Rambling a bit here but SAP still pays my bills (and fairly well at that), but I'm no fan and I'm always looking for a way out. Unfortunately, for me the situation is like many SAP customers - once you've checked in, it's hard to leave (apologies to The Eagles).
It mirrors a dysfunctional business run on command-and-control rather than, like AWS, you have a large set of loosely affiliated teams and although you risk some duplication, it makes for much more agile work.
Imagine you have a supplier who supplies "products" but your system calls them "items", SAP would say that you have to standardise the nomenclature. Agile says, let them call them whatever works for them and lets build small systems with just the interfaces we need.
Sure, the senior management don't get their dashboards but it is still possible to get metrics from disparate systems and form pretty basic cashflow and inventory reports.
One has to remember that many large companies don't have an in-house set of software engineers to kludge things together, or a set of people to audit and make sure problems aren't accumulating silently somewhere because of some bug or some vendor changing their API or whatever. Even if they did, the supposedly "agile" solution proposed here just sounds rather fragile. You even see this in codebases that are built on a "microservices" mindset -- you start getting weird emergent patterns in internal dependencies that start bogging things down.
For a smaller or even medium-sized business, sure, maybe a custom solution works. But it looks like for the scale of organization SAP works on, it seems difficult for an individual to even understand all the components of that organization, let alone build something maintainable for themselves and their eventual replacements.
I used to think this, but then I started interacting with actual end users (normal, non-engineering people). There are 2 main problems with exposing more barebones stuff to non-engineers:
1) Problem solving (thinking about how to compose the raw primitives) takes a lot of creativity. Most normal people only know what end outcome they want, not how to engineer their way there*. The reason wizards are so common is because they address this exact need. Wizards try to figure out what you want to do via a series of questions (and then do it for you) rather than have you come up with how to do it yourself. They are so common because when designed correctly they work very well!
2) Understanding errors is also very hard. Just because something didn't fail doesn't mean it worked correctly. Sure, anyone can file a transaction into a database, but they can just as easily file an incorrect one either by mistake or due to inadequate understanding. The complexity of the systems are their to catch problems before they become problems.
Sure, sometimes there will be corner cases that aren't accounted for by the existing system. And these will be frustrating. But taking away both the end users' guide and also removing their guardrails just so they can maybe solve the problem themselves is not generally a great idea.
*: This is not meant to disparage the normal users, but different people just have different interests and goals. Not everyone should be forced to know exactly how a machine works just to operate it.