GUI-centric SAP systems design, part 1

[OttoGold]

For me the SAP Usability question is very important and would like to add my piece to the puzzle. In this blog series I would like to discuss my own practical approach. I will also remind the reader of the other blog posts which discuss the same topic to let everybody think about the SAP Usability and maybe help some people to decide which course to proceed.

Before I present my own approach I would like to remind the readers of the blog posts about the same topic which had some useful points to note or to argue with:

• User Interface decision tree: User Interface decision tree
• User Interface technologies: Problem of too many? User Interface technologies : Problem of too many?
• Enhance Your Business Process Productivity by Enhancing User Productivity. [Part 1 a 2] Enhance Your Business Process Productivity by Enhancing User Productivity. [Part 1] , Enhance Your Business Process Productivity by Enhancing User Productivity. [Part 2]

Even this short list of relevant blogs (I am sure there are more, but these attracted my attention, so I recommend them) show how many people are struggling with the user interfaces "problem" and the user productivity. Everybody has his own approach; I would like to present mine.

I read many SAP system development offers, I took part in some appointments of the SAP team and the clients (users, managers, sponsors), I spent hours discussing the SAP system usability with the numerous end-users , super-users and support people. What all the conversations had in common was the functional approach. The fundamental message of all the conversations was, the people believe, the implementation of one more SAP module can speed up their business processes, can reduce the number of errors (data quality, delays and subsequent loss), can help "the ordinary people" do their jobs better. I don´t believe it.

The HR experience

A part of my SAP experience which I consider to be very important (both for my career and this blog´s topic) is the HR part. I have been involved in some HR module implementations, changes, enhancements and development. Based on this experience I understand the importance of the GUI (graphical user interface) for the user. On HR project you face more people who don´t spend their working hours doing any ABAP or filling some super-mega-complex-screens.

These people have their own work to do; quite often they use email and the Office at most. They only need SAP to get a leave of absence approved. Or to check how many free days they have left. Some of these people are responsible for the data exchange with the other software the company is running, some of them are responsible for the data entry ("give me the paper, I will fill that into SAP for you"), some are responsible for the data output ("yes, boss, I will make that reports ready for you"), but the message I am trying to share here is that the different users have different needs. Of course, you know that already.

But have you ever tried to:

• distribute all the users into groups (where the users in a group have common needs)
• find and assign the suitable GUI technology to the user groups
• measure the user´s productivity and its dependence on choosing the user interface technology

My own try

I tried that - I distributed the users of few (existing) companies I had worked for into the suggested groups. I wrote my thesis around this topic and think some of the conclusion can be useful to provide one more point of view to the general design.

Let s discuss, what you can learn out of such distribution (or from an attempt to create one):

• There are users who use the suitable user interface, the typical examples are the super-users, support guys, internal consulting team members etc. who use SAP GUI which is the most complex SAP user interface (and the hardest to master for the "ordinary people").
• There are users who would work more efficiently if their user interface would be adjusted to their wishes (you can omit these), their needs (you can for example change their job description and change their needs a little) and their abilities (you cannot change these, you cannot change one´s age, ones attitude to IT, cure one´s fears about the computer, change one´s live experience and education, change one's ability to learn new things).
• There are the user interfaces which your company does not use although the price for implementing them would be less than a potential benefit.
• There is a lot of functionality implemented which is not used because the user interfaces are too complex to be used by a user (users come and go and so the knowledge disappears).
• Errors happen a lot because the people, who were not properly trained, are using the complex user interfaces or you pay big money for the user trainings because they have to use very complex GUIs; both could be solved by adjusting the overall complexity of the used user interface to the user's needs and abilities.
• In many tools/ transactions/ screens there are plenty of fields the user does not use or people find some values that work ok when filled in a field but means nothing/ error when used in reporting on the business process.
• The performance of the team is reduced when a member leaves the team/ company and is replaced by a fresher who is not experienced in use of the user interface. The functionality used by the team/ department is changing time to time, some functionality is abandoned when the responsible person leaves the company, and new functionality is configured for a user (or even RE-implemented (!!)).
• There is only one user interface to the system functionality which is used by the members of the different user groups. The same interface is used by the managers (don´t have time for that), the end-users (fill like two out of the hundred fields on the screen), the administrators (who love all the shortcuts through menus, buttons and stuff) etc.
• There is no strategy in the user interfaces deployment

I am sure about what you think at the moment. Of course this happens. A lot. It happens in my company as well. We know about it for ages, why is this guy talking about the obvious?

I talk about all that obvious stuff because I would like to ask (myself) some questions and through answering them I would like to present a part of the "theory" I have built, to understand how the user´s efficiency and the influence of choosing the suitable user interface can be measured.

I understand this post is long enough by now so I will cut it here, but to tell you what will come in the next parts let me present the questions:

• What is important to know about the users before distributing them into the groups
• How many groups will we distribute the users into? What criteria set we can use to distribute the people into the groups?
• How can we map this "group" theory to our company´s user groups?
• How can we find suitable interfaces for the user groups? Or better: How to find a set of metrics we can apply both on the users (groups) and the interfaces
• How can the theory help us understand what steps should we take to deal with the problem? How should we order the steps so we fix the problems with the best outcome first?
• How can we estimate the price and the outcome BEFORE we start any project dealing with the user interfaces?

I hope I have attracted a user or two who has read this far. Stay tuned. Regards, Otto