What's SAP, and why's it worth $163B? (2020)(retool.com) |
What's SAP, and why's it worth $163B? (2020)(retool.com) |
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.
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.
Back in the 90s Sybase was the only "major" database that SAP didn't support, ostensibly because it didn't support row-level locking, only page-level. Support for SQL Server 6.5 was added in 1993/1994 with the assistance of Microsoft (SQL Server also only supported page-level locking at the time and was still based largely on Sybase). Sybase ASE was only supported by SAP many years later, after they'd bought the company (primarily, I believe for the now-discontinued mobile products).
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.
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.
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.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.
One has to remember that many large companies don't have an in-house set of software engineers to kludge things together, or a set of people to audit and make sure problems aren't accumulating silently somewhere because of some bug or some vendor changing their API or whatever. Even if they did, the supposedly "agile" solution proposed here just sounds rather fragile. You even see this in codebases that are built on a "microservices" mindset -- you start getting weird emergent patterns in internal dependencies that start bogging things down.
For a smaller or even medium-sized business, sure, maybe a custom solution works. But it looks like for the scale of organization SAP works on, it seems difficult for an individual to even understand all the components of that organization, let alone build something maintainable for themselves and their eventual replacements.
I used to think this, but then I started interacting with actual end users (normal, non-engineering people). There are 2 main problems with exposing more barebones stuff to non-engineers:
1) Problem solving (thinking about how to compose the raw primitives) takes a lot of creativity. Most normal people only know what end outcome they want, not how to engineer their way there*. The reason wizards are so common is because they address this exact need. Wizards try to figure out what you want to do via a series of questions (and then do it for you) rather than have you come up with how to do it yourself. They are so common because when designed correctly they work very well!
2) Understanding errors is also very hard. Just because something didn't fail doesn't mean it worked correctly. Sure, anyone can file a transaction into a database, but they can just as easily file an incorrect one either by mistake or due to inadequate understanding. The complexity of the systems are their to catch problems before they become problems.
Sure, sometimes there will be corner cases that aren't accounted for by the existing system. And these will be frustrating. But taking away both the end users' guide and also removing their guardrails just so they can maybe solve the problem themselves is not generally a great idea.
*: This is not meant to disparage the normal users, but different people just have different interests and goals. Not everyone should be forced to know exactly how a machine works just to operate it.
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.
Would like to hear of cost/focus tradeoffs after so many years of use.
Anyone at Tesla thought of open sourcing it?
I left a number of years ago and I'm certain things have evolved since, but the cost/benefit calculus is similar to any make vs buy decision.
In my opinion the primary benefit of an in-house developed ERP system (or any purpose-built system) is that it does only what it needs to do and nothing else. Thus, some types of accidental complexity are reduced, business user cognitive load can be lower, and performance and scalability can potentially be higher. Also of course there is no application licensing cost and hence user count is constrained only by infrastructure and code quality.
Now the difficult part: you spread the cost and risk of development over one customer, and ERP software is not a simple matter to build: essential complexity inherent in modeling business processes in software remains unchanged. You also have challenges finding subject matter experts as most of the folks who understand the internals of ERP systems are already working for one of the commercial vendors and will scoff at your audacity.
To be successful it requires leadership with vision, commitment, and patience; as well as a team of talented analysts and engineers.
But here in Poland the government apparently found a solution to this problem - it's called KSeF and it will force all local entities to send invoices as XML through their portal first (there will be no other legal way to invoice, because the KSeF number which is generated by the portal, is required for every legal invoice, without they won't be able to deduct VAT).
Only time will tell if this will bring new era of electronic invoicing or just another failed government project.
As for whether or not it will work, I think as long as Polish companies need to invoice non-Polish companies and vice-versa, trying to standardize in this manner will be challenging.
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.)
It can work for a long time, but eventually it does create opportunities for competitors.
You're absolutely right that there's a floor for how simple these products can be, but most of the incumbents aren't anywhere close to that.
However, I do believe a (slightly) better competitor could be created, with better technology, better workflow, etc. If well-capitalized. If it had well-factored plugins. If you had a top-notch team to design all that and then build it.
That's a lot of ifs. Joel says it isn't guaranteed a brand new team will even do better than the old on the essential angle. It's risky and costly enough to prevent it from happening.
But the most likely scenario, I think, is that built-for-purpose competitors will build products that peel away small pockets of SAP's customer base over time.
The irony of course is that a product like SAP is the end result of similar built-for-purpose products being hoovered up and merged together in the first place.
Everything is a pendulum!
[1] https://www.cbinsights.com/research/craigslist-unbundling/
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.
Now what does this say, about LIDL, a discounter who dumped 500 m with SAP?
https://www.computerweekly.com/news/252446965/Lidl-dumps-500...
Basically, if your buisness process match that of SAP, everything is fine, if not, good riddance. Or in the words of a former SAP manager about Lidl: “They don’t have the right level of business engagement”
Meaning they did not adapt to SAP enough.
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
Customers are growing increasingly frustrated, the company has dipped its toe into political agendas and they regularly get lit up on Twitter as a result, and Bloomberg has targeted them due to questionable moral practices (most recently, silencing rape victims).
SAP is more concerned with protecting their reputation than actually developing quality software. Sooner or later that is going to catch up with them. They are constantly playing damage control. It's only a matter of time before more and more comes out (and there is plenty to come out).
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.
Upgrade windows aside, it's ok. I imagine that the sweet-spot for Netsuite are businesses that do 5MM to 100MM ARR. Possibly less if there's a heavy need for EDI, volumetric shipping, etc.
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.
SAP will fall from a thousand cuts of the facade pattern.
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.
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.
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...
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.
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).
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.
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.
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".
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 :)
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.
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.
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".
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.
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.
But lots of domain specific languages have idiosyncrasies. The Apex language used to program Salesforce is a half-implemented clone of Java from a decade ago. And they didn't cherry pick the best parts.
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?
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.
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.
* 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.
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.
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).
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).
[ ] 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.
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]
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
I was a GA from 2003-2004.
It does not make sense for Amazon to run there own shipping fleet... until it does.
The other point is that armed forces tend to have a mandate to control the supply chain, this might be a case of that.
The Army isn't a business and should never be run as one.
SAP and Jira are just not great software. They’ve got excellent sales teams, connections, and probably great support. That’s the key to getting user-hostile software into big orgs.
Apps are what organizations/people buy. Databases are just the storage engine.
The difference is that Oracle underwrote their apps with database profits and they never got the apps game.
As you say, the switching cost is way too high and dangerous. They moved billions and billions of dollars daily through a highly complex structures and complex laws in different jurisdictions across the USA. The business logic was built over the 40 years when the world was DOS. It's not like they are dumb and don't know linux or Windows exist and all that.
They brought in huge consulting companies all the time to see if they could get it upgraded, but no programming house, no consulting company would touch it. These consulotants turned down hundreds and hundreds of millions of dollars, because 1) it was just too f-ing complex, and 2) if they messed up, the liability would be immense because of the dollars daily transactions, and what the dollars were used for. It would be an absolute shit-show of the first order if things were to go sideways. I'm positive that these consulting companies E & O (errors and ommissions) insurance company would refuse to insure them. Doing it wrong would be catastrophic on a corporate, but also national level. It would not be a matter of some stick-it notes from 3M not getting to the stores on time, or shoes getting to the shoe stores.
So, DOS in 2020.
The requirements change, merge, flow. In theory each department within the enterprise could have their own optimized, silo'd tool ... but then you need "enterprise integration platforms" to glue together all the workflows between them.
Now that's one simple process imagine that on every single step. SAP is worst software I've ever used.
Basic business logic is built into SAP - but because it covers all aspects of business, it’s a massive tangle of rules.
For instance, let’s say you get an invoice from a vendor. Now you have to update your balance with that vendor, and your general ledger. You have to record the new inventory moving in. Perhaps the inventory has a barcode, or a serial number with a warrantee date, or a batch with an expiry date. The inventory movement will be tied to the cost of that invoice - remember to take into account those exchange rates. Also, there’s a variety of ways to account for item cost. You will have had one or more purchase orders - those have to be closed. If the vendor is to be paid in a different currency, you have to do every accounting entry in your currency and theirs, and record the exchange rate differences. Your accounts payable are now in that other currency, which means that has to be updated all the time for accurate bookkeeping. You have to note which employee was the buyer. This buyer has targets and metrics to be tracked. Perhaps there are reports and alerts set up for them. You will have a budget, which may impact this transaction. Of course you also have master data for the vendor, the employee, and the items bought.
There is a lot more to this than the above, and this is for the simplest business case - one that happens hundreds or thousands of times a day depending on the business. Usually there are special considerations to program into the above as well. Now imagine what happens when a complicated situation arises, where you have complex transactions spanning months, many countries, and many other businesses. Sometimes there are legal rules built into the logic. Usually those rules only alply to one country. And I haven’t even mentioned freight or tax or landed costs from secondary invoices.
SAP is a ball of wire because it simply has to be.
If you built a new ERP, you will end up the same.
It's been one year of this BS and it's clear no one cares or listens to our complains, so we just pretend to work and execs are angry because of KPIs, clients complain, etc.
But seriously, we can't do it anymore. Their idea is that with this new software everything will be taken care automatically and so they won't have to educate employees anymore and technical knowledge will no longer be needed, and we'll become you regular brainless contact center but magically better because we have such good software!
I hope I can get out soon.
I haven't, but some of my colleagues have been in the space for 20+ years.
>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.
Wrong. Upgrades almost never break your customizations, because in the ERP space backwards compatibility is verry much a thing with the exception of a few extreme cases now and then. I've migrated customizations from a 2004 version of NAV to a 2022 version of Business Central - even the name of the software changed, and the language in which it is written, but the customizations were almost plug and play after running the code migration tool provided by Microsoft.
>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.
I never said employees wishes should be blindly followed, you still have to do the consulting part of the job...
>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.
Wrong. The benefit you get on the accounting side, and the all data being in one place side(reporting) outweighs almost any customization that needs to be done - because, good luck making those 2 things from scratch. And good luck living without those 2 things if you're a mid/big company.
This happens because the people working below senior management are usually not slick talkers and many people in senior management do not understand IT. So a savvy salesman who knows the right words can convince the guys at the top to do what he (its almost always a he) says.
If your company is small or at least in a field with lots of competition sure. I work in a >100person company that encounters loads of regulatory changes due to food safety and lots of international trade and 2 people developing is good enough. The part doing the accounting and such is largely outsourced to an ERP but is honestly simpler yet just as costly if not more.
What's more things go wrong. That's a given and the absolute best way to deal with it is with someone as close to the processes as possible. you don't want to be calling vendors that are generally absent to see in which part the software lies. Even for industrial equipment that is a lot more single process it is kind of accepted that we people on the ground need to know a good bunch to troubleshoot ourselves rather than paying someone to come over. After all if we wait for that we get a bottleneck that has dozens of people twiddling their thumbs.
SAP is very inconsistent across different views. It's not about learning a different concept, but memorizing each little detail.
On some forms you need to press <enter> to get to the next one. Sometimes it's clicking a button. Another time it's <F3>.
You can become a pro in SAP UIs, of course. But it's tedious and your knowledge applies nowhere else.
Correct. This is the problem my company solves. We are ERP consultants/dev's who also know web development. Through the years we've made 50+ web apps to extend Microsoft's ERP, most of which can be used in most companies with similar needs with slight modifications.
And, of course you don't blindly follow a process. There's always some improvements to be made to the process before developing an app for it.
EDIT: Drastically changing workflows for employees within huge companies will ultimately almost always cost you more... It all depends on the company of course, but we have to generalize a bit.
I think it's really a case of a self-fulfilling prophecy, of a sort. They are the biggest in the business, so people go with them, which makes them bigger, which attracts people.. and so on. It probably helps(SAP) that they also decades worth of man-hours implementing all sorts of insane business logic(like for accounting, as you mentioned, which is something you definitely don't want to get wrong) where other players are likely to be behind.
Second part is actually correct - you have to change your way into how SAP works, its just a typical crappy legacy rigid mammoth software that requires overpriced army of devs/analysts, not much more. If it would be marketed that way, they would go bankrupt very quickly because no company willingly wants to do that, and certainly not at that cost.
But anytime some c-suite manager picks up SAP, you can be sure there were some nice meetings done in ultra luxurious places and more often than not some bribes went that way, in one form or another. This is the way, if your system sucks so much it destroys companies
The drive to ERP is understandable. The issue is that homegrown solutions suck too - most businesses aren't IT companies and can't properly maintain a custom solutions. Using a third party makes sense, and allows you to hire outside devs with experience. SAP is however usually not the best solution...
I remember SAP circa 2003. The only think that used XMLHttpRequest (AJAX aka dynamic html) was Outlook web frontend, and SAP web UI. GMail that widely popularized dynamic html did not even existed yet.
How common is „three system landscape“ in cloud, like S4HANA? Elastic scaling? No. TCO footprint of an new tenant? Sigh.
I've not yet used S/4HANA Cloud (only the on-premise version), but it looks to me like it's just a hosted version of standard S/4HANA but with various restrictions on what you can customise etc. No real elasticity, cloud scaling, etc. SAP ERP has been multi-tenant since at least R/3 in 1992 (I never used R/2) so "Cloud ERP" smells to me like "we host it for you and call it cloud".
Yes, I am rather cynical at times.
There are of course the certified consultants that work for clients of SAP. I can however understand why they need certifications. It's probably impossible to configure these systems without some kind of special education in them.
And as for the quality of SAP devs.. I work for SAP and I have met many very qualified developers at the company. Far more than I anticipated before joining the company. Quite a few have been poached by Google et al but that is another topic.
Currently the customer is very happy with our development speed and unhappy with their Accenture project's speed
But only if there are someone who can and would provide you with all that stuff.
> Taken to the extreme presuambly one would end up with nothing but
This is the premise of 'The 4-hour Workweek'. It was a quite entertaining read.
And if you managed to get it down to only 10% of its current size, it'd still be several times larger than the Linux kernel.
SAP makes copious amounts of money, so naturally people have tried to replace it. So far, they have not succeeded.
Exampletime:
A thousand versions of a cylinder valve controller software for a plc floating around a machine builder.
Instead of writting one for each version of statefullness and interfaces to encapsulate the different usecases. (Can be done with TC3) shared by all collagues via Git.
IOpenCloseable {} and that then can be used for example for a drive home routine
DrivePointHome() {
foreach (IOpenCloseable cylinder in allElementsInHomestateInOpeningOrder)
{
cylinder.open()
wait(cylinder.isOpen())
}
And there you have it. Configuration instead of programming. Reusability instead of Recreating. Testability (https://tcunit.org/).
It could all be done. It is done, good, elsewhere on the planet, daily.
In my last career we fought this mentality, to exaustion.
Now im out of it, im just waiting for someone with the mindset to swoop in, disrupt and clean that space out with the effectiveness of good software. There really is no reason to employ half a million electricians to program subpar software when you can have it better for cheap.
It's like when Mercedes/BMW et al started making SUVs after years of making sedans and coupés. It's a different form factor, but still the same basic product.
It is not feasible to rewrite it in the fancy language/technology du jour - huge waste of resources for things which already work fine and at the moment you are done you have to start again, since the IT-pendulum is traveling in the opposite direction.
We, as an industry are really bad at working with legacy code, but for a lot of us it may be the main task if we endure this line of work for some decades more.
Small problems benefit from small tools. Large problems benefit from large tools. However, small problems grow and your bet as a small problem is that your tools will grow with you.
In practice, they usually do. If they don't, you end up extending the tool or rewriting it in a larger tool.
So, our tools start small, and small companies use small tools, and the ecosystems grow together. Then, the successful ecosystems end up the next large problem toolkit.
As you're a small ERP SaaS, you're banking on growing with your customers, I presume. And you can make an argument to start on the large tools at the cost of initial velocity, but that's your tradeoff.
I really think the innovation that needs to happen is a system that has a prescribed growth path. Retool/Excel/similar that can compile to a simple app that can adapt to more complex patterns as the need comes.
I’m fairly certain most of them are bad. You don’t make an everything monster and have things be good. They’re likely at best adequate.
Basically, if you are a manufacturing company SAP is easily among the best solutions out there. Added benefit of using an ERP that litterally everone else is usong as well: you have a way larger pool of people to recruit from that know the system. The less market pebetration an ERP has, the harder it is to get people who prwviously worked with it. That means higher training efforts, more need for external cobsultants and performance issues until your emoloyees adapted to whatever ERP you have.
Basically the whole education system needs to push discussions more, were you have to argue a point, proof you are right and stick to your guns. Something regarding this is going right in some education systems and cultures, and fails utterly in others. Its a education to lead, instead of education to be led.
As a Skat player, this is only true in Null, the game you actively try to "lose". Fitting, I guess?
"Why stick to the status quo?"
As GP comment said, there has been innovation in the electrical engineering space that maintains backward compatibility.
So if Open/LibreOffice could actual deal well with MS Office formats, for example, whilst removing the annoying bits (cost, telemetery, UI[0]), then yes, it might be wise to move on from the status quo.
[0] in practice I don't think the OpenOffice UI is better than the MS Office, but in theory some people could prefer it
(but it is in academia)
https://www.joelonsoftware.com/2000/04/06/things-you-should-...
Experience probably has already taught you some of these ideas, but you hadn’t invested the time to reason about them and putting them together. Then you read an old blog post, from two decades ago, putting all those ideas into words and it simply clicks in your mind.
Thanks for sharing the link.
I find it very difficult to fight for sensible defaults in a company when everybody only sees their area and has a very strong opinion about that. Only a strong force like the SAP transition can break up with those encrusted structures.
After seven years and 500 million euro spent, the project was cancelled and they went back to using their old inventory system.
So, in this case, customising SAP to fit the company's processes wasn't worth it even for a rather large company like Lidl.
That is a low bar. Your "lowest bidders" should at least be able to equal that. It just has to accomplish the business processes and do so within the software. It doesn't need to be fast, intuitive or look good doing it, it just needs to do it.
Funny considering in the 80/90s SAP sales/management was known for saying that you don't adapt SAP to fit your company, you adapt the company to fit SAP. There was another company (was it Baan or JDE? I think Baan as I had too many meetings at the time with those religious fruitcakes) that said they were better than SAP because you don't need to change your processes; you change the software.
Baan still exists as Infor ERP Ln
I’m amazed that this is what happens every. Single. Time. And yet we plow ahead with this kind of projects like we have no idea it’s the usual outcome.
A couple years and millions over budget later, we rediscover this axiom. I really don’t get it. And try to warn about this, you’re labeled as not a team player or whatever and paint crosshairs on your back for the next round of layoffs. It’s just soul sucking.
The details about the day-to-day operations disappear quickly as you move up the hierarchy.
My boss recently had a meeting with a large customer of us, we deliver a product used heavily by one of their departments. Here's roughly how that went down:
My boss: "Well, what about when you do orders of type X?"
Manager: "Oh we don't do those"
My boss: "Really?"
My boss brings up the order list and filters on type X, finds at least one entered each day by user ABC
Manager: "Oh... so that's what she does"
So that information was lost in just one level.
This is why we try our best to get the actual users involved when discussing requirements with a customer. I don't think I've ever experienced a project where at least one of the users haven't brought up some edge case the manager wasn't aware of or had completely forgotten.
On the flip side, the projects where the users are left out of it until it goes live never goes well. We'll get it fixed eventually, but there's always pain for far longer than necessary.
Most of my work right now is trying to eke information out of customers about their ERP system so we can get it connected via EDI or to their Ecommerce system (shopify whatever).
So we go live, with a whole process revolving how payments are accepted - and then within an hour there's a problem. Nobody mentioned that certain customers have a different payment workflow!
Back to the drawing board, except we're already live.
This happens again and again.
This is what big corp suppliers like IBM, Oracle or SAP thrive on. CEOs and executives not actually knowing the intricacies of their company, and underestimating the risk of creating a very expensive second system effect.
The fact is the higher you go the concerns separate. I think the army motto was "go 2 levels up". You're a grunt, you need to know what your platoon and your company are up too and what the goals are so that if you can't follow the plan directly, you can still hit the objective. This is good because no plan army or business, survives reality without changing.
In the same way, you can only go so many levels down.
What did you find is a mess about Odoo? And why is customizing it a nightmare?
It would have been better to integrate an existing system instead.
My experience when evaluating Odoo was using Studio, which I have found can really mess up your Odoo instance.
Are you working with Odoo code directly?
I am intrigued - you mean terminal output is actually parsed, and a GUI view is then generated from it?
E: this would certainly explain the issue of listboxes only having the currently shown items loaded (described by another commenter) - everytime you scroll, the terminal output has to be produced + parsed again
Remember that back in the late 90s SAP had a native GUI that ran on Windows, OS/2 and Unix (Motif-based) and each had their own native controls (a native Windows listbox is implemented differently from a Motif one, for example). Developers would develop a UI in ABAP with platform-independent controls and that UI would be sent over the wire to the client as DIAG and the client would translate that into the native control and data, etc for the end user.
I challenged this design decision when Fiori was introduced and the thing is that statistically the lists are either small or huge. When they're huge, they got touched in less than 10% cases, so by not loading the whole content you save a lot.
It's absolutely not something you just randomly explore. I think that's a more interesting question: what sort of empowerment of employees could you create if the UI wasn't so terrible?
But SAP's moat is elsewhere. You put up with its terribleness because nothing else can do what it does. Beating SAP would require you to reach that, and do something else, part of which could be a nicer UI.
Every detail of the business process is now explicit. Employees have to be forced to work according to actual process. You need quite a bunch training for that. Then employees will find shortcuts to make their own job a bit faster/easier, which will fuck up some cases. You need even more training for that and possibly some redesigns. And all you get from that is depression
This was the craziest part of doing SAP development. (I'll admit this is an America-centric viewpoint.) But the codes to get to various screens were (to me) totally random. e.g. to create a purchase order, the code is ME21N. Only after 6 months, did my German boss let me in on the secret that all the codes "made sense" if you knew the German phrase for "purchase order" or whatever.
I guess it's fair for the world having to deal with .cfg .txt .exe and all the other English that's essential for modern computing.
But the table and column names are literal german abbreviations. E.g. table AUFK - "SAP Order master data" is named after "Auftrag" (=order).
Column "AUFART" = auftrag art = order type. And often more
When you go into the actual ABAP code of some transactions, it can have comments in German, made by programmers many years ago.
I have done work with some subsystems like you would also find in SAP and usually I found the SQL Databases weren't that amazing at modeling what I wanted.
But I don't know enough of how these systems work. Does every location or subsystem have its own db that get some compared in the software layer or is there usually a single source of truth db somewhere?
SAP HANA basically sits on a custom server and (as far as I know) just uses a column database. The hardware is setup/customized by SAP. Perhaps they want to squeeze some margin here too. The conspiracy theory is that it is not for speed, but to spy on their clients. Or that they dont want to deal with customers mis-configuring their servers.
As for the table structure, then most stuff sits in just big tables. I dont know if the system shards them internally; from user point the tables are just one entity, not divided by anything. You can query them without having to glue anything. For example the table AUFK has order data for all orders, in all entities, in all years. (on a side note: many other ERP systems make separate tables for each year, what is a pain in the butt for reporting, but also allows to shard the data easier). SAP also has this concept of "MANDANT" which is kind of abstract concept of access rights, that can be compared to entity, but it is not really a financial entity (there is a field for that too). Perhaps internally the databse somehow shards the data on MANDANT level, but from user perspective you just see one big table.
And boy, some of those tables are big that you only extract deltas to your business warehouse.
>Does every location or subsystem have its own db that get some compared in the software layer or is there usually a single source of truth db somewhere?
The idea of SAP ERP (and I'd argue the idea of most ERP systems) is the ERP system is your source of truth. All its subsystems sit on one database, that (if you stay within standard) shouldnt ever break.
Many companies have other systems that "feed" data to SAP -> e.g. you do some inventory planning in some super-nice stuff, but the actual "bookkeeping" (source of truth, orders, financials) is in SAP.
Many many customers have been burned by this over the years - being too trigger happy and customising/building their own extensions rather than using the out-the-box functionality. Packaged software exists for a reason, don't use it like a PaaS to built your own solutions.
SAP is now pushing customers to "keep the core clean" and stick to standard as much as possible, which is definitely a move in the right direction.
s/SAP/Debian/g
s/mature/so-so/
s/customer/sucker/Specially with the tools that exist in open source. Amazing databases, data modeling systems, libraries to integrate into literally everything.
It think the bigger problem might actually be to define the process you want to implement. What are the specifications, what of your existing system is actually needed and what isn't. Rather then the actual implementation of those processes in some digital process.
I have a friend who work himself up from worker in a warehouse to team leader and now SAP something something manager. And from the story he tells me I am mostly constantly confused. The whole environment feels incredibly foreign.
Build a inventory planning and tracking system for a company that operates in every country in the world and has to issue and receive invoices, customs documents, waybills etc in hundreds of formats, currencies, languages and accounting standards.
And you are right that the biggest problem is definining processes and data types. Whatever waybill system a 100-head HN Rust and JS crack commando comes up with, you can rest assured that there's some authority somewhere that wants an item displayed differently, so you either patch this and many other edge cases until your codes becomes an unworkable spaghetti, or you go back to the drawing board countless times and ship nothing, or you outsource it to SAP and the likes who have spent decades coming up with a working solution (even if it's not that elegant).
You really don't just need 100 programs but you need 30 people defining the processes and 200 configuration experts.
This really seems like something the world would profit from creating a huge amount of open libraries for all this stuff. There are so many old apis in all these old systems. I work in banking and when switching company and then you re-implement the same shitty format again.
You would obviously need some people who have done ERP systems experience, not just 100 random developers.
I think, at least I have heard, that Tesla does its own internal system, would be interesting to see how many people they have working on that if its true.
Posters in this thread are so clueless it hurts to read.
But also, SAP has a lot of accounting and legal process knowledge baked in that is reusable even if you customize everything about it. That's what "mildly competent" developers are missing.
Essentially, they used SAP as a framework.
If memory serves well, Liqui Molly had similar, but cheaper, experiences with Microsoft.
If you could hide the budgeting effects from anyone with the ability to 1. start projects or 2. add scope to projects, then it seems like it'd work out just fine.
(Of course, actually doing that would require splitting "planning" roles into separate, almost-adversarial "defining projects + increasing scopes for projects" and "feasibility-analyzing + cost-optimizing + decreasing scope for projects" roles. But that seems like exactly the sort of thing the DHS would be fond of. War-games for the project managers; and separate levers for both kinds of sitting presidents to pull on to satisfy their bases, where building up one capability doesn't tear down the other.)
That's the generous interpretation. There's also the case when project managers deliberately low-ball their project estimates to take advantage of the phenomenon. I'd put that in the trust problem category.
A market economy does not really help, that just means you don't have a budget to cut in the first place.
It’s more the opposite, that many people have a strong financial interest in maintaining the system.
Where do you think the customer is going to find that army of hyper competent experienced staff ideling around their premisess waiting for the day an SAP project drops?
One thing I've seen frequently is treating erp implementation as IT project. I'm a technical team member doing erp implementations for last 25 years (not sap) but I'll freely admit erp implementation is not about me or technology. It's primarily a business transformation project. You need those erp business process experts to guide and customize, AND you need thorough willingness to change your internal processes to fit the industry best practices you're buying. "successful erp project" empathically does not mean "installed it and it runs". It means thorough and detailed understanding of requirements, mapping to new processes, customization where absolutely positively necessary, substantial and organized and embraced business transformation, extensive training, and thorough testing including user acceptance testing.
If you think is erp as something you just install and life will be the same but magically better, you're gonna fail hard. Missed requirements and edge cases, and or significant internal resistance to change, are frequent challenges.
Also, because leading employees usually have no idea about the intricacies of the "old" system and think it's easily replaceable with a solution from the shelf.
We've been fed an off-the-shelf solution with modern tech like Angular and the like.
And even without the SAP burden the company is basically destroying our departament. I guess they don't care to lose us poor peasants but they're basically losing al know-how and one of the only two edges they have against competition.
I can't say I care too much at this point, but it's amazing how easy can companies destroy themselves for not caring about their employees.
BUT the problem is that Jira is infinitely configurable. Add 20+ projects with 20+ project managers/leads who want to do things Their Way and you've got a clusterfuck on your hands. Every project has different terminology, different workflows and different ways of handling the same types of projects.
What Jira needs is a single (benevolent) dictator who is the gatekeeper of adding new workflows, tags etc. Then it works.
One very large video game studio has tons of automation for Jira. Imagine someone deciding to add new weapon. The automation creates 100s of tasks for concept artists, 3d artists, animators, sound artists, software developers with complex dependencies better those. Most importantly, automation creates multiple QA steps for each element of completed work.
The same exists for levels, enemies, quests and tons of other elements.
I would not be surprised if a lot of studios had similar workflows.
This is pretty much never the case, and more often than not the company is successful despite those process, not because of.
Many processes evolve on an ad-hoc and as-needed basis, with some tweaks here and there over time as the company grows and staff turns. You eventually reach a point when no one can remember how a process came to be, or why Sarah has to export four files from three web interfaces and copy/paste data across two Excel files to send to John over in accounting that was just trained last week on how to use this file to true up actuals.
There's only so many ways a company can track inventory, or manage purchase orders, or calculate product costs, or represent sales order and invoices. An ERP acknowledges that a vast majority of businesses operate with the same set of industry-specific operational primitives, and businesses have learned that it's both more time-and-cost effective to adapt your business to the expectations of the ERP than the other way around.
In the rare case you're doing something novel, you can still build your bespoke solution on top of those existing ERP primitives without having to re-invent how the numbers come together so your company can spit out the three financial statements.
SAP does not need to touch the "unique" detailed processes that makes a company great, nor it's culture. But if you e.g. manufacture a product, the design process can still be relatively unique to your company, but most often, the manufacturing processes should follow the high-level blueprint of manufacturing companies.
If its the former, than conforming to SAP is giving up what made you good. But if its the latter, then conforming to SAP is just making the basics more standard and easier to maintain.
No executive wakes up and things ‘this is a great day to pour 500M down the drain’.
Standardise the mundane (with an ERP, with minimal customisation) business processes so your company can focus on innovating where they have true competitive advantage. This is the recipe for a successful ERP implementation.
I do some Scaled Agile Framework consulting and the implementation a good example, because it can be fantastic but if leadership at the top of the company doesn't get on board the entire process will self destruct or be bastardized.
The professors who built the system knew this about every customer they talked to and it was a big learning experience for me. New leaders will come in and often insist on tools that they already know, rather than take the time to learn about better options.
If you've ever read Skunk Works (fantastic book), you see lots of this in the military procurement process in the US. It's bad enough that you worry how much it's hurting US national security innovations.
I've seen this with developers. Newly joining developers, particularly junior and mid career developers, tend to insist on using the languages, libraries, and techniques they are familiar with. Senior Developers don't seem to do it as much. Either because they are familiar with many things, or because they have been on the other side of these well intentioned suggestions to know when it is actually productive.
I do care about using the right abstractions and high-level interactions, not as much about the language or frameworks. I’ll let others put in their political weight on that, so that I can do it in the areas I believe will really make an impact to the business goals.
I saw it posted below. The system was/is called Balanced Flow.
For example, the solution may not have worked well with other procurement items and they wanted a single platform. Or the navy already had an SAP contract that could be leveraged without spending money on a separate stand-alone army solution.
So it can look like a bad decision that generated local inefficiency while globally it was a better choice. That's not to say SAP actually delivered on those promises.
Its always good to call out corruption, but its also important to realize when a situation is actually crazy complex and while its an awesome story might not be worth formulating a summary judgement from.
However, for an organization like the army that spends $$$ on logistics, I would bet they would continually fund something like this if it showed enough promise. One thing the DoD and Congress are good at is throwing money at R&D efforts.
I've worked alongside consultants from Accenture, Deloitte, IBM, etc over the years and, while many of them are very competent, I would /never/ engage one of those large system integrators (SIs) on any project I was involved in. There are many excellent individuals working for those companies, but the companies themselves are terrible and you will struggle to get any of the excellent people involved during your implementation. The experts will appear during the early stages of the consulting sales cycle but will be nowhere to be seen during the implementation.
Unfortunately this is the dirty little secret of SAP implementations. Many SAP customers think "I'll pay top dollar and get a good SI" but they end up getting the latest round of juniors doing the implementation. Seen it many a time.
Your comment is a mechanistic explanation of the failure mode, which again, I quite agree with. I worked at PwC for a couple of years; quite corrupt incentive structures and quite a dysfunctional organization because of it.
But other than that, I haven't found time to continue with that project. But you can check out my YouTube channel for future endeavours: https://www.youtube.com/channel/UCFU7a7OMYfcpjtIpu2j47_Q
I see this trotted out a lot but are all large companies really that oblivious? Do none of the decision makers talk with the people that work for them? Surely those executives aren't so divorced from reality and common sense that they don't see a problem when people complain that things don't work or if they do, it takes an order of magnitude more time and effort?
Surely there must be some other explanation for the proliferation of these systems other than "execs dumb and bad"?
Overloading the customer is one of the simplest ways to make sure ít is not your fault when things most often go south.
Executives at a large company are divorced from your reality at your level of the job.
Incidentally, that’s part of the fun of working at smaller companies, though the variance is higher there’s also the potential to work more closely with good earnest executives who also want the company to succeed.
>people complain that things don't work
that's a problem and we're going to have to fix it
>it takes an order of magnitude more time and effort
that's not a problem
the fact that Jane the accounting drone has to do twice the amount of work, or has to hire an intern to help her out, or even wants to quit because the job is so awful now is not a problem
it's a rounding error in the overall cost of implementing an ERP system
a new screen with some new data to show for the exec is worth 20 Jane's and her opinions on the new system
you can't even call the new system unethical or fraudulent because 10 people other then Jane can now stop using broken excel sheets to organize their work
basically Jane is collateral damage
This sounds about right to me. In particular, it tends to partiton the organization into (A) the people whose job it is to plug away at the ERP system (orders, invoices, tickets, etc), and (B) the people who actually do whatever it is that the company does.
(C) - License costs can also play into this partitioning.
Then you hope (and work to ensure) that the benefit achieved for B, by having consistent org-wide information systems to work from, is enough to cover the overheads of A and C.
Executives want to have successful projects to show to their value to an organization. But usually the board members are unable to comprehend the details of a project. So the herd mentality kicks in. The CTO will seek approval for SAP and provide Gartner magic quadrant BS to give the board a level of comfort.
Now whether SAP is the right tool, or if it inconveniences users doesn't matter a whit to the CTO. All that matters is budget and timeline. The CTO wants to be able to speak to the board and say that the project timeline was met and under budget. All else is a complete non-factor.
In many cases, no. In part because the people that do the operational work aren't the same people who work for the decision maker.
Big players tend to do the minimum, either attracting with shiny red herrings or barely doing anything at all. Both are bad UX.
This is the crux of why enterprise software sucks: the user is not the buyer.
For all its faults, SAP is the market leader ERP. Without knowing anything more than what I've read in the general press, I'm fairly confident that the implementation could have been a success.
Trying to do those two is a clear signal of incompetence.
General Marshall, Eisenhower's superior also delegated broadly, while making key decisions as to the timing of the invasion, which units would be involved, and making sure all the disparate organizations involved were used to the best effect. Again, delegating broadly, as a good commander should.
This goes on and on up to Roosevelt himself, the Commander in Chief at the time. Does he know jack about the tide tables on Omaha beach? The range of a German 105mm howitzer? Of course not. Yet he clearly mandated the important decisions.
All three of these leaders were clearly EXTREMELY competent.
Now I favor ugly but robust UX for business applications. The user doesn't have to love it, it's their job to use it. It just has to be efficient and comprehensive, not pretty
The same dynamic can occur with hedge funds, where the incentive is to increase variance (because high volatility pays the fund managers a lot more on average) or increase risk (example swing for the fences if underwater).
It is a trust problem because organizations generally aren't worried about losing money they don't spend that year or the next. They're worried about never getting it back. When you use a ratchet approach to budgets it doesn't allow organizations to respond to responsibilities which may be cyclical in nature. This leads to permanent worst case thinking which leads to hording.
edit: on the other hand: If I'm going to quit the job next year and I don't like my successor I'm definitely going to cut corners and budget.
We already know the answer to this, on average at least the system will be gamed to put money in their pockets, to overall detriment of service.
The people who are hurt by it are not the people deciding to buy it.
SAP looks great for Csuite executives when it produces reports. For an engineer trying to enter their hours it's an hours long torture session every two weeks.
(Microsoft uses SAP as an ERP).
(This was also my motivation to start my own financial reporting startup: what if we designed a system in the year 2022 to be able to support big businesses without it being as awful as big business software.)
Furthermore, AFAIK Microsoft started using SAP well before they acquired Axapta.
They had evidently selected one approved hotel to demonstrate the process and never bothered to go further.
The hotel was some four-star facility 40km from the office and twice the price of the economy tourist-tier hotels 5km away (which also featured free wi-fi and breakfast). So the remote workers continued to stay at those hotels and had to waste effort poking the system to do an override.
Fortunately, they still did it as "pay with your own account and we'll reimburse you" so you weren't stuck waiting for someone to approve a "can I pretty please spend less money and avoid an extra two hours of travel time per day?" request.
At my prior job, we were trying to do marketing for a SAP consultancy firm, and it was just surreal trying to get a grasp on it. How will potential customers know they're ready for SAP, or ready for your services in particular? Where do you reach out to potential buyers? What sort of messaging are you trying to target? I never got anything resembling an answer. I think they basically just wanted us to write the HTML for the terrible email blasts they sent to their existing lead pool.
After a thought, I suspect there's a particular corner of the C*O universe that treats Gartner reports as some sort of Death Note: a supernatural document where once someone's name appears in it, their entire destiny and fate is fully programmed out. I think they pretty much believed they could ride being in the Magic Quadrant for Nasal Hair Removal Advisory Services in 2006 into golden retirement.
Beyond that, just the philosophy of creating a "purchase order" to pay a UX researcher who did 10 hours of work over three months seemed goofy -- purchase order is what I think of when doing something like ordering printer paper, not getting an invoice paid.
How can you pay an invoice for a service / item you haven’t purchased? If you buy a service from a supplier, you raise a po, you pay an invoice based on the po. As a supplier, I always ask for a po.
And yeah, there's a lot of paperwork but maybe you're hiring this gal because she's your sister. Maybe she's really good. Or maybe you're just funneling some money to a family member. As companies scale up they need controls for a lot of things even if they're legit 95% of the time.
And, again, not a software issue. It's a perhaps necessary bigco process issue.