GUI-centric SAP systems design, part 5
In the previous four parts I started describing my thoughts about how to learn if the user´s performance is not negatively affected because he is forced to use an unsuitable user interface. GUI-centric SAP systems design, part 1 was discussing frequent problems with user interfaces – I described my motivation there. GUI-centric SAP systems design, part 2 was about a simple example how certain “groups of users” use certain “interfaces” and was vaguely naming the reasons why bother. GUI-centric SAP systems design, part 3 was discussing the idea that there is a customer for every article, or: certain interfaces offer what certain users need/ want/ can use, briefly said: we can create an abstract “model” of a SAP system, where we look for pairs: users + interfaces (suitable for each other). GUI-centric SAP systems design, part 4 was about a search for a demonstrational criteria set how could we measure the “quality of the pairs”, measure the suitability of the use of an interface for a user.
Today´s blog is about how to glue everything I said before together…
Let me use a word “methodology” and outline how it is supposed to work:
- First of all, you need to learn what are the available user interfaces and what user groups you could/ would recognize in your company (like in the GUI-centric SAP systems design, part 2)
- Next you need to decide what criteria set you will use to measure the “suitability” of the interface for the users (GUI-centric SAP systems design, part 3)
- Next you can compute some numbers (GUI-centric SAP systems design, part 4). An example follows, but let me continue with the “methodology”, because I didn´t covered the whole purpose yet.
- What comes next?
The model and the magic numbers
You put some numbers into the “model” and got some magic numbers. But what do the numbers say? Well, they say whether you offer the suitable interfaces to the right users. But that means (I said “whether”) that sometimes the selected/ available/ offered interfaces do not fit into the users´ taste/ needs. You can use this “model” to understand things like (you can come back here after finishing reading the blog, because the pictures at the end can help you understand… hopefully):
- Which interfaces are deployed but not fit into users taste (so you could spare some money stopping the use of/ development of certain interfaces)
- Which users are not happy about their interface (you can ask them why they´re not happy or you can learn the group of the users is not homogenous – if you would split a group into two groups and offer different interfaces for both groups replacing the old one – the numbers could rise. By the way: remember this point, I will elaborate on this later).
- If there are any weak points in the certain interface – user relationship, where are they? (since we use a set of criteria and evaluate one criteria after one, we know exactly which number damages the “suitability” – or it would be more appropriate to use the word “usability”, which is the key point of my interest)
- If there is an indication your SAP systems lacks a user interface, how would this missing interface “look like” (again: you have the numbers, so you can learn if the interface would be more useful for an occasional user or a pro and this way continue inspecting rest of the criteria set).
- You are considering to deploy a new interface (or you´re offered by your favorite consulting company or – like in my case – you ARE the consulting company who creates the offer) and would like to know if there are any “customers” (I mean internal customers, the users of the SAP system) for what you offer.
- If a group of people who use a certain GUI is homogenous – if those people have common needs or the GUI works well for just a few of them and the rest “suffers”.
I can imagine this is becoming little fuzzy, kind of complicated and a too much abstract (I am sure you cannot apply my thoughts on your company or your customer´s company easily). I am also aware of the fact an image is worth thousand words. So let me finish this part with a picture which will illustrate first three bullets from the first list above. The fourth item – “what comes next” – will follow in the next blog.
Example 1: how to count the “usability of the interface for the user (group)”
Description: Let´s say we have a set of six criteria (C1-C6). Each criterion is evaluated both for the user (upper line) and the interface (lower line). Let´s say we had defined some scales for the criteria before.
Now we measure the proximity of the evaluation for the user and for the interface. For example: the interface is very simple, easy to use but that means user can do very little using this interface. But we are trying to learn if this interface is suitable for a trained analyst, everyday user. It is obvious the values are on the different sides of the scale. So instead of using some magic words or numbers I used colors to visualize that the values does not match. And does not match means “false”, that´s why you can see zero “points” below in the C1 “column”. In the column C2 the values both for the user and the interface are “neutral” what matches together, so the resulting value is “true”, so +1 point.
Now let´s put it all together: 6 criteria and 1 point for every match means that 100% suitability or usability of the interface for the user means 6 points out of 6 criteria. In the example above you can count 3 points. “3 out of 6” means 50%. Now we can tell how much we could improve the usability if we would take some actions 50% – even if I cannot tell you how much money, time or errors this number means, you can imagine it means something. You can also learn which attributes of the interface or the user damage the quality of the relationship.
For example: your users get a training to get their ERP skills refreshed every six months, what means they´re “rarely trained”. You have estimated that the interface they´re using to process their tasks needs more like”training on an average level”. If you would spend some little more money on the internal training for these users, it could help their productivity.
I am sure you now wonder “why is this guy talking about such basic things like it would be something extra difficult”. Well, it is a) I don´t pretend it something “brand new” b) I used an example, where it is obvious what to do and how to do it. But try to use this approach on the other criteria.
I must admit here, this is all very fuzzy. I am sure not everybody can believe the fuzzy “methodology” or the fuzzy “results”.
Example 2: how to model the SAP system using the interfaces + users + usability approach
Description: we have four interfaces I1-I4 (interface technologies, GUIs, integrations with 3rd party faces etc.) and we have 4 groups of users, where users of the group how kind of homogenous and common needs and abilities. Let´s say I1-I3 are common SAP user interfaces:
- SAP GUI,
- SAP NW Portal
- Adobe forms (my favorite example).
Let´s say the groups U2-U4 are “common” SAP user groups to be seen in most of the companies:
- professional/ trained users performing daily tasks with high complexity,
- managers who use ERP access time to time
- “ordinary people” who only use ERP access to have their absence leave approved.
You can naturally map the interfaces and the groups I mentioned. But there is an interface that does not have any users (I4) and there are users without an interface (U1). You can now use this “model” or the “methodology” to learn if some of the users would “like” the interface not yet used before you will try by “trial/ error” approach (which will cost you a lot of money).
Hope I have not puzzled you too much and hope to see you reading the next part,
Best regards, Otto