> 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.

and experienced users can move very quickly through screens like a terminal but Fiori UI5 is the root of all evil

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.

at least DIAG is relatively small on the network, probably as a result

> 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 wish we were actually allowed to use the text interface but all we get is some halfway reasonable, halfway terrible web ui.

The article says you should reserve 17% of your project budget in training. Couldn't good UX help with that?

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.