6 ms·

This is a genuine question, I don't mean to rip on you: Why is everything SAP I've used terrible? From payroll, employee/student management to industrial contro

by meibo 4y ago

This is a genuine question, I don't mean to rip on you: Why is everything SAP I've used terrible? From payroll, employee/student management to industrial control systems - the UX is horrible and it seems so brittle that you're happy if you're out of there as quickly as possible. I've had to reach out to my school's IT multiple times over the years since random parts of the SAP tool they used break.

_glass 4y ago
I think it's mostly the culture surrounding SAP. SAP developers are a lot of times slow to adapt to new technology. For the UI you can use react components https://sap.github.io/ui5-webcomponents-react/?path=/story/getting-started--page https://sap.github.io/ui5-webcomponents-react/?path=/story/g... or you can just generate OData services from CDS Views that are then integrated into your frontend https://blogs.sap.com/2022/02/24/sap-cds-for-new-and-experienced-professionals/ https://blogs.sap.com/2022/02/24/sap-cds-for-new-and-experie.... The problem is that a lot of people use SAP as a front end, which is wrong in my experience.
- zeroth32 4y ago
  SAP can be quite innovative. 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.
  - cygx 4y ago
    AJAX and DHTML are not synonyms: The latter predates the former and refers to interactivity via client-side scripting.
  - taway19920706 4y ago
    Did the WebGUI really use AJAX in 2003? IIRC the early versions still used the old standalone (AGate/WGate) ITS, not even the integrated version.
  - pdpi 4y ago
    "SAP developers" can mean two different groups of people. The developers who build SAP, and the developers who build the custom stuff that clients need. The former can be quite innovative, but the situation with the latter is pretty damn grim (and I say this having worked in the industry, and my dad still works on it)
wheels 4y ago
Answer from former SAP employee (may have changed in the last 15 years): 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.
- lqet 4y ago
  > It's actually terminal software, that's translated into a GUI from a text interface on the fly I am intrigued - you mean terminal output is actually parsed, and a GUI view is then generated from it? E: this would certainly explain the issue of listboxes only having the currently shown items loaded (described by another commenter) - everytime you scroll, the terminal output has to be produced + parsed again
  - wheels 4y ago
    Historically, yes. It was basically like translating an ncurses (semi-GUI command line thing) into a UI. There were attempts to move away from that model, but at least when I worked for SAP, most actual deployments were still text-to-UI. It was basically a way of slapping some varnish on what was fundamentally an old-school mainframe system.
    - 656565656565 4y ago
      at least DIAG is relatively small on the network, probably as a result
    - taway19920706 4y ago
      It's the same today - S/4HANA is still accessible from the GUI and DIAG is still used. Web applications (which SAP is pushing customers towards) are freed from this, of course (they talk native http to the SAP application server). Remember that back in the late 90s SAP had a native GUI that ran on Windows, OS/2 and Unix (Motif-based) and each had their own native controls (a native Windows listbox is implemented differently from a Motif one, for example). Developers would develop a UI in ABAP with platform-independent controls and that UI would be sent over the wire to the client as DIAG and the client would translate that into the native control and data, etc for the end user.
dandare 4y ago
The UX is horrible because: 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.
- BlargMcLarg 4y ago
  I hate how bad UX has become the standard due to management/executive negligence, and there is so little the actual users can do about it. Even small players tend to neglect UX because of the financial incentives.
  - ehnto 4y ago
    I find smaller companies can have a more direct connection to their users, so the outcome is usually better UX. The disconnect from the user in enterprise software regularly results in poor UX, and the incentives to improve it just don't make their way to the people who need to hear them.
  - hef19898 4y ago
    I hate it how UX is so much more important than actual funtionality. I blame Instagram, Apple and consumer apps in general for that.
    - BlargMcLarg 4y ago
      I don't see why you'd split the two. Actual good functionality is UX. Lack of good functionality implies the user has a bad experience given the intended goal. Big players tend to do the minimum, either attracting with shiny red herrings or barely doing anything at all. Both are bad UX.
