GUI-centric SAP systems design, part 4

[OttoGold]

In the first three parts of the series (one, two, GUI-centric SAP systems design, part 3) I was discussing what problems one can discover, when modeling the SAP system and its user interfaces. I think it was enough to express the need for such modeling. The most important question to get the whole picture about how to build a model is about what do the interfaces and the user groups in common. Or better: how can we measure quality of the relationship between the user interfaces and the users. Or the best: how exactly we can tell if the interface abilities match the user group members´ needs?

Let´s work with the example:  how can one tell if the SAP GUI (like PPOME transaction or something - replace by your own favorite transaction, which is not totally trivial) is suitable for your CEO? Of course it is not suitable for him at all, but why? Get a pen and try to write down few ideas why do you think he (or she) would not like it. Is that because he would not like the colors? Probably not. Is that because he would not like the navigation and complexity of the interface? Probably yes. He would not like to operate in SAP GUI without a proper training for which he does not have time. And so on. You can come up with your own set of reasons.

I have used the following set of criteria (I am afraid some of them can be confusing/ not self-explanatory, but I don´t want to double the length of this blog describing all of them in a detail). You can change the criteria, add some, remove some, as you like, the "model" is flexible.

Computer skills:

• IT background (educated or not in IT),
• Level/ frequency of training,
• Ability to work with the help documents

Costs:

• Licensing/ price of the user´s license (too expensive, then not suitable for the group with many members),
• Cost of change of the interface (you can expect the standard must be changed sometimes),
• Cost of creating a brand new interface of the same type (sometimes new feature must be implemented or a cost of change leads to a complete re-implementation)

Daily routine:

• Automate the data entry (occasional user submits one screen/ form/document a month, an expert user like dozens every day),
• Advisable frequency of use (regular use refreshes the skills needed to operate a nontrivial interface, you don´t hesitate where to click in some SAP GUI "complex" tools?),
• Volume of the data entry (to insert a bigger amount of data through some of the interfaces is a nightmare, but some users don´t need to do that),
• Expected number of the controls (sometimes you can see/use like two buttons, sometimes you could count like hundreds of buttons/fields all over the screen)
• Number of different tasks processed with a single tool/ screen (in some "transactions" you can do A, B, of course C, D without a doubt etc. But for the occasional laic user it is anightmare to understand, which 2 buttons out of dozens one should use to complete his/her specific task)
• Error "immunity" (how easy and common is to use/ implement rules not to let the user input any error into the system)

Of course the evaluation of the criteria set both for the users and the interfaces will not be exact and objective but it should help you get a rough idea about where the bottlenecks of the user productivity may be hidden and if the realignment of the user interfaces is needed or not.

From the example the idea/ the message should be understandable (I hope). The interface offers something or requires something and so does the user. If the user need matches the interface offer and the user can make it with the interface demands, then a suitable pair is found.

I will elaborate on the pairs in the next part, Otto