Bedienbare Software ist kein Zufall

Feature | 2. November 2004 von admin 0

Die Evolution der SAP-GUI

Die Evolution der SAP-GUI

Langjährige SAP-Anwender werden sich noch an die Zeiten von SAP R/2 erinnern: Eine schwarze Maske auf dem 3270-Terminal, die nur für Eingeweihte bedienbar war. Stand in den Pioniertagen der elektronischen Datenverarbeitung noch die Technologie mit ihren Algorithmen im alleinigen Blickpunkt des Interesses, sind in den vergangenen Jahren mehr und mehr die Anwender in den Vordergrund gerückt. Bei SAP wurde dieser Wandel bereits 1989 mit den Arbeiten an SAP R/3 eingeläutet und das Usability Engineering Center gegründet. Das Ziel der Abteilung ist es, die SAP-Software möglichst leicht bedienbar zu machen.
“Zu Beginn unserer Arbeit ging es vor allem darum, Style-Guides für die Entwickler zu schreiben”, erinnert sich Ulrich Kreichgauer, Leiter des Usability Engineering Centers. Dabei waren zunächst grundlegende Fragen zu klären. In der Welt von SAP R/2 gab es zum Beispiel für die Funktion “Schreibe die Eingabe in die Datenbank” noch zahlreiche verschiedene Bezeichnungen. Je nach Anwendung nannten die Entwickler diesen Vorgang “Speichern”, “Sichern”, “Save” oder “Abspeichern”. Es gehörte zu den ersten Aufgaben der Usability-Experten, hier eine gemeinsame und für alle SAP-Anwendungen verbindliche Sprache festzulegen. Ebenso befasste sich das Usability Engineering Center damit, an welchen Stellen der Eingabemasken Menüs und Felder platziert werden mussten.

Keine Frage der Schönheit

Dabei geht es nicht um Aspekte wie Farbgebung oder Form der Buttons. “Schönheit spielt aus Usability-Sicht die geringste Rolle”, erläutert Kreichgauer. “Benutzbarkeit heißt, das anzubieten, was eine bestimmte Arbeit möglichst gut unterstützt.” Seiner Meinung nach sollte ein Produkt im Idealfall aus sich selbst heraus alles über seine Bedienung aussagen und Fehler unmöglich machen. Deutlich wird das am Beispiel eines Türbeschlags: Muss eine Tür durch Drücken geöffnet werden, bietet sich eine schlichte Platte als optimale Lösung an. Damit ist eine Fehlbedienung so gut wie ausgeschlossen, denn durch Ziehen lässt sich die Tür nicht öffnen.

Ulrich Kreichgauer

Ulrich Kreichgauer

Inzwischen hat sich das Usability Engineering Center als zentrale Stelle für Fragen der Bedienbarkeit etabliert. Dabei arbeiten die Experten nur in Ausnahmefällen an konkreten Software-Projekten, wie Kreichgauer erläutert: “Wir definieren die Verfahren, Prozesse und Methoden, mit denen die Bedienbarkeit in den Produkten sichergestellt werden kann. Für die Umsetzung in den Projekten sind die Application-User-Interface-Designer aus den Entwicklungsabteilungen zuständig, die von uns trainiert werden.”
So hat das Usability Engineering Center zum Beispiel einen Prozess für die Software-Entwicklung ausgearbeitet, der gewährleistet, dass die Benutzerfreundlichkeit gleich zu Beginn berücksichtig wird. Unter dem Schlagwort “User Interface First” beginnt die Arbeit an neuen Lösungen und Releases mit der Frage, wie der Anwender eine Aufgabe später am effektivsten lösen kann. Dabei werden die einzelnen Arbeitsschritte eines Workflows definiert, die Verknüpfungen der Schritte untereinander festgelegt und im optimalen Fall auch erste Tests mit Prototypen durchgeführt. Daraus ergeben sich die Spezifikationen der GUI (Graphical User Interface). Erst dann soll im Idealfall mit der eigentlichen Programmierarbeit begonnen werden. Am Ende der Entwicklung stehen dann Usability-Tests mit Anwendern, die sich dafür zur Verfügung stellen.

Usability-Tests für das Fein-Tuning