734129837261 4y ago
They wrote you can be agile if you move to the cloud. Did you try that? I jest. But that's kind of the point. SAP is terrible by the nature of the beast. It's a closed off system with specialised developers who require all sorts of expensive certifications. That doesn't make for good developers, that makes for pigeon-holed developers who don't have a lot of competition. A terrible SAP developer with all the certifications to their name would probably still find plenty of work, because the expectations are low to begin with, as proven by SAP being held in low regard across the industry. To me, needing expensive certifications to prove your worth (as if...) is a big red flag. I'm a developer who has 20+ years of experience, I recently worked for Apple and other Fortune top 50 companies, I went from startups to enormous companies. Nowhere did I need certifications. And my past experience was never enough to land a job. I'd have to prove myself in every job application. That's tiresome and feels extremely unnecessary, but it requires me (and my peers) to stay sharp. Of course, none of the above is very black and white. There are certified developers who are amazing, and there are open-source developers who keep themselves relevant who actually suck at what they do. But I'd argue that the SAP group of developers have far more developers who aren't very good and grow complacent, oftentimes because of their certifications. That, combined with a closed-off system, bad documentation, a lack of online support, and a much smaller community, will MORE often lead to software that is of lower quality.
- fileeditview 4y ago
  I think you don't see the full picture here. The developers working for SAP usually don't need any certifications. They are regular computer scientists/physicists/mathematicians etc. who write code / design systems. There are of course the certified consultants that work for clients of SAP. I can however understand why they need certifications. It's probably impossible to configure these systems without some kind of special education in them. And as for the quality of SAP devs.. I work for SAP and I have met many very qualified developers at the company. Far more than I anticipated before joining the company. Quite a few have been poached by Google et al but that is another topic.
  - mardifoufs 4y ago
roydivision 4y ago
The UI isn’t just terrible, it’s hostile to the user. The rare times I am forced to interact with it I feel like I’m using software that was meant for some other purpose. I’ve worked in the industry for 25 years, I’ve never come across worse UI.
- robertlagrant 4y ago
  My favourite bit of the SAP UI is whenever you scroll a listbox, it goes back to the server to load the rest of the list. It only has data for the exact 5 items it's showing; the other 1 above or 3 below each need a server hit. And it forgets the data it loaded before.
- hef19898 4y ago
  It isn't use for you as a user, it is meant to run your company. You are not the user, you are the one feeding data into the system. And that is actually perfectly fine in case of ERP systems.
  - tiborsaas 4y ago
    That's nonsense, people interacting with software are by definition users. If they pay for it we call them customers.
texasbigdata 4y ago
tldr: hard stuff is hard and not fun to work on 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-consumer-business-just-turned-off-its-final-oracle-database/ https://aws.amazon.com/blogs/aws/migration-complete-amazons-... 2. https://careers.google.com/jobs/results/142858723165905606-revenue-operations-controller/?category=FINANCE&page=2 https://careers.google.com/jobs/results/142858723165905606-r... 3. https://careers.google.com/jobs/results/118792275728704198-sap-business-systems-analyst-devices-and-services/?category=FINANCE https://careers.google.com/jobs/results/118792275728704198-s... 4. https://news.ycombinator.com/item?id=26706991 https://news.ycombinator.com/item?id=26706991 5.(imprecise but good starting point) https://developer.intuit.com/app/developer/qbo/docs/api/accounting/most-commonly-used/account https://developer.intuit.com/app/developer/qbo/docs/api/acco... 6. https://fivetran.com/docs/applications/quickbooks https://fivetran.com/docs/applications/quickbooks 7. https://docs.google.com/presentation/u/0/d/1u0dnyq5L_rcEgR2__F8OxI4jv-6yla8a1Bk4LjsB6gg/mobilepresent https://docs.google.com/presentation/u/0/d/1u0dnyq5L_rcEgR2_... 8. https://fivetran.com/docs/transformations/dbt/data-models/quickbooks-data-model/quickbooks-source-model https://fivetran.com/docs/transformations/dbt/data-models/qu...
singingfish 4y ago
I think ERPs are a basket case category generally. I've worked with SAP for a few years (or more accurately work hard to keep it out of scope for what I do) in my day job. I've also worked for a company providing ERP stuff for SMEs (mostly S). Anyway SAP/ERPs aren't code for running your business. They're code for running code to run your business. Now you have all the shortcuts SAP made to get stuff out the door, and on top of that you've got all the layers of shortcuts your business has made to get things out the door too. Therefore lots of nasty difficult complexity. And finally I've seen evidence that in SAP people treat it like the fundamental abstraction layer is the spreadsheet[1]. So like in unix everything is a file, in SAP everything is a spreadsheet. This is a nasty complicated fundamental abstraction without the natural elegance of Unix's one. [1] Maybe it really is, maybe it isn't but that's how a large chunk of the ABAP code I've seen treats it.
Aeolun 4y ago
I kinda feel like SAP is the ultimate in checkbox checking. If you ask every department what they need, and write it all down, then find the product that matches all the checkboxes, SAP is it.
- hef19898 4y ago
  SAP checks most of the boxes of almost all industries you need to run a modern business. Some specifc domains better than others, sure, but none are actually bad or unusable. And all tjose functions are integrated with each other. That alone is tremendous value.
  - Aeolun 4y ago
    > Some specifc domains better than others, sure, but none are actually bad or unusable. 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.
    - hef19898 4y ago
      Some weaknesses I see with SAP compared to dedicated solutions are in logistics and warehouse management, process industries (e.g. continious chemicals production, SAP is way better for discrete products and still it works just fine for the pricess industry), aerospace MRO (SAPs aerospace and defence package is more geared towards production) and eCommerce (eCommerce as a business is not that complex). Basically, if you are a manufacturing company SAP is easily among the best solutions out there. Added benefit of using an ERP that litterally everone else is usong as well: you have a way larger pool of people to recruit from that know the system. The less market pebetration an ERP has, the harder it is to get people who prwviously worked with it. That means higher training efforts, more need for external cobsultants and performance issues until your emoloyees adapted to whatever ERP you have.
