In part 1 of my Blog series I wrote about the circumstance that all of us are managers in some way. And a manager has to do everything at once and ASAP while this fact is very poorly reflected in current IT systems.

What are the two main reasons for this?

Up to now, technology and systems simply were not ready for this! Since the beginning of the computer age, capacity in storage and memory was scarce or at least expensive and hence basically never available in desired quantity. Remember Moore´s Law, IT price-performance rate is doubling every 18 months and this rule has proven constant over quite a number of years already. Price of sizing of course still matters, but it is no longer the critical factor or even the bottleneck that it used to be. Back in the old days however, the computing power was sometimes to be split between different systems and this limitation was also the reason for the separation between Online Transactional Processing (OLTP) and Online Analytical Processing (OLAP). At the center of OLAP are complex multidimensional and multi relational data analyses with high data volumes, supporting controlling and planning processes. Being not as time critical however as e.g. the business transaction in front of a customer, it was hence a logical step to separate it from daily business which was done in real-time like e.g. with ERP systems. So the aggregated data is collected separately in Data Warehouses with a delay due to batch upload. These are not in direct touch with operational systems and are also technically strictly separated by building up multidimensional info cubes rather than the transactional row based structures used in OLTP.

The second reason in my opinion is the approach of software design in general and ERP Systems in particular to cover as many different use cases as possible. This ends up in an enormous wealth of data and functions. In an attempt to bring structure to things, for developers and solution architects it was a quite logical step to do this also by different user roles. This split into managerial, transactional and analytical roles was also to some degree due for performance reasons taken to different systems as well, but the main focus was to use different roles in order to base the use cases on this. Of course this separation by roles is not a bad idea at all, sometimes even being a direct translation from the business world. However it leads to a problem, as developers were actually not thinking from the user in the first place. They came rather from the other end of the scope and end up to cluster that functionality in specific roles afterwards and not thinking from the requirements of the particular user in the first place. As a result, an average ERP user sees quite a lot of information and interaction points on his screen which he will probably never use, require or even understand. At the same time, so much space on the user interface is wasted for the not necessary information while others, important to the user, can only accessed by entering a different transaction with a different screen.

It was getting better with the invention of portals, combining the access to relevant transactions. But the basic idea that every transaction is reflecting a specific role is still alive. In the times of mobile apps, self-explaining and specific as it can get, this makes the classical look somewhat outdated. And they are also not flexible enough, especially given the requirement of doing everything in real-time on the spot and distinctions between roles are vanishing more and more these days.

So let us call it a day regarding the challenges for the user. But what can be done? Are you curious? So read more in part 3 of my Blog series.

Credits:

If you are interested more in the details of management theory, I could recommend at least some starting point for further readings: