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.
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.
> The buyer is not the user. The buyer (playing golf with a sales rep) doesn't give a damn about the actual productivity of what he is buying
I see this trotted out a lot but are all large companies really that oblivious? Do none of the decision makers talk with the people that work for them? Surely those executives aren't so divorced from reality and common sense that they don't see a problem when people complain that things don't work or if they do, it takes an order of magnitude more time and effort?
Surely there must be some other explanation for the proliferation of these systems other than "execs dumb and bad"?
It’s not “execs dumb and bad,” it’s that execs have different priorities than you think they do, which I think is partially dandare’s point.
Executives at a large company are divorced from your reality at your level of the job.
Incidentally, that’s part of the fun of working at smaller companies, though the variance is higher there’s also the potential to work more closely with good earnest executives who also want the company to succeed.
that's a problem and we're going to have to fix it
>it takes an order of magnitude more time and effort
that's not a problem
the fact that Jane the accounting drone has to do twice the amount of work, or has to hire an intern to help her out, or even wants to quit because the job is so awful now is not a problem
it's a rounding error in the overall cost of implementing an ERP system
a new screen with some new data to show for the exec is worth 20 Jane's and her opinions on the new system
you can't even call the new system unethical or fraudulent because 10 people other then Jane can now stop using broken excel sheets to organize their work
This sounds about right to me. In particular, it tends to partiton the organization into (A) the people whose job it is to plug away at the ERP system (orders, invoices, tickets, etc), and (B) the people who actually do whatever it is that the company does.
(C) - License costs can also play into this partitioning.
Then you hope (and work to ensure) that the benefit achieved for B, by having consistent org-wide information systems to work from, is enough to cover the overheads of A and C.
The simplest explanation is a mis-alignment in incentives.
Executives want to have successful projects to show to their value to an organization. But usually the board members are unable to comprehend the details of a project. So the herd mentality kicks in. The CTO will seek approval for SAP and provide Gartner magic quadrant BS to give the board a level of comfort.
Now whether SAP is the right tool, or if it inconveniences users doesn't matter a whit to the CTO. All that matters is budget and timeline. The CTO wants to be able to speak to the board and say that the project timeline was met and under budget. All else is a complete non-factor.
I hate how bad UX has become the standard due to management/executive negligence, and there is so little the actual users can do about it. Even small players tend to neglect UX because of the financial incentives.
I find smaller companies can have a more direct connection to their users, so the outcome is usually better UX. The disconnect from the user in enterprise software regularly results in poor UX, and the incentives to improve it just don't make their way to the people who need to hear them.
I don't see why you'd split the two. Actual good functionality is UX. Lack of good functionality implies the user has a bad experience given the intended goal.
Big players tend to do the minimum, either attracting with shiny red herrings or barely doing anything at all. Both are bad UX.
From talking to actual end users though I am convinced there is no universally good UX. Someone will not understand it no matter how perfect you think it is.
Now I favor ugly but robust UX for business applications. The user doesn't have to love it, it's their job to use it. It just has to be efficient and comprehensive, not pretty
I am so thankful to be working in an organisation which is reshaping its delivery teams into product teams. Our users are customers and if they want a better UX, they get a better UX.
> It's actually terminal software, that's translated into a GUI from a text interface on the fly
I am intrigued - you mean terminal output is actually parsed, and a GUI view is then generated from it?
E: this would certainly explain the issue of listboxes only having the currently shown items loaded (described by another commenter) - everytime you scroll, the terminal output has to be produced + parsed again
Historically, yes. It was basically like translating an ncurses (semi-GUI command line thing) into a UI. There were attempts to move away from that model, but at least when I worked for SAP, most actual deployments were still text-to-UI. It was basically a way of slapping some varnish on what was fundamentally an old-school mainframe system.
It's the same today - S/4HANA is still accessible from the GUI and DIAG is still used. Web applications (which SAP is pushing customers towards) are freed from this, of course (they talk native http to the SAP application server).
Remember that back in the late 90s SAP had a native GUI that ran on Windows, OS/2 and Unix (Motif-based) and each had their own native controls (a native Windows listbox is implemented differently from a Motif one, for example). Developers would develop a UI in ABAP with platform-independent controls and that UI would be sent over the wire to the client as DIAG and the client would translate that into the native control and data, etc for the end user.
Agreed! SAP's GUI is generally terrible for occasional users (luckily most have now been moved to web-based applications, of varying levels of user friendliness), but in the hands of experienced back office staff it works well. Not pretty, but very functional and with shortcuts for everything.
> the issue of listboxes only having the currently shown items loaded
I challenged this design decision when Fiori was introduced and the thing is that statistically the lists are either small or huge. When they're huge, they got touched in less than 10% cases, so by not loading the whole content you save a lot.
I'm not actually sure, because I feel like most of the things people do with SAP are very repetitive. Their UIs are mind-bendingly bad, but you mostly learn to do the 3 things you have to do all of the time, and then do them over and over again. I'm not sure how much having a nicer UI would make that easier.
It's absolutely not something you just randomly explore. I think that's a more interesting question: what sort of empowerment of employees could you create if the UI wasn't so terrible?
But SAP's moat is elsewhere. You put up with its terribleness because nothing else can do what it does. Beating SAP would require you to reach that, and do something else, part of which could be a nicer UI.
Every business software is at least as complex as the business process it models. That's the thing you training for.
Every detail of the business process is now explicit. Employees have to be forced to work according to actual process. You need quite a bunch training for that. Then employees will find shortcuts to make their own job a bit faster/easier, which will fuck up some cases. You need even more training for that and possibly some redesigns. And all you get from that is depression
No, because the training is about the core functionalities of those ERP systems, what action triggers what and so on. Training is not about how the UI works, this knowledge is gained on the job.
They wrote you can be agile if you move to the cloud. Did you try that?
I jest. But that's kind of the point. SAP is terrible by the nature of the beast. It's a closed off system with specialised developers who require all sorts of expensive certifications. That doesn't make for good developers, that makes for pigeon-holed developers who don't have a lot of competition.
A terrible SAP developer with all the certifications to their name would probably still find plenty of work, because the expectations are low to begin with, as proven by SAP being held in low regard across the industry.
To me, needing expensive certifications to prove your worth (as if...) is a big red flag. I'm a developer who has 20+ years of experience, I recently worked for Apple and other Fortune top 50 companies, I went from startups to enormous companies.
Nowhere did I need certifications. And my past experience was never enough to land a job. I'd have to prove myself in every job application. That's tiresome and feels extremely unnecessary, but it requires me (and my peers) to stay sharp.
Of course, none of the above is very black and white. There are certified developers who are amazing, and there are open-source developers who keep themselves relevant who actually suck at what they do.
But I'd argue that the SAP group of developers have far more developers who aren't very good and grow complacent, oftentimes because of their certifications. That, combined with a closed-off system, bad documentation, a lack of online support, and a much smaller community, will MORE often lead to software that is of lower quality.
I think you don't see the full picture here. The developers working for SAP usually don't need any certifications. They are regular computer scientists/physicists/mathematicians etc. who write code / design systems.
There are of course the certified consultants that work for clients of SAP. I can however understand why they need certifications. It's probably impossible to configure these systems without some kind of special education in them.
And as for the quality of SAP devs.. I work for SAP and I have met many very qualified developers at the company. Far more than I anticipated before joining the company. Quite a few have been poached by Google et al but that is another topic.
I think they were talking about "front end" SAP devs that are hired to work on custom solutions by a client. Not the core devs that actually work for SAP on building the product itself.
I think ERPs are a basket case category generally. I've worked with SAP for a few years (or more accurately work hard to keep it out of scope for what I do) in my day job. I've also worked for a company providing ERP stuff for SMEs (mostly S).
Anyway SAP/ERPs aren't code for running your business. They're code for running code to run your business. Now you have all the shortcuts SAP made to get stuff out the door, and on top of that you've got all the layers of shortcuts your business has made to get things out the door too. Therefore lots of nasty difficult complexity.
And finally I've seen evidence that in SAP people treat it like the fundamental abstraction layer is the spreadsheet[1]. So like in unix everything is a file, in SAP everything is a spreadsheet. This is a nasty complicated fundamental abstraction without the natural elegance of Unix's one.
[1] Maybe it really is, maybe it isn't but that's how a large chunk of the ABAP code I've seen treats it.
I remember SAP circa 2003. The only think that used XMLHttpRequest (AJAX aka dynamic html) was Outlook web frontend, and SAP web UI. GMail that widely popularized dynamic html did not even existed yet.
"SAP developers" can mean two different groups of people. The developers who build SAP, and the developers who build the custom stuff that clients need. The former can be quite innovative, but the situation with the latter is pretty damn grim (and I say this having worked in the industry, and my dad still works on it)
The UI isn’t just terrible, it’s hostile to the user. The rare times I am forced to interact with it I feel like I’m using software that was meant for some other purpose. I’ve worked in the industry for 25 years, I’ve never come across worse UI.
My favourite bit of the SAP UI is whenever you scroll a listbox, it goes back to the server to load the rest of the list. It only has data for the exact 5 items it's showing; the other 1 above or 3 below each need a server hit. And it forgets the data it loaded before.
It isn't use for you as a user, it is meant to run your company. You are not the user, you are the one feeding data into the system. And that is actually perfectly fine in case of ERP systems.
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.
I kinda feel like SAP is the ultimate in checkbox checking. If you ask every department what they need, and write it all down, then find the product that matches all the checkboxes, SAP is it.
SAP checks most of the boxes of almost all industries you need to run a modern business. Some specifc domains better than others, sure, but none are actually bad or unusable. And all tjose functions are integrated with each other. That alone is tremendous value.
Some weaknesses I see with SAP compared to dedicated solutions are in logistics and warehouse management, process industries (e.g. continious chemicals production, SAP is way better for discrete products and still it works just fine for the pricess industry), aerospace MRO (SAPs aerospace and defence package is more geared towards production) and eCommerce (eCommerce as a business is not that complex).
Basically, if you are a manufacturing company SAP is easily among the best solutions out there. Added benefit of using an ERP that litterally everone else is usong as well: you have a way larger pool of people to recruit from that know the system. The less market pebetration an ERP has, the harder it is to get people who prwviously worked with it. That means higher training efforts, more need for external cobsultants and performance issues until your emoloyees adapted to whatever ERP you have.
I think part of it is the problem space to be honest. SAP basically gets used to glue all the fiddly bits of organisations together and I don't know that there is an approach to that set of problems that doesn't get tangled up in corner cases.
With a lot of the nice looking web based apps we're used to looking at, the UX and the target domain evolve together and if there isn't an elegant way of doing a particular operation then there's going to be pressure to drop that operation entirely. SAP deployments always have to do everything in the organisation so complicated corner cases either get dropped (bad) or end up with suboptimal interfaces (also not great!).
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.