Mvandenbergh 4y ago
I think part of it is the problem space to be honest. SAP basically gets used to glue all the fiddly bits of organisations together and I don't know that there is an approach to that set of problems that doesn't get tangled up in corner cases. With a lot of the nice looking web based apps we're used to looking at, the UX and the target domain evolve together and if there isn't an elegant way of doing a particular operation then there's going to be pressure to drop that operation entirely. SAP deployments always have to do everything in the organisation so complicated corner cases either get dropped (bad) or end up with suboptimal interfaces (also not great!).
cgeier 4y ago
I would disagree that the UX is horrible. 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.
- mrmaloke 4y ago
  I would disagree with your disagreement and instead argue that the UX is indeed horrible. 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.

by meibo 4y ago

_glass 4y ago

I think it's mostly the culture surrounding SAP. SAP developers are a lot of times slow to adapt to new technology. For the UI you can use react components https://sap.github.io/ui5-webcomponents-react/?path=/story/getting-started--page https://sap.github.io/ui5-webcomponents-react/?path=/story/g... or you can just generate OData services from CDS Views that are then integrated into your frontend https://blogs.sap.com/2022/02/24/sap-cds-for-new-and-experienced-professionals/ https://blogs.sap.com/2022/02/24/sap-cds-for-new-and-experie.... The problem is that a lot of people use SAP as a front end, which is wrong in my experience.

zeroth32 4y ago
SAP can be quite innovative. 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.
- cygx 4y ago
  AJAX and DHTML are not synonyms: The latter predates the former and refers to interactivity via client-side scripting.
- taway19920706 4y ago
  Did the WebGUI really use AJAX in 2003? IIRC the early versions still used the old standalone (AGate/WGate) ITS, not even the integrated version.
- pdpi 4y ago
  "SAP developers" can mean two different groups of people. The developers who build SAP, and the developers who build the custom stuff that clients need. The former can be quite innovative, but the situation with the latter is pretty damn grim (and I say this having worked in the industry, and my dad still works on it)

wheels 4y ago

Answer from former SAP employee (may have changed in the last 15 years): 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.

