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.
Probably not. SAP is an everything-to-everyone product. Using Fred Brook's terminology for essential versus accidental, the problem with everything boxes is that even just the essential complexity of such a product is so insanely large that they are sufficient to produce a "horrid" product. Of course they don't have just the essential complexity and add a healthy dose of accidental complexity, but so would any putative "less horrid" replacement by the time it successfully solved the same essential problems as SAP.
Closer to home, "bug tracking" is an example of an everything-to-everyone product. I can't even count the number of times I've seen a "simpler, less horrid" bug tracker get started due to the perceived horribleness of the current bug tracker, but the new bug tracker simply became the old one once it tried to grow into the same niche. This may sound strange to 2022 ears, but I remember when JIRA was being pitched as the simpler solution and developers were pretty keen on it. There will never be a mature bug tracker that is any fun to use, because by the time it's everything to everyone it'll just be the same morass of being everything to everyone again. It turns out that the "less horrid" bug tracker wasn't actually intrinsically less horrid... it just wasn't everything to everyone. Instead it was a bug tracker for developers, so developers love it. But then if developers are going to be allowed to use it everywhere, it has to satisfy all the other stakeholders too, and it inevitably mutates into an everything for everyone product.
(See also: Salesforce. Letting users configure custom DB schemas is a key indicator of being an everything to everyone product. To some extent, programming languages too; there's a lot of people who pine for something simpler (such as the people who think that if we just went to visual languages, or tried to jam everything into "no code") and don't understand that by the time you have a general purpose language that is truly general purpose you've got a large amount of irreducible essential complexity whether you like it or not.)
https://www.thirdstage-consulting.com/the-biggest-erp-failur...
Larry Ellison had a famous quote from some Oracle ERP event where he chucked every Oracle ERP consultant under the buss by saying: "It doesn't do everything you want, but it does everything your business needs". He was referring to custom workflows business take on which require massive customizations of ERP platforms, increased consulting costs and a painfully hard upgrade process.
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.
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
Personally, I rather liked the approach that Oodoo takes: https://www.odoo.com/
It tries to be pretty modular and even the cloud hosted plans can be mixed and matched, in addition to which the apps can be self-hosted for free: https://www.odoo.com/page/all-apps
Of course, attempting to compare it to something like SAP is a bit like comparing OpenProject with Jira or something along those lines: where one of the solutions is way more popular and recognizable, even if the other could be serviceable in certain scenarios. It's pretty clear which one will be picked by most of the enterprises, though.
SAP is the "European" way of doing things, which means there's one right way and you need to align your business to SAP's way of doing things. If you do that, things work very well.
Peoplesoft is the "American" way of doing it, which means that you make your software fit around you. This means a lot of customizations. This makes integrations much more challenging if you're too far off kilter, and things like upgrading is much much harder, because there's too many customizations.
That's the information I had about 10 years old and not sure how much SAP has evolved since then.
Smaller companies these days have a lot more options, like Netsuite is already there for small businesses and Workday is moving in that direction. Startups come and go every day. Rippling appears to be one that is headed in this direction as well.
I used to work at a company building software that competed directly with SAP products. The IT people in our customers’ organizations were the hardest people to convince to adopt our software. The end users loved our stuff because it allowed anyone at the factory to build forms and share data. But the IT folks would always get in the way.
“Nobody got fired for choosing SAP.”
Competing with them is super hard because of that.
Alternatives do exist. Well, one does - Oracle ERP. Migration is indeed long and close to impossible, and it’s very much out of the frying pan into the fire.
We've spent 3 years refining our processes and automating our ERP system, both the data structures we need and the design of the UX. No thank you SAP
A few years ago, I was working for a small, family owned industrial company. They were in the process of moving all of their ERP stuff over to SAP. Things were slow with some of the UI/UX stuff I was working on and someone asked me if I wanted to learn how to be an ERP developer.
Before I was shown anything, the SAP guy pulled me to the side and told me, "Fates, I know you could probably write a DB program significantly faster than what you're about to learn, but this is just the way the software was written."
Cue several of their SAP people dropping random stuff in my lap and me taking days and sometimes weeks to discern how to do it in their UI. It was the most maddening thing I've ever tried to learn. I just remember this graph paper like grid and having to line everything up perfectly or the program wouldn't run at all. I felt like I was working with something from the 1970's, it felt that out of date.
I finally told my boss I couldn't do it anymore, it was driving me mad.
On the flip side, I play hockey with a guy who is an SAP sales person and makes hella money selling their software and thinks its the greatest thing ever.
I don't know about SAP, but one of the main reasons we're adopting Retool internally is because our engineering team keeps deprioritizing writing internal operational tools in favor of adding features for out customers, yet our operations are becoming increasingly more complex. Something like Retool lets our end users (our own staff) be able to work with it.
In a lot of ways, Retool is more like an MS Access, only it is a cloud native SAAS and from the get go, work with integrating existing databases. Writing about SAS, I think it's clear Retool has been thinking about how to grow with the organization, possibly where organizations can stay with Retool instead of trying to implement SAP. I'm also curious about how they are going to work with the increasing shift from "data lakes" to "data mesh".
Fresh out of college, with a full two week (!!!) training on the product, I was sent to a customer place, to build some forms for them. Apparently they were not important or big enough for senior people, so I had the privilege (!!!) of building forms using our software for this client. I spent two days building the perfect form, then suddenly all the layout was lost. I couldn’t recover the layout, I call my team. They casually say our layout engine can be finicky sometimes and will refuse to work if you annoy it too much. No one told me though.
Thankfully I found another job soon.
Many of these so called enterprise products are terrible. But they’re so entrenched that it is next to impossible to beat them. They’re also expensive and their business practices dubious.
For many companies it would be easier to do an asset sale of all their IP than to replace the ERP.
Since most ERP implementations are horrendously overdue and over budget, they are usually declared Done before they’re actually finished. That leaves a lot of crud and manual processes in their wake.
In addition, so many of these systems are on prem using hardware, operating systems and databases that haven’t been supported in decades.
I’m getting nightmares just thinking about it!
I'm sure their goal was to eventually replace SAP. Instead, I think they ended up with an 80% solution that requires the customers to invest 20% as much time as a full SAP setup.
For instance, Salesforce spends a lot of effort on sales and customer facing things. SAP does that too, but it also does logistics. Logistics infrastructure is much harder to reuse across industries than sales and customer support.
True. Making something with a less sadistic and convoluted UI is the easy part. Migrating the data is the hard part.
Many companies died from updating ERPs.
They protect and take care of a lot of problems, the issue is they're so flexible that sometimes people build ad-hoc things on top of them and over time it becomes a ridiculous monstrosity similar to any other system in a company with major legacy.
There is no inherent solution to this problem other than disciple (or control, which has it's own productivity issues).
A lot of things developers must build in, and decisions developers make, are built in already for these systems.
more likely situation would be the companies stuck on SAP themselves dying and SAP eventually dying as a result of that. Obviously that's on a long term timescale, but smaller companies not burdened by legacy technologies winning is pretty much the story of modern business
It's probably also too boring for any tech entrepreneur to even try, but disrupting the space would seem to be the white whale of startups. You never know. At one point in time nobody had a computer on their desk either.
Isn't that where Salesforce came from? At least in the CRM space. It is not as horrid, though that is not saying much :P
And yet somehow last time we had this discussion on HN, more of than half of the developers have never heard of SAP.
Sorry friend, that is not a joke - at least this was attempted once! :)
These go hand in hand
I have a family member who has had enough professional success with SAP; when I mention projects there is a specific response he has that relates to this.
tl;dr- If you change your processes to follow the SAP happy path where they don't you are OK. The more you go out of bounds the more problems you have (be they problems of kafkaesque workflows, or paying the bills to customize it while the scope of customization keeps changing.)
I don't know how true that is, but it's there.
SAP removed virtually every automation advantage of the old system, and added the additional complexity of navigating the SAP GUI. Because of this additional workload and the reluctance of the company to hire more people to counter it (after all, SAP was implemented to streamline everything!), employee turnover suddenly skyrocketed. Everytime I talk with my mother, she complains about the system and tells me that another colleague has quit. She only stays because she only has 2 years until retirement.
I don't work with SAP, but I've been working with Microsoft's ERP(Dynamics NAV/Business Central) my whole professional career(almost 5 years).
When it comes to shipping, manufacturing, HR, supply, sales, planning, quality assurance etc... every big company is going to have a million edge cases which are impossible to cover with the standard functionality of an ERP. And most importantly - hundreds, or maybe thousands of employees that have gotten used to working a certain way.
When you try to make your process fit to a standard ERP functionality you are fighting two dragons:
1) Working your way around edge cases - with the right consultants/developers this doesn't have to be a big pain.
2) Getting your employees to change the way they have been working for years, or even decades. And in addition giving them an overwhelming UI - I've never seen this work as planned. This is also probably the reason the company your mother works for had so many pains.
On the other hand, if you try to make the ERP fit to your processes, there's only one dragon you need to slay - extending the ERP's functionality.
I can only speak for Microsoft's ERP, but everything that is impossible or hard to extended within the ERP itself can easily be extended through an outside application. And by doing so, you can probably even make the employees job easier by keeping the process the same, but giving him an UI that isn't overwhelming.
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)
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.
Is this the story of every migration, every rewrite though?
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)?
I took a brief look at the ABAP wikipedia article and this insanity [1] stood out to me. I think after a decade of SAP you are too brain-washed to give an objective opinion anymore.
Yes, the scope of ERP and SAP is so immense that even other software companies that have competency in the business of programming also buy SAP licenses instead of coding their own home-grown ERP system.
E.g. Microsoft, Apple, Amazon, Google all run SAP.
Microsoft even has their own ERP software (Dynamics GP acquired from Great Plains Software) and yet they run SAP. Microsoft sells Dynamics GP to mid-tier businesses but they don't use it internally for the consolidated financial accounting of their complex multinational business.
And in an interview about Google's early days, one of the employees recommended that they install ERP system like SAP and co-founder Sergei Brin was skeptical saying "Why would they need to buy that when their programmers could just code it themselves?!?" Well, Google did eventually buy Oracle Financials ERP and then eventually switched to SAP: https://www.google.com/search?q=google+migrates+oracle+finan...
If you're a brand new YC startup, you're not going to need a complex behemoth like SAP ERP. Maybe Quickbooks or some SaaS service for accounting & HR/Payroll is all you need. However, if the business grows enough (i.e. multinational), you'd be wasting money by paying your own staff programmers to re-invent what SAP already does. Just pay the millions in SAP licenses. It's expensive but still cheaper than trying to do it yourself.
The first time we brought in someone truly experienced in SAP development, we paid him more than any other developer on staff[0]. I appreciate the different take on SAP. Can I ask -- is it still as lucrative to be an SAP developer?
[0] This was a global multi-national telecom who ran an in-house developed audio conferencing service (written entirely in C++, interacting with a lot of hardware) ... the skillset of some of our devs was incredible, which made this all the more surprising.
I do see how Fiori launchpad is a great thing, how HANA is extremely powerful if you know what you're doing. At the same time I couldn't stand the corporate culture, QA processes and etc anymore. There're innovations and innovative teams but for the most things SAP is doing, software development is not the core competency.
Fun fact: I work with Datapath now (if you know what it is then you get an irony)
This should be the SAP tagline. I swear I've heard this since I started working with SAP in maybe 2009(?) as well - I had a brief stint as an ABAP developer.
Does SAP even have ERP in the „real“ cloud?
1) Your company processes MUST adapt to SAP processes.
That's it.
You can try customising SAP to fit your processes, but you will just waste time and hundreds of millions of money and then you will fail.
Lidl spent almost a decade and 500M€ on its SAP project, but didn't follow rule #1: https://www.henricodolfing.com/2020/05/case-study-lidl-sap-d...
What you've said is absolutely true, but it's mostly a feature, not a bug. Once you get big enough to need SAP, it's actually useful to put your business processes on a standardized platform. It's painful, always mind bendingly expensive and often fails. But few companies want to be innovative in their business processes. It's actually better to move to "the standard" since it makes processes more understandable across different ginormacorps, which is useful for the upper management sorts that tend to move between them. There's virtually no competitive advantage to having unique business processes. There are many folks that even will say that that's the advantage of moving to SAP is it makes the internal mechanics of the company work a lot like every other giant company.
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!"
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?
Telling SAP that you want them to change their ways to accommodate your brilliant idea is akin to a layman telling a brain surgeon how he wants his surgery done.
SAP is sold to the C=suit, never to IT or business operations, nor any of the people that will ever come onto contact with the software.
SAP is priced based on your company's revenue. In industry X typical spend on IT is y% of revenue, so SAP will charge you a project for an amount equal to y% of your revenue.
SAP project often fail (this is not specific to SAP but common for large projects). Making sure that in case the project fails it is the customers fault will be strategically taken into account from day 1.
SAP's revenue is for the large majority based on consultancy and education revenue, not on software sales.
SAP's data and business process model maturity varies extremely depending on the industry and business segment. This will not be clear in the sales trajectory and not easy to discover upfront.
SAP is a fairly closed ecosystem. Typically consultants are recruited straight out of school and never leave the stack as it is very different from the rest of the industry. It has it's own cultute and habits that do not travel well outside of it's niche.
Plenty of terrible corporate software works like this. Precurement has a checklist of features, and that list never includes "Has great UX", because only the people on the floor has to use it.
I'm looking at you JIRA...
> SAP project often fail (this is not specific to SAP but common for large projects). Making sure that in case the project fails it is the customers fault will be strategically taken into account from day 1.
I was a consultant at a major software consultancy for the better part of three years. No matter what, it is always the costumor's fault, even when it isn't.
Paying a customer back some 100 billable hours worth of payments is simply just not feasible, when a large part of consultants have less than a years worth of work experience.
While you sit down and talk about the project with senior and managing consultants, you are being deluded with a completely skewed perception of the base level competence of those that will carry out the work.
The higher hierarchical "level" a consultant is at, the less implementation work they'll do, because associates will take longer time doing the same tasks and will therefore sell more billable hours.
The entire T&M consulting industry is economically incentivized to produce organisations that shirks responsibility, while simultaneously work on "too big to fail" projects, because that's where the money is at.
> SAP is a fairly closed ecosystem. Typically consultants are recruited straight out of school and never leave the stack as it is very different from the rest of the industry. It has it's own cultute and habits that do not travel well outside of it's niche.
Not to mention that it has its own programming language. I had a colleague that worked as a SAP consultant, and she said it was horrible. Features like "variables names can consist of at most 8 characters" certainly didn't help.
The company I work for maintains and has built some custom ERP solutions. While we've never dealt with SAP directly, almost universally the mindset of the IT departments at these businesses is that they are the last defence against the dark forces of SAP.
ERP migration is a terrifying thing and they seem to fall into the same pattern every time. Company has their way (workflows, processes, strategies, philosophies) of doing things. New ERP consultant promises the tool will adapt. Company spends $50M with consultant and product trying to make the tool adapt. Pain loop of "Well, it can't really do X like we said, but we can make it do Y which is close!". Company either a) bends to the opinionated process of New ERP, b) cuts their losses and runs, c) spends years and millions more trying to fight the opinionated process and then cuts their losses and runs, and/or d) goes bankrupt.
It seems to me that the only way to do this right is to spend as much time as it takes nailing down your processes and workflows, being honest with your company about what you need to change, what you want to change, and what can functionally change. Then use the broadest technology possible and create a custom solution. I feel like there's room for a broad business logic framework/library.
Sap's secret sauce was understanding that different companies have mostly the same needs. All have employees that need paying and maybe shifts to be tracked. All generate invoices. All buy stuff from suppliers, etc. So they built different solutions (HR/FI/etc.) For those needs. All running on the same technical platform with its own programming language: ABAP. All domain code is ABAP and everything is readable, you can even debug code that SAP wrote years ago but (generally) you're not allowed to change it. And it's full of comments in German so good luck :)
For medium to large companies it's a no brainer to use SAP so most do. For example Sap keeps the client's systems compliant with new laws. Say some country changes laws on how employees pay taxes, sap updates the code or tells their clients what's needed to update the systems.
Companies that have been around for a few years, most likely they already have SAP so makes no sense to shift to something else.
SAP's ERP code is also quite generic. Tons of configurations are possible in any module. E.g. you may have employees but no shifts. Or maybe you have 200 different shift patterns across many factories to configure. Configuration is so complex it's a well paid profession in itself: the functional consultant.
When that config is not enough to implement the requirements then developers can modify the system. Either changing existing ABAP code, or building new ABAP programs or (more commonly nowadays) just building webapps with the normal tools (react/node.js/java etc) in the cloud and using sap ERP as a backend to read/write data to. This last one sums up my day to day.
ABAP is interesting though. Syntactically it looks like COBOL and that you've gone back 40years plus most of the DB tables/columns/data types have seemingly random names like WERKS or DMBTR. They make sense in German after you've shortened the German meaning to 5chars :). So ABAP code looks very cryptic at first sight.
But semantically the language is ok. It is strongly typed, has some nice features for working with finance programs (e.g. fixed point arithmetic) and an OO model that feels familiar to anyone that knows Java (e.g. single inheritance).
* Compliance * Standard Processes * Interoperability between companies (a lot of purchasing runs automatically through some sort of SAP Software)
What mostly fails in my experience is the customization. Everybody thinks their process is super special and important and needs 100 escape hatches. But if you ask them to draw their process on a whiteboard, they couldn't do it for one single process without drawing 100 question marks.
That is where SAP shines: The whole thing is so bureaucratic, coming from Germany, which is something you will need after your company has grown beyond a certain size.
In a postmodern ERP there is no ERP.
It’s a strategy where you accept that different domains and companies know their business and processes best and you integrate best of breed systems & services with homegrown solutions.
You trade the convenience of letting SAP or Salesforce own your processes against flexibility and actual agility.
The cost is competence - you’ll need developers working in stable, dedicated domain teams, even within the administrative/cost-center areas such as HR & Finance. But there is a massive potential in this approach. It forces ownership of processes and allows for rapid changes of digitized processes, integrations and technology.
I must stress stability of the teams: agility comes from building domain knowledge and continually working on contracts between organizational units over time. This is the complete opposite to classic project management.
SAP caters to non-tech savvy businesses people striving for control, which is something they think is achieved through “one system”. I personally call it the “one system trap”.
In the end what matters is data, and that data do not have to reside in one database. In fact, it’s better for everyone if it doesn’t - this is what ELT is for.
[0] https://www.gartner.com/en/information-technology/glossary/p...
When my sister started to working at SAP working on documentation, I had to look at some of those. I noticed something like SAPUI5 and thought: hey, this looks pretty modern and nice and something that competes with Microsoft offerings! https://sapui5.hana.ondemand.com/#/topic/8b49fc198bf04b2d980...
Then I see them documenting/pushing people in CI/CD direction (https://help.sap.com/docs/BTP/65de2977205c403bbc107264b8eccf...) involving Docker, Kubernetes, github and stuff like that. Pretty modern.
I went onto HN to learn how people feel about the development tools they provide and found... nothing. I was like: what? How can they have slick documentation, processes, tools, frameworks, cloud offerings, database (SAP HANA?). So basically I thought - so much competitiveness for Microsoft there. How come HNers don't mention this? What are the people working with this tech? Germans mostly or what? But navigating their documentation, tutorials feels something that could be evaluated as a modern development platform.
It is built on top of jQuery and extremely slow. They are very adamant on MVC with two-way databinding (the opposite of React or most other frontend libraries that have been around for almost 10 years). The backend request is geared toward OData (think graphql but table-oriented), and adding logic between the UI and the OData endpoint is hard.
SAPUI5 is hard to use even for a mediocre screen need. It aims to get the simple apps really simple to write (to lower development cost), but at that it kills the productivity of all the other apps.
Getting back to documentation, after your app is not just some components living in logical islands but have to interact with one another (think getting data from one place to drive another component) most of the time the documentation did not help with that, and I had to resort to debug the whole library internally to understand it.
Add all that to the fact that they don’t even care to support firefox for non-windows users bah
It is really understandable why no one but SAP uses this library. It was made for one use case by sap for sap and that’s it.
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.
UI5 is a travesty. It is a complete disaster, and if I somehow ended up working on it, I would not put that experience on my resume out of shame.
1) They do Enterprise Resources Planning.
2) Because ERP is immensely complicated, and encompasses features that would be useful for almost anyone coordinating any organization, and ERP systems are really hard to change, so they have acquired a user base with lots of zeroes and a thick moat to keep them in.
Now, I get it, once you have to deal with taxes and payroll in multiple countries it gets messy, but why wouldn't you consider that a core part of your business worth investing into? You may not be paying with accountant salaries, but you are still paying with yearly contracts you can never get away from and with a horrible user experience for every employee that has to interact with it (oh, P69, how much I hate you).
Some people dream of being a superhero. I dream of being one day big enough to have an SAP salesman come to me so I can tell them "no".
Comparison with hosting your own email is like a dozen orders of magnitude off in complexity. SAP really only makes sense for ginormous corporations, but up in that range, Oracle's ERP is the only real competition. Just the kernel of SAP is on the order of 100 million lines of code, and that's not counting the even more hundreds of millions of lines of business logic.
It'd be more like saying, "I'm going to reinvent email, write all clients, servers, and try to get everyone to adopt it." Except that would still be a few orders of magnitude off.
SAP has modules that handle regulatory issues in virtually every country in the world. There's so much business complexity that's encoded into its systems that it's literally hard for mere mortals to grasp.
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.
I was chatting with a member of the small army of project managers involved, and I was trying to explain to him that for that kind of money I'll build them a whole new mainframe from sand. Silicon, circuitry, operating system, applications, everything.
For two billion dollars you could literally afford to build a dedicated foundry just to stamp out the sheetmetal for the case and still have 1.9 billion left over for everything else.
Because it's a complex legal issue that isn't in the competency of most companies, getting it wrong has consequences. Since most companies have similar legal requirements, there's enough scale for a large 3rd party. Also, some countries require the local IRS-alike to approve your software if you wish to file certain tax reports. Bad UX pales compared to these requirements.
I think we've established from the various "I give up hosting my own email" articles posted on HN that this is basically down to luck.
Yes, that's true, and every organization of any size (one sufficiently large enough to implement SAP) will have experts in those domains. The problem is that implementing them in software is a large task - definitely not impossible, or even extremely difficult (it's just CRUD on a grand scale), but you need software that can change quickly when new legislation is implemented, etc. Painful, and the reason why so many do implement a COTS ERP. Hell, even Google run SAP S/4HANA these days (they migrated off Oracle ERP AFAIK).
Good luck competing in that industry
> basic installation of SAP has 20,000 database tables, 3,000 of which are configuration tables. In those tables, there are ~8,000 configuration decisions you need before even getting started.
Gotta be fun :)
[ ] Digital Bureaucracy
[ ] All of the above
[ ] None of the above
My little pet theory is that the old "Do as you told" buisness-culture is to blame for germanys inability to produce great software. Software needs developers with agency, who refuse "idiotic" tasks and fight back to improve the product.
Know an israeli who complained about "endless arguing" in israeli software projects, while not recognicing the strength of that.
If its not fought over, all things are developed, all things become meh, teams exaust themselves doing all the things and the product fails, internally unoppossed, but externally years to late, bloated and mediocre to the core.
Still happy that SAP exists.
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.
- 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
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
Anecdotally I knew a few people in the mid nineties that did SAP work and they were paid multiples of everyone else, literally hundreds of thousands of dollars a year. Since then lots has been outsourced and offshored so its the opposite, but for a few glory years before dotcom boom it was definitely the place to be.
SAP sells you a software system that includes ready-made workflows and battle-tested instruction manuals. Plus they can synchronize your purchasing and sales departments with everyone else that also uses their software. So if you want to start a small company working with the big car manufacturers, you buy SAP and suddenly you can send quotes in precisely the format that VW expects, because you and VW now both use the SAP specification. In that regard, signing up for SAP is quite similar to signing up to be a Subways location.
the goal was to create some transparency for the producers and to fight coffee-loss (every step taking a bit coffee away and sells it otherwise).
the project was a huge success. With fast adoption and immidiate benefit for the farmers and village collection centers.
the software behind it is SAP! and they do not even charge for it, they sponsor it - together with Deutsche Entwicklungszusammenarbeit.
Why?
Even though Uganda is not yet a profitable market for SAP.
And not in 10 years. And not in 20 years.
In 30 they might.
At these kinds of numbers, I've got to ask a genuine question here: what's the benefit of using SAP as opposed to rolling your own solution?
From reading some of the other comments here, it sounds like getting your business to integrate with SAP involves trying to fit a lot of square pegs in round holes and doesn't always succeed in the end anyways.
At these levels of stratospheric costs, it seems like it would often be cheaper and less risky to simply use your standard software stack of choice and build a custom web app over a database that mirrors your existing business processes perfectly, and then transform/integrate those processes over time as needed for increased efficiency.
Some thoughts:
* Most companies are not software companies, and most c-level managers are not tech leaders. They treat IT as an annoying expense, like taxes. The idea of hiring software engineers to gather requirements and run a lean process to build efficient software from the ground up on a modern web stack is as foreign to them as setting up a chemical processing pipeline and logistics management network is to me.
* Rolling your own solution takes time, and more importantly, energy and involvement of the whole company. I would argue that it might take less time than a big SAP implementation, but with the latter you can just hire a big consulting firm (there's that cost center again...) and they'll deal with everything for you so your people can just work.
* This is a bit of a chicken and egg thing, but: A lot of SAP's customers aren't startups. If you're hired in the be the CEO of an oil company running major pipelines, you've already got SAP running everywhere. And you do your first big move and acquire a small competitor, and THEY have SAP running too. So why are you going to embark on a huge software development project when a) you're not a software company, b) you're not a startup leader, etc. etc. etc.
Although to be honest, the success (?) the US Government has had doing basically what you propose via the USDC / 18F does give me some hope. But alas, much of the world is too far gone already (sigh).
"We held firm to the NO CUSTOMIZATION rule, we re-engineered our processes to fit SAP. Other than a few hiccups when integrating all aspects of a company that has 100 sub companies, and is under federal, state and local regulation the project basically went off without a hitch." [0]
I've made a living writing custom software for engineering, embedded with engineers, that fixes problems with these monstrous systems, and which IT could never implement in 100 years.
So, yes, companies with CIO's who want to make a name for themselves (and probably collect a kickback in the process): PLEASE continue to implement these hundred-million dollar IT systems. You MAKE a lot of extra work in the process, guaranteeing job security for everyone who has to use them, and work around them.
You'd think that Fortune 100 companies would put people into positions like the CIO or CTO who are sharp enough to understand how this REALLY works out, but I guess those kinds of people aren't politically savvy enough to reach that position.
At the end of that year, Mercedes hosted a "we're sorry" conference in San Diego and paid for all parts and service managers across the nation to travel and drink at the open bars for a week. I guess that part was okay.
When you tell a warehouse worker to pick up an iPhone from row A4-143-X and it's not there, you need to figure out why. So yes, doing the accounting for that involved a "status" flag to figure out what happened. If another iPhone is later found in A5-143-X, great.
If not, at the end of the year you do the math how much stock dissappears "for unknown reasons" and you have your number on "possibly employee theft". To balance the books you can't just put an amount and "IDK what happened to it".
Bit harsh to mention this, but SAP (who run SAP ERP internally, naturally) have not been immune from bribery scandals -
https://www.thesouthafrican.com/news/sap-apologise-to-south-...
https://www.reuters.com/article/us-sap-se-safrica-exclusive-...
A bit more background: https://www.news24.com/Fin24/what-sap-really-knew-when-it-pa...
It would be quite hard to write such things for SAP (it's too monolithic, even if you find people to write such things the moment they come for you they would have the access to all your illegal data) , but I knew of people who ran two sets of accounting bases, though that was mostly for tax evasion purposes.
In Germany, for a long time you could write-off bribes made in foreign countries as a tax expense. It was handled just like any other expense (e.g. telephone cost goes to "telephone costs" account, bribery went to a "bribery costs" account). Also you had to provide some proof that the bribe was actually made. It was ok to cheat foreign countries by bribing their officials or bribe purchasers from other countries to purchase your stuff, but it was illegal to cheat the state of Germany by making a non existant tax expense (for a non existand bribe). After EU was formed this practice became illegal
For the rest of your question, SAP allows you to keep multiple ledgers. One ledger can be official, others unofficial. Those ledgers are conceptually something like "views". Some managers look at different stuff. For example you can have one ledger ("view") done as per local accounting regulations, another as per US GAAP, another per international accounting standards, another just to calculate local tax.. and yes "local tax ledger" is often different than "local bookkeeping ledger" (mostly different way depreciation is calculated). Why would you make self incriminating evidence I dont know. Probably you are sarcastic. But usually the cheaters misclassify stuff in their books (e.g. revenue recognition - like Enron), or not show it at all (e.g. financial derivatives). I saw also something made of nothing (inventory movements that increased value).
Employee theft is just generic FI-AA accounting. When you have many employees sooner or later someone will steal something valuable that the company kept on its books (say an expensive laptop). Other thing is if you catch them.
If your company stole something, you can supposedly just recognize it as unusual gain and pay tax on it. I am not a lawyer so I dont know if your corpotation can go to prison ;), but some say that the tax office wont care if you paid the tax on the stolen goods (this is not tax advise). I heard about a construction company that got some tools from other company (that didnt want it back - they were shipped far away) and they just recognized it. Not sure how the other company dealt with it, sounds like criminal negligence. But maybe they didnt write it off from tax point of view. Was just a cost of running business that ate their result, but not a cost that decreases tax.
I heard that corruption is just handled by giving a bonus to the sales person. Then the sales person just cashes it out and uses this cash as a bribe. Of course such practice is illegal in civilized world. Also illegal if your parent company is in civilized world - they will even make you take those obligatory trainings about that.
If you are interested in reading about tax crime then search for articles about samen dividend used multiple times to change tax scandal. What has the very unfortunate name "cum-ex" ( https://en.m.wikipedia.org/wiki/CumEx-Files ). Some argue that the practice was legal in Germany for many years. Some say it wasnt.
Also you can read about money parked in Bermuda, Irish sandwich, treasure islands... many of those big companies seem to do those tricks.
Those arent related to the software you use
What I do remember is that it seems to be down a lot. I started working in 1997 and about twice a week we would get emails from IT saying "SAP is down" and then a few hours later "SAP is back up"
After a few months of this spam I set up an email filter.
I was on the engineering side. I still don't know what SAP is and I've never needed to learn but it doesn't seem like a great product for how unreliable it seemed to be.
As for downtime, that's probably not down to SAP itself; it's core business, if it goes down, companies can no longer operate and will lose millions. But, with so many moving parts, there's a lot of things that can and will go wrong if handled uncarefully.
Let's say there is some common business task that needs to be done. Maybe it's a legal filing with the local government, or tracking how many people at the company are using a particular piece of software for licensing purposes, or records-keeping for equal opportunity employment questionnaire responses. There are many ways to accomplish each of these goals, but most people will be familiar with the SAP way. The laws on the books will be written by people who have used SAP before, and public comments on the law will be made by people who have used SAP before. Ancillary tools to do niche features that SAP doesn't cover will work best if you've adopted the SAP way.
And so, SAP becomes enshrined into the law and society in a way that's impossible to duplicate. Even if you mimicked SAP's features 1:1, there would still be obscure quirks and bugs that you didn't capture but are nonetheless somehow beneficial to users' workflow, because those quirks and bugs have been imprinted onto the standard business practices in our world.
But I've written my thoughts about what ERP is:
You need to get some certifications?
Technology wise, it's weird. It reminds me a bit of Lotus Notes, in that everything including the screen layouts are stored in the database.
they have hosted plans as well as allowing users to selfhost and only pay for "support and customization" for anyone needing which works out pretty well for many....
SAP is well and good but you have good alternatives
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.
The come in ~6TB and ~12TB.
Somehow, that tells so much about SAP and the institutions that depend on it.
OTOH, the general principle of "just have a giant in memory DB" isn't actually that crazy. In fact, a lot of the complex distributed data storage systems that a lot of services use might just be better off with a system like it. See also: Stack Overflow.
It mirrors a dysfunctional business run on command-and-control rather than, like AWS, you have a large set of loosely affiliated teams and although you risk some duplication, it makes for much more agile work.
Imagine you have a supplier who supplies "products" but your system calls them "items", SAP would say that you have to standardise the nomenclature. Agile says, let them call them whatever works for them and lets build small systems with just the interfaces we need.
Sure, the senior management don't get their dashboards but it is still possible to get metrics from disparate systems and form pretty basic cashflow and inventory reports.
One has to remember that many large companies don't have an in-house set of software engineers to kludge things together, or a set of people to audit and make sure problems aren't accumulating silently somewhere because of some bug or some vendor changing their API or whatever. Even if they did, the supposedly "agile" solution proposed here just sounds rather fragile. You even see this in codebases that are built on a "microservices" mindset -- you start getting weird emergent patterns in internal dependencies that start bogging things down.
For a smaller or even medium-sized business, sure, maybe a custom solution works. But it looks like for the scale of organization SAP works on, it seems difficult for an individual to even understand all the components of that organization, let alone build something maintainable for themselves and their eventual replacements.
1. It is extremely challenging to integrate with. Your basic option is to overhaul your existing software to at least match the available integration options.
2. It requires constant care. SAP Expert Consultants hired by the companies initially for two years, which was supposed to be the timeline when SAP would have been fully adopted (and turned over), still works as the complexity and evolution of updating the software itself is tantamount to a new system adoption.
3. Users (Majority I would say) hate it. The only reason they live up with it is because someone higher up the decision and authority chain imposed the software after being sold to the premise that it is a game changer to the organization.
Many of those systems might be somewhat standard, covering account receivables, payables, inventory, sales, production, planning, supply chains, payroll/hr, relationship management and general accounting. Many may be versions of these customized to a specific industry or business. Others are unique and require a customizable platform to implement a custom system.
SAP offers such software that scales to the worlds largest corporations and organizations. How well it does that is of course contentious. That reflects its market worth.
I do however often work adjacent to SAP or have to integrate with it, and since I've been at this for a few years now, I've gotten to try a bunch of their stuff.
SAP's biggest problem is honestly just that they are absolutely terrible engineers, while they suffer from the worst Not Invented Here syndrome I've ever seen. They nearly always want to build their own thing instead of using something that already exists.
Do you want to build web applications that interact with SAP systems? Well, SAP uses OData almost exclusively for all of its backend stuff, and practically no one else uses it. This means all developer tooling, like libraries and such, are almost non-existent. So what do you do? You use SAP's UI5.. which is easily the worst-made UI library out there that anyone has ever built. It's technical debt personified.
No one knows UI5 except people who work in this business, so companies are forced to hire consultancies like mine, because no normal web developer has ever worked with it(nor would they want to look at it in their spare time). I can scarcely begin to imagine how many man-hours SAP has wasted on building out this gigantic turd, or how many hours they could have saved by going with, say, React, and instead building libraries and tooling around that.
This sort of thing permeates everything SAP does. Everything they do is some of the worst stuff I've ever seen.
But hey, it pays great money, and the company I work for has great benefits and lots of freedom. All other things equal, I don't think there are many tech companies out there that could offer me a more rewarding job. But that doesn't change the fact that observing SAP from close-up is like watching an on-going technical trainwreck that never ends.
I'm glad that someone else feels the same way I do about OData and UI5. I've used both extensively (initially to learn more about them and then because I need to develop solutions that can be supported by customers) and neither is, well, ideal. The worst is that the SAP ecosystem is a massive echo chamber, filled with fanboys saying how wonderful OData and UI5 are. Really, they're not - UI5 is open source and yet no-one uses it. Why? And let me not get started with CAP (WTF did you give a product the same name as Brewer's theorem?).
There have been some attempts to extract some of the UI5 controls so that they can be used with React/Angular but I can't see those ever being adopted. I've worked with UI5 development teams that struggle with even getting the basics of Git and love using that godawful WebIDE, so I have no hope for customers being dragged away from SAP solutions to anything vaguely "industry standard".
Sorry for the negativitiy, but after 20+ years of SAP paying my bills (and paying them well), I'm even more cynical than ever.
I don't know the internals of SAP. I really don't have to. For us, SAP is a collection of OLAP cubes that have a highly curated view of that part of the business that the SAP system manages.
And there's a clean API to this data since SAP supports the XML/A SOAP interface standard to those OLAP cubes. It is a very chatty API to extract the data from the cube - but it gets the job done. It allows us to leverage all of the business logic that goes into the cube schema, and the huge investment that the business makes in SAP. I could instead run extracts of the underlying source data but that would lack all of the business logic that goes into the cube definition. I do occasionally have to use their desktop UI to better understand the cube schemas. It is like a trip down memory lane to use the SAP user interface screens. Harks back to the 90s for sure.
Anyway, if anyone's interested in interfacing with SAP through a relatively clean programmatic interface, I highly recommend using the XML/A soap interface to the cubes. My client company's SAP team does a great job of building cubes that expose what is relevant to the business. The SAP data is merged with lots of other business data in our data warehouse and the business gets a modern web and Tableau reports. Problem solved.
Ha!
"This International Standard does not specify — the mechanism by which C programs are transformed for use by a data-processing system;" [ISO C, every version]
I'm not sure why in the early days they were more succesful than the competitors (JD Edwards, BAAN, etc) - all of the others were doing something similar but SAP overtook them all. Perhaps it was because the system was very flexible - if you needed to enhance the SAP-delivered functionality or build your own to integrated with SAP, they delivered tooling to do so (very crude in the early days, a lot better now).
Related to this is that almost all application souce is available to customers (not open source, but available to view and modify if required). For those who've never worked with SAP, the majority of the application code in their on-premise systems is written in a proprietary COBOL-like 4GL called ABAP. One of SAP's key differentiators in the early years was that customers had access to all of this code and, with the required access, could extend/modify as needed. A masterstroke IMHO.
Source: I've worked as an SAP consultant for 20+ years (including a fair number of those working for SAP) and I'm no fan of any of their products. For the number of extremely intelligent people who work there (and I mean that sincerely - a lot of their employees are /extremely/ smart and forward thinking), the code quality and quality control of their products is abysmal. It's like the majority of the code is written by people who did a training course last week and they /love/ overengineering things, reinventing the wheel or backing the wrong horse. SAP went all in on Silverlight at one point and these days they love OData, which NO-ONE really uses. It also took them years and years to officially support a browser other than IE.
At times they have done some pretty forward-thinking things though. In the late 80s they adopted three-tier before most (R/3, the first three-tier release came out in 1992) and they cleverly have a very portable application. Back in the days of the Unix wars SAP ran on pretty much every OS and all the major databases (heck, Microsoft had to convince them to port to NT and SQL Server, primarily so that Microsoft could run SAP on NT in their own back office).
Rambling a bit here but SAP still pays my bills (and fairly well at that), but I'm no fan and I'm always looking for a way out. Unfortunately, for me the situation is like many SAP customers - once you've checked in, it's hard to leave (apologies to The Eagles).
Most companies stick with a single ERP provider for 20-30 years. And 80% of attempts to swap in one ERP for another fail. Usually after customers waste millions of dollars and years of engineering work.
The underlying complexity of the physical processes managed by ERP is enormous. ERP systems are digital models of a company's physical operations.
Platform lockin and platform innovation are inversely proportional. Companies like SAP in ERP, and Epic in EHR, simply don't have to innovate to make lots of money.
That's one reason why technological change in those industries is so slow.
In our case, it was, basically a "success." I don't think that our customers saw too much of a change. I have heard nightmare stories of organizations, basically grinding to a halt, for months (I think HP lost about $400M when they switched).
It did result in the company hiring a bunch of programmers. Most were women, and they drove nice cars.
Where it's truly east to store data, create business units and UI interfaces and pro 'implementers' can do it quickly.
Then you have a company automated system for 'everything' that can just replace a lot of things like SAP, Salesforce.
Way in the future though.
It'll start small, in one area, and just make it's way to others.
Also, it will be it's own giant mess as 'implementers' screw things up and requirements from management change weekly.
The Lyons Electronic Office would beg to disagree. https://en.wikipedia.org/wiki/LEO_(computer)
The first business application to be run on LEO was Bakery Valuations, which computed the costs of ingredients used in bread and cakes [and] LEO took over Bakery Valuations calculations completely on 29–30 November 1951
The software is rather shit esp the old HR and MM stuff ported over from R3 but there is a HUGE ecosystem around it of consultants and consulting companies - nobody is going to get fired for choosing SAP.
It is a huge money hole - take any proposed budget and multiply it by 3.
But heck it transaction flow works and all the modules tie in with each other and the accountants are very happy.
Prior to that I was an ERP technical consultant. I've had the opportunity to work with many ERP systems at a deep technical level, on both sides of an implementation: the old system a company was moving off of, and the new system I was implementing.
I'm neither an advocate for, nor detractor of, any particular ERP system. Each offering has things it does well, and each has pain points. Unfortunately a lot of people cargo-cult their particular system of choice and lose objectivity. Software is simply a tool and is far less important than the implementation and execution.
A few SAP aspects that stood out to me from a technical perspective:
1. You are virtually guaranteed to have an existing capability available for any arbitrary business process need
2. The system architecture facilitates efficient data processing. Tables, forms, and reports tend to be narrow slices of an overall business process, and thus can reduce contention and concurrency problems. Batch jobs are utilized for background processing.
3. The user interface is lightweight and very performant over remote connections (e.g. VPN). Similar to older green-screen systems, data entry can be very fast for experienced users and does not rely on the mouse.
4. The API options for enterprise application integration are good
1. The surface area and complexity to match the capability is crushing. Tesla's relatively vanilla SAP environment had 10,000+ reports and T-Codes in it, of which I would guess less than 1% were actively in use.
2. Optimizing the architecture for scalability came at the expense of the user experience. One would often need to perform several tasks in order to answer a single need. For example, I would observe users exporting several reports, each of which provided a narrow slice of the information, and then combine the dumps in Excel to get the answer they sought.
1. It is very difficult to find subject matter experts who can deeply understand what a complex system offers out of the box, and successfully select the optimal capabilities and implement them for business processes. Or, in the case of true functional gaps, can modify and extend the system without creating a mess.
2. It is vital that a company retains the people who have the institutional history of a system and its modifications. Many end up with a revolving door of consultants, each of whom may be an expert in the vanilla product but has no company-specific context.
3. Clarity and completeness are at odds with one another. As you attempt to drive a system or specification toward completeness, clarity and understandability will diminish.
4. The longer an ERP system has been around, the more likely it will accumulate legacy and historical impediments. If a product aspect is working and widely deployed it tends not to be changed or updated to modern patterns or technology. An example in SAP is the cluster table concept, which as I recall from the lore some years ago was a workaround because SAP needed more columns per table than Oracle allowed. Cluster tables do not spark joy in data migration and egress when ABAP is not a feasible option.
5. Also for long-lived ERP systems, from the user experience standpoint, as these systems incrementally evolve over time the standardization and consistency of behavior across modules and application areas tends to fade or diverge. AS I recall with SAP for example, some transaction forms and reports can export to Excel, while many others do not: the feature was not or could not be added as part of the architectural core but was instead bolted on later to limited areas. A young ERP typically builds this in as standard core feature which is available on all forms in the product.Would like to hear of cost/focus tradeoffs after so many years of use.
Anyone at Tesla thought of open sourcing it?
And yet. They thrive and grow. I always leave with the impression that it really does do things well after all, just not in obvious ways.
I had a upgrade process meeting for SAP and I invited my usual SAP engineers.
I had a polite decline from one of my favorites so I dropped by her desk to ask her why she wouldn't come.
"I work on SAP 7, not SAP 8. I'm going to be retired in 2 years by the time this project kicks off and dead by the time it's implemented"
My last name is Sap ( translated to Juice from Dutch).
Recruiters don't get it. So my linkedin profile says: i wish my last name was DotNet instead of Sap :p
Absolute joke of a UX/UI. And don't tell me it can't be done better. The dated, out of support one we had prior had a better UI.
My parents won't ever praise Delphi, yet they (probably) still use that piece of software I wrote with Delphi 20+ years ago.
It does, notably, have an integration problem because the rest of the DHB services don't use it.
Nothin' much, how bout you?
This doesn't seem realistic if they mean inflation adjusted; do they mean using today's exchange rate? Or are both numbers inflation adjusted?
(For those who don’t know Sybase supports an SQL implementation which is seemingly used nowhere except sales and trading for Wall Street banks, who largely adopted it in the 90’s and have been slow to move off. MS SQL Server was originally a port of Sybase.)
You'll save tens of million on implementation, you'll get better support, your users won't want to kill themselves...
The rest of the world went one way, and SAP another, and believers are obsessed with it. Despite every other thing they do going an entirely different direction.
At least my company auto books the flights out of their slush funds as opposed to me needing to buy it and get reimbursed :puking_emoji:
I think there is great potential for modern ERP frameworks.
I worked at a global multi-national telecom that used an ancient version of the software. You suffered with it. I'm convinced -- because we were always cash strapped (having been through bankruptcy and back) that part of the motivation for keeping it was that it made doing expense reports so difficult that many abandoned them.
SAP looked cool at the time[0]. The web UI had an appearance of a web app and attempted to behave like one. It had many flaws, but they all went unnoticed because of one massive flaw -- it failed to handle the Back button in the browser ... and the UI often put you in a state that "instinct" made you want to click it. When you did click the back button, the web app would see two of you. As this was not an allowed state for a user, the new "you" couldn't access the system until the old "you" timed out ... an hour later. This meant a sufficiently complex expense report could take two days to complete since, on average, hitting the back button (by accident) twice per line wasn't unusual. So if it resulted in less than $40 coming back, it often wasn't worth the effort to do the expense report.
My entire experience with SAP was limited to integration with downstream (simple) internal applications and expense reports. Others spent all day within it. It was bad enough to warrant a special launch page that popped the thing up in a window that lacked the back button[1] but that was a pretty inadequate solution.
The worst part was hiring SAP developers. Having not looked at the product since the mid-00s (and being far from huge-company-land), I don't know if it's still the case, but I suspect so -- SAP was basically a custom setup everywhere it existed. It had the same graphics, similar UI, but requires substantial development to tie everything into it and tie it into everything else. I ended up participating in the interview when the company "got serious" and decided to put some money toward hiring a solid SAP developer/lead to get everything upgraded and solve some of the worst problems we had. We brought on a guy and paid him 25K more than the highest paid developer on staff[2]. He, like the previous four (under-paid) employees, lasted about three months before he left for substantially more money. We tried "paying some third party", too. The problem there was similar -- whomever was contracted to us was either incapable of doing the work or didn't last long enough to get past initial planning.
The end result was SAP existed in our organization at the same version it was when it was setup, initially, until we got rid of it ten years later when we merged with a competitor. The competitor ran Oracle for ERP and had a team of people to manage/develop/maintain it. Personally, I'm not an Oracle fan, but I wanted to buy Larry Ellison a beer.
[0] This was the mid 00s.
[1] This idea, I think, was tried -- IIRC, the more frequent case was accidentally running into the Backspace key on a non-text field and having the browser hot-key back which isn't solved by taking the buttons away.
[2] This was saying a lot considering we had software actively developed in C++ that managed a pretty massive audio-conferencing service (and set of related bridges/hardware). I met with several on that team -- they were geniuses. The "SAP Guy" had to know Java and SAP. I interviewed him. I wasn't impressed.
Even better is that it's written in some bullshit language that nobody else uses.
Though the drop is not SAP specific, but broad based (tech stocks carnage, ukraine war effects).
Then I worked places with SAP. And if they were lucky and just "did things the SAP way", the result was easy to understand, actually worked, and saved time.
Can you do that without SAP? Of course. Can a SAP system also suck? Of course. I have no argument to make here, other than it's sometimes good and sometimes not. If I had to compare it to anything it'd be IBM.