I feel there is a lot of room to develop better tools that are not so horrid, however, the process for replacing SAP will be long and close to impossible. SAP feels like one of those businesses that’s too big to fail because it’s so entrenched in the corporate world. Somewhat jokingly, I think it would be easier to switch the US over to the metric system. Any challenger will have to be massive, accept losses for over a decade to gain market share, and have incredible support for their clients if they ever want to takeover in the Fortune 500 world. Challenges too great for a mere startup to accomplish.
It’s easier to just hire people to learn the SAP workflow and then hire external auditors to make sure the accounting policies are properly being followed.
A new general came in and insisted on using SAP. 6 months later, they had to rebuild both warehouses.
EDIT: For some additional context, the system managed to basically eliminate the "bull whip effect" all the way down the supply chain. It's really a fascinating system. Developed by Dr. Bill Kernodle and Dr. Steve Davis from Clemson Apparel Research.
It’s a really broken system that no one seems interested in fixing.
Authored by Joseph W Kernodle of CLEMSON APPAREL RESEARCH.
Later I meet a former procurement officer who was reprimanded for excess purchases in the year leading up to the system launch. In the end his team was the only one able to provide equipment for an extended period of time after the new system was introduced. Everyone else had relied in JIT supply chains, but this guy didn't believe that the new system would work and spend a year building up inventory.
In this case, it sounds like they should’ve bolted the JIT platform onto SAP
I developed a custom engine for things like aluminium rails, and thermal sensors, to generate a new product with the production tree in SAP, so it would be able to decrease the right ammount of raw materials from the warehouse.
Probably not. SAP is an everything-to-everyone product. Using Fred Brook's terminology for essential versus accidental, the problem with everything boxes is that even just the essential complexity of such a product is so insanely large that they are sufficient to produce a "horrid" product. Of course they don't have just the essential complexity and add a healthy dose of accidental complexity, but so would any putative "less horrid" replacement by the time it successfully solved the same essential problems as SAP.
Closer to home, "bug tracking" is an example of an everything-to-everyone product. I can't even count the number of times I've seen a "simpler, less horrid" bug tracker get started due to the perceived horribleness of the current bug tracker, but the new bug tracker simply became the old one once it tried to grow into the same niche. This may sound strange to 2022 ears, but I remember when JIRA was being pitched as the simpler solution and developers were pretty keen on it. There will never be a mature bug tracker that is any fun to use, because by the time it's everything to everyone it'll just be the same morass of being everything to everyone again. It turns out that the "less horrid" bug tracker wasn't actually intrinsically less horrid... it just wasn't everything to everyone. Instead it was a bug tracker for developers, so developers love it. But then if developers are going to be allowed to use it everywhere, it has to satisfy all the other stakeholders too, and it inevitably mutates into an everything for everyone product.
(See also: Salesforce. Letting users configure custom DB schemas is a key indicator of being an everything to everyone product. To some extent, programming languages too; there's a lot of people who pine for something simpler (such as the people who think that if we just went to visual languages, or tried to jam everything into "no code") and don't understand that by the time you have a general purpose language that is truly general purpose you've got a large amount of irreducible essential complexity whether you like it or not.)
https://www.thirdstage-consulting.com/the-biggest-erp-failur...
Larry Ellison had a famous quote from some Oracle ERP event where he chucked every Oracle ERP consultant under the buss by saying: "It doesn't do everything you want, but it does everything your business needs". He was referring to custom workflows business take on which require massive customizations of ERP platforms, increased consulting costs and a painfully hard upgrade process.
Switching costs and risk are the major reasons these systems stay around forever. If you've got something that works. Even if it's sub-optimal, you're never going to move away from it. I worked at a place that used an ERP from a company that went out of business, so they would install DOS emulators for a really ancient version of DOS on every computer for people who needed access to the ERP. This was seen as a better solution than the perceived risk of switching ERPs. This was 10+ years ago, but to my knowledge they're still doing this.
Apparently Stanford had its own homebrew system, and some dean had decreed that they had to move to Oracle Financials. For literally years, these poor people struggled with it.
I never worked with that or SAP so I can't compare them, but I think both are the Full Employment Act for consultants.
Most organizations have horribly convoluted organizational structures and processes, and SAP has been shaped by those customers over the years to cater to those clusterfucks.
A clean, sensible ERP system can only work if the organization it serves is also sensibly organized. It is much easier (and less risky) for a company to choose an ERP system that caters to them, warts and all, rather than overhaul the way it conducts business.
As the old saying goes, SAP and its customers deserves each other.
For every "We had a great internal platform that we custom built" story, there are multiple "We used a small vendor's product, and it was a nightmare."
Why is SAP successful? Because the general purpose tools (or worse, amalgamations of multiple single-purpose tools) that came before were absolute shit, and SAP is instead only difficult to use.
Progress!
(Also, a TAM that is literally every company, ever)
It seems like it, but I don't think it is possible. Sure you can clean up SAP itself a bit, but most of the problem is custom UIs that companies develop only to the point where they are useful, but then they decide it is cheaper to train people on how to use the clumsy UI they have instead of paying developers to clean it up. They probably are not long, it only takes a few minutes to train most people on the how to find the few things they actually need, and the slow workflow costs them a couple hours per person per year (and most of them are low wage employees), while cleaning up the UI would costs several man-years of programmer effort.
Now they are migrating to the cloud, and loosing customers as they push them off their on prem s0lutions
Clayton Christensen has some nice youtubes about disruptive innovation where he predicts the death of SAP
What it turns into is another story though :-).
Personally, I rather liked the approach that Oodoo takes: https://www.odoo.com/
It tries to be pretty modular and even the cloud hosted plans can be mixed and matched, in addition to which the apps can be self-hosted for free: https://www.odoo.com/page/all-apps
Of course, attempting to compare it to something like SAP is a bit like comparing OpenProject with Jira or something along those lines: where one of the solutions is way more popular and recognizable, even if the other could be serviceable in certain scenarios. It's pretty clear which one will be picked by most of the enterprises, though.
SAP is the "European" way of doing things, which means there's one right way and you need to align your business to SAP's way of doing things. If you do that, things work very well.
Peoplesoft is the "American" way of doing it, which means that you make your software fit around you. This means a lot of customizations. This makes integrations much more challenging if you're too far off kilter, and things like upgrading is much much harder, because there's too many customizations.
That's the information I had about 10 years old and not sure how much SAP has evolved since then.
Smaller companies these days have a lot more options, like Netsuite is already there for small businesses and Workday is moving in that direction. Startups come and go every day. Rippling appears to be one that is headed in this direction as well.
I used to work at a company building software that competed directly with SAP products. The IT people in our customers’ organizations were the hardest people to convince to adopt our software. The end users loved our stuff because it allowed anyone at the factory to build forms and share data. But the IT folks would always get in the way.
“Nobody got fired for choosing SAP.”
Competing with them is super hard because of that.
Alternatives do exist. Well, one does - Oracle ERP. Migration is indeed long and close to impossible, and it’s very much out of the frying pan into the fire.
We've spent 3 years refining our processes and automating our ERP system, both the data structures we need and the design of the UX. No thank you SAP
Yes, it does it correctly for tax purposes everywhere and can be used in a way which conforms with how these companies want to do their accountings for shareholders reporting. Also it used by so many companies that every niche thing you want to do has probably already been done.
The people here complaining about the UX for reporting their hours just have no idea of the mind boggling complexity of the problem space. There is a reason everyone use SAP and it’s not because it’s bad.
A few years ago, I was working for a small, family owned industrial company. They were in the process of moving all of their ERP stuff over to SAP. Things were slow with some of the UI/UX stuff I was working on and someone asked me if I wanted to learn how to be an ERP developer.
Before I was shown anything, the SAP guy pulled me to the side and told me, "Fates, I know you could probably write a DB program significantly faster than what you're about to learn, but this is just the way the software was written."
Cue several of their SAP people dropping random stuff in my lap and me taking days and sometimes weeks to discern how to do it in their UI. It was the most maddening thing I've ever tried to learn. I just remember this graph paper like grid and having to line everything up perfectly or the program wouldn't run at all. I felt like I was working with something from the 1970's, it felt that out of date.
I finally told my boss I couldn't do it anymore, it was driving me mad.
On the flip side, I play hockey with a guy who is an SAP sales person and makes hella money selling their software and thinks its the greatest thing ever.
I don't know about SAP, but one of the main reasons we're adopting Retool internally is because our engineering team keeps deprioritizing writing internal operational tools in favor of adding features for out customers, yet our operations are becoming increasingly more complex. Something like Retool lets our end users (our own staff) be able to work with it.
In a lot of ways, Retool is more like an MS Access, only it is a cloud native SAAS and from the get go, work with integrating existing databases. Writing about SAS, I think it's clear Retool has been thinking about how to grow with the organization, possibly where organizations can stay with Retool instead of trying to implement SAP. I'm also curious about how they are going to work with the increasing shift from "data lakes" to "data mesh".
Fresh out of college, with a full two week (!!!) training on the product, I was sent to a customer place, to build some forms for them. Apparently they were not important or big enough for senior people, so I had the privilege (!!!) of building forms using our software for this client. I spent two days building the perfect form, then suddenly all the layout was lost. I couldn’t recover the layout, I call my team. They casually say our layout engine can be finicky sometimes and will refuse to work if you annoy it too much. No one told me though.
Thankfully I found another job soon.
Many of these so called enterprise products are terrible. But they’re so entrenched that it is next to impossible to beat them. They’re also expensive and their business practices dubious.
For many companies it would be easier to do an asset sale of all their IP than to replace the ERP.
Since most ERP implementations are horrendously overdue and over budget, they are usually declared Done before they’re actually finished. That leaves a lot of crud and manual processes in their wake.
In addition, so many of these systems are on prem using hardware, operating systems and databases that haven’t been supported in decades.
I’m getting nightmares just thinking about it!
I'm sure their goal was to eventually replace SAP. Instead, I think they ended up with an 80% solution that requires the customers to invest 20% as much time as a full SAP setup.
For instance, Salesforce spends a lot of effort on sales and customer facing things. SAP does that too, but it also does logistics. Logistics infrastructure is much harder to reuse across industries than sales and customer support.
True. Making something with a less sadistic and convoluted UI is the easy part. Migrating the data is the hard part.
Many companies died from updating ERPs.
They protect and take care of a lot of problems, the issue is they're so flexible that sometimes people build ad-hoc things on top of them and over time it becomes a ridiculous monstrosity similar to any other system in a company with major legacy.
There is no inherent solution to this problem other than disciple (or control, which has it's own productivity issues).
A lot of things developers must build in, and decisions developers make, are built in already for these systems.
more likely situation would be the companies stuck on SAP themselves dying and SAP eventually dying as a result of that. Obviously that's on a long term timescale, but smaller companies not burdened by legacy technologies winning is pretty much the story of modern business
It's probably also too boring for any tech entrepreneur to even try, but disrupting the space would seem to be the white whale of startups. You never know. At one point in time nobody had a computer on their desk either.
Isn't that where Salesforce came from? At least in the CRM space. It is not as horrid, though that is not saying much :P
And yet somehow last time we had this discussion on HN, more of than half of the developers have never heard of SAP.
Sorry friend, that is not a joke - at least this was attempted once! :)
These go hand in hand
I have a family member who has had enough professional success with SAP; when I mention projects there is a specific response he has that relates to this.
tl;dr- If you change your processes to follow the SAP happy path where they don't you are OK. The more you go out of bounds the more problems you have (be they problems of kafkaesque workflows, or paying the bills to customize it while the scope of customization keeps changing.)
I don't know how true that is, but it's there.
SAP removed virtually every automation advantage of the old system, and added the additional complexity of navigating the SAP GUI. Because of this additional workload and the reluctance of the company to hire more people to counter it (after all, SAP was implemented to streamline everything!), employee turnover suddenly skyrocketed. Everytime I talk with my mother, she complains about the system and tells me that another colleague has quit. She only stays because she only has 2 years until retirement.
I don't work with SAP, but I've been working with Microsoft's ERP(Dynamics NAV/Business Central) my whole professional career(almost 5 years).
When it comes to shipping, manufacturing, HR, supply, sales, planning, quality assurance etc... every big company is going to have a million edge cases which are impossible to cover with the standard functionality of an ERP. And most importantly - hundreds, or maybe thousands of employees that have gotten used to working a certain way.
When you try to make your process fit to a standard ERP functionality you are fighting two dragons:
1) Working your way around edge cases - with the right consultants/developers this doesn't have to be a big pain.
2) Getting your employees to change the way they have been working for years, or even decades. And in addition giving them an overwhelming UI - I've never seen this work as planned. This is also probably the reason the company your mother works for had so many pains.
On the other hand, if you try to make the ERP fit to your processes, there's only one dragon you need to slay - extending the ERP's functionality.
I can only speak for Microsoft's ERP, but everything that is impossible or hard to extended within the ERP itself can easily be extended through an outside application. And by doing so, you can probably even make the employees job easier by keeping the process the same, but giving him an UI that isn't overwhelming.
That depends. I’ve seen a lot of adaptation to processes that are legitimately & measurably better in time & accuracy ignored in favor of costly customizations out of nothing more than “not created here” syndrome. If a customer doesn’t like that then an off the shelf product is the worst choice they can make unless they are prepared to hire a significant in house dev team.
Otherwise, if you have been adapting your current business processes to deal with the limitations of a legacy system first deployed in the early 80's then there's an excellent chance that at least some of those things can be done more easily in a more modern system. (Though SAP may not always be the best place for that to actually be the case).
Every. Single. Customization. You make, which makes so much sense to seemingly eagerly satisfy the user during implementation, will be a massive pain, forever, with every patch and upgrade and new functionality released by vendor in perpetuity, and will inevitably cause performance and failure issues eventually. And will only be getting more expensive and painful to maintain exponentially over many years.
Yes, you should customize erp for your very specific edge cases that you a absolutely need. But:
A) number of processes Bob from accounting or Fatima from HR believe are absolutely crucial and immutable and special and unicorn and mandatory, is way way higher than processes which actually are special and must be preserved. Personal inertia is huge. More often than not, special ways of doing things which are not your core business are an unnecessary cost, whether through erp or not.
This may seem like I'm a traditional grognard IT head who disregards users and their needs, but it's quite the opposite so let me clarify with
B) The threshold of customization at which erp no longer makes sense is in fact very very low.
If you actually, really properly are a special snowflake of a company and your convoluted hr or finance or pay processes are your key immutable competitive advantage, then don't get an erp. Other name for erp is cots, commercial off the shelf, which strongly hints as to how its meant to be used. With erp, customizations should be fought tooth and nail on every level,and that's a largely accepted industry wisdom.
> I don't work with SAP ..
Yeah.. that's just it. Your experience doesn't matter. Adjusting your business to fit SAP nearly as much as an unspoken requirement. It's not just a smart bit of wisdom people throw around. It's literally what you have to do if you want to have any hope of implementing SAP successfully, because it is such a colossal, messy charlie-foxtrot that there is no hope otherwise. Not even SAP's own people understand their own mess.
Adapting Dynamics ERP to business process is a challenge of its own, and not every company can do it. At least it's possible in Dynamics, SAP is a mess - most customers I know with SAP have to use external software and import/export for significant customization.
But then, did you really gain anything by using an ERP instead of just a dumb database, which would have worked just as well as backed for those applications?
Is this facetious, or unintentionally so? Do you mean you need to replace one in-house staff with between 3 and 5 and presumably very expensive consultants?
The most obvious failure modes are going for the lowest bidders incentivizing them to deliver with a skeleton crew, trying to nickel and dime the budget cutting features or their scope or straight up coming at the table with no documentation of how orgs own internal processes actually work.
I know of no project failing because of sap or their consultant on its own without any of the above comorbidities.
Whether it is worth it depends a lot and is hard to say. It will certainly demotivate many employees who are used to the old way, but might lead to streamlining (partially due to software, but norendue to analysis) and more insights (with risk of then optimizing the wrong metric)
In my experience, what demotivate them is that a lot of the features in the marketing materials for these types of products are lies and they are filled with bugs. The executive who chose the product typically don't use it so they think it's a great tool. When you report major problems or workflows that makes no sense, they brush it off like it's just small details that need to be ironed out in the future because aren't the ones dealing directly with them on a daily basis.
The exec get sold on an AI feature and it's the intern who is then forced to deal with a search bar that take 2 minutes instead of 0.5s to search and gives you vastly inferior results.
By the way, edge cases, if if they work in a legacy system, are a thing to get rid of during a SAP / ERP implementation. Most people see ERP systems as IT projects and fail. ERP projects are at least as much business reengineering projects as they are IT projects.
Anyone who's ever worked with ERP software knows the entire system pushes you to do the reverse - adapt the business to the ERP. Going against that flow is possible, but expensive. This is especially the case with SAP which was always even more difficult and expensive to customize.
Unfortunately I don't think this is realistic scenario because when you start a company you probably don't have time/money or need for SAP or anything like that.
Here are things upper management doesn't consider:
* Picking the same ERP solution everyone else in your industry uses means you have zero competitive advantage now. Homegrown solutions with teams staffed to run them could give you an advantage.
* You need to pay expensive consultants to do things with ERP. If you want any customizations they will be a bottleneck for all future updates, possibly having to bring in expensive consultants every time you need to upgrade.
* The culture shift for employees is usually negative across the board. The IT people supporting it, the end users inside the company, basically the choice implies that management doesn't value its people or their thoughts on how to do their work.
* Vendor lock in. Switching from one ERP to another isn't likely to happen. They can raise their licensing/cloud costs when contracts are up and your company is likely stuck.
It would be like interacting with other people who knew based on the average of everyone on Earth as opposed to dealing with the person you knew based on their own personality.
But it's easy to manage based on these kinds of broad generalities and, as the saying at least once went, no one gets fired for choosing IBM.
"Successfully lead SAP implementation bla bla bla saving bla bla bla streamlining bla bla bla"
The pointy-haired bosses of our nightmares are real.
I used to be a consultant for a big non-SAP workflow product. Had a long time employee quit specifically because of how bad the product was. That was not an easy thing to explain away.
The complexity of the task is eventually discovered in production.
The short answer is that a sales guy in a nice suit took some execs out for steaks and more than a couple cocktails.
The long answer is that management, these days, is trained to outsource everything while still being clueless about what the people they're replacing actually do.
If the software needs to change due to industry changes or regulations or something like that, it will probably be a lot more expensive to implement it yourself compared to using an off-the-shelf tool developed by a company who's sole purpose it is to respond to those kind of changes.
It’s infuriating as anybody below senior management can see right through it
Is this the story of every migration, every rewrite though?
A system completely broken forever is something only the upper management can create.
The real problems are
1) organization staff on the implementation who don’t actually know enough edge cases etc. This can be through poor requirements gathering ir because the power users are considered too important to take off their normal work and the company is too cheap to hire enough temp staffing to cover their absence.
2) A bad “fit-gap” analysis the maps old system functions to the new system to find the gaps. This is the vendor/partner (consultants) job so that’s on them. Failing here sets the project up for failure or major cost overruns or just years of people pissed if that they can’t do what they need to do. It also breeds shadow systems and work arounds that make knowledge transfer after staff departures vastly more difficult.
3) vendor/consultants looking to maximize $$ by either sandbagging hours of work with unnecessary things like customizations that are just not needed. I’ve seen plenty of examples where vanilla functionality is much faster than the old system but “that’s not how we do it here” . The vendor doesn’t care to push back because they’re getting paid for the extra work, and when the customer runs out if its 1,000 hour block of custom dev time and still has essential work undone the customer has no choice but to pay up or suffer. Meanwhile the vendor has every email and change request order signed off in their records where the customer approved the work so they just shrug their shoulders.
4) A general unwillingness by the customer to actually pay the $ required to do these things right. There seems to be a sense in higher level leadership that “it’s software, how hard is it to install software?” and have no clue and don’t care to hear it until the sky is falling that there’s a lot more to it.
There’s more too, but I’ve been on a few of these and never seen one that didn’t include some combination of the above. They absolutely can go smoothly with a minimal amount of the above but it takes real work and a dedicated procurement & vetting process just to find the right outside implementation partner (going with the vendor itself is sometimes okay, sometime not. I wouldn’t touch Oracle Consulting ever ever.)
Even then it will not always be as smooth as using a legacy erp with roots in the early 80’s that has been customized for decades. But that sort of tech debt is massive. New functionality can be a nightmare, causing more tech debt and raising maintenance costs non linearly. If it needs regular updates for things like federal compliance (tax systems or other regulated areas) a vendor might when it finally EOL’s a system it first released before you were born still provide those updates to remaining customers of their legacy product to give extra time to transition but then you need to either role your own dev team to do it or pay outside consultants to do so: Retirees from places like SAP often make a nice bit of extra income doing dev work like this.
TLDR: Too late, you already read this far.
And what is the take-home-message here? Should they have stayed with their (admittedly not good enough) internally developed system? Should they have gone for an Oracle solution (plagued with its own set of anecdotal catastrophes)?
Often times it's very difficult to correctly specify a system. This is one of the problems with lock files and why some people have gone over to docker for development.
IMO, the people to blame are management, who needed to appropriately staff the transition for enough time to get it right.
> Should they have stayed with their (admittedly not good enough) internally developed system?
What evidence is there that it wasn't good enough? Sometimes management gets sold on a "better" system, only to find out that it isn't actually better.
Also you can re-write everything in Rust https://blogs.sap.com/2020/07/23/learning-rust-with-cap-part...
Already happening: https://apphaus.sap.com/location/heidelberg
on't forget rewriting all the scripts in Zig of course.
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.
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 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.
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.
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.
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!).
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. https://fivetran.com/docs/transformations/dbt/data-models/qu...
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.
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.
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 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)
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.
Does SAP even have ERP in the „real“ cloud?
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...
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.
Either is SAP though so, who knows.
> There's virtually no competitive advantage to having unique business processes.
Take "Time Accounting" for example. I'm not referring to tracking hourly employee hours for payroll, I'm referring to tracking salary employee "project time." Every past salaried position I've had at a company with more than 90 employees had its own custom time tracking software[1]. The first company to do this was a multi-national telecom that I worked for. It was done so that each project could be broken out into its stages and the portion of the employees' salary could be itemized among "Capital Expenses" and "Operational Expenses". This was so important to the company that it warranted a massive development effort along with a corporate initiative to get 100% of time reporting in "on time." They did this as you'd expect a huge company would -- fail to hand in a time sheet on time a few weeks in a row and you'd get dinged more for that mistake than anything else.
The second and third companies ended up "accidentally developing time tracking software" specifically because there was competitive advantages to improving "Resource Planning". It was most helpful to my last employer. Their businesses was creating new products (often hardware/software combinations) for companies. This involved hiring a large number of people specialized in things that had limited cross-over. Resource Planning was predicting when what skills at what level would be available. This, necessarily, involved tracking what time was spent on projects in the past to improve those predictions and ultimately ballooned into a full time management and accounting application for the business (they sold "our time" to customers at the end of the day so it helped them to plan what to charge).
I'm curious -- from your perspective, is it that the competitive advantage is lost "because the tools that everyone is stuck with won't work" if you stray too far from "standardized" or is there another advantage to this standardization?
[0] Unique business processes and marketing are frequently the difference between the #1 and #2 company in a given space.
[1] In one case (about 250 employee global company), the company wrote it as a concept for a future product but once it was available, the existing solution was tossed primarily because the business side really liked the flexibility. In another it grew out of a pet project and became entrenched. At the remaining two, a decision was made to develop something from the ground up.
I found this hilarious.
That's maybe one or two words away from a literal conversation in a huge meeting with dozens of high-level IT staff overseeing an org with 30K staff and a petabyte of existing Microsoft Office documents.
Boggles the mind that some people think this way, but they do.
Like... imagine an electrician wiring a new office building having a debate about which frequency and voltage to use. "Don't make assumptions!"
Imagine what wiring an office building would be like if all the wires, circuit breakers and tools could only be bought from a single vendor. Boggles the mind.
> Lidl based its inventory management system on purchase prices. The standard SAP for retail software uses retail prices, and fearing the group could lose a competitive edge by compromising, Lidl declined to change, so the software was instead adapted.
https://www.henricodolfing.com/2020/05/case-study-lidl-sap-d...
So you are paying hundreds of millions to get a canned, pre-packaged, inflexible solution?
Why is SAP still in business? Is it solely customer misinformation?
If you go too far, a SAP version upgrade is no longer a drop-in operation, but rather a year long project of porting all your changes to the new version.
If you stay as vanilla as possible, upgrades are a lot easier.
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.
The lock-in is huger than huge. I don't think a single company on earth managed the art of locking in customers as well as SAP. Does anyone ever drop SAP? I don't know: the cases have to be exceptionally rare.
It's a racket. Highway robbery. This kind of behavior brings in a lot of revenues.
I personally do think the sale to the customer is complete and total misinformation. And once you've fallen for it, there's no way out.
Very hard to throw/replace ERP. It might happen but it‘ll take decades for global SAP installed base to shrink seriously.
> Is it solely customer misinformation?
SAP (and other „enterprise sales“ players) sold to CIO with „account relationships“. Then software is shoved down the throat of business users.
First you should know that the market for ERP systems is very wide. There are LOTS of various companies that offer their ERP systems. Also a lot of those "ERP" systems are "enterprise resource planning" in name only. The smaller ones often are focused on one thing only: bookkeeping, warehousing, invoicing, purchase management, salary calculation. Often they started as something that does one thing (usually: bookkeeping) and then more and more stuff was added on top -> as requested by customers. There was this old theory, that at some point each peace of popular software becomes so big that it can handle email. And guess what, SAP can send emails too. Tons of those other ERP systems can send email too. Different thing is if they really should.
The smaller ERP solutions often dont scale well (they cannot handle too many "things" e.g. millions of invoices, millions inventory SKUs, 20 different countries..) or are too simple / not flexible enough to actually customize. With those smaller systems, you can understand them (e.g. the whole system has few thousand tables), but this comes at the surprising cost of lower flexibility, because in order to handle the complicated business cases you have to recreate the complicated logic as well. SAP was used by so many big companies that a lot of the complicated logic is already there in its 'standard' (and as others pointed out: if you want your life easy, you should adjust your company to the standard, instead of trying to customize). Different thing is that you need a consultant to even know that those features exist. And as you can imagine SAP is so big that even the consultants can only focus on a certain part. [also I personally knew a situation where consultants wrote a custom extension for something that was available in standard -> they didn't know standard SAP standard well enough..]
I kind of disagree that a typical configuration of SAP has 20 000 tables. The ones I knew usually had 50 000+ and those were just few "modules". Using SAP terminology you have modules like FI (finance: bookkeeping), CO (controlling - financial reporting), FI-AA (asset accounting -> think list of assets the company owns), SD (sales & distribtion - e.g. issuing invoices). There are lots of those modules and usually the consultants know "their" module + the finance module. Because at the end the FI (finance) and CO (controlling) modules are always on the top -> you want to register the things that happen in financial ledgers and make some reports out of it.
For example: the consultant that sets up invoicing for you will know SD module (to set up the actual layout of invoices - how it looks like when you print it, the process flow etc) and FI (to help you configure that the invoices land on correct sales accounts). Someone else sets up the PM (plant management) module. Someone else handles access rights / authorization (small ERP systems often struggle at this part - and often "everyone can see everything" what is a big no-no in times of GDPR and just batshit insane when we think about corporate espionage).
A lot of complication with SAP comes from the fact that it can do things as per laws of different countries (please note: not necessarily out of the box, usually you need configurations and external add-ons). For example if you want the taxes calculated by the system for USA, Germany, Poland and Japan - then SAP can do it for you. The system (after painful configuration) will calculate the sales tax / VAT tax and also provide data to calculate CIT (I am not sure if any company calculates corporate income tax out of the box, I always saw an expert from SAP to some data/warehouse and a magic Excel file on top). Also laws change all the time, so system has to change all the time.
Even the basic stuff gets complicated once you need to handle it at scale + for many countries e.g. you want to issue the invoice, you need to use the correct tax type (e.g. VAT in Europe), the correct tax rate (e.g. like 50++ rates per each country), then you need to handle things like invoice corrections, exchange rates, handling exchange rate differences, withholding tax. And it is like this with >everything<. Every business activity that can be handled can be cancelled/reversed, what makes the logic of everything convoluted (e.g. when you reverse the invoice 3 weeks after it happened you need to use the correct exchange rate as per each country's law), because the bigger the company the more probable is that they will do something that shouldnt happen. SAP can handle this at scale.
Other thing is that there is a big moat. The process of setting up any ERP system takes at least months and generally years. The article explained it quite well. You need to migrate data to the system, check if it works, see if can handle your cases, train the users (the training part often is ignored, so lots of features are not used). Often the companies also dont have anyone to help with customization AFTER the migration, what is another big problem. It is public knowledge that more than 50% of ERP implementations fail.
There is also some degree of economy of scale. People who used SAP at one company have it easier to use at another. Although devil is in the configuration details. But at least they dont need to relearn the interface (that is awful in most ERP systems).
In a typical big company at some point you need to have your own in-house ERP administrators, who outsource parts of requirements to external sources and deal with the easier stuff on its own. The smaller systems are often inflexible for that - source code is not available. Different thing is if you want to handle the SAP source code with comments in German (yes, that's how it looks in some places; table and column names are German abbreviations too).
Speaking about incumbents: I read that there is some "magic" open ERP system (forgot its name - maybe it was OpenERP), that has just under 20 tables that supposedly can handle everything, but I never looked much into it. Perhaps 20 tables with 1000+ columns each (maybe still better than 50 000 tables with 10 columns each).
And to end it: ERP systems are like elephants. Once you set it up and it "kind of" works, then you dont want to touch it. You dont want another few years spent putting lots of effort on your tooling. You want to deal with actual core business part of the business. The article also pointed it out -> the quote that in some markets being able to implement the ERP better than the competition is the competitive edge is quite true. There are lots of companies with very very bad ERP, or multiple systems that dont talk with each other. What makes reporting hell. (not that reporting in SAP is easy) And without good reporting, the decisions are taken too late, or not at all.
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.
SAP is sold to the C=suit, never to IT or business operations, nor any of the people that will ever come onto contact with the software.
SAP is priced based on your company's revenue. In industry X typical spend on IT is y% of revenue, so SAP will charge you a project for an amount equal to y% of your revenue.
SAP project often fail (this is not specific to SAP but common for large projects). Making sure that in case the project fails it is the customers fault will be strategically taken into account from day 1.
SAP's revenue is for the large majority based on consultancy and education revenue, not on software sales.
SAP's data and business process model maturity varies extremely depending on the industry and business segment. This will not be clear in the sales trajectory and not easy to discover upfront.
SAP is a fairly closed ecosystem. Typically consultants are recruited straight out of school and never leave the stack as it is very different from the rest of the industry. It has it's own cultute and habits that do not travel well outside of it's niche.
Plenty of terrible corporate software works like this. Precurement has a checklist of features, and that list never includes "Has great UX", because only the people on the floor has to use it.
I'm looking at you JIRA...
> SAP project often fail (this is not specific to SAP but common for large projects). Making sure that in case the project fails it is the customers fault will be strategically taken into account from day 1.
I was a consultant at a major software consultancy for the better part of three years. No matter what, it is always the costumor's fault, even when it isn't.
Paying a customer back some 100 billable hours worth of payments is simply just not feasible, when a large part of consultants have less than a years worth of work experience.
While you sit down and talk about the project with senior and managing consultants, you are being deluded with a completely skewed perception of the base level competence of those that will carry out the work.
The higher hierarchical "level" a consultant is at, the less implementation work they'll do, because associates will take longer time doing the same tasks and will therefore sell more billable hours.
The entire T&M consulting industry is economically incentivized to produce organisations that shirks responsibility, while simultaneously work on "too big to fail" projects, because that's where the money is at.
> SAP is a fairly closed ecosystem. Typically consultants are recruited straight out of school and never leave the stack as it is very different from the rest of the industry. It has it's own cultute and habits that do not travel well outside of it's niche.
Not to mention that it has its own programming language. I had a colleague that worked as a SAP consultant, and she said it was horrible. Features like "variables names can consist of at most 8 characters" certainly didn't help.
I always see this comment on HN, I think I have been using Jira for a decade, never really had any major complaints.
I dunno. I find Jira pretty easy to use, like Git. Focus on the main fields/commands and open a new ticket/clone again if you mess up.
/s
BTW, on the last point - ABAP (SAP's proprietary language) has improved a lot over the years. Variable names are no longer so short (a vestige of the R/2 mainframe days) and the language has adopted a lot of features from Java and JavaScript. Not always the best (OOP like it's Java in 1998, woo!), but definitely a lot better than in the past.
The company I work for maintains and has built some custom ERP solutions. While we've never dealt with SAP directly, almost universally the mindset of the IT departments at these businesses is that they are the last defence against the dark forces of SAP.
ERP migration is a terrifying thing and they seem to fall into the same pattern every time. Company has their way (workflows, processes, strategies, philosophies) of doing things. New ERP consultant promises the tool will adapt. Company spends $50M with consultant and product trying to make the tool adapt. Pain loop of "Well, it can't really do X like we said, but we can make it do Y which is close!". Company either a) bends to the opinionated process of New ERP, b) cuts their losses and runs, c) spends years and millions more trying to fight the opinionated process and then cuts their losses and runs, and/or d) goes bankrupt.
It seems to me that the only way to do this right is to spend as much time as it takes nailing down your processes and workflows, being honest with your company about what you need to change, what you want to change, and what can functionally change. Then use the broadest technology possible and create a custom solution. I feel like there's room for a broad business logic framework/library.
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.
In a postmodern ERP there is no ERP.
It’s a strategy where you accept that different domains and companies know their business and processes best and you integrate best of breed systems & services with homegrown solutions.
You trade the convenience of letting SAP or Salesforce own your processes against flexibility and actual agility.
The cost is competence - you’ll need developers working in stable, dedicated domain teams, even within the administrative/cost-center areas such as HR & Finance. But there is a massive potential in this approach. It forces ownership of processes and allows for rapid changes of digitized processes, integrations and technology.
I must stress stability of the teams: agility comes from building domain knowledge and continually working on contracts between organizational units over time. This is the complete opposite to classic project management.
SAP caters to non-tech savvy businesses people striving for control, which is something they think is achieved through “one system”. I personally call it the “one system trap”.
In the end what matters is data, and that data do not have to reside in one database. In fact, it’s better for everyone if it doesn’t - this is what ELT is for.
[0] https://www.gartner.com/en/information-technology/glossary/p...
It’s a strategy. No products. No quadrants. Just a more reasonable way of looking at business IT and enterprise development.
It happens to mesh well with my experiences and it’s sometimes nice to be able to whack “Gartner” about in certain settings - especially when someone’s trying to get traction for a magic quadrant product! :)
And to be fair - this is a thread about SAP and ERP…
When my sister started to working at SAP working on documentation, I had to look at some of those. I noticed something like SAPUI5 and thought: hey, this looks pretty modern and nice and something that competes with Microsoft offerings! https://sapui5.hana.ondemand.com/#/topic/8b49fc198bf04b2d980...
Then I see them documenting/pushing people in CI/CD direction (https://help.sap.com/docs/BTP/65de2977205c403bbc107264b8eccf...) involving Docker, Kubernetes, github and stuff like that. Pretty modern.
I went onto HN to learn how people feel about the development tools they provide and found... nothing. I was like: what? How can they have slick documentation, processes, tools, frameworks, cloud offerings, database (SAP HANA?). So basically I thought - so much competitiveness for Microsoft there. How come HNers don't mention this? What are the people working with this tech? Germans mostly or what? But navigating their documentation, tutorials feels something that could be evaluated as a modern development platform.
It is built on top of jQuery and extremely slow. They are very adamant on MVC with two-way databinding (the opposite of React or most other frontend libraries that have been around for almost 10 years). The backend request is geared toward OData (think graphql but table-oriented), and adding logic between the UI and the OData endpoint is hard.
SAPUI5 is hard to use even for a mediocre screen need. It aims to get the simple apps really simple to write (to lower development cost), but at that it kills the productivity of all the other apps.
Getting back to documentation, after your app is not just some components living in logical islands but have to interact with one another (think getting data from one place to drive another component) most of the time the documentation did not help with that, and I had to resort to debug the whole library internally to understand it.
Add all that to the fact that they don’t even care to support firefox for non-windows users bah
It is really understandable why no one but SAP uses this library. It was made for one use case by sap for sap and that’s it.
Might not have official support, but personally I've never had problems with Firefox on Mac using UI5.
I currently work on a UI5-app at SAP and even though we don't use odata, I honestly don't find the process of developing it all that unpleasant. I found it really quite easy to onboard (being productive within like 2 weeks), though it may have helped me that I didn't really have much relevant frontend experience beforehand.
Some decently cool stuff is happening behind the scenes though. I believe they're working on getting rid of the jQuery dependency, and typescript support is also coming (though still somewhat in its infancy).
I will agree that it's pretty slow though, and very heavy as frameworks go. You can do a good bit to make it quicker, but it will never win any speed awards in its current form.
Microsoft targets the most generic use-cases possible, even more so than, say, Linux. You can do anything[2] with Windows, SQL Server, ASP.NET, Azure, etc...
[1] For some values of never. [2] For some values of anything.
FWIW, I'm a massive HANA skeptic - I think it's overpriced and SAP betting the farm on it a few years ago wasn't necessarily the best option. It's a product that was put together from various disparate components - TREX, P*TIME (from Transact in Memory), etc - and that shows. It hangs together like something made of brown paper and string, with so many tuneables it puts Oracle to shame.
My task was replacing it with Spark/S3 :P
UI5 is a travesty. It is a complete disaster, and if I somehow ended up working on it, I would not put that experience on my resume out of shame.
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.
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".
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
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).
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".
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).
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.
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.
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.
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.
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).
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.
Gotta be fun :)
[ ] 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.
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 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.
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.
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.
- 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
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.
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...
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.
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.
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.
the goal was to create some transparency for the producers and to fight coffee-loss (every step taking a bit coffee away and sells it otherwise).
the project was a huge success. With fast adoption and immidiate benefit for the farmers and village collection centers.
the software behind it is SAP! and they do not even charge for it, they sponsor it - together with Deutsche Entwicklungszusammenarbeit.
Why?
Even though Uganda is not yet a profitable market for SAP.
And not in 10 years. And not in 20 years.
In 30 they might.
At these kinds of numbers, I've got to ask a genuine question here: what's the benefit of using SAP as opposed to rolling your own solution?
From reading some of the other comments here, it sounds like getting your business to integrate with SAP involves trying to fit a lot of square pegs in round holes and doesn't always succeed in the end anyways.
At these levels of stratospheric costs, it seems like it would often be cheaper and less risky to simply use your standard software stack of choice and build a custom web app over a database that mirrors your existing business processes perfectly, and then transform/integrate those processes over time as needed for increased efficiency.
Some thoughts:
* Most companies are not software companies, and most c-level managers are not tech leaders. They treat IT as an annoying expense, like taxes. The idea of hiring software engineers to gather requirements and run a lean process to build efficient software from the ground up on a modern web stack is as foreign to them as setting up a chemical processing pipeline and logistics management network is to me.
* Rolling your own solution takes time, and more importantly, energy and involvement of the whole company. I would argue that it might take less time than a big SAP implementation, but with the latter you can just hire a big consulting firm (there's that cost center again...) and they'll deal with everything for you so your people can just work.
* This is a bit of a chicken and egg thing, but: A lot of SAP's customers aren't startups. If you're hired in the be the CEO of an oil company running major pipelines, you've already got SAP running everywhere. And you do your first big move and acquire a small competitor, and THEY have SAP running too. So why are you going to embark on a huge software development project when a) you're not a software company, b) you're not a startup leader, etc. etc. etc.
Although to be honest, the success (?) the US Government has had doing basically what you propose via the USDC / 18F does give me some hope. But alas, much of the world is too far gone already (sigh).
"We held firm to the NO CUSTOMIZATION rule, we re-engineered our processes to fit SAP. Other than a few hiccups when integrating all aspects of a company that has 100 sub companies, and is under federal, state and local regulation the project basically went off without a hitch." [0]
I've made a living writing custom software for engineering, embedded with engineers, that fixes problems with these monstrous systems, and which IT could never implement in 100 years.
So, yes, companies with CIO's who want to make a name for themselves (and probably collect a kickback in the process): PLEASE continue to implement these hundred-million dollar IT systems. You MAKE a lot of extra work in the process, guaranteeing job security for everyone who has to use them, and work around them.
You'd think that Fortune 100 companies would put people into positions like the CIO or CTO who are sharp enough to understand how this REALLY works out, but I guess those kinds of people aren't politically savvy enough to reach that position.
At the end of that year, Mercedes hosted a "we're sorry" conference in San Diego and paid for all parts and service managers across the nation to travel and drink at the open bars for a week. I guess that part was okay.
When you tell a warehouse worker to pick up an iPhone from row A4-143-X and it's not there, you need to figure out why. So yes, doing the accounting for that involved a "status" flag to figure out what happened. If another iPhone is later found in A5-143-X, great.
If not, at the end of the year you do the math how much stock dissappears "for unknown reasons" and you have your number on "possibly employee theft". To balance the books you can't just put an amount and "IDK what happened to it".
Bit harsh to mention this, but SAP (who run SAP ERP internally, naturally) have not been immune from bribery scandals -
https://www.thesouthafrican.com/news/sap-apologise-to-south-...
https://www.reuters.com/article/us-sap-se-safrica-exclusive-...
A bit more background: https://www.news24.com/Fin24/what-sap-really-knew-when-it-pa...
It would be quite hard to write such things for SAP (it's too monolithic, even if you find people to write such things the moment they come for you they would have the access to all your illegal data) , but I knew of people who ran two sets of accounting bases, though that was mostly for tax evasion purposes.
In Germany, for a long time you could write-off bribes made in foreign countries as a tax expense. It was handled just like any other expense (e.g. telephone cost goes to "telephone costs" account, bribery went to a "bribery costs" account). Also you had to provide some proof that the bribe was actually made. It was ok to cheat foreign countries by bribing their officials or bribe purchasers from other countries to purchase your stuff, but it was illegal to cheat the state of Germany by making a non existant tax expense (for a non existand bribe). After EU was formed this practice became illegal
For the rest of your question, SAP allows you to keep multiple ledgers. One ledger can be official, others unofficial. Those ledgers are conceptually something like "views". Some managers look at different stuff. For example you can have one ledger ("view") done as per local accounting regulations, another as per US GAAP, another per international accounting standards, another just to calculate local tax.. and yes "local tax ledger" is often different than "local bookkeeping ledger" (mostly different way depreciation is calculated). Why would you make self incriminating evidence I dont know. Probably you are sarcastic. But usually the cheaters misclassify stuff in their books (e.g. revenue recognition - like Enron), or not show it at all (e.g. financial derivatives). I saw also something made of nothing (inventory movements that increased value).
Employee theft is just generic FI-AA accounting. When you have many employees sooner or later someone will steal something valuable that the company kept on its books (say an expensive laptop). Other thing is if you catch them.
If your company stole something, you can supposedly just recognize it as unusual gain and pay tax on it. I am not a lawyer so I dont know if your corpotation can go to prison ;), but some say that the tax office wont care if you paid the tax on the stolen goods (this is not tax advise). I heard about a construction company that got some tools from other company (that didnt want it back - they were shipped far away) and they just recognized it. Not sure how the other company dealt with it, sounds like criminal negligence. But maybe they didnt write it off from tax point of view. Was just a cost of running business that ate their result, but not a cost that decreases tax.
I heard that corruption is just handled by giving a bonus to the sales person. Then the sales person just cashes it out and uses this cash as a bribe. Of course such practice is illegal in civilized world. Also illegal if your parent company is in civilized world - they will even make you take those obligatory trainings about that.
If you are interested in reading about tax crime then search for articles about samen dividend used multiple times to change tax scandal. What has the very unfortunate name "cum-ex" ( https://en.m.wikipedia.org/wiki/CumEx-Files ). Some argue that the practice was legal in Germany for many years. Some say it wasnt.
Also you can read about money parked in Bermuda, Irish sandwich, treasure islands... many of those big companies seem to do those tricks.
Those arent related to the software you use
What I do remember is that it seems to be down a lot. I started working in 1997 and about twice a week we would get emails from IT saying "SAP is down" and then a few hours later "SAP is back up"
After a few months of this spam I set up an email filter.
I was on the engineering side. I still don't know what SAP is and I've never needed to learn but it doesn't seem like a great product for how unreliable it seemed to be.
As for downtime, that's probably not down to SAP itself; it's core business, if it goes down, companies can no longer operate and will lose millions. But, with so many moving parts, there's a lot of things that can and will go wrong if handled uncarefully.
Let's say there is some common business task that needs to be done. Maybe it's a legal filing with the local government, or tracking how many people at the company are using a particular piece of software for licensing purposes, or records-keeping for equal opportunity employment questionnaire responses. There are many ways to accomplish each of these goals, but most people will be familiar with the SAP way. The laws on the books will be written by people who have used SAP before, and public comments on the law will be made by people who have used SAP before. Ancillary tools to do niche features that SAP doesn't cover will work best if you've adopted the SAP way.
And so, SAP becomes enshrined into the law and society in a way that's impossible to duplicate. Even if you mimicked SAP's features 1:1, there would still be obscure quirks and bugs that you didn't capture but are nonetheless somehow beneficial to users' workflow, because those quirks and bugs have been imprinted onto the standard business practices in our world.
But I've written my thoughts about what ERP is:
You need to get some certifications?
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.
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".
I've had the pleasure(?) of doing some elearning work for some clients that used SAP... I feel sorry for anyone who has to interact with their software on a daily basis.
Most are only exposed to SAP software for time allocations, travel arrangements and expense management, but I imagine there's some poor souls in the account department who have to spend a large part of their day suffering it. It's something you probably won't encounter in small companies, but seems inevitable in large companies and organisations at least in Europe.
What problems do you have with Jira?
They send you PDF invoices with no consistent formatting.
There's never a decent way to get an electronic invoice.
Any electronic files you do get, such as lists of invoices, are in a completely different format from all the others.
There's no way to place an electronic order without using their website (manually or by scraping)
At best, stuff comes by email. Often, you get emails that say you can go to the website to manually download the PDF.
Do you know of a QuickBooks-scale accounting system that does EDI easily?
The come in ~6TB and ~12TB.
Somehow, that tells so much about SAP and the institutions that depend on it.
OTOH, the general principle of "just have a giant in memory DB" isn't actually that crazy. In fact, a lot of the complex distributed data storage systems that a lot of services use might just be better off with a system like it. See also: Stack Overflow.
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.
1. It is extremely challenging to integrate with. Your basic option is to overhaul your existing software to at least match the available integration options.
2. It requires constant care. SAP Expert Consultants hired by the companies initially for two years, which was supposed to be the timeline when SAP would have been fully adopted (and turned over), still works as the complexity and evolution of updating the software itself is tantamount to a new system adoption.
3. Users (Majority I would say) hate it. The only reason they live up with it is because someone higher up the decision and authority chain imposed the software after being sold to the premise that it is a game changer to the organization.
Many of those systems might be somewhat standard, covering account receivables, payables, inventory, sales, production, planning, supply chains, payroll/hr, relationship management and general accounting. Many may be versions of these customized to a specific industry or business. Others are unique and require a customizable platform to implement a custom system.
SAP offers such software that scales to the worlds largest corporations and organizations. How well it does that is of course contentious. That reflects its market worth.
I do however often work adjacent to SAP or have to integrate with it, and since I've been at this for a few years now, I've gotten to try a bunch of their stuff.
SAP's biggest problem is honestly just that they are absolutely terrible engineers, while they suffer from the worst Not Invented Here syndrome I've ever seen. They nearly always want to build their own thing instead of using something that already exists.
Do you want to build web applications that interact with SAP systems? Well, SAP uses OData almost exclusively for all of its backend stuff, and practically no one else uses it. This means all developer tooling, like libraries and such, are almost non-existent. So what do you do? You use SAP's UI5.. which is easily the worst-made UI library out there that anyone has ever built. It's technical debt personified.
No one knows UI5 except people who work in this business, so companies are forced to hire consultancies like mine, because no normal web developer has ever worked with it(nor would they want to look at it in their spare time). I can scarcely begin to imagine how many man-hours SAP has wasted on building out this gigantic turd, or how many hours they could have saved by going with, say, React, and instead building libraries and tooling around that.
This sort of thing permeates everything SAP does. Everything they do is some of the worst stuff I've ever seen.
But hey, it pays great money, and the company I work for has great benefits and lots of freedom. All other things equal, I don't think there are many tech companies out there that could offer me a more rewarding job. But that doesn't change the fact that observing SAP from close-up is like watching an on-going technical trainwreck that never ends.
I'm glad that someone else feels the same way I do about OData and UI5. I've used both extensively (initially to learn more about them and then because I need to develop solutions that can be supported by customers) and neither is, well, ideal. The worst is that the SAP ecosystem is a massive echo chamber, filled with fanboys saying how wonderful OData and UI5 are. Really, they're not - UI5 is open source and yet no-one uses it. Why? And let me not get started with CAP (WTF did you give a product the same name as Brewer's theorem?).
There have been some attempts to extract some of the UI5 controls so that they can be used with React/Angular but I can't see those ever being adopted. I've worked with UI5 development teams that struggle with even getting the basics of Git and love using that godawful WebIDE, so I have no hope for customers being dragged away from SAP solutions to anything vaguely "industry standard".
Sorry for the negativitiy, but after 20+ years of SAP paying my bills (and paying them well), I'm even more cynical than ever.
I don't know the internals of SAP. I really don't have to. For us, SAP is a collection of OLAP cubes that have a highly curated view of that part of the business that the SAP system manages.
And there's a clean API to this data since SAP supports the XML/A SOAP interface standard to those OLAP cubes. It is a very chatty API to extract the data from the cube - but it gets the job done. It allows us to leverage all of the business logic that goes into the cube schema, and the huge investment that the business makes in SAP. I could instead run extracts of the underlying source data but that would lack all of the business logic that goes into the cube definition. I do occasionally have to use their desktop UI to better understand the cube schemas. It is like a trip down memory lane to use the SAP user interface screens. Harks back to the 90s for sure.
Anyway, if anyone's interested in interfacing with SAP through a relatively clean programmatic interface, I highly recommend using the XML/A soap interface to the cubes. My client company's SAP team does a great job of building cubes that expose what is relevant to the business. The SAP data is merged with lots of other business data in our data warehouse and the business gets a modern web and Tableau reports. Problem solved.
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]
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).
Most companies stick with a single ERP provider for 20-30 years. And 80% of attempts to swap in one ERP for another fail. Usually after customers waste millions of dollars and years of engineering work.
The underlying complexity of the physical processes managed by ERP is enormous. ERP systems are digital models of a company's physical operations.
Platform lockin and platform innovation are inversely proportional. Companies like SAP in ERP, and Epic in EHR, simply don't have to innovate to make lots of money.
That's one reason why technological change in those industries is so slow.
In our case, it was, basically a "success." I don't think that our customers saw too much of a change. I have heard nightmare stories of organizations, basically grinding to a halt, for months (I think HP lost about $400M when they switched).
It did result in the company hiring a bunch of programmers. Most were women, and they drove nice cars.
Where it's truly east to store data, create business units and UI interfaces and pro 'implementers' can do it quickly.
Then you have a company automated system for 'everything' that can just replace a lot of things like SAP, Salesforce.
Way in the future though.
It'll start small, in one area, and just make it's way to others.
Also, it will be it's own giant mess as 'implementers' screw things up and requirements from management change weekly.
The Lyons Electronic Office would beg to disagree. https://en.wikipedia.org/wiki/LEO_(computer)
The first business application to be run on LEO was Bakery Valuations, which computed the costs of ingredients used in bread and cakes [and] LEO took over Bakery Valuations calculations completely on 29–30 November 1951
The software is rather shit esp the old HR and MM stuff ported over from R3 but there is a HUGE ecosystem around it of consultants and consulting companies - nobody is going to get fired for choosing SAP.
It is a huge money hole - take any proposed budget and multiply it by 3.
But heck it transaction flow works and all the modules tie in with each other and the accountants are very happy.
Prior to that I was an ERP technical consultant. I've had the opportunity to work with many ERP systems at a deep technical level, on both sides of an implementation: the old system a company was moving off of, and the new system I was implementing.
I'm neither an advocate for, nor detractor of, any particular ERP system. Each offering has things it does well, and each has pain points. Unfortunately a lot of people cargo-cult their particular system of choice and lose objectivity. Software is simply a tool and is far less important than the implementation and execution.
A few SAP aspects that stood out to me from a technical perspective:
1. You are virtually guaranteed to have an existing capability available for any arbitrary business process need
2. The system architecture facilitates efficient data processing. Tables, forms, and reports tend to be narrow slices of an overall business process, and thus can reduce contention and concurrency problems. Batch jobs are utilized for background processing.
3. The user interface is lightweight and very performant over remote connections (e.g. VPN). Similar to older green-screen systems, data entry can be very fast for experienced users and does not rely on the mouse.
4. The API options for enterprise application integration are good
1. The surface area and complexity to match the capability is crushing. Tesla's relatively vanilla SAP environment had 10,000+ reports and T-Codes in it, of which I would guess less than 1% were actively in use.
2. Optimizing the architecture for scalability came at the expense of the user experience. One would often need to perform several tasks in order to answer a single need. For example, I would observe users exporting several reports, each of which provided a narrow slice of the information, and then combine the dumps in Excel to get the answer they sought.
1. It is very difficult to find subject matter experts who can deeply understand what a complex system offers out of the box, and successfully select the optimal capabilities and implement them for business processes. Or, in the case of true functional gaps, can modify and extend the system without creating a mess.
2. It is vital that a company retains the people who have the institutional history of a system and its modifications. Many end up with a revolving door of consultants, each of whom may be an expert in the vanilla product but has no company-specific context.
3. Clarity and completeness are at odds with one another. As you attempt to drive a system or specification toward completeness, clarity and understandability will diminish.
4. The longer an ERP system has been around, the more likely it will accumulate legacy and historical impediments. If a product aspect is working and widely deployed it tends not to be changed or updated to modern patterns or technology. An example in SAP is the cluster table concept, which as I recall from the lore some years ago was a workaround because SAP needed more columns per table than Oracle allowed. Cluster tables do not spark joy in data migration and egress when ABAP is not a feasible option.
5. Also for long-lived ERP systems, from the user experience standpoint, as these systems incrementally evolve over time the standardization and consistency of behavior across modules and application areas tends to fade or diverge. AS I recall with SAP for example, some transaction forms and reports can export to Excel, while many others do not: the feature was not or could not be added as part of the architectural core but was instead bolted on later to limited areas. A young ERP typically builds this in as standard core feature which is available on all forms in the product.Would like to hear of cost/focus tradeoffs after so many years of use.
Anyone at Tesla thought of open sourcing it?
And yet. They thrive and grow. I always leave with the impression that it really does do things well after all, just not in obvious ways.
I had a upgrade process meeting for SAP and I invited my usual SAP engineers.
I had a polite decline from one of my favorites so I dropped by her desk to ask her why she wouldn't come.
"I work on SAP 7, not SAP 8. I'm going to be retired in 2 years by the time this project kicks off and dead by the time it's implemented"
My last name is Sap ( translated to Juice from Dutch).
Recruiters don't get it. So my linkedin profile says: i wish my last name was DotNet instead of Sap :p
Absolute joke of a UX/UI. And don't tell me it can't be done better. The dated, out of support one we had prior had a better UI.
My parents won't ever praise Delphi, yet they (probably) still use that piece of software I wrote with Delphi 20+ years ago.
It does, notably, have an integration problem because the rest of the DHB services don't use it.
Nothin' much, how bout you?
This doesn't seem realistic if they mean inflation adjusted; do they mean using today's exchange rate? Or are both numbers inflation adjusted?
(For those who don’t know Sybase supports an SQL implementation which is seemingly used nowhere except sales and trading for Wall Street banks, who largely adopted it in the 90’s and have been slow to move off. MS SQL Server was originally a port of Sybase.)
You'll save tens of million on implementation, you'll get better support, your users won't want to kill themselves...
The rest of the world went one way, and SAP another, and believers are obsessed with it. Despite every other thing they do going an entirely different direction.
At least my company auto books the flights out of their slush funds as opposed to me needing to buy it and get reimbursed :puking_emoji:
I think there is great potential for modern ERP frameworks.
I worked at a global multi-national telecom that used an ancient version of the software. You suffered with it. I'm convinced -- because we were always cash strapped (having been through bankruptcy and back) that part of the motivation for keeping it was that it made doing expense reports so difficult that many abandoned them.
SAP looked cool at the time[0]. The web UI had an appearance of a web app and attempted to behave like one. It had many flaws, but they all went unnoticed because of one massive flaw -- it failed to handle the Back button in the browser ... and the UI often put you in a state that "instinct" made you want to click it. When you did click the back button, the web app would see two of you. As this was not an allowed state for a user, the new "you" couldn't access the system until the old "you" timed out ... an hour later. This meant a sufficiently complex expense report could take two days to complete since, on average, hitting the back button (by accident) twice per line wasn't unusual. So if it resulted in less than $40 coming back, it often wasn't worth the effort to do the expense report.
My entire experience with SAP was limited to integration with downstream (simple) internal applications and expense reports. Others spent all day within it. It was bad enough to warrant a special launch page that popped the thing up in a window that lacked the back button[1] but that was a pretty inadequate solution.
The worst part was hiring SAP developers. Having not looked at the product since the mid-00s (and being far from huge-company-land), I don't know if it's still the case, but I suspect so -- SAP was basically a custom setup everywhere it existed. It had the same graphics, similar UI, but requires substantial development to tie everything into it and tie it into everything else. I ended up participating in the interview when the company "got serious" and decided to put some money toward hiring a solid SAP developer/lead to get everything upgraded and solve some of the worst problems we had. We brought on a guy and paid him 25K more than the highest paid developer on staff[2]. He, like the previous four (under-paid) employees, lasted about three months before he left for substantially more money. We tried "paying some third party", too. The problem there was similar -- whomever was contracted to us was either incapable of doing the work or didn't last long enough to get past initial planning.
The end result was SAP existed in our organization at the same version it was when it was setup, initially, until we got rid of it ten years later when we merged with a competitor. The competitor ran Oracle for ERP and had a team of people to manage/develop/maintain it. Personally, I'm not an Oracle fan, but I wanted to buy Larry Ellison a beer.
[0] This was the mid 00s.
[1] This idea, I think, was tried -- IIRC, the more frequent case was accidentally running into the Backspace key on a non-text field and having the browser hot-key back which isn't solved by taking the buttons away.
[2] This was saying a lot considering we had software actively developed in C++ that managed a pretty massive audio-conferencing service (and set of related bridges/hardware). I met with several on that team -- they were geniuses. The "SAP Guy" had to know Java and SAP. I interviewed him. I wasn't impressed.
Even better is that it's written in some bullshit language that nobody else uses.
Though the drop is not SAP specific, but broad based (tech stocks carnage, ukraine war effects).
Then I worked places with SAP. And if they were lucky and just "did things the SAP way", the result was easy to understand, actually worked, and saved time.
Can you do that without SAP? Of course. Can a SAP system also suck? Of course. I have no argument to make here, other than it's sometimes good and sometimes not. If I had to compare it to anything it'd be IBM.