lqet 4y ago
> It's actually terminal software, that's translated into a GUI from a text interface on the fly I am intrigued - you mean terminal output is actually parsed, and a GUI view is then generated from it? E: this would certainly explain the issue of listboxes only having the currently shown items loaded (described by another commenter) - everytime you scroll, the terminal output has to be produced + parsed again
- wheels 4y ago
  Historically, yes. It was basically like translating an ncurses (semi-GUI command line thing) into a UI. There were attempts to move away from that model, but at least when I worked for SAP, most actual deployments were still text-to-UI. It was basically a way of slapping some varnish on what was fundamentally an old-school mainframe system.
  - 656565656565 4y ago
    at least DIAG is relatively small on the network, probably as a result
  - taway19920706 4y ago
    It's the same today - S/4HANA is still accessible from the GUI and DIAG is still used. Web applications (which SAP is pushing customers towards) are freed from this, of course (they talk native http to the SAP application server). Remember that back in the late 90s SAP had a native GUI that ran on Windows, OS/2 and Unix (Motif-based) and each had their own native controls (a native Windows listbox is implemented differently from a Motif one, for example). Developers would develop a UI in ABAP with platform-independent controls and that UI would be sent over the wire to the client as DIAG and the client would translate that into the native control and data, etc for the end user.

dandare 4y ago

The UX is horrible because: 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.

BlargMcLarg 4y ago
I hate how bad UX has become the standard due to management/executive negligence, and there is so little the actual users can do about it. Even small players tend to neglect UX because of the financial incentives.
- ehnto 4y ago
  I find smaller companies can have a more direct connection to their users, so the outcome is usually better UX. The disconnect from the user in enterprise software regularly results in poor UX, and the incentives to improve it just don't make their way to the people who need to hear them.
- hef19898 4y ago
  I hate it how UX is so much more important than actual funtionality. I blame Instagram, Apple and consumer apps in general for that.
  - BlargMcLarg 4y ago
    I don't see why you'd split the two. Actual good functionality is UX. Lack of good functionality implies the user has a bad experience given the intended goal. Big players tend to do the minimum, either attracting with shiny red herrings or barely doing anything at all. Both are bad UX.

734129837261 4y ago

They wrote you can be agile if you move to the cloud. Did you try that? I jest. But that's kind of the point. SAP is terrible by the nature of the beast. It's a closed off system with specialised developers who require all sorts of expensive certifications. That doesn't make for good developers, that makes for pigeon-holed developers who don't have a lot of competition. A terrible SAP developer with all the certifications to their name would probably still find plenty of work, because the expectations are low to begin with, as proven by SAP being held in low regard across the industry. To me, needing expensive certifications to prove your worth (as if...) is a big red flag. I'm a developer who has 20+ years of experience, I recently worked for Apple and other Fortune top 50 companies, I went from startups to enormous companies. Nowhere did I need certifications. And my past experience was never enough to land a job. I'd have to prove myself in every job application. That's tiresome and feels extremely unnecessary, but it requires me (and my peers) to stay sharp. Of course, none of the above is very black and white. There are certified developers who are amazing, and there are open-source developers who keep themselves relevant who actually suck at what they do. But I'd argue that the SAP group of developers have far more developers who aren't very good and grow complacent, oftentimes because of their certifications. That, combined with a closed-off system, bad documentation, a lack of online support, and a much smaller community, will MORE often lead to software that is of lower quality.

fileeditview 4y ago
I think you don't see the full picture here. The developers working for SAP usually don't need any certifications. They are regular computer scientists/physicists/mathematicians etc. who write code / design systems. There are of course the certified consultants that work for clients of SAP. I can however understand why they need certifications. It's probably impossible to configure these systems without some kind of special education in them. And as for the quality of SAP devs.. I work for SAP and I have met many very qualified developers at the company. Far more than I anticipated before joining the company. Quite a few have been poached by Google et al but that is another topic.
- mardifoufs 4y ago

roydivision 4y ago

The UI isn’t just terrible, it’s hostile to the user. The rare times I am forced to interact with it I feel like I’m using software that was meant for some other purpose. I’ve worked in the industry for 25 years, I’ve never come across worse UI.

robertlagrant 4y ago
My favourite bit of the SAP UI is whenever you scroll a listbox, it goes back to the server to load the rest of the list. It only has data for the exact 5 items it's showing; the other 1 above or 3 below each need a server hit. And it forgets the data it loaded before.
hef19898 4y ago
It isn't use for you as a user, it is meant to run your company. You are not the user, you are the one feeding data into the system. And that is actually perfectly fine in case of ERP systems.
- tiborsaas 4y ago
  That's nonsense, people interacting with software are by definition users. If they pay for it we call them customers.

texasbigdata 4y ago