Es gibt gute Gründe, die Bedienbarkeit der Software vorrangig zu behandeln, wie Kreichgauer erläutert: “Wenn die Usability erst zum Schluss in unserem Labor getestet wird, kann es zum Super-GAU kommen. Dann sind die Testanwender vielleicht nicht in der Lage, die Masken zu bedienen oder die gestellten Aufgaben zu lösen.” Doch zu diesem Zeitpunkt gibt es keine Möglichkeit mehr, große Änderungen vorzunehmen. “Die Usability-Tests kurz vor der Produktauslieferung können nur dem Fein-Tuning dienen”, betont Kreichgauer.
Die Bedeutung der Bedienbarkeit ist bei SAP allgemein akzeptiert und wird vom Management voll unterstützt. Das spiegelt sich nicht zuletzt darin, dass die Usability ein fester Bestandteil des “Process Innovation Lifecycles” ist und auch bei der Qualitätssicherung geprüft wird. Dennoch müssen Kreichgauer und seine Kollegen immer mit Konflikten rechnen: “Oft wollen die Anwender keine Neuerungen, sondern ihr gewohntes Umfeld beibehalten.” Als die SAP-Listen von der Hintergrundfarbe Grau auf Weiß umgestellt wurden, kam bei internen Tests die Kritik auf, dass das SAP-Weiß greller sei als das von Windows gewohnte Microsoft-Weiß − dabei handelte es sich exakt um dieselbe Farbe.

Der Anwender hat das letzte Wort

Buchtipp

Buchtipp

Beim Design von Anwendungen müssen die Usability-Experten auch immer wieder zwischen unterschiedlichen Anforderungen abwägen und Kompromisse finden. So ist es zum Beispiel aus Sicht der Usability wünschenswert, dass alle Produkte eines Anbieters möglichst konsistent sind. Das führt aber aus Kreichgauers Sicht am praktischen Sinn der Usability vorbei: “Es geht dabei um die Frage, wie ich einem Anwender ein optimal auf seinen Bedarf angepasstes Werkzeug zur Verfügung stellen kann, dessen Bedienung selbsterklärend ist.” Obwohl zum Beispiel das Schreiben von Eingaben in die Datenbank in allen SAP-Produkten mit “Sichern” bezeichnet werden soll, gibt es eine Ausnahme: In Anwendungen für die Buchhaltung heißt diese Funktion “Buchen”. “Ein Buchhalter sichert nicht, er bucht. In diesem speziellen Fall unterstützt diese Bezeichnung die Bedienbarkeit besser, als wenn wir auf absoluter Konsistenz bestanden hätten.” Ein rein wissenschaftlicher Ansatz bei der Bewertung der GUIs ist deswegen nicht ausreichend. Kreichgauer und seine Kollegen setzen zu einem guten Teil auch auf ihre langjährige Erfahrung. Das letzte Wort in Sachen Bedienbarkeit haben aber immer die Anwender.
Sie und ihre Arbeit sind für das Usability Engineering Center das Maß der Dinge, daher ist die Feldarbeit für Kreichgauer unerlässlich: “Die Interface-Designer und Entwickler müssen vor Ort bei den Anwendern schauen, wie diese arbeiten. Die Aufgaben der User müssen bekannt sein, damit wir sie optimal unterstützen können.” So gibt es zum Beispiel für Materialstammdaten rund 500 mögliche Felder, die jedoch nie alle gebraucht würden. “Die Schwierigkeit liegt nun darin, nicht zu viele aber auch nicht zu wenige Informationen in der Maske anzuzeigen und alle wichtigen Daten aufgabenbezogen zur Verfügung zu stellen.”

Wo der Einfluss des Anbieters endet

Trotz der umfassenden Bemühungen, die Bedienbarkeit der Software immer weiter zu verbessern, hat SAP laut Kreichgauer jedoch noch immer einen schlechten Ruf in diesem Bereich. “Zu mindestens 80 Prozent liegt das jedoch nicht an der Software, die wir ausliefern”, fasst der Usability-Chef seine Beobachtungen zusammen. Meist lägen die Probleme der User an schlecht ausgeführtem Customizing, mangelnder Anwenderschulung und an kundeneigenen Erweiterungen. “Darauf haben wir natürlich keinen Einfluss”, bedauert Kreichgauer. “Das ist ein ähnliches Problem wie bei der Arbeitsplatzergonomie: Ob ein mit unseren Produkten ausgestatteter Arbeitsplatz der Arbeitsplatzverordnung entspricht oder nicht, können wir nicht festlegen. Da spielen viele Faktoren hinein, die ausschließlich vom Anwender bestimmt werden.” So gebe es zum Beispiel eine Norm, die festlegt, wie eine gut lesbare Schrift aussehen muss. “Ob die Schrift nachher am Bildschirm auch so groß ist, wie die Norm es fordert, hängt unter anderem von den Monitoreinstellungen des Benutzers ab. Wir können nur Sorge tragen, dass unsere Software es ermöglicht, die Vorschriften im Einzelfall auch umzusetzen.”

Jan Schulze

Jan Schulze

Leave a Reply