Two main reasons:
- It's actually terminal software, that's translated into a GUI from a text interface on the fly.
- The people that buy SAP never have to use SAP. Its interface is not a selling point.
I am intrigued - you mean terminal output is actually parsed, and a GUI view is then generated from it?
E: this would certainly explain the issue of listboxes only having the currently shown items loaded (described by another commenter) - everytime you scroll, the terminal output has to be produced + parsed again
Remember that back in the late 90s SAP had a native GUI that ran on Windows, OS/2 and Unix (Motif-based) and each had their own native controls (a native Windows listbox is implemented differently from a Motif one, for example). Developers would develop a UI in ABAP with platform-independent controls and that UI would be sent over the wire to the client as DIAG and the client would translate that into the native control and data, etc for the end user.
I challenged this design decision when Fiori was introduced and the thing is that statistically the lists are either small or huge. When they're huge, they got touched in less than 10% cases, so by not loading the whole content you save a lot.
It's absolutely not something you just randomly explore. I think that's a more interesting question: what sort of empowerment of employees could you create if the UI wasn't so terrible?
But SAP's moat is elsewhere. You put up with its terribleness because nothing else can do what it does. Beating SAP would require you to reach that, and do something else, part of which could be a nicer UI.
Every detail of the business process is now explicit. Employees have to be forced to work according to actual process. You need quite a bunch training for that. Then employees will find shortcuts to make their own job a bit faster/easier, which will fuck up some cases. You need even more training for that and possibly some redesigns. And all you get from that is depression