tldr: hard stuff is hard and not fun to work on 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-consumer-business-just-turned-off-its-final-oracle-database/ https://aws.amazon.com/blogs/aws/migration-complete-amazons-... 2. https://careers.google.com/jobs/results/142858723165905606-revenue-operations-controller/?category=FINANCE&page=2 https://careers.google.com/jobs/results/142858723165905606-r... 3. https://careers.google.com/jobs/results/118792275728704198-sap-business-systems-analyst-devices-and-services/?category=FINANCE https://careers.google.com/jobs/results/118792275728704198-s... 4. https://news.ycombinator.com/item?id=26706991 https://news.ycombinator.com/item?id=26706991 5.(imprecise but good starting point) https://developer.intuit.com/app/developer/qbo/docs/api/accounting/most-commonly-used/account https://developer.intuit.com/app/developer/qbo/docs/api/acco... 6. https://fivetran.com/docs/applications/quickbooks https://fivetran.com/docs/applications/quickbooks 7. https://docs.google.com/presentation/u/0/d/1u0dnyq5L_rcEgR2__F8OxI4jv-6yla8a1Bk4LjsB6gg/mobilepresent https://docs.google.com/presentation/u/0/d/1u0dnyq5L_rcEgR2_... 8. https://fivetran.com/docs/transformations/dbt/data-models/quickbooks-data-model/quickbooks-source-model https://fivetran.com/docs/transformations/dbt/data-models/qu...

singingfish 4y ago

I think ERPs are a basket case category generally. I've worked with SAP for a few years (or more accurately work hard to keep it out of scope for what I do) in my day job. I've also worked for a company providing ERP stuff for SMEs (mostly S). Anyway SAP/ERPs aren't code for running your business. They're code for running code to run your business. Now you have all the shortcuts SAP made to get stuff out the door, and on top of that you've got all the layers of shortcuts your business has made to get things out the door too. Therefore lots of nasty difficult complexity. And finally I've seen evidence that in SAP people treat it like the fundamental abstraction layer is the spreadsheet[1]. So like in unix everything is a file, in SAP everything is a spreadsheet. This is a nasty complicated fundamental abstraction without the natural elegance of Unix's one. [1] Maybe it really is, maybe it isn't but that's how a large chunk of the ABAP code I've seen treats it.

Aeolun 4y ago

I kinda feel like SAP is the ultimate in checkbox checking. If you ask every department what they need, and write it all down, then find the product that matches all the checkboxes, SAP is it.

hef19898 4y ago
SAP checks most of the boxes of almost all industries you need to run a modern business. Some specifc domains better than others, sure, but none are actually bad or unusable. And all tjose functions are integrated with each other. That alone is tremendous value.
- Aeolun 4y ago
  > Some specifc domains better than others, sure, but none are actually bad or unusable. 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.
  - hef19898 4y ago
    Some weaknesses I see with SAP compared to dedicated solutions are in logistics and warehouse management, process industries (e.g. continious chemicals production, SAP is way better for discrete products and still it works just fine for the pricess industry), aerospace MRO (SAPs aerospace and defence package is more geared towards production) and eCommerce (eCommerce as a business is not that complex). Basically, if you are a manufacturing company SAP is easily among the best solutions out there. Added benefit of using an ERP that litterally everone else is usong as well: you have a way larger pool of people to recruit from that know the system. The less market pebetration an ERP has, the harder it is to get people who prwviously worked with it. That means higher training efforts, more need for external cobsultants and performance issues until your emoloyees adapted to whatever ERP you have.

Mvandenbergh 4y ago

I think part of it is the problem space to be honest. SAP basically gets used to glue all the fiddly bits of organisations together and I don't know that there is an approach to that set of problems that doesn't get tangled up in corner cases. With a lot of the nice looking web based apps we're used to looking at, the UX and the target domain evolve together and if there isn't an elegant way of doing a particular operation then there's going to be pressure to drop that operation entirely. SAP deployments always have to do everything in the organisation so complicated corner cases either get dropped (bad) or end up with suboptimal interfaces (also not great!).

cgeier 4y ago

I would disagree that the UX is horrible. 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.

mrmaloke 4y ago
I would disagree with your disagreement and instead argue that the UX is indeed horrible. 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.