Usability-Management bei SAP-Projekten : Grundlagen - Vorgehen - Methoden [1. Aufl] 9783834802446, 3834802441 [PDF]

Zitiervorschau

Petra Abele Jörn Hurtienne Jochen Prümper (Hrsg.)

Usability Management bei SAP-Projekten

Aus dem Bereich IT erfolgreich nutzen

Best-Practice mit SAP® von Andreas Gadatsch und Reinhard Mayr SAP R/3® – Praxishandbuch Projektmanagement von Holger Gubbels Unternehmensführung mit SAP BI® von Heinz-Dieter Knöll, Christoph Schulz-Sacharow und Michael Zimpel SAP®-gestütztes Rechnungswesen von Andreas Gadatsch und Detlev Frick Logistikprozesse mit SAP R/3® von Jochen Benz und Markus Höflinger Requirements Analysis realisieren von Karl Scharbert Six Sigma in der SW-Entwicklung von Thomas Michael Fehlmann Management der Software-Entwicklung von Carl Steinweg Projektmanagement der SW-Entwicklung von Werner Mellis

Usability Management bei SAP-Projekten von Petra Abele, Jörn Hurtienne und Jochen Prümper (Hrsg.)

www.vieweg.de

Petra Abele Jörn Hurtienne Jochen Prümper (Hrsg.)

Usability Management bei SAP-Projekten Grundlagen – Vorgehen – Methoden Mit 73 Abbildungen

Bibliografische Information Der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über abrufbar.

Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne von Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürfen. Höchste inhaltliche und technische Qualität unserer Produkte ist unser Ziel. Bei der Produktion und Auslieferung unserer Bücher wollen wir die Umwelt schonen: Dieses Buch ist auf säurefreiem und chlorfrei gebleichtem Papier gedruckt. Die Einschweißfolie besteht aus Polyäthylen und damit aus organischen Grundstoffen, die weder bei der Herstellung noch bei der Verbrennung Schadstoffe freisetzen.

1. Auflage Juli 2007 Alle Rechte vorbehalten © Friedr. Vieweg & Sohn Verlag | GWV Fachverlage GmbH, Wiesbaden 2007 Lektorat: Günter Schulz / Andrea Broßler Der Vieweg Verlag ist ein Unternehmen von Springer Science+Business Media. www.vieweg.de Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlags unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. Konzeption und Layout des Umschlags: Ulrike Weigel, www.CorporateDesignGroup.de Umschlagbild: Nina Faber de.sign, Wiesbaden Druck- und buchbinderische Verarbeitung: MercedesDruck, Berlin Printed in Germany ISBN 978-3-8348-0244-6

Geleitwort In Unternehmen, Verwaltungen und Organisationen erledigen Mitarbeiterinnen und Mitarbeiter Arbeitsaufgaben, damit Ziele erreicht werden können. Dabei stützen sie sich immer häufiger auf Informations- und Kommunikationssysteme (IuK). Neueren Untersuchungen zufolge arbeiteten im Jahre 2005 fast 54 % der deutschen Beschäftigten mindestens ein Viertel ihrer Arbeitszeit am Computer. Ca. 40 % nutzten dabei E-Mail oder das Internet für ihre Arbeit, fast 9 % arbeiteten im Rahmen von Telearbeit von zu Hause aus an einem Computer (Europäische Stiftung, 2007). In anderen, wirtschaftlich auch sehr erfolgreichen europäischen Ländern wie z. B. Dänemark, Finnland, den Niederlanden, Norwegen, Schweden und der Schweiz sind die Anteile übrigens noch höher, so dass wir davon ausgehen können, dass die IuKgestützte Aufgabenerledigung auch in Deutschland noch weiter zunehmen wird. Diese Entwicklung hat schon in den 80er Jahren des vergangenen Jahrhunderts die Europäische Union veranlasst, sich durch eine Richtlinie der Arbeitsbedingungen bei der Bildschirmarbeit anzunehmen. Die EG-Bildschirm-Richtlinie (1990), die in Deutschland durch die Bildschirmarbeitsverordnung vom 4. Dezember 1996 in nationales Recht umgesetzt wurde und die zur Zeit gerade evaluiert wird, beschränkte sich dabei nicht nur auf die klassischen ergonomischen Faktoren, wie z. B. Bildschirm, Schreibtisch, Arbeitsstuhl und Arbeitsumgebung, sondern thematisierte auch die Mensch-Maschine-Schnittstelle, also das Zusammenwirken von Arbeitsaufgabe, Benutzer und Computer. Dies stieß in der Praxis vielfach auf Skepsis: Kann man so etwas überhaupt gesetzlich regeln? Sind die Zielformulierungen im Anhang der Richtlinie nicht viel zu allgemein, um wirklich eine Wirkung entfalten zu können? Auch folgende Argumentation war zu hören: „Es mag zwar wünschenswert sein, die Benutzungsfreundlichkeit von Software zu regeln, aber in der Praxis wird doch in sehr hohem Maße Standardsoftware eingesetzt, und die lässt sich doch gar nicht verändern.“ In diesem Zusammenhang fällt dann auch regelmäßig das Stichwort SAP. Ausgehend von diesem Einwand hat das nordrhein-westfälische Arbeitsministerium mit Hilfe des europäischen Sozialfonds zwei Projekte gefördert, die sich mit dieser Frage auch unter dem GeV

Geleitwort sichtspunkt der Verwendung von SAP-Software befasst haben: „Ergusto – Ergonomic Customizing bei SAP R/3“ und „ErgoCust – Gesundheits- und Effektivitätsförderung durch integriertes Ergonomic Customizing“. Dabei haben sich zwei Haupterkenntnisse ergeben: Erstens ist festzuhalten, dass der oben wiedergegebene Einwand nicht zutrifft. Moderne Software-Systeme bieten heute oftmals viele Anpassungsmöglichkeiten an betriebliche Gegebenheiten. Durch deren systematische Nutzung kann in Zusammenwirken mit Trainingsmaßnahmen und einem guten Management des Veränderungsprozesses ein Mehr an software-ergonomischer Qualität, ein Mehr an Usability erzielt werden. Dies führt wiederum dazu, dass die Beschäftigten gesünder arbeiten. Zweitens hat sich gezeigt, dass die Unternehmen, Verwaltungen und Organisationen, die den skizzierten Weg der Anpassung der Software an die betrieblichen Bedürfnisse gegangen sind, einen Nutzen davongetragen haben, der weit über das Themenfeld „Sicherheit und Gesundheit bei der Arbeit“ hinausweist. Sie konnten die Produktivität erhöhen und Kosten sparen. Denn die Benutzer arbeiten dann nicht nur effektiver und effizienter, sondern auch zufriedener. Kosteneinsparungen ergeben sich, weil Kosten für Training, Dokumentation und nachträgliche, aufwändige Änderungen entfallen. Allerdings zeigte sich auch: Der Einführungs- oder Veränderungsprozess, der zu mehr Benutzungsfreundlichkeit, zu mehr Usability führen soll, muss gemanagt werden, und er setzt zwingend die Beteiligung der Benutzer voraus. Es reicht nicht, Benutzungsfreundlichkeit nur gelegentlich in einem ansonsten rein betriebswirtschaftlich-technisch orientierten Einführungsprozess zu thematisieren oder einen „Usability-Beauftragten“ zu benennen. Usability muss konsequent und systematisch als Ziel verfolgt werden. Dies ist wiederum ohne die Einbeziehung der Benutzer, ohne ihre Beteiligung nicht möglich. Beteiligung bedeutet hier nicht nur Anhörung oder Unterweisung, sondern den direkten und individuellen Einfluss der Beschäftigten auf den Prozess der Einführung oder Weiterentwicklung der Software. Auch hierdurch kommt es zu produktivitätssteigernden Wirkungen (Richenhagen, Prümper & Wagner, 2002, S. 158ff).

VI

Geleitwort Es ist also ein Management der Benutzungsfreundlichkeit, ein Usability Management erforderlich, das das herkömmliche Projektmanagement in SAP-Projekten ergänzt. Dafür wiederum werden Erkenntnisse und Werkzeuge benötigt, die relativ einfach anwendbar sind. Diese stellt das vorliegende Buch bereit. Es leistet so einen wichtigen Beitrag zur Sicherung der Nachhaltigkeit der öffentlichen Projektförderung durch den europäischen Sozialfonds und das nordrhein-westfälische Ministerium für Arbeit, Gesundheit und Soziales: Die erzielten und nach Ende der Förderung weiterentwickelten Projektergebnisse werden in Form eines wissenschaftlich abgesicherten Handbuches zur Verfügung gestellt. Auf diese Weise ist es allen Unternehmen, Verwaltungen und Organisationen möglich, von den erarbeiteten Lösungen zu profitieren, zu ihrem Nutzen und zum Nutzen der Beschäftigten. Gottfried Richenhagen Ministerium für Arbeit, Gesundheit und Soziales des Landes Nordrhein-Westfalen

VII

Inhaltsverzeichnis Geleitwort .......................................................................................................................... V Konventionen .................................................................................................................XIII 1

Usability bei SAP-Projekten ......................................................................1

1.1

Praktischer Bedarf für Usability Management ....................................................1

1.2

Usability Management = Usability + Management .............................................7

1.3

Aufbau des Buches.............................................................................................13

1.4

Business Case für Usability Management .........................................................14

1.5

An wen wendet sich dieses Buch? ....................................................................19

1.6

Zusammenfassung und Ausblick.......................................................................21

2

Produktivitätsfaktor Usability Management..........................................23

2.1

Usability Management erhöht die Produktivität ...............................................23

2.2

Usability Management spart Kosten bei der Einführung .................................33

2.3

Usability Management verringert Stress ............................................................37

2.4

Zusammenfassung und Ausblick.......................................................................49

3

Gesetze, Verordnungen, Normen...........................................................51

3.1

Arbeitsschutzgesetz und Bildschirmarbeitsverordnung ...................................52

3.2

Behindertengleichstellungsgesetz......................................................................53

3.3

DIN EN ISO 9241: Ergonomie der Mensch-System-Interaktion ......................55

3.4

Zusammenfassung und Ausblick.......................................................................77

4

Vorgehensmodell zum Usability Management......................................79

4.1

Systematisch, ASAP-kompatibel und benutzerorientiert: Erfolgsfaktoren von Usability Management ......................................................80

4.2

Das Vorgehensmodell im Überblick .................................................................86

4.3

Exkurs: Ergonomische Stellschrauben ............................................................104

4.4

Zusammenfassung und Ausblick.....................................................................106

IX

Inhaltsverzeichnis 5

Projekteinstieg.......................................................................................109

5.1

Ergonomische Projektziele...............................................................................110

5.2

Projektumfang und Projektaufgaben...............................................................114

5.3

Beteiligung ........................................................................................................118

5.4

Projektstandards ...............................................................................................129

5.5

Ergonomischer Meilenstein 1 ..........................................................................130

5.6

Zusammenfassung und Ausblick.....................................................................131

6

Anforderungsanalyse............................................................................133

6.1

Nutzungskontextanalyse: Aufgaben, Benutzer, Technik ...............................135

6.2

Anforderungen..................................................................................................160

6.3

Ergonomischer Meilenstein 2 ..........................................................................171

6.4

Zusammenfassung und Ausblick.....................................................................171

7

Sollkonzeption ......................................................................................173

7.1

Arbeitsprozess- und Dialoggestaltung.............................................................175

7.2

Ergonomischer Rollenzuschnitt .......................................................................197

7.3

Evaluation mit Benutzern.................................................................................206

7.4

Ergonomischer Meilenstein 3 ..........................................................................209

7.5

Zusammenfassung und Ausblick.....................................................................210

8

Realisierung...........................................................................................213

8.1

Aufbau testbarer (Teil-)Prozesse .....................................................................216

8.2

Evaluation testbarer (Teil-)Prozesse mit Benutzern .......................................218

8.3

Evaluation integrierter Arbeitsprozesse...........................................................230

8.4

Ergonomischer Meilenstein 4 ..........................................................................235

8.5

Zusammenfassung und Ausblick.....................................................................235

9

Schulung ................................................................................................239

9.1

Qualifizierung der Projektbeteiligten ..............................................................240

9.2

Lernsystem ........................................................................................................247

9.3

Zusammenfassung und Ausblick.....................................................................256

X

Inhaltsverzeichnis 10

Go Live & Optimierung .........................................................................259

10.1

Test im Echtbetrieb und Optimierung ............................................................260

10.2

Ergonomischer Meilenstein 5 ..........................................................................264

10.3

Kontinuierlicher Verbesserungsprozess ..........................................................269

10.4

Zusammenfassung und Ausblick.....................................................................273

11

Usability Care ........................................................................................275

11.1

Überblick...........................................................................................................276

11.2

Ergonomische Ist-Analyse................................................................................278

11.3

Systemanpassung..............................................................................................302

11.4

Wirkungskontrolle ............................................................................................309

11.5

Zusammenfassung und Ausblick.....................................................................314

12

Erfolgsfaktoren .....................................................................................317

12.1

Erfolgsfaktor Projektplanung ...........................................................................318

12.2

Erfolgsfaktor Zielklarheit..................................................................................321

12.3

Erfolgsfaktor Wissen.........................................................................................326

12.4

Erfolgsfaktor Kommunikation..........................................................................328

12.5

Erfolgsfaktor Verbindlichkeit ...........................................................................330

12.6

Zusammenfassung und Ausblick.....................................................................332

13

User-Centered Design-Prozess der SAP AG..........................................333

13.1

Herausforderungen an die SAP AG.................................................................333

13.2

Benutzbarkeit im Vergleich zu Gebrauchstauglichkeit..................................336

13.3

Prinzipien des User-Centered Design .............................................................337

13.4

Was passiert konkret im UCD? ........................................................................343

13.5

SAP-Produktstandard Usability, Styleguides ...................................................353

13.6

Zusammenfassung ............................................................................................354

Literaturverzeichnis ........................................................................................................357 Dank................................................................................................................................365 Über die Autorinnen und Autoren................................................................................367 Sachregister.....................................................................................................................371

XI

Konventionen In diesem Buch gelten folgende Konventionen: Software-Ergonomie, Gebrauchstauglichkeit, software-ergonomische Qualität und Usability werden synonym verwendet. Entsprechend meint z.B. „software-ergonomische Anforderungen“ immer die Anforderungen, deren Erfüllung die Usability einer SAP-Software erhöht. Häufig wird eine „herkömmliche Vorgehensweise“ dem Vorgehen im Usability Management gegenüber gestellt. Mit dem Wort „herkömmlich“ sind diejenigen Aktivitäten gemeint, die heute bereits standardmäßig bei SAP-Einführungsprojekten (ohne Usability Management) ablaufen. Um die Interessen unserer Kunden und Projektteilnehmer zu wahren, mussten wir einige der aufgeführten Praxisbeispiele anonymisieren bzw. abwandeln. So konnten wir an manchen Stellen nicht allzu sehr ins Detail gehen. Manche Fallbeispiele setzen sich auch aus Erfahrungen in mehreren Projekten zusammen. Ebenso wurden aus Datenschutzgründen einige Screenshots verwischt oder teilweise geschwärzt sowie andere Angaben nur näherungsweise übernommen. Microsoft, WINDOWS, EXCEL, Word und PowerPoint sind eingetragene Marken der Microsoft Corporation; ORACLE ist eine eingetragene Marke der ORACLE Corporation; SAP, R/3, mySAP, mySAP.com, xApps, SAP NetWeaver und weitere im Text erwähnte SAP-Produkte und -Dienstleistungen sowie die entsprechenden Logos sind Marken oder eingetragene Marken der SAP AG in Deutschland und anderen Ländern weltweit. Alle anderen Namen von Produkten und Dienstleistungen sind Marken der jeweiligen Firmen. Jede Auslassung der Markennennung bei allen Produkten bedauern wir; eine Rechtsverletzung dieser Marke(n) ist damit nicht beabsichtigt. Aus Gründen der besseren Lesbarkeit wird bei geschlechtsspezifischen Substantiven die männliche Form verwendet. Diese Form versteht sich explizit als geschlechtsneutral, Frauen sind an den entsprechenden Stellen selbstverständlich mit eingeschlossen.

XIII

1

Usability bei SAP-Projekten Dieses Kapitel führt Sie in das Themenfeld „Usability bei SAP-Projekten“ ein. Es zeigt Ihnen, was Usability Management ist und wie es nutzbringend eingesetzt werden kann. Sie erhalten einen Überblick über die angesprochenen Zielgruppen und die Kapitelgliederung dieses Buches. Sie halten das Buch „Usability Management bei SAP-Projekten“ in Ihren Händen. Was hat Sie wohl bewogen, hineinzuschauen oder es gar zu erwerben? Vielleicht sind Sie grundsätzlich an Usability interessiert und wollen wissen, was man tun kann, damit SAP-Software im Unternehmen benutzungsfreundlicher wird. Möglicherweise stehen Sie und Ihr Unternehmen auch vor einer SAP-Einführung, und Sie suchen noch nützliche Tipps und Hinweise zum Vorgehen. Vielleicht sind Sie auch mit der SAP-Lösung, die in Ihrem Unternehmen realisiert wurde, nicht zufrieden und suchen nach Verbesserungsmöglichkeiten. Oder Sie sind in Ihrem Unternehmen für die Einhaltung der Bildschirmarbeitsverordnung an SAP-Arbeitsplätzen verantwortlich und benötigen für die entsprechende Umsetzung fundierte Hintergrundinformationen. Es gibt viele Gründe, die Sie bewogen haben mögen, in dieses Buch zu schauen. Wahrscheinlich fragen Sie sich auch: Was genau ist eigentlich Usability Management? Wie kann mir Usability Management nützen? Wie geht man dabei vor? Das Buch versucht auf alle diese Fragen Antworten zu geben.

1.1

Praktischer Bedarf für Usability Management Beispiele aus der Praxis zeigen, dass SAP-Einführungsprojekte bei weitem nicht immer so rund laufen, wie sich dies alle Beteiligten wünschen: •

Michael Doane, ehemals Vizepräsident und Forschungsdirektor des US-amerikanischen Marktforschungsunternehmens META Group (seit 2005 Gartner Group) berichtet, dass 80 % der Kunden des SAP-Basissystems von der erreichten Performanz, deren Messbarkeit und der Kompetenz der Nutzer nach dem Einführungsprojekt enttäuscht sind (Doane, 2004).

1

1 Usability bei SAP-Projekten •

Der Wirtschaftsinformatiker Oliver Kohnke (2005) berichtet von einer Studie mit 117 Unternehmen, die betriebswirtschaftliche Software eingeführt haben, nach der ein Fünftel der Projekte vor dem Abschluss der Implementierung abgebrochen werden. Bei den abgeschlossenen Projekten gaben 40 % der Unternehmen an, dass sie ihre Ziele auch nach einem Jahr noch nicht erreicht hatten.

•

In der Fachpresse veröffentlichte Studien zeigen, dass, was die Zufriedenheit der Benutzer betrifft, implementierte SAPSoftware oftmals Programmen von kleineren Anbietern unterlegen ist (Bayer, 2006; Niemann, 2006). Eine häufige und von Anwendern übereinstimmend geäußerte Anforderung ist: Die Softwarepakete sollten flexibler und benutzungsfreundlicher sein (vgl. Niemann, 2006).

Ein konkretes Beispiel aus der Praxis in Kasten 1.1 soll dies anschaulich illustrieren. Kasten 1.1: SAP-Einführung (Negativbeispiel) Ein SAP-Flop? In einem großen Industrieunternehmen sollte an allen 20 Standorten SAP-Software eingeführt werden, um die unterschiedlichen Altsysteme in den verschiedenen Tochterunternehmen abzulösen. Ziel der durch den Vorstand beschlossenen Einführung war einerseits die Reduzierung des Arbeitsaufwandes für die Systempflege durch eine einheitliche integrierte IT-Landschaft. Andererseits sollten die Geschäftsprozesse in der gesamten Organisation aneinander angeglichen und dadurch nicht nur effektiver und transparenter, sondern auch effizienter im Ablauf werden. Für das Einführungsprojekt war eine Gesamtdauer von sieben Monaten vorgesehen. Einen Monat vor dem festgesetzten Termin für die unternehmensweite Inbetriebnahme der SAP-Software (d. h. die Produktivsetzung) war bereits offensichtlich, dass nicht alle zur Abwicklung der Geschäftsprozesse erforderlichen Funktionalitäten rechtzeitig zur Verfügung stehen würden. So war beispielsweise abzusehen, dass eine für die Buchung von Rechnungen erforderliche Schnittstelle noch nicht wie gewünscht funktionieren sollte, da einige Anforderungen an diese erst sehr spät bekannt geworden waren. Auch die Vergabe von Berechtigungen für die Nutzung unterschiedlicher Softwarefunktionalitäten war aufgrund des Zeitdrucks durch andere Probleme noch nicht hinreichend umgesetzt. 2

1.1 Praktischer Bedarf für Usability Management Dennoch sollte der Termin für die Produktivsetzung unbedingt gehalten werden, und so wurden Übergangslösungen entworfen, die allerdings einen beträchtlichen Zusatzaufwand für die Beschäftigten mit sich brachten. Die Realisierung anderer Funktionalitäten (außerhalb der Kernfunktionalität) wurde zunächst einmal zurückgestellt. Zwei Monate nach Produktivsetzung wurde an mehreren Standorten offensichtlich, dass das SAP-System im Vergleich zum jeweiligen Altsystem komplizierter, langsamer und umständlicher war. Lokale Besonderheiten in einigen Tochterunternehmen waren nicht ausreichend berücksichtigt worden, da die Konzeption der SAP-gestützten Geschäftsprozesse zentral erfolgte. Entsprechend gelang in diesen Standorten die Anpassung an die neue unternehmenseinheitliche Arbeitsweise nur teilweise. Zusätzliche „Notlösungen“ mussten entwickelt werden. Statt der beabsichtigten einheitlichen, transparenten und effektiven Geschäftsprozesse herrschte ein undurchschaubares und unproduktives Chaos. Obwohl keine grundlegend anderen Funktionalitäten erforderlich waren, verlangte die neue SAP-Software viele zusätzliche Arbeitsschritte und organisatorische Umwege. So konnte beispielsweise jeder Mitarbeiter nur die Buchungsbelege einsehen, die er selber gebucht hatte. Anordnungsbefugte Mitarbeiter mussten daher die Belege für Buchungen, die sie veranlasst hatten, erst von denjenigen anfordern, die die Buchungen tatsächlich durchgeführt hatten. Durch den Zusatzaufwand in der ersten Zeit nach der Produktivsetzung und durch die langsamere, umständliche Abwicklung der Geschäftsprozesse hatte sich so viel Arbeit angestaut, dass Rechnungsstellungen oft erst mit einer Verspätung von vier bis sechs Wochen erfolgten. Dies hatte nicht nur wirtschaftliche Konsequenzen, sondern wirkte sich durch die notwendige – und in den Augen der Mitarbeiter unnötige – Mehrarbeit stark beeinträchtigend auf die Motivation und Zufriedenheit aus. Stress und Unzufriedenheit der Mitarbeiter mit der neuen SAP-Software wuchsen derartig an, dass das Unternehmen in kürzester Zeit mit einer bislang noch nie da gewesenen Krankheitsquote konfrontiert wurde. Infolge dieser Entwicklung drohte der Betriebsrat mit der Einstellung des SAPProjektes. Die Probleme führten dazu, dass ein im ursprünglichen Etat nicht vorgesehenes Optimierungsprojekt gestartet wurde. Ein 3

1 Usability bei SAP-Projekten Jahr später waren die drängendsten technischen und organisatorischen Probleme so weit gelöst, dass endlich die Weiterentwicklung der SAP-Berichte gemeinsam mit den Benutzern in Angriff genommen werden konnte, da das Berichtswesen noch nicht in ausreichendem Maße die Bedürfnisse der dezentralen Unternehmenseinheiten abdeckte. 20 Monate nach der Einführung startete dann noch eine „Offensive zur Erhöhung der Datenqualität“, um die Altdaten so weit zu bereinigen, dass endlich der Abschluss des vorhergehenden Buchungsjahres erfolgen konnte. Zwei Jahre nach der SAP-Einführung waren die Optimierungen endlich so weit abgeschlossen, dass mit der SAP-Software so produktiv gearbeitet werden konnte wie mit den Altsystemen. Die Belastungen der Mitarbeiter waren wieder auf ein erträgliches Maß gesunken. Aus dem Büro der Projektleitung hörte man: „Unser System läuft inzwischen technisch stabil, und die Integration der einzelnen Komponenten ist abgeschlossen. Jetzt stehen zunehmend die Prozesse und die Erarbeitung SAP-konformer Vorgänge im Mittelpunkt der Arbeit des SAP-Teams und der Fachabteilungen.“ Insgesamt hat das Projekt viel mehr Zeit und Geld gekostet, als eingeplant war, und die angestrebten Ziele der SAP-Einführung konnten – wenn überhaupt – nur mit langer Verzögerung erreicht werden. Positivbeispiele

Ebenso lassen sich in der Praxis jedoch auch zahlreiche Beispiele erfolgreicher SAP-Installationen finden, mit denen die Kunden hoch zufrieden sind (z. B. Kasten 1.2). Auf den Webseiten der SAP AG (www.sap.com) und ihrer Logo-Partner finden sich so genannte „SAP Customer Success Stories“, die erfolgreiche Einführungsprojekte mit verschiedensten SAP-Softwarelösungen beschreiben. Darunter sind durchaus Projekte, die „in time and below budget“ abliefen, die also innerhalb der geplanten Projektzeit abgeschlossen wurden und die auch das im Vorfeld veranschlagte Budget nicht überschritten. Zu den am häufigsten genannten Erfolgen dieser SAP-Einführungen zählen: •

4

die verbesserte Transparenz der Geschäftsprozesse, der Kosten und Erlöse durch integrierte und aktualisierte Daten und die damit mögliche zeitnahe und effizientere Planung (bessere Ausschöpfung von Ressourcen, z. B. im Außendienst);

1.1 Praktischer Bedarf für Usability Management •

eine höhere Geschwindigkeit und Effizienz der Geschäftsprozesse (z. B. bei Reaktionszeiten auf Kundenwünsche oder Auftragsdurchlaufzeiten);

•

die erweiterte Funktionalität und Automatisierung der DVProzesse;

•

die reduzierten Kosten für Systemadministration durch eine vereinheitlichte Systemlandschaft;

•

der reduzierte Verwaltungsaufwand durch medienbruchfreies Arbeiten, Vermeidung von redundanter Datenerfassung und effiziente Funktionalität.

Auch „Benutzerfreundlichkeit“ und „Mitarbeiterzufriedenheit“ werden in den Success Stories explizit genannt, wenn auch noch nicht häufig (z. B. SAP AG, 2005). Kasten 1.2: SAP-Einführung (Positivbeispiel) Erfolgsstory in der Zeiterfassung Bei einem europäischen Energieversorger mit etwa 35.000 Mitarbeitern wurde eine webbasierte ESS-Lösung (Employee Self Service) von SAP eingeführt, mit deren Hilfe die Arbeitszeitund Reisedaten zukünftig von den Mitarbeitern selbst eingegeben werden konnten. Vorher war gerade die Zeiterfassung des Wartungspersonals, das oftmals weite Strecken fährt, um z. B. Generatoren und Hochspannungsleitungen zu überprüfen und zu reparieren, mit einem sehr hohen Verwaltungsaufwand einhergegangen. So zeigte eine Arbeitsanalyse folgenden typischen Ablauf: Von einem Auftrag kehrten Wartungsarbeiter mit Notizen auf Papier zurück. Anschließend füllten sie ein Formular mit den Arbeitszeiten und den verwendeten Werkzeugen aus. Ein Sachbearbeiter sammelte die Unterlagen ein und öffnete eine Erfassungssoftware. Dazu meldete er sich nacheinander unter den Namen der jeweiligen Wartungsarbeiter an und füllte den Zeitreport aus. Dieser bildete dann die Grundlage für Bezahlung, Überstundenausgleich und Buchung der Auftragsdurchführung auf einzelne Kostenstellen. Dieser hohe Verwaltungsaufwand reduzierte nicht nur die Produktivität, sondern wurde von den Mitarbeitern auch als lästige Behinderung ihrer eigentlichen Arbeit erlebt. Die Einführung von SAP ESS ermöglichte den Wartungsarbeitern selbst eine einfache Eingabe der Daten, so dass der zeitraubende und fehleranfällige Zwischenschritt über den Sachbearbeiter entfallen konnte. Da die Arbeiter selten allein unterwegs waren und oft ähnliche Aufgaben erledigten, konnte der Verwaltungsauf5

1 Usability bei SAP-Projekten wand zusätzlich dadurch noch weiter reduziert werden, dass für mehrere Arbeiter gleichzeitig Gruppenbuchungen vorgenommen werden konnten. Indem ca. 35.000 Mitarbeitern eine schnelle und einfache Buchführung über ihre Arbeitszeit und Reisekosten zur Verfügung gestellt wurde, konnte nicht nur in erheblichem Umfang die Produktivität verbessert werden, auch die Zufriedenheit der Mitarbeiter wuchs. Gründe für Erfolg Wie kommt es, dass Projekte, bei denen die gleiche Software eingeführt wird, mal als Erfolgsstory enden und mal scheitern? und Misserfolg Ob ein Softwareprojekt erfolgreich ist oder nicht, hängt ganz wesentlich davon ab, inwieweit bei der Einführung Usability und Benutzerorientierung eine zentrale Rolle spielen und sie nicht nur mit einem rein betriebswirtschaftlich-technischem Verständnis von Projektmanagement durchgeführt wird. So wurde im ersten Beispiel die SAP-Software nur mit den technisch oder betriebswirtschaftlich unbedingt erforderlichen Anpassungen im Unternehmen eingeführt, ohne dass man auf die Besonderheiten der betrieblichen Situation Rücksicht nahm. Entsprechend zeigte sich auch erst im Nachhinein, dass die Arbeit mit der SAP-Lösung unproduktiver, fehleranfälliger und unbefriedigender war als die Arbeit mit dem Altsystem. Im zweiten Beispiel hingegen wurde von Anfang an sehr viel Wert darauf gelegt, die Software so an die betrieblichen Belange anzupassen, dass den Benutzern eine schnelle, leicht zu bedienende SAP-Lösung zur Verfügung gestellt werden konnte, die sie bei ihrer Arbeit optimal unterstützte und von ihnen akzeptiert wurde. Dieses Ziel wurde mittels Usability Management konsequent und systematisch während der SAP-Einführung verfolgt. Die Beispiele zeigen, dass Investitionen in Hard- und Software per se nicht ausreichen, um produktive Arbeit zu gewährleisten. Ob SAP-Software produktiv genutzt werden kann, hängt vielmehr davon ab, wie ihre Einführung erfolgt. Damit stellt sich auch nicht so sehr die Frage, ob sich Investitionen in SAP-Software auszahlen, sondern wie SAP-Software im Unternehmen am besten genutzt werden kann, damit sich Investitionen lohnen. Faktor Mensch bei SAPEinführungen

6

Studien zeigen, dass bei Konzipierung, Auswahl, Erwerb und Anpassung von ERP-Software (Enterprise Ressource Planning Software, z. B. SAP R/3) immer wieder drei Bereiche wichtig sind, die sich mit dem „menschlichen Faktor“ befassen und die entscheidend für den Erfolg eines Software-Projektes sind; nämlich:

1.2 Usability Management = Usability + Management •

Organizational Change Management,

•

Training und

•

Usability Management.

Diese drei Bereiche hängen eng zusammen und weisen entsprechend auch immer wieder Überschneidungen auf, unterscheiden sich jedoch wesentlich in der jeweiligen Schwerpunktsetzung. Organizational Change Management ist das Management von Veränderungsprozessen in einer Organisation. Sollen, wie bei einer SAP-Einführung häufig der Fall, Funktionen und Arbeitsabläufe umstrukturiert werden, so sind davon immer Menschen mit ihren spezifischen Einstellungen, Sorgen und Wünschen betroffen. Bewusst durchgeführtes Change Management dient dazu, diese „weichen Faktoren“ nicht zum Sand im Getriebe eines Umstellungsprozesses werden zu lassen. Daher ist Organizational Change Management ein unverzichtbarer Bestandteil erfolgreicher SAP-Projekte. Für mehr Informationen zu Organizational Change Management sei auf die Bücher von Kohnke & Bungard (2005) sowie Doppler & Lauterburg (2005) verwiesen. Damit eng verbunden sind alle Maßnahmen, die mit dem Training der Benutzer, nicht nur im Umgang mit der Software, sondern auch im Hinblick auf neue fachliche Aufgaben entstehen. Mehr über SAP-Training finden Sie in dem Buch von Scherer & Schaffner (2003). Während sich die beiden vorgenannten Bereiche vorrangig mit Veränderungen der Organisation und der Beschäftigten befassen, hat der dritte Bereich – Usability Management – die Anpassung der Software im Fokus der Aufmerksamkeit. Über Usability Management erfahren Sie mehr in diesem Buch. Zunächst soll der Begriff in den folgenden Abschnitten ausführlicher erläutert werden.

1.2

Usability Management = Usability + Management Der Ausdruck „Usability Management“ besteht aus den beiden Wörtern Usability und Management: Usability ist das Ziel, das erreicht werden soll, und mit Management ist die Gestaltung des Prozesses gemeint, mit dem dieses Ziel erreicht werden kann. Schauen wir uns beides näher an.

7

1 Usability bei SAP-Projekten

1.2.1

Usability Usability, oft auch Benutzungsfreundlichkeit, Gebrauchstauglichkeit oder software-ergonomische Qualität genannt, ist ein Maß dafür, wie gut eine Software die Benutzer bei der Erledigung ihrer Arbeitsaufgaben unterstützt. Damit geht Usability weit über ein ergonomisches Design von Benutzungsoberflächen hinaus. Ergonomische Benutzungsoberflächen, d. h. Benutzungsoberflächen, die die physischen und psychischen Eigenschaften des Menschen berücksichtigen (z. B. bei Schriftgröße, Art und Anordnung von Schaltflächen, Farbgestaltung etc.), sind eine Voraussetzung für Usability, reichen aber alleine nicht aus, um Usability zu sichern. Ganz allgemein kann Usability zunächst als die Passung zwischen Aufgabe, Benutzer und Software in einem bestimmten Nutzungskontext beschrieben werden (s.Abbildung 1.1). Mit dem Konzept der Gebrauchstauglichkeit und den Kriterien Effektivität, Effizienz und Zufriedenheit nach DIN EN ISO 9241-11 lernen Sie im Kapitel 2 eine ausführlichere Definition von Usability kennen.

Dreieck der Software-Ergonomie

Sehen wir uns die einzelnen Komponenten derAbbildung 1.1 genauer an. Zu einer Aufgabe, z. B. der Eingabe von Zeitdaten in SAP ESS (Employee Self Service) oder dem Ausstellen einer Rechnung, gehören bestimmte Inhalte, Abläufe, Kooperationsbeziehungen etc., die die Software unterstützen muss, damit ein effektives Arbeiten möglich ist. Hier ist besonders zu berücksichtigen, dass sich durch die Einführung von SAP-Software bestehende Arbeitsaufgaben häufig verändern oder neue Aufgaben für die Benutzer entstehen. Die Benutzer bzw. die Benutzergruppen, die mit der Software arbeiten sollen, können u. a. hinsichtlich Alter, kulturellem Hintergrund, Wissen über und Erfahrungen mit den Aufgaben, SAPSoftware oder Computern allgemein, hinsichtlich eventuell vorhandener Wahrnehmungs- oder Bewegungseinschränkungen (Behinderungen) sowie hinsichtlich ihrer Ansprüche und Erwartungen charakterisiert werden. Diese Eigenschaften beeinflussen, wie die SAP-Software von den Benutzern wahrgenommen wird und wie sie mit ihr arbeiten. Die Technik stellt den Benutzern die Werkzeuge zur Lösung ihrer Arbeitsaufgaben zur Verfügung. Sie ist beschrieben durch die Eigenschaften der Hardware mit den verfügbaren Ein- und Ausgabegeräten sowie – im vorliegenden Kontext besonders relevant – durch die Eigenschaften der Software. Eigenschaften der Software sind z. B. die verfügbare Funktionalität, das grafische De-

8

1.2 Usability Management = Usability + Management sign und die Interaktionsmöglichkeiten, die dem Benutzer angeboten werden. Aber auch die vorhandenen Möglichkeiten, die Software an betriebliche Belange anzupassen, zählen dazu.

Abbildung 1.1:

Dreieck der Software-Ergonomie: Usability als Passung von Aufgabe, Benutzer und Technik in einem Nutzungskontext

Aufgaben, Benutzer und Technik stehen dabei nicht im leeren Raum, sondern ihre Beziehungen zueinander werden maßgeblich bestimmt durch den sie umgebenden Nutzungskontext. Dazu gehören zum Beispiel Größe und Organisation des Unternehmens, die Organisationskultur und der gesellschaftlich-rechtliche Kontext, in dem die Nutzung stattfindet. Usability ist dann gegeben, wenn in einem konkreten Nutzungskontext die Passung zwischen Aufgaben, Benutzern und Technik – hier vor allem SAP-Software – optimal ist. Dazu muss erstens die SAP-Software zu den Arbeitsaufgaben passen, also die richtigen Funktionalitäten bereitstellen. Zweitens muss sie zu den Eigenschaften ihrer Benutzer passen, d. h. ihnen ein effektives Arbeiten ermöglichen. Schließlich müssen auch noch die Benutzer zu den (neuen) Aufgaben passen, d. h. entsprechend qualifiziert sein. Wenn die Software nicht zu den Aufgaben oder den Benutzern passt, resultieren daraus Probleme wie z. B. die oben im ersten 9

1 Usability bei SAP-Projekten Praxisbeispiel (Kasten 1.1) beschriebenen: Arbeiten dauern länger als früher, zusätzliche Arbeitsschritte werden erforderlich, die Qualität der Arbeitsergebnisse wird schlechter, die Zufriedenheit der Beschäftigten sinkt. Damit wird auch offensichtlich, dass SAP-Software nicht per se über Usability verfügt oder nicht verfügt, sondern dass es immer darauf ankommt, wie, wo und wann die Software eingesetzt wird. Oder, um es noch einmal an einem anderen Beispiel zu veranschaulichen: Wenn Sie Microsoft Excel für Ihre Reisekostenaufstellungen verwenden, werden Sie die Usability sicherlich sehr viel höher einschätzen, als wenn Sie mit Microsoft Excel umfangreiche Serienbriefe erstellen müssen. SAP AG und Usability

Damit wird auch klar, dass die SAP AG als Hersteller nicht allein für die Usability von SAP-Software sorgen kann, sondern dass das Anwenderunternehmen ebenso dafür verantwortlich ist. Die SAP AG kann lediglich die Voraussetzungen dafür schaffen, dass sich im Anwenderunternehmen Usability durch eine gute Anpassung der Software ermöglichen lässt, indem sie zum einen für ergonomisch gestaltete Benutzungsoberflächen sorgt und zum anderen eine Vielzahl von Anpassungsmöglichkeiten ihrer Software vorsieht. Beidem wird bei der SAP AG bereits seit langem ein hohes Gewicht beigemessen (vgl. hierzu insbesondere auch Kapitel 13). So kümmern sich zum Beispiel etwa 100 Mitarbeiter bei der SAP AG in einer User Experience Gruppe um die Gestaltung der Benutzungsschnittstellen. Auch Möglichkeiten zur Anpassung der Software werden bei technologischen Weiterentwicklungen immer mitbedacht, damit die SAP-Software in Zukunft noch flexibler wird und Änderungen schneller und kostengünstiger realisierbar sind. Beispiele für die zunehmende Flexibilität sind die auf der SAP NetWeaver-Technologie basierenden xApps Composite Applications, das neue Muse GUI oder iViews für SAP Enterprise Portale. Trotz dieser umfassenden Bemühungen hat SAP-Software im Hinblick auf Usability aber noch immer einen schlechten Ruf. Die Gründe hierfür liegen – so Ulrich Kreichgauer, Diplom-Psychologe und Leiter der Gruppe „User Experience Infrastructure“ bei der SAP AG – „zu mindestens 80 Prozent ... jedoch nicht an der Software, die wir ausliefern", sondern an schlecht ausgeführtem Customizing, mangelnder Anwenderschulung und an kundeneigenen Erweiterungen (vgl. Schulze, 2004) – und damit an Faktoren, auf die die SAP AG selbst so gut wie keinen Einfluss hat. Die Anwenderunternehmen haben aber oft noch nicht er-

10

1.2 Usability Management = Usability + Management kannt, dass sie selbst gefragt sind, die Passung zwischen Aufgaben, Benutzern, Organisation und SAP-Software herzustellen und damit Usability zu sichern. Maßnahmen zur Verbesserung der Usability

Wenn die Passung zwischen Aufgabe, Benutzer und Technik nicht optimal ist, können Sie Maßnahmen zur Verbesserung der Situation ergreifen, die an allen Ecken des oben beschriebenen Dreiecks der Software-Ergonomie ansetzen: •

Sie können die Arbeitsaufgaben verändern, z. B. durch die Veränderung der Arbeitsteilung zwischen den Mitarbeitern.

•

Sie können die Benutzereigenschaften verändern, z. B. durch die Auswahl geeigneter Mitarbeiter oder durch Schulungen.

•

Sie können die Software verändern, z. B. durch Ausnutzen der vorhandenen Anpassungsmöglichkeiten.

Solche Verbesserungsmaßnahmen sind oft eng miteinander verzahnt. Je nachdem, worauf Sie den Schwerpunkt legen, werden Sie ein Projekt in dem bereits erwähnten Bereich Organizational Change Management (für einen Schwerpunkt bei „Aufgaben“) oder ein Projekt in dem oben erwähnten Bereich Training (für einen Schwerpunkt bei „Benutzerqualifikationen“) oder ein Projekt zum Usability Management (für einen Schwerpunkt bei „Software“) anstoßen. Letzteres steht im Fokus dieses Buches. Selbstverständlich aber gibt es, wie bereits erwähnt, Überschneidungen zwischen diesen drei Bereichen, und dies wird bei der Planung konkreter Verbesserungsmaßnahmen auch beim Usability Management berücksichtigt. Nachdem die vorausgehenden Abschnitte verdeutlicht haben, was unter Usability zu verstehen ist, soll nachfolgend der Begriff des Usability Management im Zusammenhang einer SAP-Einführung beleuchtet werden.

1.2.2

Usability Management Bei SAP-Einführungen gehen die meisten Unternehmen heute immer noch lediglich betriebswirtschaftlich-technisch orientiert vor. Aus dieser Perspektive wird, ausgehend vom technischen Angebot der Software, diskutiert, welche Anpassungen vorgenommen werden müssen, damit die Geschäftsprozesse betriebswirtschaftlich richtig ablaufen, und welche betriebsspezifischen Inhalte dafür in die Software integriert werden müssen. Zur Unterstützung dieser Vorgehensweise stellt die SAP AG eine Einführungsmethodik namens ASAP (Accelarated SAP) als Hilfsmittel zur Verfügung (vgl. auch Kapitel 4). Bei einer solchen Vorge11

1 Usability bei SAP-Projekten hensweise werden allerdings die konkreten Aufgaben, die künftig mit der SAP-Software erledigt werden müssen, sowie die Benutzer, die sie erledigen sollen, schnell vernachlässigt. Dies kann leicht zu einer schlechten Passung von Aufgaben, Benutzern und Software und somit zu geringer Usability führen. Um Usability zu erzielen, ist also eine stärkere Orientierung auf die Benutzer und ihre Aufgaben im Unternehmen erforderlich. Für eine benutzerorientierte Perspektive bei der SAP-Einführung reicht es aber nicht aus, Usability nur gelegentlich, wenn gerade Zeit dazu ist, im Einführungsprozess zu thematisieren oder einen „Usability-Beauftragten“ zu benennen. Es ist vielmehr erforderlich, Usability konsequent und systematisch als Ziel zu verfolgen. Nur der systematisch geplante und gezielte Einsatz software-ergonomischer Analyse-, Design- und Evaluationsmethoden zu den jeweils richtigen Zeitpunkten sichert den Projekterfolg. Usability Management meint demnach eine benutzerorientierte Vorgehensweise, bei der durch software-ergonomische Maßnahmen in enger Verzahnung zu den allgemeinen Aktivitäten bei einer SAP-Einführung (z. B. nach ASAP) die Passung zwischen der SAP-Software, der konkreten Arbeitstätigkeit und den Benutzern optimiert und damit Usability gesichert wird. Usability Management ergänzt also das herkömmliche betriebswirtschaftlich-technische Projektmanagement in SAP-Projekten dort, wo es erforderlich ist, um eine angemessene Usability der SAP-Lösung im Anwenderunternehmen zu erreichen. Baukastenprinzip Usability Management bedeutet natürlich auch, das Kosten-Nutzen-Verhältnis von Usability-Aktivitäten zu optimieren. In den nachfolgenden Kapiteln werden Sie eine Vielzahl von Maßnahmen und Methoden kennenlernen, die keinesfalls immer alle vollständig eingesetzt werden müssen. Manchmal reicht schon eine einzelne Maßnahme, um Usability entscheidend im positiven Sinne zu beeinflussen. Ein anderes Mal sind vielleicht viele software-ergonomische Anpassungen erforderlich, um gute Usability zu erzielen, aber eine geringe Usability würde den Unternehmenserfolg gefährden, z. B. weil Fehler der Benutzer fatale Folgen hätten oder die Produktqualität sehr nachließe. Auch über Aspekte, die bei der Auswahl von Usability-Aktivitäten zu berücksichtigen sind, um das Kosten-Nutzen-Verhältnis zu optimieren, werden Sie in den nachfolgenden Kapiteln mehr erfahren. Um diesen Prozess des Managens von Usability sichernden Maßnahmen bei SAP-Projekten wird es in dem Buch gehen.

12

1.3 Aufbau des Buches

1.3

Aufbau des Buches Im folgenden Kapitel 2 geht es um den Nutzen von Usability Management. Usability Management hilft Ihnen, die „Total Cost of Ownership“ einer eingeführten SAP-Software zu verringern, indem es direkt die Produktivität bei der Abwicklung von Geschäftsprozessen mit SAP-Software erhöht und auf indirektem Weg die Belastungen und Beanspruchungen der Beschäftigten verringert. Auch kann Usability Management schon bei der Einführung von SAP-Software helfen, Kosten zu sparen. In Kapitel 3 erfahren Sie mehr über die Normen und Gesetze, die im Umfeld der Software-Ergonomie zu beachten sind. Ausführlicher zur Sprache kommen hier die Bildschirmarbeitsverordnung und die damit verknüpften Normen DIN EN ISO 9241-2 (Anforderungen an die Arbeitsaufgabe) und DIN EN ISO 9241-110 (Grundsätze der Dialoggestaltung). Kapitel 4 stellt Ihnen unser Vorgehensmodell zum Usability Management bei der Einführung von SAP-Software vor, gibt Ihnen einen Überblick über die Systematik, insbesondere in Beziehung zur SAP-eigenen Einführungsmethodik ASAP, erläutert die einzelnen Phasen des Modells und enthält einen Exkurs zum Thema „software-ergonomische Stellschrauben“. Die einzelnen Phasen des Usability Management bei der SAPEinführung (Projekteinstieg, Anforderungsanalyse, Sollkonzeption, Realisierung, Schulung, Go Live & Optimierung) werden in den Kapiteln 5 bis 10 vertieft. Es werden die eingesetzten Methoden vorgestellt, ihre Verknüpfung zum herkömmlichen Vorgehen bei der SAP-Einführung erläutert und anhand von Praxisbeispielen illustriert. Wenn Sie die Usability einer bereits eingeführten SAP-Software verbessern möchten, werden Sie in Kapitel 11 fündig. Unter dem Titel „Usability Care“ stellt es Ihnen Vorgehensweisen und Methoden für eine nachträgliche Optimierung von SAP-Software im Unternehmen vor. In Kapitel 12 finden Sie, noch einmal zusammengefasst, die Diskussion von sechs Erfolgsfaktoren, die aus langjähriger Beratungspraxis destilliert wurden. Sie werden vor typischen Stolperstellen gewarnt, die in SAP-Usability-Projekten auftreten können, und es werden Ihnen Lösungsansätze gezeigt. Während die vorangegangenen Kapitel die Verbesserung der Usability durch das SAP-Anwenderunternehmen selbst zum Thema hatten, stellt Ihnen Kapitel 13 vor, wie der Hersteller, die SAP 13

1 Usability bei SAP-Projekten AG, vorgeht, um die Usability schon bei der Entwicklung neuer Softwarekomponenten zu berücksichtigen. Fokus auf den Prozess

Um Missverständnissen vorzubeugen, soll an dieser Stelle ausdrücklich darauf hingewiesen werden, dass das Buch den Prozess des Usability Management zum Inhalt hat und daher keine einzelnen Usability-Regeln (z. B. zur Farbgebung, Iconauswahl, optischen Gestaltung von Dialogfenstern etc.) oder inhaltliche Empfehlungen für die Anpassung der SAP-Software (z. B. detaillierte Vorgaben zu Customizing-Einstellungen) enthält. Einen Überblick über solche Regeln finden Sie in Abschnitt 6.2.3 unter der Überschrift „Anforderungen aus ergonomischen Guidelines und Normen“. Die bisherigen Ausführungen – insbesondere die beiden eingangs geschilderten Beispiele – haben Ihnen vielleicht schon eine Idee davon vermittelt, warum Sie überhaupt Usability Management betreiben sollten. Betrachten wir dies doch noch genauer.

1.4

Business Case für Usability Management Wollen Sie Usability Management erfolgreich einsetzen, hilft es, vorher einen Business Case aufzustellen, d. h., Kosten und Nutzen abzuschätzen und dies als Entscheidungsgrundlage zu nehmen, für welche Geschäftsprozesse, Benutzer und Organisationseinheiten Usability Management nutzbringend eingesetzt werden kann.

1.4.1

Nutzen

Produktivität erhöhen

Wie bereits dargestellt, riskieren Sie ohne Usability Management eine unzureichende Usability, also eine schlechte Passung zwischen den Aufgaben, den Benutzern und der SAP-Software im Unternehmen – und damit auch eine geringere Produktivität, z. B. durch mehr Fehler oder längere Bearbeitungszeiten. Usability Management hilft also, die Produktivität zu verbessern, indem Effektivität und Effizienz der Aufgabenbearbeitung verbessert werden und die Zufriedenheit und die Motivation der Benutzer steigen. Vertreter der SAP AG selbst berichten von einem Einsparpotenzial in Höhe von bis zu 65 % bei guter gegenüber schlechter Usability – unter Berücksichtigung der mit einer Applikation möglichen betriebswirtschaftlichen Lösung – in Unternehmen (vgl. Gillar, 2004). Warum das so ist, wird in Kapitel 2 detailliert erläutert und an Beispielen veranschaulicht.

Folgekosten vermeiden

Unzureichende Usability bringt neben den Kosten reduzierter Produktivität oft ungeplante weitere Folgekosten mit sich, sei es,

14

1.4 Business Case für Usability Management dass schlechte Benutzbarkeit die Kosten für Benutzerschulungen und Support in die Höhe treibt, sei es, weil teure Nachbesserungen an der SAP-Software unumgänglich werden. Ebenso können unnötige Folgekosten entstehen, weil durch mangelnde Usability die Belastungen der Benutzer so zunehmen, dass der Krankenstand deutlich erhöht wird. Usability Management hilft also, solche vermeidbaren Folgekosten einer SAP-Einführung einzusparen, indem erforderliche Anpassungen frühzeitig vorgenommen werden und die Arbeit mit der Software möglichst belastungsarm gestaltet wird. Auch dazu erfahren Sie mehr in Kapitel 2. Rechtssicherheit erhöhen

Außerdem verhilft Ihnen Usability Management zu mehr Rechtssicherheit. Der Gesetzgeber hat eine gesetzliche Verpflichtung erlassen, die Arbeit mit Software so zu gestalten, dass sie Benutzer nicht schädigt oder beeinträchtigt, sondern ihnen Entwicklungsmöglichkeiten eröffnet. Um das Ziel effektiver, effizienter, zufriedenstellender und belastungsarmer Arbeit zu konkretisieren, wurden spezielle Gestaltungsnormen entwickelt, die mit Hilfe von Usability Management erfüllt werden können. Mehr über die gesetzlichen Grundlagen und Nomen, denen Sie mittels Usability Management Rechnung tragen können, erfahren Sie in Kapitel 3. Wie Sie sehen, hat Usability Management einen beträchtlichen Nutzen. Welche Kosten sind zu kalkulieren, wenn Sie Usability Management einsetzen?

1.4.2

Kosten Da wären zunächst die direkten Kosten zu nennen, die durch das Usability Management entstehen.

Direkte Kosten

Die direkten Kosten von Usability Management-Maßnahmen bei einem SAP-Projekt werden immer von den konkreten Projektbedingungen und dem vereinbarten Projektplan (vgl. Kapitel 5) abhängen. Daraus leiten sich die Personalkapazitäten (z. B. für Projektmitarbeiter, Benutzer, externe Berater) ab, die für bestimmte Aktivitäten benötigt werden. Die direkten Kosten sind dann relativ gut im Voraus abschätzbar. In Software-Entwicklungsprojekten, die Usability Aktivitäten beinhalten, liegt der Anteil der Usability am Gesamtbudget etwa bei 10 % (vgl. Nielsen, 2003, für eine Studie über 863 Projekte). Allerdings sollte in SAP-Einführungsprojekten der Usability-Anteil an den Gesamtkosten weitaus niedriger sein, da die in SAP definierten „Best Practice“-Lösungen oft schon als Richtlinie für die Anpassung dienen können.

Releasefestigkeit

Die direkten Kosten für Usability-Aktivitäten sind oft weniger das Problem als die gefürchteten möglichen Folgen, die eine Ände15

1 Usability bei SAP-Projekten rung der SAP-Software mit sich bringen könnte. „Releasefestigkeit“ ist hier das Stichwort, denn oft ist den Verantwortlichen nicht klar, welche Veränderungen der Software beim Einspielen eines neuen SAP-Release bestehen bleiben, welche eventuell aufwändig nachprogrammiert werden müssen und ob nicht vielleicht sogar Probleme mit der neu eingespielten Software entstehen. Oft befürchtet man hier eine Kostenfalle unklaren Ausmaßes und ein nicht endendes Abhängigkeitsverhältnis zu Anbietern und Beratern. Um dem zu entgehen, wird in einigen Unternehmen grundsätzlich versucht, die Arbeit an die unveränderten Standardfunktionalitäten der SAP-Software anzupassen, und dabei werden alle Probleme in Kauf genommen, die dies für die Arbeitsorganisation, die Produktivität, die Produktqualität bis hin zur Veränderung der Unternehmenskultur mit sich bringen kann. Spektrum von Anpassungen

Das Risiko einer „Abweichung vom Standard“ wird jedoch von vielen Unternehmen falsch eingeschätzt, weil sie irrtümlich die Mehrzahl der Anpassungen als „Abweichung vom Standard“ interpretieren. Dabei hat der Hersteller SAP AG explizit unterschiedliche Anpassungsmöglichkeiten der Software vorgesehen. Von Anpassungsmöglichkeiten für die Benutzer am individuellen Arbeitsplatz über Customizing-Maßnahmen zur Tabellenpflege und Customer-Exits für zusätzliche Programmentwicklungen bis hin zu Modifikationen, die tatsächlich eine Veränderung des Standardprogramms bedeuten. Häufig sind Anpassungen releasefest und ohne großen Aufwand durchzuführen. Unsere Erfahrung zeigt, dass gerade software-ergonomische Anpassungen (so genannte „ergonomische Stellschrauben“ – s. Kapitel 4) meist nur wenig Aufwand verursachen, gleichzeitig aber einen hohen Nutzen für die Usability liefern. Wenn unklar ist, ob Anpassungen releasefest sind oder nicht und welchen Aufwand sie mit sich bringen, sollte also im Zweifelsfall zunächst die Einschätzung eines SAP-Beraters eingeholt werden, bevor sie generell abgelehnt werden. Wenn der Nutzen hoch genug ist, können unter Umständen sogar Modifikationen sinnvoll sein, die auf jeden Fall eine „Abweichung vom Standard“ bedeuten. Der nachträgliche Aufwand, der durch Modifikationen am Standard entsteht, kann sehr unterschiedlich hoch sein und sollte im Verhältnis zum Nutzen abgewogen werden. Wie bereits erwähnt, deutet der Trend darauf hin, dass in Zukunft SAP-Software noch flexibler wird und Änderungen schneller und kostengünstiger möglich werden. Dadurch werden auch Anpassungen leichter handhabbar als bisher.

16

1.4 Business Case für Usability Management

1.4.3

Abwägen des Kosten-Nutzen-Verhältnisses Ein Abwägen des Kosten-Nutzen-Verhältnisses wird allerdings nicht immer leicht sein. Einerseits lassen sich Kosten und finanzieller Nutzen von Maßnahmen des Usability Management nicht immer handfest messen, da sich im betriebspraktischen Kontext häufig Effekte verschiedener Maßnahmen überlagern und sich gegenseitig beeinflussen sowie Langzeitwirkungen oftmals schwer abschätzbar sind. So sind beispielsweise die eingesparten Kosten der durch gute Usability von Anfang an vermiedenen Fehler meist kaum zu quantifizieren. Außerdem dürfen Nutzenerwägungen nicht auf unmittelbare finanzielle Einsparungen reduziert werden. Auch andere positive Effekte müssen berücksichtigt werden; so könnte beispielsweise eine gute Usability dazu führen, das Image des Unternehmens zu verbessern, weil sie schnellere und bessere Dienstleistungen für den Kunden ermöglicht. Es lassen sich demnach keine generellen Einschätzungen des Kosten-Nutzen-Verhältnisses von Usability Management-Projekten aufstellen. Stattdessen müssen Sie jeweils für Ihr konkretes SAP-Projekt das Kosten-Nutzen-Verhältnis einschätzen und optimieren. Die detaillierte Beschreibung von Maßnahmen zum Usability Management sowie die Praxisbeispiele in den nachfolgenden Kapiteln helfen Ihnen, vor dem Hintergrund Ihrer betrieblichen Situation zu bestimmen, welcher Aufwand für Usability Management z. B. bei einem bestimmten Geschäftsprozess notwendig ist, welcher Nutzen zu erwarten ist und wie das Kosten-Nutzen-Verhältnis optimiert werden kann. Für die Beschreibung weiterer Usability-Fallstudien und Business Cases lohnt sich auch ein Blick in die Bücher von. Bias & Mayhew (1994, 2005).

Faustregeln zum Einsatz von Usability Management

Im Allgemeinen können Sie jedoch folgende Faustregeln im Hinterkopf behalten: Der größte Nutzen von Usability Management wird immer dann erzeugt, wenn es um zentrale Geschäftsprozesse geht. Was „zentral“ bedeutet, lässt sich dabei quantitativ oder qualitativ bestimmen. Bei der quantitativen Sicht geht es um Abläufe, die von sehr vielen Benutzern durchgeführt werden und täglich mehrere Male wiederholt werden. Beispiele sind Buchungsprozesse, die mehrfach am Tage durchgeführt werden müssen, Rechnungsstellung oder die Zeitdatenerfassung in einem ESS-System (Employee Self Service). Zeiteinsparungen bei solchen „Massenprozessen“ multi17

1 Usability bei SAP-Projekten plizieren sich mitunter zu enormen Werten, so dass sich Investitionen in Usability Management immer auszahlen werden. Werden diese Kernprozesse dagegen im Usability Management vernachlässigt, kann das ein Unternehmen viel Zeit, Geld und möglicherweise auch Kunden kosten. Die qualitative Sicht schaut eher auf kritische Prozesse, seien sie kritisch aufgrund von Qualitätsanforderungen (z. B. fehlerfreie Datenerfassung), aufgrund von Sicherheitsanforderungen (z. B. Prozesse mit hohen finanziellen Risiken) oder aufgrund strategischer Überlegungen (z. B. die Kostenführerschaft im Markt durch möglichst schlanken Auftragsdurchlauf zu erreichen). Besonders bei strategisch wichtigen Geschäftsprozessen stellt sich die Frage, ob mit der Anwendung des SAP-Standards – der ja auch den Wettbewerbern zur Verfügung steht – strategische Vorteile tatsächlich realisiert und damit Imitationsbarrieren für den Wettbewerb aufgebaut werden können. Ein großzügigerer Umgang mit Abweichungen vom SAP-Standard kann hierfür durchaus nützlich sein, wenn dafür eine für das Unternehmen passend zugeschnittene, effizient zu benutzende Software herausspringt (s. dazu auch die Diskussion bei Schwarz, 2000). Aber auch Geschäftsprozesse, die in Arbeitskontexten mit Extremanforderungen an die Benutzer abgewickelt werden, in denen die Arbeit mit der SAP-Software nur eine Aufgabe unter vielen ist, profitieren von Usability Management. Dies betrifft vor allem Arbeitskontexte mit Zeitdruck, mit häufig wechselnden Anforderungen, mit zahlreichen Unterbrechungen beispielsweise durch Kundenkontakt sowie Bereiche mit hoher Mitarbeiterfluktuation, beispielsweise in Call-Centern oder Medienagenturen. Gerade bei letzteren können durch eine ergonomisch gestaltete Software massiv Kosten im Trainings- und Supportbereich eingespart werden. Darüber hinaus verspricht Usability Management immer dann einen großen Nutzen, wenn man schon von Anfang an davon ausgeht, dass die eigenen Geschäftsprozesse mit keiner SAP-Standardlösung vollständig abgedeckt werden können, SAP-Software aber aus anderen Gründen dennoch eingesetzt werden soll. Usability Management kann in solchen Fällen eine Menge dazu beitragen, durch effektive Anpassungen der SAP-Software eine optimierte betriebsspezifische Lösung zu entwickeln. Für die Zukunft lässt sich festhalten, dass durch die kontinuierlich steigende Flexibilität der SAP-Software und die zunehmenden Freiheitsgrade bei der Auswahl der gewünschten SAP-Funk18

1.5 An wen wendet sich dieses Buch? tionalitäten (z. B. durch NetWeaver und xApps) auf der einen Seite auch die Komplexität der Planungs- und Anpassungsprozesse auf der anderen Seite steigt. Usability Management wird daher zunehmend an Bedeutung gewinnen. Es kann im Unternehmen helfen, Anforderungen für den Anpassungsbedarf aufgrund tatsächlicher Arbeitsabläufe zu ermitteln, und Unsicherheiten hinsichtlich der konkreten Anpassung nehmen.

1.4.4

Der richtige Zeitpunkt für Usability Management Zu welchem Zeitpunkt in einem SAP-Projekt kann Usability Management überhaupt eingesetzt werden? Usability Management lässt sich zu verschiedenen Zeitpunkten einsetzen:

1.5

•

Schon vor Beginn des eigentlichen Einführungsprojekts zur Implementierung von ERP-Software können Sie Usability Management in einem so genannten „Discovery & Evaluation“Projekt einsetzen, in dem Sie die Anforderungen an eine Software definieren, noch bevor Sie sich für einen Anbieter entscheiden. Dafür sind besonders Vorgehensweisen aus den Phasen „Anforderungsanalyse“ (Kapitel 6) und „Sollkonzeption“ (Kapitel 7) zu empfehlen, mit deren Hilfe Sie frühzeitig feststellen können, ob SAP-Software überhaupt für die Lösung der Anforderungen in Ihrem Unternehmen in Frage kommt.

•

In einem Einführungsprojekt zur Implementierung von SAPSoftware kann Usability Management entweder von Anfang an oder auch zu einem späteren Zeitpunkt angewandt werden. Ist das SAP-Projekt beispielsweise bereits bis in die Phase „Realisierung“ fortgeschritten, können Sie Usability Methoden aus den Phasen „Realisierung“ (Kapitel 8) sowie „Go Live & Optimierung“ (Kapitel 10) anwenden.

•

Ist die SAP-Software in Ihrem Unternehmen bereits ohne Usability Management eingeführt worden, empfiehlt sich ein Vorgehen nach „Usability Care“ (Kapitel 11).

An wen wendet sich dieses Buch? Jeder, der mit der Einführung von SAP-Software in Organisationen zu tun hat, sollte wissen, warum Usability wichtig ist, was Usability Management bedeutet und wie man dabei vorgeht. Dementsprechend gibt es für dieses Buch verschiedene Zielgruppen mit unterschiedlichen Interessensschwerpunkten:

19

1 Usability bei SAP-Projekten

20

•

IT-Projektleiter, denen eine SAP-Einführung bevorsteht und für die Usability / User Productivity ein wichtiges Ziel darstellt: Sie können sich informieren, welche Vorteile Usability Management bietet, welches Vorgehen empfehlenswert ist, welche Werkzeuge Sie einsetzen können und was von Seiten des Managements für den Projekterfolg getan werden kann.

•

Betriebs- und Personalräte, für die das Thema Usability vor allem hinsichtlich der (positiven) Auswirkungen auf die Arbeitsbedingungen der Beschäftigten von Interesse ist: Sie erhalten Informationen über den rechtlichen Rahmen, über das Vorgehen bei der Umsetzung und darüber, welche Unterstützung der Betriebs- bzw. Personalrat dabei bieten kann.

•

Projektmitarbeiter in SAP-Einführungsprojekten, die für die konkrete Umsetzung von Usability-Maßnahmen im Einführungs- oder Veränderungsprojekt verantwortlich sind: Sie können sich hier – mit Praxisbeispielen illustriert – Hintergrund- und Methodenwissen aneignen sowie Anregungen für die eigene Arbeit holen.

•

SAP-Berater, deren Kunden Usability nachfragen: Sie erhalten vor dem Hintergrund Ihrer eigenen Erfahrungen im Projektmanagement neue Anregungen, indem Sie hier alle Phasen des Einführungsprojektes konsequent aus dem Blickwinkel der Benutzerorientierung und damit auch der User Productivity betrachtet finden. Außerdem erfahren Sie, wie sich Usability Management in das herkömmliche Vorgehen bei der SAP-Einführung (nach ASAP) integrieren lässt.

•

Sicherheitsbeauftragte und Betriebsärzte, die oftmals für die praktische Umsetzung des Arbeitsschutzgesetzes und der Bildschirmarbeitsverordnung im Unternehmen verantwortlich sind: Sie erhalten das erforderliche Wissen über Methoden und Vorgehensweisen, um diesen Aufgaben gerecht zu werden.

•

Usability-Berater: Sie können die Anwendung von Usability Methoden in einem in der Branche bisher relativ wenig beachteten Anwendungsfeld studieren und entsprechend Ihre Betätigungsfelder erweitern.

•

Lehrende, die IT-Professionals, aber auch Fachverantwortliche (z. B. Personal- oder Produktionsleiter) der Zukunft ausbilden: Sie können das Buch als Lehrmaterial in Ihrem Unterricht nutzen.

1.6 Zusammenfassung und Ausblick •

1.6

Verantwortliche für die Einführung von Software, die nicht zu den SAP-Produkten gehört: Sie können die dargestellten Informationen auf Ihre eigene Situation übertragen, denn Usability Management kann grundsätzlich bei jeder im Unternehmen anzupassenden Software eingesetzt werden.

Zusammenfassung und Ausblick Nachdem Sie erfahren haben, was die Begriffe Usability und Usability Management bedeuten sowie warum und wann sich der Einsatz von Usability Management bei SAP-Projekten lohnen kann, gab dieses Kapitel eine Übersicht über den Aufbau und die Zielgruppen des Buches. Im nächsten Kapitel finden Sie eine genauere Betrachtung des Nutzens von Usability Management für die Produktivität in SAP-Anwenderunternehmen. Jörn Hurtienne, Petra Abele und Jochen Prümper

21

2

Produktivitätsfaktor Usability Management Im vorigen Kapitel haben Sie erfahren, was wir unter „Usability Management bei SAP-Projekten“ verstehen. In diesem Kapitel möchten wir Ihnen erläutern, warum Usability Management sinnvoll ist und welche Vorteile es den Unternehmen und ihren Beschäftigten bringt. Warum sollten Sie Usability Management betreiben? Was bringt es, die SAP-Software benutzungsfreundlich zu gestalten? Mehrere Gründe sprechen dafür. Hier sind sie auf einen Blick kurz zusammengefasst, in den folgenden Abschnitten dieses Kapitels werden sie näher beleuchtet: •

Usability Management erhöht die Produktivität Nach der Anwendung von Usability Management arbeiten die Benutzer nicht nur effektiver und effizienter, sondern auch zufriedener.

•

Usability Management spart Kosten bei der Einführung Wenn der Fokus bereits früh im Einführungsprojekt auf der Benutzungsfreundlichkeit des Systems liegt, können Unternehmen Kosten für Training, Dokumentation und kostspielige Änderungen sparen.

•

Usability Management verringert Stress Ein benutzungsfreundlich gestaltetes System führt zur Verringerung der Belastungen (wie Zeitdruck, Arbeitsüberlastung, Einengung des Handlungsspielraumes) und deren negativer Folgen für die Beschäftigten.

2.1

Usability Management erhöht die Produktivität

Total Cost of Ownership

Unternehmen achten nicht nur auf die Kosten, die der Kauf der Softwarelizenz und der Hardware sowie die Einführung der Software verursachen, sondern verfolgen mehr und mehr den Ansatz des Total Cost of Ownership (TCO), bei dem sämtliche Kosten berücksichtigt werden, die durch den Besitz und den Gebrauch des Systems entstehen. Hierzu zählen neben technisch bedingten Kosten wie den Anpassungskosten bei einem Releasewechsel auch die Arbeitskosten, die das System verursacht. 23

2 Produktivitätsfaktor Usability Management DIN EN ISO 9241-11

In den nachfolgenden Abschnitten betrachten wir die Auswirkungen von Usability Management auf die Produktivität bei der Nutzung von SAP-Software. Dabei orientieren wir uns an den drei Kriterien der internationalen Norm DIN EN ISO 9241-11 (Ergonomische Anforderungen für Bürotätigkeiten mit Bildschirmgeräten, Anforderungen an die Gebrauchstauglichkeit – Leitsätze): •

Verbesserung der Effektivität;

•

Verbesserung der Effizienz;

•

Erhöhung der Zufriedenheit der Benutzer.

In den folgenden Abschnitten definieren wir diese Kriterien und erläutern sie anhand von Beispielen aus der SAP-Anwendungspraxis. Außerdem zeigen wir, wie diese Kriterien die Produktivität der Arbeit mit SAP-Software beeinflussen.

2.1.1

Verbesserung der Effektivität

Genauigkeit und Vollständigkeit

Effektivität ist in der Norm DIN EN ISO 9241-11 definiert als die Genauigkeit und Vollständigkeit, mit der Benutzer ein bestimmtes Ziel erreichen. Kann ein Benutzer mit der SAP-Software sein Ziel nicht erreichen, fehlt jegliche Effektivität. Teilweise muss er zur Lösung seiner Aufgabe auf andere Software-Programme zurückgreifen oder z. B. Berechnungen mit dem Taschenrechner durchführen. Mangelnde Effektivität erzeugt erheblichen Mehraufwand für Benutzer und damit Kosten (vgl. Kasten 2.1). Usability Management kann bereits während der Einführung von SAP-Software Probleme mit der Effektivität frühzeitig abfangen. So werden zu Beginn des Projektes die Aufgaben und Ziele der Benutzer analysiert. Die sich daraus ergebenden Anforderungen an Genauigkeit und Vollständigkeit der Zielerreichung werden dann als ergonomische Ziele festgelegt und mittels Prototyping überprüft. Falls erforderlich, können Effektivitätsprobleme auch noch nach dem Produktivstart der SAP-Software behoben werden.

24

2.1 Usability Management erhöht die Produktivität Kasten 2.1: Herr Bauer und die Bundesknappschaftsbescheinigungen Problem Herr Bauer arbeitet in der Personalabteilung eines Energieversorgers. Zu seinen Aufgaben gehört es, den Beschäftigten Bescheinigungen für Krankenkassen, Arbeitsämter etc. auszustellen. Normalerweise dauert das Erstellen solcher Bescheinigungen jeweils etwa zwei Minuten. Besonders die Erstellung von Bescheinigungen für die Bundesknappschaft oder für Unterhaltszahlungen ist kompliziert, da diese nicht im System hinterlegt sind. Diese Bescheinigungen erstellt Herr Bauer mühsam in MS Word. Das heißt, er trägt die betreffenden Daten aus mehreren SAP-Masken, dem Lohnkonto etc. per Hand zusammen und trägt sie in eine MS Word-Vorlage ein. Dies dauert jeweils etwa 17 Minuten und ist höchst fehleranfällig. Lösungsweg Bescheinigungen, die in der SAP-Software nicht hinterlegt sind, können nachträglich als Report angelegt werden. In unserem Beispiel wurde die Bescheinigung für die Bundesknappschaft in die SAP-Software eingepflegt und ist nun als Report für Herrn Bauer verfügbar. Ergebnis Usability Management ermöglicht die Erfüllung von Arbeitsaufgaben, die vorher nicht mit dem System erledigt werden konnten. Herr Bauer spart beim Erstellen jeder dieser Bescheinigungen 15 Minuten und kann in dieser Zeit andere Aufgaben bearbeiten, die er sonst erst am nächsten Tag angefasst hätte.

2.1.2

Verbesserung der Effizienz

Aufwand zur Zielerreichung

Effizienz ist in der internationalen Norm DIN EN ISO 9241-11 definiert als der im Verhältnis zur Genauigkeit und Vollständigkeit eingesetzte Aufwand, mit dem Benutzer ein bestimmtes Ziel erreichen. Der Aufwand wird dabei beispielsweise gemessen in Form von •

Zeit, die für die Aufgabenlösung gebraucht wird, bzw. der Zeitanteil für produktive Tätigkeit im Gegensatz zur Fehlerbehebungszeit; 25

2 Produktivitätsfaktor Usability Management •

Kosten für Material und Personal, die bei der Aufgabenbearbeitung entstehen;

•

physischem Aufwand in Form der Häufigkeit von Klickzahlen, Länge der Mauswege etc.;

•

psychischem Aufwand in Form von mentalem Aufwand z. B. für Berechnungen, Aufmerksamkeit, Konzentration auf die Arbeitsaufgabe oder in Form von emotionalem Aufwand wie Ärger, Frustration oder Langeweile.

Usability Management hat Auswirkungen auf alle diese Aufwandsarten und damit auf die Effizienz und Produktivität der SAP-Benutzung. Das Beispiel in Kasten 2.2 zeigt, wie sich anhand einer einfachen Veränderung in den Customizing-Einstellungen – hier das Ausblenden überflüssiger Eingabefelder – der Arbeitsaufwand verringert. Dies betrifft nicht nur den zeitlichen Aufwand und damit den Aufwand in Kosten, sondern auch den physischen und psychischen Aufwand für die Beschäftigten. Kasten 2.2: Viele Tastendrücke für Frau Beier Problem Frau Beier arbeitet in der Personalabteilung eines Stahlwerkes. Sie pflegt für die von ihr betreuten Mitarbeiter u. a. Prämien und weitere Zulagen in die SAP-Software ein. So erhalten Mitarbeiter z. B. eine Prämie für das Führen von hochliegenden Kranen, die als „Sonstige Prämien/Zulagen“ verschlüsselt ist. Abbildung 2.1 zeigt die Maske, die Frau Beier für ihre Eingaben nutzt. Nach der Eingabe der Anzahl der Stunden muss sie mit der Tabulatortaste mehrere nie genutzte Felder überspringen, um zu dem Feld zu gelangen, in dem die Prämienart eingegeben wird. Dies kostet unnötig Zeit, macht mehr Aufwand und ärgert Frau Beier. Das Arbeiten mit der Maus lehnt Frau Beier ab, da das Umgreifen von der Tastatur zur Maus und wieder zurück noch aufwändiger ist als das mehrmalige Drücken der Tabulatortaste. Lösungsweg Überflüssige Felder, die für die Arbeit nicht benötigt werden, können in den SAP-Customizing-Einstellungen (Erweiterte Tabellenpflege) durch einfaches Setzen eines Attributes in einer Tabelle ausgeblendet werden. In unserem Beispiel wurden in der Tabelle T588M die Felder „Anzahl/Einheit“, „Betrag“, 26

2.1 Usability Management erhöht die Produktivität „Währung“, „Aufgeld/Bewertung“, „Tarifgruppe/Stufe“, „Planstelle/Arbeitsplatz“ und „MehrVerrechnungsart“ ausgeblendet.

Abbildung 2.1: Verringerte Effizienz durch überflüssige Felder in einer Maske (Beispiel). Die Pfeile zeigen den Tabulatorweg durch die Maske an, der jedes Mal erfolgen muss. Ergebnis Wie Abbildung 2.2 auf der nächsten Seite zeigt, ist der Tabulatorweg nach dem Ausblenden überflüssiger Felder viel kürzer: Frau Beier muss jetzt nur noch 4-mal statt 15-mal die Tabulatortaste betätigen (geringerer physischer Aufwand). Jede Prämieneingabe verkürzt sich damit um drei Sekunden (weniger Zeit). Rechnet man diesen Effekt hoch auf die Einsparung für alle Prämieneingaben von Frau Beier am Tag, die Arbeitstage im Jahr und die Anzahl weiterer Benutzer mit gleichen Aufgaben, spart allein die Änderung dieses kleinen Problems Geld – zumal das Problem recht schnell behebbar ist (geringere Kosten). Darüber hinaus muss Frau Beier nicht mehr aufpassen, dass sie den Cursor bei mehrmaligem Betätigen der Tabulatortaste im richtigen Feld platziert. Dadurch macht sie weniger Fehler und ist erheblich weniger verärgert, wenn wieder einmal am Ende der Woche ein Stapel von Prämienzetteln zu bearbeiten ist (geringerer psychischer Aufwand). 27

2 Produktivitätsfaktor Usability Management

Abbildung 2.2: Verbesserte Effizienz nach dem Ausblenden überflüssiger Felder (Beispiel). Die Pfeile zeigen den verkürzten Tabulatorweg durch die Maske an. Der in Kasten 2.2 geschilderte Fall steht stellvertretend für viele kleine Umständlichkeiten, die den Benutzern nach der Einführung von SAP-Software die Arbeit unnötig erschweren. Und es gibt viele dieser kleinen Effizienzmängel, deren Effekte sich aufsummieren und die sich über die Anzahl der Wiederholung der Arbeitsaufgaben und der betroffenen Benutzer multiplizieren. Usability Management beseitigt derartige Effizienzeinbußen und steigert die Produktivität der Benutzer. Fehler

Effizienz zu steigern bedeutet aber nicht nur, Informationen auffindbar zu machen und Abläufe zu vereinfachen, sondern auch, kostspielige Fehler zu verringern. Im Kasten 2.3 ist ein Beispiel für einen Fehler bei der Arbeit mit SAP angegeben. Die Sachbearbeiterin, Frau Müller, hat das Ziel die Mehrarbeitszeiten für die von ihr betreuten Mitarbeiter korrekt in das System einzupflegen. Dieses Ziel erreicht sie nicht, da sie sich bei der Eingabe der Arbeitszeit vertippt und den Vorgang abspeichert. Dabei wäre dieser Fehler durchaus vermeidbar gewesen.

28

2.1 Usability Management erhöht die Produktivität Kasten 2.3: Kleiner Vertipper mit großen Folgen Problem Frau Müller pflegt für die Mitarbeiter eines Verlages Mehrarbeitszeiten und Prämien ein. Wenn Frau Müller für einen Tag aus Versehen mehr als zehn Stunden Arbeitszeit eingibt, gibt das System keine Fehlermeldung. Dadurch werden Prämien zuviel bezahlt, die – wenn der so beschenkte Mitarbeiter sich nicht von selbst meldet – nicht wieder rückgängig gemacht werden. Selbst wenn der Fehler entdeckt wird, ist der Korrekturaufwand sehr hoch, gerade dann, wenn die Prämie bereits ausgezahlt wurde. Lösungsweg Für Eingaben in das Datenfeld „Anzahl Stunden“ wird eine Plausibilitätskontrolle eingerichtet. Wenn der eingerichtete Grenzwert (hier zehn Stunden) überschritten wird, präsentiert das System die Warnmeldung „Sie haben mehr als zehn Stunden Mehrarbeitszeit eingegeben. Bitte überprüfen Sie Ihre Eingabe.“ Ergebnis Das Einfügen einer Plausibilitätskontrolle für das Feld „Anzahl Stunden“ hilft Fehler bei der Eingabe von Prämien zu vermeiden. Die Gehälter der Mitarbeiter werden dadurch korrekt ausgezahlt. Zusätzlich entfällt der Aufwand für die Korrektur solcher Fehler, an der sonst mehrere Personen beteiligt wären. Fehlervermeidung

Eine systemseitige Strategie der Fehlervermeidung wird im Beispiel in Kasten 2.3 angesprochen: Es wird eine Plausibilitätskontrolle für das Feld „Arbeitszeit“ eingeführt. In diesem Fall ist auch eine personelle Strategie der Fehlervermeidung denkbar: Frau Müller wird angewiesen, bei der Eingabe der Mehrarbeitszeiten zunächst alle Eingaben zu überprüfen und dann erst auf „Speichern“ zu drücken. Da Usability Management aber nicht davon ausgeht, dass sich der Benutzer auf die Vermeidung von Fehlern konzentrieren sollte, versucht es systemseitige Lösungen zur Fehlervermeidung anzubieten. Das Beispiel im Kasten 2.3 deutet auch darauf hin, dass einmal gemachte Fehler häufig nur unter großem Aufwand wieder rückgängig gemacht werden können. Der Psychologe Brodbeck (1991) hat herausgefunden, dass Benutzer immerhin 10 % ihrer Zeit am Computer damit verbringen, Fehler zu bewältigen. Dass

29

2 Produktivitätsfaktor Usability Management dies die Effizienz der Arbeit stark beeinträchtigt, ist wohl nicht von der Hand zu weisen. Fehlermanagement

Möchte man die Effizienz der Nutzung verbessern, sind also neben Strategien zur Fehlervermeidung auch Strategien zum Fehlermanagement gefragt. Ist ein Fehler einmal aufgetreten, so soll der Benutzer ihn möglichst einfach entdecken und auch wieder korrigieren können – und dies, ohne erst ein Handbuch aufschlagen zu müssen. In unserem Beispiel in Kasten 2.3 fehlen Funktionen, mit denen Fehler einfach entdeckt und korrigiert werden können. Dazu gehört eine Transaktion, mit der Frau Müller ihre Eingaben überprüfen kann, und eine weitere Transaktion, mit der sie die Fehleingabe korrigieren kann und die automatisch den zu viel gezahlten Betrag mit der nächsten Lohnabrechnung verrechnet. Usability Management erhöht die Effizienz der Benutzung. Dabei gilt ebenso wie bei der Verbesserung der Effektivität: Maßnahmen zum Usability Management dürfen nicht erst nach dem Produktivstart der Software ergriffen werden. Sie sollten bereits während der Einführung stattfinden. Hier hilft Usability Management z. B. durch die Bereitstellung software-ergonomischer Regeln Effizienzeinbußen zu verhindern. Durch Benutzertests an Prototypen deckt Usability Management mangelnde Effizienz auf. Nach einer Anforderungsanalyse wird in einem Sollkonzept festgelegt, welche Aufgabenbearbeitungszeiten, Kosten sowie physische und psychische Aufwände nicht überschritten werden dürfen.

2.1.3

Erhöhung der Zufriedenheit

Zufriedenheit und Akzeptanz

Die Norm DIN EN ISO 9241-11 definiert Zufriedenheit als das Fehlen von Beeinträchtigungen und als positive Einstellung gegenüber der Nutzung des Produktes. Hier spielen die subjektive Wertschätzung des Produktes und die Akzeptanz bei der Ausführung verschiedener Aufgaben eine Rolle. Einen Eindruck von der Zufriedenheit der Benutzer bekommt man, wenn man auf die positiven und negativen Äußerungen zur Nutzung achtet. Ebenso ist auch ein Blick auf Langzeitwirkungen nötig, wie z. B. die Häufigkeit der Systemnutzung oder gar den Wunsch von Benutzern, Aufgaben zu verändern. Zufriedenheit und Produktivität hängen auch an SAP-Arbeitsplätzen eng zusammen. Knauer (2000) berichtet im SPIEGEL von einer repräsentativen Studie des Computerherstellers Compaq 1999 unter 1255 PC-Nutzern in britischen Firmen, nach der

30

2.1 Usability Management erhöht die Produktivität Zufriedenheit • und Produktivität

fast ein Viertel der Befragten mindestens einmal am Tag wegen eines Computerproblems die Arbeit unterbrechen musste,

•

jeder Zweite Zeitverluste durch Abstürze und Fehler des Systems beklagte,

•

zwei Fünftel der Befragten den Computerjargon in Anleitungen und Betriebshandbüchern kritisierten und

•

Benutzer häufig mit „Fluchen, Schlagen oder Stecker ziehen“ auf störrische Informationstechnologie am Arbeitsplatz reagierten.

Wie mangelnde Effizienz einer SAP-Software zur Unzufriedenheit der Benutzer führt und wie diese wiederum ein geplantes SAPRollout ins Stocken bringen und zu enormen Mehraufwänden führen kann, ist in Kasten 2.4 beschrieben. Kasten 2.4: Mangelnde Zufriedenstellung ist teuer Problem Bei einem Dienstleistungsunternehmen wurde im Rahmen der Ablösung eines Altsystems in 30 von ca. 200 Filialen SAP R/3 pilotartig eingeführt. Obwohl sich im Vergleich zum Altsystem die Funktionalität kaum veränderte, war die SAP-Software im Gegensatz zum Altsystem sehr durch betriebswirtschaftliche Begriffe und Prozessdefinitionen geprägt, die im realen Arbeitsalltag gar nicht vorkamen: Statt von Kunden wurde jetzt von „Debitoren“ geredet, eine simple „Abrechnung“ wurde zur „Auftragsrückmeldung“. Früher gaben die Beschäftigten Art und Umfang der erbrachten Dienstleistungen selbst in das Altsystem ein und rechneten diese dann direkt im Anschluss mit den Kunden ab. Obwohl keine grundlegend anderen Daten eingegeben werden mussten, verlangte die neue SAP-Software viele zusätzliche Schritte, z. B. das Anlegen, Rückmelden und Abschließen eines Kundenauftrags. Alle diese Zusatzschritte trieben den Verwaltungsaufwand derart in die Höhe, dass die Abrechnung der Dienstleistungen nun nicht mehr unmittelbar nach der Erbringung am gleichen Tag erledigt werden konnte. Inzwischen hatte sich für die Beschäftigten so viel Arbeit angestaut, dass die Abrechnungen erst vier bis sechs Wochen später erstellt werden konnten. Dies hatte nicht nur wirtschaftliche Konsequenzen (verspätete Rechnungsstellung), sondern wirkte sich durch die daraus resultierende – und in den Augen der Mitarbeiter unnötige – Mehrarbeit stark beeinträchtigend auf die Motivation 31

2 Produktivitätsfaktor Usability Management und Zufriedenheit aus. Viele der Pilotfilialen gingen sogar dazu über, Abrechnungen – entgegen der Anweisung der Geschäftsführung – wieder mit dem alten System durchzuführen. Der Stress und die Unzufriedenheit der Beschäftigten mit der neuen SAP-Software wuchsen an – die Mitarbeiter ließen sich häufiger krankschreiben. Infolge dieser Entwicklung verlangte der Betriebsrat die Einstellung des SAP-Projektes. Da die SAPEinführung aber von der Geschäftsführung bereits mit hohen Investitionen vorangetrieben worden war und andere Organisationseinheiten bereits mit anderen Modulen von SAP arbeiteten, weigerte sie sich, das Projekt zu beenden, und hielt an der geplanten Breiteneinführung für die übrigen Filialen fest. Lösungsweg In dieser Situation griff der Betriebsrat ein. Aufgrund der Gesundheitsgefahren für die Beschäftigten nutzte er seine Mitbestimmungsrechte und erzwang eine Einigungsstelle unter Vorsitz eines Arbeitsrichters. Mehrere Gutachten wurden beauftragt, die den desolaten Stand des Projektes bestätigten. Unter Hinzuziehung eines Usability-Beraters einigte man sich auf die Erstellung von so genannten „Schnellerfassungsmasken“, die die Schritte „Auftrag anlegen“, „Auftrag ändern“, „Auftrag rückmelden“ und „Auftrag abschließen“ automatisieren und die Arbeit damit radikal vereinfachten. Die Schnellerfassungsmasken wurden unter Einbezug von Benutzern entwickelt und im System produktiv geschaltet. Ergebnis Die einberufene Einigungsstelle verursachte direkte Kosten in Höhe von einigen hunderttausend Euro und verzögerte das Projekt um ein halbes Jahr. Tests ergaben, dass die Benutzer mit den Schnellerfassungsmasken ähnlich schnell arbeiteten wie mit dem Altsystem. Aufgrund dieser Ergebnisse wurde die Breiteneinführung von SAP R/3 wie geplant durchgeführt. Die SAP-Benutzung läuft heute nahezu reibungslos. Die Geschäftsführung nahm diese Erfahrung zum Anlass, andere Probleme bei der Einführung von SAP ernst zu nehmen, und startete zu diesem Zweck ein eigenes Projekt zum Usability Management.

32

2.2 Usability Management spart Kosten bei der Einführung Das Beispiel im Kasten 2.4 zeigt, wie wichtig es ist, bereits in den frühen Phasen der Einführung von SAP auf die Faktoren zu achten, die die Zufriedenheit der Benutzer beeinträchtigen können. Beim Usability Management werden Anforderungen an die Zufriedenstellung der Benutzer ermittelt und Zufriedenheitsziele für die Gestaltung der SAP-Software definiert. Bereits vor der Produktivsetzung wird die Zufriedenheit der Benutzer mit dem System überprüft, um durch mögliche Gegenmaßnahmen Verminderungen der Zufriedenstellung effektiv auffangen zu können. Die vorangehenden Abschnitte zeigten, dass Usability Management die Effektivität und Effizienz der Benutzung von SAP-Software erhöht und auch die Zufriedenheit der Benutzer steigert. Wichtig ist dabei, die Usability-Aktivitäten frühzeitig in ein SAPEinführungsprojekt aufzunehmen. Während die bisher betrachteten Produktivitätssteigerungen erst nach dem Produktivstart (Go Live) des Systems zum Tragen kommen, erklärt der nächste Abschnitt, wie Usability Management hilft, Kosten bereits direkt im Einführungsprojekt einzusparen.

2.2

Usability Management spart Kosten bei der Einführung Nicht erst nach der Produktivsetzung des Systems, sondern bereits während der Einführung von SAP-Software kann Usability Management Nutzen erzeugen. Auf den ersten Blick erzeugt Usability Management bei der Einführung von SAP-Software zusätzliche Arbeit. Benutzer müssen in die Projektaktivitäten eingebunden werden, Arbeitsanalysen werden durchgeführt, das Sollkonzept wird abgestimmt und bereits realisierte Teilprozesse werden mit den Benutzern getestet. Wie kann Usability Management dazu führen, dass der Einführungsprozess dennoch vereinfacht wird? Wie kann Usability Management dazu beitragen, im Endeffekt sogar Kosten zu sparen? Zwei Wirkungen von Usability Management wollen wir in diesem Abschnitt näher betrachten: zum einen die Vereinfachung von Training und Support, zum anderen das frühzeitige Erkennen von Anforderungen.

33

2 Produktivitätsfaktor Usability Management

2.2.1

Vereinfachung von Training und Support Durch die konsequente Ausrichtung der Systemgestaltung auf den Benutzer, seine Arbeitsaufgabe und den Nutzungskontext der Software kann Usability Management dazu beitragen, Arbeitsabläufe im System möglichst einfach zu gestalten.

Erlernbarkeit

Wenn SAP-Software einfach benutzbar wird, schlägt sich das auch auf die Erlernbarkeit nieder. Eine leichtere Erlernbarkeit der Software wiederum verringert den Aufwand für die Benutzerschulung bei der Einführung und hat Auswirkungen auf den Aufwand für die Erstellung und den Umfang der notwendigen Trainingsunterlagen und Benutzungshandbücher. Zum Beispiel berichtet Thomas K. Landauer (1995) von der Universität Colorado von einer Reduktion der Schulungszeiten um 25 % durch die Anwendung ergonomischer Maßnahmen bei der Software-Entwicklung. Der Effekt von reduzierten Schulungszeiten wird naturgemäß größer, je mehr Fluktuation unter den Benutzern einer Software herrscht, z. B. in einem Call-Center bei Benutzern von SAP CRM – Customer Relationship Management. Reduzierte Schulungszeiten wirken sich natürlich umso mehr aus, je größer die Anzahl der Benutzer eines SAP-Modules ist, vgl. z. B. SAP HR für die Mitarbeiter in der Personalwirtschaft versus SAP ESS – Employee Self Service für alle Beschäftigten eines Unternehmens.

Supportkosten

Ein einfaches und benutzungsfreundlich gestaltetes System senkt auch den Aufwand für den Support. Dies betrifft einerseits die direkten Supportkosten, z. B. für Hotline und Nachschulungen, andererseits indirekte Kosten, die von anderen Quellen herrühren. Was die direkten Kosten betrifft, so zählte die Norwich Union (eine Versicherungsgesellschaft in Australien) zwei Drittel weniger Anrufe in der Hotline nach Verbesserung einer Kernanwendung durch benutzerzentrierte Entwicklungstechniken (Computerworld, 1995). Zum anderen verringert ein benutzungsfreundlich gestaltetes System auch die indirekten Supportkosten. Dazu gehören versteckte Kosten, die durch verlorene Produktivität entstehen, etwa wenn sich die Mitarbeiter gegenseitig Tipps bei Computerproblemen geben. In einer Studie fanden Catherine Ko und Margaret A. Hurley (1995) heraus, dass pro Arbeitsplatz etwa 10.000 Dollar für Wartung und Support aufzuwenden sind. Etwa die Hälfte dieser Kosten entstehen aufgrund verlorener Produktivität durch die Unterstützung der Mitarbeiter untereinander. Haupteinflussfaktor

34

2.2 Usability Management spart Kosten bei der Einführung war dabei die Qualität der Benutzungsoberfläche. Durch Usability Management können auch solche indirekten Kosten verringert werden.

2.2.2

Frühzeitiges Erkennen von Anforderungen Nur ein Fünftel der Kosten, die nach dem Produktivstart einer Software entstehen, fallen für die Beseitigung von Programmierfehlern (Bugs) und Zuverlässigkeitsproblemen an, vier Fünftel dagegen aufgrund nicht erfüllter oder nicht erkannter Benutzeranforderungen (Karat, 1993). Deshalb sollte man so früh wie möglich versuchen, Benutzer im Sinne des Usability Management mit einzubeziehen und Methoden der ergonomischen Anforderungsanalyse anzuwenden (mehr zu diesem Thema lesen Sie in Kapitel 6). Je später eine neue Anforderung von Benutzern bekannt wird, desto teurer wird ihre Umsetzung. Je nachdem, in welcher Phase sich ein SAP-Einführungsprojekt bereits befindet, wenn eine neue Anforderung auftaucht, ist es unterschiedlich aufwändig, diese Anforderung umzusetzen. Schon eine kleine Anforderung wie ein zusätzliches Eingabefeld kann viel Aufwand verursachen, wenn sie erst spät erkannt wird. Daher ist das frühzeitige Entdecken von Benutzeranforderungen ein positiver Effekt von Usability Management. Pascal Mangold (2004) berichtet von einer altbekannten Faustregel unter Software-Entwicklern, die besagt, dass die Kosten für Änderungen einer Software sich von Stufe zu Stufe eines Projektes verzehnfachen. Die Mechanismen dieser Kostenexplosion zeigt das Beispiel in Kasten 2.5. Kasten 2.5: Ein kleines Eingabefeld mit großen Folgen Problem Bei der Einführung von SAP-Software bei einem Zeitungsverlag stellt sich heraus, dass Mitarbeiter die Möglichkeit haben, eine der im Unternehmen produzierten Zeitungen kostenfrei zu beziehen. Als Anforderung wird formuliert: Ein entsprechender Vermerk soll im SAP HR-System hinterlegt werden. Dazu ist ein zusätzliches Eingabefeld nötig. Bearbeitung in der Blueprint-Phase Wird bei der Anforderungsanalyse oder der Erstellung des Sollkonzepts (Business Blueprint) festgestellt, dass ein Feld fehlt, so lässt sich dieser Mangel durch eine kleine Änderung 35

2 Produktivitätsfaktor Usability Management des Anforderungsdokumentes beheben. Das Feld wird eingefügt, seine Abhängigkeiten beschrieben, eine neue Version des Dokumentes erzeugt und allen Projektmitgliedern verfügbar gemacht. Bearbeitung während der Realisierung Wird das Fehlen des Feldes in der Phase der Realisierung entdeckt, müssen bereits entworfene Masken, Zugriffsfunktionen, bereits fertig gestellte und getestete Module geändert und nochmals getestet werden. Wenigstens die Testspezifikation muss erweitert werden. Die Änderung kann nachträgliche Fehler mit sich bringen, deren Beseitigung und erneutes Testen einige Zeit kostet. Die Dokumentation muss nachgepflegt werden. Zusätzlich müssen bereits abgestimmte und vom Unternehmen abgenommene Projektbausteine neu definiert und nochmals freigegeben werden. Bearbeitung nach dem Go Live Ist das System bereits fertiggestellt und die Anforderung wird jetzt erst entdeckt, müssen einige Schritte des Einführungsprojektes unter Umständen noch einmal ganz von vorn ausgeführt werden. Möglicherweise müssen bereits importierte Daten nochmals importiert, in eine inzwischen neue Struktur konvertiert und manuell bereinigt werden. Vielleicht ist damit eine bereits durchgeführte manuelle Datenbereinigung umsonst gewesen. Das momentan unvollständige neue System muss mangels Alternative bereits trotzdem benutzt werden. Ist die Anforderung im System implementiert, müssen die Mitarbeiter informiert werden, das Handbuch und die Schulungsunterlagen müssen aktualisiert werden. Bei größeren Änderungen wird eine Nachschulung fällig. In unserem Beispiel ist das Eingabefeld „Mitarbeiterzeitung“ unmittelbar nach dem Go Live noch nicht vorhanden und wird jetzt nachprogrammiert. In der Zwischenzeit führt die Personalabteilung Excel-Listen über die Mitarbeiter, die eine Zeitung abonniert haben. Diese Daten müssen später migriert werden. Das Beispiel mit dem Eingabefeld in Kasten 2.5 ist bewusst einfach gewählt: Prinzipiell gilt das Gesagte für neue Anforderungen jeder Art – und natürlich umso mehr, je komplexer nachträgliche Anforderungen sind.

36

2.3 Usability Management verringert Stress Kostenexplosion

Zusätzlich zu den in Kasten 2.5 dargestellten Mechanismen der Kostenexplosion müssen weitere Aspekte in Betracht gezogen werden: •

Je später eine Änderung im Projektverlauf erfolgt, desto höher potenziert sich die Anzahl an Schnittstellen, Einstellungen und Modifikationen, die geändert werden müssen.

•

Erfolgt die Fehlerbehebung in der Implementierungs- oder Wartungsphase, wird hochqualifiziertes Fachpersonal gebunden, das eigentlich bereits für andere Aufgaben eingeplant war: Unter Umständen müssen externe Ressourcen teuer hinzugekauft werden.

•

Betreffen die neuen Anforderungen grundlegende Systemeigenschaften, resultiert dies in „Anbauten“ an das System, die spätere Updates und Veränderungen erschweren können.

•

Fehlende Funktionen und nicht berücksichtigte Benutzeranforderungen bei der Einführung der Software führen zu Produktivitätsverlusten bei der Arbeit mit dem System und nachfolgend erhöhten Aufwendungen für Dokumentation, Schulung und Support.

Es zeigt sich also, dass Usability Management durch die Vereinfachung von Training und Support sowie durch das frühzeitige Erkennen von Anforderungen Kosten bei der Einführung von SAPSoftware spart. Neben diesen ökonomischen Vorteilen hat Usability Management auch – wie der folgende Abschnitt zeigt – positive Auswirkungen auf die Gesundheit der Benutzer.

2.3

Usability Management verringert Stress Die Produktivität von Unternehmen hängt nicht zuletzt von der Zufriedenheit und dem Wohlbefinden ihrer Mitarbeiter ab. In diesem Abschnitt erläutern wir, wie Usability Management zur Verringerung von Belastung und Beanspruchung beitragen und damit Wohlbefinden und Zufriedenheit steigern kann. Die Beispiele in den Kästen 2.6 und 2.7 zeigen, wie SAP-Software bei den Benutzern zu Belastung und Beanspruchung führen kann und wie Usability Management dabei hilft, diese zu verringern. In Kasten 2.6 sehen Sie, wie bereits vorhandene Belastungen eines Benutzers (Zeitdruck) durch eine ungenügende Gestaltung der SAP-Software zu noch größeren Belastungen führen können (rechtliche Konsequenzen durch das Vergessen von Eingaben).

37

2 Produktivitätsfaktor Usability Management Kasten 2.6: Stress mit der Terminverfolgung Problem Herr Bauer ist in einem Verlag für die Einstellung neuer Mitarbeiter zuständig. Dies erfolgt mit SAP R/3 HR durch die Maßnahme (Maskenfolge) „Einstellung neuer Mitarbeiter“. Nach der Eingabe der Probezeit des neuen Mitarbeiters öffnet sich automatisch das Bild „Terminverfolgung“. Hier kann Herr Bauer das Ende der Probezeit als Termin setzen. Obwohl weitere Termine eingegeben werden müssen (tarifliche Umstufung, Neuausgabe der Sicherheitsschuhe, Gehöruntersuchung), kommt die Maske „Terminverfolgung“ in der Maßnahme nicht wieder vor. Herr Bauer muss sich diese Termine merken und später außerhalb der Maßnahme per Hand nachpflegen. Da Herr Bauer durch seine weiteren Aufgaben unter Zeitdruck steht, kann er schnell vergessen, diese Termine nachzupflegen. Wenn die Termine aber bei Fälligkeit aufgrund der fehlenden Eingabe nicht wahrgenommen werden, kann dies für die Firma nachteilige rechtliche Konsequenzen haben. Wenn dies passiert, ist Herr Bauer als zuständiger Sachbearbeiter verantwortlich. Dies bedeutet vermehrten Stress für Herrn Bauer und stellt hohe Anforderungen an seine Konzentrationsfähigkeit. Lösungsweg Fehlende Masken in einer Transaktion können durch Customizing hinzugefügt werden. In die Maßnahme „Einstellung neuer Mitarbeiter“ werden mehrere Masken (Infotypen) „Terminverfolgung“ für die Eingabe weiterer Termine eingefügt. Ergebnis Nach der ergonomischen Anpassung ist eine aufgabenangemessene Bearbeitung der Maßnahme möglich. Herr Bauer kann weitere Termine innerhalb der Maßnahme „Einstellung neuer Mitarbeiter“ eingeben, und, vor allem, kann er die Eingabe der Termine nicht so leicht vergessen. Das führt zu weniger Konzentrations- und Gedächtnisaufwand. Herr Bauer muss sich nicht davor fürchten, bei der Einstellung eines Mitarbeiters Fehler zu machen und deren Folgen „ausbaden“ zu müssen. Das Beispiel in Kasten 2.7 zeigt, welche Schwierigkeiten sich für eine Organisation ergeben, wenn die SAP-Software nur ungenügend an die Arbeitstätigkeit der Benutzer angepasst ist. 38

2.3 Usability Management verringert Stress Kasten 2.7: Fehlbelastungen reduziert Problem Die Einführung eines SAP-Moduls in einer öffentlichen Verwaltung führte zu einem enormen Eingabeaufwand für die betroffenen Beschäftigten. Die Eingabe der gleichen Daten beanspruchte mit SAP doppelt so viel Zeit wie im Vorgängersystem. Viele Akten blieben liegen. Die spontane Reaktion in vielen Zweigstellen der Verwaltung war darauf eine neue Arbeitsteilung. Beschäftigte, die sonst beides, Arbeit am Kunden (dem Bürger) und interne Verwaltungstätigkeit, ausführten, spezialisierten sich nun entweder auf reine Verwaltungstätigkeit mit der SAP-Software oder auf reine Arbeit am Kunden. Für die Mitarbeiter, die nur noch mit der SAP-Software arbeiten mussten, bedeutete dies eine Einschränkung der Vielseitigkeit ihrer Tätigkeiten und eine 100%ige Arbeit am Computer mit überwiegend sitzender Tätigkeit. Nicht zuletzt drohte eine Herabstufung im Gehalt, da sie ja nur noch „Sachbearbeitertätigkeiten“ durchführten und keine anspruchsvollen Aufgaben. Lösungsweg Radikale Vereinfachungen erfordern manchmal die Abweichungen vom SAP-Standard. In unserem Beispiel wurden die SAP-Eingabemasken radikal vereinfacht. Einige Eingabeschritte wurden auf einer Maske zusammengefasst, andere automatisiert. Von vormals 13 Prozessschritten blieben fünf zur Bearbeitung übrig. Ergebnis Der Effekt der Usability-Maßnahme war eine drastische Verkürzung der erforderlichen Eingabezeiten, so dass die SAP-Tätigkeiten nach und nach wieder an alle Mitarbeiter verteilt wurden und kein Mitarbeiter mehr zu 100 % mit (einseitiger) Verwaltungsarbeit belastet war. Alle Mitarbeiter hatten wieder eine gemischte Tätigkeit, die Arbeit am Bildschirm und Arbeit am Kunden umfasste. Damit reduzierten sich die Belastungen und Beanspruchungen der Beschäftigten. Die Beispiele in Kasten 2.6 und Kasten 2.7 zeigen, wie sich Belastungen und Beanspruchungen durch Usability Management positiv beeinflussen lassen. In den folgenden Abschnitten stellen wir den Zusammenhang zwischen „Belastung“ und „Beanspruchung“ dar und zeigen, wie

39

2 Produktivitätsfaktor Usability Management Usability Management zur Verringerung von beidem beitragen kann.

2.3.1

Belastung und Beanspruchung

Stress

Das, was allgemein als „Stress“ bezeichnet wird, gliedern Wissenschaftler in die Konzepte von „Belastung“ und „Beanspruchung“. Danach wird unter „Belastung“ die Gesamtheit aller erfassbaren Einflüsse, die von außen auf den Menschen zukommen und auf ihn einwirken, verstanden. „Beanspruchung“ dagegen ist die Auswirkung der Belastungen auf den Menschen (vgl. Semmer & Udris, 2004). Diese Definition ist bewusst neutral gehalten, da Belastungen und Beanspruchungen auch positiv erlebt werden können. Im Folgenden wollen wir uns jedoch den negativen Aspekten zuwenden und sehen, wie sie mit Hilfe von Usability Management vermieden werden können.

Belastung

Zu den Belastungen, denen Benutzer von Computerprogrammen – so auch Benutzer von SAP-Software – ausgesetzt sein können, gehören •

körperliche Belastungen, wie stark repetitive, also sich in kurzen Abständen wiederholende Bewegungen der Finger, der Hand, des Armes und der Schulter bei der Eingabe von Daten; Bewegungsmangel aufgrund sitzender Tätigkeit; Belastung der Augen;

•

Belastungen aus der Arbeitsumgebung, wie mangelhafte Lichtverhältnisse, schlechtes Klima, Lärm, ungünstige Beschaffenheit der Räumlichkeiten;

•

Belastungen, die aus den Arbeitsinhalten, aus der Arbeitsaufgabe und der Arbeitsorganisation resultieren; wie Zeitdruck, hohe Konzentrationsanforderungen, organisatorische Probleme, Arbeitsunterbrechungen, monotone Arbeit, hohe Verantwortung für Personen oder für Sachwerte;

•

soziale und emotionale Belastungen wie fehlende soziale Unterstützung von Kollegen oder Vorgesetzten;

•

Belastungen, die aus den organisatorischen Rahmenbedingungen resultieren, wie mangelnde Anerkennung, schlechte Informations- und Lohnpolitik, eingeschränkte Aufstiegsmöglichkeiten, Arbeitsplatzunsicherheit.

Beanspruchungen Belastungen, wie sie hier aufgelistet sind, können sich im Alltag der SAP-Benutzer als Beanspruchungen auswirken. Einen Über-

40

2.3 Usability Management verringert Stress blick über verschiedene Wirkungsebenen von Beanspruchungen sowie ihre kurz- und langfristigen Folgen gibt Tabelle 2.1. Wirkung auf

kurzfristige Folgen

langfristige Folgen

Körper

erhöhte Pulsfrequenz, Steigerung des Blutdrucks

psychosomatische Beschwerden, organische Krankheiten

Erleben

Anspannung, Frustration, Ärger, Gereiztheit, Ermüdung, Monotonie

Ängstlichkeit, Depressivität, Burn-Out, Arbeitsunzufriedenheit

Verhalten

Leistungsschwankungen, Nachlassen der Konzentration, Fehler, Konflikte, Streit, Aggression

Fehlzeiten, erhöhter Medikamenten-, Alkohol- und Nikotinkonsum

Tabelle 2.1:

Ressourcen

Verschiedene Arten von Beanspruchungen, sowie ihre kurz- und langfristigen Auswirkungen (in Anlehnung an Kaufmann, Pornschlegel & Udris, 1992 und Zapf & Dormann, 2001)

Bei gleicher Belastung können Menschen unterschiedlich beansprucht sein. Menschen unterscheiden sich nämlich darin, inwieweit sie Belastungen bewältigen können. Wissenschaftler sprechen dabei von Ressourcen, die dem Menschen zur Verfügung stehen. Zu den Ressourcen zählen: •

Ressourcen, die in der Situation vorhanden sind, wie Handlungsspielraum oder soziale Unterstützung durch Kollegen und Vorgesetzte;

•

Ressourcen, die in der Person liegen, wie Qualifikation, Problemlösekompetenz, Bewältigungsstrategien oder soziale Kompetenzen.

Gibt es Benutzungsprobleme mit der SAP-Software, kann man z. B. mit Benutzerschulungen die Ressourcen „Qualifikation“ und „Problemlösekompetenz“ erhöhen. Geschulte Anfänger, die wissen, wie sie bestimmte Probleme mit der Software lösen können, werden sich weniger oft über die Software ärgern als Anfänger, die bestimmte Tricks und Kniffe nicht kennen. Der Zusammenhang zwischen Belastungen, Beanspruchungen und Ressourcen ist in Abbildung 2.3 wiedergegeben.

41

2 Produktivitätsfaktor Usability Management

Abbildung 2.3:

Zusammenhang zwischen Belastung, Beanspruchung und Ressourcen

Die Einführung eines neuen Arbeitsmittels wie SAP-Software hat fast immer einen Einfluss auf Belastungen und Beanspruchungen der Mitarbeiter. Die Anpassung und Gestaltung von SAP ist zugleich auch immer eine Gestaltung der Arbeit, die Mitarbeiter in einem Unternehmen verrichten müssen. Dessen müssen sich Projektleiter, SAP-Berater und alle Teammitglieder bewusst sein. Usability Management versucht als ganzheitlicher Ansatz diesen Blickwinkel in das SAP-Einführungsprojekt zu bringen. Bei grundlegenden Problemen mit Beanspruchungen und Belastungen in der Organisation empfiehlt es sich, ein eigenes Projekt zur Organisationsentwicklung anzustoßen, das sich primär mit betrieblicher Gesundheitsförderung beschäftigt. Bei einer SAP-Einführung sollte man sich frühzeitig um Fragen der Belastung und Beanspruchung kümmern. Ein Ansatz dazu ist Usability Management, dessen Vorteile im Folgenden dargestellt werden.

2.3.2

Usability Management verringert Belastungen Auf einige der Belastungsarten aus dem obigen Abschnitt hat Usability Management durch die Erstellung von benutzungsfreundlicher SAP-Software direkten Einfluss, auf andere Belastungsfaktoren wirkt Usability Management indirekt. Diese direkten und indirekten Wirkungen werden im Folgenden erläutert. Direkte Wirkungen auf körperliche Belastungen

Repetitive Tätigkeiten

42

Durch eine gute software-ergonomische Gestaltung der SAP-Software kann – gerade für stark repetitive Tätigkeiten – die Anzahl von Bedienungsschritten wie Tastendrücke, Mausklicks etc. verringert werden (s. dazu das Beispiel im Kasten 2.2). Dies beugt

2.3 Usability Management verringert Stress u. a. Beanspruchungsfolgen wie RSI (Repetitive Strain Injury, auch als „Mausarm“ bekannt) vor. Direkte Wirkungen auf Belastungen aus der Arbeitsaufgabe und der Arbeitsorganisation Usability Management berücksichtigt die Arbeitsaufgabe, die Benutzer und den Nutzungskontext, in dem SAP-Software eingesetzt wird. Durch eine gute Anforderungsanalyse und eine aufgabenangemessene wie benutzergerechte Gestaltung kann die Software negative Belastungen aus der Arbeitsaufgabe und der Arbeitsorganisation verringern helfen. Unterbrechungen

Negative Belastungen können durch zu häufige Unterbrechungen der konzentrierten Bearbeitung der Aufgaben durch Telefon, Kunden oder Kollegen entstehen. Sie können dadurch abgefangen werden, dass Arbeitsaufgaben bzw. -teilaufgaben schnell und einfach mit dem System zu bearbeiten sind und die Software möglichst viel Kontextinformation bereitstellt, z. B. darüber, welche Aufgaben schon abgeschlossen sind, welche Teilschritte noch gelöst werden müssen etc. Entscheidend ist dabei, dass Benutzer unterbrochene Arbeitsprozesse am System nach einer Unterbrechung leicht wieder aufnehmen und zu Ende führen können.

Konzentrationsanforderungen

Eine ergonomisch gut gestaltete SAP-Software hilft auch, die Konzentrationsanforderungen der Arbeit zu senken, indem sie möglichst alle Informationen bereithält, die in der jeweiligen Situation benötigt werden, und diese auch so aufbereitet darbietet, dass sie einfach gelesen werden können. Eine benutzungsfreundliche Software erfordert per se keine hohen Konzentrationsleistungen, denn sie ist so gestaltet, dass Benutzer sie gebrauchen können, ohne sich an komplizierte Wege und Bearbeitungsweisen erinnern zu müssen. Eine „möglichst intuitive Bedienung“ ist hier das Schlagwort. Schließlich kann Usability Management dazu beitragen, dass durch Software Probleme des Zeitdruckes gelindert werden, indem es die Bearbeitung bestimmter Aufgaben vereinfacht oder automatisiert. Direkte Wirkungen auf soziale Belastungen

Kommunikations- Usability Management deckt durch die Analyse der Benutzeranhürden forderungen auch Kommunikationshürden zwischen einzelnen Rollen und Abteilungen auf. Solche Hürden können durch entsprechende Gestaltung der SAP-Software abgebaut werden. Un-

43

2 Produktivitätsfaktor Usability Management ter anderem wird dies bei der Vergabe von Berechtigungen oder der Gestaltung der Workflow-Funktionalität berücksichtigt. Usability Management sieht den Test integrierter Teilprozesse vor, der genau solche Hindernisse in der Kommunikation und Kooperation aufdeckt (mehr zum „Test integrierter Teilprozesse“ finden Sie in Kapitel 8). Indirekte Wirkungen auf Belastungen Usability Management kann auch indirekt negative Belastungen reduzieren. Durch die Anforderungsanalyse, wenn sie direkt am Arbeitsplatz des Benutzers durchgeführt wird, können wertvolle Hinweise zur Gestaltung von Arbeit und zur Arbeitsteilung gesammelt werden. Die daraus abgeleiteten Anforderungen werden in ergonomische Ziele umgesetzt und im Sollkonzept festgeschrieben. Das Beispiel in Kasten 2.7 macht klar, dass die Gestaltung von SAP-Software einen Einfluss auf die Arbeitsbedingungen (hier Arbeitsorganisation) hat.

2.3.3

Usability Management vermehrt Ressourcen Usability Management wirkt auch auf die Bildung von Ressourcen, die Beschäftigten helfen, besser mit negativen Belastungen umzugehen.

Qualifikation als Ressource

Eine bedeutende Ressource ist Qualifikation. Je besser die Benutzer über SAP-Software und ihre Arbeitsaufgaben Bescheid wissen, desto besser sind ihre Bewältigungsfähigkeiten bei auftauchenden Problemen. Usability Management trägt dem Rechnung, indem es einerseits eine fortlaufende Qualifizierung aller Projektmitglieder vorsieht, andererseits aber auch Lernsysteme bereithält, die frühzeitig das Wissen über die neue SAP-Software unter allen Beschäftigten verbreiten (mehr zu dem Konzept von „Lernsystemen“ finden Sie in Kapitel 9). Die beiden Beispiele in Kasten 2.8 und Kasten 2.9 zeigen zwei weitere Maßnahmen des Usability Management zur Förderung der Ressourcen von Beschäftigten.

Tipps & TricksSchulung

44

Das erste Beispiel in Kasten 2.8 erläutert die Tipps & Tricks-Schulung, in der die Benutzer Hinweise zur effizienteren Benutzung der SAP-Software erhalten.

2.3 Usability Management verringert Stress Kasten 2.8: Tipps & Tricks-Schulung stärkt Ressourcen Problem In SAP-Software sind einige Funktionen implementiert, mit denen sich die Benutzer das System an ihre Arbeitsaufgaben und Bedürfnisse anpassen können. Wir nennen sie die „Stellschrauben für Benutzer“. Unter anderen gehören dazu die Möglichkeiten, Favoriten mit den am häufigsten benutzten Transaktionen einzurichten, persönliche Wertelisten für Eingabefelder zu erstellen, Tabelleneinstellungen den eigenen Bedürfnissen entsprechend einzurichten, benutzerspezifische Vorbelegungen von Eingabefeldern zu definieren, Varianten für Berichte abzuspeichern u. v. m. Bei einer Umfrage unter SAP-Benutzern in einem stahlverarbeitenden Betrieb stellte sich heraus, dass vielen Benutzern einige dieser Funktionen schlichtweg nicht bekannt waren und sie dadurch die Vorteile bei der Arbeit gar nicht nutzen konnten. Lösungsweg Indem man Benutzer darin qualifiziert, sich die SAP-Software selbst nach ihren Bedürfnissen einzustellen, kann eine wirkungsvolle Ressource geschaffen werden. Im Rahmen unserer Usability-Projekte führen wir mit den Benutzern halbtägige Tipps & Tricks-Schulungen durch, in denen Anpassungs- und Einstellungsmöglichkeiten der SAP-Software erläutert werden. Dies geschah auch in dem stahlverarbeitenden Betrieb. Ergebnis Bereits die unmittelbare Reaktion der Benutzer auf die Schulung war sehr positiv. Darüber hinaus wurde einige Monate nach der Schulung noch einmal eine Erhebung zum Lernerfolg und zur Auswirkung der Schulung auf der Verhaltensebene durchgeführt. Zur Messung des Lernerfolgs wurde u. a. noch einmal das Wissen zu den einzelnen Stellschrauben abgefragt. Nur etwa 2 % der Benutzer gaben an, die jeweiligen Stellschrauben nicht zu kennen. Bei der Erhebung der Auswirkung auf die Verhaltensebene war zu erkennen: Im Schnitt stieg der Anteil der Benutzer, der die Stellschrauben in der täglichen Arbeit nutzte, von 41 % auf 78 %, verdoppelte sich also nahezu. Als Resultat der Schulung stieg die beurteilte Individualisierbarkeit der SAP-Software um 26 %. 45

2 Produktivitätsfaktor Usability Management Benutzertreffen

Das zweite Beispiel in Kasten 2.9 schildert die Einrichtung regelmäßiger Benutzertreffen im Unternehmen, die im Sinne eines Kontinuierlichen Verbesserungsprozesses (KVP) die Ressourcen „Qualifikation“, „soziale Unterstützung“ und „Bewältigungsstrategien“ vermehren sollen. Kasten 2.9: Benutzertreffen und KVP Problem Das Modul Personalwirtschaft der SAP-Software ist bei einem Unternehmen für Haushaltsartikel auch nach der Einführung ständigen Änderungen ausgesetzt. Diese betreffen die tariflichen Vorschriften für Lohn und Gehalt genauso wie gesetzliche Vorgaben (z. B. zum Thema Altersteilzeit oder private Rentenversicherung) sowie innerbetriebliche Regelungen (Ausschüttung von Boni an die Mitarbeiter). Nicht immer sind alle Mitarbeiter der Personalabteilung über die Änderungen informiert. Nicht immer ist nach der Implementierung dieser Änderungen der Test so gründlich gewesen, dass es im laufenden Betrieb keine Probleme mit der Abrechnung gegeben hätte. Oftmals führte das zu Frustration und Mehrarbeit bei den Beschäftigten. Das Klima zwischen der technischen Abteilung – zuständig für die Änderungen – und der fachlichen Abteilung, die mit diesen Änderungen arbeiten musste, war frostig. Lösungsweg Durch die Einrichtung geeigneter Kommunikations- und Kooperationsstrukturen können Verständigungsprobleme zwischen einzelnen Organisationseinheiten verhindert werden. Zwischen technischer und fachlicher Abteilung wurden im Sinne eines Kontinuierlichen Verbesserungsprozesses wöchentlich stattfindende Benutzertreffen eingerichtet, in denen die neuen Änderungen vorgestellt und auftretende Probleme besprochen werden konnten. Ergebnis Die Einrichtung der regelmäßigen Benutzertreffen führte nicht nur zu einem schnelleren Informationsaustausch zwischen technischer und fachlicher Abteilung, auch die Stimmung zwischen den Abteilungen verbesserte sich immens. Die wöchentlich stattfindenden Treffen dienten bald nicht nur der schnellen Qualifizierung der Teilnehmer, sondern auch der schnellen und unkomplizierten Erfassung und Umsetzung von Anforderungen der Benutzer, die nicht unmittelbar aus den Software-

46

2.3 Usability Management verringert Stress Änderungen entstanden. Die Mitarbeiter der technischen Abteilung waren froh, Rückmeldung von den Benutzern zu ihrer Arbeit zu erhalten, entwickelten ein tieferes Verständnis für die Belange der Benutzer und konnten sich besser mit ihrer Arbeit identifizieren. Sie nannten ihr Motto selbst „im Gespräch bleiben“ – und meinten damit mit allen Beschäftigten der Personalbereiche aller mit der SAP-Software abgerechneten Unternehmen; durch die regelmäßigen Arbeitskreise mit Hilfestellungen und Demonstrationen zur optimalen Arbeit im Personalsystem, durch den Erfahrungsaustausch zu aktuellen Personalthemen, durch Schulungen zu Systemveränderungen, kurz: durch „vor Ort“-Arbeit. Die Beispiele in diesem Abschnitt zeigen, wie durch einfache organisatorische Maßnahmen (Schulung, regelmäßige Benutzertreffen) die Ressourcen der Mitarbeiter erhöht werden können. Usability Management legt deswegen auch einen Fokus auf Benutzerqualifizierung und einen Kontinuierlichen Verbesserungsprozess nach dem Go Live der SAP-Software.

2.3.4

Usability Management verringert Beanspruchungen Über die Verringerung von Belastungen und die Vermehrung von Ressourcen wirkt Usability Management auch auf die kurzund langfristigen Beanspruchungsfolgen, die bei der Arbeit mit SAP-Software auftreten können.

Gereiztheit und psychosomatische Beschwerden

In Kasten 2.10 stellen wir die Ergebnisse einer Studie vor, die untersuchte, wie sehr die Benutzungsfreundlichkeit einer Software und die kurz- und langfristigen Beanspruchungsfolgen bei den Benutzern zusammenhängen. Das Ergebnis zeigt, dass eine mangelnde Benutzungsfreundlichkeit nicht nur zu erhöhter Gereiztheit, sondern gar zu psychosomatischen Beschwerden wie Konzentrationsschwierigkeiten, Schlafstörungen, Kopfschmerzen oder empfindlichem Magen beitragen kann. Kasten 2.10: Kurz- und langfristige Beanspruchungen aufgrund mangelnder Benutzungsfreundlichkeit Eine wissenschaftliche Studie Der Haupteinfluss von Usability Management liegt in der Schaffung einer benutzungsfreundlichen SAP-Software. Wir (Hurtienne & Prümper, 2003, 2004) konnten zeigen, dass die ergonomische Qualität von Software (darunter auch SAP-Software), in direktem Einfluss zu kurz- und langfristigen Beanspruchungen der Benutzer steht. Mit dem Fragebogen der Psy47

2 Produktivitätsfaktor Usability Management chologin Gisela Mohr (vgl. Mohr, Rigotti & Müller, 2005) wurde als kurzfristige Beanspruchungsfolge die Irritation/Gereiztheit der Benutzer gemessen. Hierzu zählen Aussagen wie „Ich reagiere gereizt, obwohl ich es gar nicht will.“ oder „Es fällt mir schwer, nach der Arbeit abzuschalten.“ Als langfristige Beanspruchungsfolgen wurden psychosomatische Beschwerden erhoben (Fragebogen von Mohr, 1986). Hierzu zählen Konzentrationsschwierigkeiten, Schlafstörungen, Kopfschmerzen oder ein empfindlicher Magen. An der Studie nahmen 395 Benutzer teil. Insgesamt floss die Beurteilung von 21 SoftwarePaketen ein. Die beiden folgenden Abbildungen veranschaulichen die gefundenen Zusammenhänge.

Abbildung 2.4: Zusammenhang zwischen der ergonomischen Qualität von Software und der Irritation der Benutzer Abbildung 2.4 zeigt den Einfluss von Software mit als gering, mittel und hoch bewerteter ergonomischer Qualität (Fragebogen ISONORM 9241/10 von Prümper & Anft, 1993, und Prümper, 1997) auf die Irritation/Gereiztheit ihrer Benutzer. Deutlich ist zu sehen, dass die Irritation/Gereiztheit der Benutzer mit steigender ergonomischer Qualität der Software geringer wird. Selbst wenn man den Zusammenhang mit den langfristigen Beanspruchungsfolgen betrachtet, sieht man, dass auch hier ein kleiner, aber statistisch signifikanter Effekt der software-er48

2.4 Zusammenfassung und Ausblick gonomischen Qualität auf die psychosomatischen Beschwerden der Benutzer besteht (Abbildung 2.5).

Abbildung 2.5: Zusammenhang zwischen der ergonomischen Qualität von Software und den psychosomatischen Beschwerden der Benutzer Indem Usability Management auf die Verbesserung der Benutzungsfreundlichkeit (Effektivität, Effizienz und Zufriedenstellung) von SAP-Software ausgerichtet ist, wirkt es auch positiv auf die Beanspruchungen der Benutzer.

2.4

Zusammenfassung und Ausblick Dieses Kapitel hat gezeigt, welche Umstände zur Verringerung der Produktivität bei der Arbeit mit SAP-Software beitragen. Schlecht an die Arbeit und Organisation angepasste Software vermindert die Effektivität, Effizienz und Zufriedenheit bei der Arbeit und erhöht die Belastungen und Beanspruchungen der Mitarbeiter. Das Kapitel hat auch gezeigt, wie Usability Management zur Erhöhung der Effektivität, Effizienz und Zufriedenheit, zur Verringerung von Belastung und Beanspruchung und zum Aufbau von Ressourcen führt. Darüber hinaus hilft Usability Management durch eine frühzeitige Berücksichtigung der Benutzeranforderungen Kosten im Einführungsprozess von SAP-Software zu sparen. Ein Vorteil von Usability Management blieb noch ungenannt: Es trägt dazu bei, dass Unternehmen ihre gesetzlichen Verpflichtun49

2 Produktivitätsfaktor Usability Management gen aus der Bildschirmarbeitsverordnung (BildscharbV) erfüllen. Doch wie geht das? Ganz einfach: Usability Management gründet sich auf die Leitlinien ergonomischer Systemgestaltung, wie sie in der Bildschirmarbeitsverordnung und in einschlägigen internationalen Normen niedergelegt sind. Lesen Sie dazu mehr im nächsten Kapitel. Jörn Hurtienne und Jochen Prümper

50

3

Gesetze, Verordnungen, Normen Im vorangegangenen Kapitel haben Sie erfahren, welche Umstände die Produktivität bei der Arbeit mit SAP-Software verringern können und wie Usability Management zur Erhöhung der Effektivität, Effizienz und Zufriedenheit, zur Verringerung von Belastung und Beanspruchung und zum Aufbau von Ressourcen führen kann. Dieses Kapitel erläutert, welche Anforderungen der Gesetzesgeber an gute Software stellt und welche davon bei Usability Management relevant werden. Usability Management kommt eine zentrale Rolle zu, wenn es darum geht, gesetzliche Vorschriften beim Einsatz von SAP-Software einzuhalten. Auf diesem Weg verfolgt Usability Management auch das Ziel der menschengerechten Gestaltung der Arbeit. Unter einer menschengerechten Arbeit versteht man solche, die für den Menschen ausführbar ist, ihn weder schädigt noch beeinträchtigt und ihm Freiheiten für die Entwicklung seiner Persönlichkeit lässt. Durch Usability Management werden Software-Systeme an die physischen und psychischen Eigenschaften des Menschen angepasst. Im engeren Sinne liegt der Schwerpunkt damit auf der menschengerechten Gestaltung der Benutzungsoberfläche. Im weiteren Sinne sucht Usability Management nach organisatorischtechnischen Lösungen, um die Arbeit und die Software an menschliches Arbeitshandeln anzupassen. Für die menschengerechte Gestaltung der Mensch-Computer-Interaktion wurden deutsche und internationale Gesetze, Verordnungen und Normen formuliert, die Anforderungen an den Dialog stellen, der zwischen Benutzer (z. B. einem Sachbearbeiter) und Dialogsystem (z. B. SAP-Software) bei der Erledigung einer Arbeitsaufgabe (z. B. Anlegen von neuen Materialstammsätzen) stattfindet. Für unsere Belange sind das Arbeitsschutzgesetz (ArbSchG) und die daraus folgenden Verordnungen und Normen von besonderer Bedeutung, sie werden deshalb in den folgenden Abschnitten kurz vorgestellt. Im Einzelnen behandelt das vorliegende Kapitel:

51

3 Gesetze, Verordnungen, Normen •

Arbeitsschutzgesetz und Bildschirmarbeitsverordnung Dieser Abschnitt behandelt die grundlegenden Gesetze und Verordnungen, die beim Usability Management von SAP-Projekten zu beachten sind.

•

Behindertengleichstellungsgesetz und Barrierefreie Informationstechnik-Verordnung Barrierefreiheit und Accessibility, also die behindertengerechte Gestaltung von Informationstechnologie, gewinnen im SAP-Umfeld zunehmend an Bedeutung. Dieser Abschnitt informiert über den entsprechenden gesetzlichen Hintergrund.

•

DIN EN ISO 9241: Ergonomische Anforderungen für Bürotätigkeiten mit Bildschirmgeräten Den Schwerpunkt dieses Abschnitts bilden die Leitsätze zur Aufgabengestaltung und die Grundsätze der Dialoggestaltung. Sie werden für die Arbeit mit SAP-Software konkretisiert und mit Beispielen illustriert.

3.1

Arbeitsschutzgesetz und Bildschirmarbeitsverordnung

Arbeitsschutzgesetz

Von herausragender Bedeutung ist das Arbeitsschutzgesetz (ArbSchG), das in Deutschland als „Gesetz über die Durchführung von Maßnahmen des Arbeitsschutzes zur Verbesserung der Sicherheit und des Gesundheitsschutzes der Beschäftigten bei der Arbeit“ zur Umsetzung von EU-Richtlinien im Arbeitsschutz dient und das Ziel verfolgt, die Gesundheit aller Beschäftigten zu sichern und zu verbessern. Als eine Art „Grundgesetz des Arbeitsschutzes“ enthält das Arbeitsschutzgesetz die Ermächtigungsgrundlage zum Erlass von Verordnungen auf dem Gebiet „Sicherheit und Gesundheit bei der Arbeit“.

Bildschirmarbeits- Für Bildschirmarbeitsplätze findet das Arbeitsschutzgesetz Konkretisierung in der Bildschirmarbeitsverordnung (BildscharbV). verordnung Diese „Verordnung über Sicherheit und Gesundheitsschutz bei der Arbeit an Bildschirmgeräten“ – so der vollständige Titel – dient der Umsetzung der so genannten EG- oder EU-BildschirmRichtlinie, also der „Richtlinie des Rates vom 29. Mai 1990 über die Mindestvorschriften bezüglich der Sicherheit und des Gesundheitsschutzes bei der Arbeit an Bildschirmgeräten“ (BildschRL). In der Bildschirmarbeitsverordnung werden u. a. Vorschriften an die Softwaregestaltung formuliert, die (bis auf wenige Ausnah52

3.2 Behindertengleichstellungsgesetz men) für jeden Arbeitsplatz gelten, an dem ein Bildschirmgerät benutzt wird. Sie finden sich unter den Nummern 20 bis 22 des Anhanges zu § 4 BildscharbV: Zusammenwirken Mensch-Arbeitsmittel 20. Die Grundsätze der Ergonomie sind insbesondere auf die Verarbeitung von Informationen durch den Menschen anzuwenden. 21. Bei Entwicklung, Auswahl, Erwerb und Änderung von Software sowie bei der Gestaltung der Tätigkeit an Bildschirmgeräten hat der Arbeitgeber den folgenden Grundsätzen insbesondere im Hinblick auf die Benutzerfreundlichkeit Rechnung zu tragen: 21.1 Die Software muss an die auszuführende Aufgabe angepasst sein. 21.2 Die Systeme müssen den Benutzern Angaben über die jeweiligen Dialogabläufe unmittelbar oder auf Verlangen machen. 21.3 Die Systeme müssen den Benutzern die Beeinflussung der jeweiligen Dialogabläufe ermöglichen sowie eventuelle Fehler bei der Handhabung beschreiben und deren Beseitigung mit begrenztem Arbeitsaufwand erlauben. 21.4 Die Software muss entsprechend den Kenntnissen und Erfahrungen der Benutzer im Hinblick auf die auszuführende Aufgabe angepasst werden können. 22. Ohne Wissen der Benutzer darf keine Vorrichtung zur qualitativen oder quantitativen Kontrolle verwendet werden. Konkretisierung finden die Nummern 20 bis 22 des Anhanges zu § 4 BildscharbV in der Normenreihe DIN EN ISO 9241, die im Abschnitt 3.3 dieses Kapitels vorgestellt wird.

3.2

Behindertengleichstellungsgesetz Nach Schätzungen der World Health Organization (WHO) leben weltweit etwa 600 Millionen Menschen mit Behinderung. Allein in den USA gibt es rund 30 Millionen Menschen mit Behinderung im erwerbsfähigen Alter, in Europa sind es zwischen 17 und 24 Millionen. Insbesondere blinden und sehbehinderten Menschen erlauben die allermeisten Softwareprogramme häufig keine Nutzung in vollem Umfang. 53

3 Gesetze, Verordnungen, Normen Behindertengleichstellungsgesetz

Ziel des bundesdeutschen Gesetzes zur Gleichstellung behinderter Menschen (BGG) ist deshalb, „die Benachteiligung von behinderten Menschen zu beseitigen und zu verhindern sowie die gleichberechtigte Teilhabe von behinderten Menschen am Leben in der Gesellschaft zu gewährleisten und ihnen eine selbstbestimmte Lebensführung zu ermöglichen“ (BGG, § 1). Im Sinne des Behindertengleichstellungsgesetzes sind Dienststellen und sonstige Einrichtungen der Bundesverwaltung (also alle öffentlichen Stellen) u. a. verpflichtet, barrierefreie Informationstechnik (BGG, § 11) für Mitarbeiter und Bürger bereitzustellen. „Barrierefrei sind [...] Systeme der Informationsverarbeitung, akustische und visuelle Informationsquellen und Kommunikationseinrichtungen sowie andere gestaltete Lebensbereiche, wenn sie für behinderte Menschen in der allgemein üblichen Weise, ohne besondere Erschwernis und grundsätzlich ohne fremde Hilfe zugänglich und nutzbar sind“ (BGG, § 4).

Barrierefreie Informationstechnik

Die Verordnung zur Schaffung barrierefreier Informationstechnik nach dem Behindertengleichstellungsgesetz (BITV) ist diesem nachgeschaltet und präzisiert im Wesentlichen die Anforderungen, die sich aus dem BGG in Bezug auf barrierefreie Informationstechnik ergeben. Diese Verordnung gilt (§ 1) für 1.

Internetauftritte und -angebote,

2.

Intranetauftritte und -angebote, die öffentlich zugänglich sind, und

3.

mittels Informationstechnik realisierte grafische Programmoberflächen, die öffentlich zugänglich sind,

der Behörden der Bundesverwaltung. SAP und Accessibility

54

Obwohl SAP-Software in den seltensten Fällen öffentlich zugänglich ist, hat die SAP AG „Barrierefreiheit“ als Zukunftsthema erkannt und ein „Accessibility Competence Center“ eingerichtet. Damit möchte die SAP AG sicherstellen, dass jeder, vor allem auch Menschen mit Behinderungen, SAP NetWeaver und andere SAP-Lösungen optimal nutzen kann. Zwar stellt die SAP AG „Accessibility“ und „Barrierefreiheit“ bei der Entwicklung ihrer Software sicher, doch ist es auch bei der Einführung und Anpassung von SAP-Software in Wirtschaft und öffentlicher Verwaltung wichtig, auf diese Aspekte zu achten. Obwohl die Hauptaufgabe, Accessibility herzustellen, beim Hersteller liegt, wird Usability Management mithelfen, Accessibility-Aspekte im Rahmen der benutzer- und aufgabenzentrierten Anpassung von SAP-Software im Detail zu berücksichtigen.

3.3 DIN EN ISO 9241: Ergonomie der Mensch-System-Interaktion

3.3

DIN EN ISO 9241: Ergonomie der Mensch-SystemInteraktion Unterhalb von Gesetzen und Verordnungen gibt es Normen, die sich spezifisch mit dem Thema „Software-Ergonomie“ beschäftigen und die wichtige und zuverlässige Hinweise für die Erfüllung der Gesetze und Verordnungen geben. Von zentraler Bedeutung für das Thema „Usability Management von SAP-Software“ ist die Normenreihe DIN EN ISO 9241. Kasten 3.1 enthält eine Übersicht der bereits erschienenen Normteile. Weitere Teile, z. B. zur „Gestaltung von Benutzungsschnittstellen für das World Wide Web“ (Teil 151), zur „Barrierefreiheit von Software“ (Teil 171) und zu „Prüfverfahren zur Benutzerleistung“ (Teil 304) existieren vorerst nur als Entwurf. Kasten 3.1: DIN EN ISO 9241 Teil 1

Allgemeine Einführung

Teil 2

Leitsätze zur Aufgabengestaltung

Teil 3

Anforderungen an Bildschirmgeräte

Teil 4

Anforderungen an die Tastatur

Teil 5

Anforderungen an Arbeitsplatzgestaltung und Körperhaltung

Teil 6

Leitsätze für die Arbeitsumgebung

Teil 7

Anforderungen an visuelle Anzeigen bzgl. Reflexionen

Teil 8

Anforderungen an Farbdarstellungen

Teil 9

Anforderungen an Eingabemittel, ausgenommen Tastaturen

Teil 110 Grundsätze der Dialoggestaltung (ehemals Teil 10) Teil 11

Anforderungen an die Gebrauchstauglichkeit; Leitsätze

Teil 12

Informationsdarstellung

Teil 13

Benutzerführung

Teil 14

Dialogführung mittels Menüs

Teil 15

Dialogführung mittels Kommandosprachen

Teil 16

Dialogführung mittels direkter Manipulation

Teil 17

Dialogführung mittels Bildschirmformularen

Teil 400 Grundsätze und Anforderungen für physikalische Eingabegeräte 55

3 Gesetze, Verordnungen, Normen Die DIN EN ISO 9241 stellt Anforderungen an den Dialog, der zwischen Benutzer und Software bei der Erledigung einer Arbeitsaufgabe stattfindet. Dies umfasst Anforderungen an die •

Aufgabengestaltung, da diese den Dialog wesentlich steuert;

•

Hardwaregestaltung, da diese den Dialog wesentlich reguliert;

•

Arbeitsumgebung, da diese den Dialog wesentlich beeinflusst;

•

Softwaregestaltung, da diese den Dialog wesentlich prägt.

Daher müssen bei der Anwendung der Grundsätze zur Erreichung einer menschengerechten Dialoggestaltung stets die Merkmale des Benutzers, die Arbeitsaufgaben, die Arbeitsumgebung und die jeweils eingesetzte Hardware berücksichtigt werden. Wie den einzelnen Titeln der Norm DIN EN ISO 9241 in Kasten 3.1 zu entnehmen ist, handelt es sich lediglich beim Teil 110 und den Teilen 11-17 um software-ergonomische Normen im engeren Sinne. Bei diesen nimmt wiederum besonders Teil 110 „Grundsätze der Dialoggestaltung“ eine zentrale Position ein, da in ihm allgemeine, übergeordnete Anforderungen definiert werden, die unabhängig von der Art der Dialogführung anwendbar sind. Im nächsten Abschnitt soll es jedoch zunächst um den Hard- und Software übergreifenden Teil 2 der DIN EN ISO 9241, den „Leitsätzen zur Aufgabengestaltung“, gehen.

3.3.1

Leitsätze zur Aufgabengestaltung Arbeit besteht darin, Aufgaben auszuführen. Entscheidend für die Effizienz und Belastungsarmut der Arbeit ist damit letztlich die angemessene Gestaltung der Arbeitsaufgabe. Was dies bedeutet, ist in DIN EN ISO 9241-2 (S. 3) festgelegt: „Gleichzeitig mit ihrem Beitrag zum Hauptzweck des bildschirmgestützten Informationsverarbeitungssystems sollte eine angemessene und effiziente Gestaltung von Arbeitsaufgaben für Bürotätigkeiten“ sieben Humankriterien der Gestaltung von Arbeitsaufgaben erfüllen. Diese (vgl. Abbildung 3.1) werden im Folgenden kurz erläutert.

56

3.3 DIN EN ISO 9241: Ergonomie der Mensch-System-Interaktion

Abbildung 3.1:

Anforderungen an die Arbeitsaufgaben – Leitsätze nach DIN EN ISO 9241-2

Benutzerorientierung Die Gestaltung von Arbeitsaufgaben sollte „die Erfahrung und Fähigkeiten der Benutzergruppe berücksichtigen“. In der Forderung nach Benutzerorientierung drückt sich die Erkenntnis aus, dass es nicht „den“ Computernutzer gibt, sondern die Art und Weise des Herangehens vom jeweiligen Benutzer und seinen Kenntnissen und Erfahrungen abhängig ist. Dementsprechend sollen die Arbeitsaufgaben mit SAP-Software so gestaltet sein, dass weder Überforderung noch Unterforderung zu beeinträchtigend wirken. Eine benutzerorientierte Aufgabengestaltung bedeutet beispielsweise, dass die zu erledigenden Aufträge weder zu einfach noch zu kompliziert sind, weder zu wenig noch zu viel Arbeit vorliegt, weder Zeitdruck noch Langeweile dominiert und der Beschäftigte die in seinem Beruf und in der Ausbildung erworbenen Kenntnisse und Fähigkeiten einsetzen kann. Der Vorteil der Benutzerorientierung ist also das ausgewogene Verhältnis von Benutzereigenschaften und Aufgabenanforderungen, das zu verringerter Beanspruchung führt. Vielseitigkeit Die Gestaltung von Arbeitsaufgaben sollte „vorsehen, dass eine angemessene Vielfalt von Fertigkeiten und Aktivitäten angewandt wird“. Arbeit mit SAP-Software ist vielseitig, wenn der Benutzer ein breites Spektrum seiner Fähigkeiten und Fertigkeiten einsetzen kann. 57

3 Gesetze, Verordnungen, Normen Aufgaben gestalten sich vielseitig, wenn der Benutzer wechseln kann zwischen Routinetätigkeiten und anspruchsvollen, hohe Konzentration erfordernden Denkaufgaben; zwischen Tätigkeiten mit Bildschirmnutzung und handschriftlichen Arbeiten wie Lesen, Nachschlagen, Sortieren etc. sowie zwischen sitzender und stehender Körperhaltung. Der Vorteil der Vielseitigkeit liegt darin begründet, dass einseitige Belastungen vermieden werden. Ganzheitlichkeit Die Gestaltung von Arbeitsaufgaben sollte „sicherstellen, dass die zu erledigenden Aufgaben als ganzheitliche Arbeitseinheiten statt als Bruchstücke davon erkennbar sind“. Eine ganzheitliche Aufgabe ermöglicht dem Beschäftigten, den Anteil seiner Tätigkeit am Gesamtprodukt zu erkennen; eine Rückmeldung über den Arbeitsfortschritt ergibt sich aus der Tätigkeit selbst. Eine ganzheitliche Aufgabe umfasst planende, vorbereitende, ausführende und kontrollierende Elemente. Ganzheitliche oder vollständige Aufgaben ermöglichen selbstständiges Planen und Setzen von Zielen, die ihrerseits in übergeordnete Zusammenhänge eingeordnet werden können. Dazu gehören auch die Abstimmung mit anderen, die Kontrolle des Arbeitsergebnisses und die Eigenverantwortlichkeit für getroffene Entscheidungen. Ganzheitliche Aufgabengestaltung mit SAP-Software bedeutet beispielsweise, dass ein Benutzer selbstständig aus allgemeinen Vorgaben über Termine Teilziele wie Zwischentermine ableiten kann, selbstständig den Bearbeitungsweg wählen kann, sich selbstständig mit vor- und nachgelagerten Arbeitsbereichen abstimmt und selbstständig seine Arbeitsresultate überprüft. Der Vorteil der Ganzheitlichkeit besteht darin, dass Benutzer die Bedeutung und den Stellenwert ihrer Tätigkeit erkennen und Rückmeldung über den eigenen Arbeitsfortschritt aus der Tätigkeit selbst erhalten. Eindeutigkeit Die Gestaltung von Arbeitsaufgaben sollte „sicherstellen, dass die zu erledigenden Aufgaben einen bedeutsamen, dem Benutzer verständlichen Beitrag zur Gesamtfunktion des Systems leisten“.

58

3.3 DIN EN ISO 9241: Ergonomie der Mensch-System-Interaktion Die hier angesprochene Bedeutsamkeit und Verständlichkeit wird zum Begriff der Eindeutigkeit zusammengefasst. Eindeutigkeit liegt vor, wenn der Benutzer seine Arbeit mit SAPSoftware als notwendig, wichtig und nützlich empfindet; vorhersehen kann, welche Auswirkungen seine eigene Arbeit für die Arbeit anderer hat; genaue und durchschaubare Anweisungen für seine Arbeit erhält und ein hohes Maß an persönlicher Verantwortung für die Arbeit empfindet. Eine eindeutige Aufgabenstellung umfasst genaue Informationen über die Anforderungen wie Qualität und Menge der Arbeitsergebnisse sowie einzuhaltende Termine. Der Vorteil der Eindeutigkeit besteht darin, dass Arbeitsaufträge realistisch geplant und durchgeführt werden können und die Benutzer motivierter bei der Arbeit sind. Handlungsspielraum Die Gestaltung von Arbeitsaufgaben sollte „einen angemessenen Handlungsspielraum hinsichtlich Reihenfolge, Arbeitstempo und Vorgehensweise für den Benutzer vorsehen“. Ein Benutzer verfügt über Handlungsspielraum, wenn er über die Arbeitsweise, die verwendeten Arbeitsmittel und die zeitliche Organisation der Arbeit mit SAP-Software selbst entscheiden kann und die Möglichkeit hat, eine Situation entsprechend den eigenen Vorstellungen zu beeinflussen: beispielsweise das Arbeitstempo je nach Tagesform zu variieren; Tätigkeiten, die eine hohe Konzentration erfordern, in störungsfreien Zeiten zu erledigen u. v. m. Schon das Wissen um vorhandene Handlungsspielräume macht gelassener. Dagegen wirken einengende Vorschriften oder eine starke Abhängigkeit von den Vorgaben der SAPSoftware als Stressoren. Eine Einschränkung des Handlungsspielraums kann u. a. zu Störungen im Wohlbefinden, andauernden psychischen und körperlichen Beschwerden sowie zu einem Abbau der intellektuellen Leistungsfähigkeit führen. Der Vorteil des Handlungsspielraums besteht darin, dass Benutzer mit belastenden Situationen besser umgehen können. Als gesundheitsförderlich stellen sich SAP-Arbeitsplätze heraus, an denen die Beschäftigten über große Handlungsspielräume verfügen, d. h. eigenständig Ziele setzen, Entscheidungen treffen und Planungen entwickeln können.

59

3 Gesetze, Verordnungen, Normen Rückmeldung Die Gestaltung von Arbeitsaufgaben sollte „ausreichende Rückmeldung über die Aufgabenerfüllung in für den Benutzer bedeutsamer Weise vorsehen“. Im Rahmen der Gestaltung der Rückmeldung kann von zwei Möglichkeiten Gebrauch gemacht werden: „Rückmeldungen durch die SAP-Software“ und „Rückmeldungen durch Kollegen und Vorgesetzte“. Rückmeldungen durch die SAP-Software müssen unmissverständlich eingeordnet werden können. Der Benutzer sollte die Möglichkeit haben, diese Rückmeldungen selbst anzufordern. Konstruktive Rückmeldungen durch Kollegen und Vorgesetzte bedeuten soziale Rückendeckung. Deren Ausmaß entscheidet, inwieweit sich ein Beschäftigter auf Personen seiner Arbeitsumgebung verlassen kann. Soziale Rückendeckung ist ein wichtiger Puffer für Stress und entscheidend für die Qualität der sozialen Interaktion mit Kollegen und Vorgesetzten. Rückmeldung von diesen ist jedoch nur möglich, wenn die Arbeit ein zufriedenstellendes Maß an Zusammenarbeit erfordert. Der Vorteil der Rückmeldung besteht darin, dass Schwierigkeiten bei der Arbeit mit SAP-Software besser bewältigt und Belastungen besser ertragen werden können. Entwicklungsmöglichkeit Die Gestaltung von Arbeitsaufgaben sollte „Gelegenheit zur Weiterentwicklung bestehender und die Aneignung neuer Fertigkeiten im Rahmen der Aufgabenstellung vorsehen“. Jede Arbeit verändert auch die Persönlichkeit des Arbeitenden – manchmal zum Guten, manchmal zum Schlechten. Deshalb ist es wichtig, Arbeitsaufgaben so zu gestalten, dass sie die Kompetenzen des SAP-Benutzers weiterentwickeln. Beispielsweise sollte die Arbeit mit SAP herausfordernd sein und ausreichend Komplexität bereitstellen. Dadurch wird auch die Leistung gefördert. Lern- und Persönlichkeitsförderlichkeit der Arbeit ist eine notwendige Voraussetzung für eine gute Motivation des Benutzers. Als negativ gelten Tätigkeiten, bei denen ein Beschäftigter ständig über oder unter seinen Leistungsmöglichkeiten arbeitet, die kein Weiterlernen ermöglichen oder die zum Verlust von Qualifikationen führen.

60

3.3 DIN EN ISO 9241: Ergonomie der Mensch-System-Interaktion Entwicklungsmöglichkeiten bieten für SAP-Benutzer den Vorteil, dass ihre geistige Flexibilität erhalten bleibt und sie ihre beruflichen Qualifikationen weiterentwickeln können.

3.3.2

Grundsätze der Dialoggestaltung Teil 110 der internationalen Norm DIN EN ISO 9241 beschäftigt sich mit der ergonomischen Gestaltung interaktiver Systeme und beschreibt sieben ergonomische Gestaltungsgrundsätze, die unabhängig von einer bestimmten Anwendungssoftware gültig sind. Diese Grundsätze der Dialoggestaltung sind bei der Analyse, der Gestaltung sowie der Bewertung von Software anzuwenden. Im Folgenden werden die sieben Grundsätze der Dialoggestaltung nach DIN EN ISO 9241-110 (vgl. Abbildung 3.2) vorgestellt, kommentiert und mit Beispielen aus der Anwendung von SAP-Software illustriert, und es wird erläutert, wie mittels Usability Management die Anforderungen der Norm erfüllt werden können.

Abbildung 3.2:

Grundsätze der Dialoggestaltung nach DIN EN ISO 9241-110

Aufgabenangemessenheit Ein interaktives System ist aufgabenangemessen, wenn es den Benutzer unterstützt, seine Arbeitsaufgabe zu erledigen, d. h., wenn Funktionalität und Dialog auf den charakteristischen Eigenschaften der Arbeitsaufgabe basieren anstatt auf der zur Aufgabenerledigung eingesetzten Technologie. Eine Software sollte den Benutzer bei der Erledigung seiner Arbeitsaufgaben unterstützen, ohne ihn unnötig zu belasten. Die Software sollte unkompliziert zu bedienen sein, alle Funktionen enthalten, um die anfallenden Aufgaben effizient zu bewältigen, gute Möglichkeiten anbieten, sich häufig wiederholende Bearbeitungsvorgänge zu automatisieren, keine überflüssigen Eingaben 61

3 Gesetze, Verordnungen, Normen erfordern – kurzum: gut auf die Anforderungen der Arbeit zugeschnitten sein. Effektivität und Effizienz

Diese Forderungen weisen eine große Nähe auf zu dem in Teil 11 der DIN EN ISO 9241 niedergelegten Kriterien der Effektivität (also der Genauigkeit und Vollständigkeit, mit der der Benutzer ein bestimmtes Ziel erreichen kann) und Effizienz (also des im Verhältnis zur Genauigkeit und Vollständigkeit eingesetzten Aufwandes, mit dem der Benutzer ein bestimmtes Ziel erreichen kann) (vergleichen Sie hierzu Kapitel 2).

Gestaltungshinweise

„Effektiv und effizient“ bedeutet hier: Die Software muss eine im Hinblick auf den Arbeitsaufwand und die verwendeten Betriebsmittel wirksame Aufgabendurchführung unterstützen. Im Einzelnen heißt dies, dass (vgl. DIN EN ISO 9241-110, S. 8 ff.)

62

•

dem Benutzer nur solche Informationen anzeigt werden, die im Zusammenhang mit der erfolgreichen Erledigung der Arbeitsaufgabe stehen;

•

dem Benutzer keine Informationen anzeigt werden, die nicht für die erfolgreiche Erledigung relevanter Arbeitsaufgaben benötigt werden;

•

die Form der Ein- und Ausgabe der Arbeitsaufgabe angepasst ist;

•

dem Benutzer Eingabewerte, die für eine bestimmte Arbeitsaufgabe ganz typische sind, automatisch als voreingestellte Werte zur Verfügung stehen;

•

die von der Software verlangten Dialogschritte zu dem Arbeitsablauf passen, also alle notwendigen Dialogschritte vorhanden sind und unnötige Dialogschritte, die automatisch durch die Software ausgeführt werden können, vermieden werden;

•

die Software kompatibel zu vorhanden Quelldokumenten wie Papiervorlagen oder Formularen ist;

•

die Eingabe- und Ausgabemedien der Software aufgabenangemessen sind.

3.3 DIN EN ISO 9241: Ergonomie der Mensch-System-Interaktion Kasten 3.2: Aufgabenangemessenheit – ein Negativbeispiel aus der Praxis Herr Müller und die Einstellung von Witwen Herr Müller arbeitet in der Personalabteilung und ist verantwortlich für die Auszahlung von Betriebsrenten. Wenn ein Rentner verstirbt, erhält dessen Frau Witwenrente vom Unternehmen. Obwohl viele Daten wie Name, Adresse oder Geburtsdatum der Frau bereits im System gespeichert sind, müssen sie neu eingegeben werden. Um die Zahlung der Witwenrente zu veranlassen, muss Herr Müller die R/3-Maßnahme „Einstellung Mitarbeiter“ durchführen. Diese Maßnahme verlangt das Ausfüllen von Mussfeldern mit Daten zur täglichen Arbeitszeit, zur Lohnfortzahlung im Krankheitsfall und zu Reiseprivilegien. Die gesamte Prozedur dauert elf Minuten, wovon Herr Müller mehr als zwei Minuten damit verbringt, sinnlos Masken auszufüllen oder zu überspringen. Da Herr Müller als Bearbeiter von Renten sehr oft Witwen „einstellen“ muss, ist er sehr verärgert über die vielen Zusatzschritte. Er hat das Gefühl, viel Zeit zu verschwenden, die er für andere Arbeiten besser nutzen könnte. Selbstbeschreibungsfähigkeit Ein Dialog ist in dem Maße selbstbeschreibungsfähig, in dem für den Benutzer zu jeder Zeit offensichtlich ist, in welchem Dialog, an welcher Stelle im Dialog er sich befindet, welche Handlungen unternommen werden können und wie diese ausgeführt werden können. Eine Software verfügt über Selbstbeschreibungsfähigkeit, wenn sie dem Benutzer genügend Erläuterungen gibt und in ausreichendem Maße verständlich ist. Die Selbstbeschreibungsfähigkeit einer Software kann reaktiv, aktiv oder proaktiv erfolgen. Reaktive Selbstbeschreibungsfähigkeit

Reaktive Selbstbeschreibungsfähigkeit liegt vor, wenn die Software auf Anforderung des Benutzers Angaben zu der Bedeutung von Bildschirminhalten oder Funktionen liefert. Zur reaktiven Selbstbeschreibungsfähigkeit gehört z. B., dass die Software auf Verlangen situationsspezifische Erklärungen bietet, die konkret weiterhelfen.

Aktive Selbstbeschreibungsfähigkeit

Aktive Selbstbeschreibungsfähigkeit liegt vor, wenn die Software von sich aus so informationshaltig ist, dass mögliche Missinterpretationen oder Fehleingaben von vornherein vermieden werden. Software mit aktiver Selbstbeschreibungsfähigkeit bietet beispielsweise einen guten Überblick über ihr Funktionsangebot, verwendet gut verständliche Begriffe, Bezeichnungen, Abkürzun63

3 Gesetze, Verordnungen, Normen gen oder Symbole in Masken und Menüs und liefert in zureichendem Maße Informationen darüber, welche Eingaben zulässig oder nötig sind. Proaktive Selbstbeschreibungsfähigkeit

Proaktive Selbstbeschreibungsfähigkeit liegt vor, wenn die Software von sich aus frühzeitig und differenziert auf mögliche Fehlentwicklungen hinweist, beispielsweise von sich aus situationsspezifische Erklärungen bietet, die konkret weiterhelfen, oder vor möglichen Fehleingaben warnt.

Gestaltungshinweise

Grundsätzlich gilt, dass die Software nach jeder Handlung des Benutzers dort, wo es zweckmäßig ist, eine Rückmeldung in aufgabenangemessener Form geben muss. Um ihm die Dialogschritte verständlich zu machen, sollte zur Erreichung von Selbstbeschreibungsfähigkeit zudem beachtet werden, dass (vgl. DIN EN ISO 9241-110, S. 10) •

dem Benutzer bei jedem Dialogschritt Informationen (Anleitungen, Rückmeldungen, Zustandsinformationen usw.) angezeigt werden, die ihm erlauben, den Dialog erfolgreich abzuschließen;

•

während der Interaktion mit der Software die Notwendigkeit minimiert ist, Benutzer-Handbücher oder andere externe Informationen heranzuziehen;

•

der Benutzer, z. B. wenn Eingaben erwartet werden, über Zustandsänderungen der Software informiert wird;

•

die Software dem Benutzer Informationen über erwartete Eingaben bereitstellt;

•

durch die Gestaltung der Dialoge die Interaktion für den Benutzer offensichtlich ist;

•

die Software dem Benutzer Informationen über erforderliche Formate und Einheiten bereitstellt.

Kasten 3.3: Selbstbeschreibungsfähigkeit – ein Positivbeispiel aus der Praxis QuickInfos – schnell und informativ Gerade am Anfang, wenn man die Benutzung der SAP-Software noch erlernen muss und noch nicht alle Funktionen bekannt sind, helfen kleine Informationen, die das System von sich aus gibt, weiter. Die Abbildung 3.3 zeigt das am Beispiel von QuickInfos. QuickInfos erscheinen, wenn der Cursor länger auf einem Button verweilt, und zeigen an, welche Funktion dieser Button hat und mit welchen Tastaturkürzeln er, al64

3.3 DIN EN ISO 9241: Ergonomie der Mensch-System-Interaktion ternativ zur Maus, betätigt werden kann. QuickInfos helfen somit nicht nur dem Anfänger, der das System erst noch erlernen muss, sondern auch dem fortgeschrittenen Benutzer, der nach effizienteren Bedienmöglichkeiten wie Tastaturkürzeln sucht oder bisher nicht benutzte Funktionen erkunden möchte. Ein Benutzer hingegen, der keine QuickInfos wünscht, kann diese auch ganz einfach ausblenden.

Abbildung 3.3: Erfüllung der Selbstbeschreibungsfähigkeit: Anzeige von Funktionen und Tastaturkürzeln von Buttons durch QuickInfos (Beispiel) Erwartungskonformität Ein Dialog ist erwartungskonform, wenn er den aus dem Nutzungskontext heraus vorhersehbaren Benutzerbelangen sowie allgemein anerkannten Konventionen entspricht. Eine Software verfügt über Erwartungskonformität, wenn sie durch eine einheitliche und verständliche Gestaltung den Erwartungen und Gewohnheiten des Benutzers entgegenkommt – ihm also die Orientierung erleichtert, ihn nicht im Unklaren darüber lässt, ob eine Eingabe erfolgreich war oder nicht, ihn in ausreichendem Maße darüber informiert, was sie gerade macht, mit gut vorhersehbaren Bearbeitungszeiten reagiert und sich durchgehend nach einem einheitlichen Prinzip bedienen lässt. Innere Konsistenz

Der Schlüssel zur Erwartungskonformität lautet „Konsistenz“. Dies bedeutet zum einen, dass sich die Software durch ein in sich einheitliches und widerspruchsfreies Dialogverhalten und Erscheinungsbild auszeichnet (innere Konsistenz).

Äußere Konsistenz

Zum anderen muss erwartungskonforme Software in zentralen Bedienschritten auch anderen an einem Arbeitsplatz zum Einsatz kommenden Dialogsystemen angeglichen werden, damit es dem Benutzer möglich ist, sein Wissen aus den anderen Programmen direkt in die neue Software „mitzunehmen“ (äußere Konsistenz). Neben der äußeren Konsistenz zu anderen Softwareprogrammen spielt auch die äußere Konsistenz zur Arbeitsaufgabe und zum soziokulturellen Umfeld eine Rolle in der Erfüllung der Erwartungskonformität. 65

3 Gesetze, Verordnungen, Normen Zur Sicherstellung der äußeren Konsistenz zur Arbeitsaufgabe sollte der Dialog bei ähnlichen Arbeitsaufgaben ebenfalls ähnlich gestaltet sein. Dies wird beispielsweise dadurch erreicht, dass das Dialogsystem den Wortschatz verwendet, der dem Benutzer bei der Erledigung seiner Arbeitsaufgaben vertraut ist. Jede Gesellschaft hat soziale Konventionen. Auch diese müssen in einer Software berücksichtigt werden. Dazu gehört, dass manche Kulturen von links nach rechts, andere wieder von rechts nach links schreiben oder dass Farben – wiederum in Abhängigkeit von ihrem jeweiligen Kontext – unterschiedliche inhaltliche Bedeutungen zugeschrieben werden. Gestaltungshinweise

66

Erwartungskonformität kann beispielsweise dadurch sichergestellt werden, dass (vgl. DIN EN ISO 9241-110, S. 11 f.) •

die Software das Vokabular verwendet, das dem Benutzer bei der Ausführung der Arbeitsaufgabe vertraut ist oder von ihm aufgrund seiner Kenntnisse und Erfahrungen verwendet wird;

•

auf Handlungen des Benutzers eine unmittelbare und passende Rückmeldung folgt, soweit dies den Erwartungen des Benutzers entspricht;

•

die Software den Benutzer über Abweichungen von erwarteten Antwortzeiten informiert;

•

Informationen so strukturiert und organisiert sind, wie es von dem Benutzer als natürlich empfunden wird;

•

Formate den kulturellen und sprachlichen Konventionen des Nutzungskontextes entsprechen;

•

Art und Länge von Rückmeldungen oder Erläuterungen den Benutzerbelangen entsprechen;

•

Dialogverhalten und Informationsdarstellung innerhalb einer Arbeitsaufgabe und über ähnliche Arbeitsaufgaben hinweg konsistent sind;

•

bestimmte, von dem Benutzer erwartete Eingabepositionen voreingestellt sind;

•

Rückmeldungen oder Mitteilungen, die dem Benutzer angezeigt werden, in einer objektiven und konstruktiven Art formuliert sind.

3.3 DIN EN ISO 9241: Ergonomie der Mensch-System-Interaktion Kasten 3.4: Erwartungskonformität – ein Negativbeispiel aus der Praxis Sprechen Sie SAP? Die Einführung von SAP bringt häufig eine Umstellung der Sprachgewohnheiten mit sich. Heißt es im Alltag „Bankleitzahl“, so ist in der SAP-Software von „Bankschlüssel“ die Rede. Was jedermann „Umsatzsteuer“ nennt, findet man in der SAP-Software als „Ausgangssteuer“. Besonders in den Bereichen im Unternehmen, die nicht dem Rechnungswesen angehören, stoßen viele SAP-Vokabeln auf Unverständnis und bürden dem Benutzer unnötigen Lehrstoff auf. Sprach man etwa im Unternehmen bisher immer nur von Kunden, so muss man in der SAP-Software nach „Debitoren“ suchen. Aber zum Glück gibt es ja die „Wertehilfedrucktaste“, hinter der sich eine Liste mit verfügbaren Einträgen verbirgt. Lernförderlichkeit Ein Dialog ist lernförderlich, wenn er den Benutzer beim Erlernen der Nutzung des interaktiven Systems unterstützt und anleitet. Lernförderlichkeit bedeutet, dass eine Software wenig Zeit zum Erlernen erfordert, den Benutzer ermutigt, auch einmal neue Funktionen auszuprobieren, ihm nicht abverlangt, sich viele Details zu merken, und so gestaltet ist, dass sie gut ohne fremde Hilfe oder Handbuch erlernbar ist und sich einmal Gelerntes gut einprägt. Zusammenhang mit anderen Dialogprinzipien

Lernförderlichkeit bedeutet weiter, dass Software qualifizieren soll. Sie überschneidet sich stark mit den anderen Dialogprinzipien: Eine aufgabenangemessene Software ist lernförderlich, weil sie dem Benutzer erlaubt, Wissen aus seinem Arbeitsalltag in die Benutzung der Software „mitzunehmen“. Eine selbstbeschreibungsfähige Software ist lernförderlich, weil sie den Dialog unmittelbar verständlich darstellt oder dem Benutzer auf Anfrage erklärt. Eine steuerbare Software ist lernförderlich, weil sie die Kontrolle des Dialogs beim Benutzer lässt. Eine erwartungskonforme Software ist lernförderlich, weil sie es dem Benutzer erlaubt, Arbeitsweisen routiniert auszuführen und Wissen aus anderen Softwarepaketen in die Benutzung der Software „mitzunehmen“. Eine fehlertolerante Software ist lernförderlich, weil sie das Lernen am „Versuch und Irrtum“ unterstützt. Eine individualisierbare Software ist lernförderlich, weil sie dem Benutzer er67

3 Gesetze, Verordnungen, Normen laubt, die Software an seinen Wissens- und Könnensstand anzupassen. Gestaltungshinweise

Die Lernförderlichkeit wird beispielsweise dadurch unterstützt, dass (vgl. DIN EN ISO 9241-110, S. 12 f.) •

Regeln und zugrundeliegende Konzepte, die für das Erlernen nützlich sind, dem Benutzer zugänglich sind;

•

Berücksichtigung findet, dass manche Dialoge selten gebraucht werden oder charakteristische Eigenschaften des Benutzers es erforderlich machen, den Dialog erneut zu erlernen;

•

geeignete Unterstützung bereitgestellt wird, damit der Benutzer mit dem Dialog vertraut wird, und dabei Berücksichtigung findet, dass unterschiedliche Benutzer unterschiedlichen Unterstützungsbedarf haben können;

•

Rückmeldung und Erläuterungen den Benutzer unterstützen, ein grundlegendes Verständnis der Software auszubilden;

•

die Software ausreichende Rückmeldung über Zwischenund Endergebnisse von Handlungen bereitstellt, damit der Benutzer die Möglichkeit hat, von erfolgreich ausgeführten Handlungen zu lernen;

•

der Benutzer die Möglichkeit hat – falls es zu seinen Arbeitsaufgaben und Lernzielen passt –, Dialogschritte ohne nachteilige Auswirkungen auszuprobieren;

•

der Benutzer die Möglichkeit hat, die Arbeitsaufgabe mit minimalem Lernaufwand auszuführen, indem die Software eine möglichst geringe Anzahl von Eingaben erfordert, jedoch zusätzliche Information auf Anforderung zur Verfügung stellt.

Kasten 3.5: Lernförderlichkeit – ein Negativbeispiel aus der Praxis Anfänger haben es schwer Bevor ein Anfänger die Bearbeitung seiner Aufgaben mit der SAP-Software lernt, muss er die grundlegende Navigation beherrschen. Abbildung 3.4 zeigt einen typischen Ausschnitt aus einer Bildschirmmaske. Es gilt eine Menge Navigationssymbole zu lernen und deren Unterschiede zu begreifen. So ist einem Anfänger oftmals der Unterschied zwischen „Okay“ und „Objekt ausführen“ sowie zwischen „Zurück“, „Abbrechen“ und „Beenden“ unklar, denn das Anklicken dieser Symbole führt je nach Systemzustand zu ähnlichen Ergebnissen. 68

3.3 DIN EN ISO 9241: Ergonomie der Mensch-System-Interaktion A

B

Abbildung 3.4: Verletzung der Lernförderlichkeit: Benutzer muss Funktionen mit unklarem Ausgang uneindeutigen Symbolen zuordnen. A: Symbole im Kontext der Maske, B: Erläuterung der Symbole. Steuerbarkeit Ein Dialog ist steuerbar, wenn der Benutzer in der Lage ist, den Dialogablauf zu starten sowie seine Richtung und Geschwindigkeit zu beeinflussen, bis das Ziel erreicht ist. Von Steuerbarkeit einer Software spricht man, wenn der Benutzer die Art und Weise, wie er mit ihr arbeitet, beeinflussen kann. Damit dies sichergestellt ist, sollte ihm die Software die Möglichkeit bieten, die Arbeit an jedem Punkt zu unterbrechen und dort später ohne Verluste wieder weiterzumachen, sie sollte weder eine unnötig starre Einhaltung von Bearbeitungsschritten noch unnötige Unterbrechungen der Arbeit erzwingen, einen leichten Wechsel zwischen einzelnen Menüs oder Masken ermöglichen, und der Benutzer sollte beeinflussen können, wie und welche Informationen am Bildschirm dargeboten werden. Kontrollverlust

Es ist ein Grundbedürfnis des Menschen, seiner Umwelt nicht passiv ausgeliefert zu sein. Das macht es notwendig, dem Benutzer weitestgehend die Kontrolle über die Software zu geben. Kontrolle über seine Umwelt – also auch über die Software – zu haben ist eine wichtige Ressource im Umgang mit Stress. Kontrollverlust geht bei Menschen, insbesondere in Zeiten hoher Belastung, Hand in Hand mit einer hohen Beanspruchung (vergleichen Sie hierzu Kapitel 2). 69

3 Gesetze, Verordnungen, Normen Gestaltungshinweise

Steuerbarkeit ist beispielsweise dann gegeben, wenn die Software sicherstellt, dass (vgl. DIN EN ISO 9241-110, S. 13 f.) •

die Geschwindigkeit der Interaktion nicht durch die Software vorgegeben wird, sondern von dem Benutzer steuerbar ist, und zwar unter Berücksichtigung seiner Belange und charakteristischen Eigenschaften;

•

der Benutzer die Steuerung darüber hat, wie der Dialog fortgesetzt wird;

•

der Benutzer den Dialog unterbrechen oder beenden kann, soweit dies bei den vorgegebenen Arbeitsaufgaben möglich ist;

•

der Benutzer mindestens den letzten Dialogschritt rückgängig machen kann, sofern der ursprüngliche Anwendungszustand wieder herstellbar ist und der Nutzungskontext dies zulässt;

•

der Benutzer die Anzeige großer Datenmengen steuern kann, wenn dies für die Erledigung der Arbeitsaufgabe sinnvoll oder notwendig ist;

•

der Benutzer dort, wo es geeignet ist, die Möglichkeit hat, jedes verfügbare Eingabe- oder Ausgabemittel zu nutzen;

•

der Benutzer voreingestellte Werte ändern kann, wenn es für die Arbeitsaufgabe zweckmäßig ist;

•

nach Änderung von Daten die Originaldaten für den Benutzer verfügbar bleiben, wenn dies für die Arbeitsaufgabe erforderlich ist.

Kasten 3.6: Steuerbarkeit – ein Negativbeispiel aus der Praxis Mussfelder zwingen Arbeitsrhythmus auf Viele SAP-Masken verlangen das Ausfüllen von so genannten Mussfeldern. Diese sind nicht immer als solche gekennzeichnet. Wenn nicht alle Mussfelder ausgefüllt wurden, verhindert das System das Speichern der bisher eingegebenen Daten, den Wechsel zur nächsten Maske oder das Zurückgehen auf eine frühere Maske – so lange, bis alle Mussfelder ausgefüllt sind. Dies ist besonders dann ein Problem, wenn die erforderlichen Daten für die Mussfelder dem Benutzer noch gar nicht vorliegen.

Abbildung 3.5: SAP-Meldung bei nicht ausgefüllten Mussfeldern 70

3.3 DIN EN ISO 9241: Ergonomie der Mensch-System-Interaktion Fehlertoleranz Ein Dialog ist fehlertolerant, wenn das beabsichtigte Arbeitsergebnis trotz erkennbar fehlerhafter Eingaben entweder mit keinem oder mit minimalem Korrekturaufwand seitens des Benutzers erreicht werden kann. Fehlertolerante Software ist so gestaltet, dass kleine Fehler keine schwerwiegenden Folgen haben können, die Software zeitnah über fehlerhafte Eingaben informiert, gut verständliche Fehlermeldungen liefert, bei Fehlern insgesamt einen geringen Korrekturaufwand erfordert und konkrete Hinweise zur Fehlerbehebung gibt. Fehlererkennung, Fehlervermeidung, Fehlerkorrektur, Fehlermanagement

Zur Entwicklung konkreter Designvorschläge bietet sich grundsätzlich eine Unterscheidung in Möglichkeiten zur Fehlererkennung und Fehlervermeidung sowie zur Fehlerkorrektur und zum Fehlermanagement an. Bei Fehlererkennung und Fehlervermeidung steht das Bemühen im Vordergrund, durch gutes Softwaredesign Fehler zu reduzieren. Bei der Fehlerkorrektur geht es um die Möglichkeit, einmal gemachte Fehler zu beheben, bevor es zu negativen Konsequenzen kommt, und bei der Strategie des Fehlermanagements wird das Augenmerk auf die Reduzierung der negativen Auswirkungen von Fehlern gelegt.

Gestaltungshinweise

Positive Unterstützung erfährt die Fehlertoleranz, wenn (vgl. DIN EN ISO 9241-110, S. 14 f.) •

die Software den Benutzer dabei unterstützt, Eingabefehler zu entdecken und zu vermeiden;

•

die Software verhindert, dass irgendeine Handlung des Benutzers zu undefinierten Systemzuständen oder zu Systemabbrüchen führt;

•

bei einem Fehlerereignis dem Benutzer eine Erläuterung zur Verfügung gestellt wird, um die Beseitigung des Fehlers zu erleichtern;

•

dort, wo typischerweise Fehler auftreten, aktive Unterstützung zur Fehlerbeseitigung zur Verfügung steht;

•

der Benutzer bei automatischer Fehlerkorrektur des Dialogsystems über Korrekturmöglichkeiten informiert wird und Gelegenheit erhält, diese zu beeinflussen;

•

der Benutzer die Möglichkeit hat, Fehlerkorrekturen aufzuschieben, um ggf. später darauf zurückzukommen;

71

3 Gesetze, Verordnungen, Normen •

dem Benutzer auf Anfrage zusätzliche Informationen zum Fehler und dessen Beseitigung zur Verfügung gestellt werden;

•

die Prüfung auf Gültigkeit und Korrektheit von Daten stattfindet, bevor die Software die Eingabe verarbeitet;

•

die Anzahl der zur Fehlerbehebung erforderlichen Schritte minimal ist;

•

Benutzerhandlungen mit großer Tragweite einer zusätzlichen Bestätigung bedürfen.

Kasten 3.7: Fehlertoleranz – ein Negativbeispiel aus der Praxis Bochum: Deutschlands Hauptstadt? Manche Fehler werden nicht abgefangen, obwohl sie vermieden werden könnten. So ermöglichen manche Masken die Eingabe von täglichen Arbeitszeiten über 24 Stunden oder von Adressen, bei denen Postleitzahl und Ort nicht übereinstimmen. Den letzteren Fall zeigt Abbildung 3.6. Im Beispiel hat der Benutzer fälschlicherweise die Postleitzahl von Bochum mit dem Ort Berlin kombiniert. Dies kann gravierende Folgen haben, denn Post, die an die betreffende Person geschickt wird, kommt nicht oder erst mit Verspätung an. Mit einer einfachen Eingabekontrolle und einem Hinweis auf den Fehler durch das System hätte die Fehleingabe toleriert werden können, ohne ernsthafte Schäden hervorzurufen.

Abbildung 3.6: Verstoß gegen das Kriterium Fehlertoleranz: Der Benutzer bekommt keine Rückmeldung, dass PLZ und Ort nicht übereinstimmen

72

3.3 DIN EN ISO 9241: Ergonomie der Mensch-System-Interaktion Individualisierbarkeit Ein Dialog ist individualisierbar, wenn Benutzer die MenschSystem-Interaktion und die Darstellung von Informationen ändern können, um diese an ihre individuellen Fähigkeiten und Bedürfnisse anzupassen. Eine Software erfüllt den Grundsatz der Individualisierbarkeit, wenn sie sich vom Benutzer für unterschiedliche Aufgaben passend einrichten lässt und für neue Aufgaben leicht erweitert werden kann, wenn der Benutzer sie gut an seine persönliche Art der Arbeitserledigung anpassen kann, sich die Bildschirmdarstellung nach seinen individuellen Bedürfnissen einstellen lässt und wenn sie sich für Anfänger und Experten gleichermaßen eignet. Kasten 3.8: Individualisierbarkeit – ein Positivbeispiel aus der Praxis Eigene Daten sparen Zeit Muss der Benutzer in bestimmte Datenfelder wiederholt die gleichen Werte eingeben, so kann er diese voreinstellen, so dass sie bei erneutem Aufruf der Maske schon eingetragen sind. Dazu dienen die Optionen „Halten Daten“, „Setzen Daten“ und „Eigene Daten“ des in Abbildung 3.7 gezeigten Menüs.

Abbildung 3.7: Erfüllung der Individualisierbarkeit: Benutzer können individuell Werte für Datenfelder festsetzen – sie sind bei erneutem Aufruf der Maske schon voreingetragen 73

3 Gesetze, Verordnungen, Normen „One best way“?

Häufig wird der SAP-Standard als der beste Weg, wie die Arbeit zu tun ist, angesehen, und dieser sollte am besten nicht verändert werden. Dahinter steht die Vorstellung, dass es einen „one best way“ der Aufgabenerledigung und Softwaregestaltung gibt. Benutzer unterscheiden sich jedoch in ihren Fähigkeiten und Fertigkeiten, ihren Erfahrungen, ihrer Motivation etc. Solche Unterschiede dürfen nicht unterschätzt werden. Zudem verändern sich Benutzer über die Zeit. Aus Anfängern werden Experten, aus jungen werden alte Menschen. Darüber hinaus läuft im Arbeitsalltag nicht immer alles nach dem gleichen Schema ab: Die Arbeitsaufgaben variieren nicht nur von Benutzer zu Benutzer (z. B. Zuständigkeit für unterschiedliche Bereiche), sondern auch von Tag zu Tag (z. B. mehr Störungen, mehr Zeitdruck).

Gestaltungshinweise

74

Individualisierbarkeit ist beispielsweise gegeben, wenn (vgl. DIN EN ISO 9241-110, S. 15 ff.) •

die Software dem Benutzer dort, wo unterschiedliche Benutzerbelange typischerweise vorkommen, Techniken zur Anpassung an die charakteristischen Eigenschaften von Benutzern bereitstellt;

•

die Software – wenn es für die individuellen Bedürfnisse unterschiedlicher Benutzer zweckmäßig ist – dem Benutzer erlaubt, zwischen verschiedenen Darstellungsformen zu wählen;

•

der Umfang von Erläuterungen (z. B. Details in Fehlermeldungen, Hilfeinformationen) entsprechend dem individuellen Wissen des Benutzers veränderbar ist;

•

der Benutzer, soweit zweckmäßig, die Möglichkeit hat, eigenes Vokabular einzubinden, um Objekte und Funktionen individuell zu benennen;

•

der Benutzer, soweit zweckmäßig, die Geschwindigkeit von dynamischen Ein- und Ausgaben einstellen kann, um sie an seine individuellen Bedürfnisse anzupassen;

•

der Benutzer, soweit zweckmäßig, die Möglichkeit hat, zwischen unterschiedlichen Dialogtechniken zu wählen;

•

der Benutzer die Möglichkeit hat, die Art zu wählen, in der Ein- und Ausgabe-Daten dargestellt werden;

•

der Benutzer die Möglichkeit hat, das Niveau und die Methoden der Mensch-System-Interaktion so auszuwählen, dass sie am besten seinen Bedürfnissen entsprechen;

3.3 DIN EN ISO 9241: Ergonomie der Mensch-System-Interaktion

3.3.3

•

der Benutzer, soweit zweckmäßig, zur Unterstützung individueller Bedürfnisse bei der Ausführung von Arbeitsaufgaben Dialogelemente oder Funktionen hinzuzufügen oder neu ordnen kann;

•

individuelle Einstellungen eines Dialoges rückgängig gemacht werden können und der Benutzer zu den ursprünglichen Einstellungen zurückzugehen kann.

Erfüllung der Dialogprinzipien bei SAP-Software SAP-Software – die in jedem Fall noch an individuelle Kundenanforderungen angepasst werden muss – ist hinsichtlich ihrer software-ergonomischen Qualität nicht grundsätzlich „gut oder schlecht“. Entscheidend für die software-ergonomische Qualität kundenspezifischer Lösungen ist die Güte der Anpassung, die für das jeweilige Anwendungsunternehmen geleistet wird. Eine Studie von Hurtienne u. a. (2004a, 2004b) zum Usability Management (s. Kasten 3.9) konnte zeigen, dass •

die Erfüllung der Dialogprinzipien der DIN EN ISO 9241-110 in einzelnen Unternehmen stark unterschiedlich ist und

•

die ergonomische Qualität der Software durch Usability Management angehoben werden kann.

Kasten 3.9: Eine Studie zur Usability von SAP-Software Die Erfüllung der Dialogprinzipien ist messbar Was tun Sie, wenn Sie sichergehen möchten, dass Ihre SAPSoftware die genannten Dialogprinzipien tatsächlich erfüllt? In Kapitel 10 stellen wir den ISONORM 9241/10 Fragebogen vor, mit dem Sie die Erfüllung der Dialogprinzipien mit einfachen Fragen messen können. Diesen Fragebogen haben wir u. a. in neun Unternehmen, die SAP HR einsetzten, von insgesamt 105 Benutzern ausfüllen lassen. Abbildung 3.8 zeigt die gemittelten Werte für die einzelnen Unternehmen. Die Linie bei +1 markiert die Grenze der software-ergonomischen Mindestanforderung. Zwei Dinge sind bemerkenswert: Erstens, die software-ergonomische Qualität des betrachteten SAP R/3-HR Moduls schwankt beträchtlich – abhängig vom Unternehmen, in dem es eingesetzt wird. Zweitens, in nur einem Unternehmen wird die Mindestanforderung für zufriedenstellende Software (+1) erreicht. SAP-Installationen in anderen Unternehmen liegen teilweise stark darunter. Dies lässt den Schluss zu, dass SAP R/3 HR nicht per se eine schlechte oder gute Erfüllung der Dialogprinzipien 75

3 Gesetze, Verordnungen, Normen aufweist, sondern es auf die konkrete Anpassung vor Ort in den Betrieben ankommt.

Abbildung 3.8: Erfüllung der Dialogprinzipien bei SAP R/3 HR in neun Unternehmen Ein Blick ins Detail: Einzelne Dialogprinzipien und ihre Veränderung durch Usability Management Greifen wir uns ein Unternehmen heraus (B), in diesem Fall einen Zeitungsverlag, so wird die Erfüllung der einzelnen Dialogprinzipien sichtbar (s. Abbildung 3.9, „vorher“-Balken). Der ISONORM-Gesamtwert und einzelne Dialogprinzipien liegen schon nahe am Wert +1. Für an das Unternehmen angepasste SAP-Software liegt die Aufgabenangemessenheit – im Allgemeinen das wichtigste Kriterium – zu niedrig (unter der Marke +1). Besonders schlecht schnitt das Kriterium Individualisierbarkeit mit -0,2 ab. Und dies, obwohl die SAP-Software den Benutzern viele Möglichkeiten zur Individualisierung bietet. Es stellte sich heraus, dass ihnen viele dieser „Stellschrauben“ gar nicht bekannt waren. Um diesen Missstand zu beheben, entwickelten wir für die Benutzer eine Tipps & Tricks-Schulung (mehr dazu finden Sie in Kapitel 2 und Kapitel 11), in der bereits einige der im Vorfeld erhobenen Benutzungsprobleme gelöst werden konnten. Das Ergebnis dieser Usability Management-Maßnahme zeigt Abbildung 3.9 („nachher“-Balken). Wie erwartet, stieg die Bewertung der „Individualisierbarkeit“ deutlich an, da die Benutzer nach der Schulung nun viele Individualisierungsmöglichkeiten der SAP-Software selbst nutzten. Durch die Optimierungen am System stieg auch die – ergonomisch sehr relevante – Aufgabenangemessenheit. Auch alle anderen Kriterien (bis auf die Lernför76

3.4 Zusammenfassung und Ausblick derlichkeit) sowie der Gesamtwert stiegen über die +1-Grenze. Die Erfüllung der Dialogprinzipien lässt sich durch Usability Management also gezielt beeinflussen, und entsprechende Veränderungen lassen sich mit dem ISONORM-Fragebogen gut erfassen.

Abbildung 3.9: Erfüllung der Dialogprinzipien bei einem Zeitungsverlag vor und nach dem Usability Management Die Dialogprinzipien der DIN EN ISO 9241-110 bilden die Basis für das Usability Management und seine Methoden.

3.4

Zusammenfassung und Ausblick Dieses Kapitel erläuterte, welche zentralen Gesetze, Verordnungen und Normen bei der Entwicklung, der Auswahl, dem Erwerb und der Änderung von Software zu berücksichtigen sind, welche Rolle sie in einem Projekt zum Usability Management spielen und wie sie die Basis für Evaluationsinstrumente bilden. Diese Gesetze, Verordnungen und Normen sollten dabei nicht als eine unangenehme Pflicht verstanden werden, die es notgedrungen zu erfüllen gilt. Im Gegenteil, sie dienen der menschengerechten Gestaltung von Software und damit der menschengerechten Gestaltung von Arbeitsbedingungen. Usability Management stützt sich dabei besonders auf die Kriterien der Normen DIN EN ISO 9241-2 (Anforderungen an die Arbeitsaufgabe) und DIN EN ISO 9241-110 (Grundsätze der Dialoggestaltung). Das Vorgehen des Usability Management finden Sie im nächsten Kapitel im Überblick dargestellt. Jochen Prümper und Jörn Hurtienne

77

4

Vorgehensmodell zum Usability Management Sie haben in den vorigen Kapiteln bereits erfahren, dass Usability unverzichtbar für produktives Arbeiten mit EDV-Systemen ist und dass Usability nicht allein der Hersteller liefern kann. Usability sicherstellen können Sie vielmehr dann, wenn Sie ergonomische Ziele und Anforderungen in den Prozess der unternehmensspezifischen Anpassung der Software integrieren, d. h. das herkömmliche Vorgehen im Einführungsprojekt um ergonomische Ziele und Aufgaben ergänzen. Wie sich das bewerkstelligen lässt, zeigt Ihnen das Vorgehensmodell zum Usability Management, das in diesem Kapitel im Überblick und in den nachfolgenden Kapiteln detailliert vorgestellt wird. Warum ist Usability Management im SAP-Einführungsprozess erforderlich? In welchem Zusammenhang steht das Vorgehen beim Usability Management zum herkömmlichen Vorgehen bei der Einführung von SAP-Software? Wie kann das Vorgehensmodell zum Usability Management eingesetzt werden? Was sind seine Bestandteile? Auf diese Fragen will das vorliegende Kapitel Antworten geben. Es gliedert sich in folgende Abschnitte: •

Systematisch, ASAP-kompatibel und benutzerorientiert: Erfolgsfaktoren von Usability Management In diesem Abschnitt lernen Sie die wesentlichen Eigenschaften unseres Vorgehensmodells zum Usability Management kennen. Im Fokus steht hier vor allem die sinnvolle Integration dieses Modells in die herkömmliche Vorgehensmethodik bei der Einführung von SAP-Software (ASAP; s. u.). Sie erfahren, wie Usability Management die einzelnen ASAP-Phasen sinnvoll um ergonomische Komponenten ergänzt. Als weitere Erfolgsfaktoren des Modells werden sein systematischer Aufbau, seine Benutzerorientiertheit und das „Baukastenprinzip“ erläutert, das es ermöglicht, das Modell auf Ihr unternehmensspezifisches SAP-Einführungsprojekt abzustimmen.

79

4 Vorgehensmodell zum Usability Management •

Das Vorgehensmodell im Überblick Im Anschluss folgt ein Überblick über das gesamte Vorgehensmodell, der Ihnen das Verständnis der vertiefenden Darstellung in den nachfolgenden Kapiteln erleichtern soll. Die Phasen „Projekteinstieg“, „Anforderungsanalyse“, „Sollkonzeption“, „Realisierung“, „Go Live & Optimierung“ sowie das Modul „Schulung“ werden vorgestellt und die jeweiligen Bausteine der Phasen erläutert.

•

Exkurs: Ergonomische Stellschrauben Zum Abschluss des Kapitels erfahren Sie, was unter „ergonomischen Stellschrauben“ zu verstehen ist, auf die im Usability Management immer wieder Bezug genommen wird. Hierbei handelt es sich um Werkzeuge, um SAP-Software ergonomisch zu optimieren.

4.1 4.1

Systematisch, ASAP-kompatibel und benutzerorientiert: Erfolgsfaktoren von Usability Management In Kapitel 1 haben Sie erfahren, was wir generell unter Usability verstehen. Um Usability nachhaltig sicherzustellen, muss das Vorgehen beim Usability Management eine Reihe von Erfolgsfaktoren berücksichtigen. Unser Vorgehensmodell zum Usability Management zeichnet sich durch diese Erfolgsfaktoren aus: •

Usability Management ist systematisch;

•

Usability Management ist ASAP-kompatibel;

•

Usability Management erfolgt integriert in das SAP-Einführungsprojekt;

•

Usability Management ist benutzerorientiert;

•

Usability Management ist qualifizierend;

•

Usability Management ist projektspezifisch anpassbar;

•

Usability Management kann präventiv und kurativ (d. h. zur nachträglichen Optimierung) eingesetzt werden.

Diese Aspekte werden in den nachfolgenden Abschnitten zunächst dargestellt, bevor das Vorgehensmodell zum Usability Management im Überblick erläutert wird.

80

4.1 Erfolgsfaktoren von Usability Management

4.1.1

Usability Management ist systematisch Nur ein systematisches Vorgehen unter umfassender Beteiligung der Benutzer sichert den Erfolg ergonomischer Aktivitäten. Ein solches Vorgehen in den Projektphasen •

Projekteinstieg,

•

Anforderungsanalyse,

•

Sollkonzeption,

•

Realisierung,

•

Go Live & Optimierung

wird in den folgenden Kapiteln dargestellt. Ergebnis der Einbindung von ergonomischen Schritten in das SAP-Einführungsprojekt ist eine benutzungsfreundlich gestaltete Software, die von den Beschäftigten akzeptiert wird und leicht erlernbar ist. So können Sie kostspielige nachträgliche Änderungen wegen fehlender, fehlerhafter oder ineffizienter Funktionalitäten vermeiden.

4.1.2

Usability Management ist ASAP-kompatibel

Einführungsmethodik der SAP AG

Ein systematisches Vorgehen ist nicht nur beim Usability Management erforderlich, sondern grundsätzlich eine Voraussetzung für die erfolgreiche Einführung einer SAP-Software. Aus diesem Grund hat die SAP AG eine Vorgehensmethodik für Einführungsprojekte entwickelt, in der der optimale Ablauf einer SAP-Einführung beschrieben und mit Vorlagen, Beispielen und speziellen Werkzeugen unterstützt wird. Das Vorgehen im Einführungsprozess wird entlang einer so genannten „Implementation Roadmap“ in fünf Phasen unterteilt (s. Abbildung 4.1). •

Project Preparation Diese Phase dient der Planung und Vorbereitung des SAPEinführungsprojektes. Dazu zählen die Initialisierung des Projektes, das Erstellen eines Projektplans, die Definition der Implementierungsstrategie und die Ressourcenplanung.

•

Business Blueprint In dieser Phase werden die für die unternehmensspezifische Implementierung der SAP-Software erforderlichen Informationen erhoben und entsprechende Sollvorgaben konzipiert. Beispielsweise werden Organisationsstruktur und Geschäftsprozesse definiert und die technische Systemumgebung festgelegt. 81

4 Vorgehensmodell zum Usability Management •

Realization In dieser Phase findet die Anpassung der SAP-Software an die unternehmensspezifischen Daten, Prozesse und Strukturen statt. Außerdem werden verschiedene Tests der Software durchgeführt.

•

Final Preparation Diese Phase dient abschließenden Vorbereitungen, bevor die so genannte Produktivsetzung der Software erfolgt, d. h. ihre Inbetriebnahme im Arbeitsalltag des Unternehmens. Zu den erforderlichen Vorbereitungen zählen auch die Benutzerschulungen.

•

Go Live & Support In der letzten Phase erfolgt die Produktivsetzung der SAPSoftware inklusive des bereitgestellten Supports im Unternehmen. Diese Phase endet mit dem offiziellen Abschluss des Projektes.

ASAP Implementation Roadmap

Bekannt ist die SAP-Einführungsmethodik unter der Bezeichnung Accelerated SAP – ASAP. Die ASAP Implementation Roadmap ist Bestandteil des Solution Managers. Der SAP Solution Manager bietet einen zentralen Zugriff auf Werkzeuge, Methoden und vorkonfigurierte Inhalte, die u. a. die Implementierung von SAPSoftware unterstützen. Anstelle der Bezeichnung „ASAP Implementation Roadmap“ wird nachfolgend in der Regel kurz von ASAP gesprochen.

Abbildung 4.1:

Phasen der ASAP Implementation Roadmap

Auch SAP-Berater, die sich nicht an der SAP-Einführungsmethodik orientieren, sondern eine eigene Vorgehensweise bevorzugen, gliedern zur Systematisierung ihr Vorgehen nahezu immer in ähnliche Phasen wie die im ASAP genannten. Allerdings werden software-ergonomische Belange in den Arbeitsschritten zu wenig berücksichtigt – sowohl in der SAP-Einführungsmethodik als auch bei anderen individuellen Vorgehensweisen bei der SAP-Einführung. 82

4.1 Erfolgsfaktoren von Usability Management

Abbildung 4.2: Vorgehensmethodik

Phasen des Usability Management

Um dieses Defizit zu beseitigen, wurde das Vorgehensmodell zum Usability Management entwickelt. Es unterstützt jede der fünf Phasen der SAP-Vorgehensmethodik aus ergonomischer Sicht. ASAP-Phasen

Phasen im Vorgehensmodell zum Usability Management

Project Preparation

Projekteinstieg

Business Blueprint

Anforderungsanalyse Sollkonzeption

Realization

Realisierung

Final Preparation

Schulung

Go Live & Support

Go Live & Optimierung

Tabelle 4.1:

ASAP-Phasen und Phasen des Usability Management

Für jede Projektphase eines Einführungsprojektes werden ergonomische Schwerpunkte sowie geeignete Methoden und Instrumente für eine ergonomische Optimierung vorgestellt. Der „Project Preparation“ im ASAP entspricht dabei im Vorgehensmodell zum Usability Management die Phase „Projekteinstieg“. Aus ergonomischer Sicht ist es sinnvoll, den Schwerpunkt der UsabilityAktivitäten möglichst in frühe Projektphasen zu legen. Somit entsprechen der ASAP-Phase „Business Blueprint“ im Vorgehensmodell zum Usability Management zwei Phasen: Anforderungsanalyse und Sollkonzeption. Die ASAP-Phase „Realization“ stimmt mit der Phase „Realisierung“ im Vorgehensmodell zum Usability Management überein. Im Hinblick auf die Phase „Final Preparation“ interessiert aus ergonomischer Sicht vor allem der Aspekt der Schulung – daher ist dieser Phase im Vorgehensmodell zum Usability Management das Modul „Schulung“ zugeordnet. Der Phase „Go Live & Support“ wiederum entspricht die Phase „Go Live & Optimierung“ im Vorgehensmodell zum Usability Management. 83

4 Vorgehensmodell zum Usability Management

4.1.3

Usability Management in das SAP-Einführungsprojekt integrieren Die Gegenüberstellung in Tabelle 4.1. soll deutlich machen, dass Usability Management nicht losgelöst von dem eigentlichen SAPEinführungsprojekt betrachtet werden darf. Die Integration der ergonomischen Aspekte in das betriebliche SAP-Einführungsprojekt und eine enge Verzahnung zwischen ergonomischen und herkömmlichen Aktivitäten im Einführungsprozess ist ein wesentlicher Erfolgsfaktor für das Usability Management.

Usability Management ergänzt ASAP

Daher ist das Vorgehensmodell zum Usability Management auch nicht dazu gedacht, parallel im Rahmen eines eigenen Ergonomie-Projektes umgesetzt zu werden. Das Vorgehensmodell zum Usability Management wird vielmehr wie eine Schablone über die Vorgehensplanung des SAP-Einführungsprojektes gelegt und ergänzt diese um erforderliche ergonomische Aktivitäten. Im Verhältnis zur SAP-Einführungsmethodik ASAP ergeben sich dabei einige zusätzliche Projektaufgaben. Häufiger jedoch werden bereits vorgesehene Arbeitsschritte nur um ergonomische Aspekte erweitert; beispielsweise wird die im Rahmen der Projektplanung vorgesehene Festlegung von Zielen für das Einführungsprojekt ergänzt um die Festlegung von Usability-Zielen. Bitte bedenken Sie beim Lesen dieses Buches, dass im Folgenden zwar die Maßnahmen des Usability Management für sich stehend beschrieben werden, in der Praxis jedoch viele Schritte (z. B. Planung, Qualifizierung, Meilensteine) gut in das Projektgeschehen integriert werden können.

4.1.4

Usability Management ist benutzerorientiert Im Unterschied zur betriebswirtschaftlich-technisch orientierten SAP-Methodik fokussiert sich das Vorgehen beim Usability Management stärker auf die realen Arbeitsaufgaben der Benutzer. So wird beispielsweise beim Usability Management bei der Anforderungsanalyse eine Aufgabenanalyse an den konkreten Arbeitsplätzen der Benutzer vorgeschlagen, um ergonomische Anforderungen aus der spezifischen Arbeitssituation ermitteln zu können, die bei einer formalen betriebswirtschaftlich-technischen Betrachtung meistens verborgen bleiben.

Benutzerbeteiligung

84

Eine benutzungsfreundliche SAP-Software ist nicht allein im Projektteam gestaltbar, sondern bedarf der stärkeren Einbindung von „frischen“ Benutzern, die z. B. nicht als Key-User kontinuierlich ins Projektteam integriert sind. Das belegen viele Beispiele aus Betrieben, in denen nach dem Go Live teure und zeitintensi-

4.1 Erfolgsfaktoren von Usability Management ve Nachbesserungen notwendig wurden: Ein wesentlicher Grund dafür war die zu geringe Einbindung der Benutzer in die Gestaltung und Evaluation der neuen Software. Entsprechend liegt ein Schwerpunkt des Vorgehensmodells zum Usability Management auf einer über das von SAP vorgesehene Key-User-Konzept hinausgehenden, breiten, frühzeitigen und qualifizierenden Benutzerbeteiligung.

4.1.5

Usability Management ist qualifizierend

Qualifizierung für UsabilityAktivitäten

Nicht nur die beteiligten Benutzer, sondern alle Personen, die an ergonomischen Aktivitäten im Einführungsprojekt beteiligt sind, werden beim Usability Management hinsichtlich ergonomischer Fraugestellungen, Vorgehensweisen und Optimierungsmöglichkeiten qualifiziert. Eine solche Qualifizierung von Projektbeteiligten erfolgt während des Einführungsprozesses punktuell immer dann, wenn neue Personen(-gruppen) an der Projektdurchführung aktiv beteiligt werden. Das heißt, es werden nicht sämtliche Projektbeteiligten bereits zu Anfang qualifiziert, unabhängig davon, wann sie im Projektverlauf ergonomische Aktivitäten durchführen, sondern die Qualifizierung erfolgt jeweils zeitnah vor dem Beginn von Arbeitsschritten, für die die jeweiligen Personen verantwortlich sind. Welche Personengruppen an ergonomischen Aktivitäten in einem Einführungsprojekt beteiligt werden, kann abhängig von den Rahmenbedingungen des jeweiligen Projektes variieren.

4.1.6

Usability Management ist projektspezifisch anpassbar

Baukastensystem

Das Vorgehensmodell zum Usability Management ist als Baukastensystem konzipiert, d. h., es zeigt umfassend Methoden und Möglichkeiten zur ergonomischen Optimierung auf – sowohl hinsichtlich der Softwaregestaltung als auch hinsichtlich der Aufgabengestaltung und Benutzerqualifizierung. Für ein konkretes SAP-Einführungsprojekt müssen in der Regel nicht alle dieser Möglichkeiten zum Tragen kommen. Es kann vielmehr abhängig von den vereinbarten Usability-Zielen projektspezifisch festgelegt werden, welche Bestandteile des Vorgehensmodells umgesetzt werden und welche nicht. Aus didaktischen Gründen werden wir im Folgenden jedoch den Fall beschreiben, bei dem Usability Management mit allen Bausteinen eingesetzt wird.

85

4 Vorgehensmodell zum Usability Management

4.1.7

Usability Management ist präventiv und kurativ einsetzbar

Usability im Einführungsprojekt

Im Hinblick auf Kosten, Aufwand und Zufriedenheit der Benutzer ist es am günstigsten, Usability von Anfang an sicherzustellen, indem das Usability Management sozusagen „präventiv“ in den SAP-Einführungsprozess integriert wird – wie im Vorgehensmodell zum Usability Management nachfolgend beschrieben. Dies wird jedoch nicht immer möglich sein – sei es, weil die Software bereits eingeführt oder das Einführungsprojekt zu weit fortgeschritten ist, oder sei es, weil die finanziellen, zeitlichen und sonstigen Rahmenbedingungen des Einführungsprojektes ein Usability Management nicht erlauben und das Unternehmen zu diesem Zeitpunkt die Rahmenbedingungen nicht verändern kann.

Usability nach dem Go Live

In den Fällen, in denen ein präventives Usability Management im Einführungsprozess nicht möglich ist, kann auf optimierende Usability Care nach erfolgter Produktivsetzung der Software zurückgegriffen werden, um die Usability nachträglich zu verbessern. Das Vorgehen bei der Usability Care wird in Kapitel 11 beschrieben. In den folgenden Kapiteln (5 bis 10) ist jedoch zunächst dargestellt, wie sich präventives Usability Management im Einführungsprozess realisieren lässt.

4.2

Das Vorgehensmodell im Überblick

Phasen des Vorgehensmodells

Das Vorgehensmodell (Abbildung 4.3) besteht aus den fünf zeitlich aufeinander folgenden Phasen „Projekteinstieg“, „Anforderungsanalyse“, „Sollkonzeption“, „Realisierung“ und „Go Live & Optimierung“, die sukzessive durchlaufen werden, sowie einem zusätzlichen Modul „Schulung“. „Schulung“ wird in Abgrenzung zu den Phasen als Modul bezeichnet, weil sich die Aufgabe der Qualifizierung aller Projektbeteiligten nicht in den sukzessiven zeitlichen Ablauf der Phasen einordnen lässt, sondern während des gesamten Einführungsprozesses punktuell immer wieder relevant wird. Die genannten fünf Phasen finden sich in vergleichbarer Form in jeder Vorgehenssystematik in Einführungsprojekten für SAP-Software und werden daher auch in jedem unternehmensspezifischen Projekt zum Tragen kommen – wenn auch in unterschiedlichem Umfang.

86

4.2 Das Vorgehensmodell im Überblick

Abbildung 4.3:

Vorgehensmodell zum Usability Management

Bausteine des Vorgehensmodells

Jede der Phasen und auch das Modul „Schulung“ enthält mehrere Bausteine, die umfassende Möglichkeiten beinhalten, durch Softwaregestaltung, Aufgaben- bzw. Arbeitsprozessgestaltung und Benutzerqualifizierung Usability zu verbessern und die Arbeit ergonomisch zu optimieren. In einem konkreten Einführungsprojekt im Unternehmen brauchen nur die vor dem Hintergrund der unternehmensspezifischen Usability-Ziele relevanten Bausteine eingesetzt werden. So könnte sich ein Unternehmen beispielsweise entscheiden, aus der Phase „Sollkonzeption“ nur den Baustein „Evaluation des Sollkonzepts mit Benutzern“ umzusetzen, weil dies im Hinblick auf die vereinbarten Usability-Ziele ausreicht.

Ergonomische Meilensteine

Die fünf Phasen schließen jeweils mit einem Ergonomischen Meilenstein ab. Die Ergonomischen Meilensteine sollen sicherstellen, dass sämtliche in einer Phase erforderlichen ergonomischen Aktivitäten erfolgreich und zufriedenstellend abgeschlossen wurden, bevor die nächste Phase in Angriff genommen wird.

87

4 Vorgehensmodell zum Usability Management Diese formelle „Freigabe“ ist aus ergonomischer Perspektive erforderlich, da gerade ergonomische Anforderungen leicht vernachlässigt werden, wenn im Projekt zeitliche Engpässe entstehen. Ergonomische Meilensteine entsprechen damit den in ASAP/Solution Manager vorgesehenen Schritten zur Qualitätssicherung am Ende jeder Phase und können zeitgleich mit ihnen durchgeführt werden. Nun zu dem Überblick über die Projektphasen des Vorgehensmodells zum Usability Management.

4.2.1

Projekteinstieg In der Phase „Projekteinstieg“ treffen Sie verbindliche Vereinbarungen über die Rahmenbedingungen zur Integration des Usability Management in den SAP-Einführungsprozess. Dies ist erforderlich, um zum einen die Rolle der Software-Ergonomie im Einführungsprojekt festzuschreiben und zum anderen den Aufwand zu legitimieren, der durch software-ergonomische Aktivitäten im Projektverlauf entsteht. Die Festlegung der Rahmenbedingungen vermittelt zudem einen Überblick darüber, welche Aktivitäten in welchem Umfang mit welchen Beteiligten zu welchem Zeitpunkt erforderlich sind. Die Phase „Projekteinstieg“ beinhaltet die Bausteine:

Ergonomische Projektziele

88

•

Ergonomische Projektziele;

•

Projektaufgaben und Projektumfang;

•

Beteiligungskonzept;

•

Projektstandards;

•

Ergonomischer Meilenstein 1.

Zu den zu vereinbarenden Rahmenbedingungen gehören zunächst Vereinbarungen über die ergonomischen Projektziele. Auf einer eher globalen Ebene werden hier Leitbilder und UsabilityZiele festgelegt, die durch das Usability Management im Einführungsprojekt erreicht werden sollen. Ebenso wird vereinbart, mit Hilfe welcher Kriterien die Zielerreichung überprüft werden soll. Der Baustein dient dazu, Software-Ergonomie als Qualitätskriterium fest im Einführungsprojekt zu verankern, ergonomische Aktivitäten zielspezifisch ausrichten zu können und den Aufwand für ergonomische Aktivitäten zu legitimieren. Der nachfolgende Kasten 4.1 zeigt anhand eines Beispiels, wie solche projektspezifischen Usability-Ziele und Prüfkriterien aussehen können.

4.2 Das Vorgehensmodell im Überblick Kasten 4.1: Ergonomische Projektziele (Beispiele) Usability-Ziele für ein Call-Center Ziel: Aufgabenangemessene Versorgung mit Informationen durch die SAP-Software, um eine reibungslose schnelle Bearbeitung von Kundenanfragen im Call-Center zu ermöglichen. Prüfkriterien: Bearbeitungszeiten von Kundenanfragen sind zwei Monate nach dem Go Live im Schnitt kleiner als die derzeitigen Bearbeitungszeiten. Kunden sind mit den erhaltenen Informationen zufrieden. Call-Center-Mitarbeiter haben alle erforderlichen Informationen innerhalb von 20 Sekunden zur Verfügung. Projektumfang und Projektaufgaben

Aufbauend auf den vereinbarten Usability-Zielen bestimmen Sie den Projektumfang des Usability Management und stellen fest, welche ergonomischen Projektaufgaben zur Zielerreichung bearbeitet werden müssen. Aufwand für Usability-Maßnahmen lohnt sich am meisten bei Kernprozessen, die häufig und von vielen Benutzern durchgeführt werden, bei ergebniskritischen Prozessen oder bei Prozessen, die stark vom SAP-Standard abweichen. Zu diesem Arbeitsschritt gehört auch eine Aufwandsschätzung sowie eine Zeit- und Budgetplanung. Sämtliche Planungen zum Usability Management müssen natürlich immer in Übereinstimmung mit den Planungen des betrieblichen Einführungsprojektes gebracht werden.

Beteiligungskonzept

Ein zentraler Baustein in der Phase „Projekteinstieg“ besteht darin, ein Beteiligungskonzept zu entwerfen, das die für ein erfolgreiches Usability Management im Einführungsprojekt erforderliche Beteiligung verschiedener Personengruppen und Funktionsträger sicherstellt. Themen, die im Zusammenhang mit dem Beteiligungskonzept zu bearbeiten sind, betreffen u. a.: •

die Zusammensetzung der Projektgremien des Einführungsprojektes (z. B.: Wer muss aus ergonomischer Sicht hinzugezogen werden; wer hat welche ergonomiebezogenen Entscheidungsbefugnisse; wer ist verantwortlich dafür, dass Usability im Einführungsprojekt sichergestellt wird?).

89

4 Vorgehensmodell zum Usability Management

Erfolgsfaktor Beteiligung

•

das Einbinden des Betriebs-/Personalrates (inkl. Analysieren bzw. Einbeziehen vorhandener Betriebsvereinbarungen sowie ggf. Aushandeln neuer Vereinbarungen).

•

die Beteiligung von Beschäftigten, die nicht als Key-User bereits in das Einführungsprojekt einbezogen sind (inkl. einer entsprechenden Aufwandsschätzung, dem Festlegen von Verfahrensregeln zur Beteiligung und dem Aufbau einer formellen Beteiligungsstruktur).

Beim Usability Management steht die Perspektive der Benutzer und deren Arbeitskontext im Zentrum. Daher ist eine umfassende Beteiligung der künftigen Benutzer unerlässlich, denn nur sie verfügen über das erforderliche Detailwissen, mit dessen Hilfe sich Usability erzielen lässt. Wie erfolgreich Sie beim Usability Management sind, hängt u. a. davon ab, wie gut es Ihnen gelingt, das Thema Usability auf breiter Basis im Einführungsprojekt zu verankern. Neben einer umfassenden Beteiligung von Beschäftigten als künftigen Benutzern der Software ist dafür auch ein frühzeitiges Einbinden des Betriebs-/Personalrates sinnvoll. Darüber hinaus empfiehlt es sich, Promotoren für das Thema Usability zu gewinnen, die in die Projektgremien eingebunden sind. Die Arbeitsschritte der Phase „Projekteinstieg“ bearbeiten Sie in der Regel in Projektsitzungen. Die erforderlichen Planungen, Aushandlungen und Vereinbarungen können dabei häufig im Rahmen der regulären Projektsitzungen des Steuergremiums behandelt werden. Dies setzt allerdings voraus, dass die Gremienzusammensetzung den Anforderungen aus ergonomischer Sicht entspricht.

Projektstandards

Auch im Hinblick auf das Usability Management müssen Projektstandards vereinbart werden. Beispielsweise sollten Sie festlegen, wie ergonomische Aktivitäten dokumentiert werden sollen; wer wann und in welcher Weise aus ergonomischer Perspektive über Aktivitäten im Einführungsprojekt informiert werden muss; wie offene Fragen und Veränderungsvorschläge zur Usability im Einführungsprojekt behandelt werden etc. Es empfiehlt sich, die Projektstandards und Verfahrensweisen für das Usability Management zusammen mit den Standards für alle anderen Aktivitäten im Einführungsprojekt zu vereinbaren und zu dokumentieren.

Ergonomischer Meilenstein 1

Ergebnis dieser Phase ist ein Projektplan zum Usability Management, in dem verbindlich ergonomische Zielvereinbarungen, die Vereinbarung zu Projektumfang und Projektaufgaben, das Betei-

90

4.2 Das Vorgehensmodell im Überblick ligungskonzept sowie die vereinbarten Projektstandards dokumentiert sind. Den Projektplan zum Usability Management, der einen Bestandteil des Gesamtprojektplans bildet, verabschieden Sie im Ergonomischen Meilenstein 1 in einer Projektsitzung des Steuerungsgremiums.

4.2.2

Anforderungsanalyse In der Phase „Anforderungsanalyse“ ermitteln Sie die software-ergonomischen Anforderungen, die erfüllt werden müssen, damit die vereinbarten Usability-Ziele erreicht werden.

Benutzungszentrierte Anforderungsanalyse

Diese Anforderungen können Sie nicht aus einer rein formalen Betrachtung der mit SAP zu unterstützenden Geschäftsprozesse ableiten. Software-ergonomische Anforderungen lassen sich nur konkretisieren, wenn bekannt ist, in welchem Arbeitskontext und von welchen Benutzern die Geschäftsprozesse bearbeitet werden (mehr darüber haben Sie in Kapitel 1 erfahren). Hierzu dient Ihnen die benutzungszentrierte Anforderungsanalyse, wie sie das Vorgehensmodell zum Usability Management – als Ergänzung zu den im ASAP/Solution Manager vorgesehenen Schritten zur ISTAnalyse und Anforderungsentwicklung – vorsieht. Die Phase „Anforderungsanalyse“ beinhaltet die Bausteine:

Nutzungskontextanalyse

•

Nutzungskontextanalyse: – Aufgaben, – Benutzer, – Technik;

•

Anforderungen;

•

Ergonomischer Meilenstein 2.

Der Baustein „Nutzungskontextanalyse: Aufgaben, Benutzer, Technik“ dient zum einen dazu, einen Überblick über ergonomisch relevante Eigenschaften der künftigen Benutzergruppe, ihrer Aufgaben und der ihnen (künftig) zur Verfügung stehenden Technik zu erhalten. Zum anderen werden durch eine Analyse der Arbeitsabläufe und Arbeitsbedingungen direkt am Arbeitsplatz der zukünftigen Benutzer detailliert Informationen darüber erhoben, wie und unter welchen Bedingungen die Benutzer derzeit im Arbeitsalltag ihre Arbeit verrichten. Aus diesen Informationen lassen sich spezifischere software-ergonomische Anforderungen ableiten als aus der stärker überblicksartigen Erhebung von Eigenschaften.

91

4 Vorgehensmodell zum Usability Management Überblick über ergonomisch relevante Merkmale

Ein Überblick über ergonomisch relevante Eigenschaften wird entweder durch eine Befragung von Benutzern per Fragebogen ermittelt oder durch Interviews mit Personen, denen bekannt ist, wie sich die Eigenschaften, die jeweils interessieren, in der untersuchten Benutzergruppe verteilen. Kasten 4.2 nennt einige Beispiele für Merkmale von Benutzern, Aufgaben oder Technik, die aus ergonomischer Sicht relevant sein können. Kasten 4.2: Ergonomisch relevante Merkmale (Beispiele) Ergonomisch relevante Merkmale der Benutzer, der Aufgaben und der Technik Ergonomisch relevante Merkmale der Benutzer können Fachkompetenz oder Erfahrung mit SAP-Software, aber beispielsweise auch Rot-Grün-Blindheit sein. Ebenso ergonomisch relevant ist es, wie viele unterschiedliche Aufgaben ein Benutzer zu erledigen hat, ob er bei der Aufgabenerledigung häufig unterbrochen wird, ob er Maus oder Tastatur für die Eingabe bevorzugt, ob er mit einem kleinen oder großen Bildschirm arbeitet etc. Aus all diesen Eigenschaften können sich unmittelbar ergonomische Anforderungen ergeben. Aus den erhobenen Merkmalen leiten Sie dann in einem nächsten Schritt allgemeine software-ergonomische Anforderungen ab.

Nutzungskontextanalyse am Arbeitsplatz

Um spezifische software-ergonomische Anforderungen zu ermitteln, ist eine Nutzungskontextanalyse an Arbeitsplätzen (ausgewählter) künftiger Benutzer vorgesehen. Ein generelles Ziel ergonomischer Aktivitäten im Einführungsprozess ist es, die SAP-Software, die Aufgaben und die Arbeitsabläufe der Benutzer aufeinander abgestimmt so zu gestalten, dass den Benutzern effektives, effizientes und zufrieden stellendes Arbeiten möglich ist. Um dieses Ziel erreichen zu können, ist es erforderlich, die derzeitige Arbeit der Benutzer detailliert zu untersuchen – nicht nur hinsichtlich der Aufgaben, die künftig mit der SAP-Software unterstützt werden sollen, sondern auch hinsichtlich ihrer anderen Aufgaben. Die Informationen über derzeitige Aufgabenzuschnitte, Arbeitsabläufe, Arbeitsverteilung, Arbeitsumgebung und Qualifikationen der künftigen Nutzer dienen dazu, ergonomische Anforderungen an die Arbeits- und SAP-Softwaregestaltung abzuleiten. Gerade solche Anforderungen, die sich erst aus einer Nutzungskontextanalyse am Arbeitsplatz erschließen, werden bei einer herkömmlichen Ist-Analyse, wie sie im ASAP vorgesehen ist, häufig übersehen. Dies kann zu sehr unangenehmen Überraschungen nach dem Go Live führen, die

92

4.2 Das Vorgehensmodell im Überblick schnellstmöglich teure Nachbesserungen notwendig werden lassen. Die für die Nutzungskontextanalyse erforderlichen detaillierten Informationen werden durch Beobachtungsinterviews an den Arbeitsplätzen ausgewählter künftiger Nutzer erhoben. Kasten 4.3 schildert zwei Praxisbeispiele für Anforderungen, die sich aus Nutzungskontextanalysen am Arbeitsplatz ergeben haben. Kasten 4.3: Nutzungskontextanalysen am Arbeitsplatz (Praxisbeispiele) Ungeliebte Eingabetätigkeiten Eine Nutzungskontextanalyse an Arbeitsplätzen in einer Abteilung eines Dienstleistungsunternehmens zeigte beispielsweise, dass in dieser Abteilung die Eingabe von Daten, die später mit der SAP-Software unterstützt werden soll, derzeit von allen Mitarbeitern erledigt wird. Allerdings macht die Dateneingabe nur einen nicht sehr geschätzten, weil monotonen Bruchteil ihrer sonstigen Aufgaben aus und muss häufig unterbrochen werden, weil andere dringendere Aufgaben kurzfristig erledigt werden müssen. Aus ergonomischer Sicht ergab sich die Anforderung, dass die derzeitige Arbeitsorganisation, bei der kurzfristige monotone Tätigkeiten auf viele Mitarbeiter verteilt sind, besser ist als eine Lösung, bei der die monotonen Tätigkeiten auf einige wenige Mitarbeiter konzentriert werden. Die gegenwärtige Arbeitsorganisation sollte also beibehalten werden. Entsprechend muss für ein unterbrechungsresistentes Design der entsprechenden Eingabeprozeduren der SAP-Software gesorgt werden. Schmutzarbeit In einem Metallverarbeitungsunternehmen ergab die Analyse des Nutzungskontexts an Arbeitsplätzen in der Produktion, dass einige der künftigen Benutzer für viele der Aufgaben, die sie erledigen, aus Sicherheitsgründen Handschuhe tragen müssen. Es wäre nicht besonders effektiv, falls sie diese Handschuhe ständig ausziehen müssten, wenn sie künftig Aufgaben mit Unterstützung der SAP-Software erledigen wollen. Bei der Softwaregestaltung sollte daher sichergestellt werden, dass eine Bedienung (z. B. per Touchscreen) auch mit Handschuhen möglich ist.

93

4 Vorgehensmodell zum Usability Management Anforderungen ableiten

Im Baustein „Anforderungen“ setzen Sie die Informationen, die Sie bei der Nutzungskontextanalyse gewonnen haben, in software-ergonomische Anforderungen um. Anschließend systematisieren, priorisieren und dokumentieren Sie die Anforderungen.

Strategische Anforderungen

Aus dem Überblick über ergonomisch relevante Eigenschaften leiten Sie eher strategische Anforderungen ab, die ergonomische Schwerpunkte für die Anpassung der SAP-Software aufzeigen. Eine solche strategische Anforderung könnte beispielsweise lauten: „Bei der SAP-Anpassung muss der Schwerpunkt auf leichter Erlernbarkeit der Softwarebedienung liegen.“

Spezifische Anforderungen

Aus den Analysen am Arbeitsplatz leiten Sie spezifische Anforderungen ab. Eine spezifische Anforderung könnte beispielsweise sein: „Die Informationen zu Name, Adresse, Telefonnummer, EMail-Adresse und offenen Bestellungen des Kunden müssen auf einer Maske angezeigt werden.“ Die abgeleiteten software-ergonomischen Anforderungen stellen somit gleichzeitig auch eine Konkretisierung der Usability-Ziele dar.

Ergonomischer Meilenstein 2

Im Ergonomischen Meilenstein 2 beurteilen Sie, ob software-ergonomische Anforderungen hinreichend detailliert ermittelt wurden, so dass damit gerechnet werden kann, dass die vereinbarten Usability-Ziele auch erreicht werden, wenn diese Anforderungen umgesetzt werden. Wenn dies der Fall ist, verabschieden Sie das Dokument mit den festgelegten Anforderungen verbindlich.

4.2.3

Sollkonzeption

Gestaltungsvorga- In der Phase „Sollkonzeption“ überführen Sie die ergonomischen Anforderungen aus der Anforderungsanalyse in konkrete, umben entwickeln setzbare Gestaltungsvorgaben für Arbeitsprozesse, Dialoge und Zuschnitte für SAP-Rollen. Als SAP-Rollen werden im SAP-Standard vorgegebene anpassbare Zusammenstellungen von SAP unterstützten Aktivitäten bezeichnet. Unter Rollenzuschnitt verstehen wir die auf den Aufgabenzuschnitt von Personen im Unternehmen abgestimmte Kombination von SAP-Rollen (vergleichen Sie hierzu Kapitel 7, Abschnitt 7.2). In der Phase „Sollkonzeption“ bringen Sie die ergonomischen Anforderungen mit den technischen und organisatorischen Realisierungsmöglichkeiten in Ihrem Unternehmen zusammen. Dabei bieten sich in der Regel mehrere Gestaltungsvarianten an. Unterschiedliche Gestaltungsoptionen vergleichen Sie vor dem Hintergrund ihres Beitrags zur Erfüllung der Usability-Ziele miteinander 94

4.2 Das Vorgehensmodell im Überblick und treffen dann Entscheidungen für die jeweils unternehmensspezifisch optimalen Gestaltungsoptionen. Daher werden bereits bei der Sollkonzeption die Weichen dafür gestellt, wie weit es gelingt, die Usability-Ziele tatsächlich zu erfüllen. Evaluation durch die Benutzer

Daher, und um Fehlentwicklungen frühzeitig zu vermeiden, werden im Vorgehensmodell zum Usability Management die in der ASAP-Phase „Business Blueprint“ vorgesehenen Arbeitsschritte um eine Evaluation des Sollkonzepts durch die Benutzer ergänzt. Auf diese Weise können unergonomische, ineffektive, fehlende oder fehlerhafte Konzeptionen von Arbeitsprozessen, Dialogen und/oder Rollenzuschnitten entdeckt und korrigiert werden, bevor mit der Umsetzung begonnen wurde. Dieses Vorgehen spart Zeit und Kosten, da spätere Änderungen viel mehr Aufwand mit sich bringen. Die Phase „Sollkonzeption“ beinhaltet die Bausteine:

Arbeitsprozessund Dialoggestaltung

•

Arbeitsprozess- und Dialoggestaltung;

•

Ergonomischer Rollenzuschnitt;

•

Evaluation Sollkonzept mit Benutzern;

•

Ergonomischer Meilenstein 3.

Ziel des Bausteins „Arbeitsprozess- und Dialoggestaltung“ ist es, produktive, belastungsarme und qualifikationsförderliche Abläufe zu konzipieren, indem die einzelnen konkreten Arbeitsprozesse und Dialoge ergonomisch gestaltet werden. Bei der Konzeption der Arbeitsprozesse ist aus ergonomischer Sicht vor allem DIN EN ISO 9241-2 „Leitsätze zur Aufgabengestaltung“ relevant, während bei der Dialoggestaltung die Kriterien der DIN EN ISO 9241-110 „Grundsätze der Dialoggestaltung“ eine Rolle spielen (vergleichen Sie hierzu die Abschnitte 3.3.1 und 3.3.2 im dritten Kapitel). In Workshops, an denen auch künftige Benutzer teilnehmen, werden Gestaltungsvorgaben sowohl für Arbeitsprozesse als auch für Dialoge entwickelt. An den Gestaltungsworkshops nimmt jeweils auch ein so genannter Konsistenzmanager teil. Hauptaufgabe des Konsistenzmanagers ist es, die interne Konsistenz der Software, d. h. die Einheitlichkeit in Erscheinungsbild und Bedienung der Benutzeroberfläche, sicherzustellen. Er muss u. a. Gestaltungsvorgaben, die sich auf mehrere Arbeitsprozesse, Dialoge und/oder Rollen beziehen, vereinheitlichen. Außerdem achtet er darauf, dass bei allen Aktivitäten zur Gestaltung von Arbeitsprozessen, Dialogen und Rollenzuschnitten ein einheitlicher ergonomischer Qualitätsstandard gewahrt wird. 95

4 Vorgehensmodell zum Usability Management Ergonomischer Rollenzuschnitt

Ein Stolperstein bei nahezu jeder SAP-Einführung ist das Thema Rollen und Berechtigungen. Im Baustein „Ergonomischer Rollenzuschnitt“ betrachten Sie aus ergonomischem Blickwinkel die Zuordnung künftiger Arbeitsaufgaben zu einzelnen Benutzern. Um produktive, belastungsarme und kompetenzrelevante Arbeit zu ermöglichen, müssen sowohl die einzelnen Aufgaben eines Benutzers als auch die Zusammenstellung aller von ihm zu bearbeitenden Aufgaben ergonomisch gestaltet sein. Die künftigen Soll-Aufgabenzuschnitte für Benutzer haben Konsequenzen für die Gestaltung der Rollen in der SAP-Software. Nicht nur der Soll-Aufgabenzuschnitt, sondern auch die Zusammenstellung von SAP-Rollen, die den Benutzern zugeordnet werden, sollen ergonomisch sein. So werden über die Rollenzuschnitte beispielsweise auch die Berechtigungen, auf Daten und Funktionen in der SAP-Software zugreifen zu dürfen, gesteuert. Die Benutzer sollen alle für die Erledigung ihrer Aufgaben erforderlichen Berechtigungen besitzen. Im Baustein „Ergonomischer Rollenzuschnitt“ überprüfen Sie die ergonomische Angemessenheit der Soll-Aufgabenzuschnitte und legen – falls erforderlich – Gestaltungsvorgaben für eine Überarbeitung der Soll-Aufgabenzuschnitte fest. Auf diesen basierend werden dann ergonomische Anforderungen für die Anpassung und Zuordnung von SAP-Rollen erarbeitet. Die Gestaltungsvorgaben aus den Bausteinen „Arbeitsprozess und Dialoggestaltung“ und „Ergonomischer Rollenzuschnitt“ dokumentieren Sie im Sollkonzept. Mit dem Sollkonzept ergibt sich ein Gesamtbild, wie die Arbeit künftig mit Unterstützung der SAP-Software erledigt werden soll.

Evaluation des Sollkonzepts mit Benutzern

Das Sollkonzept, d. h. die konzipierten Arbeitsabläufe, Dialoge und Rollenzuschnitte, evaluieren die Benutzer auf der Basis ihrer realen Arbeitsaufgaben und ihrer Kenntnis der am jeweiligen Arbeitsplatz vorhandenen Arbeitsbedingungen. Ein „Durchspielen“ von Arbeitsaufgaben, beispielsweise anhand von Screenshots der Bildschirmmasken, Ablaufdiagrammen oder anderen Hilfsmitteln zur prototypischen Veranschaulichung der Abläufe, lässt Fehler, Unzulänglichkeiten oder Schwachstellen der Sollkonzeption frühzeitig deutlich werden. Ergebnis der Phase „Sollkonzeption“ ist das nach der Evaluation durch Benutzer ggf. nochmals überarbeitete Sollkonzept, das eindeutig formulierte, konsistente und umsetzbare ergonomische Gestaltungsvorgaben für Arbeitsprozesse, Dialoge und Rollenzuschnitte beinhaltet.

96

4.2 Das Vorgehensmodell im Überblick Ergonomischer Meilenstein 3

Im Ergonomischen Meilenstein 3 überprüfen Sie, ob das Sollkonzept vollständig ist, ob also alle Gestaltungsvorgaben, die zum Erreichen der Usability-Ziele erforderlich sind, vorliegen. Wenn dies der Fall ist, verabschieden Sie das Sollkonzept als verbindliche Arbeitsgrundlage für die Realisierungsphase.

4.2.4

Realisierung In der Phase „Realisierung“ wird das Sollkonzept umgesetzt. Im Usability Management stellen Sie fest, ob die im Sollkonzept dokumentierten ergonomischen Vorgaben erfüllt sind. Etwaige Fehler, Unzulänglichkeiten und ergonomische Schwachstellen, die die Usability im Arbeitsalltag beeinträchtigen würden, werden vor der Produktivsetzung der Software aufgedeckt und behoben.

Benutzer testen die Usability

Um dieses Ziel zu erreichen, testen künftige Benutzer, die bisher nicht im Projektteam an der Softwareanpassung mitgewirkt haben, sowohl realisierte (Teil-)Prozesse als auch abschließend integrierte Arbeitsprozesse auf der Basis realer Arbeitsaufgaben und Arbeitssituationen. Die künftigen Benutzer kennen die Details der zu erledigenden Arbeitsaufgaben und Arbeitssituationen, die die Usability beeinflussen, genauer, als dies den Mitgliedern des Projektteams möglich ist. Für die Benutzer steht der Nutzen der Software für ihre Alltagsarbeit im Vordergrund, nicht der weitere Projektverlauf. Daher beurteilen sie die Usability der Software unter Umständen unvoreingenommener als stark in das Projekt involvierte Personen. Die Beteiligung der Benutzer an der ergonomischen Optimierung der Software fördert zudem die spätere Akzeptanz. Damit werden im Vorgehensmodell zum Usability Management die technischen und funktionalen Tests, die in der ASAP-Realisierungsphase vorgesehen sind, um ergonomische Evaluationen durch die Benutzer im Sinne eines Prototyping ergänzt. Die Phase „Realisierung“ enthält die Bausteine:

Testbare (Teil-)Prozesse

•

Testbare (Teil-)Prozesse;

•

Evaluation testbarer (Teil-)Prozesse mit Benutzern;

•

Evaluation integrierter Arbeitsprozesse mit Benutzern;

•

Ergonomischer Meilenstein 4.

Im Baustein „Testbare (Teil-)Prozesse“ geht es vor allem um die technische Vorbereitung der Evaluation von Softwarebestandteilen durch die Benutzer. Bei der technischen Umsetzung der (Teil-)Prozesse, d. h. bei der Anpassung von Bestandteilen der 97

4 Vorgehensmodell zum Usability Management SAP-Software an die Anforderungen des Unternehmens, sind einige wenige zusätzliche Anforderungen zu realisieren, damit die angepassten Software-Bestandteile von Benutzern getestet werden können (z. B. Berechtigungen, „Spieldaten“). Die Evaluation mit Benutzern muss zeitlich auf die technische Realisierung der (Teil-)Prozesse abgestimmt werden etc. Evaluation testbarer (Teil-) Prozesse mit Benutzern

Die Durchführung der Benutzertests erfolgt im Baustein „Evaluation testbarer (Teil-)Prozesse mit Benutzern“. Zur Vorbereitung werden „Tester“ ausgewählt, über das Prototyping angemessen informiert und in Softwarehandhabung und in ergonomischen Gesichtspunkten geschult, daneben werden Testaufgaben inkl. notwendiger Arbeitsmaterialien vorbereitet. Bei der Durchführung der Evaluation bearbeiten Benutzer reale Arbeitsaufgaben mit Hilfe bereits fertig gestellter Teile der SAP-Software und protokollieren etwaige ergonomische Mängel sowie Verbesserungsvorschläge. Die Ergebnisse der Benutzertests werden dem Projektteam rückgemeldet, und nach einer Machbarkeitsprüfung werden ergonomische Optimierungen an den (Teil-)Prozessen vorgenommen. Die Durchführung kann – falls erforderlich – wiederholt werden, nachdem die (Teil-)Prozesse überarbeitet wurden.

Evaluation integrierter Arbeitsprozesse

Im Baustein „Evaluation integrierter Arbeitsprozesse mit Benutzern“ überprüfen Benutzer aus verschiedenen Organisationseinheiten den Workflow und die Schnittstellen integrierter Prozesse. Ergänzend zum eher technisch orientierten abschließenden Integrationstest nach ASAP stehen hier die organisatorischen Schnittstellen im Arbeitsfluss im Mittelpunkt. Dadurch können Sie vor dem Produktivstart sicherstellen, dass die integrierte kooperative Bearbeitung von Geschäftsprozessen auch organisatorisch reibungslos möglich ist. Unliebsamen organisatorischen Überraschungen nach dem Go Live und damit einhergehenden Produktivitätseinbußen ist damit vorgebeugt. Bei der Evaluation integrierter Arbeitsprozesse simulieren alle an einem integrierten Prozess beteiligten Benutzer die Bearbeitung eines realen Geschäftsprozesses unter realistischen Arbeitsbedingungen in allen Arbeitsschritten (sowohl mit als auch ohne SAPSoftware). Diese Art Planspiel dient dazu, noch vorhandene Schwachstellen aufzudecken. Die Schwachstellen werden wiederum entsprechend protokolliert, rückgemeldet und nach Möglichkeit vor dem Go Live behoben. Dabei können erforderliche ergonomische Optimierungen sowohl die SAP-Software als auch die Arbeitsorganisation betreffen. Ein Beispiel für ein solches Planspiel zeigt Kasten 4.4.

98

4.2 Das Vorgehensmodell im Überblick Kasten 4.4: Evaluation integrierter Arbeitsprozesse (Praxisbeispiel) Planspiel „Kundenanfragen“ In einem Energieversorgungsunternehmen sitzen acht Sachbearbeiter aus den Abteilungen Call-Center, Kundenservice Privatkunden und Buchhaltung zusammen, um in einem Planspiel die künftige Bearbeitung unterschiedlicher Kundenanfragen realitätsgetreu durchzuspielen. Die meisten Kundenanliegen lassen sich reibungslos erledigen, aber es werden auch einige Schwachstellen entdeckt. So ist beispielsweise nicht geklärt, wer künftig dafür zuständig ist, mit den Kunden auf deren Wunsch hin Ratenzahlungen zu vereinbaren, wenn sie zum Jahresabschluss eine hohe Nachzahlungsaufforderung erhalten haben. Darf das der Mitarbeiter im Call-Center, bei dem der Kunde anruft, oder ist dafür jemand im Back Office des Kundenservice zuständig? Dadurch, dass Schwachstellen wie z. B. diese „Zuständigkeitslücke“ bereits im Planspiel und nicht erst nach dem Go Live entdeckt werden, können Servicemängel verhindert werden, die sonst den Kunden, die mit einem entsprechenden Anliegen anrufen, offensichtlich geworden wären. Durch eine Evaluation integrierter Arbeitsprozesse mit Benutzern können Sie nicht nur mehrfache, fehlende oder ungeeignete organisatorische Zuständigkeiten aufdecken, wie im Beispiel in Kasten 4.4. Auch andere organisatorische Probleme wie z. B. personelle Engpässe im Workflow, umständliche Arbeitsorganisation, fehlender Zugang zu Informationen, die nicht über die Software zur Verfügung gestellt werden etc. lassen sich vor dem Go Live feststellen und beheben. Außerdem können Sie auf diese Weise bisher unerkannte technische Schwierigkeiten bei der kooperativen Bearbeitung integrierter Prozesse entdecken und rechtzeitig beseitigen. In den Bausteinen der Phase „Realisierung“ werden vor allem Methoden zur Unterstützung der Benutzertests eingesetzt, beispielsweise Protokollblätter zum systematischen Dokumentieren von Testergebnissen. Auch Benutzertreffen zur Rückmeldung, Diskussion und Bewertung der Ergebnisse können von Nutzen sein. Ergebnis der Phase „Realisierung“ ist eine vor dem Produktivstart anhand realer Aufgaben und Arbeitssituationen geprüfte und ergonomisch optimierte SAP-Software.

99

4 Vorgehensmodell zum Usability Management Ergonomischer Meilenstein 4

Im Ergonomischen Meilenstein 4 entscheidet das Steuerungsgremium auf der Grundlage der Evaluationsziele, Ergebnisprotokolle von Benutzertests und der dokumentierten ergonomischen Verbesserungsmaßnahmen, ob alle vor der Produktivsetzung aus ergonomischer Sicht erforderlichen Schritte erfüllt wurden. Wenn dies der Fall ist, erfolgt die Freigabe für die Phase „Go Live & Optimierung“.

4.2.5

Schulung

Zielsetzungen

Das Modul „Schulung“ des Vorgehensmodells zum Usability Management verfolgt zwei Ziele. Zum einen sollen alle Projektbeteiligten über die ergonomischen Sichtweisen und Kenntnisse verfügen, die sie benötigen, um im Rahmen des Einführungsprojektes erfolgreich Usability-Aktivitäten durchführen zu können. Zum anderen sollen die Benutzer in der Durchführung ihrer Arbeitsaufgaben mit Hilfe der SAP-Software bereits vor dem Go Live ausreichend geübt sein. Das Modul „Schulung“ beinhaltet entsprechend die beiden Bausteine: •

Qualifizierung aller Projektbeteiligten;

•

Lernsystem.

Qualifizierung der Projektbeteiligten

Im Baustein „Qualifizierung der Projektbeteiligten“ bereiten Sie die Projektbeteiligten ergänzend zu den im ASAP vorgesehenen Schulungen mit speziellen Usability-bezogenen Qualifizierungsmaßnahmen auf ihre Aufgaben im Rahmen des Usability Management vor. Durch die Vermittlung von Grundlagen der Software-Ergonomie sowie von Vorgehensweisen beim Usability Management stellen Sie sicher, dass die Projektbeteiligten die Notwendigkeit und die Inhalte ergonomischer Projektaktivitäten verstehen und ggf. entsprechende Usability-Aktivitäten durchführen können.

Zielgruppenspezifische Qualifizierung

Neben dem Projektteam des Einführungsprojektes gelten beim Usability Management noch weitere Personengruppen als Projektbeteiligte und müssen entsprechend qualifiziert werden. Dazu gehören Mitglieder des Steuerungsgremiums, Mitglieder des Betriebs-/Personalrates sowie an Analysen/Evaluationen im Rahmen des Usability Management beteiligte Benutzer. Die Qualifizierung erfolgt zielgruppenspezifisch zu unterschiedlichen Zeitpunkten im Projektverlauf. Jede der beteiligten Personengruppen erhält einerseits genau das jeweils erforderliche praxisbezogene software-ergonomische Hintergrundwissen, um im Sinne der pro-

100

4.2 Das Vorgehensmodell im Überblick jektspezifischen Usability-Ziele erfolgreich agieren zu können. Andererseits werden die für das Usability Management notwendigen Qualifikationen den einzelnen Zielgruppen jeweils zeitnah vor ihrer Anwendung vermittelt. Lernsystem

Im Baustein „Lernsystem“ wird als Ergänzung zu den im Einführungsprojekt stattfindenden Benutzerschulungen ein Lernsystem eingerichtet, an dem die künftigen Benutzer ihr erworbenes Wissen einüben und aufgabenbezogen vertiefen können. Auf diese Weise können Sie einerseits Produktivitätsverlusten und andererseits vermeidbaren Fehlbelastungen der Benutzer kurz nach dem Go Live vorbeugen.

Übungsmöglichkeiten vor dem Go Live

Nur wenn die Benutzer die künftige Art ihrer Aufgabenerledigung mit Hilfe der SAP-Software verstehen und sicher beherrschen, sind sie in der Lage, nach dem Go Live effektiv und effizient mit der SAP-Software zu arbeiten. Dazu sind neben den Benutzerschulungen ergänzende Übungsmöglichkeiten vor der Inbetriebnahme der Software im Arbeitsalltag erforderlich – insbesondere, wenn zwischen Benutzerschulungen und Go Live ein längerer Zeitraum liegt, denn sonst geraten die vermittelten Inhalte leicht in Vergessenheit und sind beim Go Live nicht mehr verfügbar. Es ist daher sinnvoll, den Benutzern die bereits weitgehend fertig angepasste SAP-Software vor dem Go Live zu Übungszwecken als Lernsystem zur Verfügung zu stellen. Damit ein möglichst großer Übungseffekt erzielt werden kann, muss die Software in Oberfläche und Funktionen den vorgesehenen Ausprägungen nach dem Go Live entsprechen sowie aktuelle Daten und erforderliche Systemberechtigungen für die Benutzer enthalten.

Lernaufgaben entwerfen

Neben diesen unmittelbar die Software betreffenden Vorbereitungen werden für den Einsatz der Software als Lernsystem auch Lernaufgaben für die einzelnen Benutzergruppen konzipiert, die sich eng an die künftig zu erledigenden Arbeitsaufgaben anlehnen. Um Lernerfolge sicherzustellen, sollten Sie zudem eine Betreuung der Benutzer bei der Arbeit mit dem Lernsystem organisieren.

Vorteile eines Lernsystems

Das Einrichten eines Lernsystems bietet Ihnen neben einer reibungsloseren Inbetriebnahme der Software im Arbeitsalltag der Benutzer noch weitere Vorteile. Zum einen können anhand der Übungsaufgaben, die die Benutzer mit dem Lernsystem durchführen, Schwachstellen der Software auch bei den Prozessen vor dem Go Live entdeckt und beho101

4 Vorgehensmodell zum Usability Management ben werden, die bisher noch nicht von den Benutzern evaluiert wurden (s. Abschnitt 4.2.4), da sie nicht für Usability-Aktivitäten ausgewählt wurden (s. Abschnitt 4.2.1 zu Projektumfang und Projektaufgaben). Zum anderen können Sie den Einsatz des Lernsystems auch dazu nutzen, Informationen über den Stand der Benutzerqualifizierung und die Angemessenheit der Supportangebote zu erhalten. Dadurch gewinnen Sie eine gute Grundlage für die Planung weiterer Maßnahmen der Benutzerunterstützung. Wenn die Benutzer einige Zeit die künftige Art ihrer Aufgabenbearbeitung mittels der SAP-Software am Lernsystem eingeübt haben, können sie sehr viel präzisere Angaben zu eventuellem zusätzlichem Qualifizierungs- bzw. Supportbedarf machen, als dies nach den herkömmlichen Benutzerschulungen der Fall ist. Diese Bedarfe können Sie – beispielsweise mittels Fragebogen – systematisch erheben, um durch zusätzliche Qualifizierungs- und/oder Supportangebote sicherzustellen, dass die Benutzer künftig ihre Aufgaben mit der SAP-Software kompetent, effektiv und effizient bewältigen. Als Ergebnis des Moduls „Schulung“ besitzen die Projektbeteiligten die für sie jeweils erforderlichen software-ergonomischen Kompetenzen, und die Benutzer sind in der Durchführung ihrer Arbeitsaufgaben mit der SAP-Software schon vor dem Go Live geübt.

4.2.6

Go Live & Optimierung In der Phase „Go Live & Optimierung“ bietet sich Ihnen die Möglichkeit, ergonomische Mängel, die erst bei der alltäglichen Arbeit mit der Software offensichtlich werden, zu erfassen und zu beheben. Außerdem schaffen Sie in dieser Phase die organisatorischen Voraussetzungen für einen Prozess der kontinuierlichen Softwareoptimierung. Die Phase „Go Live & Optimierung“ gliedert sich in die Bausteine: •

Test im Echtbetrieb und Optimierung;

•

Ergonomischer Meilenstein 5;

•

KVP (Kontinuierliche Verbesserung).

Der Baustein „Test im Echtbetrieb und Optimierung“ sowie der Ergonomische Meilenstein 5 werden vor dem offiziellen Abschluss des Projektes durchlaufen. Der Baustein „Kontinuierlicher Verbesserungsprozess“ beginnt nach dem offiziellen Projektende.

102

4.2 Das Vorgehensmodell im Überblick Test im Echtbetrieb

Trotz ergonomischer Optimierung vor dem Go Live können im Arbeitsalltag noch bisher unentdeckte Störungen und Fehler bei der Arbeit mit der Software auftreten, oder es zeigt sich, dass die Qualifizierung nicht ausreichend war, der Support nicht optimal unterstützt etc. Wenn Sie auch nach dem Go Live die von den Benutzern als wichtig erachteten Verbesserungsnotwendigkeiten regelmäßig erfassen und umsetzen, so ermöglichen Sie damit auch langfristig effektives, effizientes und zufriedenstellendes Arbeiten mit der SAP-Software. Im Vorgehensmodell zum Usability Management erfolgt daher vor dem Projektabschluss ein Test im Echtbetrieb mit entsprechender nachfolgender Optimierung. Bei dem Test im Echtbetrieb dokumentieren Benutzer im Anschluss an die Produktivsetzung Probleme und Veränderungswünsche bei der Arbeit mit der Software. Die aufgetretenen Probleme werden systematisiert, priorisiert und mit Verbesserungsvorschlägen versehen.

Optimierung

Bei der Optimierung wird die technische und organisatorische Umsetzbarkeit der Verbesserungsvorschläge geprüft, und realisierbare Vorschläge werden umgesetzt. Vor dem offiziellen Ende des Projektes erheben Sie zur Vorbereitung des Meilensteins 5, in welchem Ausmaß die Usability-Ziele des Projektes erreicht wurden.

Ergonomischer Meilenstein 5

In Meilenstein 5 beurteilt das Projektsteuerungsgremium u. a. auf der Basis dieser Bewertungsergebnisse, wieweit die angestrebten Usability-Ziele erreicht wurden und ob aus ergonomischer Sicht der offizielle Projektabschluss befürwortet werden kann. Weiterhin werden ggf. Optimierungsaufträge für die Zeit nach dem Projektabschluss vereinbart.

Kontinuierliche Verbesserung

Die Softwareoptimierung endet beim Usability Management jedoch nicht mit dem Projektabschluss. Wie in Kapitel 1 dargestellt, bezieht sich Usability auf das Zusammenspiel von Benutzer, Aufgaben und Software. Im Lauf der Zeit kann dieses Zusammenspiel vielfältigen Veränderungen unterliegen: Die Erfahrung der Benutzer mit der Software wächst, es können neue Aufgaben hinzukommen, die Software kann aktualisiert werden, neue organisatorische oder gesetzliche Regelungen müssen beachtet werden etc. Um Usability auch langfristig sicherzustellen, ist daher eine kontinuierliche Softwareoptimierung notwendig, wie sie im Baustein „KVP“ (Kontinuierlicher Verbesserungsprozess) im Vorgehensmodell zum Usability Management vorgesehen ist.

103

4 Vorgehensmodell zum Usability Management Dieser Baustein dient dazu, organisatorische Rahmenbedingungen zu schaffen, die es ermöglichen, neue oder veränderte Anforderungen und Verbesserungsvorschläge kontinuierlich zu erheben und umzusetzen. In der Phase „Go Live & Optimierung“ kommen als Methoden beispielsweise Protokollbögen, in denen Benutzer entdeckte Schwachstellen dokumentieren, Benutzerbefragung mittels Fragebogen, sowie Workshops mit Benutzern zum Einsatz. Ergebnis dieser Phase ist zum einen eine vor Projektabschluss nochmals im Produktivbetrieb überprüfte und optimierte Software sowie eine abschließende Beurteilung der erzielten Usability. Zum anderen haben Sie die Voraussetzungen für eine kontinuierliche, langfristige Sicherung der Usability geschaffen.

4.3

Exkurs: Ergonomische Stellschrauben Bei der Beschreibung des Usability Management wird immer wieder auf ergonomische Stellschrauben verwiesen. Was ist darunter zu verstehen?

4.3.1

Was sind ergonomische Stellschrauben?

Umfassendes Verständnis

Unter ergonomischen Stellschrauben können im umfassenden Sinne alle Möglichkeiten der Einflussnahme verstanden werden, die geeignet sind, die Passung zwischen individuellen Benutzern, SAP-Software und konkreter Arbeitsaufgabe zu verbessern. In diesem Sinne fallen unter Stellschrauben nicht nur technische Einstellmöglichkeiten, sondern z. B. auch Schulungsmaßnahmen, die Benutzer in die Lage versetzen, die Software kompetenter bedienen zu können. Dazu gehört auch, die Software – soweit möglich – mit vorhandenen Bedienelementen ihrem individuellen Arbeitsstil anpassen zu können. Neben Schulungen können auch organisatorische Maßnahmen, z. B. wie individuelle Aufgabenzuschnitte und Berechtigungskonzepte sinnvoll aufeinander abzustimmen sind, als ergonomische Stellschrauben im umfassenden Sinne betrachtet werden.

4.3.2

Stellschrauben als technische Einstellmöglichkeiten

Technische Stellschrauben

Im engeren Sinne sind ergonomische Stellschrauben Einstellmöglichkeiten an der SAP-Software, die geeignet sind, software-ergonomische Kriterien wie Aufgabenangemessenheit, Selbsterklärungsfähigkeit, Individualisierbarkeit, Fehlertoleranz etc. zu verbessern.

104

4.3 Exkurs: Ergonomische Stellschrauben Das können beispielsweise Einstellmöglichkeiten sein, um die Darstellung von Feldern auf Bildschirmmasken zu verändern (weniger und/oder andere Felder), um eine voreingestellte Abfolge von Masken anzupassen, um Fehlertexte zu verbessern oder um die Schriftgröße einer Bildschirmdarstellung anzupassen. Wenn nachfolgend von ergonomischen Stellschrauben die Rede ist, bezieht sich das in der Regel auf die technischen Stellschrauben im engeren Sinne. Grundsätzlich können die folgenden vorgesehenen Veränderungsmöglichkeiten der Software als potenzielle Stellschrauben betrachtet werden: •

Anpassungsmöglichkeiten für die Benutzer am individuellen Arbeitsplatz, um z. B. Felder mit Default-Werten vorzubelegen, Zeichengröße oder Cursorverhalten einzustellen etc.;

•

Customizing (Tabellenpflege);

•

Customer-Exits (zusätzliche Entwicklung/Programmierung);

•

Modifikationen (Veränderungen eines Standardprogramms).

Diese Aufzählung macht bereits deutlich, dass einige Stellschrauben von Benutzern direkt am Arbeitsplatz eingesetzt werden können, andere Stellschrauben von Customizern/Administratoren verwendet werden und ein weiterer Teil der Stellschrauben Programmierkompetenz erfordert und eher für Entwickler gedacht ist. Entsprechend ist auch der Aufwand, um mittels Stellschrauben ergonomische Mängel zu beheben, sehr unterschiedlich: bei Anpassungsmöglichkeiten für Benutzer eher gering, bei Modifikationen eher sehr hoch. Letztere lohnen sich daher nur, wenn die resultierenden ergonomischen Verbesserungen einen entsprechend großen Nutzen mit sich bringen, beispielsweise weil sie für eine Vielzahl von Benutzern Zeitersparnisse bedeuten. Kasten 4.5: Stellschrauben (ausgewählte Beispiele) Stellschrauben für Benutzer •

Anlegen von Favoriten in der Menüstruktur, um schneller auf häufig benötigte Transaktionen zugreifen zu können;

•

Anpassen von Spaltenbreiten/Spaltenreihenfolge/Ausblenden von Spalten in der Anzeige von Tabellen;

•

Einstellen des Cursorverhaltens, der Historienanzeige, der Schriftgröße und Farbdarstellung der Bildschirmanzeige.

105

4 Vorgehensmodell zum Usability Management Stellschrauben für Customizer/Administratoren • Ein- und Ausblenden von Feldern; •

Definieren unternehmensspezifischer „Mussfelder“;

•

Anlegen eines rollenspezifischen Benutzermenüs.

Stellschrauben für Entwickler, die keine Modifikation des Standardprogramms erfordern •

Entwickeln unternehmensspezifischer Plausibilitätsprüfungen für Eingabefelder;

•

Einrichten zusätzlicher Eingabefelder auf Bildschirmmasken;

•

Eintragen unternehmensspezifischer Vorschlagswerte für Eingabefelder.

Stellschrauben für Entwickler, die eine Modifikation des Standardprogramms erfordern

4.4

•

Anpassen von Fehlermeldungstexten;

•

Ändern von Feldnamen;

•

Ändern der Feldanordnung auf Bildschirmmasken.

Zusammenfassung und Ausblick In diesem Kapitel haben Sie zentrale Eigenschaften des Usability Management kennengelernt und dabei auch erfahren, in welchem Zusammenhang das Vorgehen beim Usability Management zum herkömmlichen Vorgehen bei der Einführung von SAP-Software steht. Sie haben einen Überblick über die Phasen und Bausteine des Vorgehensmodells zum Usability Management und wie es eingesetzt werden kann, erhalten. Auch ergonomische Stellschrauben als Werkzeuge zur ergonomischen Optimierung von SAP-Software wurden Ihnen vorgestellt. In den nachfolgenden Kapiteln werden Ihnen nun die einzelnen Phasen und Bausteine des Vorgehensmodells zum Usability Management im Detail erläutert – beginnend mit der Phase „Projekteinstieg“ im nächsten Kapitel, in dem Sie erfahren, wie Sie beim Projekteinstieg Rahmenbedingungen für ein erfolgreiches Usability Management schaffen können. Petra Abele und Stefanie Floegel

106

5

Projekteinstieg Im vorigen Kapitel haben Sie in einem Überblick das Vorgehensmodell zum Usability Management kennengelernt. In diesem Kapitel erfahren Sie, wie Sie beim Projekteinstig Rahmenbedingungen für erfolgreiches Usability Management schaffen können. Ziel der Phase „Projekteinstieg“ ist es, dass die verantwortlichen Entscheidungsträger festlegen, welche ergonomischen Projektziele im SAP-Einführungsprojekt erreicht werden sollen, welche ergonomischen Aktivitäten in welchem Umfang dafür erforderlich sind und welche Personen dazu in welcher Art am Einführungsprozess beteiligt werden müssen. Damit die Entscheidungsträger die in dieser Phase notwendigen Entscheidungen kompetent treffen können, ist ihre vorherige Schulung zu Grundlagen und Vorgehen des Usability Management unabdingbar. Alle erforderlichen Rahmenbedingungen verbindlich zu vereinbaren ist ein zentraler Faktor für erfolgreiches Usability Management im SAPEinführungsprojekt. Anderenfalls muss damit gerechnet werden, dass die Aspekte der Software-Ergonomie, wenn Engpässe auftreten, entweder geopfert oder in die Phase nach dem Produktivstart verschoben werden. Die Rahmenbedingungen, unter denen ergonomische Aktivitäten im SAP-Einführungsprojekt stattfinden sollen, dokumentieren Sie in der Projektvereinbarung zum Usability Management. Diese wird in den allgemeinen Projektplan des SAP-Einführungsprojektes integriert, und Sie verabschieden sie im Ergonomischen Meilenstein 1 als verbindliche Grundlage für weitere Aktivitäten im Einführungsprojekt. Die Phase „Projekteinstieg“ beinhaltet die Bausteine: •

Ergonomische Projektziele Sie legen Leitbilder und konkrete Usability-Ziele fest, um Software-Ergonomie als zentrales Qualitätskriterium im Einführungsprojekt zu verankern und den Aufwand für ergonomische Aktivitäten zu legitimieren. Ebenso vereinbaren Sie Kriterien, mit denen die Zielerreichung überprüft werden kann. 109

5 Projekteinstieg •

Projektumfang und Projektaufgaben Sie legen den Projektumfang (einbezogene Benutzergruppen, betrachtete Module/Prozesse etc.) des Usability Management fest und bestimmen, welche Projektaufgaben zur Erreichung der Usability-Ziele bearbeitet werden müssen. Danach schätzen Sie den Aufwand und erstellen eine Zeit- und Budgetplanung.

•

Beteiligung Sie legen in einem Beteiligungskonzept spezifisch für Ihr Projekt fest, welche Zusammensetzung von Projektgremien aus ergonomischer Sicht erforderlich ist, wie die Einbindung des Betriebs-/Personalrates organisiert werden soll und wie die Beteiligung von Beschäftigten, die nicht als Key-User bereits im Einführungsprojekt einbezogen sind, umgesetzt wird.

•

Projektstandards Sie vereinbaren Standardverfahrensweisen und Qualitätsstandards für ergonomische Aktivitäten.

•

Ergonomischer Meilenstein 1 Im Ergonomischen Meilenstein 1 verabschieden Sie die Ergebnisse der Phase „Projekteinstieg“.

5.1

Ergonomische Projektziele

Usability als zentrales Projektziel

Im Vorgehensmodell von SAP ist vorgesehen, dass ein formeller Projektauftrag formuliert und von den Verantwortlichen unterzeichnet wird. Der Projektauftrag soll insbesondere die Projektbzw. Einführungsziele fixieren. Damit Usability als zentrales Ziel des Projektes im Bewusstsein der Projektbeteiligten verankert wird, ist es von entscheidender Bedeutung, dass Sie auch die ergonomischen Ziele des Projektes frühzeitig und verbindlich festlegen. Software-Ergonomie wird in der Praxis in Einführungsprojekten häufig vernachlässigt – und zwar fast immer aus demselben Grund: Das Zeitbudget für die Einführung von SAP ist oft zu knapp kalkuliert. Schon der Projektplan nach der SAP-Einführungsmethodik (ASAP) ist in der Regel so dicht gedrängt, dass er nur eingehalten werden kann, wenn keine unerwarteten Probleme auftreten. Kommt der Zeitplan ins Rutschen, wird das, was für den Produktivstart nicht unbedingt erforderlich ist, häufig geopfert. Ist Software-Ergonomie nicht als zentrales Qualitätskriterium fest im Einführungsprojekt verankert und liegen keine konkreten Zielformulierungen und Kontrollkriterien für die software-

110

5.1 Ergonomische Projektziele ergonomischen Qualitäten der SAP-Einführung vor, ist die Usability gefährdet, wenn Engpässe auftreten. Von Leitbildern zu Detailzielen

Dabei ist es nicht erforderlich, dass Sie die ergonomischen Ziele schon beim Projekteinstieg bis ins Detail festlegen. Vielmehr reicht es, zu Beginn des Projektes die wesentlichen Anforderungen an die Ergonomie in Form von Leitbildern zu formulieren und diese dann im Laufe des Usability Management schrittweise zu konkretisieren. Software-Ergonomie ist nicht alleine die Aufgabe des Projektleiters oder eines einzelnen Teammitglieds. Entscheidend ist, dass alle Projektmitarbeiter motiviert und einbezogen werden. Häufig herrscht allerdings ein sehr unterschiedliches Verständnis darüber vor, was das Ziel des Projektes sein soll und wie es erreichbar ist. Leitbilder, die verbindliche Anforderungen an die ergonomische Qualität des Projektergebnisses formulieren und trotzdem Spielraum bei der Art der Umsetzung lassen, können einen besseren Zusammenhalt und eine konstruktive Zusammenarbeit der Akteure bewirken. Dazu müssen die Ziele verständlich formuliert sein, eine Vorstellung davon vermitteln, wie eine Umsetzung aussehen könnte, und über ein gewisses Maß an Nachprüfbarkeit verfügen. Es ist empfehlenswert, die ergonomischen Ziele des Projektes in einem Workshop des Projektsteuerungsgremiums zu formulieren. Dafür können Sie Formblätter verwenden, in denen die als Leitbild formulierten Ergonomie-Ziele erläutert bzw. konkretisiert werden (s. Abbildung 5.1). Das Leitbild legen Sie als verbindliches, zum Produktivstart zu erfüllendes Qualitätskriterium bereits zu Projektbeginn fest. Weitere Ziele, die dieses Leitbild konkretisieren, formulieren Sie im Projektverlauf abhängig von den Ergebnissen der Anforderungsanalyse, der Sollkonzeption oder der Evaluation von (Teil-) Prozessen in der Realisierungsphase.

Zielworkshop

In einem Zielworkshop untersuchen Sie alle wesentlichen Themen, die bezüglich der Effektivität, der Effizienz und der Zufriedenstellung der Benutzer bei der Arbeit mit der SAP-Software eine Rolle spielen (vergleichen Sie hierzu die Kapitel 2 und 3). Sie stellen fest, was Sie im jeweiligen Themenbereich erreichen wollen, und formulieren entsprechende Usability-Ziele.

Themen für Usability-Ziele

Themen für Usability-Ziele können beispielsweise sein: •

Steigern der Produktivität durch störungsfreie und reibungslose Arbeitsabläufe;

•

Erfüllen von Normen und gesetzlichen Vorgaben; 111

5 Projekteinstieg

Beispiele für Usability-Ziele

Zielvereinbarung

•

Reduzieren von Fehlbelastungen;

•

Herstellen der Akzeptanz und Zufriedenheit der Benutzer.

Abhängig von der Art des Einführungsprojektes und der Situation des jeweiligen Unternehmens ist eine weite Spannbreite von Usability-Zielen denkbar. Je nach Unternehmen können so unterschiedliche Usability-Ziele formuliert werden wie beispielsweise: •

Die einzuführenden Bestandteile der Software (Module) sind so zu gestalten, dass die einschlägige Norm zur Dialoggestaltung (DIN EN ISO 9241-110) erfüllt wird.

•

Usability Management soll sicherstellen, dass die einzuführende CRM-Anwendung auch Außendienstmitarbeiter effektiv bei ihrer Arbeit unterstützt und von ihnen akzeptiert wird.

•

Bei der Einführung sind Software und Arbeitsprozesse aufeinander abgestimmt so zu gestalten, dass arbeitswissenschaftliche Kriterien „guter Arbeit“ erfüllt und Fehlbelastungen der Beschäftigten vermieden werden.

•

Benutzungsoberfläche, Inhalte und Funktionen der Portalanwendung „Managergate“ sind so zu gestalten, dass die Bedienung für Manager, die die Anwendung nur gelegentlich nutzen, leicht erlernbar ist, die Portalanwendung ihre Arbeit effektiv unterstützt und sie diese gerne nutzen.

Die unternehmensspezifisch als Leitbild formulierten UsabilityZiele, die jeweils noch weiter konkretisiert werden – beispielsweise anhand der Vorgaben in dem in Kasten 5.1 dargestellten Formblatt (s. Abbildung 5.1) – müssen von den beteiligten Interessengruppen im Zielworkshop ausgehandelt und verbindlich vereinbart werden. Kasten 5.1: Vereinbarte ergonomische Projektziele (Beispiel) Bildschirmdialoge sollen normgerecht sein In einem Unternehmen des Kreditwesens wurden UsabilityZiele als Leitbild für das SAP-Einführungsprojekt von Betriebsrat, Geschäftsführung und der Fachkraft für Arbeitssicherheit ausgehandelt. Zur Dokumentation der Ziele verwendeten die Beteiligten Formblätter. Für jeden Zielbereich wurden in den Formblättern die Usability-Ziele in der jeweils vereinbarten Zielformulierung festgehalten. Weiterhin konkretisierten die Beteiligten die Ziele in dem Formblatt durch eine nähere Beschreibung und legten fest, wodurch die Ziele erreicht werden sollen und wie die Zielerreichung überprüft werden kann. Die

112

5.1 Ergonomische Projektziele nachstehende Abbildung zeigt beispielhaft ein solches ausgefülltes Formblatt für den Zielbereich „Gestaltung der Bildschirmdialoge.“

Abbildung 5.1: Ausgefülltes Formblatt „Ergonomische Projektziele“ (Beispiel) Die in Zielvereinbarungen dokumentierten Usability-Ziele haben im Einführungsprojekt den gleichen Stellenwert wie die übrigen Projektziele, die bei einem Vorgehen nach ASAP zu Projektbeginn festgelegt wurden. Damit eine Verankerung von UsabilityZielen im Einführungsprojekt gewährleistet ist, muss Usability von der Geschäftsleitung als für das Unternehmen relevanter Produktivitätsfaktor (vgl. Kapitel 2) erkannt sein und entsprechend unterstützt werden (vgl. dazu Abschnitt 5.4.1).

113

5 Projekteinstieg Informationspolitik

Darüber hinaus ist es – unter anderem aus Akzeptanzgründen – sinnvoll, dass Sie das Ergonomieprojekt im Unternehmen bekannt machen und insbesondere die vereinbarten Usability-Ziele auf breiter Basis kommunizieren. Dies kann beispielsweise über regelmäßige Informationen in einer Mitarbeiterzeitschrift oder in dem firmeneigenen Intranet erfolgen. Die vereinbarten UsabilityZiele dienen als Grundlage für Planungs- und Entscheidungsprozesse in den übrigen Bausteinen der Phase „Projekteinstieg“.

5.2

Projektumfang und Projektaufgaben In diesem Baustein bestimmen Sie den Umfang des Usability Management und legen fest, welche ergonomischen Projektaufgaben zur Erfüllung der Usability-Ziele bearbeitet werden müssen, d. h. welche Bausteine der weiteren Phasen des Vorgehensmodells zum Usability Management realisiert werden. Für die einzusetzenden Bausteine vereinbaren Sie anschließend das Ausmaß ergonomischer Aktivitäten, um eine Grundlage für Aufwandsschätzung, Zeit- und Budgetplanung zu haben. Ihr Ziel ist es dabei, eine solide Planungsgrundlage für die Umsetzung ergonomischer Aktivitäten zu schaffen, die abgestimmt ist auf die übrigen Planungen im Einführungsprojekt.

Umfang des Usability Management

Aufbauend auf den vereinbarten Usability-Zielen bestimmen Sie den Umfang des Usability Management. Dafür müssen Sie entscheiden, welche einzuführenden Bestandteile der Software einbezogen werden und ob die Usability-Ziele für alle Benutzer verfolgt werden oder sich auf spezielle Benutzergruppen beschränken. Wenn das Einführungsprojekt mehrere Standorte betrifft, ist außerdem zu entscheiden, ob das Usability Management für alle Standorte realisiert werden soll oder z. B. als Pilotprojekt an einem Standort. Weiterhin legen Sie fest, ob im Rahmen des Usability Management auch eine Reorganisation und ergonomische Aufgabengestaltung nach arbeitswissenschaftlichen Kriterien (vergleichen Sie hierzu die Ausführungen zu DIN EN ISO 9241-2 in Kapitel 3) erfolgen soll oder ob sich die ergonomischen Aktivitäten überwiegend auf die Anpassung der Software beziehen sollen. Je nach unternehmensspezifischen Usability-Zielen sind die Entscheidungen zum Projektumfang in unterschiedlichem Ausmaß bereits festgelegt. In der ersten Beispielformulierung auf Seite 112: „Die einzuführenden Bestandteile der Software (Module) sind so zu gestalten, dass die einschlägige Norm zur Dialoggestaltung (DIN EN ISO 9241-110) erfüllt wird“, ist z. B. schon entschieden, dass sich das Usability Management auf alle Bestand-

114

5.2 Projektumfang und Projektaufgaben teile der Software beziehen soll. Es bleibt jedoch offen, auf welche Benutzergruppen sich das Usability Management beziehen soll. In der dritten Beispielformulierung auf Seite 112 wird als Usability-Ziel formuliert, „bei der Einführung [...] Software und Arbeitsprozesse aufeinander abgestimmt so zu gestalten, dass arbeitswissenschaftliche Kriterien ’guter Arbeit’ erfüllt und Fehlbelastungen der Beschäftigten vermieden werden“. Um dieses Ziel zu erreichen, ist eine ergonomische Aufgabengestaltung unabdingbar, die nicht nur die künftig mit SAP-Software unterstützten Einzelaufgaben betrachtet, sondern die Gesamtheit der Aufgaben in den Aufgabenzuschnitten der Benutzer. Wenn durch die Usability-Ziele der Umfang des Usability Management nicht oder nur teilweise determiniert ist, werden Entscheidungen zum Umfang stärker durch Kriterien wie Aufwand, vorhandenes Zeitkontingent und Budget bestimmt. Auswahl von Kernprozessen

Falls – beispielsweise aus Kapazitätsgründen – nicht alle von der SAP-Einführung betroffenen Kernprozesse des Unternehmens beim Usability Management betrachtet werden können, sollte sich die Auswahl der einzubeziehenden Kernprozesse an einem oder mehreren der folgenden Kriterien orientieren: •

Typische Kernprozesse Um durch das Usability Management einen breit gefächerten Nutzen im Unternehmen zu erzielen, ist es sinnvoll, die Kernprozesse auszuwählen, die künftig von der größten Anzahl an Benutzern bearbeitet werden. Den größten Produktivitätszuwachs gibt es bei der Optimierung der Prozesse mit der häufigsten Durchführung und den größten Nutzerzahlen (z. B. bei dem Prozess der dezentralen Zeiterfassung).

•

Ergebniskritische Kernprozesse Ein weiterer Gesichtspunkt der Nutzenoptimierung besteht darin, Kernprozesse auszuwählen, bei denen das effektive und fehlerfreie Erreichen des Bearbeitungsergebnisses besonders wichtig für den Unternehmenserfolg ist. Dies können beispielsweise Kernprozesse sein, bei denen ein zeitverzögertes oder fehlerhaftes Ergebnis zu erheblichen finanziellen Verlusten führt oder dem Image des Unternehmens beim Kunden schadet (z. B. der Prozess der Bewertung des Auftragsrisikos bei einer Wirtschaftsprüfungsgesellschaft).

•

Abweichende Kernprozesse Es können auch Kernprozesse ausgewählt werden, bei denen bekannt ist, dass sie (teilweise) unter Bedingungen bear115

5 Projekteinstieg beitet werden, die stark von dem im SAP-Standard vorgesehenen Arbeitskontext abweichen. Durch die Einbeziehung solcher Prozesse in das Usability Management kann sichergestellt werden, dass sie dennoch problemlos mit der SAP-Software bearbeitet werden können. Auswahl von Projektaufgaben

Aufwandsschätzung

116

Nachdem Sie den Umfang des Usability Management vereinbart haben, legen Sie fest, welche Projektaufgaben bearbeitet werden müssen, um die Usability-Ziele zu erreichen. Das Vorgehensmodell zum Usability Management ist als Baukastensystem konzipiert. Jeder Baustein sieht fest definierte ergonomische Aktivitäten vor. In Abhängigkeit von den in Ihrem Unternehmen festgelegten ergonomischen Zielen müssen Sie zunächst sukzessive für alle Phasen des Vorgehensmodells feststellen, welche Bausteine durchgeführt werden sollen. Dies setzt natürlich voraus, dass den Entscheidungsträgern die Bausteine des Vorgehensmodells, die in den nachfolgenden Kapiteln detailliert beschrieben werden, bereits zu Projektbeginn bekannt sind. Dies wird am besten durch eine entsprechende Qualifizierung erreicht (mehr dazu erfahren Sie in Kapitel 9). Auch die Notwendigkeit einzelner Bausteine wird durch die unternehmensspezifischen Usability-Ziele in unterschiedlichem Ausmaß bereits vorab festgelegt. Fragen, die sich in diesem Zusammenhang stellen, sind beispielsweise: •

Ist für die Erfüllung der Usability-Ziele das Durchführen einer Benutzerbefragung zur Erhebung von Benutzermerkmalen (vgl. Kapitel 6) zweckmäßig?

•

Sind Aufgabenanalysen an den Arbeitsplätzen von Benutzern (vgl. Kapitel 6) erforderlich?

•

Soll in der Realisierungsphase eine Evaluation der Usability durch Benutzer (vgl. Kapitel 8) erfolgen?

•

Soll nach Projektende ein Kontinuierlicher Verbesserungsprozess (vgl. Kapitel 10) implementiert werden?

Nachdem Sie die zu bearbeitenden Bausteine festgelegt haben, bestimmen Sie anschließend den Umfang der ergonomischen Aktivitäten innerhalb der einzelnen Bausteine, um eine Aufwandsschätzung zu ermöglichen. Hier stellen sich Fragen wie z. B.: •

An wie vielen Arbeitsplätzen soll eine Aufgabenanalyse stattfinden?

•

Wie viele Benutzer sollen an der Evaluation des Sollkonzepts beteiligt werden?

5.2 Projektumfang und Projektaufgaben •

Wie viele Durchläufe durch die Benutzer soll es bei der Evaluation von bereits fertig gestellten Bestandteilen der Software geben?

Die beispielhaft genannten Bausteine bzw. ergonomischen Aktivitäten werden in den nachfolgenden Kapiteln eingehender erläutert. Wenn ein Überblick über den Umfang ergonomischer Aktivitäten in den einzelnen Bausteinen vorliegt, können Sie eine Aufwandsschätzung vornehmen. In Kasten 5.2 wird als Praxisbeispiel die Aufwandsschätzung für das Usability Management im Rahmen einer Machbarkeitsstudie vorgestellt. Kasten 5.2: Aufwandsschätzung für Usability Management im Rahmen einer Machbarkeitsstudie (Praxisbeispiel) Welchen Aufwand erfordert Usability Management bei der Machbarkeitsstudie? Im Rahmen einer Machbarkeitsstudie zur Einführung einer SAP-Anwendung in einem Wirtschaftsprüfungsunternehmen waren folgende Rahmenbedingungen für das Usability Management gesetzt: •

Usability-Ziel war es, Akzeptanz und effektive Unterstützung der Arbeit der Außendienstmitarbeiter zu erreichen.

•

Das Usability Management bezog sich dabei auf eine ausgewählte Kernanwendung bzw. einen zentralen Geschäftsprozess.

•

Ein Schwerpunkt des Usability Management sollte in der ASAP-Phase „Business Blueprint“ auf die Aufgabenanalyse mit drei Benutzern gelegt werden. Daraus sollten ergonomische Anforderungen und das ergonomische Sollkonzept für den ausgewählten Geschäftsprozess abgeleitet werden.

•

In der ASAP-Phase „Realization“, bei der ein Prototyp der Anwendung zu realisieren war, sollte das Projekt durch software-ergonomisches Coaching bei der Arbeitsprozessund Dialoggestaltung sowie durch die Evaluation des Prototypen mit Benutzern unterstützt werden.

•

Die software-ergonomische Optimierung sollte eng mit dem Hauptprojekt verzahnt erfolgen.

Vor dem Hintergrund dieser Rahmenbedingungen ergab sich für die ergonomischen Aktivitäten im Rahmen der Machbar-

117

5 Projekteinstieg keitsstudie ein Gesamtaufwand von 21,5 Tagen. Dieser Gesamtaufwand setzte sich wie folgt zusammen:

Abbildung 5.2: Aufwandsberechung für ergonomische Aktivitäten (Beispiel) Genau wie für alle übrigen Aktivitäten im Rahmen eines Einführungsprojektes führen Sie auch für die ergonomischen Aktivitäten eine Zeit- und Budgetplanung durch. Diese kann nur in enger Abstimmung mit den Planungsprozessen zu herkömmlichen Aktivitäten im Einführungsprojekt erfolgen, da die Aktivitäten zeitlich abhängig voneinander umgesetzt werden müssen. Transparenz herstellen

Bei der Planung der Projektaktivitäten dürfen Sie nicht vergessen, wie wichtig es ist, regelmäßig über das Projekt im Unternehmen zu informieren: Transparenz über Projektaktivitäten und -fortschritte trägt ganz wesentlich dazu bei, den Beschäftigten Angst und Unsicherheiten darüber zu nehmen, was auf sie zukommen wird. Rechtzeitige Information über anstehende Aufgaben, an denen die Beschäftigten beteiligt werden sollen, bereitet sie auf die Mitarbeit vor und erhöht ihre Motivation zur aktiven Mitarbeit.

5.3

Beteiligung Ziel dieses Bausteins ist es, die für ein erfolgreiches Usability Management im Einführungsprojekt erforderliche Beteiligung verschiedener Personengruppen und Funktionsträger zu organisieren. Um dieses Ziel zu erreichen, sind folgende Aspekte wichtig:

118

5.3 Beteiligung •

Zusammensetzung der Projektgremien Die Gremienzusammensetzung muss bestimmten Anforderungen genügen, um sicherzustellen, dass das Usability Management auch in der Aufbauorganisation des SAP-Einführungsprojektes verankert ist.

•

Einbinden des Betriebs-/Personalrates Ein frühzeitiges Einbinden des Betriebs-/Personalrates gewährleistet das Erfüllen gesetzlicher Mitbestimmungspflichten sowie die Berücksichtigung von im Unternehmen bereits vorhandenen Betriebsvereinbarungen und sichert die Unterstützung der Personalvertretung im Hinblick auf Usability-Aktivitäten.

•

Beteiligung der Beschäftigten Nur über eine Beteiligung der künftigen Benutzer, die über das herkömmliche Key-User-Konzept in SAP-Einführungsprojekten hinausgeht, lassen sich Usability-Ziele erfolgreich realisieren.

•

Beteiligungskonzept Als Ergebnis des Bausteins „Beteiligung“ müssen alle zu den vorstehend genannten Aspekten getroffenen Entscheidungen und ausgehandelten Vereinbarungen in einem Beteiligungskonzept dokumentiert werden. Das im Ergonomischen Meilenstein 1 als Bestandteil des Projektplans verabschiedete Beteiligungskonzept bildet eine für alle Interessengruppen im Unternehmen verbindliche Grundlage für das weitere Vorgehen im Projekt.

In den nachfolgenden Abschnitten wird auf diese Aspekte vertiefend eingegangen.

5.3.1

Zusammensetzung der Projektgremien

Usability verankern

Wie erfolgreich Sie die Ergonomieziele des Projektes umsetzen können, hängt u. a. davon ab, wie gut es Ihnen gelingt, das Thema Usability im täglichen Projektgeschäft des SAP-Einführungsprojektes zu verankern. Dabei ist nicht nur die Beteiligung der Beschäftigten und des Betriebs-/Personalrates zu bedenken, auf die in den nachfolgenden Abschnitten eingegangen wird. Wichtig ist ebenfalls, wie und wo betriebliche Protagonisten als Promotoren in Sachen Ergonomie in der Aufbauorganisation des Projektes wirken können und wie die Entscheidungsstrukturen im Projekt gestaltet sind.

119

5 Projekteinstieg Koordination durch den Projektleiter

Generell ist Usability Sache aller Projektbeteiligten. Jedoch können in unterschiedlichen Phasen unterschiedliche Akteure für die Umsetzung von ergonomischen Aktivitäten zuständig sein. Entscheidungsbefugnisse bei Konflikten mit Usability-Zielen (z. B. wenn Anpassungen der SAP-Software vorgesehen sind, die die Usability gefährden) sollten Sie in der Hierarchie so weit oben wie möglich ansiedeln. Die Verantwortung für die Koordination der Umsetzung von Usability-Aktivitäten liegt sinnvollerweise während des gesamten Einführungsprozesses beim Projektleiter bzw. bei den Teilprojektleitern. Der Projektleiter sollte befugt sein, bei Bedarf zur Umsetzung von ergonomischen Aktivitäten auch externe Ergonomieexperten, z. B. einen Usability-Berater, hinzuzuziehen.

Unterstützung durch die Geschäftsleitung

Wünschenswert ist in diesem Zusammenhang, dass die Geschäftsführung ihren Willen zur Usability nicht nur äußert, sondern auch deutlich demonstriert, indem sie beispielsweise ein Mitglied, das von der Wichtigkeit von Usability überzeugt ist, in das Steuerungsgremium des Einführungsprojektes entsendet. Agiert ein Mitglied der Geschäftsleitung als Usability-Promotor, kann darüber auch die erforderliche Rückendeckung des Projektleiters sichergestellt werden, die dieser, will er Usability auch in turbulenten Phasen des Projektes auf der Tagesordnung behalten, unter Umständen dringend benötigt. Weiterhin sollten Sie die Aufbauorganisation des SAP-Einführungsprojektes so gestalten, dass möglichst in allen Projektgremien Personen sitzen, die Usability-Kenntnisse und entsprechende Umsetzungsbefugnisse für diesen Bereich besitzen. Darüber hinaus muss eine angemessene Vertretung des Betriebs-/ Personalrates in allen Projektgremien gewährleistet sein. Wie diese Vertretung umgesetzt wird, muss vor dem Hintergrund der vorhandenen Mitbestimmungskultur im Unternehmen projektspezifisch festgelegt werden. Ein Einbinden des Betriebs-/Personalrates auch in die formale Aufbauorganisation des SAP-Einführungsprojektes empfiehlt sich jedoch aus mehreren Gründen, die im nächsten Abschnitt dargelegt werden.

120

5.3 Beteiligung

5.3.2

Einbindung des Betriebs-/Personalrates Ein frühzeitiges Einbinden des Betriebs-/Personalrates in das Einführungsprojekt bietet mehrere Vorteile:

Gesetzliche Mitbestimmungspflichten

•

Erfüllen gesetzlicher Mitbestimmungspflichten;

•

frühzeitiges Berücksichtigen bestehender Betriebsvereinbarungen insbesondere zur Einführung von Informations-undKommunikations-Systemen (IuK);

•

Unterstützen der Usability-Aktivitäten durch den Betriebs-/ Personalrat.

Information, Beratung und Mitbestimmung des Betriebs-/Personalrates sind bei der SAP-Einführung eine im Betriebsverfassungsgesetz (z. B. § 87 Absatz 1 Satz 6, § 87 Absatz 1 Satz 7) festgelegte gesetzliche Pflicht des Arbeitgebers. Themen wie Umstrukturierung der Arbeit, Qualifizierung, Versetzungen, Gesundheitsschutz an Bildschirmarbeitsplätzen, Mehrarbeit, Datenschutz können im Unternehmen nicht ohne die Beteiligung des Betriebs-/Personalrates entschieden werden. Ein Blick in im Unternehmen bereits bestehende Betriebsvereinbarungen gibt unter Umständen wichtige Hinweise zur Vereinbarung des Beteiligungskonzeptes für das Usability Management. Insbesondere die häufig in Betrieben bestehenden Betriebsvereinbarungen zur Einführung von IuK-Systemen beinhalten oft detaillierte Verfahrens- und Schutzregelungen, die es zu berücksichtigen gilt. Verfahrensregelungen geben vor, wie beim Einführungsprozess eines neuen IuK-Systems oder bei Veränderungen bereits bestehender Systeme vorzugehen ist, um die Mitbestimmungspflichten zu erfüllen. Die Verfahrensregelungen enthalten oft detaillierte Vorgaben zur Beteiligung des Betriebs-/Personalrates und der Beschäftigten. Derartige Vorgaben können beispielsweise festlegen, auf welche Informationen der Betriebs-/ Personalrat und die Beschäftigten Anspruch haben, welche Projektaktivitäten der Mitbestimmung unterliegen und bei welchen Projektaktivitäten der Betriebs-/Personalrat oder die Beschäftigten zu beteiligen sind. Schutzregelungen hingegen zielen eher auf die einzuhaltenden Rahmenbedingungen des Produktivbetriebs ab. Sie beinhalten Vorgaben, die die Beschäftigten gegenüber eventuellen negativen Folgen einer EDV-Einführung absichern sollen. Solche Vorgaben regeln beispielsweise häufig, wie mit Rationalisierungseffekten umgegangen wird oder welche Maßnahmen zum Schutz der Beschäftigten vor Leistungs- und Verhaltenskontrolle zu ergreifen sind. Damit die im Unterneh121

5 Projekteinstieg men bereits vereinbarten Verfahrens- und Schutzregelungen von Anfang an eingehalten werden, ist es wichtig, sich schon bei Projektbeginn über die Einbindung des Betriebs-/Personalrates zu verständigen. Die im Kasten 5.3 dargestellte Aufzählung vermittelt einen Überblick, zu welchen Themen es in Betriebsvereinbarungen zur Einführung von IuK-Systemen häufig Verfahrens- und/oder Schutzregelungen gibt. Kasten 5.3: Themen für Verfahrens- und Schutzregelungen in Betriebsvereinbarungen zur Einführung von IuK-Systemen Verfahrensregelungen •

Information, Beratung und Mitbestimmung im Projektverlauf

•

Mitbestimmungsvorbehalt bei einzelnen Softwarekomponenten

•

Bereitstellung eines Sachverständigen für den Betriebs-/ Personalrat

•

Qualifizierungsplanung

•

Beteiligung der Arbeitnehmer

•

Kontrollrechte des Betriebs-/Personalrates

Schutzregelungen

Unterstützung durch den Betriebs-/ Personalrat

122

•

Rationalisierungsschutz, Arbeitsplatzgarantie, Umschulung

•

Gesundheitsschutz (z. B. Arbeitsplatzanalyse gemäß Bildschirmarbeitsverordnung, Bildschirmpausen)

•

Regelungen zur Verarbeitung von Leistungs- und Verhaltensdaten

•

Vertretungsregelungen, Regelungen zur Arbeitsentlastung während Projektlaufzeit

•

Grundsätze zur Arbeitsgestaltung und Arbeitsorganisation

Ein frühzeitiges Einbinden des Betriebs-/Personalrates kann auch die Umsetzung geplanter Veränderungen erleichtern. Maßnahmen – insbesondere wenn sie tiefgreifende Veränderungen der Arbeitsplätze mit sich bringen – werden von den Beschäftigten oft eher akzeptiert, wenn der Betriebs-/Personalrat diese Maßnahmen befürwortet und begleitet. Zudem sind Betriebs-/ Personalräte Ansprechpartner bei Ängsten und Vorbehalten von Beschäftigten. Sie wissen häufig um bereits bestehende Probleme an den von der SAP-Einführung betroffenen Arbeitsplätzen und

5.3 Beteiligung Benutzerzentrierte Perspektive

können die daraus resultierenden Bedürfnisse der Beschäftigten teilweise besser einschätzen als die betrieblichen Führungskräfte. Der Betriebs-/Personalrat kann daher wichtige Hinweise geben, wie Beschäftigte, insbesondere die betroffenen Benutzer, informiert und eingebunden werden sollten. Die Einbeziehung des Betriebs-/Personalrates kann also helfen, die Beschäftigten zur Unterstützung der Usability-Bemühungen des Projektes zu motivieren und die für die SAP-Einführung notwendige Beteiligung der Beschäftigten zu sichern.

5.3.3

Beteiligung der Beschäftigten Usability lässt sich nur erzielen, wenn Sie bei der SAP-Einführung die Beschäftigten auch über das Key-User-Konzept hinausgehend an der Anpassung der SAP-Software in Ihrem Unternehmen beteiligen. Das Wissen über die Einzelheiten der Arbeitsabläufe und über die Praktikabilität von Umstrukturierungsvorschlägen muss bei den Beschäftigten selbst erfragt werden. Dazu sollten diese nicht nur ihr Arbeitsplatzwissen einbringen, sondern ist es sinnvoll, darüber hinaus ihre Gestaltungsvorschläge und Veränderungswünsche zu ermitteln. Beim Usability Management spielt die Benutzerbeteiligung eine zentrale Rolle. Während beim herkömmlichen Customizing die Geschäftsprozesse im Vordergrund stehen, steht beim Usability Management die Perspektive der Benutzer und deren Arbeitskontext im Zentrum. Dies gilt nicht nur für die erforderlichen Anpassungen der SAP-Software vor dem Go Live, sondern auch für den nachfolgenden Produktivbetrieb. Eine konsequente und notwendige Fortsetzung der ergonomischen Aktivitäten vor der Produktivsetzung ist die kontinuierliche Verbesserung der SoftwareErgonomie nach dem Go Live, die schon in der Projekteinstiegsphase mitbedacht werden sollte. Durch eine breite Beteiligung der künftigen Benutzer im Einführungsprozess schaffen Sie auch die Basis für das spätere erfolgreiche Etablieren eines Kontinuierlichen Verbesserungsprozesses (s. Kapitel 10). Eine realistische Kapazitäts- und Zeitplanung für das Usability Management ist eine wichtige Voraussetzung für eine funktionierende Beteiligung. Damit diese reibungslos ablaufen kann, sind jedoch weitere Voraussetzungen zu erfüllen, auf die nachfolgend eingegangen wird.

Einwände gegen Benutzerbeteiligung

In vielen Unternehmen gibt es Vorurteile gegen eine Beteiligung der Beschäftigten, selbst wenn Mitarbeiterbeteiligung als Erfolgsfaktor moderner Unternehmensführung propagiert wird. Ein sol123

5 Projekteinstieg ches Vorurteil ist beispielsweise die Auffassung, dass Beschäftigtenbeteiligung mit unverhältnismäßig hohem Zeitaufwand verbunden ist, zu langwierigen und ziellosen Diskussionen führt und in überhöhten Ansprüchen resultiert. Auch externe Projektberater warnen oft davor, dass durch zu viel Beteiligung Wünsche und Vorstellungen geweckt werden, die unter Umständen wegen zu hoher Kosten, einer Gefährdung der mit der SAP-Einführung angestrebten Integrationsziele oder aus technischen Gründen nicht umgesetzt werden können. Die Folge wäre aus dieser Sicht zwangsläufig ein Akzeptanzverlust aufgrund enttäuschter Erwartungen. Unsere Erfahrungen in Projekten zum Usability Management zeigen jedoch, dass sich solche Vorurteile und Befürchtungen nicht bestätigen, sondern bei sorgfältiger Planung und Umsetzung Beschäftigtenbeteiligung erfolgreich realisiert werden kann. Usability Management, bei dem der Arbeitskontext der Benutzer eine entscheidende Rolle spielt, ist ohne Beteiligung der Benutzer nicht denkbar. Beispielsweise lassen sich nur mit Unterstützung der Beschäftigten frühzeitig ergonomische Anforderungen ermitteln, die sich aus dem Nutzungskontext im Arbeitsalltag ergeben. Auch ergonomische Schwachstellen des Sollkonzepts oder bereits realisierter Bestandteile der Software können nur unter Beteiligung künftiger Benutzer, die nicht bereits als Key-User im Projektteam involviert sind, aufgedeckt werden. Daher müssen Sie Einwände gegen eine Benutzerbeteiligung im Einführungsprojekt aufgreifen und entkräften, um Usability Management erfolgreich durchführen zu können. Beteiligungsregeln Erfolgreiche Beteiligung der Beschäftigten erfordert nicht nur zeitliche Freiräume, sondern auch „Spielregeln“ für die Beteiligungsprozesse. Diese Regelungen vereinbaren Sie nach Möglichkeit zu Beginn des Usability Management im Beteiligungskonzept. Solche Beteiligungsregeln sind beispielsweise: •

Freiwilligkeit der Teilnahme an Beteiligungsprozessen;

•

Durchführung von Beteiligungsprozessen während der Arbeitszeit;

•

Arbeitsentlastung während der Beteiligungsprozesse;

•

Genehmigung der Teilnehmer, die Ergebnisse der Beteiligungsprozesse weiterzugeben;

•

Bearbeitung aller Verbesserungsvorschläge durch die Entscheidungsträger und Begründungspflicht bei Ablehnungen.

Zudem bedarf die Beteiligung der Beschäftigten einer geeigneten formalen Beteiligungsstruktur, die in die Aufbauorganisation des 124

5.3 Beteiligung Einführungsprojektes eingebunden sein muss. Wie die Beteiligung der Beschäftigten organisiert werden kann, ist von Unternehmen zu Unternehmen unterschiedlich und wird u. a. von der bisherigen Beteiligungskultur im Unternehmen abhängen. Damit von Anfang an Klarheit darüber besteht, wie und in welchem Umfang Beteiligung im Usability Management praktiziert werden soll, empfiehlt es sich, eine projektspezifische Beteiligungsstruktur festzulegen und diese ebenfalls im Beteiligungskonzept zu dokumentieren.

5.3.4

Beteiligungskonzept

Rahmenbedingungen dokumentieren

Im Beteiligungskonzept dokumentieren Sie u. a., in welchen Projektphasen Benutzer und/oder der Betriebs-/Personalrat zu beteiligen sind. Sinnvollerweise wird dies mit einer entsprechenden Aufwandsabschätzung hinterlegt und hinsichtlich der Zeitpunkte im Projektverlauf angemessen geplant. Im Beteiligungskonzept legen Sie somit auch verbindlich fest, welche zusätzlichen Ressourcen/Kapazitäten für die Durchführung des Usability Management von den betroffenen Unternehmensbereichen bereitgestellt werden müssen. Um späteren Diskussionen über die Notwendigkeit der Benutzerbeteiligung vorzubeugen, sollten Sie die Vorgesetzten der betroffenen Unternehmensbereiche und externe SAP-Berater frühzeitig über die Inhalte des Beteiligungskonzepts informieren. Wie Sie eine Beteiligung von Beschäftigten, die nicht als KeyUser dem Projektteam angehören, im Projektverlauf inhaltlich umsetzen, wird in der Beschreibung der weiteren Phasen des Vorgehensmodells in den nachfolgenden Kapiteln jeweils dargelegt.

125

5 Projekteinstieg Zeitpunkte der Beteiligung

Wichtige Zeitpunkte der Beteiligung im Usability Management sind in folgender Tabelle dokumentiert. Projektphase

Beteiligungsthema

Projekteinstieg

•

Festlegen ergonomischer Projektziele

•

Regeln der Beteiligung

•

Analyse des Nutzungskontextes

•

Zusammentragen und Priorisieren ergonomischer Anforderungen aus dem Arbeitsalltag der Beschäftigten

•

Workshop(s) zur Arbeitsprozess- und Dialoggestaltung

•

Evaluation des Sollkonzeptes mit Benutzern

•

Evaluation von (Teil-)Prozessen mit Benutzern

•

Evaluation organisatorischer mit Benutzern

•

Benutzer vertiefen die SAP-gestützte Aufgabenbearbeitung am Lernsystem

•

Software-ergonomische für Projektbeteiligte

•

Überprüfen/Optimieren der ergonomischen Qualität der eingeführten SAP-Software

•

Kontinuierlicher Verbesserungsprozess (KVP)

Anforderungsanalyse

Sollkonzeption

Realisierung

Schulungen

Go Live & Optimierung

Abläufe

Qualifizierung

Tabelle 5.1: Beteiligungszeitpunkte und -themen im Usability Management Beteiligungsstruktur

Neben der Berücksichtigung des passenden zeitlichen Verlaufs von Beteiligung wird vor allem die Beteiligungsstruktur als organisatorischer Rahmen der Beteiligung im Einführungsprojekt im Beteiligungskonzept dokumentiert und nach Möglichkeit mit dem Betriebs-/Personalrat vereinbart. Wie eine solche Beteiligungsstruktur aussehen kann, schildert das Praxisbeispiel in Kasten 5.4. Nicht immer muss diese so aufwändig sein. Wichtig ist jedoch in jedem Fall, dass:

126

5.3 Beteiligung •

künftige Benutzer in ausreichendem Maße beteiligt werden;

•

der Informationsfluss zwischen den beteiligten Benutzern und dem Projekt reibungslos funktioniert;

•

der Betriebs-/Personalrat eingebunden ist.

Kasten 5.4: Vereinbarte Beteiligungsstruktur (Praxisbeispiel) Koordination der Beteiligung im Einführungsprojekt Bei einem großen Nahrungsmittelhersteller wurde die nachfolgend beschriebene und in Abbildung 5.3 veranschaulichte Beteiligungsstruktur für das SAP-Einführungsprojekt vereinbart. An der Spitze des Projektes stand die Geschäftsleitung (GL). Die strategische Planung und Steuerung des Projektes erfolgte im Projektsteuerungsgremium, dem auch ein Mitglied der Geschäftsleitung angehörte. Damit sollte sichergestellt werden, dass Entscheidungen des Steuerungsgremiums strategisch und politisch von Unternehmensseite getragen werden. Weitere Mitglieder im Projektsteuerungsgremium sind z. B. der betriebliche SAP-Projektleiter (PL) und die Abteilungsleiter. Die operative Steuerung des Projektes oblag dem Projektteam, das die nächste Ebene bildete. Weisungen des Projektsteuerungsgremiums wurden im Projektteam besprochen, und es wurde vereinbart, wie die SAP-Umsetzung geschehen sollte. Das gesamte Einführungsprojekt war über mehrere SAP-Teilprojekte (TP 1 … n) organisiert, die jeweils von Teilprojektleitern verantwortet wurden. Die Teilprojektleiter setzten in diesen kleinen Teilprojekten mit Teams aus ca. fünf Personen die im Projektteam formulierten Anforderungen und Ziele um. Eine Besonderheit bildete in diesem Beteiligungskonzept die Gruppe der Koordinatoren. Dabei handelte es sich um von Geschäftsführungs- und Betriebsratsseite einvernehmlich ernannte Beschäftigtenvertreter, die nicht direkt im Projektteam mitarbeiteten, aber über eine enge Kooperation mit den Teilprojektleitern intensiv in das Projekt eingebunden waren. Ihre Aufgabe war die Umsetzung der Beteiligung der Beschäftigten an vorher festgelegten Projektaufgaben. Eine solche Projektaufgabe, für deren Planung, Organisation und Durchführung die Koordinatoren zuständig waren, war beispielsweise die Evaluation von bereits fertig gestellten Bestandteilen der Software durch die Beschäftigten. Die Koordinatoren stellten zudem das Bindeglied zwischen den Beschäftigten und den verschiedenen Projektgremien dar. Auf der einen Seite leiteten sie 127

5 Projekteinstieg Anregungen, Ideen und Beschwerden der Beschäftigten an die Teilprojektleiter weiter und wurden von diesen über den Fortgang des Projektes informiert. Auf der anderen Seite informierten sie auch den Betriebsrat über Anliegen der Beschäftigten, berieten mit ihm und wurden auch aus seiner Sicht über den Fortgang des Projektes informiert.

Abbildung 5.3: Beteiligungsstruktur (Fallbeispiel) Inhalte des Beteiligungskonzepts

Als Ergebnis des Bausteins „Beteiligung“ vereinbaren Sie ein Beteiligungskonzept, in dem vor allem •

die Zusammensetzung der Projektgremien,

•

die Zeitpunkte im Projektverlauf und die Themen, zu denen der Betriebs-/Personalrat eingebunden wird,

•

die Zeitpunkte, Themen und benötigten Kapazitäten für die Benutzerbeteiligung im Projektverlauf,

•

die formale Beteiligungsstruktur,

•

die Verfahrensregeln („Spielregeln“) zur Beteiligung Beschäftigter

dokumentiert sind.

128

5.4 Projektstandards

5.4

Projektstandards

Qualität sichern

In der SAP-Einführungsmethodik (ASAP) ist in der Phase der Projektvorbereitung die Definition von Projektstandards vorgesehen. Auch im Hinblick auf das Usability Management müssen Standards vereinbart werden. Der Baustein „Projektstandards“ im Vorgehensmodell zum Usability Management soll sicherstellen, dass die ergonomischen Aktivitäten qualitativen Mindestkriterien genügen und einheitlich gehandhabt werden. Einige wichtige Fragestellungen zu Projektstandards für ergonomische Aktivitäten sind beispielsweise: •

•

•

•

•

Informations- und Kommunikationswege –

Wer muss aus ergonomischer Perspektive wann, in welcher Weise und durch wen über Aktivitäten im Einführungsprojekt informiert werden?

–

Wie sind offene Fragen und Veränderungsvorschläge zur Usability im Einführungsprojekt zu behandeln?

Rahmenbedingungen für die Benutzerbeteiligung –

Mit welchen Kommunikationsmitteln müssen Projekträume ausgestattet sein?

–

In welcher Weise werden Benutzer für die Beteiligung an dem Einführungsprojekt von ihren Standardaufgaben entlastet?

Qualifizierung –

Wie müssen Schulungsunterlagen aufgebaut sein?

–

Wer ist wann zum Thema Software-Ergonomie zu schulen?

Dokumentation des Usability Management –

In welchem Format sind Dokumente abzuspeichern?

–

Wo sind Dokumente abzuspeichern?

–

Wer darf Dokumente, die das Usability Management betreffen, ändern?

Behandlung software-ergonomischer Fragen und Vorschläge –

Wie werden Veränderungsvorschläge gesammelt?

–

Nach welchen Regeln werden Veränderungsvorschläge bewertet und umgesetzt?

129

5 Projekteinstieg •

Ergonomische Meilensteine –

Nach welchen Kriterien werden Entscheidungen bei Ergonomischen Meilensteinen getroffen (z. B. Erfüllungsgrad der ergonomischen Aufgabenpakete als Kriterium für die Freigabe)?

–

Wann und wie wird über den Beginn der nächsten Phase des Usability Management entschieden?

Die Projektstandards und Verfahrensweisen für das Usability Management vereinbaren und dokumentieren Sie zusammen mit den Standards für die herkömmlichen Aktivitäten im Einführungsprojekt. Die erforderlichen Planungen, Aushandlungen und Vereinbarungen können Sie im Rahmen der regulären Sitzungen des Steuerungsgremiums des Einführungsprojektes behandeln.

5.5

Ergonomischer Meilenstein 1

Projektplan zum Usability Management

Das Ergebnis der Phase „Projekteinstieg“ im Vorgehensmodell zum Usability Management ist der schriftlich dokumentierte verbindliche Projektplan für das Usability Management, der mit den übrigen geplanten Aktivitäten im SAP-Einführungsprojekt verzahnt und abgestimmt ist. Der Projektplan zum Usability Management beinhaltet: •

die ergonomischen Zielvereinbarungen;

•

die Vereinbarung zum Projektumfang und zu den Projektaufgaben des Usability Management inkl. Aufwandsschätzung, Zeit- und Budgetplanung;

•

die vereinbarten Projektstandards für das Usability Management;

•

das Beteiligungskonzept.

Auf der Grundlage des unternehmensspezifischen Projektplans zum Usability Management überprüfen die Mitglieder des Steuerungsgremiums im Ergonomischen Meilenstein 1 die Vollständigkeit und Angemessenheit der entsprechenden Planungen. In den meisten Fällen bietet es sich an, den Ergonomischen Meilenstein 1 zusammen mit dem Meilenstein der ASAP-Phase „Project Preparation“ des Einführungsprojektes zu bearbeiten. Der Projektplan zum Usability Management als Bestandteil des Gesamtprojektplans stellt dann die verbindliche Grundlage für die ergonomischen Aktivitäten im Einführungsprozess dar und

130

5.6 Zusammenfassung und Ausblick kann von allen Projektbeteiligten als Richtschnur und Orientierungspunkt genutzt werden. Mit der Verabschiedung des Projektplans zum Usability Management erfolgt auch die Freigabe für die Phase „Anforderungsanalyse“.

5.6

Zusammenfassung und Ausblick Sie haben in diesem Kapitel die Rahmenbedingungen kennengelernt, die Sie zu Projektbeginn für ein erfolgreiches Usability Management vereinbaren müssen. Sie wissen, dass Sie sich mit den betroffenen Interessengruppen in Ihrem Unternehmen über Usability-Ziele für die SAP-Einführung verständigen müssen. Sie können den Projektumfang und die Projektaufgaben für das Usability Management festlegen, ein Beteiligungskonzept für die SAPEinführung in Ihrem Unternehmen entwickeln und Projektstandards für die ergonomischen Aktivitäten erarbeiten. Weiterhin wissen Sie, dass die ergonomischen Ziele, die Festlegung des Projektumfangs und der Projektaufgaben, die Projektstandards für die ergonomischen Aktivitäten und das Beteiligungskonzept in einem Projektplan zum Usability Management nachvollziehbar dokumentiert und verbindlich vereinbart werden müssen, bevor eine neue Phase des Usability Management in Angriff genommen werden kann. Im nächsten Kapitel erfahren Sie mehr über die ergonomischen Aktivitäten in der Phase „Anforderungsanalyse“, die im Vorgehensmodell zum Usability Management auf die in diesem Kapitel vorgestellte Phase „Projekteinstieg“ folgt. Petra Abele und Bernd Stein

131

6

Anforderungsanalyse Im vorigen Kapitel „Projekteinstieg“ haben Sie erfahren, wie Usability-Aktivitäten bei der SAP-Einführung geplant, abgestimmt und begonnen werden. In diesem Kapitel erfahren Sie, wie Sie die ergonomischen Anforderungen an eine SAP-Software erheben können und welche Inhalte dabei wichtig sind. Das Ziel der Phase „Anforderungsanalyse“ ist es, Anforderungen an die SAP-Software aus Benutzersicht zu generieren. Damit kommen – getreu dem Modell des Usability Management – zu den technischen und betriebswirtschaftlichen Anforderungen, die bei der SAP-Einführung standardmäßig erhoben werden, ergonomische Anforderungen hinzu. Das Ergebnis dieser Phase besteht in der Dokumentation des Nutzungskontextes und den sich daraus ergebenden Anforderungen, die im Ergonomischen Meilenstein 2 von der Steuerungsgruppe abgestimmt werden. Warum gehen wir im Modell des Usability Management so detailliert auf die Analyse von Anforderungen ein? Reichen hier nicht die üblichen Datenerhebungen in der ASAP-Phase „Business Blueprint“, nach denen dann die SAP-Software angepasst wird? Nein, denn bei den herkömmlichen Methoden zur Anforderungsanalyse liegt der Fokus stark auf Informationen zur Gestaltung von Datenstruktur und Funktionen der Software – sie bewegen sich somit auf einer aus Nutzersicht theoretischen, abstrakten Ebene. Dagegen werden Informationen zur Unterstützung der tatsächlichen Arbeitsaufgaben konkreter Benutzer in ihrem Arbeitsumfeld oft nicht ausreichend berücksichtigt. Aus ergonomischem Blickwinkel geht es vor allem darum, die Arbeit der Benutzer mit SAP-Software effektiv, effizient und zufriedenstellend zu gestalten (mehr dazu haben Sie in Kapitel 2 erfahren). Dabei müssen folgende Aspekte berücksichtigt werden: die Ziele und Handlungen der Benutzer, die Kooperation mit Kollegen und anderen Abteilungen, die bei der Ausführung der Arbeit verwendeten Begrifflichkeiten und die bei der Arbeit verwendeten Hilfsmittel wie z. B. Akten und Formulare. Die folgende Tabelle soll Ihnen die unterschiedlichen Schwerpunkte der beiden Ansät133

6 Anforderungsanalyse ze zur Anforderungsanalyse, des herkömmlichen und des ergonomischen, veranschaulichen. Herkömmliche Anforderungsanalyse

Ergonomische Anforderungsanalyse

Hauptziel

Erheben von Anforderungen zur Gestaltung von Prozessen und Datenstrukturen der SAP-Software

Erheben von Anforderungen für die Gestaltung der Mensch-ComputerInteraktion

Analyseobjekte

Daten und Funktionen, Tatsächliche ArbeitsaufGeschäftsprozesse aus gaben im Arbeitsumfeld der betriebswirtschaftlicher Sicht Benutzer

Fokus

Geschäftsprozess-Sicht: technische Informationen, betriebswirtschaftliche Informationen, Key Performance Indicators etc.; SAP-gestützte Arbeit

Aufgaben- und benutzerzentrierte Sicht: Nutzungsinformationen, Benutzereigenschaften, Aufgabenmerkmale, Umgebungseigenschaften; SAP-gestützte Arbeit im Kontext aller anderen Arbeitsaufgaben

Ergebnis

Tabelle 6.1

Business Blueprint (Funktions- und Datenmodelle)

Dokumentierter Nutzungskontext und daraus abgeleitete ergonomische Anforderungen

Vergleich von herkömmlicher und ergonomischer Anforderungsanalyse bei der Einführung von SAPSoftware

Folgende Bausteine finden Sie in der Phase „Anforderungsanalyse“: •

Nutzungskontextanalyse: Aufgaben, Benutzer, Technik Konkrete ergonomische Anforderungen ergeben sich aus der Analyse des Nutzungskontextes. Daten zum Nutzungskontext können Sie mittels verschiedener Methoden – vom Fragebogen bis zur Aufgabenanalyse am Arbeitsplatz – erheben. Ziel ist es, alle für die spezifische SAP-Einführung relevanten Merkmale der Aufgaben, der Benutzer und der Technik zu berücksichtigen.

134

6.1 Nutzungskontextanalyse: Aufgaben, Benutzer, Technik •

Anforderungen Aus der Analyse des Nutzungskontextes müssen Sie die ergonomischen Anforderungen an die Software ableiten, zusammentragen, priorisieren und dokumentieren.

•

Ergonomischer Meilenstein 2 Im Ergonomischen Meilenstein 2 verabschieden Sie die Ergebnisse der Phase „Anforderungsanalyse“.

Diese Bausteine werden in den folgenden Abschnitten näher erläutert.

6.1

Nutzungskontextanalyse: Aufgaben, Benutzer, Technik Das Ziel des Bausteins „Nutzungskontextanalyse: Aufgaben, Benutzer, Technik“ ist es, einen Überblick über die ergonomisch relevanten Merkmale der zukünftigen Benutzer der SAP-Software, ihrer Arbeitsaufgaben und -bedingungen zu bekommen.

Ziele

Es gibt nicht „die SAP-Software“, die auf alle Aufgaben, Benutzer und technischen Umgebungen passt. Die verschiedenen Einstellund Anpassungsmöglichkeiten, die in einer SAP-Software vorhanden sind, berücksichtigen dies bereits. Dennoch kann man in einem SAP-Einführungsprojekt nicht am „grünen Tisch“ entscheiden, wie die Benutzungsoberfläche aussehen und wie sich die Software verhalten soll. Denn die Anforderungen an die Software variieren – je nach Benutzer, Aufgabe und Umgebung – nicht nur zwischen verschiedenen Unternehmen, sondern bereits zwischen Abteilungen und Arbeitsplätzen ein und desselben Unternehmens. Was dem einen Benutzer hilft, kann den anderen behindern. Zum Beispiel benötigen Benutzer, die bestimmte SAP-Module selten verwenden, eine einfach zu erlernende und leicht zu erinnernde Software. Dagegen brauchen Benutzer, die häufige Eingaben machen, eine effiziente, leistungsstarke und flexible Software. Beides muss nicht dasselbe sein. Bei der hier beschriebenen Analyse des Nutzungskontextes kommt es darauf an zu ermitteln, wie die Benutzer ihre Arbeitsaufgaben bisher durchführten, um daraus abzuleiten, wie die SAP-Software sie dabei am besten unterstützen kann. Um es in Anlehnung an die Usability-Expertin Deborah Mayhew (1999) zu sagen, das Ziel ist es, bei der Gestaltung den optimalen Ausgleich zwischen folgenden Zielen zu finden:

135

6 Anforderungsanalyse •

die Möglichkeiten und Effizienz der Automatisierung zu nutzen;

•

Arbeitsprozesse so zu reorganisieren, dass sie die Geschäftsziele besser unterstützen;

•

den Aufwand für Umschulungen zu minimieren, indem die neue SAP-Software soweit wie möglich an das bestehende Aufgabenwissen der Benutzer anknüpft;

•

die Effektivität und Effizienz bei der Benutzung zu erhöhen, indem die Benutzereigenschaften, die Arbeitsaufgaben und die Software in ihrem Nutzungskontext in Einklang gebracht werden.

Häufig wird in SAP-Projekten nur das erste Ziel weitgehend und das zweite Ziel in Teilen verfolgt. Auch in diesem Baustein des Usability-Vorgehensmodells wird wieder konsequent von den Benutzern und ihren Arbeitsaufgaben ausgegangen. Folgende Fragen beispielsweise lassen sich schwer am „grünen Tisch“ beantworten: Wie unterschiedlich werden die Arbeitsaufgaben in großen und in kleinen Filialen bzw. im Innen- und im Außendienst erledigt? Welche Umgebungseinflüsse (Kundenverkehr, Lärm, Fluktuation) spielen eine Rolle? Welche informellen Informationen fließen zwischen Auftragseingang, Produktionsplanung und Produktion, die das formale Geschäftsprozessmodell nicht vorsieht? Welche konkreten Arbeitsschritte sind bei der Arbeit im Lager erforderlich? Um all dies herauszufinden, muss man Daten über die Benutzer und ihre tatsächliche Arbeit erheben. Im Folgenden sollen daher zwei Fragen beantwortet werden: •

Die Frage nach den Inhalten der Nutzungskontextanalyse: Welche Informationen braucht man, um ergonomische Anforderungen an die SAP-Software zu entdecken und ableiten zu können?

•

Die Frage nach den Methoden der Nutzungskontextanalyse: Wie erhebt man diese Daten?

Einige der in den nächsten Abschnitten besprochenen Inhalte lassen sich aus im jeweiligen Unternehmen vorliegenden Dokumentationen entnehmen sowie in den ASAP-Blueprint-Workshops erheben. Andere dagegen können nur mit eigenen Methoden der Nutzungskontextanalyse erhoben werden.

136

6.1 Nutzungskontextanalyse: Aufgaben, Benutzer, Technik

6.1.1

Inhalte der Nutzungskontextanalyse Ein ergonomisches System herzustellen heißt – gemäß dem in Kapitel 1 vorgestellten Dreieck der Software-Ergonomie –, die Passung zwischen Aufgaben, Benutzern und Technik (Hard- und Software) zu optimieren. Hierfür müssen Sie die Ecken des Dreiecks für Ihr Projekt erst einmal kennenlernen. Viele Daten werden dazu bereits bei der herkömmlichen Vorgehensweise z. B. in der ASAP-Phase „Business Blueprint“ berücksichtigt. Im Folgenden werden wir auflisten, welche Daten aus ergonomischer Sicht grundsätzlich wichtig sind. Welche Daten im spezifischen Einführungsfall von Belang sind, muss für das jeweilige Projekt entschieden werden. Verstehen Sie also diese Aufzählung als Checkliste für Aspekte, die in Ihrem SAP-Einführungsprojekt eine Rolle spielen könnten. Die folgenden Ausführungen beschäftigen sich demnach in drei Abschnitten mit Merkmalen der Arbeitsaufgaben, der Benutzer und der Technik. Merkmale der Arbeitsaufgaben Im Zentrum der Einführung von SAP-Software steht die Unterstützung der Geschäftsprozesse. Aus ergonomischer Sicht sind das die Arbeitsaufgaben der Benutzer. Um möglichst produktives Arbeiten zu ermöglichen, sollten Sie einige Fakten über die Arbeitsaufgaben der Benutzer kennen. Zur Auswahl der relevanten Aufgabenmerkmale gehen Sie am besten von den in der Phase „Projekteinstieg“ (vgl. Kapitel 5) vereinbarten Zielgruppen und Kernarbeitsaufgaben aus. Folgende Fragen zu den Arbeitsaufgaben sind aus ergonomischer Sicht zu stellen (s. für Erläuterungen Kasten 6.1): •

Welche Arbeitsschritte sind erforderlich, um die Aufgabe zu lösen?

•

Was ist das Ziel, was sind Auslöser, Eingangsinformationen und Ergebnis der Aufgabenbearbeitung?

•

Wie sind die durch SAP zu unterstützenden Arbeitsaufgaben in den allgemeinen Workflow eingebunden und welche Kommunikations- und Kooperationsbeziehungen gibt es zwischen einzelnen Benutzern sowie zwischen größeren Unternehmenseinheiten?

•

Wie häufig wird die Aufgabe durchgeführt?

•

Welche Bearbeitungsdauer hat ein Aufgabendurchlauf?

137

6 Anforderungsanalyse •

Wie wichtig sind die durch die SAP-Software abzubildenden Aufgaben für die Nutzer (Kernaufgaben vs. Zusatzaufgaben)?

•

Welche Anforderungen an die Qualität der Arbeitsergebnisse gelten (Genauigkeit vs. Geschwindigkeit der Aufgabenbearbeitung)?

•

Wie hoch ist die Flexibilität in der Wahl der Arbeitsschritte?

•

Wie häufig wird die Software benutzt werden?

•

Wie häufig finden Unterbrechungen der Aufgabenbearbeitung statt (z. B. durch Telefonanfragen, Anfragen durch Kollegen, Erledigung von Parallelaufgaben)?

•

Welche Behinderungen und Erschwernisse bestehen?

•

Welche Supportmöglichkeiten (Hotline, EDV-Abteilung, Handbücher, Key-User) sind verfügbar, und wie gut sind sie?

•

Wie hoch ist die ergonomische Qualität der Aufgabengestaltung und Aufgabenzuschnitte?

•

Wie hoch ist die Fluktuation am Arbeitsplatz, und wie lange bleiben die Beschäftigten in ihrer Position?

•

Welche Eigenschaften von Arbeitsort und Arbeitsumgebung müssen berücksichtigt werden?

Die Relevanz der einzelnen Kriterien (in der Liste kursiv gedruckt) für die spätere Ableitung von Anforderungen finden Sie im nachstehenden Kasten erläutert. Kasten 6.1: Merkmale der Arbeitsaufgaben und ihre Relevanz für die Ableitung von Anforderungen Arbeitsschritte Im Gegensatz zu festgelegten Soll-Arbeitsschritten z. B. in Arbeitsablaufbeschreibungen fragt die ergonomische Anforderungsanalyse danach, welche Arbeitsschritte tatsächlich und in welcher Reihenfolge durchgeführt werden. Die Kenntnis der bisherigen Arbeitsschritte ermöglicht es einzuschätzen, wie sehr sich die Arbeit durch die Einführung von SAP verändern wird. Dies wird wichtig im Baustein „Arbeitsprozess- und Dialoggestaltung“ (vgl. Kapitel 7), aber auch für das Organizational Change Management und Training. Die Kenntnis der bisherigen Arbeitsweise lässt nicht nur auf den Trainingsbedarf der Benutzer, sondern auch auf Rationalisierungspotenzial schließen, z. B. durch die Automatisierung von Arbeitsschritten. 138

6.1 Nutzungskontextanalyse: Aufgaben, Benutzer, Technik Ziel, Auslöser, Eingangsinformationen, Ergebnis Diese Daten werden benötigt, um herauszufinden, ob die SAPSoftware Ergebnisse in der geforderten Qualität und Quantität liefert, ob sie im Arbeitsablauf von tatsächlich vorhandenen Daten ausgeht etc. Der Abgleich von SAP-Software und Anforderungen der Arbeitsaufgabe wird im Baustein „Arbeitsprozessund Dialoggestaltung“ (vgl. Kapitel 7) durchgeführt. Workflow Die Erfassung des Workflow gibt Hinweise auf die nötigen Informationsflüsse und zeitlichen Abhängigkeiten bei der Arbeit. Der Workflow lässt erkennen, welche Stakeholder berücksichtigt werden müssen. So ist es z. B. wichtig, auf der Verdienstbescheinigung für Arbeiter (die ja keine unmittelbaren Benutzer des SAP-Personalwirtschaftsmoduls sind) die Aufschlüsselung der verschiedenen Prämienarten genau anzugeben. Die Analyse des tatsächlichen Workflows am Arbeitsplatz lässt viele anforderungsrelevante Merkmale erkennen, die in einer formalen Workflowbeschreibung nicht abgebildet werden. Dazu gehören eingespielte Kooperationsbeziehungen, informelle Informationskanäle, verdeckte Arbeitsteiligkeit oder ihr Gegenteil. Durch den Vergleich von aktuellem Workflow-Ist und zukünftigem Workflow-Soll lässt sich erkennen, welche Maßnahmen des Organizational Change Management getroffen werden müssen und wie hoch der Aufwand für fachliche Schulungen sein wird. Weiterhin liefern die Daten zum Workflow Hinweise für die Gestaltung von Aufgabenzuschnitten. Häufigkeit Je häufiger eine Aufgabe durchgeführt werden muss, desto höher werden die aus ihr entstehenden Anforderungen in der Regel priorisiert. Bearbeitungsdauer Die bisherige Bearbeitungsdauer wird häufig als Maßstab genommen, um konkrete Usability-Ziele festzulegen, an denen sich die SAP-Software messen lassen muss, z. B.: „Das Ausstellen einer Standard-Rechnung muss in weniger als zwei Minuten erledigt sein.“ Aufgabenwichtigkeit Die Aufgabenwichtigkeit hängt unmittelbar mit der Motivation zusammen, die Benutzer zur Benutzung der neuen SAP-Software mitbringen. So muss eine Software bei hoher Aufgaben139

6 Anforderungsanalyse wichtigkeit möglichst effizient zu benutzen sein, während bei niedriger Aufgabenwichtigkeit Merkmale wie Selbstbeschreibungsfähigkeit oder Erwartungskonformität im Vordergrund stehen. Anforderungen an die Qualität der Arbeitsergebnisse Kommt es auf eine hohe Qualität der Arbeitsergebnisse an, muss die SAP-Software z. B. Kontrollmöglichkeiten vorsehen. Soll eine Aufgabe dagegen vor allem schnell erledigt werden und ist bei ihr keine hohe Fehlerquote zu erwarten, können oftmals als überflüssig empfundene Kontrollschritte entfallen. Flexibilität Erfordert die Aufgabenbearbeitung eine sehr strukturierte Vorgehensweise, kann auch die SAP-Software sehr viel Struktur vorgeben, z. B. die Benutzer Schritt für Schritt zum Ziel leiten. Ist die Aufgabenbearbeitung dagegen sehr frei, muss auch die SAP-Software von Benutzern relativ flexibel gehandhabt werden können. Häufig werden mit SAP-Software sehr strukturierte Aufgaben durchgeführt, weil diese sich leichter automatisieren lassen. Flexibilität ist dagegen z. B. bei Abfragen im Modul BW (Business Warehouse) gefragt, bei dem Analysen von Unternehmensdaten aus verschiedenen Blickwinkeln und verschiedenen Aggregationsebenen (z. B. Abteilung, Bereich, Gesamtunternehmen) durchgeführt werden können. Nutzungshäufigkeit Benutzer, die einen Großteil ihrer Arbeitszeit mit der Software verbringen, sind eher bereit, sich in die Bedienung einzuarbeiten, als Gelegenheitsnutzer. Für erstere ist die einfache Erlernbarkeit der Software weniger wichtig als eine effiziente Benutzung. Wird die Software dagegen nur selten benutzt, muss sie leicht erlern- und erinnerbar sein. Die Benutzerführung zu vereinfachen ist hier wichtiger als eine möglichst effiziente Arbeitsweise zu ermöglichen. Unterbrechungen Wird eine Arbeit oft unterbrochen, ist es wichtig, dass der aktuelle Arbeitsstand erhalten bleibt, eingegebene Daten sichtbar bleiben und so viele Kontextinformationen auf dem Bildschirm vorhanden sind, dass Benutzer nach der Unterbrechung ihre Arbeit einfach und schnell fortsetzen können. Ebenso ratsam ist es, den Aufruf mehrerer Modi zuzulassen, so dass auch Zwischenaufgaben schnell mit der Software erledigt werden können. 140

6.1 Nutzungskontextanalyse: Aufgaben, Benutzer, Technik Behinderungen und Erschwernisse Behinderungen und Erschwernisse deuten auf eine ineffiziente Art der Arbeitserledigung hin, die es bei der Anpassung der SAP-Software zu berücksichtigen gilt. Von Behinderungen und Erschwernissen kann man z. B. immer dann sprechen, wenn Informationen fehlen, Drucker schwer zu erreichen sind, Geräte häufig defekt sind, Arbeitsmaterialien fehlen oder Arbeitsabläufe umständlich strukturiert sind. Wenn Informationen z. B. erst verspätet vorliegen, nützt es nichts, die Eingabe der Informationen in einer Maskenabfolge zwingend zu verlangen. Oft können durch die SAP-Software aber auch Behinderungen und Erschwernisse aus dem Weg geräumt werden, was die Motivation bei der Arbeit mit der Software erhöht. Da viele Behinderungen und Erschwernisse die Art der Arbeitsorganisation betreffen, gibt es hier viele Anknüpfungspunkte zum Organizational Change Management. Supportmöglichkeiten Ist ein Support (z. B. durch Handbuch oder Kollegen) nicht verfügbar, verbringen Benutzer entweder sehr viel Zeit damit, Probleme selbst zu beheben, oder die Datenqualität im System leidet. Die Frage nach der bisherigen Organisation und Nutzung des Supports bestimmt auch das Ausmaß an Hilfe und Lernförderlichkeit, die die SAP-Software bereitstellen muss, und sie lässt erkennen, wo der Support-Bedarf zukünftig besteht und wo es Stolperstellen und Erfolgsfaktoren gibt. Ergonomische Qualität von Aufgabengestaltung und Aufgabenzuschnitt Die Fragen zur ergonomischen Qualität der Aufgabengestaltung und der Aufgabenzuschnitte ergeben sich aus den Kriterien der DIN EN ISO 9241-2 (vgl. Kapitel 3): Wie stehen die Arbeitsaufgaben im Verhältnis zu den Erfahrungen und Fähigkeiten der Beschäftigten? Sind die Aufgaben vielseitig, ganzheitlich und mit viel Handlungsspielraum gestaltet? Gibt es Qualifizierungs- und Entwicklungsmöglichkeiten? Wie hoch ist ihre Komplexität, wie hoch die Konzentrationserfordernisse bei der Erledigung? Die Art der Aufgabengestaltung bildet den arbeitsorganisatorischen Kontext, in dem eine zukünftige SAPSoftware benutzt wird und der häufig durch die Einführung von SAP verändert wird. So ist darauf zu achten, dass die Einführung von SAP nicht zu monotonen, zerstückelten Aufgaben führt bzw. der Handlungsspielraum nicht eingeengt wird. Auch diese Themen werden in den Bausteinen „Arbeits141

6 Anforderungsanalyse prozess- und Dialoggestaltung“ sowie „Ergonomischer Rollenzuschnitt“ (vgl. Kapitel 7) wieder aufgegriffen. Fluktuation Eine sehr aufwändig zu erlernende SAP-Anwendung sollte nur bei Arbeitsplätzen mit niedrigen Fluktuationsraten eingesetzt werden. Die hohen Trainingskosten sind ökonomisch kaum vertretbar für Arbeitsplätze mit hoher Fluktuation (z. B. CallCenter). Bei Letzteren muss dann z. B. auf eine höhere Lernförderlichkeit der Software geachtet werden. Arbeitsort und Arbeitsumgebung Zu den Merkmalen des Arbeitsortes gehört, ob die Benutzer an einem festen Arbeitsplatz im Unternehmen, zu Hause (Telearbeiter), an wechselnden festen Arbeitsorten (Unternehmensberater) oder unterwegs am Laptop (Außendienstmitarbeiter) arbeiten. Auch ist zu prüfen, ob in der Arbeitsumgebung besondere Bedingungen wie Lärm oder wechselnde oder ungünstige Lichtverhältnisse herrschen. Außerdem sind Art und Form der unmittelbaren Arbeitsumgebung zu beachten (z. B. ob die Computer überhaupt verfügbar sind, wenn sie benötigt werden; ob beengte Platzverhältnisse herrschen; ob ein Computer von mehreren Personen benutzt wird). Aus Arbeitsort und -umgebung ergeben sich ggf. Anforderungen an Input/Output-Geräte (Sprachein- und Sprachausgabe, Touchscreen) oder Netzanbindung (bei Benutzern mit mobilen Geräten, etwa im Außendienst). Ganz allgemein bestimmt die Arbeitsumgebung, wie leicht Arbeiten zu erledigen sind und wie schnell Arbeitsergebnisse vorliegen: Sind lange Wege zurückzulegen (z. B. beim Ausdruck eines Formulars, wenn der Drucker am Ende eines Flures steht)? Sind bestimmte Vertraulichkeitsbedingungen einzuhalten (z. B. Bildschirmeinsicht von Besuchern)? Stehen bei Mehrpersonenbenutzung von Geräten diese auch ausreichend zur Verfügung? Merkmale der Benutzer Wenn von den Merkmalen der Benutzer die Rede ist, geht es um die Verteilung bestimmter Ausprägungen der Merkmale innerhalb der gesamten Benutzergruppe. So möchten Sie z. B. wissen, wie viele der Meister Computererfahrung besitzen. Die wichtigsten Benutzermerkmale stammen aus den Bereichen Wissen und Erfahrung, psychologische und körperliche Eigenschaften. Auswirkungen auf die Usability der SAP-Software hat z. B., wie hoch jeweils der Anteil von erfahrenen und unerfahrenen Benutzern 142

6.1 Nutzungskontextanalyse: Aufgaben, Benutzer, Technik ist. Auch können in einem spezifischen Einführungsprojekt einige Merkmale eine größere Rolle spielen als andere. Die folgende Liste von Fragen bemüht sich um möglichst große Vollständigkeit bei der Erfassung von Benutzermerkmalen und ist wiederum als Checkliste zu verstehen: •

Wie hoch ist die Computererfahrung der Benutzer (Anfänger oder Fortgeschrittene)?

•

Wie hoch ist die Anwendungserfahrung der Benutzer (z. B. Betriebssysteme, Softwareprogramme)?

•

Wie hoch ist die fachliche Erfahrung der Benutzer?

•

Welche psychologischen Eigenschaften der Benutzer (z. B. Einstellung zu Computerarbeit, Ängste) gilt es zu berücksichtigen?

•

Wie ist die Verteilung von Fehlsichtigkeit und Farbenblindheit in der Benutzergruppe?

•

Welche Behinderungen von Benutzern sind zu berücksichtigen?

Die Relevanz der einzelnen Kriterien (in der Aufzählung kursiv gedruckt) für die spätere Ableitung von Anforderungen finden Sie im nachstehenden Kasten erläutert. Kasten 6.2: Benutzermerkmale und ihre Relevanz für die Ableitung von Anforderungen Computererfahrung Der Grad der bereits vorhandenen Computererfahrung bestimmt den Trainingsaufwand und lässt Akzeptanzprobleme vorhersagen. Allgemein gilt: Für Benutzer mit wenig Erfahrung sind Selbstbeschreibungsfähigkeit und Lernförderlichkeit der Software wichtig, für erfahrene Benutzer eine effektive und effiziente Benutzung. Anwendungserfahrung Außer der Frage, mit welchen Betriebssystemen und Softwareprogrammen sich die Benutzer auskennen, interessiert hier, inwiefern sie Standard-Office-Anwendungen benutzen und ob sie die Arbeitsaufgaben, die zukünftig mit SAP-Software erledigt werden, vorher mit einem ähnlichen System bearbeitet haben. Die Anwendungserfahrung weist darauf hin, wie weit sich die bisherige von der einzuführenden (SAP-)Software unterscheidet. Ist der Unterschied in Benutzungsweise, Terminologie, Bearbeitungsablauf etc. sehr groß, führt das zu 143

6 Anforderungsanalyse geringerer Akzeptanz der SAP-Software, verursacht höheren Trainings- und Supportaufwand, verlängert die Einarbeitungszeiten und sorgt zumindest am Anfang für höhere Fehlerraten. In diesem Falle sollte darüber nachgedacht werden, die SAPSoftware der bisherigen Anwendungserfahrung anzupassen. Dabei sind nicht immer gleich Modifikationen nötig, unter Umständen genügen hier bereits einfachere Anpassungen. Wenn die Benutzer z. B. viel Erfahrung mit MS Excel haben, kann die SAP-Software die Auswertung von Daten in Tabellen über eine Schnittstelle frühzeitig an MS Excel übergeben, so dass die Benutzer auf ihre vorhandenen Fähigkeiten aufbauen können. Möglicherweise wurde für bestimmte Aufgaben bereits SAPSoftware eingesetzt (z. B. für den Einkauf von Büromaterial) – in diesem Fall ist das grundsätzliche Aussehen und Verhalten der Software schon bekannt. Auch hier gilt wieder: Für Benutzer mit wenig Erfahrung sind die Selbstbeschreibungsfähigkeit und die Lernförderlichkeit der Software wichtig, für erfahrene Benutzer eine effektive und effiziente Benutzung. Fachliche Erfahrung Je nach dem Ausmaß der fachlichen Erfahrung der Benutzergruppe muss die Software ihnen auch mehr oder weniger Fachwissen zur Verfügung stellen können. Besitzen die Benutzer viel System- und wenig Fachwissen (z. B. Datentypisten), sollte die Software ihnen viel Hilfe im fachlichen Bereich anbieten. Verhält es sich umgekehrt, sollten Benutzer fokussiert Hilfe zur eigentlichen Softwarebenutzung bekommen. Psychologische Eigenschaften Einstellung und Motivation der zukünftigen Benutzer sind wichtige Aspekte für die spätere Akzeptanz und Nutzung einer SAP-Software. Die Einführung kann aus unterschiedlichsten Gründen Ängste auslösen: So glauben Benutzer vielleicht, sie verstünden nicht genug von Computern und könnten „etwas kaputt machen.“ Oder die SAP-Software könnte die Arbeit grundlegend verändern, der sie dann vielleicht nicht mehr gewachsen sind. Oder sie könnten ihren Arbeitsplatz verlieren, der durch die neue Software möglicherweise überflüssig wird. Wenn Benutzer mit zu starken Ängsten an die SAP-Software herantreten, werden sie diese schlechter erlernen, weniger gut damit arbeiten und mehr Fehler bei der Benutzung machen. Die Gestaltung der SAP-Software sollte darauf Rücksicht nehmen. Bei hoher Benutzungsangst sollte der Schwerpunkt auf 144

6.1 Nutzungskontextanalyse: Aufgaben, Benutzer, Technik leichter Erlernbarkeit, Fehlertoleranz und Steuerbarkeit der SAP-Software liegen. Nur wenn die Software diese Eigenschaften besitzt, können anfängliche Ängste leicht überwunden werden, da die Benutzer dann schnell merken, dass „man nichts wirklich kaputt machen kann“ (Fehlertoleranz), „das man das System unter Kontrolle hat“ (Steuerbarkeit) und „schnell Lernfortschritte macht“ (Lernförderlichkeit). Ist die Motivation der Benutzer hoch und sind sie sehr interessiert daran, eine neue Software zu erhalten, spielen viel eher Funktionsvielfalt sowie Effizienz und Einfachheit der Benutzung eine Rolle. Hoch motivierte Benutzer nehmen es eher in Kauf, Zeit mit dem Erlernen der Software verbringen zu müssen. Niedrig motivierte Benutzer müssen hingegen durch eine leichte Erlernbarkeit und hohe Einfachheit der Benutzung erst an die Software herangeführt werden. Fehlsichtigkeit und Farbenblindheit Bei der Gestaltung der SAP-Oberfläche ist zu berücksichtigen, ob Benutzer von Fehlsichtigkeit oder Farbenblindheit betroffen sind (dies ist insbesondere bei älteren Belegschaften häufiger der Fall). Zu achten ist beispielsweise auf benutzungsfreundliche Schrift- und Symbolgrößen. Für von Farbenblindheit Betroffene können Probleme entstehen, wenn relevante Informationen zur Aufgabenbearbeitung in SAP farbkodiert sind (z. B. Verwendung von Ampelfarben für bestimmte Bearbeitungszustände). Behinderungen Behinderungen wie z. B. Blindheit, Schwerhörig-/Gehörlosigkeit oder motorische Behinderungen können die Performanz von Benutzern stark beeinträchtigen, wenn ihre Belange (z. B. hinsichtlich geeigneter Ein- und Ausgabegeräte) bei der Einführung von SAP-Software nicht berücksichtigt wurden. Merkmale der Technik Die Erhebung von Technikmerkmalen ist wichtig, um technische Grenzen für den Einsatz der SAP-Software kennen zu lernen und entsprechende Anforderungen daraus ableiten zu können. Wichtige Fragen zur technischen Leistungsfähigkeit sind: •

Welche Bildschirmgrößen und -auflösungen sind verfügbar?

•

Welche Eingabegeräte sollen berücksichtigt werden?

•

Welche weiteren technischen Daten sind wichtig?

145

6 Anforderungsanalyse Die Relevanz der einzelnen Kriterien (in der Aufzählung kursiv gedruckt) für die spätere Ableitung von Anforderungen finden Sie im nachstehenden Kasten erläutert. Kasten 6.3: Merkmale der Technik und ihre Relevanz für die Ableitung von Anforderungen Bildschirmgröße und -auflösung Von diesen Merkmalen hängt z. B. ab, wie groß Masken und Tabellen sowie Schrift dargestellt werden können. Eingabegeräte Zu den häufig verwendeten Eingabegeräten gehören u. a. Tastatur, Maus, Joystick, Touchscreen, Stift (Stylus), Spracheingabegerät, Strichcode-Scanner. Eingabegeräte müssen unter den gegebenen Arbeitsbedingungen tatsächlich einsetzbar sein. So ist eine Tastatur oder Optik-Maus in einer stark schmutzenden Umgebung fehl am Platze. Vorhandene Eingabegeräte müssen von den Benutzern bedienbar sein. So wird eine Spracheingabe bei einer Belegschaft von Nicht-Muttersprachlern nicht sehr effizient sein. Weitere technische Daten Zu den weiteren technischen Leistungsdaten der vorhandenen Hardware gehören z. B. die Systemgeschwindigkeit, die Arbeits- und Festplattenspeicherkapazität, die Netzwerkgeschwindigkeit. Die Art der benutzten Hardware (Desktop, Laptop, PDA oder Handy) lässt Rückschlüsse auf Bildschirmgröße, Leistungsfähigkeit, Netzwerkanschluss etc. zu. Eine nicht an die Benutzer oder die Arbeitsaufgaben angepasste Hardware kann die Effektivität, Effizienz und Zufriedenheit der Benutzung beeinträchtigen. Diese Liste erhebt keinen Anspruch auf Vollständigkeit, soll aber an dieser Stelle einen Überblick über die wichtigsten Charakteristika geben. Obwohl die Hardware-Umgebung bereits im herkömmlichen SAP-Einführungsprozess berücksichtigt wird, geht es hier um die spezielle Sichtweise für die Ergonomie und die Benutzungsfreundlichkeit der SAP-Software. Nachdem diese umfangreiche Sammlung von relevanten Merkmalen für die Nutzungskontextanalyse gezeigt hat, was aus ergonomischer Perspektive zur Ableitung von Anforderungen wichtig ist, wird der nächste Abschnitt sich mit Methoden befassen, also damit, wie Sie die Ausprägung dieser Merkmale erheben können.

146

6.1 Nutzungskontextanalyse: Aufgaben, Benutzer, Technik

6.1.2

Methoden der Nutzungskontextanalyse Im ersten Schritt sollten Sie festlegen, welche der im letzten Abschnitt aufgelisteten Merkmale für das aktuelle SAP-Einführungsprojekt relevant sind und welche Daten daher erhoben werden sollen. Im zweiten Schritt werden die benötigten Daten zu den Aufgaben-, Benutzer- und Technikmerkmalen erhoben. Mehrere Methoden bieten sich an: •

Nutzung schriftlicher Dokumentation;

•

Befragung von Benutzern;

•

Befragung von Schlüsselpersonen;

•

Aufgabenanalysen vor Ort.

Diese Methoden werden in den folgenden Abschnitten erläutert. Nutzung schriftlicher Dokumentation Der erste Schritt bei der Erhebung der Aufgaben-, Benutzer- und Technikmerkmale besteht darin, vorhandenes schriftliches Material zu sichten. In den Business-Blueprint-Workshops sind bereits einige dieser Merkmale erhoben worden. Andere Daten finden sich in betrieblichen Dokumenten wie Stellenbeschreibungen, Geschäftsprozessablaufplänen, Qualifizierungsunterlagen u. v. m. Gewiss ist es von Vorteil, das SAP-Vorgängersystem, so vorhanden, kennen zu lernen. Möglicherweise gibt es dazu auch ein Handbuch und /oder Schulungsunterlagen, durch die Sie sich einen Eindruck von diesem System verschaffen können. Einschränkungen Bei der Nutzung vorhandener Dokumentationen zur Beschreibung von Aufgaben ist Vorsicht geboten, denn oftmals werden Arbeitsaufgaben in der Praxis ganz anders bearbeitet, als es (möglicherweise vor längerer Zeit) einmal dokumentiert wurde. Auch Aufgabenzuschnitte einzelner Stelleninhaber werden oft anders dargestellt, als sie in Wirklichkeit sind. Wollen Sie etwas über die tatsächlichen Arbeitsabläufe und Aufgaben wissen, müssen Sie den Benutzern vor Ort „über die Schulter schauen“ (s. u., Aufgabenanalysen vor Ort). Die Analyse schriftlicher Dokumentation kann Ihnen dennoch als eine gute Grundlage dienen, die jedoch durch weitere Methoden ergänzt werden muss. Befragung von Benutzern Diese Methode bietet sich an, wenn im Vorfeld sehr wenig über die zukünftigen Benutzer der SAP-Lösung bekannt ist. Durch die direkte Befragung der Betroffenen bekommen Sie die besten und 147

6 Anforderungsanalyse zuverlässigsten Ergebnisse. Besonders geeignet sind Benutzerbefragungen zur Erfassung von Benutzer- und Technikmerkmalen. Auch einige grundlegende Aufgabenmerkmale (wie z. B. Teilaufgaben, Aufgabenwichtigkeit, Aufgabenhäufigkeit) können bei einer Benutzerbefragung bereits erfasst werden. Für konkrete Arbeitsabläufe sowie Kommunikations- und Kooperationserfordernisse haben sich Aufgabenanalysen vor Ort besser bewährt als reine Befragungen. Schriftliche Befragung

Befragungen können mündlich oder schriftlich erfolgen. Da eine SAP-Einführung in der Regel sehr viele Benutzer betrifft, die nicht alle mündlich durch ein persönliches oder telefonisches Interview befragt werden können, bietet sich meist eine schriftliche Befragung mittels Papier- oder Online-Fragebogen an. Entwerfen Sie dazu einen Fragebogen, der die für das Projekt wichtigen und von Ihnen ausgewählten Aufgaben-, Benutzer- und Technikmerkmale erfragt. Beispielhafte Ausschnitte aus einem derartigen Fragebogen sehen Sie in Kasten 6.4. Testen Sie den Fragebogen vorher mit zwei bis fünf Benutzern, und achten Sie darauf, dass die Fragen verständlich, vollständig und angemessen sind. Legen Sie im Vorfeld auch fest, wie viele Benutzer insgesamt befragt werden sollen. Meistens reicht es, statt alle Benutzer eine kleine Auswahl stichprobenartig zu befragen. Bedenken sollten Sie allerdings, dass der Rücklauf bei den meisten schriftlichen Befragungen nur zwischen 30 und 40 % liegt und der Fragebogen an entsprechend mehr Benutzer verteilt werden muss. Sie erhalten höhere Rücklaufquoten, wenn die Benutzer vor der Befragung durch eine E-Mail, die Mitarbeiterzeitung oder Aushänge informiert werden.

Auswertung

Je nachdem, ob Sie die Befragung per Papier- oder Online-Fragebogen durchführen, wird unterschiedlicher Auswertungsaufwand auf Sie zukommen. Online-Fragebögen erfordern zwar in der Vorbereitung bei der Programmierung und Einrichtung etwas mehr Aufwand, bei der Beantwortung können die Daten jedoch gleich in eine elektronische Datenbank übertragen werden. Die Antworten in Papierfragebögen müssen erst manuell oder halbautomatisch kodiert werden. Die Auswertung muss keine komplizierte Statistik sein – in den meisten Fällen reichen Häufigkeitswerte für die einzelnen Antwortkategorien aus (s. Kasten 6.4), um daraus erste strategische Anforderungen abzuleiten (vgl. Abschnitt 6.2). Vergessen Sie nicht, die Ergebnisse in einer kurzen Zusammenfassung an die Benutzer zurückzumelden. Damit schaffen Sie die besten Voraussetzungen für eine zukünftige gute Zusammenarbeit!

148

6.1 Nutzungskontextanalyse: Aufgaben, Benutzer, Technik Kasten 6.4: Befragung von Benutzern (Beispiel) Benutzermerkmale in einem gemeinnützigen Verband Um einen Überblick über die Eigenschaften einer Benutzergruppe von etwa 2.000 Mitarbeitern zu erlangen, wurde in einem gemeinnützigen Verband eine Befragung der Benutzer durchgeführt. Es wurde anhand des Mitarbeiterverzeichnisses eine zufällige Stichprobe von 500 Benutzern verschiedener Regionen und Tätigkeiten gezogen und angeschrieben. Abbildung 6.1 zeigt einen Ausschnitt aus dem Fragebogen, der im Projektteam entworfen und mit der Steuerungsgruppe abgestimmt wurde.

Abbildung 6.1: Ausschnitt aus einem Benutzerfragebogen – Fragen zur Computererfahrung und zur Einstellung gegenüber der Arbeit mit Computern Die Rücklaufquote betrug 38 % (191 Benutzer). Zur Auswertung wurden für die offenen Fragen Kategorien gebildet. Es ergaben sich folgende Ergebnisse für die hier interessierenden Benutzergruppen der Sachbearbeiter und Führungskräfte (Tabelle 6.2).

149

6 Anforderungsanalyse Frage

Abstufung

Sachbearbeiter (92 %)

Führungskräfte (8 %)

Seit wie vielen Jahren führen Sie diese Tätigkeit aus?

< 1 Jahr 1 bis 3 Jahre > 3 Jahre

15 % 34 % 51 %

0% 0% 100 %

Seit wie vielen Jahren arbeiten Sie schon mit Computern?

< 1 Jahr 1 bis 3 Jahre > 3 Jahre

11 % 20 % 69 %

71 % 20 % 9%

Wie viele Stunden arbeiten Sie pro Woche durchschnittlich mit Computern?

Mittelwert (0 … Max)

28 Std. 20 Min.

4 Std. 54 Min.

Wie gut beherrschen Sie den Umgang mit Computern?

Mittelwert (-3 … +3)

1,2

0,1

Wie ist Ihre generelle Einstellung gegenüber der Arbeit mit Computern?

positiv neutral negativ anderes

33 % 40 % 27 % 0%

20 % 17 % 63 % 0%

Tabelle 6.2:

Antworten auf ausgewählte Fragen zu Benutzereigenschaften in einem gemeinnützigen Verband

Die Ergebnisse der Benutzerbefragung flossen in die Ableitung der strategischen Anforderungen ein (s. dazu Kasten 6.8). Befragung von Schlüsselpersonen Eine Alternative zur Befragung von großen Benutzerstichproben ist die Befragung von Benutzervertretern. Benutzervertreter sind repräsentative einzelne Benutzer oder Vorgesetzte, die auf einer breiten Basis Benutzer aus der interessierenden Benutzergruppe kennen (z. B. Gruppenleiter, Abteilungsleiter). Diese Benutzervertreter werden gebeten, die ihnen bekannte Benutzergruppe hinsichtlich der für das Projekt relevanten Aufgaben-, Technikund Benutzermerkmale zu beschreiben. Das Ziel ist es, ein Ergebnis wie im Beispiel im Kasten 6.4 (Tabelle 6.2) zu bekommen. Man beginnt also mit dem Auswertungsblatt und lässt die ausgewählten Interviewpartner schätzen, wie die Benutzer über die verschiedenen Ausprägungen eines Merkmals verteilt sind. Zum Beispiel: Wie hoch ist der jeweilige prozentuale Anteil an sehr guten, guten, mittelguten und schlechten Maschineschreibern. 150

6.1 Nutzungskontextanalyse: Aufgaben, Benutzer, Technik Obwohl diese Methode schneller und möglicherweise kostengünstiger zu Ergebnissen führt als eine Benutzerbefragung, hängt ihr Erfolg sehr davon ab, wie gut die Gesprächspartner die jeweiligen Arbeitsplätze und Benutzer kennen. Haben Sie mit diesen Methoden relevante Merkmalsverteilungen ermittelt, müssen diese interpretiert und dabei in konkrete Anforderungen umgewandelt werden. Wie dies geschieht, wird weiter unten in Abschnitt 6.2 erläutert. Aufgabenanalyse vor Ort Den Königsweg zur Analyse des Nutzungskontextes ist die Aufgabenanalyse vor Ort. Mit der Analyse von vorhandenen Dokumenten oder einer Befragung von Benutzern bzw. Schlüsselpersonen erhalten Sie bereits nützliche Informationen, die eine Gewichtung der Usability-Ziele im Projekt erlauben und übergreifende strategische Usability-Anforderungen erkennen lassen. Konkrete ergonomische Anforderungen erkennt man jedoch nur direkt vor Ort an den Arbeitsplätzen bei der Beobachtung der realen Arbeit der Benutzer. Deswegen werden bei der Aufgabenanalyse so genannte Beobachtungsinterviews an den Arbeitsplätzen der Benutzer durchgeführt. Gründe für Aufgabenanalysen vor Ort

Nun können Sie sich fragen, warum man an die Arbeitsplätze der Benutzer gehen sollte, um den bisherigen Prozess zu analysieren, wenn sich die Prozesse doch durch SAP sowieso ändern werden? Die Antwort auf diese Frage hat mehrere Facetten: •

Um den Übergang von der bisherigen Vorgehensweise zu SAP möglichst einfach machen zu können, müssen Sie wissen, wie die Arbeit momentan ausgeführt wird. Nur so können Sie die Arbeit mit der SAP-Software entsprechend darauf einrichten. Durch die Anpassung der SAP-Software an den gegenwärtigen Nutzungskontext kann das Erlernen der SAPSoftware stark vereinfacht werden.

•

Auch wenn sehr große Änderungen in der Arbeit durch Einführung der neuen SAP-Software zu erwarten sind, ist es von Vorteil, die Benutzer und ihre bisherige Arbeit kennen zu lernen. So können frühzeitig Akzeptanzprobleme oder Probleme des Übergangs erkannt und durch Organisationsentwicklungsmaßnahmen (Organizational Change Management) aktiv angegangen werden. Auch eine Planung von Trainingsmaßnahmen ist besser möglich.

151

6 Anforderungsanalyse •

Durch eine Nutzungskontextanalyse können Sie sehen, wie die Geschäftsprozesse laufen, an welchen Stellen Redundanzen entstehen und wo Prozesse optimiert werden können.

•

Prozesse haben viele Verzweigungen und Abhängigkeiten, so dass von Veränderungen auch andere Personen als die direkten Benutzer von SAP betroffen sind, z. B. Kunden, Lieferanten oder Mitarbeiter anderer Abteilungen. Eine Nutzungskontextanalyse deckt diese oft informellen Abhängigkeiten auf und berücksichtigt sie in den Anforderungen.

Im Folgenden erfahren Sie, wie man eine Aufgabenanalyse plant, durchführt und auswertet. Anschließend beschreiben wir Alternativen, die Sie nutzen können, wenn die Durchführung einer Analyse am Arbeitsplatz aus bestimmten Gründen nicht möglich ist. Ein Beispiel für die Durchführung einer Aufgabenanalyse vor Ort finden Sie in Kasten 6.7. Planung und Durchführung Planung

Zur Vorbereitung und Planung der Beobachtungsinterviews vor Ort sollten Sie sich zunächst fragen, welche Benutzer(-gruppen) interviewt werden sollen. Um zeit- und ressourcensparend vorzugehen, konzentrieren Sie sich auf die größten bzw. strategisch relevantesten Benutzergruppen. Legen Sie auch die zu analysierenden Geschäftsprozesse fest. Konzentrieren Sie sich zunächst auf die zu unterstützenden Kerngeschäftsprozesse. Abhängig von den Geschäftsprozessen, auf die Sie sich konzentrieren wollen, müssen Sie auch den Zeitpunkt für die Analysen planen. So ist die Gelegenheit, eine Personalabrechnung zu analysieren, meist nur einmal im Monat gegeben.

Durchführung

In der Regel werden Sie drei bis fünf Benutzer je Benutzergruppe interviewen müssen, um sicher sein zu können, dass die Daten nicht nur die ganz spezifische Sichtweise eines einzelnen Benutzers widerspiegeln. Der Besuch bei den Benutzern dauert in der Regel zwischen zwei und vier Stunden. Nachdem Sie sich vorgestellt und den Zweck Ihres Besuches erläutert haben, stellen Sie dem Benutzer zunächst allgemeine Fragen. Diese dienen z. B. dazu, das Benutzer- oder Aufgabenprofil aus der schriftlichen Benutzerbefragung zu vervollständigen, und geben Ihnen erste Anhaltspunkte für weitere Fragen zum Nutzungskontext. Fragen, die am Anfang gestellt werden, sind: „Seit wann arbeiten Sie schon in dieser Tätigkeit? Worin bestehen Ihre Arbeitsaufgaben? Mit wem kommunizieren und interagieren Sie? Mit wem tauschen Sie Informationen aus? Gibt es regelmäßige Treffen?

152

6.1 Nutzungskontextanalyse: Aufgaben, Benutzer, Technik Wie oft? Wer ist einbezogen? Welche Informationen, welche Werkzeuge finden Sie unabdingbar für Ihre Arbeit?“ etc. Im Hauptteil der Aufgabenanalyse beobachten Sie die vorher mit dem Benutzer abgestimmten Kerntätigkeiten. Seien Sie neugierig und lassen Sie sich alles erklären, was der Benutzer tut. Stellen Sie dabei offene Fragen und drängen Sie den Benutzer nicht in eine bestimmte Richtung. Behalten Sie aber immer den Fokus des Interviews im Auge, den Sie bei der Planung festgelegt haben! Fragenbeispiele sind: „Können Sie mir zeigen, wie Sie das tun? Wer oder was löste diese Aktivität aus? Woher bekamen Sie diese Informationen? Was ist der nächste Schritt? Woran erkennen Sie, dass Sie die Aufgabe erfolgreich abgeschlossen haben? Was tun Sie gerade? Was taten Sie vorher?“ etc. Beherzigen Sie dabei eine Grundhaltung: Der Benutzer ist der Experte, Sie sein Lehrling (s. Kasten 6.5). Am Ende fassen Sie in wenigen Sätzen zusammen, was Sie für die Hauptergebnisse des Interviews halten, und lassen sich diese von dem Benutzer bestätigen. Klären Sie alle Fragen, die noch offen sind. Dazu gehören der weitere Verlauf des Projektes und die Verwendung der erhobenen Daten. Kasten 6.5: Leitprinzipien für die Aufgabenanalyse vor Ort Der Benutzer ist Meister, Sie sind Lehrling Welche Grundhaltung es einzunehmen gilt, um eine Aufgabenanalyse vor Ort erfolgreich durchzuführen, vermittelt anschaulich das Modell vom Meister und seinem Lehrling. Das bedeutet, der Interviewer verhält sich wie ein Auszubildender. Er lernt dadurch, dass er den Meister beobachtet und ihn ggf. durch Fragen unterbricht. Durch diesen Ansatz werden Struktur und Details der Arbeit sichtbar, die später durch SAP-Software unterstützt werden sollen. Versuchen Sie also nicht, der Experte zu sein, der vorschreibt, wie man die Arbeit am besten macht. Bei der Durchführung des Interviews sollte man sich von den vier Prinzipien Kontext, Partnerschaft, Interpretation und Fokus leiten lassen (vgl. dazu auch das Buch von Beyer & Holtzblatt, 1998). Das Prinzip Kontext besagt, dass man den Benutzer möglichst konkret bei seiner Arbeit halten soll. Wenn Sie also merken, dass die Aussagen Ihres Gesprächspartners zu allgemein werden, sollten Sie ihn dazu bringen, sich auf konkrete Details

153

6 Anforderungsanalyse seiner Arbeit zu konzentrieren. Versuchen Sie, mit dem Benutzer die einzelnen Arbeitsaufgaben Schritt für Schritt durchzugehen, und zwar anhand von konkreten Beispielen, die vor kurzem so bearbeitet werden mussten. Vermeiden Sie, über hypothetische Fälle zu spekulieren. Das Prinzip Partnerschaft dient dazu, eine angenehme Atmosphäre zu schaffen, in der der Benutzer das Gefühl hat, ernst genommen zu werden, so dass er sein Wissen als Experte in seiner Arbeit auch gern weitergibt. Sagen Sie, was Sie an der Arbeit interessiert. Seien Sie neugierig. Denken Sie an das Meister-Lehrling-Prinzip und lassen Sie sich ausbilden. Das Prinzip Interpretation besagt, dass eine Beobachtung allein noch keinen Sinn macht. Man muss daraus Hypothesen formulieren und diese mit dem Benutzer diskutieren, um die Korrektheit zu überprüfen. Versuchen Sie schon bei der Beobachtung wiederkehrende Muster zu finden, Arbeitsziele und -strategien zu erkennen und die Rolle des Benutzers zu erfassen, die er innerhalb der Arbeit spielt. Diskutieren Sie Ihre Hypothesen mit dem Benutzer. Das Prinzip Fokus definiert, wie Sie auf die Arbeit schauen. Im Gegensatz zu dem gewählten Modell, in dem der Meister bestimmt, was der Auszubildende zu lernen hat, hat der Interviewer nur die Aspekte der Arbeit im Blick, die mit der SAP- Software unterstützt werden sollen. Zu Beginn der Interviewserie wird ein solcher Fokus festgelegt. Der Fokus sollte auf der Arbeit liegen, nicht auf der Gestaltung von Soft- oder Hardware. Fragen Sie nach, wenn Sie etwas nicht verstanden haben, aber auch gerade dann, wenn Sie glauben, schon alles zu verstehen. Dokumentation und Auswertung Dokumentation

154

Wahrscheinlich haben Sie sich während des Besuchs bei den Benutzern diverse Notizen zur Person, zu den Arbeitsaufgaben, zur jetzigen technischen Unterstützung, zur Arbeitsumgebung etc. gemacht. Diese gilt es in eine geeignete Form zu bringen. Hilfreich sind dabei folgende Dokumentationsmethoden: •

Workflow: Stellen Sie den Informations- und Datenfluss zwischen dem Benutzer und anderen Mitarbeitern oder Abteilungen grafisch dar (s. Abbildung 6.2 in Kasten 6.6).

•

Aufgabenhierarchie: Bilden Sie die Beziehungen zwischen verschiedenen Aufgaben des Benutzers ab und gliedern Sie Haupt- und Teilaufgaben (s. Abbildung 6.4).

6.1 Nutzungskontextanalyse: Aufgaben, Benutzer, Technik •

Arbeitsschritte: Schreiben Sie die Abfolge einzelner Arbeitsschritte, mit ihren jeweiligen Zielen, Auslösern und Ergebnissen, mit Zeitdauern sowie Unterbrechungen und Hindernissen auf.

•

Artefakte: Kopieren Sie wichtige Unterlagen und Formulare, Notizen und Aufzeichnungen, die bei der Bearbeitung der Arbeitsaufgabe verwendet werden (s. Abbildung 6.3 in Kasten 6.6).

•

Umgebungsmodell: Fertigen Sie eine Skizze oder ein Foto vom Arbeitsplatz des Benutzers an und versehen Sie es mit Anmerkungen (s. Abbildung 6.5 im Kasten 6.7).

Kasten 6.6: Dokumentation einer Aufgabenanalyse (Beispiel) Aufgabenanalysen in einem Stahlwerk

Abbildung 6.2: Workflow-Modell für die Arbeitsaufgabe „Zeitabrechnung bei Arbeitern in einem Stahlwerk“ (Beispiel) Im Rahmen der Einführung des Moduls HR (Personalwirtschaft) in einem Stahlwerk wurden Aufgabenanalysen vor Ort durchgeführt. Dazu wurde nicht nur die Arbeit der Personalsachbearbeiter, sondern auch die der Meister berücksichtigt, da Meister in Zukunft das HR-Modul für die Zeitabrechnung der Arbeiter benutzen sollen. Den beobachteten Workflow zeigt Abbildung 6.2. Bisher wurden vom Meister Tageszettel ausgefüllt, die dann an die Personalsachbearbeiter zur Abrechnung übermittelt wurden. Über die erfolgte Abrechnung der Überstunden sowie evtl. Zulagen und Prämien erhielten die Arbeiter einen von der Software erstellten Entgeltnachweis. Interessant ist hier die in der Regel nur indirekte Kommunika155

6 Anforderungsanalyse tion der Personalsachbearbeiter mit den Mitarbeitern über die Entgeltnachweise. Direkte Kommunikation wird spätestens dann notwendig, wenn die Arbeiter Fragen zur Zusammensetzung ihrer Zulagen auf dem Entgeltnachweis haben und diese mit den Personalsachbearbeitern telefonisch zu klären versuchen.

Abbildung 6.3: Artefakt (Beispiel): Tageszettel, der bei der Aufgabe „Zeitabrechnung in einem Stahlwerk“ verwendet wird Abbildung 6.3 zeigt ein Artefakt, den Tageszettel, den der Meister ausfüllt. Für die Auswertung ist interessant, welche Informationen erhoben werden (Datum, Personalnr., Name, Planschichtabweichungen, Überstundenzeiten, Pausenzeiten, Abwesenheitszeiten und -arten, Zulagen u. a.), welche Informationen das Formular zur Verfügung stellt (dreistellige Codes der Abwesenheitsarten), welche Informationen nicht zur Verfügung stehen (z. B. Codes für die Art der Zulagen) und welche Vorgänge direkt mit dem Artefakt verbunden sind (Abzeichnung von Mitarbeiter und Meister). Ausgefüllte Formulare würden zeigen, welche der Felder tatsächlich ausgefüllt werden, wie vollständig die weitergegebenen Informationen sind, ob zusätzliche Vermerke gemacht werden, für die keine Felder vorgesehen sind etc.

156

6.1 Nutzungskontextanalyse: Aufgaben, Benutzer, Technik

Abbildung 6.4: Zusammenfassung der Interviews

Aufgabenhierarchie bei einem Kundenbetreuer einer Versicherung (Beispiel)

Die vorgestellten Dokumentationsmethoden können Sie einzeln für jedes Interview anwenden. Sie müssen dann für mehrere Benutzer zusammengeführt werden, um ein möglichst vollständiges Bild des Nutzungskontextes zu erhalten. Zur späteren Ableitung von Anforderungen ist es auch wichtig zu sehen, wie Nutzungskontexte variieren. Für eine ausführlichere Beschreibung dieser und anderer Methoden vgl. Beyer & Holtzblatt (1998), Hackos & Redish (1998), Mayhew (1999) und Holtzblatt, Wendell & Wood (2005). Günstig ist es, wenn Sie weitere Personen aus dem Projektteam, die nicht bei den Aufgabenanalysen vor Ort dabei waren, mit in die Auswertung einbeziehen, so dass möglichst alle einen Einblick in die Bedingungen des Nutzungskontextes erhalten. Der folgende Kasten enthält ein Praxisbeispiel für eine Aufgabenanalyse vor Ort. Kasten 6.7: Aufgabenanalyse vor Ort (Beispiel) Lokaltermin in einem Dienstleistungsunternehmen Im Rahmen einer Anforderungsanalyse bei einem Dienstleistungsunternehmen mit mehreren Standorten wurde entschieden, Aufgabenanalysen vor Ort durchzuführen. Drei regionale Standorte wurden aufgrund ihrer Heterogenität der Mitarbeiterzahl (5, 12 und 24 Mitarbeiter) ausgewählt. Zwei Mitglieder des Projektteams besuchten an je einem Tag die beiden kleinen Standorte und an zwei aufeinander folgenden Tagen den großen Standort, um die Arbeit und den Nutzungskontext der 157

6 Anforderungsanalyse Benutzer kennen zu lernen. Insgesamt wurden in dieser Zeit 17 (5 + 5 + 7) Benutzer befragt und bei der Arbeit nach dem Meister-Lehrlingsmodell beobachtet. Zwei Benutzergruppen konnten identifiziert werden: Sachverständige und Assistenzfachkräfte. Der Analysefokus wurde auf die Assistenzfachkräfte gelegt, da diese am meisten von der SAP-Einführung betroffen sein würden. Die Aufgaben dieser Assistenzkräfte bestanden darin, Kunden zu empfangen, vorbereitende Tätigkeiten für ein Sachverständigengutachten durchzuführen und diese mit einer Software (dem Vorgänger der SAP- Software) abzurechnen, so dass Kunden die Ergebnisse gleich auf einer Bescheinigung mitnehmen konnten und die Abrechnung der Leistung erfolgen konnte. Zusätzlich mussten Verwaltungstätigkeiten wie Terminkoordination, Datenpflege, Schriftverkehr durchgeführt werden sowie Materialien und Geräte beschafft und kontrolliert werden. Inhaltlicher und zeitlicher Schwerpunkt der Tätigkeit war eindeutig die Vorbereitung von Gutachten, nicht die Verwaltungstätigkeit. Die allgemeinen Computerkenntnisse der Beschäftigten waren gering ausgeprägt, das Interesse für die Arbeit mit dem Computer nicht sehr hoch. Dennoch hatten sich in allen drei Standorten hocheffiziente Arbeitsweisen entwickelt, bei denen mit dem Altsystem innerhalb einer Minute Bescheinigungen ausgestellt und Rechnungen vorbereitet werden konnten. Dies war u. a. auch deshalb möglich, weil das Altsystem (im Rahmen der damaligen Möglichkeiten) sehr gut auf die Anforderungen der Arbeitsaufgaben angepasst war. Zur Arbeitsteilung ist zu sagen, dass jeder Mitarbeiter beides, vorbereitende Tätigkeiten und Abrechnungstätigkeiten am Computer, durchführte. Gerade für die kleineren Standorte war dies von Vorteil, da so jeder Mitarbeiter für jede Aufgabe herangezogen werden konnte. Die Abrechnung der Leistungen wurde unmittelbar nach Leistungserbringung durchgeführt. Im Prinzip gab es zwei Arten der Abrechnung: Einzelleistungen und Sammelleistungen. Diese waren zwar inhaltlich unterschiedlich, vom Ablauf her aber ähnlich. Obwohl die Leistungsarten standardmäßig vorgegeben waren, gab es in etwa 15 % der Fälle Ausnahmen zu beachten, bei denen Standardleistungen kundenindividuell angepasst werden mussten. Der Ort, an denen die Computer standen, war in den meisten Fällen der Raum, in dem auch der gesamte Kundenverkehr stattfand. Nur an dem großen Standort gab es weitere Räume, die zur Arbeit am Computer genutzt werden konnten. 158

6.1 Nutzungskontextanalyse: Aufgaben, Benutzer, Technik

Abbildung 6.5: Umgebungsmodell – Arbeitssituation im Empfangsbereich (Beispiel; rechts ein Mitglied des Projektteams bei der Aufgabenanalyse) In Abbildung 6.5 ist ein Beispiel von der Arbeitsumgebung in einem Empfangsbereich dargestellt. Aufgrund der Lage im Empfangsbereich der Geschäftsstellen war die Arbeitsatmosphäre von diversen Unterbrechungen und Störungen geprägt. Eine Stichprobenaufnahme von jeweils einer Stunde zeigte, dass im Schnitt alle 2½ Minuten Unterbrechungen und Störungen der eigentlichen Arbeit vorlagen (s. Tabelle 6.3). Die hier dargestellten Ergebnisse bilden nur einen Ausschnitt aus den reichhaltigen Daten, die aus der Aufgabenanalyse vor Ort entsprangen. So gab es noch wichtige Hinweise zum Arbeitsablauf, zur Arbeitsteilung zwischen Assistenzkräften und Unterbrechungen und Störungen Türklingel

Tag 1, 10:35 bis 11:35 6

Tag 2, 8:10 bis 9:10 8

Kunden

9

9

Telefon

10

6

Vorgesetzte Gesamt

Tabelle 6.3:

3

4

28 Störungen/ Stunde

27 Störungen/ Stunde

Anzahl und Art der Unterbrechungen der Arbeitstätigkeit im Empfangsbereich einer Geschäftsstelle eines Dienstleistungsunternehmens

159

6 Anforderungsanalyse Sachverständigen sowie zu der bei der Arbeit verwendeten Terminologie, die später für die Bewertung der SAP-Software in der Phase „Sollkonzeption“ (vgl. Kapitel 7) herangezogen wurden. Die Ergebnisse wurden im Projektteam diskutiert und der Steuerungsgruppe berichtet und flossen in die Ableitung ergonomischer Anforderungen (s. nächstes Unterkapitel, Kasten 6.9) ein. Alternativen: Wenn Vor-Ort-Analysen zu aufwändig sind Beobachtungsinterview als Königsweg

Grundsätzlich ist das Beobachtungsinterview als Königsweg zu empfehlen. Nur hier sehen Sie, wie die reale Arbeit durchgeführt wird, und Sie können auch diejenigen Tätigkeiten beobachten, die bei Benutzern aus Gewohnheit hochautomatisch ablaufen. Können Sie aus Aufwandsgründen nicht mehrere Benutzer am Arbeitsplatz besuchen, gehen Sie nur zu einem. Hier gilt das Motto: Einer ist besser als gar keiner.

Gruppeninterviews

Ist es aber aus zeitlichen oder anderen Gründen gar nicht möglich, Nutzungskontextanalysen direkt am Arbeitsplatz vorzunehmen, sollten Sie andere Methoden verwenden, um die ergonomischen Anforderungen aus dem realen Nutzungskontext so gut wie möglich zu erfassen. Hierbei bieten sich Gruppeninterviews mit möglichst vielen Benutzern an. Als Interviewleitfaden können Sie die Fragen nehmen, die in den vorhergehenden Abschnitten als Leitfragen formuliert wurden. Versuchen Sie das Gespräch darauf zu lenken, welche Lösungen im Arbeitsalltag heute bereits gut sind und welche Probleme die heutige Vorgehensweise bei der Bearbeitung der Arbeitsaufgaben mit sich bringt. Darin sind häufig Anforderungen verborgen, die die Arbeit mit der SAP-Software erleichtern können und deshalb mit in die Analyse aufgenommen werden sollten.

6.2

Anforderungen Das Ziel dieses Bausteins ist es, die Ergebnisse der Nutzungskontextanalyse hinsichtlich Aufgaben-, Benutzer- und Technikmerkmalen in Anforderungen umzusetzen. Im Folgenden gehen wir davon aus, dass technische Anforderungen sowie Anforderungen an Datenstrukturen und -abhängigkeiten sowie organisationale/ gesetzliche Anforderungen bereits im SAP-Business-Blueprint erhoben wurden.

160

6.2 Anforderungen Strategische und spezifische Anforderungen

Wichtig bei der Ableitung von Anforderungen ist, zwischen strategischen und spezifischen Anforderungen zu trennen. Bei ersteren legen Sie die generelle Richtung der Gestaltung der SAP-Software fest, also auf welche der vereinbarten Usability-Ziele – z. B. auf leichte Erlernbarkeit und Wiedererlernbarkeit oder auf schnelle und effiziente Benutzung – der Schwerpunkt gelegt wird. Diese strategischen Anforderungen werden eher aus den allgemein erhobenen Daten von z. B. Benutzerbefragungen abgeleitet. Die spezifischen Anforderungen hingegen resultieren aus konkreten Vorgaben aus der Arbeitsaufgabe, z. B. dass ein bestimmter Geschäftsprozess in zwei Minuten erledigt werden muss oder dass eine Sortierung von Adressen nach Postleitzahl erforderlich ist. Spezifische Anforderungen lassen sich vor allem aus der Beobachtung des Nutzungskontextes ableiten. Die folgenden zwei Abschnitte zeigen Ihnen, wie es geht.

6.2.1

Ableitung strategischer Anforderungen aus Befragungen Die Ergebnisse der Befragungen beschreiben die verschiedenen Benutzergruppen hinsichtlich ihrer Aufgaben, ihrer Eigenschaften und ihrer technischen Ausstattung auf allgemeinem Niveau. So können Sie z. B. herausgefunden haben, dass die zukünftigen Benutzer die Software sehr häufig nutzen werden, wenig Erfahrung mit der Software haben und 50 % von ihnen im Außendienst auf dem Laptop arbeiten. Aus diesen Beschreibungen müssen Sie nun die richtigen Schlüsse für die ergonomische Gestaltung ziehen.

Vorgehen

Wie gehen Sie dabei vor? Die Ergebnisse der Befragungen werden in einem Anforderungsworkshop mit dem Projektteam und Vertretern der Benutzer besprochen. Hierbei steht die Verteilung von Merkmalen der Aufgaben, der Benutzer und der Arbeitsaufgaben im Vordergrund. Ist die Mehrheit der Benutzer vertraut mit der Arbeit am Computer, oder gibt es eine Untergruppe (z. B. Meister), für die Computerarbeit etwas Neues ist? Was bedeutet dies für die Einführung von SAP-Software für diese Gruppe? Lassen sich daraus Anforderungen an die SAP-Software, an die Gestaltung von Trainingsmaßnahmen oder an Maßnahmen des Organizational Change Management ableiten? Wenn ja, welche sind dies? Das Ableiten von strategischen Anforderungen wird dabei immer von den spezifischen Gegebenheiten des Unternehmens abhängen. Obwohl Verallgemeinerungen schwierig sind, gibt Abschnitt 6.1.1 (Inhalte der Nutzungskontextanalyse) bereits Hinweise, wie 161

6 Anforderungsanalyse einzelne Anforderungen dabei mit einzelnen Merkmalskategorien der Benutzer, ihren Aufgaben und der Technik zusammenhängen. Der folgende Kasten zeigt ein Beispiel aus der Praxis. Kasten 6.8: Ableitung von Anforderungen aus einer Benutzerbefragung (Beispiel) Anforderungen für Sachbearbeiter und Führungskräfte Einige ausgewählte Ergebnisse einer Befragung von Sachbearbeitern und Führungskräften in einem gemeinnützigen Verband zeigte Kasten 6.4. Analyseergebnis Sachbearbeiter: Über die Hälfte der Sachbearbeiter übt die jetzige Tätigkeit schon mehr als drei Jahre aus, und immerhin ein Drittel arbeitet zwischen ein und drei Jahren im derzeitigen Job. Auch die Computererfahrung ist recht hoch. Die Mehrheit arbeitet länger als drei Jahre mit dem Computer, die wöchentliche Nutzungszeit liegt bei knapp drei Vierteln einer Vollzeitstelle. Die Beherrschung von Computern wurde im Mittel als gut eingestuft. Die Mehrheit der Benutzer ist Computern gegenüber neutral eingestellt, ein Drittel arbeitet sogar gern mit ihnen. Analyseergebnis Führungskräfte: Die Führungskräfte dagegen sind zwar lange im Unternehmen und haben eine hohe fachliche Erfahrung, die Computererfahrung und Computernutzung ist bisher aber ausgesprochen gering. Die Mehrheit benutzt Computer seit weniger als einem Jahr und auch ziemlich selten. Ebenso ist auch die Motivation für Computerarbeit nicht besonders hoch ausgeprägt: Über die Hälfte von ihnen arbeitet nicht gern am Computer. Welche strategischen, allgemeinen Anforderungen wurden nun aus den Befragungsergebnissen der Sachbearbeiter und Führungskräfte abgeleitet? Anforderungen der Sachbearbeiter: Die hohe fachliche Qualifikation und lange Verweildauer im Unternehmen, die Geübtheit im Umgang mit Computern sowie das mittlere Interesse der Sachbearbeiter setzen den Schwerpunkt der Benutzung auf eine leichte Bedienbarkeit. Die Benutzer sind Experten auf ihrem Gebiet und können bisherige Computererfahrungen nutzen, so dass sie eine neue Software relativ leicht erlernen werden. Wichtig bei der voraussichtlich intensiven Benutzung der SAP-Software ist, dass die Aufgaben damit möglichst einfach abgewickelt werden können und mächtige Funktionalitäten vorhanden sind (z. B. Möglichkeiten für Masseneingaben, 162

6.2 Anforderungen Flexibilität in der Handhabung einzelner Masken, Tastatursteuerung des Bedienablaufs). Die geringe Fluktuation lässt vermuten, dass eine komplexere Software auch mit höherem Trainingsaufwand eingeführt werden kann, da sich die Investition in ein Training durch die lange Bleibedauer gut bezahlt macht. Anforderungen der Führungskräfte: Die eher geringe Erfahrung mit Computern und die eher negative Einstellung deuten darauf hin, dass der Fokus bei den Führungskräften auf möglichst einfache Erlernbarkeit gelegt werden muss. Die geringe Nutzungshäufigkeit fordert ein leichtes Wieder-Erlernen-Können der Bedienung, so dass auch Benutzungsabläufe, die länger nicht durchgeführt wurden, schnell wieder zur Verfügung stehen. Ebenso ist es wichtig, auf eine ausreichende Fehlertoleranz der Software zu achten, so dass Benutzerfehler leicht abgefangen werden können sowie die Nutzungsmotivation nicht durch umständliche Fehlerbehebungsroutinen zerstört wird. Diese aus den Befragungen resultierenden Anforderungen wurden bei der Konkretisierung der Usability-Ziele als Schwerpunkte für die jeweilige Benutzergruppe gesetzt. Widersprüchliche Anforderungen

Die Ableitung von strategischen Anforderungen aus den Ergebnissen einer Benutzerbefragung ist oft nicht so einfach, wie es scheinen mag. Bereits die Ergebnisse innerhalb einer Benutzergruppe können zu widersprüchlichen Anforderungen führen, die mit den Benutzern ausgehandelt werden müssen. Ebenso können verschiedene Benutzergruppen inkompatible Anforderungen haben. Zum Beispiel sind die Führungskräfte aus dem Beispiel im Kasten 6.8 durch geringe Computererfahrung, geringe Nutzungshäufigkeit und hohe fachliche Erfahrung charakterisiert. Daraus ergibt sich die Anforderung, eine möglichst einfach zu erlernende und ebenso leicht wiederzuerlernende SAP-Software zu gestalten. Demgegenüber stehen jedoch die Sachbearbeiter mit hoher Nutzungshäufigkeit und hoher Computererfahrung, die eine sehr effizient und einfach zu benutzende Software benötigen. Wie ist dies zu vereinbaren? Sind für die beiden Benutzergruppen unterschiedliche Lösungen möglich (z. B. Portallösung und „klassische“ SAP-Benutzungsoberfläche)? Können die Benutzergruppen auf ihre Belange angepasste Benutzungsoberflächen bekommen, z. B. über die Anpassung von SAP-Rollen? Oder muss eine gemeinsame Lösung für beide Gruppen gefunden werden? Wenn ja, welche Anforderungen erhalten dann Priorität? Solche 163

6 Anforderungsanalyse widersprüchlichen Anforderungskonstellationen müssen dokumentiert werden und gemeinsam mit den Benutzern im Workshop besprochen und priorisiert werden.

6.2.2

Ableitung spezifischer Anforderungen aus dem Nutzungskontext Aufgrund der Vielfalt der beobachteten Aufgaben und Tätigkeiten bei einer Aufgabenanalyse vor Ort ist es kaum möglich, einfache WENN-DANN-Regeln (WENN ich X beobachtet habe, DANN resultiert daraus Anforderung Y) für die Ableitung von Anforderungen abzustellen. Da es hier um sehr konkrete Anforderungen geht, ist das Verfahren etwas offener.

Workshops mit Benutzern

Anforderungen aus den Aufgabenanalysen vor Ort werden am besten in Workshops mit Benutzern entwickelt. Ein solcher Workshop kann gleichzeitig mit der Rückmeldung und der Evaluation der Ergebnisse aus den Beobachtungsinterviews verknüpft werden. Zur Vorbereitung des Workshops sollten die erhobenen Daten aufbereitet und noch einmal gesichtet werden. Eventuell ist es sinnvoll, bereits im Vorfeld offensichtlich erscheinende Anforderungen abzuleiten, so dass die Diskussion im Workshop fokussierter erfolgen kann. Laden Sie die Benutzer ein, bei denen Sie am Arbeitsplatz waren; so können Sie ihre Ergebnisse noch einmal überprüfen. Achten Sie aber auch darauf, Benutzer einzuladen, an deren Arbeitsplätze Sie bisher noch nicht waren, um evtl. andere Sichtweisen mit einbinden zu können.

Ablauf

Den Einstieg in den Workshop bildet ein Review der gesammelten Ergebnisse, zusammen mit ggf. bereits im Vorfeld abgeleiteten Anforderungen. Wichtig dabei ist, sich nicht von bloßen Wünschen und Meinungen leiten zu lassen, sondern Anforderungen aus tatsächlich beobachteten Daten abzuleiten. Wie kann das aussehen? Ziel der Ableitung ergonomischer Anforderungen wird immer sein, Anforderungen zu stellen, die Effektivität, Effizienz und Zufriedenheit der Benutzer erhöhen (nach DIN EN ISO 9241-11, vgl. Kapitel 3). Gesucht werden muss also gezielt nach Merkmalen des Nutzungskontextes, die diese Ziele beeinflussen können. Drei Beispiele sollen dies veranschaulichen: •

164

Bei einer Aufgabenanalyse vor Ort ließ sich feststellen, dass Instandhalter in der Produktion oft unter Lärmbedingungen arbeiten, so dass akustische Rückmeldungen der Software oftmals „im Lärm untergingen“ und zusätzlich eine visuelle Rückmeldung für erfolgte Eingaben (z. B. das Scannen eines Strichcodes an einer Maschine) erfolgen musste.

6.2 Anforderungen •

Bei der Aufgabenanalyse vor Ort fiel auf, dass im Rahmen der Kundenbetreuung Kundenstammdaten (z. B. die Adresse) an verschiedenen Stellen neu in vorhandene Softwarepakete eingegeben wurden (im Call-Center, in der Reparaturabteilung, zur Rechnungsstellung, für den Versand). Daraus leitete sich die Anforderung ab, Eingaben der Kundendaten möglichst nur an einer Stelle erfolgen zu lassen und diese dann den anderen Beteiligten einfach zur Verfügung zu stellen.

•

Bei einer Aufgabenanalyse in der Fahrzeugindustrie wurde der Nutzungskontext bei Kommissionierern im Lager durch eine Aufgabenanalyse vor Ort analysiert. Ein Ergebnis war, dass die einzusammelnden Teile je Auftrag häufig gleichartig waren und in gleicher Menge benötigt wurden, manchmal jedoch Ausnahmen vorkamen. Vor der Einführung der SAPSoftware wurden die Vorgaben auf ausgedruckten Listen gemacht. Da die Kommissionierer, während sie im Lager unterwegs waren und Teile einsammelten, keine Hand frei hatten, wurden die Listen oft nicht Zeile für Zeile abgearbeitet, sondern mehrere Zeilen am Stück. Mit diesem Verfahren konnten sich Fehler einschleichen, gerade wenn an einer Stelle andere Teile benötigt wurden, die vom üblichen Auftrag abwichen. Da diese Fehler häufig vorkamen, kennzeichnete der Meister schon bei der Auftragsvergabe Ausnahmen per Hand auf der Liste. Durch die Einführung von SAP-Software sollten die Papier-Listen durch elektronische Listen auf mobilen Geräten ersetzt werden. Eine Anforderung an die Software war es also, Abweichungen vom Standard elektronisch markieren zu können (entweder automatisch durch die Software oder per Hand), um teure Kommissionierungsfehler zu vermeiden.

Ein weiteres Beispiel, wie aus Ergebnissen der Aufgabenanalyse Anforderungen werden, ist in Kasten 6.9 dargestellt. Kasten 6.9: Ableitung von spezifischen Anforderungen aus dem Nutzungskontext vor Ort (Beispiel) Von der Beobachtung zu den Anforderungen Im Kasten 6.7 haben wir ein Beispiel für Arbeitsanalysen vor Ort bei einem Dienstleistungsunternehmen gezeigt. Als wichtige Ergebnisse erhielten wir auf Benutzerseite geringe Computererfahrung, auf Aufgabenseite hohe Störungs- und Unterbrechungsraten bei der Arbeit am Computer. Inhaltlich war es 165

6 Anforderungsanalyse wichtig, zwischen Einzel- und Sammel-Leistungen zu unterscheiden, Ausnahmen von Standardleistungen definieren zu können und Leistungen zeitnah abzurechnen, so dass Kunden gleich mit einer Bescheinigung die Geschäftsstelle verlassen konnten. In einem Workshop mit fünf Benutzern, zwei Mitgliedern des Projektteams und einem Usability-Berater wurden die Ergebnisse noch einmal vorgestellt und die wichtigsten Anforderungen für diese Abrechnungstätigkeit zusammengestellt (Ausschnitt s. Abbildung 6.6). Gewissermaßen als Überschrift fungierte dabei die Anforderung „Unterbrechungsresistenz“, die die Arbeit der Benutzer im Empfangsbereich am besten charakterisierte. Wird die Arbeit häufig unterbrochen, müssen bereits eingegebene Daten sichtbar bleiben, so dass die Benutzer nach der Unterbrechung sich schnell wieder in die Aufgabe einfinden können. Damit zusammen hängt die Forderung nach möglichst wenigen Masken – im Idealfall einer einzigen –, in die alle Eingaben gemacht werden können. Ein übersichtliches und klares Layout war ein weiteres Kriterium, das der Unterbrechungsresistenz diente. Da die Kunden direkt nach Leistungserbringung „abgefertigt“ werden sollten, war es wichtig, wie bisher eine maximale Bearbeitungsdauer pro Fall von einer Minute zu haben. Damit zusammen hängen die Forderung nach einer einfachen Suche nach Standardleistungen und die möglichst einfache individuelle Anpassung von in der Software hinterlegten Standardleistungen. Da die Arbeit mit der Software nur einen kleinen Teil der gesamten Arbeit ausmachte, war also einfache Bedienbarkeit und auch Konsistenz (Übereinstimmung) in den Bedienabläufen, etwa zwischen der Abrechnung von Einzel- und Sammelleistungen, wichtig. Um die Wichtigkeit der einzelnen Anforderungen aus Benutzersicht einschätzen zu können, wurde eine Priorisierung der Anforderungen durchgeführt. Höchste Priorität erhielt die Anforderung, Leistungen individuell anpassen zu können, hohe Priorität erhielten die Anforderungen „wenige Masken“ und „Durchführungszeit unter einer Minute“ (vgl. Abbildung 6.6). Die Anforderungen wurden präzisiert, also eindeutig, testbar und verfolgbar ausformuliert, schriftlich dokumentiert und gemäß ihrer Priorisierung in der Phase „Sollkonzeption“ mit der SAP-Software abgeglichen (s. Kasten 7.2 in Kapitel 7). 166

6.2 Anforderungen

Abbildung 6.6: Flipchartausschnitt mit den im Workshop abgeleiteten und mit Punkten priorisierten Anforderungen Nutzungskontext im Vordergrund

Wichtig ist, darauf zu achten, welche Anforderungen der Nutzungskontext stellt – nicht, ob und wie sie mit der SAP-Software umgesetzt werden können! Der Abgleich mit der SAP-Software erfolgt erst in der nächsten Phase des Vorgehensmodells (Sollkonzeption, vgl. Kapitel 7). Dies ist auch ein entscheidender Unterschied zum herkömmlichen Vorgehen bei der Einführung von SAP-Software: der Nutzungskontext und seine Anforderungen werden hier nicht durch die „SAP-Brille“ gesehen, sondern so, wie sie tatsächlich sind. Die SAP-Software wird nicht als unveränderlich gegeben betrachtet, sondern als Werkzeug zur Unterstützung von Arbeitsaufgaben. Sie muss sich der Konfrontation mit den Anforderungen aus dem Nutzungskontext stellen. Aufgrund der Flexibilität der SAP-Software ist es möglich, darauf im Einführungsprojekt reagieren zu können. Daher ist es wichtig, Anforderungen aus dem Nutzungskontext möglichst frühzeitig zu erheben. Schließlich müssen die Anforderungen aus dem Nutzungskontext priorisiert und dokumentiert werden (vgl. Abschnitt 6.2.4 und 6.2.5).

6.2.3

Anforderungen aus anderen Quellen In diesem Abschnitt sollen weitere Anforderungen besprochen werden, die nicht aus den Datenquellen des Usability Management, also aus der unmittelbaren Analyse des Nutzungskontextes, stammen. Insbesondere geht es um Anforderungen aus der

167

6 Anforderungsanalyse Organisation sowie um Anforderungen aus ergonomischen Guidelines und Normen. Anforderungen aus der Organisation Viele Anforderungen kommen aus der Organisation, also dem Unternehmen, das SAP-Software einführt, selbst. Dazu gehören die Art der Strukturierung von Daten, die Unternehmensstruktur, die Umsetzung von Regeln und internen Vorschriften (z. B. Buchhaltungs- und Stornovorschriften, Qualitätssicherungs- und Datenschutzregeln) sowie gesetzliche Regelungen (z. B. Steuergesetze, Dokumentationsvorschriften) etc. Diese sind unbedingt bei der Analyse der Anforderungen zu berücksichtigen, da sie mitunter im Widerspruch zu den Anforderungen stehen, die sich aus der Analyse des Nutzungskontextes ergeben. Da diese Anforderungen jedoch bereits standardmäßig bei einer SAP-Einführung erhoben werden sollten (z. B. ASAP-Phase „Business Blueprint“), sei hier lediglich darauf verwiesen, ohne noch einmal näher darauf einzugehen. Anforderungen aus ergonomischen Guidelines und Normen Normen

Zusätzlich zu den betriebsspezifisch erhobenen Anforderungen aus dem Nutzungskontext gibt es übergreifende ergonomische Anforderungen, die bereits in verschiedenen Quellen niedergelegt sind. Dazu gehören die DIN EN ISO 9241-2 mit den Kriterien Benutzerorientierung, Vielseitigkeit, Ganzheitlichkeit, Bedeutsamkeit, Handlungsspielraum, Rückmeldung, Entwicklungsmöglichkeiten, sowie die in diesem Buch schon häufig zitierte DIN EN ISO 9241-110 (vgl. v.a. Kapitel 3).

Styleguides

Weiterhin gelten bei der Erweiterung und Anpassung von SAPSoftware die Styleguides von SAP (zu finden u. a. auf www.sapdesignguild.org), wie z. B.

168

•

SAP R/3 Style Guide;

•

SAP R/3 Icon Style Guide;

•

Accessibility Guidelines for ABAP Dynpro;

•

SAP iView Guidelines;

•

SAP HTMLB Guidelines;

•

Internet Application Components;

•

SAP Interaction Design Guide for WAP Applications;

•

SAP Style Guide for PDA Applications;

•

SAP Style Guide for Blue-Collar Worker PDAs;

6.2 Anforderungen und weitere Styleguides für Entwickler, die zum Teil auch unternehmensspezifisch sein können. Allgemeine Usability-Regeln

Außerdem anzuwenden sind gängige Regeln für die ergonomische Gestaltung von Software, wie z. B. die zehn Heuristiken von Nielsen (1994), die Regeln von Shneiderman (1998) oder Mayhew (1992). Hierzu zählen z. B. die Forderungen nach konsistenter Gestaltung von Masken, Symbolen, Benennungen sowie Art und Formen der Rückmeldung an die Benutzer (z. B. durch geeignet gestaltete Fehlermeldungen). Zur Anwendung von ergonomischen Regeln und Styleguides und zur Klärung spezifischer ergonomischer Fragen ist es empfehlenswert, einen Usability-Experten im Projektteam zu haben bzw. diesen als externen Berater heranzuziehen.

6.2.4

Formulierung von Anforderungen Wie Anforderungen formuliert werden sollen, kann u. a. im IEEE Standard 1233 (1998) nachgelesen werden. Insgesamt sind vier Eigenschaften von Anforderungen relevant: •

Anforderungen sollen abstrakt formuliert sein: Anforderungen sollen unabhängig von ihrer technischen Umsetzung formuliert werden, also nicht: „Diese vier Alternativen werden durch Radiobuttons ausgewählt“, sondern: „Diese vier Alternativen schließen einander aus. Nur jeweils eine Alternative kann gewählt werden“

•

Anforderungen sollen eindeutig formuliert sein: Jede Anforderung sollte nur auf eine Weise interpretierbar sein. Negativ-Beispiel: „Die Bearbeitung von Formularen soll zufriedenstellend durchgeführt werden können.“ Was heißt in diesem Falle zufriedenstellend? Für den Benutzer kann das heißen: „Mit möglichst wenig Aufwand“, für den Techniker: „Alle Mussfelder sind gefüllt“, für den Vorgesetzten: „Fehlerfrei.“

•

Anforderungen sollen verfolgbar sein: Jede Anforderung sollte auf ihren Ursprung hin verfolgt werden können. Zum Beispiel kann bei den Anforderungen vermerkt werden, ob sie aus einer Befragung oder einer Aufgabenanalyse vor Ort stammen bzw. in welchem Workshop sie abgeleitet wurden.

•

Anforderungen sollen testbar sein: Jede Anforderung sollte so formuliert sein, dass ihre Erfüllung auch überprüfbar ist. Gerade diese Eigenschaft von Anforderungen ist besonders wichtig, denn nur wenn Anforderungen überprüfbar sind, 169

6 Anforderungsanalyse dienen sie als Zielformulierung für das Projekt. Eine Anforderung, die heißt: „Suchen und Drucken soll schnell gehen“, ist kaum testbar, da nicht klar ist, was gegen welches Kriterium getestet werden soll. Dagegen ist die Anforderung: „Das Suchen und Drucken der Arbeitsbescheinigung dauert max. zwei Minuten“, sehr gut testbar, z. B. in der Phase „Realisierung“ des Vorgehensmodells zum Usability Management. Usability-Ziele aus Aus den gesammelten Anforderungen ergibt sich die Festschreibung weiterer Usability-Ziele, wie z. B. „80 % der Führungskräfte lernen Anforderungen die Bedienung der Systemoberfläche in fünf Minuten“, wenn bekannt ist, dass Führungskräfte Computer im Allgemeinen wenig nutzen und wahrscheinlich auch keine Schulungen besuchen werden. Im Gegensatz zu solchen konkret festgeschriebenen quantitativen Zielen kann es auch richtungweisende qualitative Ziele geben wie: „Die SAP-Software muss Benutzer unterstützen, die sie selten benutzen. Für die Abwicklung komplexer Aufgaben muss sie selbsterklärend, leicht zu erlernen und wieder zu erinnern sein, möglichst viele fachliche Informationen zur Verfügung stellen und Benutzer Schritt für Schritt durch die Aufgabe führen, so dass sie die Details der Bearbeitung zwischen einzelnen Benutzungsepisoden nicht im Gedächtnis speichern müssen.“ Wichtig bei solchen Zielen – wie auch bei den Anforderungen im Allgemeinen – ist es, dass sie mit den Benutzern abgestimmt und priorisiert worden sind.

6.2.5

Priorisieren von Anforderungen Das Priorisieren von Anforderungen ist sehr wichtig, weil sonst bei knappen Zeit- und Budgetplänen nicht klar ist, welche Anforderungen unbedingt bearbeitet werden müssen und welche weniger dringlich sind. Die abgeleiteten Anforderungen werden am besten mit den Benutzern zusammen in einem Workshop priorisiert. Eine einfache Methode ist es, Prioritäten nach dem bekannten ABC-Schema zu vergeben. Hier bedeuten im Einzelnen: •

A: höchste Priorität, unbedingt notwendig;

•

B: mittlere Priorität, notwendig;

•

C: geringe Priorität, „nice-to-have“.

Wenn Sie diese Methode wählen, ist es wichtig, darauf zu achten, dass nicht jede Anforderung die Priorität A erhält. Im Allgemeinen ist dies jedoch kein Problem, da Benutzer sehr gut zwischen wichtigen und weniger wichtigen Anforderungen unterscheiden können. 170

6.4 Zusammenfassung und Ausblick Auch die Priorisierung der Anforderungen muss dokumentiert werden, denn sie entscheidet über die Wichtigkeit der Umsetzung bei der nächsten Phase (der Sollkonzeption; vgl. Kapitel 7).

6.3

Ergonomischer Meilenstein 2 Das Ziel des Ergonomischen Meilensteins 2 ist es, die Qualitätssicherung der Phase „Anforderungsanalyse“ zu betreiben und die Phase abzunehmen. Die Ergebnisse der Nutzungskontextanalyse und die daraus abgeleiteten und priorisierten Anforderungen liegen vor. Bei diesem Meilenstein findet in der Steuerungsgruppe ein Review der Projektaktivitäten und Ergebnisse statt. Das Ergebnis ist der Abschluss der Phase, ggf. mit Auflagen (z. B. fehlende Anforderungen für eine spezielle Benutzergruppe zu ergänzen), und die Freigabe für die nächste Phase, die Sollkonzeption. Dabei ist dieser Meilenstein im Vergleich zum vorhergehenden Ergonomischen Meilenstein 1 (Projekteinstieg) und dem nachfolgenden Meilenstein 3 (Sollkonzeption) mit weniger Aufwand verbunden und dient vor allem der Kontrolle und Qualitätssicherung der Arbeit des Projektteams.

6.4

Zusammenfassung und Ausblick In diesem Kapitel haben wir dargestellt, wie im Usability Management-Vorgehensmodell ergonomische Anforderungen erhoben werden. Die frühzeitige Erhebung der Anforderungen beugt teuren Nachbesserungen in späteren Phasen des SAP-Einführungsprojektes vor. In diesem Kapitel haben Sie die Inhalte einer aufgaben- und benutzerzentrierten Nutzungskontextanalyse kennengelernt. Dabei ist es wichtig, Aufgaben- Benutzer- und Technikmerkmale zu berücksichtigen, die für die Ableitung von Anforderungen relevant sind. Von den Methoden der ergonomischen Anforderungsanalyse wurden die Befragung von Benutzern bzw. Schlüsselpersonen zur Ableitung strategischer Anforderungen und die Aufgabenanalyse vor Ort zur Ableitung spezifischer Anforderungen vertiefend dargestellt. Schließlich haben wir anhand von Praxisbeispielen gezeigt, wie Sie aus Analyseergebnissen Anforderungen ableiten können und wie Sie Anforderungen formulieren und priorisieren können. Im nächsten Kapitel erfahren Sie, wie die ergonomischen Anforderungen in das Sollkonzept für die Gestaltung der künftigen Arbeit mit der SAP-Software einfließen und welche weiteren ergonomischen Aktivitäten in der Phase „Sollkonzeption“ anstehen. Jörn Hurtienne und Petra Abele 171

7

Sollkonzeption Im vorigen Kapitel haben Sie die Bedeutung und den Verlauf der Anforderungsanalyse im Rahmen des Usability Management kennengelernt. In diesem Kapitel stellen wir Ihnen die darauf folgende Phase „Sollkonzeption“ vor, in der festgelegt wird, wie die zuvor dokumentierten ergonomischen Anforderungen umgesetzt werden sollen. Ziel der Phase „Sollkonzeption“ ist es festzulegen, wie die ergonomischen Anforderungen aus der Anforderungsanalyse durch die Gestaltung von Arbeitsprozessen, Bildschirmdialogen und SAP-Rollen umgesetzt werden sollen. Die ergonomischen Aktivitäten in dieser Phase führen zu vollständigen, konsistenten und eindeutigen Formulierungen von Gestaltungsvorgaben an die SAP-Software sowie – falls erforderlich – an die Arbeitsorganisation. Diese verbindlich festgelegten Gestaltungsvorgaben werden im Sollkonzept dokumentiert. Um kostspieligen Fehlentwicklungen frühzeitig vorzubeugen, wird in Ergänzung zu den in der ASAP Implementation Roadmap vorgesehenen Arbeitsschritten in der Business Blueprint Phase das Sollkonzept von Benutzern evaluiert. Von Vorteil ist es, dass zu diesem Zeitpunkt des Projektfortschrittes erforderliche Änderungen noch recht einfach möglich und kostengünstiger sind als später. Das evaluierte und ggf. überarbeitete Sollkonzept wird als Ergebnis dieser Phase im Ergonomischen Meilenstein 3 als verbindliche Vorgabe für die Realisierungsphase verabschiedet. Die Phase „Sollkonzeption“ setzt sich aus folgenden Bausteinen zusammen: •

Arbeitsprozess- und Dialoggestaltung Unter Berücksichtigung der Ergebnisse der Anforderungsanalyse und grundlegender ergonomischer Gestaltungsregeln, wie beispielsweise allgemeiner Styleguide-Regeln, werden Gestaltungsvorgaben für die einzelnen Arbeitsprozesse und Dialoge konzipiert. Durch eine Machbarkeitsprüfung wird sichergestellt, dass sich die Vorgaben im Unternehmen technisch und/oder organisatorisch umsetzen lassen. Die Gestaltungsvorgaben sollen sicherstellen, dass die Arbeitsprozesse

173

7 Sollkonzeption und Dialoge den ermittelten ergonomischen Anforderungen entsprechen und die jeweiligen Usability-Ziele erreicht werden können. •

Ergonomischer Rollenzuschnitt Beim ergonomischen Rollenzuschnitt wird sichergestellt, dass einerseits die zukünftigen Aufgabenzuschnitte der Benutzer ergonomischen Anforderungen entsprechen und andererseits die den Benutzern zugewiesenen SAP-Rollen aufgabenangemessen sind. Im Hinblick auf die Aufgabenzuschnitte werden sowohl Aufgaben betrachtet, die mit SAP-Unterstützung erledigt werden, als auch darüber hinausgehende Aufgaben.

•

Evaluation mit Benutzern Die im Sollkonzept zusammengetragenen Gestaltungsvorgaben für Arbeitsprozesse, Dialoge und Rollenzuschnitte als Gesamtkonzeption der künftigen Arbeit mit der SAP-Software werden von Benutzern vor dem Hintergrund ihrer realen Arbeitsaufgaben und Arbeitsbedingungen überprüft. Auf diese Weise können ergonomische Schwachstellen im Sollkonzept entdeckt und behoben werden, bevor mit der Realisierung begonnen wird.

Gestaltungsvorgaben prüfen

Der Phase „Sollkonzeption“ kommt innerhalb des Usability Management eine entscheidende Rolle zu. Denn in dieser Phase gilt es die technischen und organisatorischen Anforderungen mit den Realisierungsmöglichkeiten der SAP-Software und des Unternehmens zusammenzubringen. Damit wird die Frage beantwortet, wie die software-ergonomischen Anforderungen aus der Phase „Anforderungsanalyse“ umgesetzt und von der SAP-Software erfüllt werden sollen. Im Einzelnen geht es darum zu bestimmen, wie •

Arbeitsprozesse und Aufgabenzuschnitte,

•

Dialoge zwischen Benutzern und SAP-Software,

•

Rollen und Berechtigungen in der SAP-Software

gestaltet sein müssen, um aus ergonomischer Sicht optimale Arbeitsabläufe und Arbeitsbedingungen zu garantieren. Im Kern ist es Aufgabe dieser Phase, die ergonomisch relevanten Einflussfaktoren, die sich aus Merkmalen der Aufgaben, der Benutzer und der SAP-Software ergeben (vergleichen Sie hierzu die Kapitel 1 und 6), bestmöglich aufeinander abzustimmen. In diesem Zusammenhang muss abgewogen werden, auf welche der drei Einflussfaktoren – Arbeitsaufgabe, Benutzer, SAP-Software – 174

7.1 Arbeitsprozess- und Dialoggestaltung so eingewirkt werden soll, dass sich das Gesamtergebnis positiv verändert. Demnach bieten sich die Möglichkeiten,

Lösungsvarianten

•

die Gestaltung der Arbeitsaufgabe zu verändern,

•

die Schulung der Benutzer in der SAP-Software anzupassen und zu intensivieren,

•

die SAP-Software ergonomischer zu gestalten.

Da sich für die Umsetzung der Anforderungen aus der Anforderungsanalyse in der Regel mehr als eine Lösungsalternative bietet, sind die Bausteine der Phase „Sollkonzeption“ nicht unabhängig voneinander zu betrachten. Beispielsweise führen unterschiedliche Varianten der Arbeitsprozessgestaltung zu verschiedenen Konsequenzen für die Dialoggestaltung und die Gestaltung der Rollenzuschnitte – und umgekehrt. Welche der unterschiedlichen Gestaltungsoptionen gewählt werden, hängt u. a. von ihrem Beitrag zur Erfüllung der gesteckten Usability-Ziele ab (vgl. Kapitel 5). Da die einzelnen Bausteine immer als Teile der gesamten Sollkonzeption zu sehen sind, wird die Ableitung der Gestaltungsvorgaben aus den dokumentierten Anforderungen bevorzugt in Workshops organisiert. In deren Rahmen lassen sich gemeinsam mit Benutzern und anderen Vertretern einzelner Bereiche (z. B. SAP-Berater, EDV-Techniker, Abteilungsleiter) die Gestaltungsvorgaben konstruktiv und effizient erarbeiten. Dabei können die im Folgenden getrennt erläuterten Aktivitäten zur Arbeitsprozess- und Dialoggestaltung und zum ergonomischen Rollenzuschnitt durchaus in einem Workshop zusammengefasst werden. Das formulierte Sollkonzept, das klare Zielvorgaben zur Anpassung der SAP-Software im Unternehmen enthält, ist ein zentrales Ergebnis dieser Phase. Darüber hinaus dient das Sollkonzept der Legitimierung und Überprüfung der Zielerreichung in späteren Phasen.

7.1

Arbeitsprozess- und Dialoggestaltung

Workshop zur Gestaltung

Es empfiehlt sich, die Aktivitäten zur Arbeitsprozess- und Dialoggestaltung in einem Workshop zusammenzufassen. So lässt sich zum einen der Verzahnung zwischen Arbeitsprozessen und Dialogen gerecht werden und zum anderen ökonomisch vorgehen. Ziel des Workshops ist es, durch die Ableitung von Gestaltungsideen aus den erhobenen ergonomischen Anforderungen konkrete Gestaltungsvorgaben für Arbeitsprozesse und Dialoge zu formulieren. 175

7 Sollkonzeption Um die Gestaltungsvorgaben möglichst nah an den Arbeitsaufgaben entwickeln zu können, wird der Workshop gemeinsam mit Benutzern der zukünftigen SAP-Software durchgeführt. Die Auswahl der teilnehmenden Benutzer (max. fünf) erfolgt dabei im Hinblick auf die zu erörternden Arbeitsaufgaben. Die Teilnehmergruppe kann sich sowohl aus Benutzern mit demselben Tätigkeitsprofil als auch aus Benutzern aus verschiedenen Unternehmensbereichen zusammensetzen. Entscheidend ist die Kenntnis der Arbeitsaufgabe. Ist die Anzahl der mit der SAP-Software zu unterstützenden Arbeitsaufgaben in einem Unternehmen zu groß, um innerhalb eines Workshops ausgearbeitet zu werden, sollten diese in sinnvolle Einheiten aufgeteilt und in mehreren Workshops diskutiert werden. Aus den Reihen des Projektteams wird ein Moderator mit der Durchführung und Leitung des Workshops betraut. Der Moderator sollte über software-ergonomische Vorkenntnisse und über Erfahrung in der Moderation von Workshops verfügen. Zusätzlich wird ein so genannter Konsistenzmanager ernannt.

7.1.1

Konsistenzmanager Hauptaufgabe des Konsistenzmanagers, der an allen Workshops zur Arbeitsprozess- und Dialoggestaltung teilnimmt, ist es, sicherzustellen, dass bei der Umsetzung von Gestaltungsvorgaben für verschiedene Dialoge die innere Konsistenz gewahrt wird, d. h. die Einheitlichkeit in Erscheinungsbild und Bedienung der Benutzungsoberfläche. Die Struktur von Bildschirmmasken muss beispielsweise auch in unterschiedlichen Dialogen vergleichbar sein, Funktionstastenbelegung und Menüaufbau müssen gleich sein etc. (vgl. Kapitel 3, Abschnitt 3.3.2). Die Gestaltungsvorgaben aus den einzelnen Workshops dürfen einander daher auch in diesen Punkten nicht widersprechen, und es ist Aufgabe des Konsistenzmanagers, dies sicherzustellen.

Übergreifende Gestaltungsregeln

176

Hierfür ist es sinnvoll, dass der Konsistenzmanager aus den ersten erarbeiteten Gestaltungsvorgaben übergreifende Gestaltungsregeln für alle diejenigen Aspekte ableitet, die mehrere Dialoge betreffen. Diese Gestaltungsregeln müssen bei weiteren Gestaltungsprozessen berücksichtigt werden und dürfen im Zweifelsfall nur vom Konsistenzmanager (ggf. nach Rücksprache mit den Betroffenen) verändert werden. Als Ausgangsbasis für übergreifende Gestaltungsregeln bieten sich die in Kasten 7.1 aufgezählten Beispiele für ergonomische Gestaltungsanforderungen an, die sich vielfach bei der ergonomischen Optimierung von SAP-Soft-

7.1 Arbeitsprozess- und Dialoggestaltung ware als relevant erwiesen haben. Der Konsistenzmanager ergänzt diese übergreifenden Gestaltungsregeln sukzessive im weiteren Verlauf der Gestaltungsprozesse, und die Regeln behalten auch für spätere Anpassungen der Software nach dem Go Live ihre Gültigkeit. Kasten 7.1: Ergonomische Gestaltungsanforderungen, die als Ausgangsbasis für übergreifende Gestaltungsregeln dienen können (Beispiel) Checkliste Ergonomische Anforderungen Die nachfolgende Checkliste ergonomischer Anforderungen kann bei der Arbeitsprozess- und Dialoggestaltung als Hilfsmittel eingesetzt werden, um die ergonomische Qualität von Prozessen zu überprüfen und typische ergonomische Mängel zu vermeiden. 1. Alle für die Erledigung der Arbeitsaufgaben erforderlichen Leistungen der Software sind vorhanden und fehlerfrei • Alle benötigten Informationen können in der Software hinterlegt werden. • Alle benötigten Informationen werden bei Bedarf angezeigt. • Alle für das Unternehmen wichtigen Auswertungen können mit der Software erstellt werden. 2. Es entsteht kein unnötiger Aufwand bei der Handhabung der Software • Felder, Masken, Meldungen etc., die der Benutzer für seine Arbeit nicht benötigt, werden nicht angezeigt. • Arbeitsschritte, die die Software automatisch ausführen kann, müssen nicht durch den Benutzer erledigt werden. 3. Die Arbeitsabläufe sind in der Software so abgebildet, wie sie real durchlaufen werden • Im Arbeitsablauf muss nicht zwischen Feldern hin- und hergesprungen werden; beispielsweise sind Eingabefelder in der gleichen Reihenfolge angeordnet, wie auf den Unterlagen aus denen Daten übernommen werden. • Der Arbeitsablauf wird durch eine passende Maskenabfolge effektiv unterstützt, beispielsweise muss nicht zwischen Masken gesprungen werden, und zusammengehörende Bearbeitungsschritte werden durch eine entsprechende Maskenabfolge abgebildet. 177

7 Sollkonzeption • Wenn Arbeitsabläufe häufig unterbrochen werden müssen, wird dies von der Software durch ein unterbrechungsresistentes Design unterstützt; beispielsweise ist ein schnelles Erkennen des letzten Bearbeitungsstandes möglich, und die Arbeit kann ohne Verzögerung nach einer Unterbrechung wieder aufgenommen werden. • Felder, in die häufig oder immer die gleichen Werte eingetragen werden, enthalten entsprechende Vorbelegungen. 4. Die Oberflächengestaltung der Software ist übersichtlich und einheitlich, benötigte Informationen sind schnell auffindbar und verständlich • Fehlermeldungen sind verständlich und liefern einen Hinweis darauf, wie der Fehler behoben werden kann. • Namen von Funktionen, Feldern etc. erlauben einen eindeutigen Rückschluss auf den Inhalt. • Angezeigte Listen (z. B. Wertelisten) sind nach einem nachvollziehbaren System sortiert und enthalten nicht unnötig viele überflüssige Einträge. • Einheitliches Verhalten der Software in allen ihren Bestandteilen; beispielsweise führen gleiche Funktionstasten, Buttons, Menüpunkte etc. in allen Masken der SAPSoftware zu den gleichen Reaktionen. 5. Die Reaktionszeiten der Software ermöglichen einen flüssigen Arbeitsablauf • Masken lassen sich schnell aufrufen. • Speicherung erfolgt innerhalb weniger Sekunden. • Auswertungen liefert die Software so zügig, dass für den Benutzer keine störenden Wartezeiten entstehen. 6. Die Zuständigkeiten für Daten- und Systempflege sind organisatorisch eindeutig geregelt • Es gibt keine Mehrfachzuständigkeiten für die Pflege der gleichen Daten. • Für alle Daten ist die Zuständigkeit für die Datenpflege geregelt (keine „Zuständigkeitslücken“).

178

7.1 Arbeitsprozess- und Dialoggestaltung • Für die Systempflege sind Verantwortliche benannt, und die entsprechenden Zuständigkeiten sind allen Benutzern bekannt. 7. Die Benutzer erhalten alle für die Erledigung der Arbeitsaufgaben erforderlichen Berechtigungen – und darüber hinaus keine unnötigen Berechtigungen • Die Benutzer haben Zugang zu allen benötigten Funktionen (Transaktionen, Reports etc.). • Die Benutzer haben Zugang zu allen benötigten Daten. • Auf Funktionen und Daten, die sie nicht für ihre Arbeitsaufgaben benötigen, können die Benutzer nicht zugreifen. Neben der Hauptaufgabe, die Konsistenz der Benutzungsoberfläche sicherzustellen, obliegen dem Konsistenzmanager noch einige weitere Aufgaben:

7.1.2

•

die Abstimmung der Gestaltungsvorgaben aus den einzelnen Workshops, die nicht unmittelbar die Benutzungsoberfläche betreffen;

•

die Anregung der technischen und organisatorischen Machbarkeitsprüfung, wenn alle relevanten Workshops abgeschlossen sind;

•

die Sicherstellung der Prüfung der erarbeiteten Gestaltungsideen auf Konformität mit den übergreifenden Gestaltungsregeln, den Usability-Zielen und den erhobenen Anforderungen;

•

die Dokumentation der übergreifenden Gestaltungsregeln, die den Projektbeteiligten zugänglich sein sollen.

Weitere Workshopteilnehmer Es ist sinnvoll, einen SAP-Berater an dem Workshop zur Arbeitsprozess- und Dialoggestaltung zu beteiligen, der einen guten Überblick über verschiedene systemtechnische Lösungsalternativen in der SAP-Landschaft hat. Er kann bereits während der Ableitung von Gestaltungsideen Hinweise auf evtl. nicht bekannte alternative technische Umsetzungsmöglichkeiten geben und prüfen, ob die Gestaltungsideen technisch machbar sind. Unterstützt werden die Teilnehmer des Workshops durch einen ergonomisch erfahrenen (externen) Fachmann. Von Vorteil ist zum einen sein unvoreingenommener Blick auf betriebliche Merkmale, zum anderen seine Erfahrungen und Kenntnisse zum methodi-

179

7 Sollkonzeption schen Vorgehen bei der Ableitung von Gestaltungsideen aus ergonomischen Anforderungen.

7.1.3

Vorgehen im Workshop Bei der Durchführung des Workshops zur Arbeitsprozess- und Dialoggestaltung empfehlen wir Ihnen, sich an den folgenden Schritten zu orientieren:

Ablauf des Workshops

1. Review der Anforderungen und der Usability-Ziele 2. Optional: Entwurf idealer Prozesse und Dialoge 3. Sichten des SAP-Standards bzw. der vorgesehenen SAPLösung 4. Abgleich mit der SAP-Lösung 5. Ableiten von Gestaltungsideen 6. Überprüfen der Gestaltungsideen 7. Entscheidung über Gestaltungsvorgaben Diese sieben Schritte werden anschließend einzeln vorgestellt und anhand eines Praxisbeispiels (s. Kasten 7.2) veranschaulicht. 1. Review der Anforderungen und der Usability-Ziele

Arbeitsgrundlagen sichten

Im ersten Schritt werden von den Teilnehmern die Usability-Ziele und die Ergebnisse der Anforderungsanalyse gesichtet. Hier geht es zunächst vor allem darum, die Teilnehmer auf einen Wissensstand zu bringen und den beteiligten Benutzern notwendiges Hintergrundwissen zu vermitteln bzw. zu vergegenwärtigen. Außerdem empfiehlt es sich an dieser Stelle, die Arbeitsaufgaben, für die Gestaltungsvorgaben entworfen werden sollen, zu priorisieren. Dabei ist darauf zu achten, dass an erster Stelle Arbeitsaufgaben bearbeitet werden, deren Gestaltung sich auf weitere Arbeitsprozesse auswirkt. 2. Optional: Entwurf idealer Prozesse und Dialoge

Ideale Lösung entwerfen

180

In einem optionalen zweiten Schritt erfolgt der Entwurf und die Visualisierung von idealen Prozessen und idealen Dialogen vor dem Hintergrund der ergonomischen Anforderungen. Dieser Schritt ist nicht zwingend notwendig. Ein Vorteil von gemeinsam mit Benutzern entworfenen idealen Prozessen und Dialogen ist zum einen die höhere ergonomische Qualität. Zum anderen ist der erforderliche Abgleich der ergonomischen Anforderungen mit dem SAP-Standard im vierten Arbeitsschritt (s. u.) mit dokumentierten, visualisierten Abläufen einfacher zu realisieren, weil

7.1 Arbeitsprozess- und Dialoggestaltung schneller klar wird, was umgesetzte Anforderungen für die Benutzungsoberfläche bedeuten. Papierprototypen

Um die verschiedenen Gestaltungsideen für ideale Prozesse und Dialoge zu visualisieren, verwendet man so genannte Papierprototypen (vgl. Kapitel 13). Mit dieser Art und Weise der Darstellung einer Benutzungsoberfläche lassen sich Inhalt, Aufbau und Funktionen von Bildschirmmasken sowie Systemreaktionen bildhaft machen. Papierprototypen bieten folgende Vorteile: •

sie sind schnell, einfach und ohne Vorkenntnisse der Software erstellbar;

•

ihre Kosten fallen sehr gering aus;

•

sie lassen die parallele Erstellung alternativer Lösungen zu;

•

sie lassen sich ad hoc ändern.

Mit einer Abfolge von Papierprototypen, die im Einzelfall durch weitere Materialien (z. B. Formulare) ergänzt werden können, lassen sich ganze Arbeitsabläufe simulieren. Dieses Verfahren eignet sich besonders gut, um verschiedene Lösungsalternativen für einzelne Abläufe zu diskutieren. 3. SAP-Standard bzw. sonstige vorgesehene SAP-Lösung sichten Vorgesehene Lösung kennenlernen

Sollte bisher kein SAP-Berater am Workshop beteiligt worden sein, so ist es angeraten, ihn in diesem dritten Arbeitsschritt hinzuzuziehen. Der SAP-Berater ist für die Vorstellung des SAP-Standards bzw. einer sonstigen zu diesem Zeitpunkt vorgesehenen SAP-Lösung, falls die vorgesehene Lösung nicht dem Standard entspricht, zuständig. Dies geschieht beispielsweise in Form eines Demo-Systems mit Beispielprozessen oder in Form von Screenshots. Anhand dieser Materialien lassen sich die für die Arbeitsaufgaben notwendigen Schritte in der Software von den Teilnehmern durchspielen. Beachten Sie in diesem Zusammenhang bitte, dass die einzelnen Abfolgen für die Teilnehmer nachvollziehbar sein müssen und die zugrundeliegende Arbeitsaufgabe und ihre Umsetzung in der SAP-Software nachzuvollziehen ist. 4. Abgleich mit der SAP-Lösung

Vorgesehene Lösung beurteilen

Der vierte Schritt besteht im Abgleich der ergonomischen Anforderungen bzw. der in Schritt 2 erstellten idealen Arbeitsprozesse und Dialoge mit der SAP-Lösung. Dabei überprüfen die Teilnehmer, ob die Masken, Maskenfolgen, Funktionen und Arbeitsschritte die erhobenen Anforderungen erfüllen. 181

7 Sollkonzeption • Arbeitsaufgaben „durchspielen“

Abgleich der SAP-Lösung mit Anforderungen Wurde der optionale zweite Arbeitsschritt des Workshops nicht durchlaufen, so wird die SAP-Lösung direkt mit den erhobenen ergonomischen Anforderungen abgeglichen. Dazu überprüfen die Teilnehmer beim Durchgehen einzelner Aufgaben, ob die SAP-Lösung die vorliegenden Anforderungen erfüllt. Wird im Verlauf des Abgleichs festgestellt, dass die ergonomischen Anforderungen nicht erfüllt werden können, so wird der entsprechende Punkt festgehalten.

•

Abgleich der SAP-Lösung mit idealen Arbeitsprozessen und Dialogen Zum Abgleich können beispielsweise Tests durch das Projektteam durchgeführt werden, in denen eine Arbeitsaufgabe einerseits anhand der in Schritt zwei erstellten idealen Arbeitsprozesse und Dialoge und andererseits in der SAP-Lösung „durchgespielt“ wird. Auf diese Weise lässt sich einfach und direkt ermitteln, welche Anforderungen die SAP-Software bisher nicht erfüllt. Zeigt Ihnen das Ergebnis des Tests, dass die Masken, Maskenfolgen, Funktionen und Arbeitsabläufe nicht auf die Anforderungen der Arbeitsaufgabe abgestimmt sind, so wird der betreffende ergonomische Mangel markiert. Hier lassen sich außerdem bereits konkrete Hinweise auf nötige Änderungen formulieren.

5. Ableiten von Gestaltungsideen Verbesserungen entwickeln

Ergibt sich aus dem vorangegangenen Schritt, dass die ergonomischen Anforderungen von der vorgesehenen SAP-Lösung nicht erfüllt werden, so sind im weiteren Verlauf des Workshops Gestaltungsideen für Arbeitsprozesse und Dialoge zu entwickeln. Wie oben erwähnt, entstehen bereits im Laufe des Abgleichs des SAP-Standards mit ergonomischen Anforderungen Ideen für Gestaltungsmöglichkeiten. Diese Möglichkeiten beziehen sich prinzipiell auf die Anpassung der •

Arbeitsaufgabe, beispielsweise anhand der Einrichtung von Mischarbeits- oder reinen SAP-Arbeitsplätzen;

•

Benutzer, etwa durch Training und Schulung;

•

Software, z. B. durch Zusammenfassung und Änderung von Masken.

Ziel ist es, die Faktoren Arbeitsaufgabe, Benutzer und SAP-Software ergonomisch optimal aufeinander abzustimmen. Dazu sollte zunächst überprüft werden, inwieweit die SAP-Software ergo182

7.1 Arbeitsprozess- und Dialoggestaltung nomisch angepasst werden kann. Ist hier keine adäquate Lösung zu erzielen, kann in einem zweiten Schritt über eine Umgestaltung der Arbeitsaufgabe oder erweiterte Benutzerschulungen nachgedacht werden. Ergonomieberater Dabei empfiehlt es sich, einen (externen) Ergonomieberater in den Prozess einzubeziehen. Dieser software-ergonomisch geeinbeziehen schulte Experte kann bei der Ableitung von Gestaltungsideen konkrete Hinweise auf ideale, aber auch realisierbare Wege zur Gestaltung der Arbeitsabläufe, Funktionen und Masken geben und hat die ergonomischen Konsequenzen von Gestaltungsvorschlägen im Blick. Es reicht beispielsweise nicht, nur die Anzeige bestimmter Zusatzinformationen bei einem Bildschirmdialog zu fordern, sondern es muss auch bedacht werden, ob diese ergonomisch sinnvoller als Pop-Up-Fenster oder als neue, zusätzliche Maske realisiert werden sollten, und es ist zu entscheiden, wie man wieder zur Ausgangssituation im Dialog zurückkehrt. Zudem ist es Aufgabe des Ergonomieberaters, bei Bedarf zwischen den unter Umständen nicht gleichgerichteten Interessen der Benutzer und der Unternehmensverantwortlichen zu moderieren und beispielsweise zu verdeutlichen, welche Gestaltungsvorgaben für eine gute Usability unverzichtbar sind. Die Gestaltungsideen sind möglichst detailliert zu dokumentieren. Achten Sie darauf, dass die Gestaltungsideen nachvollziehbar und anschaulich, z. B. anhand von Papierprototypen und Screenshots mit Anmerkungen, vorliegen. 6. Überprüfen der Gestaltungsideen Umsetzbarkeit überprüfen

Im sechsten Schritt befassen sich die Mitglieder des Projektteams einschließlich des Konsistenzmanagers, des SAP-Beraters, des Ergonomieexperten sowie weiterer Verantwortlicher (z. B. Benutzervertreter, IT-Betreuer, Betriebs-/Personalrat) mit der Überprüfung der im vorigen Schritt entwickelten Gestaltungsideen auf: •

organisatorische Machbarkeit inkl. Aufwandsschätzung;

•

technische Machbarkeit inkl. Aufwandsschätzung;

•

Einhaltung übergreifender Gestaltungsregeln;

•

Erfüllung genereller ergonomischer Anforderungen;

•

Erfüllung der Usability-Ziele.

Dieser Schritt kann auch aus dem Workshop ausgegliedert und separat durchgeführt werden. Im Zuge dieser Tätigkeiten ist es ebenfalls ratsam, den hinzugezogenen Ergonomieexperten als 183

7 Sollkonzeption Moderator einzusetzen. Es ist insbesondere Aufgabe des vom Projektteam eingesetzten Konsistenzmanagers, sicherzustellen, dass die notwendigen Dokumente (Usability-Ziele, übergreifende Gestaltungsregeln, Dokumente der Anforderungen, entworfene Gestaltungsideen) vorliegen. 7. Entscheidung über Gestaltungsvorgaben Gestaltungsvorgaben festlegen

Als letzter Schritt der Arbeitsprozess- und Dialoggestaltung wird nach der Überprüfung der Gestaltungsideen entschieden, welche Gestaltungsvorgaben umgesetzt werden sollen. In diesem Schritt trifft das Projektteam in Abstimmung mit dem SAP-Berater und dem Ergonomieexperten Entscheidungen bezüglich der umzusetzenden Gestaltungsvorgaben für die bearbeiteten Arbeitsprozesse. Wenn die Überprüfung der Gestaltungsideen positiv war, können diese direkt als umzusetzende Gestaltungsvorgaben übernommen werden. Sollten sie sich jedoch als nicht machbar erwiesen haben oder gegen Usability-Ziele verstoßen, müssen sie nochmals gemeinsam mit den Benutzern angepasst werden, oder es müssen Alternativen entwickelt werden, die der ursprünglichen Intention möglichst nahe kommen. Diese müssen dann erneut überprüft werden. Die Entscheidungen, welche Gestaltungsvorgaben umzusetzen sind, werden so weit wie möglich durch anschauliche Dokumente illustriert und den Benutzern zurückgemeldet.

Dokumentation der Vorgaben

Die abschließende Dokumentation der Aktivitäten zur Arbeitsprozess- und Dialoggestaltung ist so zu gestalten, dass die Ergebnisse eine geeignete Arbeitsgrundlage für die weiteren Aktivitäten zum Usability Management (beispielsweise ergonomischer Rollenzuschnitt, Evaluation mit Benutzern, verabschiedetes Sollkonzept) bilden. Dazu ist es notwendig, dass sämtliche Gestaltungsvorgaben so formuliert sind, dass sie

184

•

vollständig sind, d. h. alle für die einzelnen Arbeitsprozesse, Dialoge und SAP-Rollen nötigen Inhalte enthalten;

•

widerspruchsfrei sind, d. h. keine sich widersprechenden Angaben zur Umsetzung machen;

•

eindeutig sind, d. h. sich auf konkrete Arbeitsprozesse, Dialoge und SAP-Rollen beziehen;

•

durchführbar sind, d. h. aufgrund einer technischen und organisatorischen Machbarkeitsprüfung umsetzbar erscheinen.

7.1 Arbeitsprozess- und Dialoggestaltung Zudem sollte eine klare Trennung von Muss- und Wunschkriterien vorliegen. Dauer des Workshops Die Dauer eines solchen Workshops zur Arbeitsprozess- und Dialoggestaltung hängt vom Umfang der betrachteten Geschäftsprozesse und der Arbeitsaufgaben eines Unternehmens ab. In vielen Fällen können die Aktivitäten an einem Tag durchlaufen werden. Allerdings sollte im Bedarfsfall ein zweiter Durchgang eingeplant werden, wenn beispielsweise die Machbarkeitsprüfung nicht abgeschlossen werden kann. Kasten 7.2: Arbeitsprozess- und Dialoggestaltung (Beispiel) Von den Anforderungen zur ergonomischen SAP-Lösung Ein Dienstleistungsunternehmen führt SAP R/3 für die Abrechnung von Leistungen ein (vgl. Kasten 6.7 in Kapitel 6). Dem Projektteam liegen alle notwendigen Dokumente und Unterlagen vor: •

die Ergebnisse der Anforderungsanalyse;

•

die vereinbarten Usability-Ziele;

•

erste übergreifende Gestaltungsregeln in Form einer Checkliste ergonomischer Anforderungen (vgl. Kasten 7.1).

Im Workshop „Arbeitsprozess- und Dialoggestaltung“ sollen die ergonomischen Anforderungen mit dem SAP-Standard abgeglichen und nötige Änderungen diskutiert werden. An dem eintägigen Workshop nehmen außer dem Projektteam (Konsistenzmanager, Ergonomieexperte als Moderator, ein Mitglied des Betriebsrates, ein SAP-Berater) vier Benutzer aus der Benutzergruppe „Assistenzfachkräfte“ teil. Im Workshop werden zunächst die Abrechnungsmodalitäten der häufig genutzten „Einzelleistungen“ behandelt. 1.

Review der Anforderungen und der Usability-Ziele

Im ersten Schritt gehen Projektteam und Workshopteilnehmer die Ergebnisse der Anforderungsanalyse und die Usability-Ziele durch. Dabei wird besonderes Augenmerk auf die Anforderungen mit hoher Priorität gelegt. Dies sind „Anpassbarkeit individueller Leistungen“, „Durchführungszeit: max. 1 min.“ und „eine Maske bzw. möglichst wenige Masken zur Dateneingabe“.

185

7 Sollkonzeption

Abbildung 7.1: Übersicht der dokumentierten Anforderungen und Rahmenbedingungen 2.

Entwurf idealer Prozesse und Dialoge

Im zweiten Arbeitsschritt entwerfen die Workshopteilnehmer einen idealen Arbeitsprozess und auf diesen abgestimmte Bildschirm-Dialoge. Parallel wird bei diesem Schritt auch der künftige Aufgabenzuschnitt der Benutzer diskutiert, und es werden Anforderungen an den Soll-Aufgabenzuschnitt abgeleitet (vgl. hierzu Abschnitt 7.2). Grundlage sind die ermittelten ergonomischen Anforderungen und die Usability-Ziele. Konkret modelliert werden die idealen Arbeitsprozesse und Dialoge anhand der Ergebnisse der im Workshop geführten Diskussionen. Gestaltungsvorgaben für den Soll-Aufgabenzuschnitt und einen idealen Arbeitsprozess Aufgrund allgemeiner ergonomischer Richtlinien und Anforderungen der Benutzer (Assistenzfachkräfte am Empfang) werden folgende Gestaltungsvorgaben für den künftigen Aufgabenzuschnitt und den Arbeitsprozess „Dokumentation und Abrechnung von Sachverständigenleistungen“ festgehalten:

186

7.1 Arbeitsprozess- und Dialoggestaltung •

•

bisherige Mischarbeitsplätze sollen erhalten bleiben; d. h. die Kombination von Aufgaben am Bildschirm mit vorund/oder nachgelagerten Aufgaben ohne Bildschirmeinsatz soll weiterhin für alle Benutzer möglich sein; es werden keine gesonderten Arbeitsplätze zur Dateneingabe in SAP eingerichtet;

•

die Betreuung der Kunden erfolgt weiterhin umfassend „aus einer Hand“;

•

die Kunden können nach der Bearbeitung der Dokumentation und der Abrechnung erbrachter Leistungen ausgedruckte Bescheinigungen direkt mitnehmen;

•

der Arbeitsprozess kann jederzeit für andere Tätigkeiten unterbrochen und anschließend ohne Zeitverlust reibungslos wieder aufgenommen werden.

Diskutiert wird zudem, wie sich die Arbeit unterbrechungsfreier organisieren lässt. Da die Arbeit im Empfangsbereich nicht gänzlich unterbrechungsfrei gestaltet werden kann, werden die Anforderungen an das unterbrechungsresistente Design der Masken als umso wichtiger erachtet. Entwurf idealer Dialog Die dokumentierten Vorgaben für einen idealen Arbeitsprozess dienen als Grundlage für die Gestaltung des idealen SAPDialoges. Unter Berücksichtigung der bereits durchgesehenen ergonomischen Anforderungen aus der Anforderungsanalyse und der Usability-Ziele werden Alternativen zur Umsetzung der notwendigen einzelnen Arbeitsschritte in einer Maske entwickelt. Die Teilnehmer erarbeiten daher die erforderlichen Bestandteile der Eingabemasken anhand eines Papierprototypen der Maske auf einem Flipchart. Der entworfene Papierprototyp (s. Abbildung 7.2) fasst alle notwendigen Schritte in einer Maske zusammen. Alle notwendigen Eingabefelder und Tabellen werden aufgezeichnet. Dabei werden die Angaben aus den Anforderungen durch konkrete Hinweise der teilnehmenden Benutzer ergänzt. Im unteren Teil der nachfolgenden Abbildung wurde eine Sucheingabe und die dazugehörige Ergebnismaske (als PopUp-Fenster) skizziert.

187

7 Sollkonzeption

Abbildung 7.2: Papierprototyp der idealen Maske (Beispiel) 3.

SAP-Standard sichten

Im dritten Schritt wird der SAP-Standard durchgesehen, der zur Bearbeitung des Arbeitsprozesses „Dokumentation und Abrechnung von Sachverständigenleistungen“ zur Verfügung steht. Folgende Schritte sieht der Standard vor (hervorgehoben sind die Masken 3 und 11, die die hauptsächlichen Arbeitsschritte abbilden): 188

7.1 Arbeitsprozess- und Dialoggestaltung

189

7 Sollkonzeption

190

7.1 Arbeitsprozess- und Dialoggestaltung

Abbildung 7.3: Screenshots der SAP-Lösung zur Einzel-Abrechnung von Dienstleistungen 4.

Abgleich mit der SAP-Lösung

Die SAP-Lösung wird mit dem Entwurf des idealen Dialoges und den Anforderungen verglichen. Ergebnis ist, dass •

die Anforderungen „eine Maske bzw. möglichst wenige Masken zur Dateneingabe“ sowie „übersichtliches/klares Layout“ mit den 17 notwendigen Schritten in der vorgeschlagenen SAP-Lösung nicht zusammenpassen, da zu viele Zwischenschritte zum Markieren, Auswählen und Bestätigen nötig sind;

•

die Durchführungszeit der Arbeitsaufgabe bei ca. 2 Min. 30 Sek. liegt und somit die vierte Anforderung (Durchführungszeit unter einer Minute) nicht erfüllt wird;

•

die Suche in der „Auswahlliste Serviceprodukte“ (s. Schritte 3 und 4) so gestaltet ist, dass der Cursor sofort in das entsprechende Feld des Suchergebnisses springt, somit aufgrund der Länge der Liste bisher Eingegebenes nicht mehr sichtbar ist und daher

•

die Maske „Auswahlliste Serviceprodukte“ (s. Schritt 3) nicht unterbrechungsresistent gestaltet ist. Bereits eingegebene Werte sind nach einer Unterbrechung der Eingabetätigkeit (z. B. bei Störung durch Telefonanruf) nicht mehr sichtbar und müssen mühsam durch Scrollen oder Suchen 191

7 Sollkonzeption in der Maske ermittelt werden (und in der Zeit kann schon die nächste Unterbrechung erfolgen). Unterlaufen hier Fehler, können sie nur durch eine andere, sehr umfangreiche Stornoprozedur wieder rückgängig gemacht werden. Fazit: Die meisten Anforderungen, die in der folgenden Abbildung unter „unterbrechungsresistentes Design“ zusammengefasst sind, werden vom Ist-Zustand der SAP-Software nicht erfüllt.

Abbildung 7.4: Gegenüberstellung der Anforderungen und der Arbeitschritte in der SAP-Lösung 5.

Ableiten von Gestaltungsideen

Der Abgleich der Anforderungen mit dem Ist-Zustand der SAPLösung führt zu zahlreichen Gestaltungsideen. Dabei konzentrieren sich die Teilnehmer vor allem auf Gestaltungsvorschläge zur Anpassung der SAP-Software. Dabei ist klar, dass aufgrund der vereinbarten Beibehaltung von Mischarbeit keine Veränderung der eigentlichen Arbeitsaufgabe (z. B. Einrichten eines gesonderten Eingabearbeitsplatzes) möglich ist. Auch ein zusätzliches Training wird ausgeschlossen, da die Bearbeitungszeit bei Beibehaltung der vorgesehenen SAP-Lösung durch Training kaum zu reduzieren ist. Da das Erarbeiten konkreter Gestaltungsvorgaben unmittelbar mit der Machbarkeitsprüfung einhergeht, werden die Ergebnisse im folgenden Abschnitt besprochen.

192

7.1 Arbeitsprozess- und Dialoggestaltung 6.

Überprüfen der Gestaltungsideen

Die im vorigen Schritt entwickelten Gestaltungsideen werden auf •

organisatorische Machbarkeit,

•

technische Machbarkeit,

•

Einhaltung übergreifender Gestaltungsregeln,

•

Erfüllung der Anforderungen,

•

Erfüllung der Usability-Ziele

überprüft. In unserem Beispiel kann dank der Anwesenheit des SAP-Beraters die Entscheidung über die Machbarkeit der Gestaltungsvorschläge sofort erfolgen. Anderenfalls wäre ein gesonderter Termin zur Überprüfung der Machbarkeit und – falls die Gestaltungsvorschläge sich nicht realisieren lassen – ggf. ein weiterer Workshop zur Neuformulierung von Gestaltungsideen erforderlich geworden. Schnell wird deutlich, dass das entworfene Ideal-Modell zu aufwändig für eine Realisierung ist. In der Diskussion stehen daher Gestaltungsvarianten, die dem Ideal möglichst nahe kommen und umsetzbar sind. Es erfolgt eine Einigung auf folgenden Kompromiss: •

Schritt 1 (Name eingeben) und Schritt 8 (Datum eingeben) werden auf der Einstiegsmaske zusammengefasst. Das Datum wird mit dem aktuellen Tagesdatum vorbelegt, somit können Eingaben gespart werden.

•

Benutzer müssen nicht mehr explizit einen „Kundenauftrag“ anlegen (Schritt 2). Dies erledigt die Software bei der Auswahl der Serviceprodukte automatisch im Hintergrund.

•

Die Maske „Auswahlliste Serviceprodukte“ (Schritt 3) wird so geändert, dass bereits eingegebene Serviceprodukte sichtbar sind. Die Suche (Schritt 4) wird in die Maske integriert.

•

Schritt 5 „Anzahl eingeben“ wird von der Software automatisch übernommen, da die Anzahl immer 1 beträgt.

•

Nach Schritt 3 erfolgt sofort der Sprung in die Maske „Services bearbeiten“ (Schritt 11), so dass die Zwischenschritte 6 bis 10 (Markieren, Auswählen, …) auch entfallen.

193

7 Sollkonzeption •

• •

Die Maske „Services bearbeiten“ (Schritt 11) wird so geändert, dass Änderungen, die in Schritt 12 nötig werden, gleich hier erledigt werden können. Schritt 13 („Wirklich schließen?“) bleibt als Sicherheitsfrage erhalten, Schritt 14 entfällt. Schritte 15 bis 17 bleiben aus programmablauftechnischen Gründen erhalten.

Insgesamt kann so die Eingabe von Einzelleistungen erheblich an die erhobenen Anforderungen angenähert werden und einen schnelleren und fehlerfreieren Arbeitsablauf ermöglichen.

Abbildung 7.5: Vorher-Nachher-Vergleich notwendiger Arbeitsschritte 7.

Entscheidung über Gestaltungsvorgaben

Der letzte Schritt zur Entwicklung von Gestaltungsvorgaben findet nach dem Workshop statt. Das Projektteam trifft in Abstimmung mit dem SAP-Berater und dem Ergonomieexperten Entscheidungen bezüglich der konkreten Gestaltungsvorgaben für den Arbeitsprozess „Dokumentation und Abrechnung von Sachverständigenleistungen“. Es wird die Detailkonzeption der veränderten Maske „Auswahlliste Serviceprodukte“ besprochen und festgelegt. Die Entscheidungen werden so weit wie möglich durch anschauliche Dokumente illustriert. Dazu dienen sowohl die angefertigten Papierprototypen als auch Screenshots bereits konzipierter oder umgesetzter SAP-Teillösungen mit Anmerkungen. Beispielsweise zeigen die folgen194

7.1 Arbeitsprozess- und Dialoggestaltung den beiden Abbildungen 7.6 und 7.7 Ausschnitte aus der Dokumentation zum neuen Arbeitsschritt 2 „Auswahlliste Serviceprodukte“.

Abbildung 7.6: Ausschnitt aus den dokumentierten Gestaltungsvorgaben (Beispiel 1) Ausblick Nach der oben beschriebenen Bearbeitung der Abrechnung von Einzelleistungen erfolgt ein weiterer (halbtägiger) Workshop zur Abrechnung von Sammelleistungen. Die Eingabe und Abrechnung der Sammelleistungen wird analog dem beschlossenen Vorgehen für die Einzelleistungen ge195

7 Sollkonzeption staltet. Eine zentrale Aufgabe kommt dabei dem Konsistenzmanager zu, der darauf achtet, dass gleiche Funktionen und Arbeitsschritte auch mit den gleichen Darstellungen und Interaktionen in der Software abgebildet werden wie bei den Einzelleistungen. Das kommt dem gesetzten Usability-Ziel der Vereinheitlichung von Abrechnungsmodalitäten von Einzelund von Sammelleistungen entgegen.

Abbildung 7.7: Ausschnitt aus den dokumentierten Gestaltungsvorgaben (Beispiel 2) Die Dokumentationen der beiden SAP-Kernprozesse (Einzelund Sammelabrechnung) sind Bestandteil des Sollkonzeptes und werden vor der Realisierung noch einmal von Benutzern evaluiert (s. Abschnitt 7.3). Wie eingangs bereits erwähnt, hängen Arbeitsprozess- und Dialoggestaltung und Gestaltung des ergonomischen Rollenzuschnitts so eng zusammen, dass sie häufig zumindest teilweise 196

7.2 Ergonomischer Rollenzuschnitt im gleichen Workshop behandelt werden. Der ergonomische Rollenzuschnitt ist das Thema des nächsten Abschnitts.

7.2

Ergonomischer Rollenzuschnitt

Veränderung von Aufgaben

Durch eine SAP-Einführung können sich die Aufgaben, die an einem Arbeitsplatz anfallen, sehr verändern: Es können neue Aufgaben hinzukommen und/oder bisherige Aufgaben wegfallen. Gelegentlich entstehen sogar Arbeitsplätze mit einem völlig neuen Tätigkeitsspektrum. Ziel des Bausteins „Ergonomischer Rollenzuschnitt“ ist es, sicherzustellen, dass einerseits die künftigen Aufgabenzuschnitte der Benutzer ergonomischen Anforderungen (z. B. den weiter unten aufgeführten relevanten Kriterien aus der Norm DIN EN ISO 9241-2) entsprechen und andererseits die den Benutzern in der SAP-Software zugewiesenen SAP-Rollen bzw. Rollenkombinationen aufgabenangemessen sind. Um dieses Ziel zu erreichen, sind zwei Aktivitäten erforderlich:

Ergonomischer Aufgabenzuschnitt

Erstens: Überprüfen der geplanten „Soll“-Aufgabenzuschnitte auf ergonomische Angemessenheit. Die Gesamtheit aller Aufgaben, für die ein Beschäftigter im Unternehmen zuständig ist, wird als Aufgabenzuschnitt bezeichnet. Der „Soll“-Aufgabenzuschnitt der künftigen Benutzer beinhaltet entsprechend sowohl die Aufgaben, die nach dem Go Live mit Unterstützung der SAP-Software erledigt werden, als auch alle übrigen Aufgaben. Aus ergonomischer Sicht müssen nicht nur einzelne Arbeitsprozesse, sondern auch die Kombination von Aufgaben, die die Benutzer nach der SAP-Einführung zu bearbeiten haben, belastungsarmes und produktives Arbeiten ermöglichen. Daher müssen die vorgesehenen „Soll“-Aufgabenzuschnitte auf ergonomische Angemessenheit überprüft werden.

SAP-Rollen

Zweitens: Gestalten von ergonomischen Rollenzuschnitten, d. h. Ableiten von ergonomischen Anforderungen an die jeweiligen SAP-Rollen für die „Soll“-Aufgabenzuschnitte. SAP-Rollen sind in der SAP-Software vorgegebene, anpassbare Zusammenstellungen von SAP-unterstützten Aktivitäten (Transaktionen, Berichten etc.). Im SAP-Standard wird zwischen Einzelund Sammelrollen unterschieden. Sammelrollen sind vorgegebene anpassbare Kombinationen mehrerer Einzelrollen. Die SAPRollen werden bei der SAP-Einführung den Benutzern entsprechend ihren Aufgaben zugeordnet. Dabei werden in der Regel immer Sammelrollen, d. h. eine Kombination aus mehreren Ein197

7 Sollkonzeption zelrollen, zu Benutzern zugeordnet. Die Sammelrollen können im Unternehmen angepasst werden, beispielsweise durch das Hinzufügen von Einzelrollen. Im Folgenden wird nicht mehr zwischen Einzel- und Sammelrollen differenziert. Wenn nachfolgend von SAP-Rollen gesprochen wird, so sind damit die Sammelrollen gemeint, die Benutzern zugeordnet werden sollen. Über die SAP-Rollen wird auch das Benutzermenü und die Berechtigungsvergabe generiert, um in der SAP-Software auf Funktionen und Daten zugreifen zu können. Benutzern können eine oder mehrere SAP-Rollen zugewiesen sein. SAP-Rollen wiederum können einem oder mehreren Benutzern zugeordnet sein. Aus ergonomischer Sicht ist es erforderlich, die im SAP-Standard vorgegebenen SAP-Rollen so anzupassen, dass sie die Erledigung aller betrieblichen Aufgaben, für die Benutzer jeweils zuständig sind, angemessen unterstützen. Ergonomischer Rollenzuschnitt

Unter ergonomischem Rollenzuschnitt verstehen wir daher eine den Erfordernissen eines „Soll“-Aufgabenzuschnitts entsprechende Kombination aus betrieblich angepassten SAP-Rollen inklusive Berechtigungsprofil und Benutzermenü. Ergebnis des Bausteins „Ergonomischer Rollenzuschnitt“ ist ein Konzept zum ergonomischen Rollenzuschnitt, in dem die Gestaltungsvorgaben dokumentiert sind, die aus den beiden genannten Aktivitäten resultieren.

7.2.1

Ergonomische Angemessenheit der „Soll“-Aufgabenzuschnitte Im vorangegangenen Abschnitt 7.1 „Arbeitsprozess- und Dialoggestaltung“ stand die ergonomische Optimierung einzelner Arbeitsprozesse sowie der zugehörigen Dialoge im Mittelpunkt. Für einen ergonomischen Rollenzuschnitt muss jedoch auch die jeweilige Kombination von Arbeitsprozessen und Dialogen, für die die Benutzer zuständig sind, ergonomisch angemessen sein.

Belastungsarm und produktiv

198

Es muss sichergestellt sein, dass die Kombination von betrieblichen Aufgaben, die die Benutzer nach der SAP-Einführung zu bearbeiten haben, belastungsarmes und produktives Arbeiten ermöglicht. Daher ist es nicht ausreichend, nur die Prozessabläufe und Dialoge zu betrachten, denn diese sagen zunächst noch nichts darüber aus, wie arbeitsteilig ein Prozess bearbeitet wird, welche Benutzer für welchen Prozessschritt zuständig sind und welche Arbeitsaufgaben diese Benutzer außerdem noch zu bearbeiten haben.

7.2 Ergonomischer Rollenzuschnitt Anforderungen aus der DIN EN ISO 9241-2

Mischarbeit

Wenn Sie diese Aspekte nicht berücksichtigen, kann es leicht geschehen, dass bei der Zuordnung von Aufgaben zu Personen im Rahmen einer SAP-Einführung „Soll“-Aufgabenzuschnitte entstehen, die ergonomischen Anforderungen nicht genügen. Es muss daher geprüft werden, ob die „Soll“-Aufgabenzuschnitte den im Unternehmen vereinbarten Usability-Zielen nicht zuwiderlaufen und den Anforderungen an die Aufgabengestaltung, wie sie in der DIN EN ISO 9241-2 (vgl. Kapitel 3, Abschnitt 3.3.1) beschrieben werden, entsprechen. Die „Soll“-Aufgabenzuschnitte müssen beispielsweise so gewählt sein, dass die Benutzer •

für Aufgaben zuständig sind, die ihren Fähigkeiten und Kenntnissen entsprechen und die sie zeitlich und inhaltlich weder über- noch unterfordern (Benutzerorientierung);

•

vielseitige, abwechslungsreiche Aufgaben bearbeiten und keine Monotonie entsteht (Vielseitigkeit);

•

Prozesse möglichst ganzheitlich bearbeiten und hohe Arbeitsteiligkeit vermieden wird (Ganzheitlichkeit);

•

alle bestehenden Qualifikationen weiterentwickeln und neue Qualifikationen erwerben können (Entwicklungsmöglichkeiten).

Darüber hinaus ist aus ergonomischer Sicht Mischarbeit vorteilhaft, d. h. Aufgabenzuschnitte, bei denen Tätigkeiten mit und ohne Bildschirmarbeit anfallen. Mischarbeit reduziert die mit Bildschirmarbeit verbundenen Belastungen und wird auch in der Bildschirmarbeitsverordnung empfohlen. Wenn diese ergonomischen Anforderungen nicht berücksichtigt werden, besteht besonders in Assistenzbereichen die Gefahr, dass durch die SAP-Einführung Arbeitsplätze mit unergonomischer, hoch belastungsgeprägter Arbeit entstehen, wie das nachfolgende Beispiel im Kasten 7.3 verdeutlicht. Kasten 7.3: Aufgabenzuschnitt, der ergonomischen Anforderungen nicht genügt (Beispiel) Reine Eingabearbeitsplätze sind unergonomisch Im Kasten 7.2 wurde die „Arbeitsprozess- und Dialoggestaltung“ für Assistenzkräfte eines Dienstleistungsunternehmens beschrieben. Diskutiert wurden die Abläufe dabei unter der Voraussetzung, dass alle Assistenzkräfte wie bisher alle anfallenden Aufgaben bearbeiten (Mischarbeit) und keine gesonderten Arbeitsplätze zur Dateneingabe geschaffen werden.

199

7 Sollkonzeption Die Alternative, künftig arbeitsteilig zu arbeiten und alle Eingabetätigkeiten an einem Arbeitsplatz zu konzentrieren, war jedoch ebenfalls im Gespräch. Wie wäre der Aufgabenzuschnitt eines solchen Eingabearbeitsplatzes aus ergonomischer Sicht zu beurteilen? Zunächst einmal würde es sich um einen Arbeitsplatz ausschließlich mit Bildschirmtätigkeiten handeln. Dadurch nehmen die mit Bildschirmarbeit verbundenen körperlichen und psychischen Belastungen ein sehr viel größeres Ausmaß an als bei den ergonomisch sinnvolleren Mischarbeitsplätzen. Weiterhin sind reine Eingabetätigkeiten im Vergleich zu einem Mischarbeitsplatz, an dem auch Dienstleistungen erbracht und die Kunden umfassend bedient werden, wenig abwechslungsreich und lassen keinen Gesamtzusammenhang der Aufgabe mehr erkennen. Dienstleistungen, die am Eingabearbeitsplatz nur abgerechnet werden, können inhaltlich nicht mehr nachvollzogen werden. So können leichter Fehler unterlaufen, da Unstimmigkeiten nicht erkannt werden. Eingabearbeitsplätze ermöglichen nur den Einsatz einiger weniger der vorhandenen Kenntnisse und Fähigkeiten und lassen die inhaltlich-fachlichen Qualifikationen verkümmern. Dafür stellen sie jedoch sehr hohe Anforderungen an die Konzentrationsfähigkeit, da beim Abtippen der Vorlagen, die von den anderen Assistenzkräften stammen, keine Fehler entstehen dürfen. Im Vergleich zu den Mischarbeitsplätzen bietet ein reiner Eingabearbeitsplatz im Assistenzbereich also ein Tätigkeitsspektrum, das durch monotone, wenig ganzheitliche Tätigkeiten bei gleichzeitig überhöhten Konzentrationsanforderungen und höheren Belastungen durch Bildschirmarbeit charakterisiert ist. Aus ergonomischer Sicht ist ein derartiger „Soll“-Aufgabenzuschnitt daher negativ zu beurteilen. Das Dienstleistungsunternehmen hat sich im Sinne der vereinbarten Usability-Ziele entschieden, keinen reinen Eingabearbeitsplatz zu schaffen, sondern „Soll“-Aufgabenzuschnitte für alle Assistenzkräfte zu wählen, die die bisherige ergonomisch sinnvollere Mischarbeit auch nach der SAP-Einführung ermöglichen. Dies mag zwar kurzfristig etwas mehr Aufwand verursachen (durch die erforderliche Anpassung der Dialoge), langfristig können dadurch aber die mit einem reinen Eingabearbeitsplatz verbundenen negativen Folgekosten (Demotivation, Qualifikationsverluste, hohe Krankheitsrate) vermieden wer200

7.2 Ergonomischer Rollenzuschnitt den. Auch das vereinbarte Usability-Ziel, dass die Kundenbetreuung umfassend „aus einer Hand“ erfolgen soll und die Kunden die Bearbeitungsergebnisse (Bescheinigungen etc.) sofort mitnehmen können, lässt sich nur durch den gewählten gleichen „Soll“-Aufgabenzuschnitt für alle Assistenzkräfte realisieren. Wie das Beispiel in Kasten 7.3 deutlich macht, muss sichergestellt sein, dass auch die „Soll“-Aufgabenzuschnitte ergonomischen Anforderungen und vereinbarten Usability-Zielen entsprechen. Überprüfen der Aufgabenzuschnitte

Die Überprüfung der ergonomischen Angemessenheit der „Soll“Aufgabenzuschnitte erfolgt in der Regel ebenfalls im Rahmen der in Abschnitt 7.1 beschriebenen Workshops zur „Arbeitsprozessund Dialoggestaltung“. Dort werden die vorgesehenen „Soll“Aufgabenzuschnitte gemeinsam mit den Benutzern, die später für die entsprechenden Aufgaben zuständig sind, daraufhin überprüft, ob sie •

allgemeinen ergonomischen Anforderungen (z. B. aus der DIN EN ISO 9241-2) entsprechen,

•

effektive und effiziente Aufgabenerledigung ermöglichen,

•

mit den vereinbarten Usability-Zielen des Einführungsprojektes übereinstimmen.

Falls die „Soll“-Aufgabenzuschnitte ergonomisch nicht angemessen sind, werden Gestaltungsideen für ergonomisch sinnvollere „Soll“-Aufgabenzuschnitte entworfen und an die zuständigen Entscheidungsträger weitergeleitet. Nach einem Prüfen der organisatorischen und technischen Machbarkeit resultieren daraus Gestaltungsvorgaben für ergonomisch optimierte „Soll“-Aufgabenzuschnitte, die im Konzept zum ergonomischen Rollenzuschnitt dokumentiert werden.

7.2.2

Generieren von ergonomischen Rollenzuschnitten Wenn sichergestellt ist, dass die „Soll“-Aufgabenzuschnitte ergonomischen Anforderungen entsprechen, muss in einem zweiten Schritt Sorge getragen werden, dass die einem Aufgabenzuschnitt zugeordneten SAP-Rollen die Aufgabenerledigung angemessen unterstützen. Eine Rolle in der SAP-Software ist – wie bereits erwähnt – eine vorgegebene, anpassbare Zusammenstellung von SAP-unterstützten Funktionen (Transaktionen, Berichten etc.). Die SAP-Rollen 201

7 Sollkonzeption sagen jedoch zunächst nichts darüber aus, wer im Unternehmen für welche Aufgaben tatsächlich zuständig ist. Aufgabenzuschnitt vs. SAP-Rolle

Es ist daher wichtig, zwischen den Aufgaben, die einer bestimmten Person im Unternehmen zugeordnet sind (Aufgabenzuschnitt), und einer SAP-Rolle zu unterscheiden. Die Bezeichnungen der SAP-Rollen legen in vielen Fällen den Trugschluss nahe, dass mit der Rolle automatisch auch ein bestimmter Aufgabenzuschnitt einer Person im jeweiligen Unternehmen verbunden sei. So gibt es beispielsweise im SAP-Modul HR die SAP-Rolle „Personalsachbearbeiter öffentlicher Dienst“. Diese Bezeichnung lässt vermuten, dass es in einem Unternehmen des öffentlichen Dienstes eine oder mehrere Personen gibt, deren Aufgabenzuschnitt alle anfallenden Aufgaben der Personalsachbearbeitung umfasst und denen entsprechend diese SAP-Rolle zugeordnet ist. Tatsächlich stellt diese Rolle jedoch nur einen Bruchteil der Funktionen bereit, die für die Personaladministration im öffentlichen Dienst benötigt werden. Dies sind beispielsweise Funktionen, um Daten für die Zusatzversorgung im öffentlichen Dienst sowie den Familien-, Orts- bzw. Sozialzuschlag zu pflegen oder Altersteilzeit zu bearbeiten. Weitere erforderliche Funktionen werden über die SAP-Rollen „Personalsachbearbeiter Kindergeld öffentlicher Dienst“ und „Personalsachbearbeiter Versorgung öffentlicher Dienst“ sowie über die nicht speziell für den öffentlichen Dienst geltende allgemeine SAP-Rolle „Personalsachbearbeiter Personaladministration“ zur Verfügung gestellt. Einem Personalsachbearbeiter in einem Unternehmen des öffentlichen Dienstes ist daher keinesfalls nur die SAP-Rolle „Personalsachbearbeiter öffentlicher Dienst“ zugeordnet, sondern, abhängig von den betrieblichen Aufgaben, für die er laut seines Aufgabenzuschnitts zuständig ist, noch mindestens eine, eher jedoch mehrere weitere SAP-Rollen. Dabei kann es sein, dass er aus den im SAP-Standard vorgegebenen SAP-Rollen jeweils nur einen Teil der bereitgestellten Funktionen für die Bearbeitung seiner Aufgaben benötigt. Wenn in einem Unternehmen des öffentlichen Dienstes die Personalsachbearbeitung beispielsweise arbeitsteilig so erledigt wird, dass nur ein Beschäftigter für die Bearbeitung von Altersteilzeit zuständig ist, benötigen die anderen Personalsachbearbeiter die entsprechenden Funktionen in der Rolle „Personalsachbearbeiter öffentlicher Dienst“ für die Erledigung ihrer Aufgaben nicht.

202

7.2 Ergonomischer Rollenzuschnitt SAP-Rollen sagen daher zunächst nur etwas darüber aus, welche Aktivitäten der Inhaber der SAP-Rolle jeweils mit der SAP-Software erledigen kann. Breites Spektrum im Standard

Um die betriebliche Realität möglichst vieler Unternehmen abbilden zu können, umfassen die SAP-Rollen im SAP-Standard ein breites Spektrum an bereitgestellten Funktionen. So muss beispielsweise die Rolle „Personalsachbearbeiter Personaladministration“ die Bearbeitung von Aufgaben der Personaladministration sowohl in Unternehmen mit 100 Beschäftigten als auch in einem Unternehmen mit 50.000 Beschäftigten ermöglichen. Der Aufgabenzuschnitt eines für die Personaladministration zuständigen Mitarbeiters der Personalabteilung wird jedoch in beiden Unternehmen sehr unterschiedlich sein. Während beispielsweise in dem kleinen Unternehmen ein Personalbearbeiter alle anfallenden Aufgaben der Personaladministration sowie noch weitere Aufgaben der Personalabteilung alleine erledigt, werden die Aufgaben in dem großen Unternehmen von inhaltlich spezialisierten Personalsachbearbeitern mit unterschiedlichen Aufgabenzuschnitten arbeitsteilig erledigt.

SAP-Rollen anpassen

Die im SAP-Standard vorgegebenen SAP-Rollen müssen daher entsprechend den „Soll“-Aufgabenzuschnitten des Unternehmens betrieblich angepasst werden. Für jeden Aufgabenzuschnitt muss ein Rollenzuschnitt – d. h. eine Kombination aus SAP-Rollen – generiert werden, der alle Funktionen (Transaktionen etc.) bereitstellt, die der Inhaber des „Soll“-Aufgabenzuschnitts für die Bearbeitung aller seiner Aufgaben benötigt. Überflüssige Funktionen müssen aus den SAP-Rollen des Rollenzuschnitts entfernt werden. Dadurch

Berechtigungen anpassen

•

werden Benutzerfehler vermieden (Aufruf falscher Transaktionen etc.);

•

wird die Erlernbarkeit erleichtert (kein Befassen mit überflüssigen Funktionalitäten);

•

wird die Orientierung verbessert (es werden nur benötigte Funktionen angezeigt).

Neben den jeweiligen SAP-Rollen müssen natürlich auch die über die SAP-Rollen generierten Berechtigungsprofile eines Rollenzuschnitts betrieblich angepasst werden. In Berechtigungsprofilen sind einzelne Berechtigungen, die es erlauben, auf Funktionen und Daten in der SAP-Software zuzugreifen, zusammengefasst.

203

7 Sollkonzeption Werden Personen im Rahmen der SAP-Einführung Aufgaben zugeteilt, müssen ihnen damit einhergehend auch alle erforderlichen Berechtigungen in der SAP-Software erteilt werden, damit sie ihre Aufgaben effizient erledigen können. Das Erarbeiten eines schlüssigen Berechtigungskonzepts und eine entsprechend sinnvolle Berechtigungsvergabe sind jedoch in vielen Unternehmen keineswegs eine Selbstverständlichkeit. So wird auch die ergonomische Anforderung, dass ein Benutzer die Berechtigung haben muss, auf alle für die Erledigung seiner Aufgaben erforderlichen Daten, Transaktionen etc. zugreifen zu können und vor Fehlern geschützt zu werden, indem er keine überflüssigen Berechtigungen besitzt, nicht immer erfüllt, wie das nachfolgende Beispiel in Kasten 7.4 veranschaulicht. Kasten 7.4: Nicht aufgabengerechte Berechtigungsvergabe (Beispiel) Was tun, wenn Führungskräfte reisen? In einem Energieversorgungsunternehmen war eine Mitarbeiterin der Personalabteilung zuständig für die Reisekostenabrechnung aller Mitarbeiter. Um diese Aufgabe durchführen zu können, benötigte sie die Berechtigung für die entsprechenden Transaktionen in der SAP-Software sowie die Berechtigung, auf die erforderlichen Stammdaten der Mitarbeiter in der SAP-Software zugreifen zu können. Ihr Berechtigungsprofil erlaubte ihr zwar, auf alle benötigten Transaktionen zuzugreifen, jedoch nicht auf die Stammdaten von Führungskräften des Unternehmens. Für diese Daten erhielt sie keine Berechtigung, obwohl sie mehrfach auf diesen Missstand hingewiesen hatte. Jedes Mal, wenn die Reise einer Führungskraft abzurechnen war, stand die Sachbearbeiterin vor einem Problem und musste mit großem Umstand und vielen Tricks zu einer „Notlösung“ greifen. Das kostete sie jedes Mal sehr viel Zeit und Nerven und führte regelmäßig zu verspätet abgerechneten Reisen und entsprechender Verärgerung der betroffenen Führungskräfte. Aufgabenangemessene Berechtigungen

204

Wie das Beispiel im Kasten 7.4 deutlich macht, muss ein Unternehmen, wenn es einem Beschäftigten eine bestimmte Aufgabe überträgt, dafür Sorge tragen, dass er auch alle zur Aufgabenerledigung erforderlichen Berechtigungen erhält. Sollte dies aus Gründen der Unternehmenspolitik oder aus Datenschutzgründen nicht möglich sein, darf dem Beschäftigten die Aufgabe nicht übertragen werden.

7.2 Ergonomischer Rollenzuschnitt Ergonomische Rollenzuschnitte

Daraus ergibt sich die ergonomische Anforderung, dass die über die SAP-Rollen eines Rollenzuschnitts generierten Berechtigungsprofile für die jeweiligen Benutzer alle Berechtigungen enthalten müssen, die für die Bearbeitung aller Aufgaben des dem Rollenzuschnitts zugrunde liegenden Aufgabenzuschnitts erforderlich sind. Außerdem sollten aus Datenschutzgründen und zur Vermeidung unnötiger Benutzerfehler für die Aufgabenbearbeitung überflüssige Berechtigungen aus den Berechtigungsprofilen entfernt werden.

Benutzermenü anpassen

Über die SAP-Rolle wird auch das Benutzermenü gesteuert, das den Zugriff auf benötigte Funktionen erlaubt. Dieses muss ergonomisch sein, d. h., •

das Menü muss übersichtlich sein;

•

das Menü darf nur die Menüpunkte enthalten, die der Benutzer tatsächlich benötigt;

•

die Bezeichnungen der Menüpunkte müssen verständlich sein.

Das Gestalten von ergonomischen Rollenzuschnitten inklusive Berechtigungsprofilen und Benutzermenüs geschieht in der Regel nicht gemeinsam mit den Benutzern in Workshops, sondern wird von einem oder mehreren Mitgliedern des Projektteams übernommen. Auf der Grundlage der „Soll“-Aufgabenzuschnitte und der Zuordnung von Personen zu Aufgabenzuschnitten sowie der Ergebnisse der Aufgabenanalyse und der Workshops zur „Arbeitsprozessund Dialoggestaltung“ lässt sich ableiten, welche Personen für die Bearbeitung ihrer Aufgaben welche SAP-Funktionalitäten und Berechtigungen benötigen. Diese Anforderungen müssen in einem Konzept zum ergonomischen Rollenzuschnitt systematisch dokumentiert werden. Davon ausgehend können dann für jeden Aufgabenzuschnitt die erforderlichen SAP-Rollen, Berechtigungsprofile und Benutzermenüs angepasst werden. Eventuelle Schwachstellen der Umsetzung entdecken die Benutzer bei der in Kapitel 8 beschriebenen Evaluation vor dem Go Live. Abschließend sollen noch einmal die Anforderungen an einen ergonomischen Rollenzuschnitt zusammengefasst werden. Ein Rollenzuschnitt ist ergonomisch, •

wenn der zugrunde liegende Aufgabenzuschnitt ergonomisch angemessen ist;

205

7 Sollkonzeption •

alle zur Bearbeitung aller SAP-unterstützten Aufgaben des Aufgabenzuschnitts erforderlichen Funktionen (Transaktionen etc.) in den SAP-Rollen des Rollenzuschnitts enthalten sind;

•

überflüssige Funktionen aus dem Rollenzuschnitt entfernt wurden;

•

das über den Rollenzuschnitt generierte Berechtigungsprofil alle Berechtigungen enthält, die ein Benutzer für die Bearbeitung aller Aufgaben seines Aufgabenzuschnitts benötigt;

•

überflüssige Berechtigungen aus dem Berechtigungsprofil entfernt werden;

•

das über den Rollenzuschnitt generierte Benutzermenü ergonomisch ist.

7.3

Evaluation mit Benutzern

Review Workshop

Die Evaluation der erstellten Gestaltungsvorgaben mit Benutzern wird in einem Review Workshop umgesetzt. Ziel dieses Workshops ist die software-ergonomische Qualitätssicherung der für Arbeitsprozesse, Dialoge und Rollenzuschnitte in den vorangegangenen Bausteinen erstellten Gestaltungsvorgaben. Dabei hängt es vom Urteil der beteiligten Benutzer ab, ob die Gestaltungsvorgaben zur Verabschiedung in den Ergonomischen Meilenstein 3 übergehen können oder ob die vorliegenden Entwürfe korrigiert werden müssen. Bei der Planung des Review Workshops muss das Projektteam zunächst entscheiden, ob die in den Workshops zur Arbeitsprozess- und Dialoggestaltung beteiligten oder andere, bisher nicht einbezogene Benutzer an der Evaluation teilnehmen. Bislang nicht beteiligte Benutzer betrachten die erstellten Gestaltungsvorgaben in der Regel neutraler, d. h. sie haben keinen „voreingestellten“ Blick auf die erarbeiteten Inhalte. Daher sind von ihnen eher neue Hinweise auf unzureichende Funktionalität, mangelnde Gebrauchstauglichkeit etc. zu erwarten. Benutzer, die an den vorherigen Workshops teilgenommen haben, haben wiederum den Vorteil, nicht erst in die Thematik und in die teilweise abstrakte Darstellung eingeführt werden zu müssen. Die Entscheidung, welche Benutzer am Review Workshop teilnehmen, wird wesentlich durch die Rahmenbedingungen wie die zur Verfügung stehenden zeitlichen und personellen Ressourcen beeinflusst. Ebenfalls sollten Sie bei der Planung berücksichtigen, dass die Evaluation anhand von realen Arbeitsaufgaben erfolgt und

206

7.3 Evaluation mit Benutzern daher entsprechend vorbereitet werden muss (Auswahl geeigneter Arbeitsaufgaben inkl. Problem- und Sonderfällen, Bereitstellen benötigter Arbeitsunterlagen etc.). Die Moderation des Review Workshops sollte von einem ergonomisch geschulten Experten übernommen werden, der idealerweise auch an den Workshops zur Arbeitsprozess- und Dialoggestaltung sowie ggf. am Workshop zum ergonomischen Rollenzuschnitt beteiligt war. Er muss zum einen in der Lage sein, den bisher nicht an der ergonomischen Optimierung beteiligten Benutzern Zusammenhänge zu erläutern und im Laufe der Evaluation ggf. weitere Empfehlungen zur Gestaltung der SAP-Software abzugeben. Zum anderen ist es seine Aufgabe, gemeinsam mit den Teilnehmern die vorliegenden Materialien in einem so genannten Pluralistic Walkthrough durchzugehen.

7.3.1

Pluralistic Walkthrough Die Methode des Pluralistic Walkthrough ist ein effizientes Verfahren, mit dessen Hilfe sich die erstellten Entwürfe zur Gestaltung der Software systematisch auf ihre Brauchbarkeit prüfen lassen. In diesem Zusammenhang findet das zuvor in den Gestaltungsworkshops erstellte anschauliche Material (Papierprototypen, Screenshots) Verwendung. Für eine ausführlichere Beschreibung der Methode des Pluralistic Walkthrough empfehlen wir Ihnen den Beitrag von Bias (1994). Der Pluralistic Walkthrough erfordert folgendes Vorgehen: 1. Entwürfe Schritt für Schritt durchgehen

Reale Aufgaben

Anhand „realer Arbeitsaufgaben“ gehen mehrere (oder ein) Benutzer Schritt für Schritt die vorliegenden Entwürfe zur Gestaltung der Software durch. Dabei werden auch möglichst viele die Arbeit beeinflussende Parameter einbezogen (z. B. Formulare). 2. Aufgabenstellungen „bearbeiten“

Lautes Denken

Während der Bearbeitung der Arbeitsaufgabe sind die Benutzer angehalten, ihr Vorgehen durch lautes Denken zu erläutern. Bei Zögern fragt der Moderator nach dem evtl. vorliegenden Problem. 3. Auftretende Probleme nach jeder Aufgabe diskutieren

Probleme diskutieren

Nach dem „Durchspielen“ der Arbeitsaufgaben und verschiedener Entwurfsalternativen haben die Teilnehmer Gelegenheit, auftretende Probleme und Schwierigkeiten zu diskutieren und Änderungsvorschläge zu formulieren. 207

7 Sollkonzeption 4. Auftretende Kritikpunkte und Änderungsvorschläge notieren Ergebnisse dokumentieren

Die im Verlauf der Diskussion auftretenden Kritikpunkte und Änderungsvorschläge werden dokumentiert. Im Falle einer Überarbeitung einzelner Gestaltungsvorgaben stellen sie die Grundlage für Nacharbeiten dar.

7.3.2

Aufgabe des Moderators Der Moderator des Review Workshops soll die teilnehmenden Benutzer anleiten, die zu evaluierenden Entwürfe für die Arbeitsprozesse und Dialoge aus ihrer Perspektive zu bewerten. Es kann allerdings vorkommen, dass die Benutzer an ihren realen Arbeitsplätzen unterschiedliche Aufgaben bearbeiten. In diesem Fall sind alle Beteiligten dazu aufgefordert, die Perspektive des jeweiligen Benutzers vor dem Hintergrund „seiner“ Arbeitsaufgabe möglichst genau zu verstehen und nachzuvollziehen. Mitunter liegen die Beschreibungen von Arbeitsaufgaben, die sich mit der Einführung der SAP-Software verändern oder neu hinzukommen, nicht detailliert vor. Erscheinen die Aufgabenstellungen den Benutzern daher zu abstrakt, so können auf Grundlage des Business Blueprints bestehende Arbeitsaufgaben so aufbereitet werden, dass sie den „neuen“ Arbeitsaufgaben entsprechen und diese veranschaulichen. Ergeben sich im Rahmen des Review Workshops wesentliche Mängel an der bisherigen Umsetzung der ergonomischen Anforderungen in verbindliche Gestaltungsvorgaben, so müssen die betreffenden Dokumente in einem zweiten Durchgang der Workshops zur Arbeitsprozess- und Dialoggestaltung oder zum ergonomischen Rollenzuschnitt überarbeitet, ggf. ergänzt und – falls erforderlich – erneut von Benutzern begutachtet werden. Ein Praxisbeispiel für einen solchen Review Workshop wird im nachfolgenden Kasten beschrieben. Kasten 7.5: Review Workshop (Beispiel) Kleine Fehler vor der Realisierung entdecken und beheben Bevor die Gestaltungsvorgaben des Sollkonzepts des Dienstleistungsunternehmens (s.o., Kasten 7.2) zur Verabschiedung freigegeben werden, sollen sie von bislang nicht an der Sollkonzeption beteiligten Benutzern evaluiert werden. Ihr „frischer“ Blick soll das bisher Erarbeitete noch einmal auf bisher unentdeckte ergonomische Schwachstellen überprüfen.

208

7.4 Ergonomischer Meilenstein 3 An dem Workshop nehmen neben dem Projektteam vier Assistenzfachkräfte als zukünftige Benutzer der Software teil. Die Gestaltungsvorgaben gehen jeweils zwei Benutzer anhand der während der Arbeitsprozess- und Dialoggestaltung erstellten Papierprototypen und Screenshots Schritt für Schritt durch. Auftretende Schwierigkeiten werden sofort angemerkt und diskutiert. Im Großen und Ganzen zeigen sich die Benutzer zufrieden mit den bereits erarbeiteten Gestaltungsvorgaben zur Einzelabrechnung von Leistungen mit der SAP-Software. Ein kleines Problem gab es jedoch beispielsweise in der Auswahlmaske „Service-Produkte“ (s. Abbildung 7.8). Hier wurde die Funktion „STRG-F10“ in Verbindung mit dem Icon „Mülleimer“ neben dem Eingabefeld „Suchbegriff“ gesehen. Um die Verwirrung durch die nicht eindeutige Symbolsprache zu vermeiden, wird gemeinsam der Vorschlag erarbeitet, an dieser Stelle zwei Funktionen anzubieten. Die Funktionen „Suchen“ verbunden mit dem Icon „Fernglas“ und „Suche löschen“ verbunden mit dem Icon „Mülleimer“ sollen die bisherige Lösung ersetzen.

Abbildung 7.8: Symbol und Bezeichnung sind aus Benutzersicht uneindeutig Die Änderung in der Maske „Auswahl Serviceprodukte“ ist nach Rücksprache mit dem SAP-Berater umsetzbar und wird daher in die Gestaltungsvorgaben aufgenommen.

7.4

Ergonomischer Meilenstein 3

Ergonomisches Pflichtenheft

Am Ende der Sollkonzeption steht ein von Benutzern qualitätsgesichertes Sollkonzept mit verbindlichen ergonomischen Gestaltungsvorgaben. Die dokumentierten ergonomischen Gestaltungsvorgaben aus den oben genannten Bausteinen sind mit einem „ergonomischen Pflichtenheft“ zu vergleichen. Hier werden detailliert die software-ergonomischen Qualitäten, die die SAP-Soft209

7 Sollkonzeption ware und ggf. die Arbeitsorganisation erfüllen sollen, als Realisierungsvorgaben festgehalten. Die Dialoggestaltung, inklusive ergonomischer Funktionen, Abläufe und Oberflächendesign, ist in eine konkrete, realistische und überprüfte Form gegossen und kann in der Phase „Realisierung“ umgesetzt werden. Das Ergebnis dieser abschließenden Aktivität ist die Verabschiedung des Sollkonzeptes in einem Meilensteintreffen des Steuerungsgremiums. Damit dient der Ergonomische Meilenstein am Ende dieser Phase der Überprüfung und Verabschiedung der dokumentierten Vorgaben für die folgende Phase „Realisierung“ des Usability Management. An diesem Punkt wird sichergestellt, dass alle für diese Phase wesentlichen Aktivitäten durchgeführt und alle Entscheidungen getroffen wurden, die für den weiteren Projektverlauf notwendig sind. Sollten nicht alle notwendigen Dokumente und Vereinbarungen in der in den Projektstandards vereinbarten Qualität vorliegen, so ist Nacharbeit erforderlich. Mit der Freigabe kann die Phase „Realisierung“ beginnen: Die zum Sollkonzept gehörenden Dokumente mit ihren konkreten Gestaltungsvorgaben werden den zuständigen Mitgliedern des Projektteams zur Umsetzung übergeben.

7.5

Zusammenfassung und Ausblick In diesem Kapitel haben wir dargestellt, wie Sie in Workshops ausgehend von den vorliegenden ergonomischen Anforderungen konkrete, realisierbare Zielvorgaben für die ergonomische Gestaltung von Arbeitsprozessen, Bildschirmdialogen und SAP-Rollen in Ihrem Unternehmen entwickeln können. Sie haben die Aufgaben eines Konsistenzmanagers bei der Sollkonzeption kennengelernt und wissen, dass die entwickelten Gestaltungsvorgaben für alle Projektbeteiligten nachvollziehbar im Sollkonzept dokumentiert werden müssen. Weiterhin haben Sie erfahren, wie Sie in einem Review Workshop das Sollkonzept von den Benutzern vor dem Hintergrund ihrer realen Arbeitsaufgaben und Arbeitsbedingungen evaluieren lassen können. Sie wissen auch, welche Vorteile es bietet, eine solche Evaluation mit Benutzern durchzuführen, bevor das Sollkonzept als Arbeitsgrundlage für die nachfolgenden Schritte im Einführungsprozess verabschiedet wird. Im nächsten Kapitel erfahren Sie, welche ergonomischen Aktivitäten in der Phase „Realisierung“ anstehen. Cornelius Müller und Petra Abele

210

8

Realisierung Im vorigen Kapitel haben Sie erfahren, welche ergonomischen Aktivitäten in der Phase „Sollkonzeption“ erforderlich sind. In diesem Kapitel führen wir nun aus, wie durch die Evaluation der fertig gestellten SAP-Prozesse mit Benutzern Probleme mit der Software aufgedeckt werden und worauf Sie bei der Durchführung einer solchen Evaluation achten müssen. Die Phase „Realisierung“ dient im Usability Management der Überprüfung, wie gut die Anforderungen aus dem Sollkonzept umgesetzt wurden und wie gut die SAP-Software die Erledigung der Arbeitsaufgaben unterstützt. Die standardmäßig im Rahmen des Einführungsprojektes durchgeführten Funktionstests werden im Usability Management um Tests ergänzt, mit denen überprüft wird, inwieweit die realisierte SAP-Software die zur Aufgabenerledigung notwendigen ergonomischen Anforderungen erfüllt (vgl. Kapitel 6). Die Funktionstests reichen in der Regel nicht aus, um sicherzustellen, dass die Software auch für die Benutzer effektiv, effizient und zufriedenstellend gestaltet ist. Daher ist es wichtig, vor dem Go Live Rückmeldungen über ergonomische Schwachstellen der Software, wie z. B. Navigationshindernisse oder unübersichtliche Masken, zu erhalten. In der Phase „Realisierung“ sind aus ergonomischer Sicht folgende Bausteine relevant: •

Aufbau testbarer (Teil-)Prozesse (Teil-)Prozesse müssen so realisiert werden, dass Benutzer ausgewählte Arbeitsaufgaben mit der SAP-Software durchführen können.

•

Evaluation testbarer (Teil)-Prozesse mit Benutzern Damit sichergestellt werden kann, dass die SAP-Software an die Erledigung der Arbeitsaufgaben im Arbeitskontext angepasst ist, dokumentieren Benutzer Benutzungsprobleme, die ihnen bei Tests mit der Software auffallen, sowie Verbesserungsvorschläge.

213

8 Realisierung •

Evaluation integrierter Arbeitsprozesse mit Benutzern Um zu überprüfen, ob die kooperative Bearbeitung integrierter Arbeitsprozesse im realen Arbeitskontext reibungslos möglich ist, dokumentieren Benutzer organisatorische Schwachstellen im Workflow.

•

Ergonomischer Meilenstein 4 Im Ergonomischen Meilenstein 4 wird die getestete und verbesserte SAP-Software abgenommen und der Produktivstart aus ergonomischer Sicht genehmigt.

Gründe für Benutzerbeteiligung

Bevor diese Bausteine im Folgenden näher beleuchtet werden, erläutern wir, warum es aus ergonomischer Sicht unerlässlich ist, nicht nur das Projektteam, sondern auch die Benutzer, die am Ende mit der Software arbeiten werden, an den Tests zu beteiligen. Gründe hierfür liegen im Wesentlichen in einer gewissen „Betriebsblindheit“ und in der psychologischen Dynamik von Projektteams. Betriebsblindheit meint, dass Beschäftigte, die einen großen Teil ihrer Arbeitszeit in das Projekt investieren oder sogar ganz dafür freigestellt sind (in der Regel die so genannten Key-User), so intensiv in das Projekt involviert sind, dass sie die SAP-Software eher durch die „SAP-Brille“ wahrnehmen als aus Benutzersicht. Kasten 8.1: Nutzen frühzeitiger Benutzerbeteiligung (Beispiel) Nachträgliche Tests sind teuer Nach dem Go Live der SAP-Branchenlösung im Medienbereich, IS MAM, in einem Unternehmen beklagen sich die Beschäftigten des Call-Centers über die Unübersichtlichkeit der Kundendaten und über fehlende Möglichkeiten, schnell auf alle benötigten Informationen zugreifen zu können. Ganz offensichtlich gab es bereits gravierende Mängel im Rahmen der Konzeptionsphase (Business Blueprint). Wichtige Anforderungen an den Prozess sind dort nicht berücksichtigt worden. Im Rahmen einer Abteilungssitzung wird beschlossen, einige der vorgeschlagenen Veränderungswünsche nachträglich zu realisieren, da der schnelle und reibungslose Kundenkontakt wesentlich für eine erfolgreiche Arbeit der Beschäftigten im Call-Center ist. Der zuständige Administrator ist jedoch nicht in der Lage, diese selbstständig umzusetzen, und muss Unterstützung durch das externe SAP-Beratungsunternehmen anfordern. Dieser nachträglich hohe Verbesserungsaufwand hätte vermieden werden können, wenn man die Beschäftigten des Call-Centers die Software vor dem Go Live in der Phase „Realisierung“ hätte testen lassen.

214

8.1 Aufbau testbarer (Teil-)Prozesse Ein weiterer Grund dafür, Benutzer frühzeitig zu involvieren, liegt in der „psychologischen Dynamik“ eines Projektteams. Nur in seltenen Fällen wird ein Mitglied des Projektteams zum Zeitpunkt der Tests noch grundsätzliche Kritik anbringen, da es nicht nur die Argumente für eine bestimmte Lösung, sondern auch das Budget und den engen Zeitplan kennt. Viel eher wird es vermutlich die vorliegende Lösung (vor sich und anderen) rechtfertigen. Beschäftigte dagegen, die zum ersten Mal mit der SAP-Software konfrontiert sind, betrachten dieses durch die Brille ihrer „Altsystemwelt“ und prüfen die gewählte Lösung vor allem in Hinblick auf die Nutzbarkeit für ihre Alltagsarbeit. Das mag dort hinderlich sein, wo alte Arbeitsaufgaben und -abläufe sich komplett verändert haben, doch in den meisten Fällen ermöglicht gerade diese Sicht die Aufdeckung wesentlicher Probleme und Schwachstellen, selbst wenn die Beschäftigten, die die SAP-Software evaluieren, noch nicht so vertraut mit ihrer Handhabung und den neuen Abläufen sind. Darüber hinaus kennen sich die Benutzer oft sehr gut mit Ausnahmen und Sonderfällen aus. Häufig sind das Themen, die durch die Key-User nicht vollständig abgedeckt werden können. Da die Beteiligung der Benutzer ein sensibler Prozess ist, sollte dieser mit Kompetenz und Fingerspitzengefühl gehandhabt werden. Es gilt dabei einige grundsätzliche Aspekte zu berücksichtigen, die im Folgenden ausgeführt werden: •

Koordination der Evaluation;

•

Zeitpunkt der Evaluation;

•

Einweisung der Benutzer in die Evaluation;

Koordination der Evaluation: Es ist empfehlenswert, eine Person zu bestimmen, die die Evaluation mit den Benutzern koordiniert. Dieser Koordinator sollte Mitglied des Projektteams und vom Betriebs-/Personalrat akzeptiert sein, um einen reibungslosen Informations- und Kommunikationsfluss zu gewährleisten. Dies könnte beispielsweise der Projektleiter sein. Im Folgenden werden wir diese Person als Koordinator bezeichnen. Zeitpunkt der Evaluation: Auch die Bestimmung des richtigen Zeitpunkts für die Tests ist ein wesentliches Erfolgskriterium, da das Projektbudget häufig nur wenige Tests mit Benutzern erlaubt. Um einen möglichst hohen Nutzen der Evaluation mit Benutzern zu erzielen, sollten die (Teil-)Prozesse schon weit genug ausgereift und vom Projektteam getestet sein. Andernfalls besteht die Gefahr, dass in den Tests mit Benutzern nur die Mängel auf215

8 Realisierung gedeckt werden, die das Projektteam bei eigenen Tests selbst entdeckt (z. B. reine Funktionsfehler). Wird hingegen zu spät getestet, können Veränderungen oft schon nicht mehr ohne größeren Aufwand realisiert werden. Es empfiehlt sich, die Tests in mehreren Etappen durchzuführen, da die Standards (also standardisierte SAP-Transaktionen, die nur minimal angepasst werden müssen) meistens deutlich früher fertig gestellt sind als die Zusatzentwicklungen, die ganz spezifisch für das einführende Unternehmen neu aufgesetzt werden müssen. Die Benutzertests sollten wiederholt werden, wenn im Anschluss an die Evaluation mit Benutzern wesentliche Veränderungen vorgenommen wurden. Einweisung der Benutzer in die Evaluation: Zentral ist auch die Vorbereitung der Benutzer auf ihre Aufgaben bei den Tests. Die Benutzer sollten die SAP-Software handhaben können sowie den Zweck der Evaluation und die damit verbundenen Erwartungen kennen. Sie sollten wissen, dass die Anpassung der Software noch nicht abgeschlossen ist, und sie sollten die Beschränkungen kennen, die sich daraus für sie bei der Aufgabenbearbeitung ergeben. Gerade Benutzern, die keine Erfahrungen mit Softwareentwicklung und mit Customizing haben, muss vermittelt werden, dass die Softwarelösung, die sie testen, noch bestimmten Einschränkungen unterliegt, die im Produktivbetrieb nicht mehr auftreten werden. Darüber hinaus empfiehlt es sich, den Beschäftigten eine Systematik zu vermitteln, anhand deren sie Schwachstellen der Software identifizieren und Verbesserungsvorschläge machen können.

8.1

Aufbau testbarer (Teil-)Prozesse Der Baustein „Aufbau testbarer (Teil-)Prozesse“ beginnt direkt nach der Abstimmung des Sollkonzepts. Zu diesem Zeitpunkt beginnt im SAP-Einführungsprojekt das eigentliche Customizing, d. h. die Software wird so an die Anforderungen des Unternehmens angepasst, dass damit die unternehmensspezifischen Geschäftsprozesse bearbeitet werden können. Damit Benutzer wiederum diese Bearbeitung mit Hilfe der Software testen können, müssen die dafür jeweils erforderlichen Softwarebestandteile, d. h. die Prozesse oder Teil-Prozesse, bereits funktionsfähig sein. Dies sollte bei der Planung des Customizing im Einführungsprojekt berücksichtigt werden. Außerdem müssen einige wenige zusätzliche technische Voraussetzungen (s. u.) erfüllt sein, damit Benutzer die Erledigung von Arbeitsaufgaben mit Hilfe der (Teil-)Prozesse testen können. Dabei ist die Rede von (Teil-)Prozessen, weil es nicht unbedingt erforderlich ist, mit dem Testen zu war-

216

8.1 Aufbau testbarer (Teil-)Prozesse ten, bis die Bearbeitung eines ganzen Geschäftsprozesses möglich ist. Es kann durchaus sinnvoll sein, die Bearbeitung von Bestandteilen eines Geschäftsprozesses sukzessive jeweils dann zu testen, wenn die erforderlichen Funktionalitäten der Software, d. h. die Teilprozesse, zur Verfügung stehen. So kann beispielsweise die Eingabe und Weiterbearbeitung von Daten bereits getestet werden, auch wenn der im späteren Verlauf des Geschäftsprozesses erforderliche Ausdruck einer Bescheinigung, auf der diese Daten vermerkt sind, noch nicht möglich ist. Das sukzessive Testen und ggf. Überarbeiten von Bestandteilen der Software, die bereits an die Anforderungen des Unternehmens angepasst wurden, wird als Prototyping bezeichnet. Die Begriffe „Prototyping“ und „Prototyp“ werden in Kasten 8.2 näher erläutert. Abhängig vom jeweiligen Projekt wird in der Regel in der Projektplanung für diese Phase des Prototypings ein Großteil des Zeitbudgets vorgesehen, bis schließlich die zu testende SAP-Software so weit angepasst ist, dass sie von den Benutzern getestet werden kann. Um Mehrarbeit zu vermeiden, kann es nützlich sein, beim Aufbau der Prototypen gleich einen Ergonomieberater ins Team zu holen. Dieser kann z. B. wichtige Hinweise zum ergonomischen Aufbau von Masken und Maskenfolgen geben. Zudem könnte es seine Aufgabe sein, darüber zu „wachen“, dass sowohl generelle software-ergonomische Regeln aus entsprechenden Styleguides als auch unternehmensspezifisch vereinbarte ergonomische Gestaltungsvorgaben beachtet und letztere, sofern erforderlich, auch ergänzt werden (s. Kapitel 6.2.3, Abschnitt „Anforderungen aus ergonomischen Guidelines und Normen“ sowie Kapitel 7.1.1, „Konsistenzmanager“). Kasten 8.2: Begriffsdefinitionen Prototyping und Prototypen Nach einer Definition des Informatikers Balzert (1998) bezeichnet Prototyping das frühzeitige Erstellen ablauffähiger Modelle (Prototypen) des zukünftigen Produkts zur Überprüfung von Anforderungen sowie zum Experimentieren mit verschiedenen Ideen. Die einfachste Form eines Prototypen, einen „Papierprototypen“, haben Sie bereits in der Phase „Sollkonzeption“ (Kapitel 7) kennengelernt. Im Sollkonzept gibt es den Entwurf von Benutzeroberflächen auf Papier, die im Baustein „Evaluation mit Benutzern“ getestet werden. Nun, in der Phase „Realisierung“, geht es um lauffähige Bestandteile der Software, die von den Benutzern direkt getestet werden können.

217

8 Realisierung Grundsätzlich wird unterschieden zwischen Wegwerfprototypen und inkrementellen Prototypen. Wegwerfprototypen werden allein für Tests erstellt und danach nicht weiter verwendet. Beim Aufbau einer SAP-Software kommen dagegen in der Regel inkrementelle Prototypen zum Einsatz. Es muss also keine zusätzliche Arbeit in die Entwicklung von später nicht mehr benötigten Prototypen investiert werden, sondern Prototypen entstehen sozusagen „automatisch“ im Laufe des herkömmlichen Customizing-Prozesses. Bezogen auf SAP-Software verstehen wir unter Prototypen diejenigen Softwarebestandteile, die bereits soweit an Anforderungen des Unternehmens angepasst wurden, dass damit die Bearbeitung von Geschäftsprozessen oder Geschäftsprozessteilen getestet werden kann. Diese als (Teil-)Prozesse bezeichneten Softwarebestandteile werden sukzessive getestet und, falls erforderlich, verbessert, bis die vollständige Funktionalität der Software entwickelt ist und die Software in der getesteten und verbesserten Endversion in den Produktivbetrieb übernommen werden kann (sog. iteratives Prototyping). Technische Vorbereitungen

8.2

Damit die (Teil-)Prozesse von Benutzern getestet werden können, müssen folgende Voraussetzungen erfüllt sein: •

die (Teil-)Prozesse müssen eine sinnvolle Bearbeitungseinheit (z. B. eine Arbeitsaufgabe) abbilden;

•

die (Teil-)Prozesse müssen technisch ausgereift sein, d. h., sie müssen Funktionstests erfolgreich durchlaufen haben;

•

Oberfläche und Funktionen müssen den für den Produktivbetrieb geplanten Ausprägungen entsprechen;

•

die (Teil-)Prozesse müssen in einer Testumgebung mit aktuellen Daten zur Verfügung stehen;

•

die Systemberechtigungen müssen so eingerichtet sein, dass die testenden Benutzer auf alle erforderlichen Funktionen und Daten zugreifen können.

Evaluation testbarer (Teil-)Prozesse mit Benutzern Bevor die ergonomische Evaluation der (Teil-)Prozesse stattfindet, sind in der Regel die technischen Funktionstests für die jeweiligen (Teil-)Prozesse abgeschlossen. Damit die Evaluation der (Teil-)Prozesse mit Benutzern zum Erfolg des Einführungsprojektes beiträgt, empfiehlt es sich, in folgenden Schritten vorzugehen:

218

8.2 Evaluation testbarer (Teil-)Prozesse mit Benutzern

8.2.1

Vorbereitung Eine gründliche Vorbereitung ist wesentliches Kriterium für die erfolgreiche Durchführung von Tests mit Benutzern. Diese umfasst die folgenden Aspekte: Definition der Ziele

Ableiten von Evaluationszielen

Die Ziele für die Tests mit Benutzern müssen im Projektteam formuliert werden. Teilweise können diese auch aus den im Projekteinstieg festgelegten Usability-Zielen (s. Kapitel 5) abgeleitet werden. Konkretere Testziele ergeben sich aus den Anforderungen (s. Kapitel 6) und den Festlegungen im Sollkonzept (s. Kapitel 7). Die Testziele können sowohl quantitativer als auch qualitativer Natur sein. Ein qualitatives Evaluationskriterium ist z. B. die angemessene Unterstützung der Abfolge aller Arbeitsschritte durch die SAP-Software, während die Bewältigung einer bestimmten Aufgabe in einer vorgesehenen Mindestzeit ein Beispiel für ein quantitatives Evaluationskriterium ist. Bevor die Mitarbeiter zu den Tests der (Teil-)Prozesse eingeladen werden, sollte im Projektteam besprochen werden, ob sich durch den bisherigen Projektverlauf bis dahin noch weitere Ziele für die Evaluation ergeben haben und welche formalen Testkriterien aus dem Sollkonzept bereits in den stattgefundenen (technischen) Funktionstests überprüft wurden. Auswahl der Prozesse und Aufgaben In Abhängigkeit von den Evaluationszielen werden die Prozesse ausgewählt, die von den Benutzern getestet werden sollen. Für die Tests werden zu diesem Zeitpunkt konkrete Arbeitsaufgaben formuliert. Wenn dem Koordinator das Ergebnis einer Aufgabenanalyse vorliegt, können aus dieser die wichtigsten Aufgaben ermittelt werden. Liegt keine Aufgabenanalyse vor, werden die zu testenden Aufgaben im Gespräch mit Mitarbeitern und Vorgesetzten festgelegt. Es empfiehlt sich, gerade solche Aufgaben zu überprüfen, die entweder von besonders vielen Beschäftigten aufgeführt werden (z. B. Schnellerfassungen von Anwesenheiten), die weitreichende Auswirkungen haben (z. B. buchhalterische Vorgänge), oder die besonders „untypische“ Grenzfälle der Softwarenutzung (z. B. von Mitarbeitern im Außendienst) darstellen.

Reales Aufgabensetting

Die Aufgaben werden den Benutzern, die die Evaluation durchführen, möglichst in Form einer detaillierten Aufgabenbeschreibung vorgelegt. Dabei sollte berücksichtigt werden, ob Aufgaben 219

8 Realisierung innerhalb bestimmter Zeitvorgaben ausgeführt werden sollen. Ist dies der Fall, sollten die Benutzer gleichzeitig testen, ob diese Vorgaben sinnvoll und erfüllbar sind. Zur Vorbereitung der Evaluation gehört auch, dass die Tests auf der Basis von Originalbelegen und -formularen erfolgen, die entsprechend bereitgestellt werden müssen. Auswahl der Benutzer Anzahl der benötigten Benutzer

Die Teilnahme der Benutzer an der Evaluation erfolgt auf freiwilliger Basis. Es sollten Beschäftigte angesprochen werden, die nicht Mitglieder des Projektteams sind und die sich gut mit den zu bearbeitenden Aufgaben und Prozessen auskennen. Von den ausgewählten Prozessen ist abhängig, wie viele Beschäftigte an den Tests teilnehmen. Studien von Virzi (1990, 1992) und Nielsen (1993) belegen, dass 80 % der Usability-Probleme bereits mit fünf Benutzern entdeckt werden können. Da die SAP-Software zum Zeitpunkt der Evaluation der Benutzer auch bereits vom Projektteam getestet worden ist, müssen nicht mehr alle Prozesse von fünf und mehr Beschäftigten überprüft werden. Als Faustregel gilt, dass Aufgaben, die von vielen Beschäftigten durchgeführt werden, von ca. vier bis sechs Benutzern gestestet werden sollten, für andere Aufgaben reichen bereits zwei bis vier Benutzer aus. Einführung der Benutzer Im Zusammenhang mit Tests durch „gewöhnliche“ Benutzer wird oft die Befürchtung geäußert, diese seien nicht in der Lage zu unterscheiden, welche Schwachstellen aus technischen Gründen noch im System sind und an welchen Stellen die Umsetzung der Anforderungen tatsächlich weniger gut gelungen ist. Damit verbunden ist die Sorge, dass „negativem Gerede“ über die neue Software von Seiten der Benutzer, die bereits in Tests einbezogen wurden, Vorschub geleistet werden könnte („hab’ ich doch eh gesagt, das neue System taugt nichts, da bekommen wir mal wieder was vorgesetzt ...“) und dies negative Auswirkungen auf die Akzeptanz der SAP-Software hat.

Akzeptanz der SAP-Software

220

Diese Befürchtungen haben durchaus ihre Berechtigung. Daher ist es wichtig, den Benutzern in der Einführung die Ziele der Evaluation genau darzustellen und die mit den Tests verbundenen Erwartungen anzusprechen. Es muss spätestens zu diesem Zeitpunkt deutlich werden, dass die Tests mit einer noch nicht fertiggestellten Software stattfinden, damit Veränderungsbedarfe

8.2 Evaluation testbarer (Teil-)Prozesse mit Benutzern nicht nur erkannt, sondern auch noch aufgenommen werden können. Die Beschäftigten, die sich noch nicht mit der Handhabung der SAP-Software auskennen, sollten eine Einführung bekommen. Sie sollten sowohl im Systemnavigieren als auch die zu testenden Aufgaben und Prozesse ausführen können. Es empfiehlt sich, diese Benutzer im Rahmen von Testschulungen zu qualifizieren, sofern solche geplant sind. Alternativ müssen die Testteams im Rahmen der Evaluation eine Schulung erhalten, bevor sie die Tests durchführen. Schließlich sollte den beteiligten Beschäftigten ein Überblick über den Ablauf der Tests gegeben werden. Der Koordinator beschreibt dazu die einzelnen Schritte und stellt Instrumente vor, mit denen Schwachstellen systematisch dokumentiert werden können.

8.2.2

Durchführung Die Durchführung der Evaluation erfolgt je nach Menge der zu testenden Prozesse und der Anzahl der beteiligten Benutzer in einer bzw. mehreren Gruppen. Der Zeitplan und die Gruppenzusammensetzung werden in der Regel ebenfalls in der Projektplanung vom Projektteam bestimmt. Im Folgenden wird beschrieben, wie eine Evaluation der (Teil-)Prozesse mit Benutzern durchgeführt werden kann. Ein Beispiel dafür findet sich in Kasten 8.3.

Zwei Benutzer bilden ein Testteam

Jeweils zwei Benutzer bilden ein Testteam: A und B sitzen gemeinsam an der SAP-Software und bearbeiten nacheinander die vorbereiteten Arbeitsaufgaben. Zunächst führt sie Benutzer A durch und denkt dabei laut, d. h., er spricht aus, was ihm bei der Erledigung durch den Kopf geht, z. B. „...jetzt möchte ich drucken ... kann ich das Dokument gar nicht drucken? ... irgendwo muss es doch möglich sein ...“ Benutzer B schreibt mit, welche Probleme er beobachtet. Wichtig ist, dass Benutzer B nicht spricht und auch bei Schwierigkeiten keine Hilfestellung leistet. Jede Aufgabe sollte ungefähr zwei- bis viermal in ähnlicher Form wiederholt werden, um Probleme, die aus der Ungeübtheit mit dem System resultieren, ausschließen zu können. Benutzer B kann bei jedem Durchgang der Arbeitsaufgaben die Auffälligkeiten protokollieren und im Nachhinein die nicht mehr als relevant erscheinenden Schwierigkeiten streichen. Alternativ kann er sich aber auch in den ersten Durchläufen aufs Beobachten beschränken und erst nach mehreren Durchgängen seine Beobachtungen 221

8 Realisierung aufschreiben. Nachdem Benutzer A die Aufgabe mehrmals durchgeführt hat, tauschen beide die Rollen. Nun bearbeitet Benutzer B die Aufgaben, während Benutzer A notiert, was ihm auffällt. Dokumentation der Beobachtungen

Nachdem beide sowohl eine Aufgabe durchgeführt als auch beobachtet haben, dokumentieren sie ihre Beobachtungen in einem Protokollbogen (s. Abschnitt 8.2.3). Hierfür steht ihnen als Hilfsmittel eine Übersicht möglicher software-ergonomischer Problemfelder zur Verfügung, die wir im nächsten Abschnitt näher erläutern. Danach führt einer der beiden die nächste Aufgabe durch.

Weitere Hinweise auf Schwachstellen

Während der Tests sollte ein Mitglied des Projektteams, z. B. der Koordinator, ständig verfügbar sein, um Fragen der Testteams beantworten zu können. Diese Fragen werden ebenfalls dokumentiert, da sie auf Schwachstellen der Software hinweisen können. Darüber hinaus liefern sie möglicherweise Anhaltspunkte für Themen, die in den Schulungen besprochen werden sollten, und für Inhalte der Benutzerdokumentation. Wenn Beschäftigte in einer unruhigen Arbeitsumgebung oder unter hohem Zeitdruck arbeiten, also beispielsweise in einem Empfangsbereich oder im Call-Center, ist es sinnvoll, die Eigenschaften der Arbeitsumgebung bei der Evaluation zu berücksichtigen und die Ausführbarkeit von Aufgaben in einer authentischen Arbeitssituation zu testen. In dieser bestehen besondere ergonomische Anforderungen an die Software, wie z. B. geringe Komplexität, hohe Übersichtlichkeit oder sofortige Verfügbarkeit von Daten, und es besteht die Gefahr, dass bei Tests in einer ruhigen Laborsituation Probleme, die speziell in Verbindung mit der Arbeitsumgebung auftreten, unentdeckt bleiben. Um dem vorzubeugen, sollten wichtige Bestandteile der Umgebung im Testraum simuliert werden. Kasten 8.3: Evaluation von (Teil-)Prozessen mit Benutzern (Praxisbeispiel) Testtag in der Personalabteilung In der Personalabteilung eines metallverarbeitenden Unternehmens wird das neue HR-Modul von vier der zwölf dort arbeitenden Mitarbeiter getestet. Die Mitarbeiter sind im Rahmen eines Change-Management-Projektes vor einem Jahr alle für die gleichen Arbeitsaufgaben qualifiziert worden, damit die Arbeits- und Vertretungsplanung zukünftig erleichtert wird.

222

8.2 Evaluation testbarer (Teil-)Prozesse mit Benutzern Im Rahmen von Testschulungen wurde das Team in der Handhabung der SAP-Software geschult und die Durchführung neuer Aufgaben und Abläufe eingeübt. Die Evaluation der (Teil-)Prozesse wurde für einen Tag angesetzt. Insgesamt wurden sechs Arbeitsaufgaben getestet, und zwar: •

Einstellung von Mitarbeitern;

•

Gehaltsabrechnung;

•

Abwesenheiten anlegen;

•

Eingabe von Prämien und Zulagen;

•

Mehrarbeiten anlegen;

•

Hinterbliebenenbezüge anlegen.

Die Tests fanden in zwei Teams statt. Am Ende des Tages wurden in einer gemeinsamen Sitzung mit den Benutzern, dem Koordinator, den SAP-Beratern und dem Abteilungsleiter 38 gefundene Mängel vorgestellt und Verbesserungsvorschläge besprochen. Einige Beispiele für Mängel, die in der Evaluation identifiziert wurden: •

Beim Anlegen der Abwesenheiten ist kein Feld vorgesehen, in dem der Resturlaub eines Mitarbeiters angezeigt wird. Diese Information muss aus anderen Masken zusammengesucht werden.

•

Bei der Anlage von Hinterbliebenenbezügen wird der Benutzer durch Vorgaben der Software gezwungen, im Infotyp „Sollarbeitszeit anlegen“ Felder auszufüllen, z. B. die Arbeitszeitplanregel, obwohl er vorher deutlich gemacht hat, dass es sich um Hinterbliebenenbezüge handelt.

•

In der Gehaltsabrechnung ist es nicht möglich, eine Lohnund Gehaltsliste genauso in Excel downzuloaden, wie sie in SAP HR erscheint.

•

Beim Anlegen von Mehrarbeiten kommt es zu unverständlichen Fehlermeldungen, die dazu führen, dass die Benutzer den Vorgang abbrechen müssen.

In der gemeinsamen Sitzung wurde bereits deutlich, dass ein Großteil der gefundenen Mängel behebbar war. Einige Verbesserungsvorschläge, deren Umsetzung eine Arbeitserleichterung gebracht hätte, wurden jedoch abgelehnt, da es sich dabei um Modifikationen gehandelt hätte, auf die bei der Einführung aus Kostengründen weitestgehend verzichtet wurde. 223

8 Realisierung

Abbildung 8.1:

8.2.3

Übersicht möglicher software-ergonomischer Problemfelder einer SAP-Software

Dokumentation Um sicherzustellen, dass die Schwachstellen der SAP-Software, die bei der Evaluation von den Benutzern gefunden werden, systematisch an das Projektteam zurückgemeldet werden, soll den Benutzern ein geeignetes Verfahren zur Dokumentation an die Hand gegeben werden. Für die Evaluation von (Teil-)Prozessen erhalten die Benutzer eine Übersicht möglicher software-ergonomischer Problemfelder einer SAP-Software sowie Protokollbögen, in denen sie gefundene Probleme eintragen können. Darüber hinaus steht dem Koordinator eine detaillierte Beschreibung der möglichen software-ergonomischen Problemfelder zur Verfügung.

Übersicht software- Abbildung 8.1 gibt eine Übersicht möglicher software-ergonomischer Problemfelder. Die Übersicht entstand aus einer Sammlung ergonomischer typischer Problemstellen bei bereits eingeführter SAP-Software. Problemfelder Sie dient dazu, Benutzer für die möglichen Mängel, die die SAPSoftware zum Zeitpunkt der Evaluation aufweisen kann, zu sensibilisieren. Die Benutzer erhalten damit ein „Suchraster“, nach dem sie sich bei den Tests richten können. Darüber hinaus wird durch eine solche Übersicht auch eine gemeinsame Verständi224

8.2 Evaluation testbarer (Teil-)Prozesse mit Benutzern gungsbasis für Benutzer, Projektteam und SAP-Customizer geschaffen. Die Übersicht enthält die fünf Kategorien „Fehlendes und Fehlerhaftes“, „Unnötiges“, „Umständliches“, „Unübersichtliches und Unverständliches“ und „Langsam“. Problemfeld „Fehlendes und Fehlerhaftes“: Welche für die Arbeitsaufgabe und die Benutzung nötigen Bestandteile der Software fehlen oder funktionieren nicht richtig? Dies können fehlende oder fehlerhafte Funktionen, fehlende Hilfetexte, nicht vorhandene automatische Berechnungen, fehlende Reports oder nicht vorhandene Eingabefelder sein. Auch Mängel wie beispielsweise fehlende automatische Plausibilitätskontrollen für eingegebene Werte oder fehlende Warnmeldungen bei möglicherweise fehlerhaften Eingaben sind diesem Problemfeld zuzuordnen. Problemfeld „Unnötiges“: Hierzu gehören Mängel wie z. B. Eingabefelder und Masken, die nie benötigt werden und daher immer übersprungen werden müssen, oder unnötig lange Wertehilfelisten. Problemfeld „Umständliches“: Sind z. B. Felder und Buttons so angeordnet, dass ein flüssiger Arbeitsablauf nicht möglich ist? Muss aufgrund der Feldanordnung auf einer Maske im Arbeitsablauf zwischen den Feldern hin und her gesprungen werden? Sind Felder, die für den Arbeitsablauf sinnvollerweise auf einer Maske zusammengefasst wären, auf mehrere Masken verteilt? .... Problemfeld „Unübersichtliches und Unverständliches“: Hierzu gehören beispielsweise aus Benutzersicht unlogisch sortierte Listen (etwa alphabetisch statt chronologisch geordnete Termine) oder unverständliche Benennungen von Eingabefeldern und Buttons. Problemfeld „Langsam“: Wenn die Software bei den Tests bereits „in Echtzeit“ läuft, kann sich herausstellen, dass die Reaktionszeiten der Software zu lang für einen flüssigen Arbeitsablauf sind. Dieses Problemfeld sollte explizit jedoch nur verwendet werden, wenn die Tests bereits an einem System stattfinden, das in der Reaktionszeit dem späteren entspricht. Protokollbogen

Bei der Evaluation sollte jede erkannte Schwachstelle dokumentiert werden. Als Hilfe dafür bietet sich ein vorstrukturierter Protokollbogen an (vgl. Abbildung 8.2). Dieser strukturiert die Rückmeldung von Problemen an das Protokollteam und enthält alle Daten, die zum Nachvollziehen eines Problems benötigt werden. In dieser Eigenschaft kommt er nicht nur in der Phase „Realisie225

8 Realisierung rung“, sondern auch an anderen Stellen zum Einsatz (s. Kapitel 9, 10 und 11). Ob er dabei als Papierformular oder Onlineformular verwendet wird, spielt keine Rolle. Wichtig ist, dass Daten zu einem Problem möglichst aussagekräftig und handlungsleitend erfasst werden. Der Benutzer notiert darin nicht nur, welche Arbeitsaufgabe er durchgeführt, sondern auch, welches konkrete Ziel er dabei verfolgt hat. Oftmals können Außenstehende ein Problem erst dann genau verstehen, wenn klar wird, welche Intention ein Benutzer hatte. Eine präzise Beschreibung der Problemstelle in der Software unter genauer Angabe der Maske ist wichtig, damit das Projektteam bzw. der Customizer nachvollziehen kann, in welcher Maske bzw. bei welcher Transaktion Schwierigkeiten auftraten. Detaillierte Problembeschreibung

Die Beschreibung des Problems sollte so genau wie möglich erfolgen. Wenig hilfreich ist eine Aussage wie: „Ich muss Felder überspringen, die ich nicht benötige“. Stattdessen sollte der Benutzer z. B. schreiben: „Auf der Maske ’Prämien/Sonstige Vergütungen anlegen’ muss ich nach Eingabe der Anzahl Stunden per Tabulatortaste erst die Felder ’Stundenzahl’, ’Anzahl/Einheit’, ’Betrag’ und ’Währung’ überspringen, in die nie etwas eingegeben wird, bevor dann im Feld ’Prämie’ die Prämienart eingegeben werden kann.“ Hilfreich für das Projektteam ist es auch, wenn der Benutzer eine Einschätzung gibt, wie oft dieses Problem bei seiner Arbeit voraussichtlich auftreten wird (z. B. „einmal in der Woche“) und als wie schwerwiegend er dieses bewertet. Hierfür steht ihm eine fünfstufige Skala zur Verfügung (von 0 = „kein Problem für die Software-Ergonomie“ bis 4 = „sehr großes Problem, unbedingt beheben, höchste Priorität“). Schließlich hat der Benutzer auch die Möglichkeit, einen Verbesserungsvorschlag zu machen. Allerdings sollte dieser ebenfalls detailliert formuliert werden, damit das Projektteam nicht raten muss, was der Benutzer sich wünscht. Ein negatives Beispiel wäre: „Nur noch die Eingabefelder anzeigen, die benötigt werden“.

Rückseite für das Projektteam

226

Auf der Rückseite des Protokollbogens befindet sich ein Abschnitt für das Projektteam bzw. den SAP-Customizer (s. Abbildung 8.3). Hier ist einzutragen, wie mit dem Vorschlag des Benutzers verfahren wird („Vorschlag angenommen“, „Vorschlag abgelehnt“ bzw. „alternativer Vorschlag“) und, entsprechend der Antwort, aus welchen Gründen der Verbesserungsvorschlag nicht umgesetzt wird, welche Alternative vorgeschlagen wird und wie

8.2 Evaluation testbarer (Teil-)Prozesse mit Benutzern

Abbildung 8.2:

Protokollbogen (Vorderseite, vom Benutzer auszufüllen)

227

8 Realisierung

Abbildung 8.3:

228

Protokollbogen (Rückseite, vom Projektteam auszufüllen)

8.2 Evaluation testbarer (Teil-)Prozesse mit Benutzern die Umsetzung der Problembehebung aussehen soll. Darüber hinaus wird vermerkt, wer für die Umsetzung verantwortlich ist, wie aufwändig dies ist und bis zu welcher Frist dies geschieht. Mit geringem Aufwand lässt sich so hohe Transparenz über die Prozesse erzielen, die insbesondere in Hinblick der Akzeptanz der SAP-Software durch die Benutzer besonders wichtig ist.

8.2.4

Rückmeldung Die Ergebnisse der Evaluation werden an das Projektteam übermittelt, damit dieses ggf. entsprechende Veränderungen an der Software veranlasst. Auf welche Weise die Rückmeldung erfolgen soll, legt das Projektteam vor Beginn der Evaluation fest. So kann der Koordinator nach der Evaluation mit jedem Testteam besprechen, welche Probleme und Schwierigkeiten bei der Bearbeitung der Aufgaben aufgetreten sind. Insbesondere sollte in diesen Gesprächen auch geklärt werden, ob die ausgefüllten Protokollbögen verständlich sind, ob z. B. deutlich wird, bei welcher Transaktion ein Problem aufgetaucht ist, und ob die Problembeschreibung verständlich ist. Auf einer Projektteamsitzung stellt der Koordinator dann die Ergebnisse der Evaluation vor.

Diskussion der Evaluationsergebnisse

Eine alternative Möglichkeit ist die Rückmeldung im Rahmen eines Workshops mit allen Teilnehmern der Evaluation und dem Projektteam. Ein Vorteil dieser Methode ist, dass die dokumentierten Probleme und Verbesserungsvorschläge besprochen und ggf. ergänzt werden können und die Priorisierung der Bedeutsamkeit der Probleme in der Gruppe vorgenommen werden kann. Allerdings ist dieses Vorgehen auch etwas aufwändiger. Generell empfiehlt es sich, die Ergebnisse der Evaluation an einem zentralen Ort, z. B. einem Ordner im Intranet, bereitzustellen, auf den alle Projektmitglieder sowie die Benutzer, die getestet haben, zugreifen können.

Ableitung von Maßnahmen

Im Projektteam werden die Veränderungsvorschläge diskutiert und Maßnahmen beschlossen. Ob Probleme beseitigt bzw. Verbesserungsvorschläge umgesetzt werden, wird z. B. an Kriterien wie der Bewertung des Problems (Prioritäten) oder am Aufwand für die Umsetzung, gemessen am potenziellen Nutzen, festgemacht. Um die Entscheidungen für oder gegen die Behebung von Problemen bzw. die Umsetzung der Verbesserungsvorschläge transparent zu machen, füllt das Projektteam den zweiten Teil des Protokollbogens „Bewertung durch Projektteam / Customizer“ 229

8 Realisierung aus (Abbildung 8.3). Diese Informationen sollten auch den Benutzern, die getestet haben, zugänglich gemacht werden. Idealerweise werden daher auch sie an einem zentralen Ort bereitgestellt, so dass sich alle Projektbeteiligten jederzeit über die Umsetzung der Evaluationsergebnisse informieren können. Auch wenn es keinen zentralen Ort gibt, an dem die Ergebnisse zusammengeführt werden, so sollte das Projektteam die Benutzer, die an der Evaluation teilgenommen haben, über das weitere Vorgehen informieren. Iteratives Vorgehen

Wenn die Probleme behoben bzw. die Vorschläge umgesetzt sind, kann es sinnvoll sein, einen zweiten Evaluationsdurchgang durchzuführen (vgl. Abbildung 8.4).

Abbildung 8.4:

Iteratives Vorgehen

Welche Prozesse nach einer Veränderung noch einmal von Benutzern gestestet werden sollen, muss nach dem ersten Testdurchgang entschieden werden. Es empfiehlt sich, Kernprozesse, von denen viele Beschäftigte betroffen sind, mehrfach zu testen, wenn diese wesentlich verändert wurden.

8.3

Evaluation integrierter Arbeitsprozesse mit Benutzern Nachdem die SAP-Software in die bestehende Systemlandschaft eingefügt und die technischen Integrationstests durch das Projektteam durchgeführt wurden, werden die integrierten Arbeits-

230

8.3 Evaluation integrierter Arbeitsprozesse mit Benutzern prozesse getestet. Im Unterschied zu den technischen Integrationstests, bei denen gestestet wird, ob die Aufgabenbearbeitung mit Hilfe der SAP-Software funktioniert, wird bei der Evaluation integrierter Prozesse überprüft, ob arbeitsteilige Prozesse, die durch die SAP-Software teilweise oder ganz unterstützt werden, organisatorisch funktionieren. Ziel ist die Überprüfung und Optimierung der organisatorischen Schnittstellen und des Workflows vor dem Go Live. Veränderung der Arbeitsprozesse

Dies ist vor allem deshalb so wichtig, weil sich im Rahmen von SAP-Einführungen Arbeitsprozesse oft grundlegend ändern. Dabei besteht die Gefahr, dass Prozesse zwar gut den Gegebenheiten der Software angepasst werden, die tägliche Arbeit jedoch nicht mehr so reibungslos wie vorher organisiert ist. Hier gilt es ein Gleichgewicht herzustellen in der Abwägung von Vorgaben, die sich aus der Software ergeben, und einer effizienten Arbeitsorganisation.

8.3.1

Vorbereitung Die Evaluation der integrierten Arbeitsprozesse wird in der Regel von den Key-Usern durchgeführt, da diese die neuen und alten Kooperationsbeziehungen und Arbeitsprozesse in den einzelnen Abteilungen sehr gut kennen und gleichzeitig bereits souverän mit der SAP-Software umgehen können. Es ist auch denkbar, darüber hinaus Benutzer, die bereits im Rahmen der Evaluation der (Teil-)Prozesse beteiligt waren, die integrierten Prozesse mittesten zu lassen. Dafür muss allerdings sichergestellt sein, dass diese zum Zeitpunkt der Tests bereits sehr gut mit den ggf. neuen Arbeitsprozessen und der Handhabung der SAP-Software vertraut sind. Auch zur Vorbereitung der Evaluation der integrierten Arbeitsprozesse müssen Ziele definiert, Prozesse ausgewählt und technisch vorbereitet werden. Da die Tests der integrierten Prozesse und Schnittstellen in der Regel mit allen Teilnehmern in einem Raum stattfinden, müssen dort ausreichend SAP-Arbeitsplätze zur Verfügung stehen. Getestet werden komplexe Arbeitsabläufe, daher müssen die Arbeitsaufgaben und Kooperationsbeziehungen der einzelnen Teilnehmer so praxisgetreu wie möglich nachgestellt werden. In der Aufgabenbeschreibung werden die zu überprüfenden Schnittstellenprozesse dargestellt, in einzelne Teilaufgaben zerlegt und den verschiedenen Arbeitsplätzen zugeordnet. Ein Beispiel hierfür findet sich im Kasten 8.4. 231

8 Realisierung Kasten 8.4: Durchführung einer Evaluation integrierter Arbeitsprozesse (Praxisbeispiel) Zusammenarbeit im Verlag In einem Zeitungsverlag sollen mit Einführung von IS MAM Reklamationen von Kunden, die Anzeigen in Auftrag gegeben hatten, auch mit der SAP-Software abgewickelt werden. Da Kundenbindung ein zentrales Anliegen des Verlags ist, wird dieser Prozess gründlich getestet. An der arbeitsteiligen Bearbeitung von Reklamationen sind folgende Organisationseinheiten beteiligt (vgl. Abbildung 8.5): •

das Call-Center;

•

die Buchhaltung (SAP FI);

sowie abhängig von der Reklamationsursache: •

die Anzeigenaufnahme;

•

die Anzeigenproduktion;

und nachgeordnet: •

die Druckerei.

Die Reklamation des Kunden geht im Call-Center ein, und dort werden weitere Bearbeitungsschritte entweder direkt vorgenommen oder veranlasst, sofern sie andere Organisationseinheiten betreffen:

232

•

So wird z. B. die Buchhaltung veranlasst, die Rechnung des Kunden für Bankeinzüge oder Mahnungen zu sperren, bis die Reklamation abschließend bearbeitet ist.

•

Ist der Grund für die Reklamation in der Anzeigenaufnahme zu suchen, ist also die Anzeige beispielsweise in der falschen Rubrik oder zum falschen Zeitpunkt erschienen oder war die Bankverbindung falsch, markiert der Mitarbeiter im Call-Center im Auftrag eine Reklamation und legt dann einen Korrekturauftrag an. Der Korrekturauftrag löst ein Schreiben an den Kunden aus, in dem ihm wahlweise ein kostenloser Neuabdruck der Anzeige angeboten oder eine Gutschrift oder ein Stornobeleg mit neuer Rechnung zugesandt wird. Der Beleg hierfür wird wiederum an die Buchhaltung geschickt und das vorher gesetzte Sperrkennzeichen dort gelöscht.

•

Liegt der Grund für die Reklamation im Bereich der Anzeigenproduktion, war der Text also beispielsweise falsch ge-

8.3 Evaluation integrierter Arbeitsprozesse mit Benutzern staltet oder gab es Farbreklamationen, wird die Kopie des Auftrags mit Reklamationsgrund an die Anzeigenproduktion versendet. Hat der Mitarbeiter in der Anzeigenproduktion Rückfragen zur Reklamation, kann er dem Beleg den Bearbeiter der Reklamation entnehmen. Wenn die Bearbeitung der Reklamation abgeschlossen ist, wird wiederum die Buchhaltung veranlasst, die Sperrung der Rechnung aufzuheben. Alle genannten Organisationseinheiten haben gemeinsam die integrierte Bearbeitung von Reklamationen getestet, um festzustellen, ob die vorgesehene Organisation der arbeitsteiligen Erledigung einen reibungslosen Ablauf ermöglicht. Gestestet wurden Reklamationen unterschiedlicher Ursache und Komplexität, um eine möglichst große Bandbreite integrierter Bearbeitungsvarianten, die im Produktivbetrieb auftreten können, bereits vorab zu überprüfen. Veränderungsbedarf gab es beispielsweise im Hinblick auf die Aufhebung der Rechnungssperre in der Buchhaltung. Die neue Lösung sieht vor, dass jetzt der Sachbearbeiter im Call-Center nach Beendigung des Vorgangs die Sperrung der Rechnung selbst aufhebt. Weiterhin stellte sich heraus, dass für den zuständigen Mitarbeiter in der Anzeigenproduktion die Systemberechtigung fehlte, die ihm gestattete, Reklamationen zur zügigen Bearbeitung innerhalb seiner Abteilung weiterzuleiten.

Abbildung 8.5: Setting für die Evaluation integrierter Teilprozesse bei einem Zeitungsverlag 233

8 Realisierung Mehr oder weniger „nebenbei“ wurde beim Test der integrierten Arbeitsprozesse auch noch ein technisches Problem entdeckt: In einigen Fällen erging an den Kunden automatisch direkt eine Mahnung, weil die Software das falsche Datum (Datum der Auftragserteilung statt Tagesdatum) verwendete. So konnte auch dieser Fehler, ohne dass ein einziger Kunde davon betroffen war, noch vor dem Produktivbetrieb behoben werden.

8.3.2

Durchführung An den Tests nehmen zeitgleich alle Benutzer teil, die einen Teil des entsprechenden Prozesses durchführen. Es empfiehlt sich sogar die Anwesenheit der (Team-)Leiter der betroffenen Organisationseinheiten, da die Ergebnisse der Tests deren Arbeitsorganisation betreffen. Die Evaluation der integrierten Prozesse ist im Gegensatz zum Testen der (Teil-)Prozesse ein kommunikativer Vorgang, bei dem auftretende Schwierigkeiten sofort im Team besprochen und Verbesserungsvorschläge diskutiert werden. Im Unterschied zum Testen der (Teil-)Prozesse sind, wie oben beschrieben, auf jeden Fall Mitglieder des Projektteams (Key-User) in die Tests aktiv eingebunden. Im Anschluss an die Tests wird im Projektteam mit den Leitern der Organisationseinheiten besprochen, ob eine Umsetzung der Vorschläge technisch und organisatorisch machbar und vom Aufwand vertretbar ist.

8.3.3

Rückmeldung Da während der Evaluation nicht alle Projektteammitglieder anwesend sind, sollte im Vorfeld festgelegt werden, wie die Ergebnisse in das Projektteam zurückgespiegelt werden. Eine Möglichkeit ist, dass der Koordinator die Ergebnisse der Evaluation in einer Projektteamsitzung vorstellt. Die aufwändigere Variante wäre die Rückmeldung im Rahmen eines Workshops mit allen Teilnehmern der Evaluation und dem Projektteam. Im Projektteam sollte dann zeitnah über die Behebung evtl. auftretender technischer Probleme entschieden und festgelegt werden, welche Veränderungen auf jeden Fall vor dem Go Live umgesetzt werden müssen, welche aufschiebbar sind und welche nicht unbedingt umgesetzt zu werden brauchen.

234

8.5 Zusammenfassung und Ausblick Bereits im Vorfeld sollte überlegt werden, wie mit organisatorischen Problemen verfahren wird, so dass bei Vorliegen der Ergebnisse das vereinbarte Verfahren angewendet werden kann. Eine zweite Überprüfung nach Umsetzung der Verbesserungsvorschläge ist nicht notwendig, da davon auszugehen ist, dass diese Tests relativ kurz vor Produktivstart stattfinden, so dass abgewartet werden kann, wie sich die veränderten Abläufe in der Phase „Test im Echtbetrieb“ (s. Kapitel 10) bewähren. Diese sollten vor dem offiziellen Abschluss des Projektes noch einmal zum Thema werden.

8.4

Ergonomischer Meilenstein 4

Qualitätssicherung

Der Ergonomische Meilenstein am Ende dieser Phase dient der Überprüfung und Verabschiedung der Umsetzung einzelner (Teil-)Prozesse sowie der integrierten Arbeitsprozesse und Abläufe auf Basis der Testprotokolle und Dokumentation der Verbesserungen. An diesem Punkt wird sichergestellt, dass alle für diese Phase wesentlichen Aktivitäten durchgeführt und alle Entscheidungen getroffen wurden, die für den Produktivstart der SAPSoftware notwendig sind. Sollten nicht alle notwendigen Ergebnisse und Dokumente in der vereinbarten Qualität vorliegen, so wird in der Steuerungsgruppe festgelegt, wann und in welcher Form diese nachgeliefert werden. Eine Übertragung einzelner Aufgaben in die Phase „Go Live“ ist oft eine akzeptable Lösung, um nicht den ganzen Prozess zu verzögern. So ist es z. B. möglich, dass sich Ergebnisse aus den integrierten Tests aufgrund der Nähe zum Produktivstart nicht mehr in vollem Umfang umsetzen lassen oder Sonderentwicklungen oft erst so kurz vor Produktivstart fertiggestellt werden, dass eine Optimierung erst danach möglich ist. Das Ergebnis dieser abschließenden Aktivität ist die Verabschiedung der überprüften und ergonomisch optimierten SAP-Software in einer Meilensteinsitzung des Steuerkreises. Mit dem „Go“ kann das System aus ergonomischer Sicht produktiv geschaltet werden.

8.5

Zusammenfassung und Ausblick Der Erfolg oder Misserfolg von SAP-Software steht und fällt maßgeblich damit, wie gut die Realisierung der in den Phasen „Anforderungsanalyse“ und „Sollkonzept“ entwickelten Anforderungen und Vorgaben gelingt. Wir haben in diesem Kapitel gezeigt, dass es sinnvoll ist, in diesen Prozess Ergonomieexperten und Mitarbeiter einzubinden, die 235

8 Realisierung aus einer anderen Perspektive als der Projektsicht auf die Software schauen. Sie können wertvollen Input für Verbesserungen geben, um einen guten Start nach dem „Go“ zu befördern. Für einen reibungslosen Start ist es jedoch ebenso essenziell, dass alle Beteiligten für die Arbeit im Projekt und später an der Software gut geschult sind. Welche Faktoren hier aus ergonomischer Sicht besonders wichtig sind, erfahren Sie im nächsten Kapitel zum Modul „Schulung“. Stefanie Floegel und Anne Jansen

236

9

Schulung Im vorherigen Kapitel haben Sie erfahren, wie durch die Evaluation von Prozessen mit Benutzern in der Phase „Realisierung“ Probleme und Schwachstellen der SAPSoftware aufgedeckt werden können. In diesem Kapitel geht es um die Aktivitäten, die aus ergonomischer Sicht im Umfeld der SAP-Schulungen erforderlich sind. Das Modul „Schulung“ des Usability Management-Vorgehensmodells hat zwei Zielsetzungen. Zum einen soll sichergestellt werden, dass alle Projektbeteiligten über die ergonomischen Kenntnisse verfügen, die sie benötigen, um ihre im Rahmen des Einführungsprojektes anfallenden Aufgaben im Sinne des Usability Management erledigen zu können. Zum anderen sollen die Voraussetzungen dafür geschaffen werden, dass die Benutzer das in den Schulungen vermittelte Wissen in der Praxis umsetzen und vertiefen können. Als Ergebnis dieses Moduls besitzen die Projektbeteiligten die für sie jeweils erforderlichen software-ergonomischen Kompetenzen, und die Benutzer sind in der Durchführung ihrer Arbeitsaufgaben mit der Software schon vor dem Go Live geübt. Nach der SAP-Einführungsmethodik ist die Planung, Vorbereitung und Realisierung von Schulungen sowohl für die Projektmitarbeiter als auch für die zukünftigen Benutzer der Software vorgesehen. Folgenden Fragen sollte dabei aus ergonomischer Sicht besondere Aufmerksamkeit geschenkt werden: •

Was müssen Projektbeteiligte wissen, um Projektaktivitäten auch unter ergonomischen Gesichtspunkten beurteilen und durchführen zu können?

•

Wie kann sichergestellt werden, dass die Benutzer das in den Schulungen erworbene Wissen so verinnerlichen, dass sie nach Produktivsetzung der Software ihre Arbeitsaufgaben souverän, ohne Angst vor Fehlern und mit größtmöglicher Effizienz erledigen können?

In den Abschnitten des vorliegenden Kapitels stellen wir deshalb die folgenden Bausteine in den Mittelpunkt unserer Betrachtungen: 239

9 Schulung •

Qualifizierung der Projektbeteiligten Um die Notwendigkeit und die Inhalte ergonomischer Projektaktivitäten verstehen, bewerten und ggf. entsprechende Aktivitäten durchführen zu können, müssen alle Projektbeteiligten in Grundlagen der Software-Ergonomie und entsprechender Methodik geschult bzw. sensibilisiert werden.

•

Lernsystem Häufig fehlt es den Benutzern nach den Benutzerschulungen an Übungsmöglichkeiten. Aus diesem Grund sollte ein Lernsystem entwickelt werden, an dem Benutzer sowohl vor als auch nach der Produktivsetzung den Umgang mit der SAPSoftware üben können.

9.1

Qualifizierung der Projektbeteiligten Die SAP-Einführungsmethodik sieht vor, dass das Projektteam zu verschiedenen Zeitpunkten im Einführungsprozess geschult wird. Vorgesehen sind im Einzelnen:

Zusätzliche Qualifizierungsmaßnahmen

•

in der Phase „Projektvorbereitung“ der SAP-Roadmap Überblicksschulungen zu SAP (Level-1-Schulung) und Schulungen zum Organizational Change Management;

•

in der Phase „Business Blueprint“ Überblicksschulungen zu den Referenzprozessen und Funktionen einzelner Module (Level-2-Schulung);

•

in der Phase „Realisierung“ Schulungen zu Detailfunktionen und dem zughörigen Customizing (Level-3-Schulung).

Neben den in diesen Schulungen vorgesehenen Inhalten, bei denen die abbildbaren Geschäftsprozesse und das Customizing im Mittelpunkt stehen, ist es aus ergonomischer Sicht unerlässlich, dass alle Projektbeteiligten auch in den Inhalten des Usability Management-Vorgehensmodells geschult werden. Ziel dieser zusätzlichen Qualifizierungsmaßnahmen – von den Grundlagen der Software-Ergonomie bis zu den Methoden und Vorgehensweisen des Usability Management bei SAP-Projekten – ist es, dass alle Beteiligten des Einführungsprozesses in der Lage sind, im Sinne der im Projekteinstieg definierten Ergonomieziele zu agieren. Um dies zu gewährleisten, sollten bereits zu Beginn eines Einführungsprojektes diese zusätzlichen Qualifizierungsmaßnahmen für das Projektteam sowie für weitere Projektbeteiligte (z. B. Betriebs-/Personalrat, einzubeziehende Benutzer) geplant werden. Dies ist insbesondere deshalb wichtig, weil im

240

9.1 Qualifizierung der Projektbeteiligten Laufe eines Projektes verschiedene Personen mit unterschiedlicher Vorerfahrung und unterschiedlichem Wissen zu verschiedenen Zeiten eingebunden werden. Jede dieser Personengruppen, wie z. B. ausgewählte Key-User oder Benutzer, die an der Anforderungsanalyse oder der Evaluation der Prozesse beteiligt sind, sollte zum rechten Zeitpunkt, also kurz bevor sie dieses Wissen benötigt und aktiv anwenden muss, das erforderliche ergonomische Hintergrundwissen erhalten. Darüber hinaus sollten die in der Einstiegsphase vereinbarten ergonomischen Ziele allen Beteiligten, die nicht von Beginn an in dem Projekt mitarbeiten, vermittelt werden, um sie in die Lage zu versetzen, diese bei ihren Projektaufgaben zu berücksichtigen. Wichtige Themen in diesem Zusammenhang sind: •

Inhalte der Qualifizierung;

•

Zielgruppen der Qualifizierung.

9.1.1

Inhalte der Qualifizierung

Software-Ergonomie als Qualitätskriterium

Grundsätzlich ist es wichtig, allen Projektmitgliedern zu verdeutlichen, dass Software-Ergonomie nicht nur „nice to have“ ist, sondern die Effizienz und Effektivität der Benutzer sowie ihre Zufriedenheit mit der Software entscheidend beeinflusst. Somit stellt Software-Ergonomie ein wesentliches Qualitätskriterium für das Projektergebnis dar. Der Projektleiter, der in der Regel für das Usability Management verantwortlich ist, bestimmt daher sinnvollerweise eine Person, die für die Qualifizierung der Projektbeteiligten verantwortlich ist. Ihre Aufgabe ist es, den Projektbeteiligten deutlich zu machen, dass Software-Ergonomie sich nicht nur auf die Gestaltung der Bildschirmoberfläche beschränkt, sondern dass insbesondere das Design der Geschäftsprozesse, die bessere Unterstützung der Arbeitsaufgaben und der Kooperationsbeziehungen sowie die Qualifikation der Benutzer wichtige Ergonomie-Faktoren darstellen. Vor allem ist es wichtig, diese Grundlagen praxisbezogen in Zusammenhang mit den jeweiligen Aufgaben des Projektteams und den zu Projektbeginn vereinbarten ergonomischen Zielen zu stellen. Im Folgenden werden zunächst die Inhalte, in denen die Projektbeteiligten qualifiziert werden sollten, dargestellt. Anschließend wird ausgeführt, auf welche Inhalte bei den einzelnen Zielgruppen der Schwerpunkt gelegt werden sollte.

241

9 Schulung Grundlagen der Software-Ergonomie Zur Einführung sollten die grundlegenden Begrifflichkeiten der Software-Ergonomie (z. B. Gebrauchstauglichkeit, Nutzungskontext) vorgestellt und die software-ergonomischen Ziele erläutert werden. Es empfiehlt sich, die elementaren Ansatzpunkte software-ergonomischer Maßnahmen anhand leicht verständlicher Beispiele darzustellen. Normen und gesetzliche Regelungen DIN EN ISO 9241

Im Rahmen der Vorstellung von Normen und gesetzlichen Regelungen sollte aufgezeigt werden, aus welchen gesetzlichen Regelungen sich eine Verpflichtung zur Beachtung software-ergonomischer Grundsätze und Normen ergibt. Auch ggf. vorhandene Betriebsvereinbarungen zu diesem Thema sollten vorgestellt und die sich daraus ergebenden Anforderungen für das Einführungsprojekt diskutiert werden. Darüber hinaus gehört in diesen Themenkomplex die Vorstellung der „Ergonomischen Anforderungen für Bürotätigkeiten mit Bildschirmgeräten“ nach DIN EN ISO 9241, und zwar insbesondere Teil 2 „Anforderungen an die Arbeitsaufgaben – Leitsätze“ sowie Teil 110 „Grundsätze der Dialoggestaltung“ und Teil 11 „Anforderungen an die Gebrauchstauglichkeit – Leitsätze“. Es empfiehlt sich, diese an Beispielen aus der SAP-Welt zu diskutieren (vgl. Kapitel 3). Problembeispiele und Lösungen aus der SAP-Praxis Anhand von Beispielen aus der betrieblichen SAP-Praxis soll veranschaulicht werden, wie Schwachstellen in der Software identifiziert und wie Lösungsmöglichkeiten entwickelt werden können. Software-ergonomische Stellschrauben Technische Einstellmöglichkeiten der SAP-Software (z. B. das Ausblenden von Feldern, das Einrichten von Schnellerfassungsmasken) sollten abhängig von der Zielgruppe in unterschiedlichem Umfang behandelt werden. Nutzen von Usability Management Es ist ratsam, den Nutzen von Usability Management bei SAPProjekten zu erläutern. Insbesondere sollten die Vorteile, die aus betriebswirtschaftlicher Sicht für ergonomische Aktivitäten sprechen, aufgezeigt werden. Anhand von Praxisbeispielen lässt sich anschaulich vermitteln, wie Usability Management die Produktivität, die Einführungskosten und die zur Verfügung stehenden betrieblichen Ressourcen positiv beeinflussen kann (vgl. Kapitel 2).

242

9.1 Qualifizierung der Projektbeteiligten Methoden und Vorgehensweisen Es ist nützlich, ausgewählten Projektbeteiligten Methoden und Vorgehensweisen des Usability Management-Vorgehensmodells, wie z. B. die Durchführung einer Anforderungsanalyse oder die Evaluation mit Benutzern, zu erklären und ggf. mit ihnen zu üben (vgl. Kapitel 5 bis 10).

9.1.2

Zielgruppen der Qualifizierung An einem Software-Einführungsprojekt sind in der Regel verschiedene Personengruppen beteiligt. Es ist empfehlenswert, die Schulungen für folgende Zielgruppen durchzuführen: •

Mitglieder des Steuerungskreises;

•

(Teil-)Projektleiter;

•

Mitglieder des Betriebs-/Personalrates;

•

Key-User;

•

Benutzer, die im Projekt beteiligt werden, aber keine KeyUser sind;

•

bisher nicht aufgeführte Mitglieder des Projektteams (z. B. Systemadministratoren, Customizer, Entwickler).

Die Mitglieder dieser Gruppen nehmen unterschiedliche AufgaEinbindung zu unterschiedlichen ben im Projekt wahr. Entsprechend werden sie zu unterschiedlichen Zeitpunkten in den Einführungsprozess eingebunden. DarZeitpunkten über hinaus unterscheiden sie sich unter Umständen erheblich in ihrem Vorwissen und in ihren Schulungsvoraussetzungen. Der für die software-ergonomische Qualifizierung Verantwortliche muss diese Aspekte berücksichtigen, wenn er die Inhalte für die Qualifizierung der Projektmitglieder plant und Gruppen bildet. In Kasten 9.1 wird anhand eines Praxisbeispiels verdeutlicht, für welche Zielgruppe welche Inhalte in der Regel besonders relevant sind. Die Matrix in Abbildung 9.1 kann somit als Anhaltspunkt für Ihre Planungen dienen. Kasten 9.1: Planung software-ergonomischer Qualifizierungsmaßnahmen (Beispiel) Gut geplant ist halb geschult In einem Nahrungsmittelunternehmen wurde zu Beginn des Einführungsprojektes festgelegt, wer wann in welchen software-ergonomischen Inhalten geschult wird. Dazu wurde eine

243

9 Schulung Zielgruppen/Inhaltsmatrix aufgestellt (Abbildung 9.1), die im nachfolgenden Text begründet wird.

Anmerkung: Ü = Überblick, V = Vertiefung

Abbildung 9.1: Inhalte und Zielgruppen software-ergonomischer Qualifizierungsmaßnahmen Mitglieder des Steuerungskreises Im Steuerungskreis werden die Entscheidungen über den Umfang der Usability-Maßnahmen getroffen und die ergonomischen Ziele des Usability Management diskutiert und festgelegt. Im Rahmen der Ergonomischen Meilensteine 1 bis 5 befindet der Steuerungskreis darüber, ob der Projektfortschritt den vereinbarten Ergonomiezielen entspricht oder ob zusätzliche Aktivitäten erforderlich sind. Dabei bilden Kosten-/Nutzenaspekte ergonomischer Maßnahmen und bestehende gesetzliche Verpflichtungen wichtige Entscheidungsgrundlagen. Daher werden den Mitgliedern des Steuerungskreises vertiefte Kenntnisse über die entsprechenden Normen und gesetzlichen Regelungen sowie über den Nutzen des Usability Management vermittelt. Überblicksschulungen über die Methoden und Vorgehensweisen des Usability Management-Vorgehensmodells sollen den Steuerungskreis darin befähigen, den Aufwand einzelner Bausteine abschätzen zu können und, soweit erforderlich, alternative bzw. zusätzliche Aktivitäten zur Zielerreichung festzulegen. Hierfür sollten die Mitglieder des Steuerungskreises auch über einen groben Überblick über software-ergonomische Stellschrauben in SAP verfügen. Wie alle Projektbeteiligten sollten die Mitglieder des Steuerkreises an mindestens einer Überblicksschulung zu den Grundlagen der Software-Ergonomie und zu Problembeispielen und Lösungen aus der betrieblichen SAP-Praxis teilnehmen. 244

9.1 Qualifizierung der Projektbeteiligten Die Qualifizierung für die Mitglieder des Steuerungskreises sollte möglichst vor dem bzw. parallel zum Projektstart erfolgen. (Teil-)Projektleiter Projektleiter und Teilprojektleiter sind dafür verantwortlich, dass die Aktivitäten zum Usability Management in den Einführungsprozess integriert werden. Von ihnen wird erwartet, dass sie die Projektbeteiligten bezüglich ergonomischer Aktivitäten motivieren und unterstützen. Projektleiter und Teilprojektleiter sollen deshalb in allen in Abschnitt 9.1.1 angesprochenen Themenbereichen vertiefend geschult werden. Eine Ausnahme bildet der Themenblock „Normen und gesetzliche Regelungen“, bei dem für diese Zielgruppe ein Überblick ausreicht. Auch die Qualifizierungsmaßnahmen für die (Teil-)Projektleiter sollten möglichst schon zum Projektstart erfolgen. Mitglieder des Betriebs-/Personalrates Bei der Einführung von SAP werden immer auch Beratungsund Mitbestimmungsrechte der betrieblichen Interessenvertretung berührt. Außerdem fungiert der Betriebs-/Personalrat unter Umständen gem. BetrVG als Ansprechpartner bei Streitigkeiten im Verlauf des Projektes. Damit sich der Betriebs-/Personalrat qualifiziert an den Planungen und Entscheidungen des Steuerungskreises beteiligen kann, sollte er zu den gleichen Themenblöcken geschult werden wie die Mitglieder des Steuerkreises, auch wenn nicht alle Mitglieder des Betriebs-/ Personalrates im Steuerungskreis vertreten sind. Eine Ausnahme bildet das Thema software-ergonomische Stellschrauben in SAP, da das Wissen über die technischen Details zur Behebung von Mängeln für die Wahrnehmung der Interessenvertretung nicht unbedingt erforderlich ist. Key-User Key-User sollen unternehmensspezifisches Prozesswissen in das Projekt einbringen, die Passung zwischen den Arbeitsaufgaben in ihrer Organisationseinheit und den in SAP abgebildeten Geschäftsprozessen beurteilen und Qualifizierungs- und Unterstützungsleistungen für die Benutzer erbringen. Daher ist es für Key-User besonders wichtig, den Zusammenhang der Gestaltung von Arbeitsaufgaben und Geschäftsprozessen mit der Software-Ergonomie zu kennen. Key-User sollen deshalb vertiefte Schulungen in den Grundlagen der Software-Ergonomie in Verbindung mit Problembeispielen und Lösungen aus der betrieblichen SAP-Praxis erhalten und insbesondere in den 245

9 Schulung von den Benutzern selbst zu bedienenden software-ergonomischen Stellschrauben, wie z. B. Anlegen von Favoriten in der Menüstruktur oder Anpassen von Spalten in der Anzeige von Tabellen, geschult werden. Werden Key-User bei der Durchführung bestimmter Methoden des Usability Management-Vorgehensmodells beteiligt, so werden sie in den entsprechenden Methoden und Vorgehensweisen, wie z. B. dem Gebrauch des Protokollbogens zur Dokumentation von ergonomischen Mängeln (vgl. Kapitel 8), vertiefend qualifiziert. Benutzer, die nicht Key-User sind Von zentraler Wichtigkeit ist es, im Usability Management-Vorgehensmodell auch Benutzer einzubeziehen, die nicht zu den so genannten Key-Usern gehören. Idealerweise werden Benutzer punktuell in jeder Phase der SAP-Einführung beteiligt – im Rahmen der Anforderungsanalyse ebenso wie bei der Evaluation des Sollkonzeptes und bei den Tests der Teilprozesse. Um sie für ihre Aufgaben zu befähigen, erhalten die ausgewählten Benutzer einen Überblick über die Grundlagen der Software-Ergonomie sowie über Problembeispiele und Lösungen aus der betrieblichen SAP-Praxis. Darüber hinaus werden sie in den benutzerspezifischen Stellschrauben der SAP-Software vertiefend geschult. In die Methoden und Vorgehensweisen, bei denen sie einbezogen werden, werden sie ebenfalls eingeführt. Weitere Mitglieder des Projektteams Zu den weiteren Mitgliedern des Projektteams zählen z. B. Systemadministratoren, Customizer und Entwickler. Die SAPTechniker im Projektteam haben die Aufgabe, die Vorgaben des Sollkonzeptes und die sich in den einzelnen Evaluationsstufen ergebenden Änderungen in der SAP-Software technisch umzusetzen. Damit dies ohne Reibungsverluste erfolgen kann, sollen die Techniker im Projektteam ein Verständnis dafür entwickeln, wie wichtig Gebrauchstauglichkeit im Sinne der DIN EN ISO 9241-11 für die Qualität der Software ist und wie diese hergestellt werden kann. Neben Überblicksschulungen zu den Grundlagen der Software-Ergonomie nehmen sie an vertiefenden Schulungen über die ergonomischen Stellschrauben von SAP und über die Möglichkeiten von Tools, wie z. B. GUI XT, GUI XT Designer, Input Assistant oder Tools zur Erstellung von Online-Hilfen, teil. Alle Zielgruppen sollten in einem Überblick den Nutzen des Usability Management vermittelt bekommen, um Projektaktivitäten entsprechend bewerten zu können. 246

9.2 Lernsystem

9.2

Lernsystem

Möglichkeit zum Üben

Nur wenn die Benutzer die SAP-Software verstehen und sicher beherrschen, sind sie fähig, nach der Einführung effektiv und effizient damit zu arbeiten. Um dies zu erreichen, sollten sie die Möglichkeit haben, das in den SAP-Schulungen erworbene Wissen vorm Produktivstart der Software ausreichend zu üben. Viele Unternehmen jedoch geben den Benutzern hierzu – außer den wenigen Stunden im Rahmen der Schulung – keine Gelegenheit, so dass sie nach dem Produktivstart relativ unvermittelt unter „realen Arbeitsbedingungen“ mit der Software konfrontiert werden. Häufig liegt dann auch der Zeitpunkt der SAP-Schulung bereits eine Weile zurück, und die Benutzer können sich nur noch schwer an die vermittelten Inhalte erinnern. Daher ist es aus ergonomischer Sicht geboten, den Benutzern ein Lernsystem zur Verfügung zu stellen, an dem sie das Gelernte vertiefen und ihre Arbeitsabläufe mit der SAP-Software bis zum Go Live – und ggf. noch darüber hinaus – einüben können. Wir verstehen unter einem solchen Lernsystem die weitgehend fertig gestellte SAP-Software, die den Benutzern zum Zweck der systematischen Vertiefung von Wissen zur Verfügung gestellt wird. Ein zentraler Erfolgsfaktor ist dabei die Betreuung der Benutzer bei ihrer Arbeit am Lernsystem. Neben der technischen Realisierung des Lernsystems kommt der Gestaltung von Lernaufgaben und der systematischen Erfassung von Schwierigkeiten bei deren Bearbeitung eine besondere Bedeutung zu. Darüber hinaus kann das Lernsystem auch zu weiteren Benutzertests herangezogen werden, indem noch bestehende ergonomische Mängel der SAP-Software, die bei der Durchführung der Übungsaufgaben von den Benutzern entdeckt werden, an das Projektteam zurückgemeldet werden. In diesem Rahmen kann auch getestet werden, wie gut die Unterstützung der Benutzer bei Problemen funktioniert (s. hierzu Abschnitt 9.2.4). Schließlich kann das Lernsystem auch noch nach Produktivsetzung sinnvoll genutzt werden: So können die Beschäftigten am Lernsystem ihre neu erworbenen Kenntnisse ausprobieren und z. B. Aufgaben durchführen, bei denen sie sich noch unsicher fühlen, ohne befürchten zu müssen, irgendwelche Fehler im System zu verursachen. Bei der Implementierung eines solchen Lernsystems sollten folgende Aspekte beachtet werden: 247

9 Schulung •

Technische Ausgestaltung des Lernsystems;

•

Lernaufgaben;

•

Rahmenbedingungen;

•

Zusätzlicher Nutzen des Lernsystems.

Diese Aspekte werden in den folgenden Abschnitten näher erläutert.

9.2.1

Technische Ausgestaltung des Lernsystems Im Projektteam muss geklärt werden, wie das Lernsystem technisch realisiert wird. Im besten Fall wird die bereits evaluierte und optimierte SAP-Software als Lernsystem verwendet. Falls dies nicht möglich ist, sollte sie in einer möglichst weit fertig gestellten Version als Lernsystem eingesetzt werden. Das Projektteam sollte rechtzeitig entscheiden, in welchem Stadium sie den Benutzern als Lernsystem zur Verfügung gestellt wird.

Abbildung der Realität

Damit das Lernsystem einen möglichst hohen Übungseffekt erzielt, sollte der spätere Nutzungskontext so genau wie möglich abgebildet werden. Dazu sind verschiedene Anforderungen zu berücksichtigen: •

Aktueller Bezug der Stammdaten und Bewegungsdaten;

•

Oberfläche und Funktionen entsprechen den vorgesehenen Ausprägungen in der SAP-Software nach dem Produktivstart;

•

Berechtigungen sind so eingerichtet, dass auf alle erforderlichen Funktionen und Daten zugegriffen werden kann.

Je nach Projektverlauf lassen sich diese Forderungen unterschiedlich gut erfüllen. Dies liegt in der Regel daran, dass das Lernsystem schon vor der Produktivsetzung benötigt wird, zu diesem Zeitpunkt jedoch noch nicht alle Aspekte vollständig umgesetzt sind. Das Projektteam sollte daher genau abwägen, mit welchen Beschränkungen das Lernsystem den Benutzern zur Verfügung gestellt wird. Wichtig ist, dass die Benutzer die meisten der von ihnen benötigten Funktionen im Lernsystem erproben und reale Übungsaufgaben bearbeiten können. Beschränkungen wie z. B. verlangsamte Systemzeiten können dagegen relativ gut kompensiert werden. Im Projektteam muss gemeinsam festgelegt werden, welche Muss- und welche Kann-Anforderungen an das Lernsystem zu stellen sind, da der Zeitpunkt des Einsatzes auch mit den SAPSchulungen harmonisiert werden sollte. Falls nicht alle Anforde248

9.2 Lernsystem rungen im Lernsystem realisiert werden konnten, müssen diese Beschränkungen den Benutzern unbedingt mitgeteilt werden. Anderenfalls ist der Erfolg des Einführungsprojektes gefährdet, denn vermeintliche Schwächen der SAP-Software können sich negativ auf die Akzeptanz durch die Benutzer auswirken (vgl. auch Kapitel 8).

9.2.2

Lernaufgaben Um das Üben am Lernsystem zu erleichtern, ist es notwendig, den Benutzern Lernaufgaben zu stellen, die ihren späteren Aufgaben mit der Software entsprechen. Diese Lernaufgaben müssen im Vorfeld entworfen und auf das Lernsystem abgestimmt werden. Dabei sind folgende Empfehlungen zu berücksichtigen: Lernaufgaben •

entsprechen real anfallenden Arbeitsaufgaben;

•

sind auf einzelne Benutzer/Benutzergruppen abgestimmt;

•

beinhalten sowohl Standard-/Routineaufgaben als auch Aufgaben, die selten anfallen;

•

bestehen aus einfachen und komplexen Aufgaben;

•

berücksichtigen auch den Umgang mit Fehlern;

•

beziehen reale Informationen (Formulare etc.) mit ein;

•

weisen eine realistische Zeitvorgabe auf;

•

werden unter möglichst realen Bedingungen durchgeführt.

Die Lernaufgaben, die einzelne Benutzergruppen erhalten, sollten sich eng an ihren tatsächlichen Arbeitsaufgaben orientieren und jeweils entsprechend auf sie zugeschnitten sein. Im besten Falle berücksichtigen die Lernaufgaben ihr Wissen, ihre Erfahrung und ihre Fertigkeiten und bilden ihre späteren Arbeitsaufgaben realistisch ab. Falls im Rahmen des Einführungsprojektes eine Anforderungsanalyse durchgeführt wurde, lassen sich aus den Ergebnissen in der Regel Lernaufgaben generieren. Falls kein entsprechendes Material vorliegt, können die Aufgaben im Gespräch mit Vorgesetzten und Benutzern entwickelt werden. Außerdem sollten nicht nur Standard- und Routineaufgaben, sondern auch selten anfallende Aufgaben und Ausnahmefälle geübt werden. Natürlich legt auch hier das Projektteam im Vorfeld fest, welche Ziele mit den Lernaufgaben verfolgt werden, und entwickelt entsprechende Aufgaben. In jedem Fall ist es notwendig, eine gute Mischung zu finden zwischen einfachen Aufgaben, die 249

9 Schulung den Benutzern erlauben, Gelerntes zu trainieren, und komplexen Aufgaben, die es erfordern, erworbenes Wissen zu kombinieren. Des Weiteren ist es sinnvoll, die Lernaufgaben so zu gestalten, dass Benutzer den Umgang mit Fehlern üben können. Wie verschiedene Untersuchungen der Arbeitspsychologen Frese, Irmer & Prümper (1991) zeigen, entlastet es einen Benutzer ungemein, wenn er weiß, wie er mit Fehlern umgehen kann, und sich nicht mehr davor zu fürchten braucht, Fehler zu machen. Am Lernsystem können Benutzer gefahrlos ausprobieren, was passiert, wenn sie sich z. B. in Mengenangaben vertippen oder einen Auftrag plötzlich abbrechen. Schließlich empfehlen wir, als Material für die Lernaufgaben unbedingt tatsächlich vorkommende Arbeitsunterlagen (Formulare, Informationsdokumente etc.) zu verwenden. Zum einen erhöht dies die Realitätsnähe der Lernaufgaben, zum anderen treten so eher Schwierigkeiten zu Tage, die durch eine mangelnde Passung von Material und SAP-Software verursacht werden. Beispielsweise ist bei dem Formular für eine Auftragsbestätigung ein Kommentarfeld vorhanden, doch die dort notierte Information lässt sich in der Software nicht eintragen, weil hierfür kein entsprechendes Feld vorgesehen ist. Es ist ratsam, bereits bei den Lernaufgaben realistische Zeitvorgaben zu machen, damit die Benutzer feststellen können, wo sie an Grenzen stoßen und wo noch Training erforderlich ist. Dies setzt natürlich voraus, dass die Systemantwortzeiten denen in der späteren SAP-Software nach dem Go Live entsprechen. Zeitdruck kann z. B. induziert werden, indem ein Benutzer eine bestimmte Anzahl von Aufgaben in einer bestimmten Zeit erledigen muss.

9.2.3

Rahmenbedingungen Die Rahmenbedingungen beeinflussen entscheidend den Nutzen des Lernsystems im SAP-Einführungsprojekt. Entscheidend sind die folgenden Aspekte: •

Wartung und Pflege;

•

Übungsort und -zeit;

•

Freistellung, Einführung und Betreuung der Benutzer.

Diese werden im Folgenden genauer erläutert.

250

9.2 Lernsystem Wartung und Pflege Aktualisierung des Lernsystems

Das Lernsystem muss nicht nur erstellt, sondern auch gepflegt und aktualisiert werden. Dazu gehört, dass die technischen Anforderungen an das System (vgl. Kapitel 9.2.1) überprüft werden und das System bei Neuerungen bzw. Veränderungen ggf. aktualisiert wird. Es empfiehlt sich, eine Person aus dem Projektteam zu bestimmen, die das Lernsystem betreut und in einem funktionsfähigen Zustand hält. Übungsort und -zeit

Installation des Lernsystems

Des Weiteren muss organisiert werden, wie und wann die Beschäftigten die Möglichkeit haben, an dem System zu üben. Dies lässt sich auf verschiedene Weisen realisieren. So kann das Lernsystem an den einzelnen Arbeitsplätzen zugänglich gemacht werden, so dass die Benutzer während ihrer Arbeitszeit an dem Lernsystem üben können. Ist eine Installation des Lernsystems an den einzelnen Arbeitsplätzen nicht realisierbar und sitzen die Benutzer zusammen an einem Ort, empfiehlt sich die Einrichtung eines gesonderten Übungsraums, in dem die Beschäftigten zunächst in Ruhe, ohne vom Alltagsgeschäft gestört und abgelenkt zu werden, Übungsaufgaben durchführen können. Abhängig von der Anzahl der Übungsplätze kann jeweils nur eine bestimmte Anzahl von Personen gleichzeitig am Lernsystem arbeiten. Daher sollte jemand aus dem Projektteam, z. B. die Person, die das Lernsystem betreut, einen Zeitplan mit Übungszeiten aufstellen. Freistellung, Einführung und Betreuung der Benutzer Damit das Lernsystem von den Beschäftigten angenommen wird, sollten sie während ihrer Arbeitszeit für Übungszeiten freigestellt werden. Dies sollte im ganzen Unternehmen akzeptiert sein und von den Vorgesetzten unterstützt werden. Andernfalls ist zu befürchten, dass die Beschäftigten aus Angst vor einem schlechten Ruf „...ist ja klar, dass Herr Bornemann mit dem System übt ... der hat es ja nötig ... der hat ja nicht genug zu tun ...“ nicht auf das Lernangebot eingehen. Kasten 9.2 beschreibt beispielhaft, wie Übungen am Lernsystem in einem Unternehmen realisiert wurden. Zuletzt ist es nötig, dass die Beschäftigten systematisch in das Lernsystem eingeführt werden. Sinnvollerweise geschieht dies bereits im Rahmen der Benutzerschulungen. In der Einführung sollte den Beschäftigten vermittelt werden, wie sie am besten mit dem System üben und welche Lernaufgaben für sie am besten geeignet sind. Außerdem sollten die Chancen des Lernsystems 251

9 Schulung herausgestellt werden, wie z. B. eine reduzierte Arbeitsbelastung beim Go Live, da die Beschäftigten die wesentlichen Arbeitsaufgaben mit der SAP-Software zu diesem Zeitpunkt dank ihrer Übung bereits beherrschen. Zur Einführung gehört auch, dass die Beschäftigten ggf. auf die Beschränkungen hingewiesen werden, die das Lernsystem aus bestimmten Gründen noch aufweist. Wie bereits angesprochen, besteht ansonsten die Gefahr, dass Gerüchte über eine vermeintlich „schlechtes“ Software die Akzeptanz durch die Beschäftigten beeinträchtigen. Kasten 9.2: Einführung eines Lernsystems bei einem Energieunternehmen Eine „Übungsnische“ für Benutzer In einem Unternehmen der holzverarbeitenden Industrie wurde das Modul HR eingeführt. Aus früheren Projekten war bekannt, dass sich Benutzer in der ersten Zeit des Produktivbetriebes äußerst unterschiedliche Routinen – effiziente und weniger effiziente – aneignen. Damit die Benutzer gegenseitig von ihren mit der Software gemachten Erfahrungen profitieren können, wurden in einem Besprechungsraum der Personalabteilung mehrere Bildschirmarbeitsplätze eingerichtet, von denen aus auf eine Kopie des Qualitätssicherungssystems zugegriffen werden konnte. Zu festgelegten Zeiten standen hier ein Key-User und der modulverantwortliche Systemadministrator als Ansprechpartner zur Verfügung. Die Benutzer waren aufgefordert, diese so genannte „Übungsnische“ zum betreuten Erfahrungsaustausch mit anderen Benutzern zu nutzen. Besonders effiziente Vorgehensweisen, Fehlerquellen und deren Behebung etc. wurden von den Betreuern gesammelt und auf den monatlich stattfindenden Abteilungstreffen allen Benutzern präsentiert. Der Kommentar des HR-Abteilungsleiters: „Zuerst stand ich der Idee äußerst skeptisch gegenüber. Im Nachhinein muss ich sagen, dass die Übungsnischen erheblich zur Akzeptanz der neuen Software und zur Effizienzverbesserung unserer Arbeit beigetragen haben.“ Nicht zuletzt sollte vom Projektteam auch sichergestellt werden, dass die Beschäftigten einen Ansprechpartner haben, an den sie sich wenden können, wenn Probleme beim Arbeiten mit dem Lernsystem auftauchen. Nur so kann effektives Lernen der neuen Arbeitsaufgaben und Prozesse bei den Benutzern erreicht werden.

252

9.2 Lernsystem

9.2.4

Zusätzlicher Nutzen des Lernsystems

Weniger Verluste durch Umstellungsschwierigkeiten

Der Aufbau eines Lernsystems geht mit einem gewissen Aufwand einher. In der Regel steht dem Aufwand jedoch ein weitaus größerer Nutzen gegenüber, da die Beschäftigten besser auf das Go Live vorbereitet sind, die Umstellung dadurch reibungsloser erfolgt und weniger Verluste durch Umstellungsschwierigkeiten entstehen. Wird in einem Unternehmen im Rahmen der SAP-Einführung ein Lernsystem installiert, hat dies neben der Qualifizierung der Benutzer noch zwei weitere positive Effekte: •

Evaluation der SAP-Software;

•

Wirkungskontrolle der Benutzerschulungen.

Diese werden im Folgenden näher erläutert. Evaluation der SAP-Software Anhand der Übungsaufgaben, die die Beschäftigten am Lernsystem durchführen, lassen sich eventuelle Schwächen der SAP-Software aufdecken. Besonders interessant sind dabei die Prozesse, die bisher noch nicht mit Benutzern evaluiert worden sind. Finden die Benutzer hier noch gravierende Probleme, besteht noch die Möglichkeit, diese im Projektteam vor dem Go Live zu lösen. Weiterhin können über die Arbeit am Lernsystem Supportdokumente wie z. B. Benutzerhandbücher auf ihren praktischen Nutzen hin überprüft werden. Mögliche softwareergonomischer Problemfelder

Die Evaluation ist mit geringem Aufwand möglich. Den Beschäftigten, die mit dem Lernsystem arbeiten, muss lediglich ein Instrument an die Hand gegeben werden, das sie dabei unterstützt, gefundene Mängel und Verbesserungsvorschläge systematisch zu dokumentieren. Es empfiehlt sich, die Beschäftigten z. B. im Rahmen der Einführung in das Lernsystem auch mit dem Gebrauch der Übersicht möglicher software-ergonomischer Problemfelder von SAP-Software und mit den Protokollbögen (vgl. Kapitel 8.2.3) vertraut zu machen. Wie in Kapitel 8 bereits ausführlich dargestellt, tragen die Beschäftigten in den Protokollbogen ein, bei welcher Lernaufgabe sie auf ein Problem stoßen, beschreiben dieses detailliert, nennen die betreffende Maske bzw. Transaktion und geben an, für wie schwerwiegend sie das Problem halten. Die Person, die den Beschäftigten als Ansprechpartner für Fragen rund um das Lernsystem zur Verfügung steht, ist sinnvollerweise auch dafür ver253

9 Schulung antwortlich, die ausgefüllten Protokollbögen einzusammeln und die Ergebnisse im Projektteam und mit den Customizing-Verantwortlichen zu besprechen. Auch hier sei noch einmal betont, wie wichtig es ist, den Benutzern die Entscheidungen des Projektteams zur Beseitigung von Mängeln mitzuteilen und sie so an dem Verbesserungsprozess zu beteiligen. Dies hat einen maßgeblichen Einfluss darauf, wie sie die SAP-Software später annehmen. Zusätzlich kann auch eine Evaluation der Supportdokumente im Evaluation der Supportdokumente Rahmen der Übungen am Lernsystem erfolgen. Hierfür ist nur erforderlich, dass die Beschäftigten in den SAP-Schulungen bereits im Umgang mit den Hilfsmitteln bekannt gemacht wurden. Während die Benutzer Übungsaufgaben am Lernsystem durchführen, sollte ihnen bereits eine vorläufige Version der späteren Supportdokumente bzw. sonstiger Hilfen zur Verfügung stehen, damit sie diese bei Fragen und Problemen zunächst einmal zu Rate zu ziehen können. Auch hier können die Beschäftigten mit Hilfe von Protokollbögen dokumentieren, welche Schwierigkeiten sie mit den Hilfen haben. So kann z. B. ein Stichwort, unter dem eine Information erwartet wird, irreführend sein oder fehlen, Erläuterungen können als unverständlich empfunden werden oder für bestimmte Benutzergruppen unbrauchbar sein. Diese und andere Mängel dokumentieren die Benutzer in einem Protokollbogen ähnlich dem, der bei der Evaluation der Prozesse zum Einsatz kommt (vgl. Kapitel 8), und übermitteln diesen über das verantwortliche Mitglied an das Projektteam. Natürlich ist auch hier wichtig, dass die Beschäftigten die Supportdokumente explizit als „vorläufige“ und keinesfalls als „Endversion“ ausgehändigt bekommen. Außerdem sollte auch hierbei die Transparenz der Prozesse gewahrt bleiben und sollten die Benutzer informiert werden, was mit ihren ausgefüllten Protokollbögen geschieht. Wirkungskontrolle der Benutzerschulungen Neben der Evaluation der SAP-Software und der Supportdokumente kann mit dem Lernsystem noch einem weiteren Aspekt Rechnung getragen werden: der Wirkungskontrolle der SAPSchulungen. Qualifizierungsplanung und Support

254

Häufig wird im Anschluss an die SAP-Schulungen ein Beurteilungsbogen verteilt, in dem die Teilnehmer ihre Seminarbewertung abgeben sollen. Dies dient u. a. dazu, ihren Wissenstand zu ermitteln, um Hinweise für die weitere Qualifizierungsplanung und den Support zu erhalten.

9.2 Lernsystem

Abbildung 9.2:

Fragebogen zur Wirkungskontrolle von SAPSchulungen (Ausschnitt)

Eine Wirkungskontrolle im direkten Anschluss an ein Seminar hat jedoch den Nachteil, dass die Beschäftigten ihre SAP-Kenntnisse meist noch gar nicht beurteilen können. Fehlendes Wissen und ungenügende Kenntnisse werden ihnen häufig erst bei der 255

9 Schulung Erledigung von Arbeitsaufgaben mit der SAP-Software nach dem Go Live bewusst. Haben die Beschäftigten jedoch die Gelegenheit, Übungsaufgaben, die ihren späteren realen Arbeitsaufgaben mit der SAP-Software entsprechen, schon vor dem Go Live am Lernsystem durchzuführen, so können sie nach einem gewissen Übungszeitraum eine genauere Einschätzung ihrer (Un-)Kenntnisse geben. Mit Hilfe des in Abbildung 9.2 dargestellten Fragebogens können u. a. Qualifizierungsdefizite der Benutzer systematisch gesammelt und zur Wirkungskontrolle der Schulungen herangezogen werden. So erfasst der Fragebogen z. B., ob der betreffende Benutzer in der SAP-Software navigieren und mit den Grundbegriffen umgehen kann und ob er die für seine Aufgaben notwendigen Schnittstellensysteme bedienen kann. Darüber hinaus können mit dem Fragebogen die Themen erhoben werden, zu denen sich der Benutzer noch eine Vertiefung bzw. Ergänzung wünscht. Die Auswertung dieses Fragebogens gibt wertvolle Hinweise für die weitere Qualifizierungsplanung und den Support.

9.3

Zusammenfassung und Ausblick In diesem Kapitel haben wir dargestellt, wie die Projektbeteiligten mit speziellen Qualifizierungsmaßnahmen auf ihre Aufgaben im Rahmen des Usability Management vorbereitet werden können. Diese Qualifizierungsmaßnahmen tragen nicht nur zum Gelingen der Usability-Maßnahmen bei, sie schaffen zudem eine Grundlage für die Implementierung eines Kontinuierlichen Verbesserungsprozesses nach Produktivsetzung der SAP-Software (vgl. Kapitel 10). Des Weiteren haben Sie erfahren, wie ein Lernsystem die Beschäftigten bei der Umstellung auf die SAP-Software unterstützen kann und worauf bei der Implementierung eines Lernsystems geachtet werden muss. Im nächsten Kapitel erfahren Sie, welche ergonomischen Aktivitäten nach Produktivsetzung in der Phase „Go Live & Optimierung“ anstehen. Anne Jansen und Bernd Stein

256

10

Go Live & Optimierung In den beiden vorigen Kapiteln haben Sie erfahren, wie mittels der Evaluation von Prototypen mit Benutzern und einem konsequent umgesetzten Übungskonzept die Software und die Benutzer auf den Produktivbetrieb vorbereitet werden können. In diesem Kapitel beschäftigen wir uns mit den abschließenden Projektaktivitäten nach Produktivsetzung der SAP-Software. In der Phase „Go Live & Optimierung“ bietet sich Ihnen die Möglichkeit, ergonomische Mängel, die in den vorangegangenen Phasen „Sollkonzeption“ und „Realisierung“ nicht ermittelt werden konnten, systematisch mit Hilfe der Benutzer zu ermitteln, daraus weitere Maßnahmen zur Optimierung der Software abzuleiten und die organisatorischen Voraussetzungen für einen Prozess der kontinuierlichen Systemoptimierung zu schaffen. Dabei können auch die Abläufe und Aufgaben einbezogen werden, die bisher beim Usability Management nicht betrachtet wurden. Darüber hinaus werden die in der Phase „Projekteinstieg“ vereinbarten ergonomischen Projektziele überprüft. Die Phase „Go Live & Optimierung“ nach dem Modell des Usability Management teilt sich in drei Bausteine: •

Test im Echtbetrieb und Optimierung „Test im Echtbetrieb und Optimierung“ heißt der Baustein zwischen „Go Live“ und „Projektabschluss“. Er dient dazu, allen Benutzern die Gelegenheit zu geben, Störungen und Fehler bei der Arbeit mit der Software systematisch zu ermitteln und mit Verbesserungsvorschlägen an das Projekt zu melden. Der Zyklus der Ermittlung von Störungen und Fehlern und der daraus resultierenden Optimierung der Software wird dabei gegebenenfalls mehrfach durchlaufen.

•

Kontinuierlicher Verbesserungsprozess (KVP) Mit der Organisation eines Kontinuierlichen Verbesserungsprozesses (KVP) werden die organisatorischen Rahmenbedingungen geschaffen, die es erlauben, auch nach Abschluss 259

10 Go Live & Optimierung des Einführungsprojektes Anforderungen und Verbesserungsvorschläge zu erheben und umzusetzen. •

Ergonomischer Meilenstein 5 Im Ergonomischen Meilenstein 5 wird nicht nur überprüft, ob das Projekt alle Aufgaben der Phase „Go Live & Optimierung“ erfüllt hat, sondern auch festgestellt, ob die im Projekteinstieg vereinbarten ergonomischen Ziele in einem zufriedenstellenden Ausmaß erreicht wurden. Abhängig vom Grad der Zielerreichung und den Ergebnissen des Bausteins „Test im Echtbetrieb und Optimierung“ ist dann festzulegen, welche ergonomischen Aktivitäten in den Kontinuierlichen Verbesserungsprozess übertragen werden sollen. Im Meilenstein 5 wird das Projekt schließlich offiziell abgeschlossen und das Projektteam entlastet.

Der Ablauf dieser drei Bausteine und die damit verbundenen Aktivitäten werden im Folgenden erläutert.

Abbildung 10.1: Ablauf der Phase „Go Live & Optimierung“

10.1

Test im Echtbetrieb und Optimierung

Belastungen nach Meistens werden in der ersten Zeit des Produktivbetriebes sowohl an die Benutzer als auch an die Projektmitarbeiter hohe Produktivstart Anforderungen gestellt. Die Alltagsarbeit ist in dieser Zeit geprägt durch neue Belastungen:

260

•

Systemtechnische Probleme (z. B. hohe Antwortzeiten, System-Abstürze) sind aufzufangen.

•

Die jeweilige persönliche Arbeitsorganisation und Arbeitsweise muss umgestellt werden.

10.1 Test im Echtbetrieb und Optimierung

Testphase

•

Routine im Umgang mit den SAP-Funktionen muss entwickelt werden.

•

Fehler müssen erkannt und behoben werden.

•

Die Benutzer müssen mit eventuellen software-ergonomischen Defiziten wie fehlenden Reports, unübersichtlichen Listen etc. zurechtkommen.

Damit in dieser Zeit nicht die Chance versäumt wird, viele wichtige Verbesserungsmöglichkeiten, Wünsche und Vorschläge der Benutzer zu erheben und umzusetzen, empfiehlt sich die Vereinbarung einer mehrmonatigen Testphase im Anschluss an die Produktivsetzung. Wir empfehlen eine Dauer von ca. sechs Monaten. In dieser Zeit gilt es, systematisch zu überprüfen, ob die Software aus Benutzersicht effektiv, effizient und zufriedenstellend läuft und ob der zur Verfügung stehende Support die Benutzer wirklich unterstützt. Überprüft werden sollte z. B., ob die Benutzer mit der SAP-Software, der zugehörigen Benutzerdokumentation und den entsprechenden Schulungsunterlagen zurechtkommen und ob die Qualifizierungsmaßnahmen ausreichend waren (Blume, 1999). Die Entscheidung, eine solche Testphase durchzuführen, bedeutet entsprechend, dass das SAP-Projekt noch nicht beendet ist. Erst nach Abschluss des Bausteins „Test im Echtbetrieb und Optimierung“ ist das Projekt offiziell beendet, und das Projektteam wird aufgelöst.

Koordinationsund Betreuungsteam

Wichtigste Grundvoraussetzung für gute Resultate aus dieser Phase ist, dass eine kontinuierliche Betreuung der Benutzer bei ihrer Arbeit mit der Software gewährleistet ist. Hierzu sollte aus Mitgliedern des Projektteams ein Koordinations- und Betreuungsteam gebildet werden, an das sich die Benutzer mit allen Fragen zu einzelnen SAP-Anwendungen wenden können. Dabei ist es besonders wichtig, ausreichend Zeit- und Personalressourcen für die dadurch anfallenden Tätigkeiten einzuplanen. Mitglieder des Koordinations- und Betreuungsteams sollten •

die technischen Stellschrauben der SAP-Software kennen und vermitteln können,

•

über software-ergonomisches Grundwissen verfügen,

•

die organisatorischen Abläufe kennen und Änderungswünsche entsprechend einordnen können und

261

10 Go Live & Optimierung •

in der Lage sein, einen offenen und konstruktiven Dialog mit den Benutzern zu führen.

In den Überprüfungsprozess sollten neben den unmittelbar von SAP unterstützten Arbeiten und Abläufen auch alle anderen Tätigkeiten der Beschäftigten sowie die mittelbar angestoßenen Prozesse und Tätigkeiten einbezogen werden. Vorgehensschritte

10.1.1

Der Baustein „Test im Echtbetrieb und Optimierung“ beinhaltet folgende Schritte: •

Information der SAP-Benutzer über Ziele und Ablauf der Testphase;

•

Erhebung Mängel;

•

Optimierung der Software.

software-ergonomischer

und

organisatorischer

Information der SAP-Benutzer und Einweisung in die Testphase Es ist sinnvoll, ca. zwei Wochen nach dem Go Live eine Informationsveranstaltung mit Benutzern, dem Leiter der Organisationseinheit und dem Technikteam durchzuführen. Dort informiert der Projektleiter die Beteiligten über die Ziele und den Ablauf der Testphase.

Themen der Informationsveranstaltung

10.1.2

Themen der Informationsveranstaltung sollten sein: •

Vorstellung der ergonomischen Projektziele;

•

Rückblick: ergonomische Aktivitäten während des Einführungsprozesses;

•

Ablauf des Bausteins „Test im Echtbetrieb“ und organisatorische Fragen;

•

Funktion und Verwendung der Protokollbögen.

Erhebung software-ergonomischer Mängel und Optimierung der Software Alle Benutzer der SAP-Software dokumentieren Auffälligkeiten und Probleme, die sie bei der Arbeit behindern, in den Protokollbögen, die auch bei der Evaluation testbarer (Teil-)Prozesse eingesetzt werden (s. Kapitel 8). Sinnvoll ist es, in die Beurteilung auch die Unterstützungsangebote (z. B. Help Desk, Benutzerhandbücher) einzubeziehen. So werden alle Schritte und Aufgaben im laufenden Betrieb software-ergonomisch beurteilt und dokumentiert.

262

10.1 Test im Echtbetrieb und Optimierung

Abbildung 10.2: Ablauf der Mängelerhebung und Optimierung Nach drei bis vier Wochen werden die gesammelten Mängel von einem Projektmitglied zusammengetragen und systematisiert. Die Lösungsvorschläge werden in einem Workshop mit möglichst allen Benutzern einer Organisationseinheit (z. B. Abteilung) priorisiert und diskutiert. An diesem Workshop sollten auch der Leiter dieser Organisationseinheit und der zuständige Administrator teilnehmen.

263

10 Go Live & Optimierung Die Prüfung der technischen und organisatorischen Umsetzbarkeit der Vorschläge erfolgt danach im SAP-Koordinations- und Betreuungsteam. Die Mitarbeiter erhalten zeitnah Rückmeldung, wann und wie ein Verbesserungsvorschlag umgesetzt wird. Wird ein Vorschlag abgelehnt, ist es wichtig, dass die Benutzer dafür eine verständliche Begründung erhalten. Nach der Umsetzung der ersten Verbesserungsmaßnahmen startet gegebenenfalls ein zweiter Verbesserungszyklus, der wiederum mit einem Workshop und der Umsetzung der realisierbaren Verbesserungsvorschläge abgeschlossen wird. Nach ca. sechsmonatigem Testbetrieb ist die SAP-Software in der Regel so weit optimiert, dass der Baustein „Test im Echtbetrieb und Optimierung“ abgeschlossen und mit der Vorbereitung des Ergonomischen Meilensteins 5 begonnen werden kann.

10.2

Ergonomischer Meilenstein 5 Im Unterschied zu den bisherigen Meilensteinen dient der Meilenstein 5 nicht nur der Qualitätssicherung der Phase „Go Live & Optimierung“, sondern der abschließenden Bewertung des gesamten Projektes vor dem Hintergrund der angestrebten Usability-Ziele. Damit das Steuerungsgremium eine solche umfassende Beurteilung vornehmen kann, sind die nachfolgend dargestellten vorbereitenden Schritte erforderlich.

10.2.1

Vorbereitung des Ergonomischen Meilensteins 5

Überprüfen der Zielerreichung

Im Ergonomischen Meilenstein 5 muss entschieden werden, ob die vereinbarten ergonomischen Ziele des Projektes so weit erreicht wurden, dass dem Projektabschluss aus ergonomischer Sicht nichts im Wege steht. Auf welche Art und Weise dies überprüft wird, wurde bereits in der Phase „Projekteinstieg“ in den Vereinbarungen zu ergonomischen Projektzielen grundsätzlich festgelegt (vgl. Kapitel 5) sowie ggf. in den nachfolgenden Phasen „Anforderungsanalyse“ und „Sollkonzeption“ noch konkretisiert (vgl. Kapitel 6 und 7). Ganz allgemein werden hier wieder die drei Kriterien wichtig, die die DIN EN ISO 9241-11 als „Anforderungen an die Gebrauchstauglichkeit“ nennt: Verbesserung der Effektivität, Verbesserung der Effizienz und Erhöhung der Zufriedenheit der Benutzer (vgl. Kapitel 2).

264

10.2 Ergonomischer Meilenstein 5 Datenquellen

Zur Beurteilung der Zielerfüllung können Sie verschiedene Datenquellen heranziehen: •

Ergebnisse einer Mitarbeiterbefragung;

•

Testergebnisse aus der Evaluation testbarer Teilprozesse;

•

Ergebnisse von ergonomischen Tests an der in Betrieb genommen Software;

•

direkte Messungen von Systemvariablen, z. B. zur Feststellung der Systemantwortzeiten;

•

Art und Anzahl der Nachfragen in der Hotline zur Benutzung der SAP-Software;

•

Zahl, Ausmaß und Bedeutung der nicht umgesetzten Anforderungen aus der Anforderungsanalyse;

•

Zahl, Ausmaß und Bedeutung der nicht umgesetzten Gestaltungsvorgaben aus dem ergonomischen Sollkonzept;

•

Zahl, Ausmaß und Bedeutung der umgesetzten Maßnahmen, die aufgrund verschiedener Evaluationen mit Benutzern in den vorangegangenen Phasen beschlossen wurden;

•

Auswertung von Daten, die die SAP-Software bereitstellt, z. B. zum Nutzungsgrad; zur erreichten Datenqualität; zu erzielten Abrechnungsquoten je Zeiteinheit etc.

Achtung: Die Auswertung von Daten, die die SAP-Software über ihre Benutzer bereitstellt, wird in den meisten Fällen aufgrund bestehender Betriebsvereinbarungen zur Leistungs- und Verhaltenskontrolle nicht erlaubt sein! Benutzerbefragung

Eine bereits in Kapitel 5 genannte Möglichkeit, ergonomische Ziele zu überprüfen, ist die Befragung der Benutzer mittels eines geeigneten Fragebogens. Dabei können folgende Themen abgefragt werden: •

Benutzungsfreundlichkeit der SAP-Software (z. B. auf Grundlage der DIN EN ISO 9241-110, vgl. Kasten 10.1);

•

Aufgabengestaltung (z. B. auf Grundlage der DIN EN ISO 9241-2);

•

Wissen über benutzerspezifische Einstellmöglichkeiten der SAP-Software (vgl. Kasten 10.2);

•

Beteiligungswünsche bei der Veränderung von SAP-Anwendungen;

265

10 Go Live & Optimierung •

Wirksamkeit und Nutzen der Unterstützungsangebote (z. B. Hotline, Dokumentation, Schulungsunterlagen, Lernsystem);

•

Einschätzung des Erfüllungsgrades der ergonomischen Projektziele durch Benutzer oder Teamleiter;

•

weiterer Qualifizierungsbedarf.

Kasten 10.1: Der Benutzerfragebogen ISONORM 9241/10 Usability-Einschätzung durch die Benutzer Der ISONORM 9241/10 von Jochen Prümper (vgl. Prümper, 1993, 1997, 1999; Prümper & Anft, 1993) erlaubt eine Usability-Einschätzung nach den sieben Gestaltungsanforderungen der DIN EN ISO 9241-110 (Aufgabenangemessenheit, Selbstbeschreibungsfähigkeit, Steuerbarkeit, Erwartungskonformität, Fehlertoleranz, Individualisierbarkeit und Lernförderlichkeit) durch die Benutzer und ist ein wissenschaftlich fundiertes, effizient einsetzbares, robustes Verfahren, das erste Hinweise auf Schwachstellen und somit auf das Verbesserungspotenzial der Benutzungsfreundlichkeit von Softwaresystemen gibt. Der ISONORM 9241/10 kann sowohl zur Beurteilung von bereits etablierter Software eingesetzt werden als auch zur ersten Beurteilung von Prototypen im Rahmen eines iterativen Systemdesigns. Darüber hinaus stellt er eine geeignete Grundlage für die Moderation dar, wenn mit Benutzergruppen konkrete Designforderungen erarbeitet werden. Der „Granulationsgrad“ der Beschreibungssprache wurde so gewählt, dass die spezifischen Eigenschaften unterschiedlicher Softwaresysteme hinreichend genau differenziert werden können und sie gleichzeitig auf möglichst viele unterschiedliche Programme anwendbar ist. Um dem Anspruch eines ökonomisch einsetzbaren Verfahrens gerecht zu werden, wurde der Umfang des Fragebogens so zugeschnitten, dass jeder einzelne der sieben Grundsätze der DIN EN ISO 9241-110 über fünf bipolare Aussagen konkretisiert wird; insgesamt umfasst das Verfahren also 35 Items, und

Abbildung 10.3: Beispielitem des ISONORM 9241/10 für den Grundsatz „Steuerbarkeit“

266

10.2 Ergonomischer Meilenstein 5 die Zeit zur Beantwortung für den ISONORM 9241/10 beträgt ca. zehn Minuten. Beantwortet werden diese Aussagen auf einer sieben-stufigen Skala von „sehr negativ“ (- - -) bis „sehr positiv“ (+ + +). Abbildung 10.3 liefert ein Beispielitem des ISONORM 9241/10 für den Grundsatz „Steuerbarkeit“. Als Mindestanforderung für gebrauchstaugliche Software wurde festgelegt, dass der Gesamtmittelwert nicht unter „+1“ liegen darf. Der Fragebogen muss jeweils auf die projektspezifisch vereinbarten ergonomischen Ziele abgestimmt werden und lässt sich bei Bedarf um weitere Fragestellungen ergänzen. Einen Fragebogen als Prüfkriterium für die Zielerreichung einzusetzen ist allerdings nur dann sinnvoll, wenn sich die vereinbarten ergonomischen Ziele tatsächlich mit den Fragen des Fragebogens überprüfen lassen. Außerdem sollte bereits vor der Durchführung der Befragung feststehen, welches Mindestergebnis erreicht sein muss, damit die ergonomischen Ziele als hinreichend erfüllt angesehen werden können. Durchführung der Befragung

Im Rahmen einer Informationsveranstaltung werden die Benutzer über Ziele und Ablauf der Befragung sowie den Aufbau des Fragebogens informiert. Die Fragebögen werden an die Beschäftigten ausgegeben und auf Anfrage nochmals erläutert. Auf dem Deckblatt des Fragebogens sollten die Ziele der Befragung sowie die Modalitäten der Auswertung und der Speicherung der Daten beschrieben sein. Für das Ausfüllen des Fragebogens empfiehlt es sich, eine Zeitvorgabe von max. zwei Wochen festzulegen. Kasten 10.2: Ergebnisausschnitt einer Mitarbeiterbefragung in einem metallverarbeitenden Unternehmen Vergessene Usability-Ziele aufdecken Die folgende Tabelle zeigt ein Teilergebnis einer Mitarbeiterbefragung in der Personalabteilung eines metallverarbeitenden Unternehmens. Die Befragung wurde im Rahmen eines Projektes zur software-ergonomischen Optimierung durchgeführt und sollte ermitteln, welche Kenntnisse die Benutzer über Anpassungsmöglichkeiten der SAP-Software besaßen. In dieser Abteilung arbeiteten alle Mitarbeiter bereits zwei Jahre oder länger mit der Software. Entsprechend überraschte das Ergebnis: Denn hier zeigt sich deutlich, dass vielen Benutzern wichtige Stellschrauben zur er267

10 Go Live & Optimierung gonomischen Anpassung der Software und damit zur Erleichterung der Arbeit nicht bekannt waren. Wie konnte es dazu kommen? Bei der Festlegung der ergonomischen Ziele der SAP-Einführung war der Punkt „Anpassungswissen“ nicht in die Qualifizierungsziele aufgenommen worden. Man war stillschweigend davon ausgegangen, dass dieses Thema in den geplanten Qualifizierungsmaßnahmen auf jeden Fall ausreichend behandelt würde. Als Verbesserungsmaßnahme wurde für alle Benutzer eine so genannte Tipps & Tricks-Schulung durchgeführt, in der viele Individualisierungsmöglichkeiten vermittelt wurden (vgl. auch Kapitel 11). habe ich genutzt

habe ich nicht genutzt

kenne ich nicht

Cursorverhalten einstellen

15 %

31 %

54 %

Favoriten anlegen und bearbeiten

93 %

0%

7%

Felder mit Standardwerten vorbelegen

21 %

21 %

57 %

Persönliche Werteliste erstellen

14 %

14 %

72 %

Schriftgröße einstellen

7%

50 %

43 %

Standarddrucker einrichten

64 %

14 %

22 %

Tabellendarstellung in Masken ändern

36 %

14 %

50 %

Varianten von Reports erstellen

7%

0%

93 %

Tabelle 10.1

Wissen über Einstellungsmöglichkeiten der SAP-Software

Die beim Überprüfen der Zielerreichung ermittelten Ergebnisse (wie hier beispielsweise die Auswertungsergebnisse der Benutzerbefragung) bilden eine Entscheidungsgrundlage für die abschließende Bewertung des Projektes im Meilenstein 5.

268

10.3 Kontinuierlicher Verbesserungsprozess

10.2.2

Durchführung des Ergonomischen Meilensteins 5 Im Meilenstein 5 werden sämtliche im Laufe des Projektes erbrachten Nachweise und Ergebnisdokumentationen über ergonomische Aktivitäten begutachtet. Auf der Basis dieser Unterlagen entscheidet das Steuerungsgremium, ob die vereinbarten ergonomischen Ziele in ausreichendem Maße erreicht sind.

Entscheidung über Projektabschluss

Wenn dies der Fall ist, steht dem formellen Projektabschluss nichts im Wege, und das Steuerungsgremium kann mit der Planung des Kontinuierlichen Verbesserungsprozesses (KVP) beginnen. Falls die Usability-Ziele nicht hinreichend erfüllt sind, muss das Steuerungsgremium entscheiden, welche ergonomischen Mängel so gravierend sind, dass sie im Sinne einer „Nacharbeit“ erst behoben werden müssen, bevor ein formeller Projektabschluss erfolgen kann. Die Bearbeitung weniger gravierender ergonomischer Schwachstellen kann im Rahmen des KVP erfolgen. Als letzten Schritt im Meilenstein 5 entscheidet das Steuerungsgremium darüber, wie der Übergang in den KVP erfolgt und in welchem Umfang dieser stattfinden soll.

10.3

Kontinuierlicher Verbesserungsprozess Im Baustein „Test im Echtbetrieb und Optimierung“ können in der Regel nicht alle noch vorhandenen Mängel der SAP-Software beseitigt bzw. Optimierungsmöglichkeiten entdeckt werden. Außerdem entsteht durch SAP-Updates, Veränderung der Aufgabenzuschnitte oder auch gesetzliche Änderungen etc. immer wieder Anpassungsbedarf der Software. In dem Maße, in dem das Wissen, die Kenntnisse und die Erfahrungen der Benutzer über die Arbeit mit der Software wachsen und je länger sie damit arbeiten, verändern sich auch die Anpassungswünsche. Standen in der Testphase die groben und offensichtlichen Mängel (Ärgernisse) noch im Vordergrund, steigt das Bewusstsein für die Feinheiten und die Möglichkeiten der Software mit zunehmender Benutzungserfahrung. Um die ergonomische Qualität der SAP-Software zu erhalten bzw. weiter entwickeln zu können, müssen organisatorische Rahmenbedingungen geschaffen werden, die es erlauben, weiterhin Anforderungen und Verbesserungsvorschläge zu erheben und umzusetzen.

269

10 Go Live & Optimierung Im KVP kann die Software im Hinblick auf die Bedürfnisse der Benutzer optimiert und ihnen Hilfestellung bei der Benutzung der Software gegeben werden. Die Entscheidung, mit wie viel Initial-Aufwand man einen Kontinuierlichen Verbesserungsprozess implementiert, hängt u. a. von der Beurteilung der ergonomischen Qualität der Software in Meilenstein 5 ab. Weitere Kriterien für den Umfang des KVP sind Funktionsumfang und Zahl der Benutzer einer SAP-Anwendung. Je größer beides ist, desto wichtiger wird der systematisch durchgeführte Dialog zwischen Benutzern und SAP-Administratoren. Unsere Erfahrungen in Beratungsprojekten zum Usability Management haben gezeigt, dass in Betrieben, in denen ein regelmäßiger Austausch über die Arbeit mit der Software organisiert wird, die Benutzer die SAP-Anwendung deutlich besser beurteilen und effektiver und effizienter mit ihr arbeiten als in Betrieben, in denen es diese Möglichkeit nicht gibt. Rahmenbedingungen

Auftaktworkshop

Für die Entwicklung eines passenden KVP-Konzeptes sind eine Reihe von Fragen im Unternehmen zu klären: •

Wer soll die KVP-Aktivitäten koordinieren?

•

Welche Aufgaben fallen an?

•

Wer moderiert die KVP-Treffen?

•

In welchen Abständen sollen die KVP-Sitzungen stattfinden?

•

Wer soll an den KVP-Sitzungen teilnehmen?

•

Wie werden Fehler und Verbesserungsideen gesammelt?

•

Wie wird eine KVP-Sitzung vorbereitet?

•

Wer entscheidet über die Umsetzung der Verbesserungsvorschläge?

•

Wie werden die Benutzer über die Ergebnisse des Entscheidungs- und Umsetzungsprozesses informiert?

Als Einstieg in den KVP empfiehlt sich ein Auftaktworkshop. Falls eine abschließende Benutzerbefragung zur Beurteilung der Zielerreichung des Projektes stattgefunden hat, können hier zunächst die Befragungsergebnisse vorgestellt werden, zusammen mit den Entscheidungen des Steuerungsgremiums zur Behebung evtl. vorhandener ergonomischer Schwachstellen, die nicht vor dem Projektabschluss bearbeitet wurden. Anschließend wird das unternehmensspezifische KVP-Konzept dargestellt und für eine aktive Mitarbeit der Benutzer im KVP geworben.

270

10.3 Kontinuierlicher Verbesserungsprozess Ablauf einer KVP- Wie ein solches KVP-Konzept aussehen kann und wie eine KVPSitzung im Unternehmen ablaufen kann, wird in einem Beispiel Sitzung im nachfolgenden Kasten 10.3 veranschaulicht. Kasten 10.3: KVP (Praxisbeispiel) KVP in einem Versorgungsunternehmen In einem privatisierten Versorgungsunternehmen finden die KVP-Sitzungen in der Personalabteilung als Abteilungstreffen im Abstand von vier Wochen statt. Die Sitzungen stehen allen interessierten Mitarbeitern offen, die mit der Software arbeiten. Die Teilnahme an den Sitzungen ist freiwillig. Die Mitarbeiter der Abteilung sammeln während ihrer täglichen Arbeit an ihrem Arbeitsplatz Probleme und Verbesserungsideen und tragen diese in Protokollbögen (s. Kapitel 8) ein. Die Koordination der KVP-Aktivitäten hat der Abteilungsleiter übernommen, der auch zu den KVP-Sitzungen einlädt und diese moderiert. Ihm werden die Protokollbögen zwei Wochen vor der Sitzung zugestellt. Zur Vorbereitung der Sitzung werden die Protokollbögen vom Abteilungsleiter zusammengefasst, die Mängel bzw. Vorschläge nach Fehlerart sortiert und für die Teilnehmer der Sitzung vervielfältigt. Die KVP-Sitzungen finden in einem Raum statt, in dem neben Präsentationstechnik und Moderationsmaterialien ein SAP-Zugang zur Verfügung steht, damit ggf. Probleme direkt anhand der Software nachvollzogen werden können. Die Sitzungen laufen immer in den gleichen Schritten ab: 1. Einstieg: Präsentation der Mängel aus den Protokollbögen; Review der unbearbeiteten KVP-Themen aus der Themensammlung (s. Schritt 2); Information über den Bearbeitungsstand der Verbesserungsliste (s. Schritt 4); Präsentation / Diskussion der Aktivitätskarten aus der letzten Sitzung (s. Schritt 5). 2. Themensammlung: Die Teilnehmer schreiben auf Moderationskarten Antworten zu der Frage: „Worüber sollen wir heute sprechen?“. Die Karten werden sortiert und in Gruppen (Cluster) zusammengefasst. Zu den Clustern werden gemeinsam Bearbeitungsthemen formuliert und in die Themenliste geschrieben (Flipchart oder Pinnwand). 3. Themenauswahl: Die Teilnehmer bewerten die Wichtigkeit / Dringlichkeit der Themen nach der Frage: „Was stört, behindert am meisten?“. 271

10 Go Live & Optimierung 4. Themenbearbeitung: Die Teilnehmer diskutieren Lösungsmöglichkeiten zu einzelnen Themen. Bei Bedarf werden Mängel an der Software demonstriert. Verbesserungsvorschläge werden in einer Verbesserungsliste dokumentiert. 5. Abschluss: Die Teilnehmer treffen Absprachen für die Zeit bis zur nächsten KVP-Sitzung. Dazu ergänzt jeder Teilnehmer die Aussage „Ich werde bis zum nächsten Mal … !“ auf einer Moderationskarte (so genannte „Aktivitätskarte“). Die folgende Abbildung visualisiert die Schritte 2 und 3.

Abbildung 10.4: Themen einer KVP-Sitzung (Beispiel) Nach der Sitzung entscheiden Abteilungsleiter und Administrator gemeinsam über die Umsetzung der Vorschläge. Sie vervollständigen die Protokollbögen mit der Art der Maßnahme und dem zur Umsetzung vorgesehenen Zeitraum und begrün272

10.4 Zusammenfassung und Ausblick den die Ablehnung von Vorschlägen. Der EDV-Leiter wird bei der Bewertung und Umsetzung von abteilungsübergreifenden Verbesserungsvorschlägen hinzugezogen. Die Benutzer werden regelmäßig über die Ergebnisse des Entscheidungs- und Umsetzungsprozesses informiert.

10.3.1

Erfolgsfaktoren eines Kontinuierlichen Verbesserungsprozesses

Bereitschaft zur Beteiligung

Ein KVP kann nur dann optimal funktionieren, wenn Mitarbeiter aller Hierarchiestufen gemeinsam an Verbesserungen mitarbeiten. Dazu ist es erforderlich, dass Führungskräfte und EDV-Verantwortliche bereit sind, Mitarbeiter wirklich am Verbesserungsprozess zu beteiligen und damit auch Entscheidungskompetenz abzugeben. Verbesserungsaktivitäten – sollen sie nachhaltig sein und von allen getragen werden – sollten nach Möglichkeit durch die Beteiligten selbst erarbeitet werden.

Controlling der Aktivitäten

Damit das Thema KVP aktuell bleibt und nicht Gefahr läuft, mit der Zeit zu versanden, ist ein regelmäßiges Controlling der Verbesserungsaktivitäten von entscheidender Bedeutung. Umsetzungsergebnisse müssen zeitnah zurückgemeldet werden. Können Verbesserungsideen nicht umgesetzt werden, muss dies den Benutzern mitgeteilt und verständlich begründet werden.

Zusammenarbeit lernen

Auch die Zusammenarbeit in einem Team muss gelernt werden. Daher ist es sinnvoll, die Teilnehmer mit Methoden der Teamarbeit vertraut zu machen. Insbesondere die erste Sitzung sollte dazu genutzt werden, Aufgaben, Rechte, Pflichten und Spielregeln mit der Gruppe gemeinsam zu erarbeiten. Hilfreich für alle Teilnehmer ist es, wenn der Moderator in den Sitzungen einen Moderationsfahrplan einhält, der die Teilnehmer darin unterstützt, konstruktiv und kooperativ miteinander zu arbeiten. Die Einrichtung eines übergeordneten Entscheidungsgremiums, das in Konfliktfällen entscheidet, ist zu empfehlen. Dieses Gremium sollte jedoch nur in „Notfällen“ aktiv werden.

10.4

Zusammenfassung und Ausblick SAP-Projekte enden nicht mit dem Produktivstart. Sie haben in diesem Kapitel erfahren, dass Verbesserungs- und Qualifizierungsbedarf in der Regel auch nach dem Go Live bestehen. Diesem Umstand wird durch die Einführung des Bausteins „Test im Echtbetrieb und Optimierung“ Rechnung getragen. Durch die Einbindung der Mitarbeiter in die Optimierung der Software kann diese effizient verbessert werden, ein Prozess, der nach 273

10 Go Live & Optimierung dem offiziellen Projektabschluss kontinuierlich fortgeführt werden kann und in jedem Fall die Akzeptanz der Software bei den Benutzern in der kritischen Phase nach dem Go Live steigert. Sie haben schon eine produktive SAP-Software und möchten diese optimieren? Dass auch dies als eigenständige Maßnahme möglich ist und wie diese realisiert werden kann, erfahren Sie in dem nächsten Kapitel unter der Überschrift „Usability Care“. Bernd Stein und Stefanie Floegel

274

11

Usability Care In den vorigen Kapiteln ging es darum, wie Usability Management in den Einführungsprozess integriert werden kann. In diesem Kapitel möchten wir Ihnen zeigen, wie Sie die ergonomische Qualität von bereits eingeführten SAP-Modulen nachträglich verbessern können. Jedes SAP-Einführungsprojekt ist irgendwann zu Ende, das System aber wird nie ganz fertig. Denn die Arbeitsaufgaben verschieben sich, das Personal fluktuiert, das technische Umfeld im eigenen Unternehmen wie bei externen Partnern unterliegt einem kontinuierlichen Wandel. Das macht ein ständiges Nachjustieren der Geschäftsprozesse erforderlich, aber ebenso der SAPSoftware und ihrer Anpassung an die Arbeitsabläufe und an die Benutzer. So ist Usability Management im Grunde eine Daueraufgabe, deren Sie sich auch im laufenden Anwendungsbetrieb immer wieder annehmen müssen. Schon aus diesem Grunde ist es gut, über Verfahren und Instrumente für Usability Management im laufenden Systembetrieb zu verfügen. Erst recht brauchen Sie diese, wenn die Software-Ergonomie – aus welchen Gründen auch immer – während des Einführungsprozesses einer SAP-Software nur eine untergeordnete oder gar keine Rolle gespielt hat. Von dieser extremen Situation gehen wir in diesem Kapitel aus und präsentieren eine Vorgehensweise, mit der Sie selbst dann noch wesentliche Verbesserungen erzielen können. Wir sprechen in diesem Zusammenhang von Usability Care und meinen damit die aktive und systematische Beobachtung und Pflege der Gebrauchstauglichkeit während der gesamten Nutzungszeit eines Systems. Je nach den Vorarbeiten im Einführungsprojekt können Sie natürlich Bausteine der Usability Care weglassen oder verkürzen, wenn das sinnvoll erscheint. Das Kapitel gliedert sich nach einem kurzen Überblick entsprechend den Hauptphasen des vorgestellten Verfahrens in drei große Abschnitte:

275

11 Usability Care •

Ergonomische Ist-Analyse Dieser Abschnitt zeigt, wie Mängel aufgedeckt und Verbesserungsvorschläge entwickelt werden können.

•

Systemanpassung Hier geht es darum, Konsequenzen aus den Erkenntnissen der Ist-Analyse zu ziehen.

•

Wirkungskontrolle Die Erfolge eines Usability-Projektes sollten bilanziert werden. Dieser Abschnitt gibt dazu die entsprechenden Empfehlungen.

11.1

Überblick Die Arbeitsschritte der Usability Care sind in Abbildung 11.1 aufgelistet. Das Verfahren gliedert sich in drei Phasen: Zuerst gilt es in einer ergonomischen Ist-Analyse herauszufinden, wie die Software von den Benutzern bewertet wird und welche Verbesserungsmöglichkeiten es gibt. Danach werden die wichtigsten Verbesserungen vorgenommen. Schließlich wird überprüft, ob die ausgeführten Maßnahmen zum gewünschten Erfolg geführt haben, indem eine neuerliche Beurteilung der Software durch die Benutzer eingeholt wird.

Abbildung 11.1: 276

Usability Care im Überblick

11.1 Überblick Merkmale der Ausgangssituation

Einige Vorgehenselemente des integrierten Usability Management sind für eine nachträgliche ergonomische Optimierung ebenfalls empfehlenswert und tauchen daher auch bei der Usability Care wieder auf. Sie müssen aber modifiziert bzw. ergänzt werden, denn die Rahmenbedingungen für die ergonomische Optimierung im normalen, produktiven Systembetrieb unterscheiden sich in einigen Punkten wesentlich von der „Laborsituation“ der Einführungsphase und auch von einer Nachbesserung, wie wir sie in der Phase „Go Live & Optimierung“ des integrierten Usability Management schon wenige Wochen nach dem Produktivstart empfehlen. Wenn die Usability Care einsetzt, haben sich die Benutzer schon seit langem mit dem Softwaresystem vertraut gemacht. Sie stolpern nicht mehr über Ungewohntes, haben sich andererseits aber an mögliche ergonomische Mängel schon so sehr gewöhnt, dass sie ihnen nicht mehr auffallen. Deshalb ist der unvoreingenommene Blick betriebsfremder Experten auf das Softwaresystem und seine Einbettung in den Arbeitskontext besonders wichtig. Anders als im Einführungsprojekt haben Erscheinungsbild und Funktionen der Software schon eine gewisse Tradition und damit auch Selbstverständlichkeit gewonnen. Veränderungen fallen mehr Benutzern auf, mehr Personen müssen sich umgewöhnen, und es wird auch mehr Einwände geben. Das Management von Veränderungen ist daher ein aufwändigerer sozialer Prozess, der mehr Abstimmungen und Begründungen erfordert als in der ersten Gestaltungsphase, wo ohnehin vieles im Fluss, „das Eisen noch heiß“ ist. Dieser Abstimmungsprozess muss anerkanntermaßen fair verlaufen und transparent dokumentiert werden. Wenn die ergonomische Optimierung als eigene Maßnahme vom Einführungsprojekt separiert wird, steigt der Erwartungsdruck und angesichts der meist klar zu benennenden Projektkosten auch der Anspruch, einen nachträglichen Nutzennachweis zu erbringen. Hierfür sollten Sie von vornherein geeignete Schritte vorsehen. Wie in den Kapiteln über das integrierte Usability Management schlagen wir auch in diesem Kapitel einen Gesamtablauf vor, der sich bewährt hat, den Sie aber selbstverständlich abwandeln können und sollten, wenn die betrieblichen Rahmenbedingungen dies nahe legen.

277

11 Usability Care

11.2

Ergonomische Ist-Analyse Oft ist es schwieriger, gute Fragen zu stellen als gute Antworten zu geben. Und oft ist es schwieriger, Verbesserungsmöglichkeiten zu finden, als diese umzusetzen. Aus diesem Grund kommt der ergonomischen Ist-Analyse besonders hohe Bedeutung zu. Natürlich nützt die beste Analyse nichts, wenn sie am Ende keine realen Konsequenzen hat. Andererseits sind die fleißigsten Customizing- oder gar Programmierarbeiten verfehlt, wenn sie Probleme lösen, die niemand hatte. Kurzum: Die Ist-Analyse verdient einigen Aufwand. Wer hier spart, spart am falschen Ende.

Abbildung 11.2: Hauptarbeitsschritte der Ist-Analyse

Die ergonomische Ist-Analyse erfolgt in drei Hauptschritten: 1.

einer Fragebogenerhebung;

2.

Beobachtungsinterviews mit Videoanalyse;

3.

Fokusgruppe.

Chancen identifizieren

Das Ergebnis dieser drei Schritte ist zum einen eine Bewertung des ergonomischen Status, zum anderen eine mit Benutzern und Technikern abgestimmte Sammlung der wichtigsten Verbesserungsmöglichkeiten einschließlich Priorisierung und Aufwandsschätzung, also eine fundierte Entscheidungsvorlage zu der Frage, welche konkreten Maßnahmen tatsächlich umgesetzt werden sollen. Abbildung 11.3 zeigt den Ablauf der Ist-Analyse im Zusammenhang.

11.2.1

Fragebogenerhebung

Votum aus der Praxis

Der Ausgangspunkt der Analyse ist eine Befragung aller Benutzer des zu untersuchenden Systems bzw. Teilsystems. Die Benutzer sollen die Gestaltung der Software und ihrer Arbeitsaufgaben auf der Grundlage ihrer praktischen Erfahrung bewerten. Die Bewertungskriterien orientieren sich im Wesentlichen an den Teilen 2 und 110 der Norm DIN EN ISO 9241 (vgl. Kapitel 3).

278

11.2 Ergonomische Ist-Analyse

Abbildung 11.3:

Die Schritte der ergonomischen Ist-Analyse im Zusammenhang Vorgehensweise

Zur Erhebung der Benutzerbewertung kommen grundsätzlich verschiedene Fragensammlungen im Betracht, die mit Bezug auf DIN EN ISO 9241 entwickelt worden sind, z. B. der ErgoNormBenutzerfragebogen zu Arbeit und Software von Dzida u.a. (2001) oder auch der IsoMetrics von Willumeit u.a. (1996). Hier kommt ein Fragebogen zum Einsatz, wie er bereits in Kapitel 10 unter der Überschrift „Vorbereitung des Ergonomischen Meilensteins 5“ beschrieben wurde und der auf dem ISONORM 9241/10 von Prümper & Anft (1993) aufbaut. Während der Fragebogen in Kapitel 10 die Funktion hatte, nach der ergonomischen Anpassung eine abschließende Qualitätsbewertung zu liefern, dient er hier zur Orientierung beim Einstieg in die Optimierungsarbeit. Bewertungen und Es geht hier also nicht nur darum, eine zusammenfassende Beihr Hintergrund notung der Software unter verschiedenen ergonomischen Qualitätsaspekten zu gewinnen, sondern zugleich darum, die Ursachen für die Benotung herauszufinden, d. h. vor allem die Systemfunktionen und Arbeitsaufgaben zu identifizieren, die noch nicht optimal aufeinander abgestimmt sind. Aus diesem Grunde empfiehlt es sich, den Fragebogen ISONORM 9241/10 zu ergänzen. So sollten Sie nach den Bewertungsfragen zu den Grundsätzen der Dialoggestaltung zusätzlich um Beispiele bitten, die ggf. die Verletzung der Gestaltungsprinzipien illustrieren (vgl. Abbildung 11.4).

279

11 Usability Care

Abbildung 11.4:

Offene Fragen nach Systemmängeln bezüglich Kategorien der Norm DIN EN ISO 9241110

Weiterhin hat es Vorteile, wenn jeder Befragte angibt, welche Arbeitsaufgaben er mit der SAP-Software ausführt, wie oft er das tut und wie gut ihn die Software dabei unterstützt. Auf diese Weise wird deutlich, auf welche Funktionen und Aufgabenkontexte sich die erhobenen Benutzerbewertungen beziehen. Aufgaben, die für das zu bewertende Modul typisch sind, kann man in einer Ankreuzliste zur Auswahl vorgeben; eine offene Rubrik für „weitere Aufgaben“ sollte aber nicht fehlen. Der Kasten 11.1 zeigt Beispiele für solche Fragen, die bei der Ist-Analyse von Mitarbeitern einer Personalabteilung beantwortet wurden. Um noch gezielter nach möglichen Optimierungen suchen zu können, mag es sogar nützlich erscheinen, die Befragten um die Angabe ihrer Position oder gar ihres Namens zu bitten. Auf der anderen Seite aber kann es die Verlässlichkeit der Antworten beeinträchtigen, wenn die Teilnehmer befürchten, sich für ihre Bewertungen in irgendeiner Weise rechtfertigen zu müssen. 280

11.2 Ergonomische Ist-Analyse Kasten 11.1: Fragen und Auswertungsergebnisse zur Systemunterstützung bei bestimmten Arbeitsaufgaben aus einem HR-Anwenderbetrieb (Beispiele) Fragen zur SAP-Softwareunterstützung

Auswertung

281

11 Usability Care

Abbildung 11.5: Mögliche Themenbereiche für einen Fragebogen zur ergonomischen Ist-Analyse Fragen nach der Passung Aufgabe – Benutzer – Software

Neben den Fragen nach der Dialoggestaltung und der Unterstützung bestimmter Arbeitsaufgaben durch die Software sollten Sie auch die ergonomischen Qualitätskriterien für die Aufgabengestaltung selbst zum Thema machen. Hierzu wird ein Fragebogen verwendet, der sich eng an die Kriterien von DIN EN ISO 9241-2 anlehnt. Die Fragen beziehen sich ausdrücklich auf die Arbeit mit der SAP-Software und unterscheiden sich auch insofern von denen anderer bekannter Fragebögen, wie sie etwa im SANUSHandbuch von Burmester u.a. (1997) aufgeführt werden (vgl. hierzu Kapitel 3). Auch die Kenntnisse der Benutzer über die Software haben natürlich Einfluss auf deren Beurteilung der Gebrauchstauglichkeit und sollten daher in die Ist-Analyse einfließen. Schließlich ist es nützlich, nach der Bewertung des Benutzersupports zu fragen, denn der muss manche Mängel etwa bei der Selbsterklärungsfähigkeit kompensieren. Damit ergibt sich für die Benutzerbefragung im Rahmen der ergonomischen Ist-Analyse ein mögliches Themenfeld, wie es in Abbildung 11.5 zusammengefasst ist. Es deckt alle Aspekte der Passung im Ergonomischen Dreieck aus Benutzer, Aufgaben und Software ab. Wenn im konkreten Einzelfall der höchste Verbesserungsbedarf oder die meisten Verbesserungsmöglichkeiten an einer Ecke des Dreiecks besonders wahrscheinlich sind, z. B. bei der Technik, dann kann man natürlich auch im Fragebogen entsprechende Schwerpunkte setzen. Die Auswertung der Fragebögen zeigt auf jeden Fall, in welchen Ergonomiebereichen Schwachstellen zu suchen sind, und gibt erste Hinweise darauf, bei welchen Arbeitsaufgaben und Funktionen der SAP-Software Verbesserungsbedarf besteht.

282

11.2 Ergonomische Ist-Analyse Diese Hinweise können in die Auswahl der Arbeitsplätze für die Beobachtungsinterviews einfließen. Außerdem liefert die Auswertung der Fragebögen einen Referenzpunkt hinsichtlich der Qualitätsbewertung der Software, den Sie zum Vergleich mit einer zweiten Bewertung nach ihrer Anpassung heranziehen können. Aufwand und Ertrag Wenn eine Fragebogenerhebung nicht hochgradig routiniert und standardisiert abläuft, kann sie mit viel Arbeit verbunden sein. Hier sei nur an die notwendige Abstimmung mit Geschäftsführung und Betriebs-/Personalrat erinnert, an die erforderlichen Erläuterungen zur Befragungsaktion für die Benutzer, an Verteilung, Rücklaufkontrolle, Datenerfassung, Auswertung und Ergebnisdarstellung. Selbst wenn das Ausfüllen des Bogens nur eine halbe Stunde in Anspruch nehmen sollte, kann bei einer großen Zahl von Befragten ein beachtlicher Zeitaufwand zusammenkommen. Wo können Sie sparen? Teilbefragungen

Hat die zu untersuchende Software sehr viele Benutzer, können Sie sich auf eine Teilbefragung beschränken. Auch wenn die Erhebung nicht im strengen Sinne repräsentativ zu sein braucht, sollten Sie natürlich versuchen, mit der Auswahl der Befragten alle Aufgabenbereiche abzudecken, bei denen die Software zum Einsatz kommt. Einzeln zu betrachtende Gruppen sollten immer noch so groß sein, dass die üblichen statistischen Analysen sinnvoll anwendbar bleiben. Angesichts der Tatsache, dass die Rückläuferquote nur selten 100 % erreicht, empfiehlt sich bei weniger als 100 Benutzern eine Teilbefragung nicht. Eingespart wird ohnehin nur beim Zeitaufwand für das Ausfüllen der Fragebögen und – wenn diese nicht automatisch geschieht – bei der Datenerfassung.

Weniger Befragungsthemen

Der Gesamtaufwand sinkt auch durch eine Verkürzung des Fragebogens. Sie können z. B. erwägen, nur Fragen zur Dialoggestaltung im Sinne von Teil 110 der DIN EN ISO 9241 aufzunehmen und Fragen zur Arbeitsgestaltung wegzulassen. Oder Sie streichen die Fragen nach Beispielen für Gestaltungsmängel. Dadurch reduziert sich wieder der Zeitbedarf für die Beantwortung und die Datenerfassung, selbstverständlich aber auch der Erkenntnisgewinn. Im Minimalfall bleibt nur eine Benotung der ergonomischen Güte durch die Benutzer übrig, die es dem Anwenderbetrieb erlaubt, sich im Vergleich zu anderen Betrieben zu verorten, und die als Bezugsgröße für die Erfolgskontrolle die-

283

11 Usability Care nen kann. Ansatzpunkte für Verbesserungen ergeben sich so aber nicht. Referenzbewertung

Wenn Sie auf die Fragebogenerhebung insgesamt verzichten, fehlt auch diese numerische Qualitätseinstufung. Bei der Auswahl der Benutzer für die Beobachtungsinterviews müssten Sie sich am Rat von SAP-Betreuern, Abteilungsleitern oder Betriebs-/ Personalratsmitgliedern orientieren. Mängel-Beispiele nicht interviewter Benutzer würden gar nicht erfasst. Die Erfolgskontrolle der gesamten Usability-Maßnahme könnte sich nicht mehr auf den Vergleich zweier Bewertungen stützen, sondern müsste z. B. auf einer Befragung der Benutzer über ihre subjektive Einschätzung der Veränderung der Software basieren oder die Dokumentation der Verbesserungsmaßnahmen analysieren.

11.2.2

Beobachtungsinterviews mit Videoanalyse Beobachtungsinterviews sind mündliche Befragungen ausgewählter Software-Benutzer an ihren Arbeitsplätzen. Ziel ist es, konkrete Benutzungsprobleme zu identifizieren und ihnen möglichst genau auf den Grund zu gehen. Wir geben zunächst einen kurzen Überblick über den Ablauf der Beobachtungsinterviews und vertiefen dann einige besondere Aspekte. Allgemeine methodische Betrachtungen zu verschiedenen Interviewtechniken und Beobachtungsverfahren finden sich in der Literatur z. B. bei Kühl & Strodtholz (2002). Überblick Die Gespräche sind durch einen Interviewleitfaden vorstrukturiert. In einem ersten Teil werden die Benutzer nach ihren Arbeitsaufgaben, zu den hierbei benutzten Funktionen des betrachteten SAP-Moduls und zu den sonstigen von ihnen verwendeten Softwaresystemen befragt – und ebenso danach, welche Arbeiten sie besonders gern und welche sie besonders ungern mit der SAP-Software erledigen; denn oftmals verbergen sich hinter solchen Vorlieben und Abneigungen Vorzüge bzw. Mängel des Systems.

Beobachtung typischer Benutzungssequenzen

284

In einem zweiten Teil des Beobachtungsinterviews führen die Benutzer beispielhaft Aufgaben aus, bei denen sie die SAP-Software verwenden. Welche Aufgaben das sein sollen, stimmen die Interviewer mit den Benutzern ab. Bei der Auswahl können Sie sich an folgenden Fragen orientieren:

11.2 Ergonomische Ist-Analyse

Abbildung 11.6:

Vorgehensweise bei den Beobachtungsinterviews

•

Welche Aufgaben führt der Benutzer besonders häufig aus, und welche sind bestimmend für sein Gesamtarbeitsspektrum?

•

Bei welchen Aufgaben sind dem Benutzer Mängel der Software aufgefallen, die er vorführen möchte?

•

Zu welchen Aufgaben sind aus der Fragebogenerhebung, aus Vorgesprächen oder sonstigen Quellen Hinweise auf Probleme bekannt?

•

Welche Aufgaben führt der Benutzer besonders ungern mit der SAP-Software aus?

Während der jeweilige Benutzer die Arbeitsaufgaben ausführt, wird das Geschehen auf dem Bildschirm als Videofilm aufgezeichnet. Unmittelbar nach der Aufnahme schauen sich Benutzer und Interviewer den Film gemeinsam an und besprechen aufgetretene Schwierigkeiten und diesbezügliche Fragen des Interviewers. Der dritte Teil des Beobachtungsinterviews schließlich widmet sich bekannten, für große, integrierte Standard-Informationssysteme typischen Problemen. Die Benutzer werden gefragt, ob sie diesen bei ihrer Arbeit begegnet sind. So erkundigen sich die Interviewer z. B. nach der rechtzeitigen Verfügbarkeit korrekter Daten, die von anderen Stellen aktuell gehalten werden müssen,

285

11 Usability Care nach der Durchschaubarkeit der globalen Datenverarbeitungsprozesse und nach der Angemessenheit der Zugriffsberechtigungen. Ein Beobachtungsinterview dauert gut drei Stunden. Danach schreibt der Interviewer ein Protokoll, das er seinem Interviewpartner zur Überprüfung vorlegt. Außerdem wertet er die Videoaufnahmen aus und dokumentiert alle Benutzungsprobleme, die ihm auffallen, im „ergonomischen Fallregister“, einer Zusammenstellung von „Fundstücken“, die gewissermaßen die Stoffsammlung für die spätere Diskussion in der Fokusgruppe und danach für Verbesserungsmaßnahmen bildet. Die Beobachtungsinterviews haben Ähnlichkeit mit der Erhebung des Nutzungskontextes bei der Anforderungsanalyse im Rahmen des integrierten Usability Management (s. Kapitel 6). Während die Anforderungsanalyse vor der Einführung der neuen SAP-Software stattfindet, konzentrieren sich die Beobachtungsinterviews auf Probleme, die nach der Softwareeinführung bei ihrer produktiven Nutzung auftreten. Selbstverständlich resultieren solche Probleme nicht nur aus Fehlern der SAP-Software an sich; vielmehr begegnen uns bei der Beobachtung der Benutzer viele Mängel, die ihre Ursache in einer unzulänglichen Passung zwischen Arbeitsaufgaben und Technik haben. Wenn solche Mängel besonders gravierend sind und größere Nachbesserungen erforderlich erscheinen, kann es sinnvoll sein, Elemente der Anforderungsanalyse aufzugreifen und z. B. eine systematische Erhebung des Nutzungskontextes einzelner Arbeitsplätze nachzuholen. Der normale Ablauf der Beobachtungsinterviews wäre dann entsprechend zu modifizieren. Auswahl der zu interviewenden Benutzer Wichtige Aufgaben betrachten

Um einen möglichst umfassenden Überblick über ergonomische Mängel und Verbesserungsmöglichkeiten zu erhalten, sollten Sie bei der Auswahl der zu besuchenden Arbeitsplätze darauf achten, dass alle wichtigen Arbeitsaufgaben und alle zugehörigen Funktionen der Software betrachtet werden. Die „Wichtigkeit“ bemisst sich dabei vor allem nach der Ausführungsfrequenz. Aber auch fachliche Anforderungen an die schnelle Verfügbarkeit und Zuverlässigkeit der Arbeitsergebnisse sind zu bedenken. Lohnzahlungen dürften „wichtiger“ sein als Fehlzeitenstatistiken, die Fakturierung „wichtiger“ als Nachkalkulationen. Drei bis fünf Beobachtungsinterviews sollten ausreichen, um die Ergonomie eines SAP-Moduls zu untersuchen. Wenn die Ressourcen knapp sind, ist es besser, wenige Arbeitsplätze mit wich-

286

11.2 Ergonomische Ist-Analyse tigen Funktionen gründlich zu untersuchen, als sich an vielen Arbeitsplätzen auf Stippvisiten zu beschränken. Denn oberflächliche Analysen verfehlen allzu leicht den Kern des Problems und führen dann zu wenig hilfreichen Konsequenzen, hoffnungsvolle Benutzer mit großen Erwartungen werden frustriert, der mäßige Erfolg bringt das ganze Vorhaben in Misskredit. Positive Einzelbeispiele dagegen machen Mut, die ergonomische Optimierung in einem späteren Schritt auf andere Arbeitsbereiche auszudehnen. Persönliche Merkmale

Neben den ausgeführten Arbeitsaufgaben spielt bei der Festlegung der Beobachtungsinterviews auch die Person des Interviewpartners eine Rolle. Neueinsteiger haben andere Bedürfnisse als alte Hasen, Technikfreaks andere als Technik-Skeptiker. Alter und Geschlecht können weitere Kriterien sein, hinsichtlich deren man die Stichprobe mischt. Insgesamt aber geht es nicht etwa darum, Repräsentativität im statistischen Sinne zu gewährleisten, sondern nur um eine insofern gute Auswahl, als sie eine hohe Effektivität der Untersuchung verspricht.

Freiwilligkeit

Ein Auswahlkriterium allerdings muss unbedingt beachtet werden: Die Teilnahme ist für die Interviewpartner freiwillig. Zwar sind bei der Untersuchung ausschließlich die SAP-Software und ihre organisatorische Einbettung Gegenstand einer Beurteilung, nicht die Benutzer. Aber es ist doch unvermeidlich, dass die Interviewer auch das Arbeitsverhalten zur Kenntnis nehmen und bei der Video-Aufzeichnung sogar dokumentieren. Daher ist es unbedingt zu respektieren, wenn jemand trotz aller Zusicherungen und Informationen über die Spielregeln Vorbehalte hat. Ein gegen den Willen des Benutzers angeordnetes Beobachtungsinterview würde wegen fehlender Kooperationsbereitschaft ohnehin kaum nützliche Ergebnisse bringen. Auswahl der Interviewer Neben den Befragten sind auch die Interviewer zu bestimmen. Wer soll diese Rolle übernehmen? Die wichtigsten Auswahlkriterien beziehen sich auf zwei Aspekte: Distanz und Qualifikation.

Distanz der Interviewer

Um effektiv Schwächen und Verbesserungsmöglichkeiten identifizieren zu können, muss der Analyst die Arbeit mit der SAP-Software möglichst unvoreingenommen betrachten, und dafür braucht er einen gewissen Abstand von den Gepflogenheiten in der jeweiligen Abteilung und von den Personen, die für die Arbeitsabläufe bzw. für die Einrichtung der Software verantwortlich sind. Wer eine jahrelange Praxis gewohnt ist, dem fällt es oft schwer, notwendige Alternativen vorzuschlagen. Eine enge per287

11 Usability Care sönliche Beziehung zu Customizern und Entwicklern kann die Kritikfähigkeit beeinträchtigen. Daher sollten die Interviewer auf jeden Fall aus Abteilungen stammen, die mit den betrachteten Geschäftsprozessen und mit der Systempflege nichts zu tun haben. In großen Betrieben kommen evtl. Mitarbeiter aus dem Bereich Arbeits- und Gesundheitsschutz in Betracht. In kleinen Betrieben wird man sinnvollerweise auf Externe zurückgreifen. Qualifikation der Interviewer

Was die Qualifikationsvoraussetzungen der Interviewer betrifft, ist natürlich die Vertrautheit mit den Erhebungsinstrumenten unverzichtbar. Die Einbettung der Interviews in den gesamten Analyseprozess muss den Interviewern klar sein, sie müssen den Interviewleitfaden genau kennen und sich an eine einheitliche Vorgehensweise und Fragetechnik halten, damit die gewonnenen Ergebnisse vollständig und vergleichbar sind. Als inhaltliche Qualifikation sind Grundkenntnisse der Software-Ergonomie notwendig. Zumindest die abstrakten Anforderungskategorien müssen ihnen geläufig sein, damit sie im Dickicht auch komplizierter Funktionsabläufe nicht die Orientierung auf die Ergonomiefragen verlieren. Kenntnisse über die tatsächlichen Spielräume für die Softwaregestaltung und über Beispiele für Gestaltungsvarianten wären vorteilhaft, sind aber nicht unabdingbar. Fachkenntnisse aus dem jeweiligen Anwendungsbereich sind nur in sehr begrenztem Maß erforderlich. Zwar sollten sich die Interviewer vorab mit den Geschäftsprozessen im Groben vertraut machen. Andererseits ist es für das Sammeln von Verbesserungspotenzialen durchaus vorteilhaft, wenn man als Laie auf dem Gebiet etwa der Lagerverwaltung, der Produktionsplanung oder des Einkaufs legitimiert ist, „dumme Fragen“ zu stellen. (Vgl. die Empfehlungen aus Kapitel 6, Abschnitt 6.1.2 zur Lehrling-MeisterBefragung bei der Anforderungsanalyse.) Interviewer brauchen also nicht unbedingt wissenschaftlich hoch qualifizierte Ergonomen zu sein. Mit einer guten Sensibilität für Usability-Aspekte, einer kompakten Methodenschulung und Geschick bei der Gesprächsführung lassen sich wertvolle Informationen erheben. Im weiteren Verlauf der Analyse folgen allerdings noch Aufgaben, die eine gewisse ergonomische Expertise und zusätzliche Kompetenzen etwa für die Analyse der Videoaufzeichnungen, die Dokumentation, Kategorisierung und Gewichtung der gefundenen Mängel, die Moderation der Fokusgruppe und evtl. für die Präsentation der Ergebnisse erfordern. Diese Aufgaben können nicht auf beliebig viele Personen verteilt werden. Die Gruppe,

288

11.2 Ergonomische Ist-Analyse die ein Usability-Care-Projekt vorantreibt, wird in der Regel klein sein, und eine hauptverantwortliche Person muss ohnehin den Gesamtüberblick wahren. Daher liegt es nahe, dass bei der gesamten ergonomischen Ist-Analyse recht verschiedene Aufgaben in Personalunion von einem Analysten wahrgenommen werden, der dann allerdings über Kenntnisse und Fähigkeiten in allen erforderlichen Gebieten verfügen sollte. In kleinen Projekten mag man sogar erwägen, die gesamte Analyse einer einzigen Person zu übertragen. Was aus Sparsamkeitsgründen vorteilhaft erscheinen mag, wird sich aber in Qualitätsverlusten niederschlagen, weil diesem Analysten dann der fachliche Austausch mit Kollegen fehlt. Vertraulichkeit Informationen über Interviewpartner

Vertraulichkeit ist unter verschiedenen Gesichtspunkten von hoher Bedeutung für die Beobachtungsinterviews. Zuallererst geht es um den Schutz der Interviewpartner, die in den Interviews durchaus sensible Informationen über sich selbst mitteilen: Sie berichten über Schwierigkeiten, die sie bei der Ausführung ihrer Aufgaben erleben, und über ihre Einschätzung des IT-Systems und der Arbeitsorganisation. Sie führen dem Interviewer vor, wie sie ihre Aufgaben mit der SAP-Software bearbeiten, dulden Filmaufnahmen von ihrer Tätigkeit, die der Interviewer dann auch noch zur weiteren Auswertung mitnimmt. Man verlangt also von den Interviewpartnern großes Vertrauen, dass diese Informationen nicht missbraucht werden. Deshalb ist es unbedingt erforderlich, dass die Interviewer sich persönlich verpflichten, klar formulierte Vertraulichkeitsregeln einzuhalten. Mit diesen Regeln muss sich auch der Betriebs-/Personalrat einverstanden erklären, denn ohne seine Zustimmung wären Mitarbeiterbefragungen und erst recht Videoaufnahmen unzulässig.

Informationen aus dem System

Neben den Interviewpartnern sind oftmals auch Daten über andere Personen zu schützen, die bei den Demonstrationen am System sichtbar werden können. Das gilt in besonderem Maße für Personaldaten im Modul HR; aber auch in fast allen anderen Modulen sind personenbezogene Daten gespeichert, z. B. die Namen von Bestellern und Einkäufern, Lageristen, Kostenstellenverantwortlichen, Finanzbuchhaltern und Instandhaltern samt Hinweisen auf ihre Arbeiten. Hinzu kommen Daten über Betriebsfremde wie Kunden und Lieferanten und obendrein sensible Informationen des Unternehmens, z. B. aus dem Rechnungswesen oder über die Konditionen des Vertriebs. Wenn neben der produktiv gesetzten SAP-Software eine funktionsgleiche Test289

11 Usability Care version mit anonymisiertem Datenbestand zur Verfügung steht, kann man die Benutzung auch hieran demonstrieren und damit die Anzeige und Videoerfassung schutzbedürftiger Informationen reduzieren. Sofern aber sensible Daten im Rahmen der Untersuchung bekannt werden, müssen sie natürlich streng vertraulich behandelt werden. Verbindliche Verwendungsregeln

Über die Verwendung vertraulicher Informationen sollten mindestens folgende Kernpunkte verbindlich vereinbart werden: •

Zweckbegrenzung Die Auswertung der Informationen erfolgt nur zu dem Zweck, Optimierungsmöglichkeiten für die Ergonomie des Einsatzes der SAP-Software zu finden. Eine Bewertung des Könnens der Benutzer oder der Effizienz ihrer Arbeitweise findet nicht statt.

•

Weitergabeverbot Ergebnisse der Beobachtungsinterviews werden protokolliert. Die Protokolle werden den jeweiligen Interviewpartnern zur Prüfung vorgelegt. Die Interviewer geben die Protokolle an niemanden sonst weiter. – Die Videoaufzeichnungen verbleiben beim Interviewer. Sequenzen aus den Videofilmen werden Dritten nur vorgeführt, soweit sie keine schützenswerten Daten über das Unternehmen und keine Daten über Personen zeigen und soweit der jeweilige Benutzer dem zugestimmt hat. – Resultate der Untersuchung werden stets ohne Personenbezug, andernfalls nur nach Zustimmung durch den jeweiligen Interviewpartner weitergegeben. Der Interviewpartner kann auch die Weitergabe bestimmter Informationen ohne Personenbezug untersagen.

•

Löschung Nach Abschluss der Untersuchungen werden die Videoaufzeichnungen gelöscht, Interviewprotokolle werden vernichtet.

Videotechnik Um Arbeitssequenzen mit der Software zu dokumentieren, kann man einen „Screenrecorder“ verwenden, der zwischen PC und Bildschirm geschaltet wird und lediglich das Videosignal kopiert und aufzeichnet. Man kann das Geschehen auf dem Bildschirm natürlich auch mit einer normalen Handkamera aufnehmen, wenn die Kamera einige technische Voraussetzungen erfüllt. Bildschirmfenster, Farben, Schrift und Bilder müssen bei der Wiedergabe klar erkennbar sein. Manchmal führt das Flimmern 290

11.2 Ergonomische Ist-Analyse von Kathodenstrahlbildschirmen zu Problemen. Auch werden schnelle Mausbewegungen nicht immer vollständig dargestellt. Außerdem muss eine Kamera auf ein Stativ montiert und irgendwie auf den Bildschirm gerichtet werden. Das kann schon räumliche Schwierigkeiten bereiten und verwandelt das Büro leicht in ein kleines Filmstudio, in dem der Befragte vielleicht eine gewisse Befangenheit überwinden muss. Externe Aufzeich- Der große Vorteil solcher externen Aufzeichnungsverfahren ist, dass keinerlei Eingriffe in die Konfiguration der SAP-Software ernungssysteme forderlich sind. Alternativ dazu könnte man eines der zahlreichen Programme einsetzen, die das Bildschirmgeschehen z. B. als Quick-Time-Movie aufzeichnen. Solche Programme müssen aber erst installiert werden, was vielleicht sogar zu Kompatibilitätsproblemen führen könnte. Außerdem erscheinen softwaregestützte Aufzeichnungssysteme in den Augen der Benutzer evtl. riskanter. Denn sie können schwerer überblicken, ob das Programm nach dem Beobachtungsinterview auch tatsächlich wirksam entfernt wird und ob die Dateien mit den Filmen nicht doch irgendwie noch anderen Personen zugänglich sind. Ein Apparat, den man sichtbar anschließt und wieder wegnimmt, dürfte in dieser Hinsicht vertrauenswürdiger erscheinen. Bei der Analyse der Filme scheint es gelegentlich wünschenswert, neben den Bildschirmereignissen auch die Tastatureingaben sehen zu können. Auch Ton- oder gar Videoaufnahmen der Benutzer selbst können bei der Interpretation der Filme hilfreich sein. Jedoch sollten Sie den Erkenntnisgewinn ins Verhältnis setzen zum erhöhten technischen Aufwand und zur zusätzlichen Belastung der Probanden, die aller Erfahrung nach erleichtert reagieren, wenn sie erfahren, dass nur das Geschehen auf dem Bildschirm aufgezeichnet werden soll. Auswertung und Dokumentation Die Auswertung der Beobachtungsinterviews durch ErgonomieExperten soll die Problembeschreibungen der Interviewpartner systematisieren und – was nicht weniger wichtig ist – durch eigene Beobachtungen ergänzen. Denn die Benutzer weisen meist nur auf solche Mängel hin, die sie bei der Alltagsarbeit als lästig empfinden und die ihnen zugleich unnötig erscheinen. Der Blick des Experten entdeckt in der Regel zusätzliche Verbesserungsmöglichkeiten, weil er sich an den abstrakten Kategorien der Software-Ergonomie orientiert und die Breite der technischen Gestaltungsoptionen besser überschauen kann. Im Folgenden

291

11 Usability Care notieren wir einige Vorschläge für das Vorgehen bei der Auswertung der Beobachtungsinterviews. Suchstrategie

Es lohnt sich, das gesamte verfügbare Material zu analysieren. Dazu gehören die Notizen der Interviewer über ihre Beobachtungen am Arbeitsplatz und über die Antworten der Benutzer auf die standardisierten Fragen aus dem Interviewleitfaden, außerdem eingesammelte Artefakte (Datenerfassungsformulare, Papierlisten, Verzeichnisse, Diagramme) und vor allem die Videoaufzeichnungen. Des Weiteren sollten die bei der Fragebogenerhebung genannten Beispiele für schlechte Erfüllung der Ergonomie-Normen vorliegen. Sehr vorteilhaft ist es, wenn der Experte bei der Analyse dieses Materials einen Zugang zu einer Testversion der SAP-Software hat, so dass er Arbeitsschritte, die ihn interessieren, selbst nachspielen und in unterschiedlichen Varianten austesten kann. Wie nun können Sie in dem reichhaltigen Material nach Verbesserungsmöglichkeiten suchen? Wie finden Sie interessante Systemfunktionen bzw. Arbeitsaufgaben? •

Beschwerdenorientiert Vollziehen Sie im Videofilm und/oder an der Software die Schritte nach, die der Interviewpartner oder ein Teilnehmer der Fragebogenerhebung als verbesserungsbedürftig beschrieben hat. Prüfen Sie die vorgetragenen Mängel.

•

Vorliebenorientiert Untersuchen Sie die Benutzungssequenzen im Videofilm und/oder an der Software, die der Interviewpartner am wenigsten gern ausführt.

•

Fehlerorientiert Suchen Sie in der gesamten Filmaufnahme nach Stellen, an denen dem Benutzer Fehler unterlaufen, wie z. B. Eingabe falscher Daten, Aufruf falscher Funktionen, Mausklick in falsches Maskenfeld. Untersuchen Sie alle Situationen, in denen Fehlermeldungen erscheinen. Betrachten Sie auch Stellen, an denen der Benutzer zögert und nach den richtigen Funktionen sucht.

•

Kategorienorientiert Achten Sie auf Beispiele für die typischen Fehlerarten, wie sie in der Sammlung von Mängelkategorien in Kapitel 8 aufgelistet sind.

Erfahrungsgemäß kommen auf diese Weise pro Beobachtungsinterview leicht 30 und mehr „Fundstücke“ zusammen, Beispiele 292

11.2 Ergonomische Ist-Analyse für kleinere und größere Unzulänglichkeiten der SAP-Software und ihrer Einsatzweise, die für die weitere Bearbeitung dokumentiert und nach Art und Schwere sortiert werden müssen. Ergonomisches Fallregister

Die Analyseergebnisse dokumentieren Sie am besten sofort nach einem einheitlichen Schema in Form einer Tabelle oder einer kleinen Datenbank. Das erleichtert das Suchen, Sortieren und Exzerpieren im wachsenden Bestand der Fundstücke. Jeder Beispielfall eines ergonomischen Mangels sollte zunächst mit folgenden Angaben charakterisiert werden (vgl. Kasten 11.2): •

Eindeutige Kennung des Falls;

•

Lokalisierung der zugehörigen Videosequenz (Dateiname, Laufminute ...);

•

Betroffene SAP-Funktion;

•

Stichwort zur Arbeitsaufgabe bzw. zum Ziel der Benutzeraktion sowie Stichwort zum festgestellten Problem;

•

Beschreibung des Problems;

•

Häufigkeit, mit der das Problem auftritt;

•

Zeitverlust z. B. wegen unnötiger Arbeitsschritte oder Fehlerkorrektur;

•

Zuordnung zu den Mängelkategorien;

•

Schweregrad des Problems nach Einschätzung des Analysten durch Einordnung auf einer in Kapitel 8 schon erwähnten Bewertungsskala von 0 = „kein Problem für die Software-Ergonomie“ bis 4 = „sehr großes Problem, unbedingt beheben, höchste Priorität“);

•

Verbesserungsvorschläge.

Nicht in jedem Fall kann man alle diese Rubriken ausfüllen. Zu manchen Mängeln mag es keine Videoaufzeichnung geben, manchmal ist es schwierig, den Zeitverlust abzuschätzen oder eine Verbesserungsmöglichkeit zu benennen. Trotzdem sollte jede Auffälligkeit in die Gesamtliste der Fundstücke aufgenommen werden, damit zunächst ein Gesamtüberblick geschaffen wird. Im Interesse der Vollständigkeit empfiehlt es sich sogar, Problemmeldungen in die Liste zu übernehmen, die nur in den Benutzerfragebögen auftauchen, auch wenn diese Darstellungen typischerweise einer genaueren Aufklärung bedürfen. Dieses Gesamtverzeichnis nennen wir „Ergonomisches Fallregister“. Es begleitet Sie während aller folgenden Arbeitsschritte und wird nach und nach weiter vervollständigt. Damit steht Ihnen ein 293

11 Usability Care Kasten 11.2: Auszug aus einem Ergonomischen Fallregister nach der Videoanalyse (Praxisbeispiel)

294

11.2 Ergonomische Ist-Analyse Dokument zur Verfügung, das gleichermaßen als Aufgabenliste wie als Nachweis der vollzogenen Analyse-, Bewertungs- und Verbesserungsschritte dient. Auswahl der 20 wichtigsten Probleme

Auch für den nächsten Schritt, die Fokusgruppenarbeit, bildet das ergonomische Fallregister die zentrale Arbeitsgrundlage. Jedoch wird es voraussichtlich zu umfangreich sein, als dass Sie es vollständig in der Fokusgruppe behandeln könnten. Deshalb sollte der Ergonomie-Experte aus seiner Sicht die „Top 20“ der wichtigsten Benutzungsprobleme auswählen und speziell diese der Fokusgruppe zur weiteren Behandlung empfehlen. Folgende Auswahlkriterien bieten sich an: •

Schweregrad des Problems: Mängel, die in der Bewertungsskala hoch eingestuft wurden;

•

Häufigkeit: Mängel, die oft zu Problemen führen;

•

Reichweite: Mängel, von denen besonders viele Benutzer betroffen sind.

Insgesamt geht es darum, die Probleme herauszusuchen, deren Beseitigung den größten Nutzen verspricht oder bei denen eine Klärung in der Fokusgruppe lohnend erscheint, weil sich dabei ein besonders großes Verbesserungspotenzial zeigen könnte. Wir belassen es hier bei diesen allgemeinen Hinweisen zu möglichen Auswahlkriterien. Grundsätzlich allerdings ist die Priorisierung von Problemen ein wichtiger Vorgang, weil er eine folgenreiche Weichenstellung bedeuten kann. Er ist auch keineswegs trivial (Vgl. dazu etwa den Artikel von Hassenzahl, Prümper & Sailer, 1997). Zur Sicherheit kann man den Mitgliedern der Fokusgruppe natürlich das gesamte ergonomische Fallregister zur Verfügung stellen, so dass sie jedes Problem aus dem Register oder auch aus ihrer persönlichen Erfahrung in die Diskussion einbringen können. Die Liste der nach Problemkategorien gegliederten „Top 20“ bleibt aber eine nützliche Hilfe zur inhaltlichen Fokussierung der Gruppenarbeit. Aufwand und Ertrag Der Aufwand für die Beobachtungsinterviews in der beschriebenen Form inklusive Videoauswertung ist erheblich. Die Durchführung und Auswertung jedes Interviews kostet etwa zwei Tage Arbeit, und zur Bewertung eines SAP-Moduls sollten mindestens drei Interviews geführt werden.

295

11 Usability Care Konkrete Beispiele Auf der anderen Seite sind die Beobachtungsinterviews aller Erfahrung nach äußerst ergiebig. Sie liefern viel mehr konkrete Beispiele für Mängel und Verbesserungsmöglichkeiten als z. B. die entsprechenden Fragen in den Fragebögen. Gerade bei funktionalen Unzulänglichkeiten des Softwaresystems ist es unerlässlich, die Kritikpunkte genau zu verstehen. Die frei formulierten Problembeschreibungen in Fragebögen sind jedoch in aller Regel so grob oder setzen so viel Kontextwissen über den Arbeitsablauf des jeweiligen Benutzers voraus, dass Nachfragen erforderlich sind. Der Fragebogen lokalisiert Probleme. Für deren Lösung bedarf es einer anschließenden Detailanalyse, die zu erheblichen Teilen in den Beobachtungsinterviews stattfindet. Doppelte Perspektive

Eine besondere Stärke der Beobachtungsinterviews ist zudem, dass der Einsatz der SAP-Software sowohl aus der Perspektive des Anwendungspraktikers als auch aus der des Ergonomie-Experten betrachtet wird. Der jeweils spezifische Erfahrungshintergrund der beiden Interviewpartner und ihre direkte Verständigung führen zu einem weitaus umfassenderen, präziseren und besser strukturierten Bild von der Anwendungssituation, als es jeder Einzelne von ihnen liefern könnte.

Eventuell weniger Arbeitsplätze

Bevor man auf die Beobachtungsinterviews ganz verzichtet, sollte man deshalb lieber ihre Zahl begrenzen. Es ist besser, wenige Arbeitsplätze gründlich zu untersuchen, als nach einer oberflächlichen Breitenerhebung mangels Problemverständnis nirgends zu echten Verbesserungen zu finden. Auch die Videoanalyse ist ein zeitintensiver Prozess. Die Auswertung der Aufnahmen kann bis zu zehnmal so viel Zeit in Anspruch nehmen wie der aufgenommene Arbeitsgang selbst. Was können Sie sparen, wenn Sie auf die Videoanalyse verzichten? Der Aufwand reduziert sich – aber Sie sparen nicht die ganze Analysezeit ein. Denn die Mängel und Verbesserungsideen müssen auf jeden Fall dokumentiert werden, und dafür ist der Videofilm eine hervorragende Gedankenstütze. Ohne den Film kann der Analyst nur auf seine Notizen zurückgreifen und problematische Sequenzen bestenfalls an der Software nachspielen, was seinerseits Zeit in Anspruch nimmt. Vor allem aber bleiben zahlreiche Mängel unentdeckt, die normalerweise nicht dem Benutzer, sondern erst dem Experten bei der Durchsicht der Videoaufnahmen auffallen. Die Mängelliste wird sich also vor allem auf die von den Benutzern gemeldeten Problempunkte beschränken. Und deren Analyse wird unpräziser

296

11.2 Ergonomische Ist-Analyse oder verlagert sich in das Interview selbst, wo sie natürlich wieder Zeit beansprucht.

11.2.3

Fokusgruppe In den bisherigen Verfahrensschritten, der Fragebogenerhebung und den Beobachtungsinterviews, haben Usability-Analysten Informationen gesammelt und ausgewertet. In der Fokusgruppe werden die aufbereiteten Erhebungsergebnisse einer kleinen Gruppe von Benutzern zurückgespiegelt.

Aufgabenstellung

In der Fokusgruppe sollen folgende Fragen beantwortet werden: •

Wurden die gefundenen Benutzungsprobleme richtig verstanden und zutreffend beschrieben?

•

Wie schwerwiegend sind die erkannten Mängel?

•

Welche Änderungen an der SAP-Software (und evtl. auch an der Arbeitsorganisation) würden die einzelnen Mängel beheben?

•

Welche Mängel gehören nicht in die Liste der 20 wichtigsten Benutzungsprobleme? Welche müssen zusätzlich in die Liste aufgenommen werden?

Zur Klärung dieser Fragen ist eine moderierte Diskussionsrunde die geeignete Arbeitsform, weil sie Kreativität und Gründlichkeit fördert. Außerdem werden viele Änderungsvorschläge zur Sprache kommen, die sich auf verschiedene Benutzergruppen auswirken. Sie sind aus der Perspektive jeder betroffenen Gruppe zu beleuchten, damit sie von möglichst allen Benutzern befürwortet werden. Auswahl der Teilnehmer

Dementsprechend sind die Mitglieder der Fokusgruppe zu bestimmen. Vorteilhaft ist es, wenn die Partner der Beobachtungsinterviews der Fokusgruppe angehören. Denn bei ihrer Arbeit sind schließlich die meisten der Benutzungsprobleme aufgetreten, so dass sie auf jeden Fall in der Lage sind, die Problembeschreibung und mögliche Lösungen zu beurteilen. Außerdem vertreten sie in der Regel verschiedene Benutzergruppen, weil dies schon ein Kriterium für die Auswahl der Interviewpartner ist. Sollte dennoch eine wichtige Benutzergruppe nicht repräsentiert sein, können zusätzliche Personen gebeten werden, in der Fokusgruppe mitzuarbeiten. – Einer der Interviewer sollte in der Fokusgruppe die bis dahin dokumentierten Mängel vorstellen und die Diskussionsergebnisse notieren. Bei entsprechender Qualifikation kann er zugleich die Rolle des Moderators über297

11 Usability Care nehmen. – Techniker sollen an der Fokusgruppe nicht teilnehmen. Denn die Arbeit ist dort ganz und gar auf die Ermittlung und Lösung von Benutzungsproblemen ausgerichtet. Kritik an der aktuellen Ausgestaltung der Software soll unbefangen vorgetragen und verhandelt werden können, die Entwicklung des Wünschenswerten noch nicht durch die angenommenen Schranken des Machbaren eingegrenzt werden. Es ist ohnehin eine schwierige Moderationsaufgabe, die Teilnehmer von den Begrenzungen des Gewohnten zu befreien und den Horizont der denkbaren Verbesserungsmöglichkeiten zu erweitern. So besteht die Fokusgruppe aus ungefähr fünf bis zehn Personen. Die Sitzung dauert etwa einen halben bis einen Arbeitstag. Ablauf der Gruppenarbeit

Für den Ablauf der Fokusgruppenarbeit hat sich folgende Tagesordnung bewährt: 1.

Erläuterung der Zielsetzung für die Fokusgruppe;

2.

Vorstellung der Fragebogenergebnisse, Diskussion über Problemschwerpunkte;

3.

Bearbeitung ausgewählter Mängel aus den Beobachtungsinterviews;

4.

Vervollständigung der Mängelliste;

5.

Zusammenfassung und weiteres Vorgehen.

Zunächst werden die Teilnehmer auf die Zielsetzung und den Ablauf der Fokusgruppe eingestimmt. Die Fokusgruppe wird in Beziehung zu den bisherigen und den zukünftigen Projektaktivitäten gesetzt und in ihrer Bedeutung innerhalb des Gesamtverfahrens erläutert. Anschließend werden den Teilnehmern die Hauptergebnisse der Fragebogenerhebung vorgestellt. Wie bewerten die Benutzer die SAP-Software insgesamt? Für welche Arbeitsaufgaben wird die Unterstützung durch die Software besonders gut, für welche besonders schlecht bewertet? Wie schneidet sie hinsichtlich der verschiedenen Ergonomie-Kriterien ab? Welche Arten von Mängeln werden besonders häufig genannt? Und wie fällt das Benutzervotum im Vergleich zu anderen Betrieben aus? Anhand dieser Ergebnisse kann man diskutieren, worin wohl die Hauptursachen für Stärken und Schwächen liegen und welche Organisationsbereiche bzw. Funktionen der Software bei der weiteren Analyse besonderes Augenmerk verdienen. Für den dritten Arbeitsschritt erhalten die Teilnehmer die vom Usability-Experten vorbereitete „Top-20-Liste“ der aus seiner 298

11.2 Ergonomische Ist-Analyse Sicht wichtigsten Benutzungsprobleme. Zum Einstieg wird erläutert, wie diese Liste zustande gekommen ist. Danach werden die in der Liste aufgeführten Beispielfälle der Reihe nach gemeinsam bearbeitet. Der Analyst erläutert das Problem, die Benutzer kommentieren, korrigieren die Darstellung, soweit das notwendig ist, und entwickeln unter der Anleitung des Moderators Vorschläge zur Verbesserung der Software. Für die Illustration ist es sehr vorteilhaft, wenn Bildschirmfotos von den problematischen Funktionen vorbereitet wurden oder wenn während der Sitzung ein Systemzugang mit Projektionsmöglichkeit zur Verfügung steht, an dem die Dialogschritte vorgeführt werden können. Manchmal tragen auch Videosequenzen aus den Beobachtungsinterviews sehr zur Verdeutlichung bei. Man darf sie natürlich nur dann vorführen, wenn die betroffenen Interviewpartner ihre Erlaubnis dazu erteilt haben. Problemgewichtung durch Benutzer

Im Anschluss an die Diskussion bewerten die Teilnehmer den Schweregrad der einzelnen Probleme, indem sie nun ihrerseits eine Einstufung nach der schon zitierten Bewertungsskala zwischen 0 = „kein Problem für die Software-Ergonomie“ und 4 = „sehr großes Problem“ vornehmen. Die Teilnehmer können ihre individuelle Bewertung in ihr Exemplar der „Top-20-Liste“ eintragen. Der Moderator ermittelt dann die Verteilung der Bewertungen zu jedem Problem und visualisiert sie z. B. auf einer Overhead-Folie. Bei kleinen Fokusgruppen kann die gemeinsame Bewertung auch in der Diskussion festgelegt werden. Im vierten Schritt wird die mit der „Top-20-Liste“ getroffene Auswahl überprüft. Es könnte sein, dass der Usability-Analyst Beobachtungen weggelassen hat, die den Benutzern aber besonders wichtig erscheinen, die Benutzer wiederum können auf Probleme aus Aufgabenbereichen hinweisen, die in den Beobachtungsinterviews gar nicht untersucht worden sind, und es mag auch sein, dass Mängel aus der „Top-20-Liste“ zu streichen sind, weil sie sich nach der Diskussion als weniger gravierend darstellen. Zur Strukturierung der Suche nach wichtigen zusätzlichen Benutzungsproblemen eignet sich die in Kapitel 8 vorgestellte Übersicht möglicher software-ergonomischer Problemfelder einer SAP-Software. Die einzelnen Problemfelder werden anhand von Beispielen erläutert, und die Teilnehmer werden aufgefordert, über ähnliche Mängel bei der Erledigung ihrer Arbeitsaufgaben nachzudenken. Die anhand dieses Suchrasters identifizierten Mängel werden ebenfalls dokumentiert und gewichtet. Erste Verbesserungsvorschläge werden notiert.

299

11 Usability Care Kasten 11.3: Auszug aus einer „Top-20-Liste“ wichtiger Benutzungsprobleme (Praxisbeispiel)

300

11.2 Ergonomische Ist-Analyse Zum Ende der Fokusgruppensitzung werden Vereinbarungen über die weitere Vorgehensweise getroffen. Der Usability-Experte sollte die Sicherung der Arbeitsgruppenergebnisse übernehmen. Das heißt, er aktualisiert die „Top-20-Liste“ und legt sie zur Prüfung und Freigabe einem zu bestimmenden Mitglied der Fokusgruppe vor. Die freigegebene Liste erhalten auch die anderen Gruppenmitglieder im Sinne eines Ergebnisprotokolls. Der Usability-Experte sollte die Ergebnisse der Fokusgruppe einschließlich evtl. ergänzter Mängel zusätzlich in das ergonomische Fallregister übernehmen. Außerdem sollte vereinbart werden, wie die Gruppenmitglieder über die weiteren Projektergebnisse, vor allem natürlich über die Behandlung ihrer Vorschläge auf dem Laufenden gehalten werden. Das Hauptprodukt der Fokusgruppenarbeit ist die konsolidierte „Top20-Liste“ wichtiger Verbesserungsvorschläge. Sie wird in der nächsten Projektstufe den IT-Spezialisten zur Kommentierung vorgelegt.

11.2.4

Präsentation der Analyseergebnisse

Rückmeldung an Beteiligte

Wer zur Durchführung der Ergonomie-Analyse beigetragen hat, muss auch über die Ergebnisse informiert werden. Das ist nicht nur ein Gebot der Höflichkeit, sondern motiviert die Beteiligten, sich auch zukünftig für die Verbesserung der Arbeitsmittel und Arbeitsabläufe zu engagieren. Möglicherweise wurde den Teilnehmern etwa der Fragebogenerhebung auch schon vorab eine Rückmeldung in Aussicht gestellt. Die offiziellen Repräsentanten der Auftraggeber, also das Management, und auch die Arbeitnehmervertretung haben selbstverständlich Anspruch auf eine Präsentation der Ergebnisse. Wer wann in welcher Form informiert wird, sollten Sie bei der Planung der Usability Care für den jeweiligen Einzelfall festlegen. Es bietet sich allerdings an, nach der Ist-Analyse den erreichten Zwischenstand bekannt zu geben. Immerhin liegen jetzt Ergebnisse vor, die ein interessantes Bild von der software-ergonomischen Ist-Situation vermitteln können. Dabei wären wenigstens die prägnantesten Auswertungsergebnisse der Fragebogenerhebung darzustellen sowie Art und Anzahl der gesammelten Verbesserungsvorschläge. Als interessierte Adressaten kommen neben Geschäftsführung und Betriebs-/Personalrat die Leiter der Abteilungen in Betracht, in denen das untersuchte Softwaremodul überwiegend genutzt wird, ebenso die IT-Betreuer, betriebliche Arbeits- und Gesundheitsschützer und natürlich die Benutzer selbst. Als Form der Darstellung eignen sich z. B. Infoblätter, Artikel in Hauszeitungen oder im Intranet, 301

11 Usability Care selbstverständlich aber auch Vorträge in Meetings, Abteilungs- oder Betriebsversammlungen. „Tu Gutes und rede darüber!“ ist eine richtige Devise auch für das notwendige Marketing eines Usability-Projektes. An dieser Stelle ist die öffentliche Präsentation der guten Arbeitsergebnisse zugleich eine Verpflichtung zur Fortsetzung der Bemühungen. Die erkannten Verbesserungspotenziale müssen jetzt auch genutzt werden.

11.3

Systemanpassung In der Analysephase wurde eine vermutlich große Menge von Benutzungsproblemen und Verbesserungsvorschlägen zusammengetragen und im ergonomischen Fallregister dokumentiert. Dieses Register umreißt das Arbeitsfeld für die ergonomische Systemanpassung, wobei den Fällen aus der in der Fokusgruppe aufgestellten „Top-20-Liste“ die erste Priorität zukommt.

Abbildung 11.7: Arbeitsschritte bei der Systemanpassung

Die Aufgabe ist klar. Aber wer soll sich damit befassen? Und vor allem: Wie geht das überhaupt? Welche Instrumente stehen dafür zur Verfügung? Es kommen durchaus verschiedene Akteure in Betracht, die Anpassungen an der Software vorzunehmen, und die Aufgabenverteilung hängt wesentlich von den Anpassungswerkzeugen ab.

Da sind zum einen die Benutzer selbst. Es gibt eine beachtliche Anzahl von Einstellungsmöglichkeiten, die den Benutzern zugänglich sind oder gemacht werden können und deren Handhabung auch ohne besondere systemtechnische Kenntnisse möglich ist. Dazu zählen z. B. die Festlegung von Farben und Schriftgrößen, die Definition eines Menüs mit häufig benutzten Funktionen, das Vorbelegen von Datenfeldern, die Einrichtung persönlicher Wertelisten und Einstellungen zum Cursorverhalten. Manche sehr lästigen Benutzungsprobleme lassen sich schon mit diesen Instrumenten beheben.

302

11.3 Systemanpassung

Abbildung 11.8: Verschiedene Akteure bei der Systemanpassung

Vorgehensschritte bei der Systemanpassung

Andere Einstellungsmöglichkeiten sind weniger leicht zu handhaben oder haben eine größere Tragweite, so dass sie eher den SAP-Betreuern offen stehen. Einige solcher Instrumente gehören zum normalen Handwerkszeug von Customizern und Entwicklern. Man denke etwa an die Definition von Eingabefeldern als Muss- bzw. Kannfelder oder an die Bereitstellung neuer Reports. Manch anderen aus der Sicht der Ergonomie interessanten Instrumente, für die Maskengestaltung z. B. das Anlegen von Transaktionsvarianten oder der GUI XT, sind auch den SAP-Betreuern oftmals nicht geläufig. Es hat sich als ratsam erwiesen, sowohl die Benutzer als auch die SAP-Betreuer zum Thema „Ergonomische Einstellungsmöglichkeiten“ zu schulen, damit die Behebung von Benutzungsproblemen nicht etwa an fehlenden Kenntnissen scheitert. Deshalb sind zum Einstieg in die Phase der Systemanpassung ausdrücklich entsprechende Qualifizierungsmaßnahmen vorgesehen: „Tipps & Tricks“ für Benutzer und „Ergonomische Stellschrauben“ für SAPBetreuer. Die Qualifizierung der SAP-Betreuer ist auch insofern von Bedeutung, als sie vor der Umsetzung von Verbesserungsvorschlägen, die nicht offensichtlich trivial sind, eine Aufwandsschätzung abgeben sollen. Dies geschieht bei einem so genannten Technikertermin, der der Auswahl und Freigabe der eigentlichen Eingriffe in die Software vorausgeht.

303

11 Usability Care Ergonomische Mängel, also die Nicht-Passung zwischen Arbeitsaufgaben, SAP-Software und Benutzern, sind natürlich nicht immer nur durch Veränderungen an der Software zu beheben, sondern manchmal eher durch Aufrüstung der Hardware, durch Reorganisationsmaßnahmen, durch Anpassung von Papierformularen oder auch durch fachliche Qualifizierung der Benutzer. Für solche Verbesserungen des Arbeitssystems im weiteren Sinne kommen dann noch weitere Akteure ins Spiel, die ebenfalls für Ergonomiefragen und -gestaltungsmöglichkeiten sensibilisiert werden müssen, z. B. Abteilungs- und Bereichsleiter und Mitarbeiter der Organisationsabteilung. Hier sollten Sie sich allerdings auf die Ansatzpunkte konzentrieren, die die SAP-Software bietet.

11.3.1

Qualifizierung der Benutzer und der SAP-Betreuer

Tipps & Tricks

Ergonomische Tipps und Tricks zu kennen kann für alle Benutzer der SAP-Software nur von Vorteil sein. Eigentlich sollte man dieses Thema als festen Bestandteil in die SAP-Basisschulung integrieren, sozusagen als „Kleines Einmaleins“ der geschickten Systemeinrichtung. Tatsächlich findet das aber leider nur sehr selten statt, wie die Benutzerbefragungen bei Usability-Projekten immer wieder zeigen. Oft datiert die erste SAP-Einführung auch in eine Zeit, in der die damals aktuelle Systemversion etliche der heute verfügbaren Benutzerstellschrauben noch gar nicht anbot. Daher empfiehlt es sich, eine systematische Qualifizierung über benutzerindividuelle Einstellungsmöglichkeiten wenigstens im Rahmen der Usability Care vorzusehen. Immerhin ist die Individualisierbarkeit einer der sieben Grundsätze der Dialoggestaltung nach DIN EN ISO 9241-110, wo es heißt: „Ein Dialog ist individualisierbar, wenn das Dialogsystem Anpassungen an die Erfordernisse der Arbeitsaufgabe sowie an die individuellen Fähigkeiten und Vorlieben des Benutzers zulässt.“ So sollte man alle Benutzer des untersuchten SAP-Moduls in einer etwa halbtägigen Veranstaltung mit den Tipps und Tricks für eine auf die persönlichen Bedürfnisse zugeschnittene Einstellung der Software vertraut machen. Der Kasten 11.4 enthält Themenbeispiele für eine solche Schulung. Die meisten dieser Funktionen wirken nur benutzerspezifisch, und ihre Effekte können leicht wieder zurückgenommen werden. Daher kann man sie sogar an der produktiv gesetzten Software demonstrieren oder ausprobieren.

304

11.3 Systemanpassung Kasten 11.4: Tipps & Tricks-Schulung (Themenbeispiele) SAP Easy Access Pflegen und Organisieren von Favoriten, Nutzung von Transaktionscodes, SAP-Shortcuts etc. Dialogmöglichkeiten in der Anwendung Gültige Werte suchen, Werteliste, Matchcode, Objektmanager, Hilfefunktionen für Eingabefelder etc. Arbeiten mit Reports Hintergrundverarbeitung, Varianten etc. Personalisierung der Anwendung Persönliche Werteliste, Table Controls, benutzereigene Daten, SAP GUI-Optionen, Hilfe-Einstellungen, Arbeiten mit der Zwischenablage, einfache Funktionen des GUI XT etc. Grundprinzipien der SoftwareErgonomie

Zusätzlich zu den konkreten Anpassungsfunktionen der SAPSoftware sollten in das Themenspektrum der Tipps & TricksSchulung auch die Ziele und Grundprinzipien der Software-Ergonomie aufgenommen werden. An positiven und negativen Beispielen kann man die Bedeutung der Prinzipien veranschaulichen und zugleich zeigen, wie weit reichende Anpassungsmöglichkeiten auch ein Standardsystem wie das von SAP bietet. Das steigert die Sensibilität und die Kreativität – man kann auch sagen: die Ansprüche – der Benutzer, die sonst allzu oft geneigt sind, hinderliche Unzulänglichkeiten der Software mit einem gewissen Fatalismus wie unabwendbare Beeinträchtigungen durch höhere Gewalt hinzunehmen. Was die Kenntnisse der SAP-Betreuer im Bereich Software-Ergonomie betrifft, darf man, wie die Erfahrung lehrt, im Regelfall nicht viel mehr voraussetzen als bei den Benutzern. Es kommt hinzu, dass diese Personengruppe häufig auf die „Null-Modifikations-Doktrin“ eingeschworen wurde, die im Interesse vermuteter Kosteneinsparungen jegliche Abweichung vom Standard verbietet, mindestens jedoch rechfertigungsbedürftig macht. Umso dringlicher ist es, den SAP-Betreuern die Nützlichkeit und die Machbarkeit ergonomischer Optimierungsmaßnahmen nahezubringen. Sie sollten tiefergehend als die Benutzer mit den Grundlagen und Normen der Software-Ergonomie vertraut gemacht werden, damit sie deren Beachtung als Teil ihrer Dienstleitung betrachten und z. B. als Entwickler ergänzender Systemfunktionen Usability von vornherein zum unverzichtbaren Designkriterium machen. Auch kleinere Entwicklungsaufgaben können mehr oder weniger benutzerorientiert abgewickelt werden. Auch beim 305

11 Usability Care Entwurf neuer Reporting-Funktionen können Elemente z. B. des Rapid Prototyping nützlich eingesetzt werden. Stellschrauben für Den Schwerpunkt der Schulungseinheit „Stellschrauben für SAPBetreuer“ bilden aber, wie ihre Bezeichnung andeutet, die InstruSAP-Betreuer mente, die die SAP-Software zur ergonomischen Anpassung bietet. Behandelt werden natürlich auch die Tipps und Tricks für Benutzer. Schließlich sind SAP-Betreuer selbst auch Benutzer, und sie sind prädestiniert dafür, den Benutzern aus den Fachbereichen als Ansprechpartner für Fragen zu den individuellen Einstellungsmöglichkeiten zur Verfügung zu stehen. Darüber hinaus aber müssen sie in der Lage sein, Benutzungsprobleme auch durch weitergehende und kompliziertere Systemanpassungen zu beheben. Beispiele von Systemanpassungen, die ergonomisch von besonderer Bedeutung sein können, sind in Kasten 11.5 aufgelistet. Kasten 11.5: Ergonomisch relevante Systemanpassungen durch SAP-Betreuer (Beispiele) •

Ein- bzw. Ausblenden von Feldern

•

Erstellung von Einbildtransaktionen

•

Definition betriebsspezifischer Muss- bzw. Kann-Felder

•

Ändern von Feldnamen

•

Umgruppierung der Felder in Bildschirmmasken

•

Ergänzung unternehmensspezifischer Datenfelder

•

Einbindung betriebsspezifischer Plausibilitätsprüfungen

•

Erstellung von Transaktionsvarianten

•

Erstellung transaktionsspezifischer Drucktasten

•

Gestaltung benutzerindividueller Menüs

•

Erstellung benutzerspezifischer Reports und Auswertungen

•

Einbindung orientierender Grafiken

•

Erstellung benutzerspezifischer Anmeldedialoge

•

Integration von HTML-Dokumenten

•

Anbindung externer Systeme mit automatischer Datenübertragung

Systemtechnische Hilfsmittel und Verfahren, die für die Realisierung der aufgeführten Anpassungen nützlich bzw. erforderlich sind, sollen in der Schulung für SAP-Betreuer behandelt werden. Sie nimmt etwa zwei Tage in Anspruch. 306

11.3 Systemanpassung Anregungen zur inhaltlichen Ausgestaltung von Qualifizierungsmaßnahmen für verschiedene Zielgruppen enthält Kapitel 9 (Abschnitte 9.1.1 und 9.1.2).

11.3.2

Technikertermin Beim Technikertermin kommen zum ersten Mal diejenigen zu Wort, die beschlossene Änderungen an der Software umsetzen müssen. Man könnte meinen, nach dem langen Vorlauf mit Analysen und Ideensammlungen werde es nun aber höchste Zeit, die Usability-Fantasten aus Wolkenkuckucksheim auf den Boden des Machbaren herunterzuführen. Der Sinn dieser späten Einbindung besteht aber gerade darin, die Entfaltung der Verbesserungsvorschläge möglichst lange davor zu bewahren, durch vermeintliche technische Sachzwänge erstickt zu werden. Denn die Benutzer, die zwar Anwendungsexperten, aber oftmals technische Laien sind, lassen sich allzu leicht von der Technik-Expertise der EDVLeute beeindrucken, obwohl diese über die Arbeit in den Fachabteilungen ihrerseits meist nur Laienkenntnisse haben.

Aufwandsschätzung

Die Techniker sollen nun auch nicht eigentlich die Machbarkeit der Verbesserungsvorschläge beurteilen, denn machbar ist letztlich fast alles. Es geht bei dieser Beratung ausschließlich darum, den Aufwand abzuschätzen, der erforderlich wäre, um die Verbesserungswünsche zu realisieren. Was wäre zu tun? Wer könnte das tun? Wie viel Zeit nähme das in Anspruch, und welche Fremdkosten wären ggf. zu veranschlagen? Kommentare der Techniker zum Sinn oder zur Dringlichkeit der gewünschten Veränderungen sind nicht gefragt, sie fließen jedenfalls nicht in das Arbeitsergebnis dieses Projektschritts ein. An der Sitzung sollten als technische Sachverständige ein Customizer, ein Systementwickler und evtl. ein SAP-Betreuer aus den Fachabteilungen teilnehmen, die das untersuchte Softwaremodul hauptsächlich benutzen. Die Ergebnisse der Fokusgruppe können gut von ihrem Moderator präsentiert werden. Er kann auch die Moderation des Technikertermins übernehmen. Die Teilnahme eines weiteren Fokusgruppenmitglieds kann zur Erläuterung von Einzelheiten aus der Benutzerwelt nützlich sein, ist aber nicht unbedingt erforderlich. Wichtig ist, dass die Techniker die ergonomischen Stellschrauben gut genug kennen, um eine realistische Aufwandsschätzung machen zu können. Zur Not wäre ein Experte für ergonomische Stellschrauben zusätzlich hinzuzuziehen. Welche Verbesserungsvorschläge den Technikern vorgelegt werden, entscheidet die Fokusgruppe. Je nachdem, wie viele Ände307

11 Usability Care rungsvorschläge die Fokusgruppe bearbeitet hat, können es alle oder die vielleicht zwölf mit der höchsten Dringlichkeit sein. Erweiterte Vorschlagsliste

Als Ergebnis des Technikertermins liegt die Wunschliste der Benutzer in ergänzter Form vor: Zu jedem Vorschlag ist eine grobe Abschätzung des Umsetzungsaufwandes verzeichnet, die mindestens zwischen den Kategorien „sehr hoher“, „hoher“, „geringer“ und „sehr geringer“ Aufwand unterscheidet, evtl. auch die ausführende Stelle nennt und den geschätzten Arbeitsaufwand in Tagewerken quantifiziert. Diese Angaben werden in zusätzlichen Spalten in das ergonomische Fallregister aufgenommen. Bei Eingriffen mit geringem Aufwand wird es oft so sein, dass ihre Umsetzung von den SAP-Betreuern sofort selbst beschlossen werden kann. Andere Maßnahmen bedürfen der Zustimmung von Budgetverantwortlichen und evtl. auch des Betriebs-/Personalrats. Für sie stellt die ergänzte Vorschlagsliste eine wichtige Entscheidungsvorlage dar, weil zu jedem Vorschlag sowohl die Nützlichkeit für die Alltagspraxis als auch der Realisierungsaufwand und damit die Kosten dargestellt sind. Die Mitglieder der Fokusgruppe erhalten die ergänzte Liste ebenfalls. Sie bekommen auf diese Weise eine Rückmeldung über die Aufwandsschätzungen der Techniker und evtl. schon über Realisierungsentscheidungen.

11.3.3

Technische Änderungen, Dokumentation und Produktivsetzung Dies ist der Arbeitsschritt, in dem Veränderungen an der Software vorgenommen werden, die mit nennenswertem Aufwand verbunden sind oder die erhebliche Tragweite haben. Kleinere Anpassungen, z. B. das Einrichten benutzerspezifischer DefaultWerte, die schnell zu erledigen und jederzeit rückholbar sind, kann man sozusagen nebenbei ausführen, ohne eine förmliche Freigabe zu erwirken. Geht es hingegen um die Bereitstellung zusätzlicher Reports, die Erweiterung von Zugriffsberechtigungen, die Einführung zusätzlicher Datenfelder oder ähnlich bedeutende Eingriffe, so muss man daraus eine förmliche Maßnahme machen, die in einem geregelten Verfahren freigegeben, vollzogen und dokumentiert wird. Für solche Maßnahmen ist dieser Arbeitsschritt vorgesehen. Welche Verfahrensvorschriften zu beachten sind, variiert mit den Rahmenbedingungen im jeweiligen Anwenderbetrieb und hängt u. a. von der Art der Eingriffe ab. Wesentliche funktionale Veränderungen des Systems müssen aber wohl in den meisten Fällen zunächst in einer Testumgebung erprobt, dann dokumentiert

308

11.4 Wirkungskontrolle und schließlich ins Produktivsystem transportiert werden. So ist es in Abbildung 11.8 dargestellt. Rückkopplung zu Benutzern

Für die Usability Care ist die Rückkopplung zu den Benutzern natürlich besonders wichtig. Sie sollen erfahren, dass und wie die gewünschte Veränderung vorgenommen wurde. Unter Umständen ist auch eine Einweisung in die neuen Funktionen notwendig. Soweit Vorschläge nicht oder noch nicht umgesetzt werden konnten, sollten unbedingt die Gründe dafür genannt werden, um diffusen Frustrationen engagierter Benutzer entgegenzuwirken.

Dokumentation als Arbeitsschutzmaßnahme

Außerdem sollte der Vollzug der Maßnahme im ergonomischen Fallregister vermerkt werden. Es wird um die Spalten „Verbesserungsmaßnahmen“, „Verantwortliche Person/Stelle“, „Erledigungsdatum“ ergänzt. Damit halten Sie nicht nur die Agenda der ergonomischen Aufgaben aktuell; Sie führen zugleich den vom Arbeitsschutzgesetz (ArbSchG 1996) verlangten Nachweis über Maßnahmen zum Gesundheitsschutz und erhalten obendrein ein motivierendes Journal über die geleisteten Arbeiten im Dienste der Usability.

11.4

Wirkungskontrolle

Abbildung 11.9: Hauptarbeitsschritte der Wirkungskontrolle

Zum Abschluss der Usability Care soll der Erfolg der ergriffenen Maßnahmen überprüft werden. Haben die vielen Bemühungen die Gebrauchstauglichkeit des Arbeitsmittels SAPSoftware tatsächlich erhöht? Wurden Hindernisse abgebaut? Sind die Benutzer insgesamt zufriedener als zuvor? Oder hat man gar neue Probleme geschaffen? Die Benutzer des behandelten Moduls werden natürlich aufgrund ihrer eigenen Wahrnehmung beurteilen können, ob sich der Aufwand für sie gelohnt hat. Geschäftsleitung, Personalvertretung, Gesundheitsschützer und die Benutzer anderer Module sind aber an einer Gesamtbewertung der Maßnahmen interessiert, die ihnen Anhaltspunkte für die Frage liefert, ob Usability Care-Projekte auch für andere Softwarepakete folgen sollen und wie man sie eventuell modifizieren müss309

11 Usability Care

Abbildung 11.10:

Ablauf der Wirkungskontrolle, optional mit Auswertungsgruppe

te. Im Arbeitsschutzgesetz heißt es in § 3, der Arbeitgeber „hat die Maßnahmen auf ihre Wirksamkeit zu überprüfen und erforderlichenfalls sich ändernden Gegebenheiten anzupassen.“ Wie können Sie das im Falle der Software-Ergonomie tun? Theoretisch könnten Sie die gesamte Ist-Analyse wiederholen und prüfen, ob nun weniger Probleme auftreten als vor der Systemanpassung. Allein wegen des Aufwandes empfiehlt sich jedoch eine Beschränkung auf eine zweite Benutzerumfrage, evtl. ergänzt durch eine Ergebnisanalyse in einer Auswertungsgruppe. Auch so erhalten Sie einen guten Gesamteindruck von der neuen Ist-Situation. Abbildung 11.10 zeigt den Ablauf der Wirkungskontrolle.

11.4.1

Fragebogenerhebung Weil Veränderungen von Abläufen, Masken, Transaktionen und Reports einer gewissen Eingewöhnung bedürfen, sollte die zweite Befragung erst ein bis zwei Monate nach den Systemveränderungen beginnen. Der Fragebogen sollte grundsätzlich dieselben Themen behandeln wie bei der Erstbefragung. Auch die Fragen hierzu sollten gleich lauten, damit die Ergebnisse unmittelbar miteinander verglichen werden können. Sofern wegen be-

310

11.4 Wirkungskontrolle grenzter Aktivitäten im Rahmen der Systemanpassung zu bestimmten Themenbereichen (etwa beim Benutzersupport oder bei Schulungen) keine Veränderungen zu erwarten sind, können Sie diesbezügliche Fragen weglassen. Wegen ihrer zentralen Bedeutung empfehlen wir jedoch, die Fragen nach der ergonomischen Dialog- und Arbeitsgestaltung im Sinne der Teile 110 und 2 von DIN EN ISO 9241 auf jeden Fall noch einmal zu stellen.

Abbildung 11.11: Ausschnitte Wirkungskontrolle

aus

dem

Fragebogen

zur

311

11 Usability Care Manöverkritik

Bei der Umfrage zur Wirkungskontrolle sollten die Benutzer aber auch direkt nach ihrer Bewertung der vollzogenen Veränderungen und – gewissermaßen als Manöverkritik – nach ihrer Meinung über die gewählte Vorgehensweise gefragt werden. So erbitten Sie in zusätzlichen Fragen Einschätzungen über •

die Wirksamkeit und den Nutzen einzelner Maßnahmen (funktionale Änderungen, Qualifizierung),

•

den Projekterfolg insgesamt,

•

verbleibende Verbesserungspotenziale.

Die Abbildung 11.11 enthält einige Beispiele derartiger zusätzlicher Fragen zur Einschätzung des Aufwandes und des Nutzens einzelner Projektbausteine (hier der Fragebogenaktion), zur Veränderung der Arbeit mit SAP und zur Auswirkung des Projektes auf einzelne Aspekte der Arbeit. Wie bei der Erstbefragung sollten möglichst alle Benutzer des untersuchten Moduls einbezogen werden. Nur wenn die Benutzerzahl sehr groß ist, empfiehlt sich sowohl für die Ist-Analyse als auch für die Wirkungskontrolle eine Teilbefragung. Im Interesse besserer Vergleichbarkeit der Ergebnisse sollte der Fragebogen bei der Wirkungskontrolle jedenfalls an dieselbe Personengruppe verteilt werden wie bei der Erstbefragung. Als Zeitvorgabe für den Rücklauf bewährt sich eine Frist von nicht mehr als zwei Wochen. Vorher-NachherVergleiche

312

Bei der anschließenden Auswertung steht natürlich der VorherNachher-Vergleich im Mittelpunkt. Je nach Umfang der Fragebögen können Sie z. B. die Bewertungen im Hinblick auf die verschiedenen Prinzipien für die Dialog- bzw. Arbeitsgestaltung vergleichen. Sie können untersuchen, für welche Arbeitsaufgaben die größten Verbesserungen erzielt wurden, und Sie können die Veränderung bei der Gesamtbewertung im eigenen Betrieb denen aus anderen Betrieben gegenüberstellen. Abbildung 11.12 zeigt die Systembewertungen in einem SAP-Anwenderbetrieb nach Dialogprinzipien. Die Pfeile weisen auf die deutlichsten Verbesserungen hin, die mit einem Punkt gekennzeichneten Prinzipien der Aufgabenangemessenheit und der Fehlertoleranz haben die Benutzer als für sich besonders wichtig eingestuft.

11.4 Wirkungskontrolle

Abbildung 11.12:

11.4.2

Bewertungen der Software vor und nach der ergonomischen Optimierung aus einem SAPAnwenderbetrieb (Beschreibung s. Text)

Auswertungsgruppe Als eine im Vergleich zur Fragebogenerhebung weniger aufwändige Form der Wirkungskontrolle ist auch eine zweite Fokusgruppe denkbar. Hier kann gemeinsam Manöverkritik über die Vorgehensweise geübt werden. Schwerpunkt jedoch wäre die Bewertung der vollzogenen Veränderungen. Anhand des ergonomischen Fallregisters ist nachzuvollziehen, welche Maßnahmen ausgeführt wurden und ob die früheren Benutzungsprobleme nun zufriedenstellend behoben sind. Im Gegensatz zur Fragebogenerhebung sind hier allerdings eher qualitative Ergebnisse zu erwarten, Restkritik und evtl. neue Veränderungsvorschläge, die man den Ergebnissen der Ist-Analyse nicht so einfach gegenüberstellen kann wie die numerischen Qualitätsbewertungen. Das Resultat ist insgesamt weniger plakativ, der Grad der Verbesserung (oder Verschlechterung) schwieriger auszumachen. Als Hauptnachteil ist aber zu bedenken, dass die Zahl der Urteilenden auf relativ wenige Benutzer beschränkt bleibt. Die Gruppe wird ihre Arbeit vermutlich auf dieselben Benutzungsprobleme fokussieren, die sie auch in der Analysephase als besonders wichtig hervorgehoben hat, und die Probleme anderer Benutzer drohen bei der Erfolgsbewertung aus dem Blickfeld zu geraten.

Abschlusspräsentation

Wie auch immer die Wirkungskontrolle durchgeführt wird, das Ergebnis muss natürlich dokumentiert und präsentiert werden. Ähnlich wie bei den Resultaten der Ist-Analyse (vgl. Abschnitt 11.2.4) kommen schriftliche Zusammenfassungen für die hausin313

11 Usability Care ternen Kommunikationsmedien wie Mitarbeiterzeitungen und Intranet in Betracht. Eine Abschlussveranstaltung z. B. im Rahmen einer Abteilungsversammlung bietet die Möglichkeit, die präsentierten Ergebnisse mit allen Beteiligten zu diskutieren und die gemeinsame Arbeit zu würdigen.

11.5

Zusammenfassung und Ausblick Nun haben Sie den ganzen Zyklus der Usability Care durchlaufen. Die Benutzer hatten reichlich Gelegenheit, ihre Probleme und Wünsche zu äußern. Die Meldungen wurden systematisch von praxiserfahrenen Benutzern und von Ergonomie-Experten analysiert. Die technischen Anpassungsmöglichkeiten wurden speziell unter dem Blickwinkel der software-ergonomischen Relevanz gesammelt, den SAP-Betreuern wie auch den Benutzern in Schulungen nahegebracht und extensiv zur Heilung erkannter Mängel eingesetzt. Jetzt ist die SAP-Software ergonomisch. – Ruhigen Gewissens machen Sie einen großen Erledigt-Haken an das Thema Usability und können sich wieder anderen Fragen zuwenden. Oder? Leider verhält es sich mit der Software-Ergonomie ähnlich wie mit dem Aufräumen und Putzen. Man macht sich viel Mühe, ordnet Bücher in den Schrank, alte Zeitungen in den Müll, repariert die defekte Lampe, saugt auch in den Ecken, reinigt Fußböden und putzt Fenster. Das Ergebnis ist deutlich sichtbar, die Familie freut sich über das Auftauchen längst verloren geglaubter Gegenstände, der Besuch ist beeindruckt. Doch der reine Glanz ist nur von kurzer Dauer. Schon am nächsten Morgen kommt die neue Zeitung. Nach einigen Wochen schon muss man wieder ran. Oder ist die Lage schon früher unerträglich geworden?

Usability Care als Routine

314

Das professionelle Management lässt es nicht so weit kommen. Es entwickelt ein Konzept darüber, welche Teile des Gesamtsystems in welcher Frequenz und mit welchen Verfahren überprüft und instandgehalten werden sollen, je kritischer die Komponenten, desto häufiger und gründlicher. Software-ergonomische Untersuchungen sollten an solchen Modulen und an solchen Arbeitsplätzen engmaschig stattfinden, wo der Mensch-MaschineDialog intensiv ist oder wo Benutzungsfehler besonders weitreichende Folgen haben. Man denke z. B. an Call-Center oder an die Steuerung technischer Prozesse. Relativ kurzzyklische Untersuchungen brauchen nicht immer aufwändig zu sein. Vielleicht genügen ein kurzer Benutzerfragebogen im Abstand von sechs bis zwölf Monaten und Beobachtungsinterviews an ausgewählten Arbeitsplätzen alle zwei Jahre. Außerhalb der Routine geben na-

11.5 Zusammenfassung und Ausblick türlich wesentliche Veränderungen bei Organisation und Technik Anlass für eine ergonomische Prüfung. Ein robustes Produktionsunternehmen hat ein durchdachtes Instandhaltungskonzept. Qualitätsbewusste Betriebe sollten ihre ITgestützten Geschäftsprozesse nach einem Usability-Care-Konzept optimieren. Dann findet Usability Care mehr oder weniger kontinuierlich statt, aber in einem systematisierten Organisationsrahmen, erfahrungsgeleitet und mit planbarem Aufwand. Das ist die optimale Lösung. Denn so ganz fertig wird ein Softwaresystem nie. Eine Zusammenfassung von Erfolgsfaktoren und Stolpersteinen für Usability Management und für Usability Care ist Thema des folgenden Kapitels. Reinhard Linz und Bernd Stein

315

12

Erfolgsfaktoren Sie haben in den vorigen Kapiteln die verschiedenen Phasen des Usability Management kennengelernt. In diesem Kapitel liegt der Fokus auf den Praxisbedingungen, unter denen Usability Management in Ihrem Unternehmen erfolgreich wird. Usability ist in unserem Verständnis ein weitreichendes Qualitätskriterium für operative Softwareanwendungssysteme. Es spiegelt dabei nicht nur die wirksame Umsetzung einschlägiger DIN EN ISO-Normen wider (vgl. Kapitel 3), sondern fördert – nicht zuletzt durch den Prozess der Etablierung des Usability Management – betriebswirtschaftliche Erfolgskriterien wie geringe Betriebs- und Änderungskosten und hohe Produktivität der Benutzer durch Akzeptanz und effiziente Nutzung der Anwendung. Nicht zuletzt werden Projekte durch hohe Wirksamkeit sowie durch valide und klare Steuerungsleistungen (relativ) verkürzt. Insofern wundert es nicht, dass niemand die Lanze gegen Usability erhebt und viele der am Entscheidungs- und Einführungsprozess Beteiligten sogar der Auffassung sind, Usability implizit bereits zu berücksichtigen – es also entsprechend unnötig sei, ein spezielles „Usability Management“ zu betreiben.

Usability ist selbstverständlich

Die folgenden Ausführungen wollen dieses verbreitete Urteil der Praktiker aufgreifen und über ihr Verständnis von „Selbstverständlichkeit“ die Praxisbedingungen erfolgreicher SAP-Einführungs- und Reorganisationsprojekte entfalten. Dabei bleibt es nicht aus, dass wir – nach über 15 Jahren Erfahrung in praktischer Prozessbegleitung von SAP-Projekten – immer wieder auf den drastischen Kontrast zwischen Wunsch und Wirklichkeit hinweisen müssen. Wir wollen dabei aber nicht schulmeistern, sondern in aller angebrachten Nüchternheit und Pragmatik die vorhandenen Veränderungspotenziale deutlicher machen.

317

12 Erfolgsfaktoren Dazu betrachten wir im Folgenden die Erfolgsfaktoren: •

Projektplanung;

•

Zielklarheit;

•

Wissen;

•

Kommunikation;

•

Verbindlichkeit.

12.1

Erfolgsfaktor Projektplanung

Planung kostet Zeit

Beginnen wir gleich mit der kostbarsten Ressource eines SAPProjektes – der Zeit! Zwei Grenzbedingungen – Einhaltung des Kostenbudgets und der wohlbegründete Stichtag des Produktivstarts – bilden die Kernvorsätze nahezu aller IT-Projekte. Sie tatsächlich seriös aufzustellen, zu versprechen oder einzufordern setzt bekanntermaßen einen nicht unerheblichen Projektplanungsaufwand nebst einschlägigen Erfahrungen voraus. Doch schon hier – also vor dem eigentlichen Projektstart – wird vielerorts anderen Erwägungen gefolgt als den begründeten Erfahrungswerten eines effizienten Projektmanagements: Politisch gesetzte Budgetobergrenzen, sinnvoll erscheinende, aber unrealistische Produktivstarttermine, Angebotstaktiken von Beratern, Auslassung von Gewerken, die unter Umständen qualitätsentscheidend sind, zu viele parallele Projekte, die die Aktivierung von Ressourcen in den Fachabteilungen versperren etc. Dies sind nur einige – im jeweiligen Einzelfall wohl begründete – Restriktionen für eine realistische Projektplanung.

„Turbo-Effekt“

Um gleich einem verbreiteten Missverständnis entgegenzutreten: Wir plädieren hier nicht für eine Verlängerung von Projekten oder für größere Budgets, im Gegenteil sind wir der begründeten Auffassung, dass ein straffes Usability Management dem Gesamtprojekt Zeit und Kosten einzusparen in der Lage ist. Doch ist dieser „Turbo-Effekt“ nur möglich, wenn dem Projekt eine realistische Grundausstattung zur Verfügung steht. Ansonsten entstehen negative „Dominoeffekte“, die schließlich ein geplantes Usability Management (und nicht nur dieses) blockieren oder sein Potenzial nicht zur Geltung bringen lassen.

318

12.1 Erfolgsfaktor Projektplanung Kasten 12.1: Projektplanung – ein Negativbeispiel aus der Praxis Dauerbaustelle SAP Bei der Projektierung einer neuen, für die Kundenabrechnung relevanten SAP-Anwendung wurden u. a. folgende Aufgaben nicht berücksichtigt: •

Prüfung der Altdatenqualität (Richtigkeit / Formate etc.);

•

Entwicklung der Benutzerprofile / arbeitsorganisatorische Veränderungen;

•

Call-Center-taugliche Funktions- und Maskengestaltung;

•

Information und Beteiligung des Betriebsrates;

•

Dokumentationsverpflichtungen u. a. nach dem Bundesdatenschutzgesetz und den GoDV (Grundsätze ordnungsgemäßer Datenverarbeitung).

Zudem wurde aufgrund des Geschäftsjahres der Produktivstart auf den 1. Januar gelegt und auf dieser Zeitachse die erforderlichen Personalkapazitäten geplant, ohne jedoch darauf zu achten, dass einige Schlüsselpersonen mit zeitweilig 200 % beplant und den betroffenen Fachbereichen zu viele Kapazitäten für die Alltagsbewältigung entzogen werden mussten etc. Da der Vorstand bis in den November hinein auf einer termingerechten Einführung bestand, wurden alle Projektaktivitäten auf das technische Funktionieren ausgerichtet. Der „GAU“ bei der Altdatenübernahme führte zur Streckung des Projektes auf 1 ¼ Jahre und Parallelbetrieb – doch nur, um alle weiteren Mängel den ohnehin schon überforderten Fachabteilungen und Mitarbeitern im „Kontinuierlichen Verbesserungsprozess“ aufzuhalsen. Fast wäre der Produktivstart (nur Neudaten) auch noch durch eine „einstweilige Verfügung“ des Betriebsrates gekippt. Weitgehende Zugeständnisse des Vorstandes verhinderten dies in letzter Sekunde. Kurz: Eine Dauerbaustelle war geboren und das noch mit erheblichen Geburtswehen – die hätten vermieden werden können. Ansteigende „Stresslinie“

Naturgemäß hat jedes Projekt eine ansteigende „Stresslinie“, die in der Regel bei IT- bzw. SAP-Projekten nach dem Produktivstart wieder abflacht. Einen entgegengesetzten Verlauf nimmt dann die Bereitschaft (vom Projektleiter bis zum Mitarbeiter), für das

319

12 Erfolgsfaktoren

Abbildung 12.1:

Zur Entwicklung (negativer) Ressourcen in IT-Projekten (nach Blume, 1999)

Projekt Arbeitspakete anzufassen bzw. neu in die Agenda mit aufzunehmen, die nicht unmittelbar etwas mit dem funktionalen Kern der Software zu tun haben: Anderes – auch Usability – ist „nice to have“! Entsprechend ist bei einem SAP-Projekt der Einwand leider nicht unüblich, man könne sich während der Realisierungsphase kein Prototyping oder Forderungen / Wünsche von Mitarbeitern, Arbeitnehmervertretungen oder Fachabteilungen mehr „antun“: Nichts hören, nichts sehen ... ist die Überlebensstrategie der Überlasteten. Deshalb werden alle, die etwas anderes wollen oder nur das „Unvermeidliche“ vorhersagen, wie früher schon Laokoon (s Abbildung 12.1) bestraft. Man hat uns als Changemanager deshalb nicht nur einmal die „Schlangen“ an den Hals gewünscht. Kosten sparen

320

Doch es hilft nichts: Schon am Anfang die „Naturgesetze“ zu verdrängen oder mit gezücktem Rotstift erforderliche Aufgaben und Kapazitäten zu streichen, bedeutet letztlich, Kosten zu steigern und die Beteiligten zu überfordern. Positiv gewendet, spart eine realistische Projektplanung teure Nacharbeitskosten (auch wenn sie nicht mehr auf diesen Kostenträger gebucht werden), garantiert termingerechte Leistungen und bietet die Chance, Qualität abzuliefern: z. B. gute Usability!

12.2 Erfolgsfaktor Zielklarheit Eine seriöse Projektplanung bedarf zudem einer abgestimmten Interessens- und Auftragslage (s. Abbildung 12.2).

Abbildung 12.2: Kontrakte

Das Kontraktgeflecht von SAP-Projekten u. a. für das Usability Management

Dazu empfiehlt es sich, zwischen Geschäftsleitung, Betriebs-/Personalrat und den Dienstleistern klare schriftliche Absprachen zu treffen, die den Kunden nicht nur mit einbeziehen, sondern auch seine Zufriedenheit und Effizienz zum Ziel haben. Solche Kontrakte (Erfolgsfaktor Verbindlichkeit, s. Abschnitt 12.5) können dann auch die Projektsteuerung im Aufgaben- und Interessendschungel des Unternehmens aufs Trefflichste unterstützen. Doch kontraktfähig ist in der Regel nur derjenige, der auch weiß, wohin er will ...

12.2

Erfolgsfaktor Zielklarheit

Vorteile nicht nur für Mitarbeiter ...

Selbstverständlich müssen bei einem SAP-Einführungsprojekt die Interessen der Mitarbeiter geachtet werden, ob es nun um Jobsicherheit, um Datenschutz, um Qualifizierung oder um anderes geht. Das Ziel Usability jedoch allein oder in erster Linie unter dem Gesichtspunkt der Mitarbeiterinteressen zu begreifen – oder womöglich sogar für eine (verzichtbare?) „Wohltätigkeit“ zu halten – wäre verkürzt und verfehlt.

... sondern auch für Unternehmen

Natürlich haben auch die Benutzer ganz persönliche Vorteile von einer gut gestalteten und betriebenen SAP-Software, die ihrem Wohlbefinden und somit ihrer Gesundheit dient, aber Usability 321

12 Erfolgsfaktoren kommt vor allem auch dem Unternehmen selbst zugute: das Ziel ist die Steigerung der Produktivität, der Effizienz und der (Fehler-)Robustheit der SAP-Software. Erfolgreiches Usability Management garantiert:

Ungenutztes Potenzial

•

schlanke und stabile, weil von den Mitarbeitern verstandene und beherrschte Prozesse;

•

sichere Datenstrukturen, da sowohl die Eingabe als auch die Prüfung der Daten fehlerrobust gestaltet ist;

•

Beschleunigung der Einzelverrichtungen, da unnötiges Suchen und Bewegen in Masken und darüber hinaus vermieden wird;

•

Beschleunigung der gesamten Aufgabenerledigung, da SAPAnwendungen und ihr technisches sowie organisatorisches Umfeld aufgabenangemessen aufeinander abgestimmt sind.

Warum also wird Usability Management trotz dieser offensichtlichen Vorteile nur selten ernsthaft betrieben und wie ein Jo-Jo immer wieder in die Ecke der „nice to have“-Aktivitäten, zuweilen mit „Goldrand“ für die Interessenvertretung, gespielt? Ein wahrlich komplexes Problem, das sich in erster Näherung durch die klassische Rollenkonstellation der zentralen Projektakteure erhellen lässt.

Berater

Da gibt es den SAP-Berater, der schon viele Installationen und Kleinkriege um Modifikationen, Berechtigungen und Funktionalitäten durchgestanden hat: „Wir haben es gegen alle Unbilden immer noch hinbekommen“. Und genau diese entscheidende Funktion, externe Kompetenz und Parteiname für das Ganze, wird vom Berater auch erwartet. Jedoch kann man als „Feldherr ohne Truppen“ oder „Lotse“ im Dschungel der SAP-Technik und Betriebsinteressen nur selten einen Blick für das Detail, den konkreten Benutzer, die Usability entwickeln.

Entscheidungsgremien

Auch die Entscheidungsgremien (z. B. der Steuerkreis) betrachten die Angelegenheit gewissermaßen von der Kirchturmspitze oder vom Feldherrenhügel aus, gepaart mit dem (Kauf-)Paradigma: Die neue Software ist gut, die alte Organisation keineswegs, also merzt die „neue Ordnung“ quasi automatisch die Unzulänglichkeiten und Fehler der Vergangenheit aus. Auch hier wird der Benutzer, der Fachbereich, der Kunde einmal mehr nur zum Objekt der Maßnahme.

Projektmitarbeiter Da gibt es nun die externen und internen Projektmitarbeiter, die in den Grenzen ihrer Kenntnisse und der betrieblichen Besonderheiten 322

12.2 Erfolgsfaktor Zielklarheit ihr Bestes geben, um eine lauffähige und für die Benutzer handhabbare SAP-Software herzustellen. Usability steht somit implizit auf ihrem Aufgabenzettel, und sie definieren auch de facto, was das ist. Dies erklärt auch, warum spätere Kritik aus dem Benutzerkreis sehr emotionale Abwehrreaktionen der „Customizer“ hervorruft. „Wir haben doch alles gemacht und bedacht ...“, „Man kann denen auch nichts recht machen“ oder „... wir können doch nichts dafür, dass SAP so starr und umständlich ist ...“. Doch vor diesen üblichen Dilemma nach dem Produktivstart steht die Überforderung dieser Projektrolle, ohne Kenntnis der Ziele und Methoden von Usability und der entsprechenden SAPStellschrauben ein akzeptables System gestalten zu müssen. Leider ändert auch ein gut geschnittenes „Key-User-Konzept“ daran wenig: Denn spätestens in der Detaillierungsphase sind diese „Sprösslinge der Fachbereichspraxis“ ausgewachsene „SAP-Rosen“, die, mit berechtigtem Stolz über ihre Kenntnisse, sich zu den Anforderungen ihrer alten Kolleginnen und Kollegen stachelbewehrt auf Distanz halten. Praxisschock

Key-User beispielsweise als Prototyper einzusetzen ist genauso Zeitverschwendung, wie ihnen ohne eingehende Schulung oder Vermittlung von Designkriterien die Maskengestaltung zu überlassen. Auch sie sind – nur auf neue Art – betriebsblind geworden, freilich ohne es zu merken und mit entsprechend großem Enttäuschungspotenzial, wenn der „Praxisschock“ die alte Kollegenschaft nach dem Produktivstart wieder zusammenführt.

Arbeitnehmervertretung

Betriebs- und Personalräte schließlich – sofern überhaupt engagiert in der Frage Gesundheitsschutz im Zusammenhang mit EDV-Systemen – belegen Usability zu Recht mit dem Arbeitsschutzgesetz und den Ergonomiezielen aus dem Anhang der Bildschirmarbeitsverordnung. So erscheint Usability als Arbeitgeberpflicht und muss sogar im Rahmen der „Gefährdungsbeurteilung“ (§§ 5 und 6 ArbSchG), die ja bekanntlich auch die so genannten „psychischen (Fehl-)Belastungen“ (u. a. gemäß DIN EN ISO 10075) ermitteln muss, überprüft werden. Was so ein einklagbares Arbeitnehmerrecht geworden ist, kann im klassischen Umkehrschluss der Arbeitgeberseite wohl kaum zielführend für den Primärprozess einer SAP-Einführung sein: „Wenn’s denn sein muss, dann aber mit wenig Aufwand ... und übrigens, wie kann man überhaupt Usability objektiv messen, das bleibt doch alles im subjektiven Belieben der Benutzer ... 323

12 Erfolgsfaktoren eine Anspruchsspirale ... Keiner wird zufrieden sein, weil ja jeder anders ist!“ Kurz: Der Entscheidungselite im Unternehmen könnte suggeriert werden, Usability sei ein unkalkulierbarer Spielball von Interessen und gehöre damit aus dem Kalkül „seriöser“ Projektziele herausrangiert. SAP-Benutzer

Und die späteren SAP-Benutzer – also die Anwender der abzulösenden EDV-Systeme – tun in diesem Spiel ihr Übriges: Sie nehmen die neue Software hin und verbuchen diesen Angriff auf ihren gesunden Menschenverstand und ihr Wohlbefinden mit eingeschränkter Leistungs- und Innovationsbereitschaft oder versuchen sich über Umwegproduktion aus der Misere zu retten (s. Abbildung 12.3, Kasten 12.2). Was schließlich motivationale und was technische Effizienzbremsen sind, will dann sowieso niemand mehr auseinander halten. Interessenbedingt liefern diese Konflikte und die fehlende Effizienz die erforderliche Energie für Folgeprojekte, die dann aber in der Regel nicht an den Ursachen ansetzen, sondern nur das „Elend“ in neuen Kleidern zu verstecken suchen.

Abbildung 12.3:

324

Reaktionen auf schlechtes Customizing von ERP-Systemen (Blume & Carlberg, 2001)

12.2 Erfolgsfaktor Zielklarheit Kasten 12.2: Zielklarheit – ein Beispiel aus der Praxis Konsequent am System vorbei Für einen komplexen Montagebetrieb wurde SAP-MM / PM und PP eingeführt. Zur Unterstützung der „neuen Ordnung“ wurden geschlossene Lager eingerichtet und der Lagerbestand auf einen auftragsgerechten Stand zurückgefahren. Die einzelnen Montageschritte mussten der SAP-Software zurückgemeldet werden, sonst konnte keine Lagerentnahme erfolgen. Da die Software in ihrer den gesamten Prozess abbildenden Mechanik „immer Recht“ hatte, die physisch reale Welt aber zuweilen „nicht mitspielte“, blieb den verantwortungsvollen Mitarbeitern nichts anderes übrig, als entweder mit fehlendem Material weiter zu arbeiten, das „System zu überlisten“, z. B. über „Pseudoaufträge“ oder „Verlustbuchungen“, oder schlicht über das Aufbrechen der Lager an das erforderliche Material zu gelangen. Unabhängig davon, dass die gelegentliche SAPArbeit der Montage- und Instandhaltungsarbeiter über ergonomisch gestaltete Masken oder Barcodeleser hätte erleichtert werden können, legten die weiterhin sichtbaren Klebezettel an den SAP-Stationen und im Werkstattbüro beredt Zeugnis darüber ab, dass ein neues Projekt gestartet werden müsste, um den SAP-Best-way in den Montageablauf integrieren zu können: Das Projekt „Prozessoptimierung und Usability Management“ war angesagt! Man steht sich ge- Diese klassischen Projektkonstellationen versperren also auf jeder genseitig auf den Akteursebene und im zielkonstituierenden Prozess die systematische Sicht auf die Aufgabe „Usability“ bzw. auf die unternehmeriFüßen sche Kernaufgabe, effiziente und robuste Prozesse zu installieren. Eigentlich ließen sich solche Probleme schon mit einem einfachen Blick auf Erfahrungen mit gescheiterten oder suboptimalen früheren Projekten erkennen und vermeiden. Dass dies meist nicht geschieht, liegt nicht zuletzt daran, dass jede Akteursgruppe ihre eigene Bewältigungsstrategie finden und legitimieren muss, es also in der Regel keine übergreifende und gemeinsame Aufarbeitung der Projektvergangenheit gibt („Jeder leckt still seine eigenen Wunden“). Dieser systemischen Tendenz zur Wiederholung von Fehlern entsprechen fatalerweise die vom Hersteller und in best-practice-Berichten kolportierten Möglichkeiten wie „enjoy-SAP“, „Business-Blueprints“ und das Verbotsschild „Modifikationskosten“, weil sie suggerieren, dass es beim nächsten Mal praktisch automatisch besser gehen wird.

325

12 Erfolgsfaktoren Erfahrungswissen nutzen

Hier nun setzt der Erfolgsfaktor „Zielklarheit“ an, denn dort, wo – von wem auch immer initiiert – das Wissen über die Faktoren des Scheiterns in der Organisation verankert wird, wurden auch die neuen Ziele für alle und in allen Akteursgruppen auf Konsistenz, Klarheit, Akzeptanz und Umsetzbarkeit überprüft. Dazu bedarf es aber nicht nur eines Anlasses, eines Treibers (z. B. der Geschäftsführung) und eines organisierten Prozesses, sondern vor allem auch der Fähigkeit der Organisation, die Wissens- und Lernpotenziale aller beteiligten Akteure zu aktivieren.

Vorurteile und Mythen abbauen

Denn „Zielklarheit“ bedeutet vor allem Lernbereitschaft zum Abbau von Mythen und Vorurteilen gegenüber der eigenen Organisation, aber auch dem Produkt SAP.

12.3

Erfolgsfaktor Wissen Kann man unklaren Zielvorstellungen noch mit dem flotten Satz „Denn sie wissen nicht, was sie tun“ begegnen und empfehlen, den einzelnen Akteuren ihren jeweiligen „Tunnelblick“ abzugewöhnen, so ist der Faktor Wissen von einer anderen Konsistenz.

Usability lernen reicht nicht

An der Oberfläche geht es darum, dass das fachliche und methodische Wissen um Usability in den wenigsten Unternehmen – aber auch Unternehmensberatungen – vorhanden ist. Es geht also um Qualifizierung, Training und Erfahrungsbildung, und dies ausnahmsweise nicht nur auf Seiten der Benutzer, sondern auf allen Ebenen der Projektakteure. Dieses Wissensdefizit über die DIN EN ISO 9241-11 hinaus abzubauen – dieses Buch möchte dazu ja einige Anregungen geben –, ist aber nur die eine Seite dieses Erfolgsfaktors.

Qualifizierung und Beteiligung

Die Wissensdefizite sind nur das Spiegelbild der verbreiteten Praxis und Auffassung, dass die Investition in das System schon genügt, um alle Funktionalitäten für die Organisation zu aktivieren. Auch Kostenvergleiche von SAP-Einführungsprozessen mit und ohne Qualifizierung (vgl. Abbildung 12.4) schrecken nicht davor ab, beispielsweise mehr als 1.000 SAP PM-User nur über das Schneeballsystem der Key-User in SAP einzuweisen. Die andere Seite der Medaille ist das Erfahrungswissen, also die Nutzung der bisherigen fachlichen Erfahrungen der Organisation und der Benutzer. Nur wenn beide Wissensarten sich positiv ergänzen und stützen, wird ein beteiligungsorientiertes Usability Management möglich. Die Organisation muss wissen (wollen), dass Beteiligung zu einem positiven Wachstumsprozess für alle Beteiligten führen kann, die Mitarbeiter müssen über ihre Ar-

326

12.3 Erfolgsfaktor Wissen beitsplatzexpertenschaft hinaus wissen, dass sie nicht „ihr Herz auf den Tisch hungriger Leute legen“, mit anderen Worten, sie ernst, aber nicht ausgenommen werden.

Abbildung 12.4: Die Mischung macht’s

Kostenfolgen in Abhängigkeit von Qualifizierung (nach Scherer & Schaffner 2003, S. 36)

Aber erst das Fachwissen (SAP, Usability etc.) und das Erfahrungswissen der Benutzer zusammen liefern die Mischung, die zum Erfolg führt. Der Wissensmix bleibt aber so lange „unkritisch“, bis auch die Entscheiderebene weiß, dass jenseits kostentreibender Modifikationen die SAP-Software flexibler und auch unter Usability-Aspekten gestaltbarer ist, als das Einführungsparadigma „im Standard bleiben“ suggeriert. Kasten 12.3: Wissen – ein Beispiel aus der Praxis Sich überzeugen lassen Nach einer Einführung eines ISU-SAP-Pakets bei einem Energieversorger wurde vom Betriebsrat die Karte „Verbesserung der Software-Ergonomie“ gespielt. Im Rahmen der sachlichen Diskussion über das Thema vertraten die Geschäftsleitung und die SAP-Verantwortlichen den Standpunkt, dass Änderungen an der Benutzerschnittstelle, insbesondere die Individualisierung, weder sachlich möglich noch politisch erwünscht seien: Der ohnehin schon komplexe Abstimmungsprozess und die mühsam erreichten Standards machten jedes neue Zielsegment zu einer Gefahr für die technisch fixierte Stabilität. Dies vor allem auch deshalb, da man ja aus Erfahrung wisse, dass jeder Benutzer etwas anderes wolle und ein entsprechendes Nach327

12 Erfolgsfaktoren geben zu einem infiniten Regress in Richtung einer Unzufriedenheit auf hohem Niveau führen werde. Da sich keiner so recht weder mit den hier relevanten technischen Stellschrauben der SAP-Software noch fachlich in Usability auskannte, ordneten die unterschiedlichen Vorurteile und Erfahrungen die Argumentationslinien, die sich schließlich in einem salomonischen Kompromiss tangential annäherten: „Wir untersuchen die Auswirkungen der SAP-Schulung hinsichtlich der Befähigung zu effizientem Arbeiten mit ISU.“ Das Ergebnis der Befragung zeigte, dass die Schulungen zwar positiv bewertet wurden, leider aber nicht ihren primären Zweck erreicht hatten, und die so erforderlich gewordene „Selbstaneignung des Systems“ zugleich zur Decouvrierung von zahlreichen strukturellen und handlungsbezogenen Schwächen führte. Dieses für die Verantwortlichen höchst erstaunliche Ergebnis öffnete die Tür für eine neue – nun mit mehr Expertise ausgestattete – Diskussion über Usability und Benutzerbeteiligung.

12.4

Erfolgsfaktor Kommunikation

Information ist nicht genug

Wissensdefiziten beispielsweise zu Ergonomie-Stellschrauben in der SAP-Software oder operationalisierten Usability-Kriterien kann durch Information Abhilfe geschaffen werden: Man informiert den Steuerkreis, man informiert den Benutzer mittels Mails und Hauszeitung über die Erfolge des Projektes, die Meilensteine und das bessere Arbeiten in der Zukunft. Gewiss, „Projektmarketing“ ist wichtig und Information ist der erste Schritt, aber für viele Projektakteure bleibt es auch der Einzige. Die Schulung vermittelt Information, und über den Projektstart wird man auch irgendwie in Kenntnis gesetzt ... Zur Entwicklung von Usability aber reicht das allein nicht aus. Kommunikation ist gefordert, also Austausch, miteinander reden, kritisieren, zuhören, sich reiben und Meinung vertreten, zusammengefasst: ernsthafte Beteiligung von Mitarbeitern. Das muss man dürfen, das muss man können und das muss man wollen, wenn es Sinn haben und positive Effekte bringen soll. Eine formulargestützte „Meckerecke“ reicht dafür nicht aus.

Schon zur Planung eines Prototypings von Kernfunktionalitäten Usability heißt, die Benutzer ernst bedarf es eines Kommunikationsprozesses mit den Prototypern z. B. über die Abläufe und Aufgabenabgrenzungen entlang ihrer zu nehmen Vorerfahrungen. Auch das Resultat des Tests (vgl. Kapitel 8) – wenn auch in Checklisten und Formularen mit Kreuzchen ver328

12.4 Erfolgsfaktor Kommunikation ewigt – bedarf der Kommunikation über Wichtigkeit, über Lösungsideen und ihrer Kollateralrisiken, und dies nicht nur mit Benutzern, sondern vor allem auch mit den Entscheidungsträgern. Kommunikation ist also zugleich Beteiligung und Ernstnehmen. Deshalb ist die Methodik des Usability Management und der Usability Care kommunikativ und beteiligend ausgelegt. Kasten 12.4: Kommunikation – ein Beispiel aus der Praxis Belastungen zum Thema machen Ein Call-Center-Dienstleister für einen Energieverkäufer hatte im Rahmen einer Gefährdungsbeurteilung massive Mängel in der von seinem Auftraggeber zur Verfügung gestellten SAPAbrechnungs- und Verbraucherverwaltungssoftware aufgedeckt: Umständlichkeiten beim Aufsuchen von Kundenverbrauchsdaten (Maskenvielfalt), unzureichende Unterstützung beim Stammdatenänderungsdienst, unzumutbar überladene Masken sowie funktionale, aufgabenunangemessene „Macken“ veranlassten den Dienstleister, mit seinem Auftraggeber und dem SAP-Betreiber zu sprechen. Er stieß auf großes Unverständnis, da ja eine gerade durchgeführte Mitarbeiterbefragung eine große Zufriedenheit der eigenen SAP-Benutzer zu Tage gefördert hatte. Darüber hinaus wies die Expertise der technischen SAP-Betreibergesellschaft darauf hin, dass man ohnehin nichts oder, wenn überhaupt, nur kostspielig etwas ändern könne. In dieser Sackgasse angelangt, übernahmen nun die Mitarbeiter des Call-Centers selbst die Initiative und begannen mit den Mitarbeitern des Auftraggebers über ihre SAP-Probleme zu reden, fanden viel positives Echo bzw. ähnliche Belastungen vor und spielten diese Erfahrungen beidseitig auf die Ebene der Entscheidungsträger zurück, mit dem Erfolg, dass nun auch beim Auftraggeber eine Usability-Analyse durchgeführt wird. Spielregeln vereinbaren

Und damit das Ganze nicht mit dem Satz ausklingt: „Schön, dass wir mal darüber gesprochen haben“, bedarf es bestimmter Kommunikationsrituale und Spielregeln, die eine erfolgreiche und aufwandsangemessene Usability-Produktion strukturieren, also ein Usability Management.

An Kommunikation sparen?

Dazu gehört beispielsweise auch die gute Sitte, getroffene Entscheidungen (wenn z. B ein Mitarbeitervorschlag nicht umgesetzt wird) nicht nur zu verkünden, sondern auch vor denen zu begründen, die sich am Entstehungsprozess der Idee und der Entscheidung beteiligt haben. Doch Kommunikation bedeutet auch 329

12 Erfolgsfaktoren zunächst mehr Aufwand: Mehr Menschen reden offiziell und zielgerichtet miteinander, lösen Probleme, beurteilen Lösungen, engagieren sich ... Verkünden scheint da einfacher und schneller – nur sind die Resultate in der Regel aufwändiger, werden z. B. nachträgliche Verbesserungen notwendig oder stellen sich Arbeitssysteme als ineffizient heraus, mit den bekannten Auswirkungen auf den Motivationshaushalt der Beschäftigten. Es bleibt also nur die Entscheidung, wo man sparen will.

12.5

Erfolgsfaktor Verbindlichkeit Alles, was evident vernünftig erscheint, scheint zugleich auch selbstverständlich. Wieso also stellen wir das Selbstverständlichste einer formalen Organisation – die Verbindlichkeit – als besonderen Erfolgsfaktor heraus? Hierfür müssen wir noch einmal auf die schon eingangs erwähnte relative Unvorhersehbarkeit von SAP-Projekten zurückkommen. Wenn der Produktivstart heranrückt und sich beispielsweise herausstellt, dass die (Alt-)Daten aus formalen oder qualitativen Gründen nicht ohne weiteres übernommen werden können, müssen Kapazitäten umgeleitet und die Prioritäten neu bestimmt werden. Dabei fallen dann z. B. Prototyping-Termine aus, oder Maßnahmen im Bereich Datenschutz, Security (z. B. das Berechtigungskonzept) werden auf unbestimmt verschoben, und das Projekt regrediert auf das technisch-funktionale Niveau des reinen Funktionierens.

Gemeinsam neue Prioritäten setzen

Verbindlichkeit im Sinne eines Erfolgsfaktors bedeutet nun nicht, gegen alle Unwägbarkeiten des Projektes – quasi als einzige Konstante – das Usability Management „durchzuziehen“. Vielmehr geht es darum, dass trotz verschobener Prioritäten, Zeitdruck und technischer Probleme die vereinbarten Aktivitäten zur Optimierung der Mensch-SAP-Nahtstelle nicht gänzlich untergehen, sondern planvoll, ggf. modifiziert und umterminiert, durchgeführt werden. Das kann im Einzelfall sogar bedeuten, dass unter bestimmten Umständen ein systematisches Usability-Projekt erst nach dem Produktivstart als Usability Care (s. Kapitel 11) durchgeführt werden kann. Das wäre zwar nicht optimal, aber besser als gar nichts. Für diese Art von Verbindlichkeit haben sich projektbezogene Kontrakte für die oben skizzierte Akteurskonstellation (s. o., Abschnitte 12.1 und 12.2) sehr bewährt.

330

12.5 Erfolgsfaktor Verbindlichkeit Kasten 12.5: Verbindlichkeit – ein Beispiel aus der Praxis Nicht nur konsequent geplant Die SAP-Neueinführung einer „Classic-Konfiguration“ bei einem Retail-Filialisten wurde von SAP-Beratern der SAP AG unterstützt. Sie förderten von Anfang an die Einbeziehung des Betriebsrates und thematisierten darüber hinaus Aufgabenbereiche wie Sicherheit, Datenschutz und Software-Ergonomie. Für diesen Part empfahlen sie ein auf diese Fragen spezialisiertes Beratungsunternehmen. Von allen Beteiligten (Vorstand, Betriebsrat und die Fachbereiche) wurde eine ergänzende Aufgabenliste entwickelt und verabschiedet, die Usability und Datenschutz beinhaltete, darüber hinaus aber auch die Entwicklung einer „Betriebsvereinbarung zum Betrieb und zur kontinuierlichen Verbesserung des Systems“ als Aufgabe im Projektplan verankerte. Da über den von allen anerkannten erweiterten Projektplan ein Mitglied des Unternehmensvorstandes und der Betriebsrat gemeinsam wachten, konnte sich der sonst übliche „Verbindlichkeitsschwund“ nicht festsetzen. Für die Berater und die Fachbereiche war diese klare Orientierung insofern hilfreich, als sie gezwungen waren, sich abzeichnende Engpässe frühzeitig zur Abstimmung zu bringen, und so entsprechend neue Prioritäten auch auf Top-Ebene einvernehmlich getragen werden konnten. In diesen Kontrakten, z. B. Dienst- oder Betriebsvereinbarungen, sind vor allem die qualitätsorientierten und extrafunktionalen Anforderungen an das zu erstellende System zu formulieren sowie die Aktivitäten (Methoden, Instrumente) aufzulisten, die geeignet sind, diese Ziele / Anforderungen zu erreichen. Vor allem ist zu vereinbaren, wie die Qualität dieser Projektleistungen nachgewiesen werden soll (vgl. u. a. Blume & Carlberg, 2003). Das Zusammenspiel der Erfolgsfaktoren ist entscheidend

Wie das obige Praxisbeispiel einer erfolgreichen SAP-Einführung zeigt, müssen alle Erfolgsfaktoren zusammenspielen, sich ergänzen und aufeinander aufbauen. Aber ohne eine klare und dauerhafte Einwirkung der Entscheidungsträger – Vorstand, Geschäftsleitung, Arbeitnehmervertretung – auf das Projekt wird sich Usability Management in der Regel nur schwerlich entwickeln und behaupten können. Die Topebene nimmt diese nachhaltige Orientierungsfunktion nur wahr, wenn sie selbst überzeugt ist. Und dafür bedarf es wiederum Wissen, Kommunikation, Ziele, Verbindlichkeiten und vor allem engagierter Menschen auf allen operativen Ebenen des Projektes. 331

12 Erfolgsfaktoren

12.6

Zusammenfassung und Ausblick Je stärker eine SAP-Software vom Anspruch und ihrer Architektur her die spezifischen Fähigkeiten, Orientierungen und Entwicklungspotenziale einer Organisation unterstützt, also nicht wie ein festes Korsett Entwicklungen hemmt, sondern fördert, umso mehr bedarf es eines Usability Management als (kontinuierlichen) Anpassungs- und Verbesserungsprozesses. Organisationale Funktionalität und benutzerbezogene Usability sind somit die zwei Seiten der Erfolgsmedaille. So leicht es scheint, diese zu gewinnen, so schwer ist es in Wahrheit, die Organisation und die Projektakteure entsprechend zu orientieren und zu verpflichten. In diesem Kapitel haben wir die Erfolgsfaktoren Projektplanung, Zielklarheit, Wissen, Kommunikation und Verbindlichkeit hervorgehoben und damit mögliche Stolperstellen im Projekt gekennzeichnet, die es zu bearbeiten gilt. Unserer Erfahrung nach sind diese Erfolgsfaktoren hoch wirksam und helfen, die Verantwortung, die jede SAP nutzende Organisation für die Funktionalität der Software wie für die Gesundheit ihrer Mitarbeiter übernimmt, als integrierte Aufgabe zu begreifen und in die Hand zu nehmen. Die komplementäre Verantwortung, also die des Herstellers von SAP-Software, wird im folgenden Kapitel Thema sein. Andreas Blume

332

13

User-Centered Design-Prozess der SAP AG In den vorherigen Kapiteln haben Sie erfahren, welche Schritte Sie unternehmen können, um die Gebrauchstauglichkeit der von Ihnen einzusetzenden Software zu sichern. Sie haben dabei die Unternehmensperspektive kennengelernt. Im letzten Kapitel unseres Buches stellen wir das Thema „Usability“ aus der Sicht des Herstellers, der SAP AG, dar. In diesem Kapitel nennen wir einführend die Herausforderungen, die sich bei der Entwicklung von betrieblicher Standardsoftware stellen, und gehen auf den Unterschied zwischen Gebrauchstauglichkeit und Benutzbarkeit ein. Ihnen soll deutlich gemacht werden, dass ein Hersteller nur die Benutzbarkeit seiner Software sichern kann. Den Kern dieses Kapitels bildet die Darstellung von SAP User-Centered Design, des standardisierten Designprozesses der SAP AG. Dieser Prozess soll helfen, die Benutzbarkeit der SAP-Software zu gewährleisten, um Produkte herzustellen, die „vor Ort“ optimal an Kunden- und Nutzerbedürfnisse angepasst werden und so gebrauchstauglich gemacht werden können. Wir stellen die Phasen dieses Prozesses vor und beschreiben, was konkret in ihnen geschieht. Zum Abschluss gehen wir auf weitere Prozess- und Produktstandards der SAP AG ein, durch die allgemeine Standards eingehalten und um firmeneigene Standards ergänzt werden können.

13.1

Herausforderungen an die SAP AG Zuerst möchten wir auf zwei Herausforderungen eingehen, vor denen die SAP AG als Softwarehersteller prinzipiell steht. Die erste folgt aus dem Grundanliegen der SAP AG, Standard-Unternehmenssoftware anzubieten. Standardsoftware bedeutet, dass Software nicht individuell auf einen bestimmten Kunden zugeschnitten ist – hier spräche man von Individualsoftware. Vielmehr möchte die SAP AG mit einer – sehr flexiblen – Softwarelösung Unternehmen aus verschiedensten Branchen und aus unterschiedlichen Regionen, Ländern und Kontinenten bedienen. Für die Gestaltung von Benutzungsoberflächen (User Interface Design) erweist sich dieses Anliegen in der täglichen Praxis im333

13 User-Centered Design-Prozess der SAP AG mer wieder als „gordischer Knoten“, den es zu lösen gilt. Warum das so ist, deuten wir in Kasten 13.1 an, der ein persönliches Erlebnis aus der Praxis eines User Interface-Designers der SAP AG schildert. Kasten 13.1: Praxisbeispiel aus der SAP-Entwicklung Wie viele Felder sind wirklich nötig? Während eines Beratungsprojektes stand ein User InterfaceDesigner der SAP AG vor der Aufgabe, eine Bildschirmmaske zu vereinfachen, um das Arbeiten mit ihr effizienter zu gestalten. Schnell fand er heraus, dass von den etwa 40 Eingabefeldern in einer typischen Arbeitssituation nur etwa fünf benötigt wurden. Deshalb schlug er dem Entwicklungsteam vor, alle nicht benötigten Felder auf der Maske wegzulassen. Das Team versprach, die Maske drastisch zu vereinfachen. Vorher wollten die Teammitglieder jedoch noch einmal die vorhandenen Felder nach Wichtigkeit ordnen, damit nicht versehentlich unverzichtbare Felder von der Maske entfernt würden. Am Ende des Prozesses hatten von den gut 40 Feldern etwa 20 die Priorität 1 erhalten – und durften damit auf keinen Fall fehlen. Und noch genügend weitere Felder erhielten Priorität 2 – und waren damit eigentlich auch nicht verzichtbar. Was war hier geschehen? Das Team hatte es sprichwörtlich allen recht machen wollen und es am Ende niemanden recht gemacht. Einerseits blieben noch immer so viele Felder übrig, dass sich die meisten Benutzer nach wie vor nicht in dem „Dschungel“ zurechtfinden würden. Andererseits würden bestimmte Kunden trotz allem Felder vermissen, die sie unbedingt benötigten. Die Hersteller von Standardsoftware stehen also vor der Aufgabe, Lösungen anzubieten, die sowohl die unterschiedlichen Bedürfnisse eines breiten Kundenspektrums abdecken als auch so individuell auf den jeweiligen Kunden abstimmbar sind, dass Benutzer vor Ort ihre Aufgaben effizient erledigen können. Die zweite Herausforderung an die SAP AG ergibt sich aus dem Unterschied Kunde – Benutzer Umstand, dass eine so umfangreiche Geschäftssoftware wie das SAP-System – anders als ein Konsumenten-Produkt – nicht von derselben Person verwendet wird, die sie kauft. Wir müssen vielmehr zwischen Kunden und Benutzern unterscheiden. Warum ist diese Unterscheidung im Hinblick auf die Benutzbarkeit von Software wichtig? 334

13.1 Herausforderungen an die SAP AG Funktionsumfang Bei der Kaufentscheidung steht häufig der Funktionsumfang im Vordergrund und weniger die Benutzbarkeit. Das ist aus der Sicht der Kunden verständlich, denn sie erwerben die SAP-Software zu dem Zweck, in ihrer Firma Arbeitsabläufe effizienter zu gestalten (Workflow). Anpassung an die Benutzer interessiert dagegen, wie gut die Software an die spezifischen Aufgaben, die sie an ihrem Arbeitsplatz erledigen müsArbeitsaufgaben sen, angepasst ist (Task Flow). Nur wenn sie diese effektiv und effizient bewältigen können, also ihre Ziele schnell erreichen können, empfinden sie Zufriedenheit bei ihrer Arbeit (User Satisfaction). Die Blickwinkel von Kunden und Benutzern sind also keineswegs von vornherein identisch, obwohl ihre Interessen, im Gesamtzusammenhang betrachtet, nahe beieinander liegen. Dies verdeutlichen wir in Kasten 13.2 an einem Beispiel. Kasten 13.2: Benutzerinteressen und Kundeninteressen Verschiedene Interessen – verschiedene Sichtweisen Stellen Sie sich vor, dass Kunden und Benutzer die Funktionalität einer Software gewissermaßen aus unterschiedlichem Abstand betrachten: Kunden schauen „von weitem“ auf die Software und versuchen so, sich einen Überblick über den Funktionsumfang zu verschaffen. Benutzer betrachten die Software dagegen „mit der Lupe“ und achten auf die Details der Bedienung. Nehmen wir einmal an, ein Kunde führt eine neue Software ein, um seinen Personalbestand zu verwalten. Zunächst wird er sich den Umfang der Funktionen dieser Software anschauen und prüfen, ob alle seine Bedürfnisse damit abgedeckt werden können. Ist es z. B. möglich, alle Formen von Arbeitsverträgen, Schichtplänen und Zusatzleistungen mit der neuen Software abzuwickeln? Der Sachbearbeiter vor Ort interessiert sich dagegen für Situationen, die bei seiner täglichen Arbeit auftreten. Kann er flexibel auf bestimmte Anforderungen reagieren, ohne dass ihn die Software zu „Verrenkungen“ zwingt? Kann er Doppeleingaben vermeiden? Wie schnell kann er seine Arbeit mit der neuen Software erledigen, z. B. im Vergleich mit der bisher verwendeten Software oder seiner bisherigen Arbeitsweise?

335

13 User-Centered Design-Prozess der SAP AG Wie dem Dilemma begegnen?

Wie kann ein Softwarehersteller wie die SAP AG diesem Dilemma begegnen? Die SAP AG muss eine Gratwanderung zwischen den Gegenpolen Komplexität und Vereinfachung unternehmen: Zu große Komplexität bedeutet, dass die benötigte Funktionalität zwar vorhanden, aber nur schwer zu erreichen und zu handhaben ist. Zu stark vereinfacht wird dagegen z. B., wenn eine benötigte Funktion bereits beim Design oder während des Entwicklungsprozesses weggelassen wird, weil Kundenbedürfnisse unzureichend analysiert oder die Anforderungen an die Software aus den Augen verloren wurden. Die SAP AG muss also ihre Software einerseits mit einem ausreichenden Funktionsumfang ausstatten, um ein breites Spektrum von Kunden und Benutzern bedienen zu können. Andererseits muss sie genügend Flexibilität, also „Stellschrauben“, vorsehen, damit Anwendungen optimal auf die Bedürfnisse einzelner Kunden und Benutzer zugeschnitten werden können. Zum Beispiel muss sie erlauben, nicht benötigte Funktionen oder Felder auszublenden. Nur diese Kombination macht es möglich, alle Beteiligten zufrieden zu stellen.

13.2

Benutzbarkeit im Vergleich zu Gebrauchstauglichkeit

Benutzbarkeit vs. Gebrauchstauglichkeit

Wie Sie gesehen haben, kann die SAP AG als Anbieter von Standardsoftware nicht jedem Kunden eine von vornherein optimal auf seine Bedürfnisse angepasste Lösung zur Verfügung stellen. Sie kann aber darauf achten, dass die von ihr angebotene Software bestimmten allgemeinen Kriterien an die Bedienbarkeit genügt. Es ist deshalb für die nachfolgenden Ausführungen hilfreich, zwischen der Benutzbarkeit und der Gebrauchstauglichkeit von Software zu unterscheiden, gerade weil der Unterschied zwischen beiden Begriffen nicht auf Anhieb erkennbar sein mag.

Benutzbarkeit

Die Benutzbarkeit von Software kann bereits von einem Softwarehersteller berücksichtigt werden, indem z. B. die Software so gestaltet wird, dass in der Standardauslieferung typische Benutzer und Abläufe unterstützt werden und eine unternehmensspezifische Anpassung der Software durch „Stellschrauben“ ermöglicht wird. Des Weiteren muss ein Hersteller auch kontextunabhängige Anforderungen, wie etwa die geeignete Verwendung von Farben, Schriftgrößen sowie den Einsatz von Oberflächenelementen, die für sich genommen benutzbar sind, erfüllen. Solche allgemeinen Anforderungen haben Sie bereits in Kapitel 3 kennengelernt.

Gebrauchstauglichkeit

Die Gebrauchstauglichkeit von Software kann nur im Kontext der Nutzung erfasst werden, also direkt vor Ort am Arbeitsplatz

336

13.3 Prinzipien des User-Centered Design eines Benutzers. Die SAP AG kann nur die Benutzbarkeit der ausgelieferten Software sicherstellen und die Gebrauchstauglichkeit durch die Analyse von möglichen Nutzungskontexten und entsprechende Anpassungsmöglichkeiten vorbereiten. User-Centered Design

Um die Benutzbarkeit ihrer Software sicherzustellen, hat die SAP AG den User-Centered Design-Prozess (UCD; auf Deutsch: benutzerzentrierter Designprozess) eingeführt. Dieser Prozess beinhaltet z. B. die Analyse von Benutzern und Arbeitsabläufen. In den folgenden Abschnitten stellen wir den UCD-Prozess zunächst im Überblick und dann näher vor. Mit der Sicherstellung der Gebrauchstauglichkeit beschäftigen sich die Kapitel 4 bis 12, die ein Vorgehensmodell zum Usability Management im Unternehmen vorstellen.

13.3

Prinzipien des User-Centered Design User-Centered Design (UCD) ist ein Ansatz für die Entwicklung von Software oder Produkten im Allgemeinen, der den Fokus auf den Benutzer legt. Sein Motto lautet: Das Produkt soll auf den Benutzer passen, er soll sich nicht an das Produkt anpassen müssen. Unter User-Centered Design fasst man eine Anzahl von Techniken, Prozessen und Methoden zusammen, die auf den Benutzer ausgerichtet sind und über den gesamten Lebenszyklus einer Software hinweg angewendet werden.

Die UCDPrinzipien

Die ursprünglich von John D. Gould und Clayton Lewis (1985) formulierten drei Grundprinzipien des User-Centered Designs lauten: 1.

Früher Fokus auf Benutzer und Aufgaben: Bedürfnisse von Benutzern werden systematisch und strukturiert erfasst.

2.

Die Nutzung einer Software wird empirisch erfasst, mit Fokus auf leichter Erlernbarkeit und effektivem und fehlerfreiem Gebrauch.

3.

Iteratives Design: Anforderungen werden wiederholt erfasst, während das Produkt gestaltet, verändert und mit Benutzern geprüft wird.

Die SAP AG hat die oben genannten Prinzipien leicht abgewandelt, um sie für den eigenen UCD-Prozess „griffiger“ zu machen:

337

13 User-Centered Design-Prozess der SAP AG SAPs UCD-Prinzi- 1. pien 2.

Fokus auf „echte“ Benutzer Validierung der User Interface-Anforderungen und der Designs

3.

Iteration von User Interfaces

4.

„Ganzheitliche“ User Experience

Im Folgenden stellen wir diese Prinzipien näher vor.

13.3.1

Fokus auf „echte“ Benutzer Unter „Fokus auf echte Benutzer“ versteht die SAP AG nicht nur die frühe Einbindung von repräsentativen Benutzern, sondern auch deren kontinuierliche Beteiligung über den gesamten Design- und Entwicklungszyklus hinweg. Das gegenteilige Prinzip wäre, „Stellvertreter“ oder „Experten“ einzusetzen, die für die Benutzer sprechen.

Gründe für die Erhebung von Daten

Um die Probleme und Bedürfnisse der Benutzer verstehen zu können, ist es nötig, umfangreiche Daten über sie zu erheben, wie z. B.: •

ihre Eigenschaften, beispielsweise ihre Ausbildung, Fähigkeiten und Verantwortlichkeiten;

•

ihre Ziele, Aufgaben und Aktivitäten;

•

typische Nutzungsszenarien (Use Cases);

•

die Verwendung weiterer Software und Arbeitsmittel am Arbeitsplatz;

•

das organisatorische und soziale Umfeld;

•

Arbeitsabläufe im organisatorischen und sozialen Arbeitsumfeld.

Die Grundregel für die Datenerhebung ist: Je besser die Daten, desto besser das Design, oder genauer: desto besser passt das Design auf die Bedürfnisse der Benutzer.

13.3.2

Validierung der User Interface-Anforderungen und der Designs Es genügt nicht, Daten einmal zu erheben oder gar von älteren Designprojekten zu übernehmen und dann auf diesem Stand stehen zu bleiben. Sowohl das Design als auch die Anforderungen müssen immer wieder auf ihre Gültigkeit hin überprüft werden. Zu leicht kann sich ein Design in die falsche Richtung entwickeln und von der ursprünglichen Absicht entfernen; auch die Anforderungen können sich verlagern, wenn sich die Rahmenbedingungen verändern.

338

13.3 Prinzipien des User-Centered Design Aufgaben von Benutzertests

Low- und HighFidelityPrototypen

Die SAP AG hat deshalb im UCD-Prozess fest verankert, Benutzer bei der Bearbeitung von Aufgaben und anderen Aktivitäten zu beobachten, ihre Leistung zu messen und zusammen mit ihrem Feedback aufzuzeichnen – und zwar über die gesamte Design- und Entwicklungsphase hinweg. Hierzu gehören: •

Überprüfung (Validierung) der Benutzerprofile und -anforderungen;

•

Überprüfung (Validierung) der Nutzungsszenarien;

•

Identifizieren von Usability-Problemen mit Hilfe von Lowund High-Fidelity-Prototypen;

•

Vergleiche der Produkt-Usability durch standardisierte Usability-Tests, z. B. mit vorherigen Produktversionen.

Low-Fidelity-Prototypen sind Prototypen, die einen ersten Eindruck vom zu erwartenden Funktionsumfang einer Anwendung vermitteln. Papierprototypen werden hierfür am häufigsten eingesetzt; Kasten 13.3 nennt einige ihrer Vorteile. High-FidelityPrototypen ähneln der zukünftigen Anwendung (auch im Aussehen) und verfügen häufig bereits über eine gewisse Dynamik, mit der sich Bedienungsschritte nachbilden lassen. Solche Prototypen werden im Falle von Web-Anwendungen gern mit HTML erstellt und durch Skripte mit „Leben“ (Dynamik) versehen. Kasten 13.3: Papierprototypen als Beispiel für Low-FidelityPrototypen Vorteile und Aufbau von Papierprototypen Der „Usability-Guru“ Jared Spool propagiert seit Jahren die Methode der Papierprototypen (Paper Prototyping). Jeder User Interface-Designer wird im Laufe seines Berufslebens eigene Techniken für Papierprototypen entwickeln. Entscheidend ist, dass dabei die Kernvorteile dieser Methode nicht verloren gehen. Papierprototypen lassen sich leicht abändern und erlauben deshalb schnelle Design-Iterationen, in die das Feedback von Benutzern einfließt. Da für Änderungen keine technischen Kenntnisse notwendig sind, können sich Benutzer sogar aktiv am Gestaltungsprozess beteiligen und den Prototypen umgestalten. Der vorläufige Charakter, den Papierprototypen vermitteln, nimmt Benutzern die Scheu, Änderungen vorzuschlagen. Bei „fertig“ aussehenden High-Fidelity-Prototypen haben sie oft Hemmungen, dies zu tun. Papierprototypen verleiten Benutzer auch weniger dazu, sich von Äußerlichkeiten

339

13 User-Centered Design-Prozess der SAP AG

Abbildung 13.1: Papierprototyp (Beispiel) ablenken zu lassen und nur diese anzusprechen („Das Blau gefällt mir nicht“). Abbildung 13.1 zeigt den Papierprototypen einer Anwendung für das persönliche Informationsmanagement. Alle Einzelteile sind auf eine große, kräftige Pappe geheftet, die das Bildschirmfenster darstellen soll. Im Beispiel sind links Tasten für verschiedene Funktionen vorgesehen, rechts finden sich Bereiche für einen Kalender, für eine Aufgabenübersicht und für Kontaktadressen. Tasten sind als einfache Klebezettel ausgeführt, die von Hand mit Filzstift beschriftet wurden. Die Bereiche rechts daneben bestehen jeweils aus einem großen Zettel, auf den weitere Zettel aufgeklebt sind, z. B. um Tabellenspalten darzustellen. So lassen sich die Bereiche als Ganzes, aber auch Tabellenspalten oder Funktionstasten leicht umpositionieren. Auch andere Elemente des Prototypen sind so angelegt und unterstützen damit schnelle Änderungen durch Testpersonen oder Tester. Vermissen Testpersonen beispielsweise eine Funktion oder eine Tabellenspalte, so beschriften sie einfach einen Zettel in entsprechender Farbe und fügen diesen in den Prototypen ein.

340

13.3 Prinzipien des User-Centered Design

13.3.3

Iteration von User Interfaces Der User-Centered Designprozess ist iterativ ausgerichtet: Designs werden anhand von Prototypen immer wieder mit Benutzern überprüft und anschließend verbessert.

Ablauf der DesignIterationen

Den Ablauf der Iterationen bei Design, Prototypen-Entwicklung und Entwicklung von User Interfaces im UCD-Prozess kann man sich folgendermaßen vorstellen: •

Erste Benutzertests erfolgen mit Papierprototypen. Das Feedback der Benutzer steuert den nächsten Designschritt. Schritt für Schritt passen sich die Prototypen auf diese Weise immer besser den Benutzerbedürfnissen an.

•

Die User Interface-Prototypen werden schrittweise um Funktionen erweitert und damit der Zielanwendung zunehmend ähnlicher; sie wandeln sich im Laufe der Entwicklung von Low-Fidelity- zu High-Fidelity-Prototypen.

•

Die Ergebnisse der Usability-Tests nach der Implementation der Anwendung fließen in die Anforderungsanalysen für nachfolgende Releases ein.

13.3.4

Ganzheitliche User Experience

Was umfasst Ganzheitlichkeit?

Die SAP AG hat den Begriff „ganzheitliche User Experience“ in ihr Konzept des User-Centered Design-Prozesses aufgenommen. „User Experience“ (Benutzererleben) bezieht sich darauf, wie Benutzer den Umgang mit einer Software erleben. „Ganzheitlich“ bedeutet in diesem Zusammenhang den Einschluss von Aktivitäten, die den gesamten Lebenszyklus einer Anwendung überdecken, wie: •

Installation und Aktivierung;

•

Änderung, Customizing und Personalisierung;

•

Wartung und Problembehandlung;

•

und schließlich Deinstallation bzw. Deaktivierung.

In Kasten 13.4 zeigen wir, dass Anpassungen einer Software an Benutzerbedürfnisse zu verschiedenen Zeitpunkten und mit unterschiedlicher Reichweite erfolgen können. Stichworte dazu sind „Customizing“ und „Personalisierung“.

341

13 User-Centered Design-Prozess der SAP AG Kasten 13.4: Unterschied Customizing – Personalisierung Customizing Unter Customizing versteht man Anpassungen, die für alle Benutzer in gleicher Weise vorgenommen werden. Beispielswiese kann in einem Unternehmen der Bestellprozess vom Standardprozess, wie die SAP AG ihn vorgesehen hat, abweichen. Deshalb kann es erforderlich sein, einige zusätzliche Felder auf der Maske anzubieten. Dagegen werden vielleicht einige im Standard angebotene Felder nicht benötigt und sollen ausgeblendet werden, um die Erfassung zu beschleunigen. Diese Anpassungen können während der Einführungsphase erfolgen, aber auch später noch durch den Systemadministrator. Personalisierung Personalisierung bezeichnet dagegen benutzerspezifische Anpassungen. Zum Beispiel kann es die Arbeit beschleunigen, wenn Felder bereits mit feststehenden Werten vorbelegt sind. Solche Vorgaben sind typischerweise für jeden Benutzer verschieden. Selbst wenn Benutzer eine ähnliche Arbeit machen, können sich Vorgaben unterscheiden, etwa weil sie an verschiedenen Firmenstandorten arbeiten und Adressdaten unterschiedlich vorbelegt werden müssen. Effekte ganzheitlicher User Experience

Von einer ganzheitlichen User Experience erhofft sich die SAP AG Effekte, die sich sowohl für die Kunden als auch für die Benutzer positiv auswirken. Aus der Sicht von Kunden ist zu erwarten, dass eine solche Software •

einfach zu installieren, zu konfigurieren und in eine bestehende Arbeitsumgebung zu integrieren ist;

•

einfach zu warten ist;

•

nur minimales Training erfordert;

•

Benutzer (schnell) produktiv werden lässt;

•

Einzelpersonen und Arbeitsgruppen in ihren Bedürfnissen und Arbeitsprozessen unterstützt.

Positive Auswirkungen für die Benutzer sind, dass die Software

342

•

so ist und sich so verhält, wie sie es erwarten;

•

ihre bestehenden Arbeitspraktiken unterstützt;

•

Informationen eindeutig und konsistent darstellt;

•

positive Erfahrungen im Umgang mit ihr auslöst.

13.4 Was passiert konkret im UCD? Eine ganzheitliche User Experience senkt also nicht nur Kosten, z. B. für Training und Wartung, sondern eröffnet auch Zuwachspotenziale, indem sie die Produktivität und die Motivation der Benutzer erhöht.

13.4

Was passiert konkret im UCD? Bisher haben wir die Elemente des SAP UCD-Prozesses nur sehr allgemein angesprochen und uns mit dem Hinweis begnügt, dass für diesen Prozess ein breites Spektrum an Methoden zur Verfügung steht. Im Folgenden stellen wir die Phasen und Methoden vor, die im Rahmen des Prozesses eingesetzt werden: •

Phase 1: Den Benutzer verstehen;

•

Phase 2: Die Interaktionsarchitektur definieren;

•

Phase 3: Das User Interface gestalten.

13.4.1

Phase 1: Den Benutzer verstehen

Aufgaben der Analysephase

Der SAP UCD-Prozess beginnt mit einer Analysephase, die zum Ziel hat, Kunden und Benutzer und ihre jeweiligen Bedürfnisse zu verstehen. Die dazu nötigen Schritte sind: •

Feedback von Kunden und Benutzern durch Feldforschung, Fokusgruppen und Interviews einholen;

•

Benutzer bei der Ausübung ihrer Arbeit an ihrem Arbeitsplatz beobachten;

•

Kunden befragen, z. B. welche Funktionen für die einzusetzende Software gewünscht werden oder welche Merkmale sie haben sollte.

Zur Analyse gehört auch, bestehende Anwendungen zu untersuchen, z. B. vorherige Versionen einer Anwendung. Mögliche Analyseaspekte sind deren Funktionalität, Aufgaben, Arbeitsflüsse, verwendete Terminologie oder auch Datenanforderungen. Kundenbesuche

In Kasten 13.5 schildern wir als ein Beispiel für die Analysephase den Besuch bei einem Kunden. Kasten 13.5: Besuch beim Kunden Den Benutzer verstehen Eine Aufgabe von Kundenbesuchen (Site Visit) ist es, Benutzer direkt am Arbeitsplatz bei der Ausübung ihrer Arbeit zu beobachten. Oft genug zeigt sich, dass sie eine Software ganz anders verwenden, als deren Entwickler dies vorgesehen hatten. 343

13 User-Centered Design-Prozess der SAP AG Oder sie nutzen Teile des Funktionsumfanges nicht oder nur bruchstückhaft. Hier kann nach den Gründen gefragt werden. Die User Interface-Designer betrachten neben der Arbeit mit der Anwendung auch das Arbeitsumfeld der Benutzer. Aufmerksamkeit verdienen z. B. Hilfen, mit denen Benutzer Schwächen der Anwendung ausgleichen, etwa dass sie Informationen oder Zwischenergebnisse auf Zettel notieren. Lange Laufwege zu Druckern oder Kopierern, Anrufe bei Kollegen, um benötigte Informationen oder Hilfe bei Problemen zu erhalten, sind Hinweise auf Verbesserungsmöglichkeiten, die oft über die Anwendung selbst hinausgehen.

Abbildung 13.2: Kundenbesuch (Beispiel)

13.4.2

Phase 2: Die Interaktionsarchitektur definieren

Use Cases helfen beim Schritt zum Design

Der nächste Schritt geht von den Daten aus, die in der Analysephase erhoben wurden. Er hat zum Ziel, zunächst die globale Struktur der Anwendung zu entwerfen und dann Details der Benutzerinteraktion herauszuarbeiten. Um den Schritt von den Daten, also den Anforderungen der Kunden und Benutzer, zum Design der Benutzungsoberfläche systematisch zu vollziehen, setzt SAP UCD Nutzungsszenarien (Use Cases) ein. Diese beschreiben den Umgang des Benutzers mit dem System in unterschiedlicher Detaillierung. Use Cases können sowohl in Form kurzer Sätze als auch in Tabellenform niedergeschrieben werden; SAP UCD orientiert sich hier an der Darstellung von Alistair Cockburn (2001). Vorgegangen wird dabei wie folgt: Zunächst wird mit dem „globalen“ Use Case beschrieben, welche Aufgaben eine

344

13.4 Was passiert konkret im UCD? Anwendung hat und wie ihre Ziele und Teilziele organisiert sind. Falls erforderlich, können Flussdiagramme (Task Flow Diagrams) gezeichnet werden, um den Aufgabenfluss zu veranschaulichen. Anschließend werden für die einzelnen Teilaufgaben und -ziele weitere Use Cases beschrieben, die bei Bedarf weiter verfeinert werden können. Zum Schluss werden die Daten aus allen Uses Cases in einer Matrix zusammengestellt (s. Kasten 13.7). Beispiel für einen Use Case

Kasten 13.6 zeigt ein Anwendungsbeispiel für einen Use Case in Tabellenform. Zum leichteren Verständnis wurde eine typische Situation an einem Geldautomaten ausgewählt. Kasten 13.6: Use Case in Tabellenform (Beispiel) Use Case 2: Den Geldautomaten wieder auffüllen Benutzer-Interaktion

Daten

Wichtigster Erfolgsfall

•

Geldmenge im Automaten;

1.

Ein Bankangestellter wird per E-Mail benachrichtigt, dass der Geldautomat leer ist.

•

In der Bank verfügbare Geldmenge für den Transfer in den Automaten;

•

2.

Er prüft, ob Geld verfügbar ist, um den Automaten wieder zu befüllen.

Geldmenge, die von der Bank zum Automaten transferiert wurde.

3.

Er gibt den benötigten Betrag in der Banksoftware ein.

4.

Der Angestellte bestätigt beim Abheben des Geldes mehrere Sicherheitsabfragen.

5.

Er entnimmt der Kasse der Bank das Bargeld.

6.

Er öffnet den Geldautomaten.

7.

Er füllt das Bargeld in den Automaten.

345

13 User-Centered Design-Prozess der SAP AG Benutzer-Interaktion

Daten

Alternative Interaktion bei Erfolg 1a. Der Bankangestellte erhält die Nachricht als SMS auf seinem Handy 1b. Bankangestellte handelt aufgrund einer früheren Benachrichtigung, die besagt, dass der Automat nur noch wenig Geld enthält. Fehlschläge 1a. Es müssen redundante Nachrichten gesendet werden; der Bankangestellte könnte nicht verfügbar sein. 8a. Der Selbsttest könnte fehlschlagen, was darauf hinweisen würde, dass tatsächlich nicht Geld, sondern eine Reparatur nötig wäre (s. Reparatur-Use Case).

Beispiel für eine Datenmatrix

346

Kasten 13.7 deutet an, wie die Matrix mit Daten aus allen Uses Cases einer Geldautomaten-Anwendung aussehen kann. Hierin erscheinen auch die Daten aus dem Use Case 2 „Geldautomaten wieder auffüllen“ der in Kasten 13.6 dargestellt ist.

13.4 Was passiert konkret im UCD? Kasten 13.7: Datenmatrix (Beispiel) Das folgende Beispiel zeigt die Datenmatrix aller Use Cases für den Geldautomaten. Bezeichnung Daten

der

Beschreibung Daten

der

Use Cases

PIN-Nummer

Geheimer Kode, der für den Zugang zum Konto eines Kunden benötigt wird

1. Geld abheben X. Geld einzahlen X. Geld übertragen X. Kontostand ansehen

Verfügbares Geld (Konto)

Auf dem Konto befindliches Geld (verbunden mit Bankkarte und PINNummer)

1. Geld abheben X. Geld übertragen X. Kontostand ansehen

Verfügbares Geld (Geldautomat)

Gesamtes im Automaten verfügbares Bargeld, das an Kunden ausgezahlt werden kann

2. Geldautomaten wieder auffüllen X. Bericht mit Übersicht über die Aktivitäten des Geldautomaten ansehen

Verfügbares Geld (Bank)

Gesamtes in der Bank verfügbares Bargeld für die Versorgung von Geldautomaten

2. Geldautomaten wieder auffüllen

Bewegtes Geld (Bank)

Geldmenge, die von der Bank abgehoben und in den Geldautomaten gefüllt wurde

2. Geldautomaten wieder auffüllen

etc.

Alle anderen UseCase-Daten

Am Ende dieser Phase liegen die globale Struktur der Anwendung und der grundsätzliche Umgang mit ihr weitgehend fest. Der iterative Ansatz des UCD-Prozesses kann allerdings immer wieder Änderungen auch grundlegender Eigenschaften einer Anwendung mit sich bringen.

347

13 User-Centered Design-Prozess der SAP AG

13.4.3

Phase 3: Design des User Interface

Was zeichnet Low-Fidelity-Prototypen aus?

Die dritte Phase des SAP UCD-Prozesses widmet sich dem „eigentlichen“ Design einer Anwendung. An ihrem Beginn erstellen User Interface-Designer für die Anwendung einen Low-FidelityPrototypen der Benutzungsoberfläche. Bei diesen ersten Prototypen liegt der Fokus auf Konzepten, Metaphern und Designalternativen – weniger auf dem Umgang (der Interaktion) mit der Anwendung. Deshalb werden sie typischerweise mit flexiblen Medien erstellt, wie z. B. Papier und Bleistift, Zetteln und Haftnotizen (vgl. Kasten 13.3 und Kasten 13.8), oder als so genannte „Wireframes“ (einfache elektronische Prototypen in „Kastenform“). Kasten 13.8: Design des User Interface (Beispiel) Papierprototypen im Einsatz Papierprototypen haben vielfältige Anwendungen im UCDProzess. Erste Prototypen können im Designteam auf der Basis eines Gruppenprozesses entstehen, z. B. nach einer Brainstorming-Sitzung, in der eine erste Vision einer Anwendung skizziert wurde. Low-Fidelity-Prototypen werden mit dem Ziel eingesetzt, möglichst viele alternative Designs zu erzeugen und dann den Designspielraum so weit einzuengen, dass zu einem späteren Zeitpunkt High-Fidelity-Prototypen gebaut werden können. Ein guter Start ist beispielsweise, wenn sich die Mitglieder eines Entwicklungsteams paarweise zusammensetzen, um einen Papierprototypen zu erstellen. Anschließend stellen die Zweiergruppen einander ihre Designs vor und kritisieren sie. Mit dem konsolidierten Ergebnis, wiederum in der Form eines Papierprototyps, können User Interface-Designer erste Tests mit Benutzern vornehmen. Bei diesen Tests lässt sich das Prinzip der „schnellen Iterationen“ anwenden: Nach jedem Benutzertest wird der Prototyp den neuen Erkenntnissen angepasst und entsprechend verbessert. Dies ist, wie wir schon beschrieben haben, mit Papierprototypen besonders leicht und schnell durchzuführen. Low-Fidelity-Prototypen treiben in erster Linie den Gestaltungsprozess voran und sollen nicht bereits ein endgültiges Design vorschreiben. Das ist die Aufgabe von High-FidelityPrototypen.

348

13.4 Was passiert konkret im UCD?

Abbildung 13.3: User Interface-Designer und Test-Benutzer gestalten gemeinsam den Papierprototypen einer Anwendung Das Designteam evaluiert die Prototypen mit repräsentativen Benutzern, arbeitet deren Feedback in die Prototypen ein und verbessert sie. Dies wird so lange wiederholt, bis der Prototyp eine ausreichende Stabilität und Qualität erreicht hat. High-FidelityPrototypen

Nun erst ist es sinnvoll, mit der Ausgestaltung von Details zu beginnen und High-Fidelity-Prototypen der Benutzungsoberfläche zu erstellen. Hier wiederholt sich das Spiel: Auch diese werden mit repräsentativen Benutzern evaluiert und schrittweise verbessert. Bei High-Fidelity-Prototypen liegt der Fokus jedoch bereits auf Details der Oberflächengestaltung und der Bedienung: statischer Aufbau der Masken, insbesondere Gruppierung und Anordnung der Elemente, Auswahl von Controls (Interaktionselementen), aber auch Optimierung des Aufgabenflusses, etwa durch Variieren der Reihenfolge von Eingabeelementen und Drucktasten.

Auswahl von Controls

Welche Controls eingesetzt werden, hängt von der Nutzungssituation und der verwendeten Technologie ab. Jede Technologie verfügt über ein spezifisches Repertoire an Bildschirmelementen, oft in einer Progamm-Bibliothek organisiert, aus denen der Designer die geeigneten Elemente auswählt. Für manche Gestal349

13 User-Centered Design-Prozess der SAP AG tungsprobleme, z. B. die Auswahl von Positionen, stehen mehrere Controls mit ähnlichem Verhalten zur Verfügung. Hier muss sich der Designer anhand der Rahmenbedingungen für ein bestimmtes Control oder einen Controltyp, etwa Auswahlknöpfe/Optionsschaltflächen (Radiobuttons), entscheiden. Kasten 13.9 schildert einen solchen Fall. Kasten 13.9: Welches Control? Fallbeispiel Ein User Interface-Designer der SAP AG steht vor der Aufgabe, Eingabemasken für den Bezahlvorgang eines Webshops zu gestalten. Auf der zweiten Maske wird die Adresse des Empfängers der Bestellung eingegeben. Die Adresse beginnt mit der Anrede für den Empfänger, welche die Ausprägungen „Frau“, „Herr“ und „Dr.“ sowie „Keine Anrede“ anbieten soll. Da nur jeweils eine Möglichkeit ausgewählt werden darf, handelt es sich um eine exklusive Auswahl, also um Alternativen. Die Maske wird mit HTMLB gestaltet. HTMLB bedeutet Business-HTML und ist eine SAP-eigene Erweiterung von StandardHTML. Der Designer schaut in den HTMLB-Guidelines nach, welche Controls ihm für diesen Anwendungsfall zur Verfügung stehen. Er findet drei Controls, mit denen er die Aufgabe lösen kann: eine statische Auswahlliste (Listbox), ein Kombinationsfeld (Dropdown Listbox) und eine Gruppe von Optionsschaltflächen (Radiobuttons) (s. Abbildung 13.4). Um das am besten geeignete Control auswählen zu können, benötigt der Designer jedoch Kriterien. Auch hier wird er in den HTMLB-Guidelines fündig und trifft auf eine Seite, die HTMLB-Controls für die Auswahl von Alternativen miteinander vergleicht.

Abbildung 13.4: Auswahl mit Optionsschaltflächen (links), Auswahlliste (Mitte) und Kombinationsfeld (rechts) Als Auswahlkriterien können z. B. die Fragen dienen: „Ist es nötig, dass Benutzer alle Alternativen gleichzeitig sehen?“ „Wie viel Platz steht auf der Maske zur Verfügung, und wie viele Alternativen müssen berücksichtigt werden?“ Diese Kriterien sind, wie man sehen kann, nicht völlig unabhängig voneinander. 350

13.4 Was passiert konkret im UCD? Da für die Anrede nur vier Alternativen angeboten werden sollen, kommen sowohl Optionsschaltflächen als auch ein Kombinationsfeld in Frage. Es ist für Benutzer aber nicht nötig, alle Alternativen auf einmal zu sehen, nur die aktuelle Einstellung ist von Interesse. Deshalb entscheidet sich der User Interface-Designer für ein Kombinationsfeld. Ein statisches Auswahlfeld würde dagegen mehr Platz benötigen und die Maske optisch überfrachten und dadurch unübersichtlich aussehen lassen.

13.4.4

Pre- or post-deployment Nachdem das endgültige Design abgenommen und genehmigt worden ist, beginnt die Umsetzung des Prototypen in ein reales Produkt; diese Phase wird Implementationsphase genannt und ist nicht direkter Bestandteil des UCD-Prozesses. Damit ist die Arbeit der User Interface-Designer bei SAP AG allerdings noch nicht beendet. Sobald das fertige Produkt zur Verfügung steht, wird es weiteren Überprüfungen unterzogen, um ihm den letzten „Feinschliff“ vor der Auslieferung zu geben (genau genommen, läuft dieser Vorgang während des gesamten Lebenszyklus eines Produktes weiter).

Schwerpunkte der Hierzu gehört vor allem die Durchführung von (summativen) Usability-Tests. Schwerpunkt dieser abschließenden Tests ist die Benutzertests Erhebung folgender Kriterien (nach DIN EN ISO 9241-11, vgl. Kapitel 3):

Kanäle für Rückmeldungen an die SAP AG

•

User Effectiveness (Effektivität): Können Benutzer eine Aufgabe ohne Unterstützung durchführen?

•

User Efficiency (Effizienz): Wie lange benötigen Benutzer, bezogen auf einen Richtwert – z. B. die Vorgänger-Anwendung oder eine Zeitvorgabe –, für die Bearbeitung?

•

User Satisfaction (Benutzerzufriedenheit): Wie zufrieden sind die Benutzer mit der Anwendung?

Die Usability-Experten der SAP AG bemühen sich natürlich auch nach der Auslieferung von Produkten um eine kontinuierliche Verbesserung. Dazu nutzen sie aktiv und passiv die folgenden Kommunikationskanäle zu Kunden und Benutzern: •

Fehlerrückmeldungen per SAP Support Portal Rückmeldungen können als Problemmeldungen an die SAP AG gegeben werden. Während früher das sog. SAP Net R/3 Frontend bzw. Online Service System (OSS) im Einsatz war, 351

13 User-Centered Design-Prozess der SAP AG wird dazu inzwischen das SAP Support Portal genutzt. Usability-Probleme werden genauso behandelt wie funktionale Probleme und von der SAP AG sehr ernst genommen. Die Kunden erhalten eine Rückmeldung von der SAP AG, ob und wie die gemeldeten Usability-Probleme gelöst werden bzw. ob sie bereits in einem Folge-Release gelöst sind. •

ASUG / DSAG Vor allem auf den großen Jahreskonferenzen der SAP-Benutzerorganisationen DSAG (Deutsche SAP Anwendergruppe e.V.) und ASUG (Americas’ SAP Users Group), aber auch in Arbeitskreisen, Fokusgruppen oder während Usability-Tests (s. u.) können Kunden Rückmeldungen zur Usability von SAP-Produkten geben. Darüber hinaus besteht die Möglichkeit, sich als Kandidat für Usability-Tests und andere Usability-Aktiväten zu melden (auf der www.sap.com-Website oder der SAP Design Guild-Website; vgl. Kasten 13.10).

•

Site Visits Bei Kundenbesuchen (Site Visits) kommen SAP Usability-Experten zu Benutzern, um sie in ihrer gewohnten Arbeitsumgebung zu beobachten und zu interviewen (s. Kasten 13.5). Hieraus gewinnen sie Anregungen für neue, aber auch für die Verbesserung bestehender Produkte. Kundenbesuche stehen zwar typischerweise am Anfang der Produktentwicklung und nicht an deren Ende, finden jedoch ebenso in der Übergangsphase zwischen Produkten statt (man schaut das bestehende Produkt an, um Ideen für die Verbesserung des neuen zu erhalten).

•

Usability-Tests Die SAP AG führt weltweit Usability-Tests ihrer Produkte in den Usability Labs in Walldorf, Bangalore und Palo Alto durch. In diesen Test bearbeiten Testpersonen Aufgaben unter der Beobachtung von Usability-Experten, Entwicklern und Solution Managern. Dabei fokussieren sich die UsabilityExperten auf die Aspekte Benutzbarkeit sowie Gestaltung des User Interfaces und der Interaktion, die Entwickler hingegen auf die technischen Aspekte des User Interfaces, die Solution Manager schließlich auf die funktionalen Aspekte sowie die betriebswirtschaftlichen Hintergründe. Ziel dieser Tests ist die Feinabstimmung der Produkte vor ihrer Auslieferung. Der Vorteil für Testteilnehmer ist, dass sie das Produkt direkt beeinflussen können und frühzeitig von neuen Pro-

352

13.5 SAP-Produktstandard Usability, Styleguides duktversionen erfahren. Eine Registrierung als Testteilnehmer ist jederzeit möglich (s. o.). •

SAP Usability Partner Program Seit Februar 2006 können ausgewählte Kunden eine Partnerschaft mit der SAP AG über die Kooperation in Usability-Projekten vereinbaren. Diese Kooperation ermöglicht kurze Wege und schafft durch eine kontinuierliche Zusammenarbeit Vertrautheit zwischen Benutzern und den Usability-Experten der SAP AG.

13.5

SAP-Produktstandard Usability, Styleguides

Wir haben uns bei der Frage, wie die SAP AG die Benutzbarkeit Prozess- vs. Produktstandards ihrer Anwendungen sichert, auf die Darstellung des User-Centered Design-Prozesses beschränkt, weil sein Schwergewicht darauf liegt, die Interessen von Kunden und Benutzern zu ermitteln und bei der Entwicklung zu berücksichtigen. Die SAP AG hat neben dem Prozessstandard User-Centered Design auch verschiedene Produktstandards zu Usability und User Interface Design entwickelt, die die Qualität ihrer Software im Hinblick auf allgemeine Usability-Standards garantieren sollen. Produktbezogene Standards sind nötig, weil ein korrekt durchgeführter Prozess zunächst noch nicht garantiert, dass am Ende tatsächlich ein einwandfreies Produkt entsteht – auch wenn dies der Grundgedanke hinter der Einführung von Prozessstandards ist. Styleguides

Die von der SAP AG entwickelten Standards und Styleguides gelten einerseits für bestimmte Anwendungstypen, etwa ERP- oder Web-Anwendungen. Weitere Styleguides gelten für Bildschirmelemente, wie z. B. die Elemente der bereits erwähnten HTMLBBibliothek. In den SAP-Styleguides wird sozusagen die „UsabilitySyntax“ der SAP-Anwendungen definiert. Zum Beispiel legt der R/3-Styleguide die Anordnung und Terminologie von Menüs sowie die Einordnung von Anwendungsfunktionen in die Menüstruktur fest. Styleguides beschreiben auch das detaillierte Verhalten und Aussehen von Bausteinen der SAP-Benutzungsoberfläche. Im Falle des in Kasten 13.9 vorgestellten Kombinationsfeldes beschreiben sie, wie dieses aussieht, wie Einträge darin hervorgehoben werden, wie viele Einträge es aufnehmen darf, aber auch, in welchen Situationen es eingesetzt werden sollte und was die Alternativen dazu sind. Auf diese Weise sichert die SAP AG nicht nur die Usability der Bausteine ihrer Anwendungen, sondern auch, dass deren Zusammenspiel nach Usability-Anforderungen erfolgt. 353

13 User-Centered Design-Prozess der SAP AG Kasten 13.10: Mehr Wissen zum SAP User-Centered Design Die SAP-Design Guild – die Stimme der SAP AG im User Interface-Bereich Seit April 2000 unterhält die SAP AG eine Website, die SAP Design Guild (www.sapdesignguild.org), auf der sie ihr Wissen und ihre Ressourcen für die Gestaltung von Benutzungsoberflächen im SAP-Umfeld Kunden und Partnern zur Verfügung stellt. Diese Website ist offen für jedermann und wird auch eifrig genutzt – so z. B. von Studenten, die sich für User Interface-Design interessieren. Aber auch Designprofis und Mitarbeiter von Firmen unterschiedlichster Branchen beziehen den Design-Guild-Newsletter, um von Neuerungen auf der Website zu erfahren.

13.6

•

Die „Resources“-Ecke ist der zentrale und meistbesuchte Bestandteil der Website. Sie bietet SAP-Styleguides und weitere Informationen aus dem User Interface-Bereich an.

•

Im „Editions“-Teil der Website finden Besucher Artikelsammlungen zu SAP-nahen Themen aus dem User Interface-Bereich, wie Internet-Portale, Branding oder Barrierefreiheit.

•

Der „Community“-Bereich bietet ein breites Spektrum an Informationen und Artikeln. Hier finden Besucher einen Konferenzkalender, eine Buchliste, Buchvorstellungen und -besprechungen, Artikel zu Gestaltungsthemen, Linklisten und vieles andere mehr.

Zusammenfassung In diesem Kapitel und in den vorhergehenden haben Sie erfahren, dass Usability unverzichtbar ist. Sie haben auch gelernt, dass diese nicht allein vom Hersteller, also der SAP AG, geliefert werden kann und warum das so ist. Wir haben zur Erläuterung den Begriff „Usability“ in die Aspekte Benutzbarkeit und Gebrauchstauglichkeit aufgeteilt. Benutzbarkeit kann vom Hersteller geliefert werden, weil sie allgemeine und nicht kundenspezifische Anforderungen umfasst. Um die Benutzbarkeit ihrer Anwendungen zu sichern, hat die SAP AG den User-Centered Designprozess eingeführt. Seine Phasen, Methoden und Techniken haben wir in diesem Kapitel vorgestellt. Gebrauchstauglichkeit kann dagegen vom Hersteller nur vorbereitet werden. Er muss dazu in seinen Anwendungen die richtigen „Stellschrauben“ vorsehen. Sie ermöglichen es, diese in der Einführungsphase beim Kunden

354

13.6 Zusammenfassung und auch später optimal an seine Bedürfnisse und die der Benutzer vor Ort anzupassen. Diesen unternehmensspezifischen Anpassungsprozess, „Customizing“ genannt, und welche Rolle Usability Management dabei spielt, haben Sie im Hauptteil dieses Buches kennengelernt. Nur im Zusammenspiel von User-Centred Design der SAP AG und Usability Management im Anwenderunternehmen wird SAP-Software benutzungsfreundlich! Ulrich Kreichgauer und Gerd Waloszek

355

Literaturverzeichnis 1. Zitierte Literatur Balzert, H. (1998). Lehrbuch der Software-Technik: Software-Management, Software-Qualitätssicherung, Unternehmensmodellierung. Heidelberg: Spektrum. Bayer, M. (2006). SAP R/3 unterliegt in Sachen Usability. Computerwoche, 27, 7. Juli. Beyer, H. & Holtzblatt, K. (1998). Contextual Design: Defining Customer-Centered Systems. San Francisco: Morgan Kaufmann. Bias, R.G. (1994). The Pluralistic Usability Walkthrough: Coordinated Empathies. In J. Nielsen & R. L. Mack (Hrsg.), Usability Inspection Methods (S. 65–78). New York: John Wiley and Sons. Bias, R.G. & Mayhew, D.J. (Hrsg.) (1994). Cost-Justifying Usability. Boston, MA: Academic Press. Bias, R.G., Mayhew, D.J. (2005). Cost-Justifying Usability: An Update for the Internet Age. San Francisco: Morgan Kaufmann Publishers Inc. Blume, A. (1999). Projektkompass SAP. (3. Aufl.) Braunschweig: Vieweg. Blume, A. & Carlberg, I. (2001). Die Einführung von ERP-Software als Kooperationsprozess. PPS Management, 3. Brodbeck, F.C. (1991). Fehlerbewältigungsdauer und die Nutzung von Unterstützungsmöglichkeiten. In M. Frese & D. Zapf (Hrsg.), Fehler bei der Arbeit mit dem Computer – Ergebnisse von Beobachtungen und Befragungen im Bürobereich (S. 80– 94). Bern: Huber. Burmester, M., Görner, C., Hacker, W., Kärcher, M., Kurtz, P., Lieser, U., Risch, W., Wieland-Eckelmann, R. & Wilde H. (Hrsg.) (1997). Das SANUS-Handbuch – Bildschirmarbeit EUkonform. Schriftenreihe der Bundesanstalt für Arbeitsschutz und Arbeitsmedizin, Forschung Fb 790, Dortmund/Berlin. Cockburn, A. (2001). Writing Effective Use Cases. Boston: Addison-Wesley. Computerworld (1995). Norwich Rethinks CustomerService. Computer World, 24. November.

357

Literaturverzeichnis Doane, M. (2004). Thrive after go Live: Continuous Business Evolution with SAP R/3. Vortrag gehalten auf der TeSearchSAP.com Conference Europe. Doppler, C. & Lauterburg, C. (2005). Change Management. Den Unternehmenswandel gestalten. Frankfurt/Main: Campus. Dzida, W., Hofmann, B., Freitag, R., Redtenbacher, W., Baggen, R., Geis, T., Beimel, J., Hartwig, R., Hampe-Neteler, R. & Peters, H. (2001). Gebrauchstauglichkeit von Software. ErgoNorm: Ein Verfahren zur Konformitätsprüfung von Software auf der Grundlage von DIN EN ISO 9241 Teile 10 und 11. Schriftenreihe der Bundesanstalt für Arbeitsschutz und Arbeitsmedizin, Forschung Fb 921. Bremerhaven: Wirtschaftsverlag NW. Europäische Stiftung zur Verbesserung der Lebens- und Arbeitsbedingungen (2007) (Hrsg.). Vierte europäische Erhebung über Arbeitsbedingungen. Verfügbar unter http://eurofound.europa.eu/ docs/ewco/4EWCS/4WCS_Annex_statistical_annexEU25.pdf [5. Feb. 2007]. Frese, M., Irmer, C. & Prümper, J. (1991). Das Konzept Fehlermanagement: Eine Strategie des Umgangs mit Handlungsfehlern in der Mensch-Computer-Interaktion. In M. Frese, C. Kasten, C. Skarpelis & B. Zang-Scheucher (Hrsg.), Software für die Arbeit von morgen. Bilanzen und Perspektiven anwendungsorientierter Forschung (S. 241–251). Berlin: Springer. Gillar, J. (2004). Wir malen keine Bilder, sondern gestalten Benutzeroberflächen. SAP INFO [Online]. Verfügbar unter: http://www.sap.info [12. Jan. 2006]. Gould, J.D. & Lewis, C. (1985). Designing for Usability: Key Principles and What Designers Think, Communications of the ACM, 2 (3), 300–311. Hackos, J.T. & Redish, J.D. (1998). User and Task Analysis for Interface Design. New York: John Wiley and Sons. Hassenzahl, M., Prümper, J. & Sailer, U. (1997). Die Priorisierung von Problemhinweisen in der software-ergonomischen Qualitätssicherung. In R. Liskowski, B.M. Velichkovski, W. Wünschmann (Hrsg.), Software-Ergonomie ’97 – Usability Engineering: Integration von Mensch-Computer-Interaktion und Software-Entwicklung (S. 191–201). Stuttgart: Teubner. Holtzblatt, K., Wendell, J.B. & Wood, S. (2005). Rapid Contextual Design: A How-to Guide to Key Techniques for User-Centered Design. San Francisco: Morgan Kaufmann. 358

Literaturverzeichnis Hurtienne, J. & Prümper, J. (2003). Stress in the Office: The Influence of Software-Ergonomic Quality. In D. Harris, V. Duffy, M. Smith & C. Stephanidis (Hrsg.), Human-Centred Computing: Cognitive, Social, and Ergonomic Aspects (S. 63–67). Mahwah, N.J., London: Lawrence Erlbaum Associates. Hurtienne, J. & Prümper, J. (2004). Gebrauchstauglichkeit von Software: Ein vernachlässigtes Konstrukt in der Stressforschung? In T. Rammsayer, S. Grabianowski & S. Troche (Hrsg.), Berichte über den 44. Kongress der Deutschen Gesellschaft für Psychologie (S. 191). Lengerich: Pabst Science Publishers. Hurtienne, J., Abele, P., Floegel, S., Prümper, J. & Stein, B. (2004a). Usability von SAP-Systemen: Interventionen und Ergebnisse des Ergusto-Projektes. In M. Hassenzahl & M. Peissner (Hrsg.), Usability Professionals 2004 (S. 34–37). Paderborn: German Chapter der Usability Professionals' Association e.V. Hurtienne, J., Abele, P., Floegel, S., Prümper, J. & Stein, B. (2004b). Usability direkt bei der Einführung von SAP-Systemen: Das Projekt ErgoCust. In M. Hassenzahl & M. Peissner (Hrsg.), Usability Professionals 2004 (S. 38–41). Stuttgart: German Chapter der Usability Professionals' Association. Kaufmann, I, Pornschlegel, H. & Udris, I. (1982). Arbeitsbelastung und Beanspruchung. In L. Zimmermann (Hrsg.), Humane Arbeit – Leitfaden für Arbeitnehmer, Band 5: Belastungen und Stress bei der Arbeit (S. 13–48). Reinbek: Rowohlt. Knauer, S. (2000). PC-Frust – Klick zurück im Zorn. Ein Virus geht um in der PC-Welt: Millionen User leiden unter Computerfrust. Der Spiegel, 8. Ko, C. & Hurley, M. (1995). Managing end-user computing. Information Management and Computer Security, 3 (3), 3–5. Kohnke, O. (2005). Change Management als strategischer Erfolgsfaktor bei ERP-Implementierungsprojekten. In O. Kohnke & W. Bungard (Hrsg.), SAP-Einführung mit Change Management. Konzepte, Erfahrungen und Gestaltungsempfehlungen (S. 37–62). Wiesbaden: Gabler. Kohnke, O. & Bungard, W. (2005). SAP-Einführung mit Change Management. Konzepte, Erfahrungen und Gestaltungsempfehlungen. Wiesbaden: Gabler. Kühl, St. & Strodtholz, P. (Hrsg.) (2002). Methoden der Organisationsforschung – Ein Handbuch. Reinbek: Rowohlt. 359

Literaturverzeichnis Landauer, T.K. (1995). The Trouble with Computers. Usefulness, Usability, and Productivity. Cambridge, MA: Bradford. Mangold, P. (2004). IT-Projektmanagement kompakt. Heidelberg: Spektrum. Mayhew, D.J. (1992). Principles and Guidelines in Software User Interface Design. Englewood Cliffs, NJ: Prentice Hall. Mayhew, D.J. (1999). The Usability Engineering Lifecycle: A Practitioner' s Handbook for User Interface Design. San Francisco: Morgan Kaufmann. Mohr, G. (1986). Die Erfassung psychischer Befindensbeeinträchtigungen bei Industriearbeitern. Frankfurt/Main: Peter Lang. Mohr, G., Rigotti, T. & Müller, A. (2005). Irritation – ein Instrument zur Erfassung psychischer Beanspruchung im Arbeitskontext. Skalen- und Itemparameter aus 15 Studien. Zeitschrift für Arbeits- und Organisationspsychologie, 49, 44–48. Nielsen, J. (1993). Usability Engineering. Boston, MA: Academic Press. Nielsen, J. (1994). Heuristic Evaluation. In J. Nielsen & R.L. Mack (Hrsg.), Usability Inspection Methods (S. 25–62). New York: John Wiley & Sons. Nielsen, J. (2003). Return on Investment for Usability. Jakob Nielsen' s Alertbox, January 7, 2003: Verfügbar unter: http:// www.useit.com [15. März 2007]. Niemann, F. (2006). ERP-Nutzer bemängeln Reports. Computerwoche, 30, 25. Juli. Prümper, J. (1993). Software-Evaluation Based Upon ISO 9241 Part 10. In T. Grechenig & M. Tscheligi (Hrsg.), Human Computer Interaction (S. 255–265). Berlin Springer. Prümper, J. (1994). Fehlerbeurteilungen in der Mensch-Computer Interaktion. Reliabilitätsanalysen und Training einer handlungstheoretischen Fehlertaxonomie. Münster: Waxmann. Prümper, J. (1997). Der Benutzungsfragebogen ISONORM 9241/10: Ergebnisse zur Reliabilität und Validität. In R. Liskowsky, B.M. Velichkovsky & W. Wünschmann (Hrsg.), Software-Ergonomie ’97 – Usability Engineering: Integration von Mensch-Computer-Interaktion und Software-Entwicklung (S. 253–262). Stuttgart: Teubner. Prümper, J. (1999). Test IT: ISONORM 9241/10. In H.J. Bullinger & J. Ziegler (Hrsg.), Human-Computer Interaction – Commu360

Literaturverzeichnis nication, Cooperation, and Application Design (S. 1028–1032). Mahwah, New Jersey: Lawrence Erlbaum Associates. Prümper, J. & Anft, M. (1993). Die Evaluation von Software auf Grundlage des Entwurfs zur internationalen Ergonomie-Norm ISO 9241 Teil 10 als Beitrag zur partizipativen Systemgestaltung – ein Fallbeispiel. In K.H. Rödiger (Hrsg.), Software-Ergonomie ’93 – Von der Benutzungsoberfläche zur Arbeitsgestaltung (S. 145–156). Stuttgart: Teubner. Richenhagen, G., Prümper, J. & Wagner, J. (2002). Handbuch der Bildschirmarbeit (3. Auflage). Kriftel: Luchterhand. SAP AG (2005). SAP Customer Success Story. Strauss Innovation. Erfolgskurs mit Lifestyle-Shopping unter dem IT-Dach von SAP R/3 Enterprise. [Online] Verfügbar unter: http://www.bitbochum.de/download/strauss%20innovation%20success%20st ory.pdf [15. März 2007]. Scherer, E. & Schaffner, D. (2003). SAP-Training. Konzeption, Planung und Realisierung. Bonn: Galileo Press. Schulze, J. (2004). Bedienbare Software ist kein Zufall. SAP INFO [Online]. Verfügbar unter http://www.sap.info [12. Jan. 2006]. Schwarz, M. (2000). ERP-Standardsoftware und organisatorischer Wandel. Eine integrative Betrachtung. Wiesbaden: Gabler. Semmer, N. & Udris, I. (2004). Bedeutung und Wirkung von Arbeit. In H. Schuler (Hrsg.), Lehrbuch Organisationspsychologie (S. 157–195). Bern: Huber. Shneiderman, B. (1998). Designing the User Interface. Reading, MA: Addison-Wesley. Snyder, C. (2003). Paper Prototyping. San Francisco: Morgan Kaufmann. Virzi, R. A. (1990). Streamlining the design process: Running fewer subjects. In Proceedings of Human Factors and Ergonomics Society 34th Annual Meeting (S.291–294). Santa Monica, CA: Human Factors and Ergonomics Society. Virzi, R. A. (1992). Refining the test phase of usability evaluation: How many subjects is enough? Human Factors, 34(4), 457–468. Willumeit, H., Gediga, G. & Hamborg, K.-C. (1996). IsoMetricsL – ein Verfahren zur formativen Evaluation von Software nach ISO 9241/10, Mitteilungen des Fachausschusses 2.3 Ergonomie und Informatik, März, 5–12.

361

Literaturverzeichnis Zapf, D., Brodbeck, F.C. & Prümper, J. (1989). Handlungsorientierte Fehlertaxonomie in der Mensch-Computer Interaktion. Zeitschrift für Arbeits- und Organisationspsychologie, 33, 178– 187. Zapf, D. & Dormann, C. (2001). Gesundheit und Arbeitsschutz. In H. Schuler (Hrsg.), Lehrbuch Personalpsychologie (S. 559– 587). Göttingen: Hogrefe. 2. Gesetze, Verordnungen, Normen Arbeitsschutzgesetz (ArbSchG) – Gesetz über die Durchführung von Maßnahmen des Arbeitsschutzes zur Verbesserung der Sicherheit und des Gesundheitsschutzes der Beschäftigten bei der Arbeit. Fassung vom 7 August 1996 (BGBL. I S. 1246) in der geänderten Fassung vom 23 Dezember 2003 (BGBL. I S. 2907). Betriebsverfassungsgesetz (BetrVG) – In der Fassung der Bekanntmachung vom 25. September 2001 (BGBL. I S. 2518); zuletzt geändert durch Artikel 221 der Verordnung vom 31. Oktober 2006 (BGBL. I S. 2407). DIN EN ISO 9241. Ergonomische Anforderungen für Bürotätigkeiten mit Bildschirmgeräten / Ergonomie der Mensch-SystemInteraktion. – Teil 2 (1992). Anforderungen an die Arbeitsaufgaben; Leitsätze. Berlin: Beuth. – Teil 11 (1999). Anforderungen an die Gebrauchstauglichkeit; Leitsätze. Berlin: Beuth. – Teil 110 (2006): Grundsätze der Dialoggestaltung. Berlin: Beuth. DIN (2003). DIN-Taschenbuch 354: Software-Ergonomie. Empfehlungen für die Programmierung und Auswahl von Software. Berlin: Beuth. EG-Richtlinie 90/270/EWG (1990): Mensch-Maschine Schnittstelle. In Richtlinie des Rates vom 29. Mai 1990 über die Mindestvorschriften bezüglich der Sicherheit und des Gesundheitsschutzes bei der Arbeit an Bildschirmgeräten, Amtsblatt der Europäischen Gemeinschaften, Vol. 33, L 156, Mindestvorschriften (Artikel 4 und 5), Absatz 3, S. 18, 21.6.1990. Gesetz zur Gleichstellung behinderter Menschen. Behindertengleichstellungsgesetz (BGG) vom 27. April 2002 (BGBl I, S.

362

Literaturverzeichnis 1467–1468), zuletzt geändert durch Artikel 262 der Verordnung vom 31. Oktober 2006 (BGBL. I S. 2407). IEEE (1998). IEEE Standard 1233. IEEE Guide for Developing System Requirements Specifications. New York: Institute of Electrical and Electronics Engineers. Verordnung über Sicherheit und Gesundheitsschutz bei der Arbeit an Bildschirmgeräten (Bildschirmarbeitsverordnung – BildscharbV) vom 4. Dezember 1996 (BGBl. I S. 1841) Verordnung zur Schaffung barrierefreier Informationstechnik nach dem Behindertengleichstellungsgesetz (Barrierefreie Informationstechnik-Verordnung – BITV). BGBl I 2002, 2654. 3. Websites Deutsche SAP Anwendergruppe e.V. (DSAG). www.dsag.de. Americas' SAP Users Group (ASUG). www.asug.com. SAP AG: www.sap.com. SAP Design Guild: www.sapdesignguild.org.

363

Dank Ein Buch herauszugeben, das inhaltlich sehr starke Zusammenhänge aufweist und doch die individuellen Schwerpunkte verschiedener Berater in sich vereinigen möchte, ist keine leichte Aufgabe. Dieses schwierige Unterfangen konnte den Herausgebern nur mit Unterstützung gelingen. Daher möchten wir uns bei den folgenden Mitwirkenden bedanken. An erster Stelle gilt unser Dank natürlich den Autoren, von denen einige als Kollegen gemeinsam mit uns die dem Buch zugrundeliegenden Usability-Projekte durchgeführt haben. Dieses Buch bezieht auch Ergebnisse ein, die in zwei Projekten gewonnen wurden, die das Ministerium für Arbeit, Gesundheit und Soziales des Landes Nordrhein-Westfalen gefördert hat. Es unterstützte mit Mitteln aus dem Europäischen Sozialfond die Umsetzungsprojekte Ergusto (Ergonomic Customizing bei SAP R/3) und ErgoCust (Gesundheits- und Effektivitätsförderung durch integriertes Ergonomic Customizing). Im Rahmen dieser Projekte wurde die Idee für das Buch geboren und nach Abschluss der Projekte mit den Projektmitarbeitern auf freiwilliger Basis realisiert. In diesem Zusammenhang danken wir Dr. Gottfried Richenhagen, dem Initiator der Projekte und „spiritus rector“ des Ergonomic Customizing für fachliche Anregung, Beratung und Unterstützung. Großer Dank geht auch an alle an den Beratungs- und Forschungsprojekten beteiligten Beschäftigten in den SAP-Anwenderunternehmen. In diesen – aus Gründen der Anonymität hier nicht genannten – Betrieben haben wir die in diesem Buch vorgestellten Methoden erprobt und erhielten wertvolle Hinweise zu ihrer Verbesserung. Ebenso großer Dank geht an die SAP AG, ohne deren Kooperation wir das Usability Management bei SAP-Projekten nicht hätten entwickeln können. Von den vielen Ansprechpartnern im Vertrieb, in der Beratung und der Entwicklung sowie in der Schulung sei an dieser Stelle besonders Christian Ritter, Leiter Vertrieb Personalwirtschaft, persönlich gedankt, der uns mit seinen weit verzweigten Kontakten bei der SAP AG vielfach helfen konnte. Auch bedanken möchten wir uns bei der DSAG (Deutsche SAP-Anwendergesellschaft), die mit uns zusammen Workshops zum Thema Usability veranstaltete. 365

Dank Dank gilt auch den Mitarbeitern der beteiligten Forschungs- und Beratungsinstitute bao – Büro für Arbeits- und Organisationspsychologie GmbH in Berlin, BIT – Berufsforschungs- und Beratungsinstitut für interdisziplinäre Technikgestaltung e.V. in Bochum sowie TBS – Technologieberatungsstelle beim DGB Landesbezirk NRW e.V. in Dortmund, die uns bei der Umsetzung und Gestaltung des Buches halfen. Nicht zuletzt danken wir unserem Lektor, Maurice Lahde, der mit seinem Erfahrungsschatz und unermüdlichem Einsatz die sprachliche und optische Qualität des Buches mehr als positiv beeinflusst hat. Am Schluss steht der Dank für unsere Lebenspartner, Kinder, Familien und Freunde, denen durch die Erstellung des Buches einiges von der gemeinsamen Freizeit genommen wurde und die das Projekt dennoch jederzeit unterstützten. Petra Abele, Jörn Hurtienne und Jochen Prümper

366

Über die Autorinnen und Autoren Dr. Petra Abele studierte Arbeits-, Betriebs- und Organisationspsychologie in Bonn und Trier und promovierte an der Universität Kassel. Seit 1989 war sie Mitarbeiterin und Leiterin zahlreicher Forschungs- und Beratungsprojekte in Industrie und öffentlicher Verwaltung, u. a. zu den Themen IT-Einführung, partizipative Systementwicklung, Arbeits- und Organisationsgestaltung. Sie arbeitete von 2002 bis 2006 beim BIT – Berufsforschungs- und Beratungsinstitut für interdisziplinäre Technikgestaltung e. V. Bochum als Beraterin für Software-Ergonomie sowie Arbeits- und Gesundheitsschutz. Seit 2006 ist sie Mitarbeiterin bei der Firma marker software in Heidelberg. Dr. Andreas Blume studierte Psychologie und Sozialwissenschaften in Bochum und promovierte an der Universität Osnabrück über das Thema „Die Fabrik, eine Struktur begrenzter Entwicklung“. Er war Organisationsprogrammierer und Fachkraft für Arbeitssicherheit in der Industrie und 20 Jahre geschäftsführendes Vorstandsmitglied im BIT – Berufsforschungs- und Beratungsinstitut für interdisziplinäre Technikgestaltung e. V. Bochum. Er initiierte und leitete eine Vielzahl von Forschungs- und Industrieprojekten, z.B. zur menschengerechten und interessenbalancierten Einführung und Gestaltung von IT-Systemen. Er ist Autor zahlreicher Publikationen, u.a. des „Projektkompass SAP“. Derzeit arbeitet er als Berater, Projektleiter, Coach und Change Manager, leitet den Masterstudiengang „Betriebliches Gesundheitsmanagement“ an der Universität Bielefeld und ist Lehrbeauftragter an der Ruhr-Universität Bochum. Stefanie Floegel studierte Politische Wissenschaften, VWL und Jura in Bonn. Sie arbeitet seit 2001 beim BIT – Berufsforschungsund Beratungsinstitut für interdisziplinäre Technikgestaltung e. V. in Bochum als Coach und Beraterin für Arbeits- und Gesundheitsschutz, Gestaltung von EDV-Einführungen und Software-Ergonomie. Anne Jansen studierte Psychologie in Gießen, Amsterdam und Berlin und schloss eine Ausbildung zur Kommunikations- und Verhaltenstrainerin bei artop ab. Sie arbeitete von 2003 bis 2005 beim bao – Büro für Arbeits- und Organisationspsychologie GmbH in Berlin als Beraterin, u. a. in den Bereichen Software-Ergonomie und Arbeitsgestaltung. Seit Winter 2005 ist sie Assistentin an der Universität Zürich und promoviert dort am Lehrstuhl für Arbeits- und Organisationspsychologie. 367

Über die Autorinnen und Autoren Jörn Hurtienne studierte Psychologie mit den Schwerpunkten Ingenieurpsychologie und Marketing in Berlin und Brighton (UK). Mit der Benutzungsfreundlichkeit von Software beschäftigt er sich seit 1996. Dabei lag der Schwerpunkt zunächst bei Internet und multimodalen Systemen und erweiterte sich später auf betriebswirtschaftliche Software und Usability Management. Seit 2001 arbeitet er als Berater für Software-Ergonomie und Usability-Engineering beim bao – Büro für Arbeits- und Organisationspsychologie GmbH in Berlin. Er promoviert derzeit an der TU Berlin über Image-Schemata als Werkzeuge für die Gestaltung intuitiver Mensch-Technik-Interaktion. Ulrich Kreichgauer studierte Arbeits- und Organisationspsychologie in Mannheim. Seit 1989 arbeitet er im Bereich Usability bei der SAP AG in Walldorf. Frühere Schwerpunkte seiner Arbeit lagen in den Bereichen Standards, Guidelines, User Interface Application Design, Usability Testing und Evaluationen, Programmierung von Usability-Konsistenz-Prüfroutinen sowie UI-Konzepte. Aktuell leitet er die Gruppe „User Experience Infrastucture“, die zentral innerhalb der SAP Usability-Services im Bereich Testing, Trainings, Knowledge Transfer und Tools anbietet. Daneben arbeitet er inhaltlich an der Definition und Prüfung von SAPinternen Usability-Qualitätsanforderungen. Dr. Reinhard Linz studierte Informatik in Karlsruhe, Edinburgh und Bonn und promovierte an der Universität Bonn im Bereich Rechtsinformatik mit einer Arbeit über normative Logik. Seit 1981 Forschungs- und Beratungs- und Schulungstätigkeit auf den Gebieten Datenschutz, Software-Ergonomie und Projektorganisation, seit 1992 beim BIT – Berufsforschungs- und Beratungsinstitut für interdisziplinäre Technikgestaltung e. V. Bochum und seit 2006 bei FORBIT in Hamburg. Er verfügt über umfangreiche Erfahrungen als Sachverständiger in zahlreichen betrieblichen IT-Einführungsprojekten und war Mitarbeiter und Leiter verschiedener öffentlich geförderter Forschungsprojekte z. B. über die datenschutzgerechten und ergonomischen Gestaltungsmöglichkeiten von SAP-Software. Cornelius Müller studierte Arbeits- und Organisationspsychologie sowie Medienpsychologie in Berlin. Von 2004 bis 2006 war er beim bao – Büro für Arbeits- und Organisationspsychologie GmbH in Berlin als Berater für Software-Ergonomie und Usability Engineering beschäftigt. Seit 2006 ist er als Inhouse Usability Consultant bei der Swisscom Fixnet AG in Zürich tätig. Er setzt sich seit 1999 im Rahmen von Forschungs- und Betriebsbera-

368

Über die Autorinnen und Autoren tungsprojekten mit der Benutzungsfreundlichkeit von Internetanwendungen und betrieblicher Software auseinander. Prof. Dr. Jochen Prümper studierte Psychologie mit den Schwerpunkten Arbeits- und Organisationspsychologie in Utrecht/NL, Landau und München und promovierte an der Universität Gießen über das Thema „Fehler in der Mensch-Computer-Interaktion“. Von 1990 bis 1995 war er als arbeitswissenschaftlicher Leiter in der IT-Industrie tätig, sammelte umfangreiche Erfahrungen im Change Management bei IT-Projekten und leitet seit 1995 das Fachgebiet Wirtschafts- und Organisationspsychologie an der FHTW-Berlin. Er ist Autor zahlreicher Publikationen zu den Themen Software-Ergonomie und Usability Engineering, Personalmanagement bei computergestützter Büroarbeit, Umsetzung der Bildschirmarbeitsverordnung sowie Analyse und Gestaltung von Arbeits- und Organisationsprozessen. Dr. Gottfried Richenhagen studierte Mathematik, Informatik und Didaktik an den Universitäten Bonn und Bielefeld und promovierte an der Universität Bielefeld. Von 1987 bis 1999 war er Berater und Regionalleiter der Technologieberatungsstelle Oberhausen. Seit 1999 ist er Referatsleiter im Ministerium für Arbeit, Gesundheit und Soziales des Landes NRW und zugleich Geschäftsführer der Gemeinschaftsinitiative „Gesünder Arbeiten e. V.“. Er ist bekannt durch zahlreiche Vorträge und Veröffentlichungen u. a. auch zu den Themen demografischer Wandel, Gesundheit und Beschäftigungsfähigkeit, Arbeiten am Computer, Arbeitsschutzmanagement und Mobbing. Bernd Stein studierte Physik und Sicherheitstechnik in Essen und Wuppertal. Von 1982 bis 1989 war er Betriebs- und Sicherheitsingenieur bei der Flachglas AG in Wesel und Gelsenkirchen. Seit 1989 ist er Berater der Technologieberatungsstelle beim DGB NRW e. V. in Oberhausen und Dortmund. Er war Mitarbeiter und Leiter öffentlich geförderter Projekte u. a. über die ergonomischen Gestaltungsmöglichkeiten von SAP-Software und die Einführung von Software in kleinen und mittleren Unternehmen. Dr. Gerd Waloszek studierte Physik in Braunschweig und promovierte an der Universität Trier über das Thema „Graphische Programmierumgebung“. Seit 1993 arbeitet er im Bereich Usability bei der SAP AG in Walldorf. Zunächst war er in den Bereichen Standards, Guidelines, Terminologie und in der Anwendungsberatung tätig, später verlegte sich sein Schwerpunkt auf die Beratung von WebAnwendungen. Seit 2000 arbeitet er an der SAP Design Guild-Website und seit 2004 an der SAP-internen User Experience-Website mit. 369

Sachregister A Accelerated SAP s. ASAP Accessibility 52, 54 Accessibility Competence Center 54 Akzeptanz der SAP-Software 30, 112, 117, 124, 144, 220, 229, 317, 326 Americas’ SAP Users Group (ASAG) 352 Anforderungen (Baustein im Vorgehensmodell) 91, 94, 160-170, 173-175, 177, 179, 180-187, 191-194, 197, 199, 201, 205, 208, 210 strategische 94, 148, 150, 151, 161-163 Anforderungsanalyse s. Vorgehensmodell zum Usability Management, Phase „Anforderungsanalyse“ Anpassungskosten s. Kosten Anpassungswissen 267, 268 Ansprechpartner für Benutzer 245, 252, 253 Arbeit, menschengerechte Gestaltung von 51 Arbeitsaufgaben 137-141, 161 Arbeitskosten s. Kosten 24 Arbeitsort 138, 142 Arbeitsprozess- und Dialoggestaltung (Baustein im Vorgehensmodell) 95, 96, 138, 139, 142, 173, 175-199, 201, 205, 207-209 Arbeitsprozesse 173-175, 180182, 184, 186, 197, 198, 206, 208, integrierte 231, 234, 235

Arbeitsschritte 136, 137, 138, 155 Arbeitsschutzgesetz (ArbSchG) 51, 52, 309, 310, 323 Arbeitsteiligkeit, verdeckte 139 Arbeitsüberlastung 23 Arbeitsumfeld / Arbeitsumgebung 55, 56, 60, 138, 142, 154, 159, 344, 338 Artefakt 155, 156 ASAP 11-13, 20, 79, 80-84, 88, 91, 92, 95, 97, 98, 100, 110, 113, 117, 129, 130 -Blueprint-Workshops 136 -Implementation Roadmap 173 Aufgabenanalyse 116, 117 ... vor Ort 134, 147, 148, 151153, 155, 157, 159, 164, 165, 169, 171 Aufgabenangemessenheit (Grundsätze der Dialoggestaltung nach DIN EN ISO 9241-110) 61, 63, 67, 76, 104, 266 Aufgabenbearbeitung s. Arbeitsaufgaben Aufgabengestaltung 52, 55-58, 138, 141, 265 Aufgaben -hierarchie 155, 157 -merkmale 147, 148, 171 -wichtigkeit 139, 148 -zuschnitte 141, 174, 197, 199, 200, 201, 203, 205 Aufwandsschätzung 117, 125, 183 Auswertungsgruppe (Wirkungskontrolle) 310, 313

371

Sachregister B Barrierefreie Informationstechnik-Verordnung 52 Barrierefreiheit 52, 54 Baukastensystem 79, 80, 85 Beanspruchungen und Belastungen 23, 37-49, 51, 57, 69 Verringerung von B. 47-49 Befragung 148, 161, 163 der Benutzer 116, 147-152, 162, 163 von Benutzervertretern 150 von Schlüsselpersonen 147, 150 Behinderungen 138, 141, 143, 145 Behindertengleichstellungsgesetz 52, 53-54 Belastungen s. Beanspruchungen und Belastungen Belastungsarmut 56 Benutzbarkeit (vs. Gebrauchstauglichkeit) 336 Benutzer -anforderungen 35, 37, 43, 49, s. auch Anforderungen -befragung s. Befragung der Benutzer -beteiligung 81, 84, 85, 123, 110, 118-129 -dokumentation 222, 261 -eigenschaften 134, 136, 143, 144, 150 -merkmale 116, 143, 148150, 171 -orientierung (Leitsätze zur Aufgabengestaltung nach DIN EN ISO 9241-2) 57, 168, 199 -qualifizierung 44, 46, 85, 87, 102 -schulungen 41, 44, 82, 101, 102, 126, 139, 182, 183, 239-256

372

-supports 282 -tests 339, 341, 351 -treffen 46 -vertreter 161 workshop 164; s. auch Workshops Benutzungsfreundlichkeit VI, VII, 8, 23, 47 Benutzungsoberfläche 35, 51, 135, 163, 176, 179, 181, 333, 344, 348, 349, 353, 354 Beobachtungsinterview 151, 152, 160, 164, 278, 283-287, 289-291, 295-299, 315 mit Videoanalyse 278, 284297 Berechtigungsprofile 198, 203206 Beteiligung s. Benutzerbeteiligung Beteiligungskonzept (Baustein im Vorgehensmodell) 88, 89, 91, 110, 119, 124, 125-129, 130, 131 Beteiligungsregeln 124 Beteiligungsstruktur 124-128 Betriebs- und Änderungskosten 317 Betriebs-/Personalrat 110, 119, 121-123, 125-128, 185, 323 Betriebsblindheit 214 Betriebsvereinbarungen 119, 121, 122 Betriebsverfassungsgesetz (BetrVG) 121 Bildschirmarbeitsverordnung V, 1, 13, 20, 50, 52, 53, 122, 323 Bildschirmgröße und auflösung 145, 146 Business Blueprint 35, 81, 83, 95, 133, 134, 137, 160, 168, 173, 214, 240 -Workshops 147 Business Case 14-19

Sachregister C Computererfahrung 142, 143, 149, 162, 163, 165 Controls (Interaktionselemente) 349, 350 Customizing 38, 216, 341, 342, 355

D Daten- und Systempflege 178 Datenmatrix 346, 347 Datenschutz 321, 330, 331 Deutsche SAP Anwendergruppe e.V. (DSAG) 352 Dialoggestaltung 56, 61, 175, 206, 210 Dialogprinzipien, Erfüllung der 75-77 DIN EN ISO 10075 323 DIN EN ISO 9241 52, 53, 5577, 242, 279, 282, 317 Teil 1 (Allgemeine Einführung) 24, 55 Teil 2 (Leitsätze zur Aufgabengestaltung) 13, 55, 56-61, 77, 95, 114, 141, 168, 197, 199, 201, 242, 265, 278, 311 Teile 3-9 55 Teil 110 (Grundsätze der Dialoggestaltung; ehemals Teil 10) 13, 55, 61-75, 77, 95, 112, 114, 168, 242, 265, 266, 278, 280, 283, 304, 311 Teil 11 (Anforderungen an die Gebrauchstauglichkeit – Leitsätze) 24, 25, 30, 55, 62, 164, 242, 246, 264, 326, 351 Teile 12-17, 151, 171 55 Dokumentation und Auswertung 147, 154

Dreieck der SoftwareErgonomie 8, 9, 11, 137, 282

E Effektivität 14, 24, 30, 33, 49, 51, 62, 92, 111, 117, 133, 136, 144, 146, 164, 201, 213, 241, 261, 264, 270, 337, 351 Effizienz 5, 14, 24-33, 49, 51, 56, 62, 92, 111, 133, 135, 136, 140, 144-146, 164, 201, 207, 213, 239, 241, 261, 264, 270, 317, 321, 322, 324, 334, 351 EG-Bildschirm-Richtlinie V, 52 Eindeutigkeit (Leitsätze zur Aufgabengestaltung nach DIN EN ISO 9241-2) 58 Einführungsprojekt s. SAPEinführungsprojekt Eingabegeräte 145, 146 Entwicklungsmöglichkeit (Leitsätze zur Aufgabengestaltung nach DIN EN ISO 9241-2) 60, 61, 168, 199 Erfolgsfaktoren von Usability Management 13, 80-86, 317332 Ergonomie-Experten 235, 291, 296, 314 Ergonomische Einstellungsmöglichkeiten 303 Fallregister 295, 301, 308 Ist-Analyse 276, 278-300 Optimierung 277, 287, 313 Ergonomische Meilensteine (Vorgehensmodell) 87, 88, 130, 209, 264, 269 Ergonomischer Meilenstein 1 88, 90-91, 109, 110, 119, 130, 171, 244 Ergonomischer Meilenstein 2 91, 94, 133, 135, 171

373

Sachregister Ergonomischer Meilenstein 3 95, 97, 171, 173, 206, 209 Ergonomischer Meilenstein 4 97, 100, 214, 235 Ergonomischer Meilenstein 5 102, 103, 244, 260, 264-270 Ergonomische Projektziele (Baustein im Vorgehensmodell) 88, 109, 110-114, 126, 259, 262, 266 Rollenzuschnitte (Baustein im Vorgehensmodell) 9496, 142, 174, 175, 196-208 Stellschrauben 13, 16, 45, 80, 104-106, 242, 244-246, 261, 303, 306, 336, 354 Ergonomisches Dreieck s. Dreieck der Software-Ergonomie Fallregister 286, 293, 294, 302, 309 ErgoNorm-Benutzerfragebogen 279 Erlernbarkeit von Software 34 Erwartungskonformität (Grundsätze der Dialoggestaltung nach DIN EN ISO 9241-110) 65-67, 140, 266 Evaluation 95, 111, 116, 117, 126, 127, 174, 184, 205, 206, 207, 210, 213, 253, 254 des Sollkonzepts mit Benutzern (Baustein im Vorgehensmodell) 87, 95, 96, 174, 184, 206-210, 215, 217, 259 integrierter Arbeitsprozesse mit Benutzern (Baustein im Vorgehensmodell) 9799, 214, 230-235 testbarer (Teil-)Prozesse mit Benutzern (Baustein im Vorgehensmodell) 97, 98, 213, 218-230, 262, 265 -ergebnisse 229, 230

374

F Farbenblindheit 143, 145 Fehlbelastungen 112, 115 Fehler -management 30 -meldungen 178 -robustheit 322 -toleranz (Grundsätze der Dialoggestaltung nach DIN EN ISO 9241-110) 67, 71, 72, 104, 145, 163, 266 -vermeidung 28, 29, 30, 71 Fehlsichtigkeit 143, 145 Final Preparation 82, 83 Flexibilität 138, 140, 163, 167, 336 Fluktuation am Arbeitsplatz 136, 138, 142, 163 Flussdiagramme 345 Fokusgruppe 278, 286, 288, 295, 297-302, 307, 308, 313 Fragebogen 134, 148, 149 -erhebung 285, 292, 297, 298, 301 -erhebung (Ergonomische IstAnalyse) 278-284 -erhebung (Wirkungskontrolle) 310-313 Funktionstests 213, 218, 219

G Ganzheitliche User-Experience 341 Ganzheitlichkeit (Leitsätze zur Aufgabengestaltung nach DIN EN ISO 9241-2) 58, 168, 199 Gebrauchstauglichkeit 8, 242, 246 vs. Benutzbarkeit 336 Gestaltungs-ideen 175, 179-184, 192, 193, 201 -prozesse 177 -regeln 173, 176, 177, 179, 183-185, 193

Sachregister -vorgaben 173-176, 179, 180, 183, 184, 186, 192, 194, 196, 198, 201, 206, 208-210 Gesundheitsförderung, betriebliche 42 Gesundheitsschutz 121, 122 Go Live 33, 36, 80-84, 86, 89, 92, 98-104, 177, 197, 205, 213, 214, 231, 234, 235, 239, 247, 250, 252, 253, 256, 259, 260, 262, 264, 273; s. auch Produktivstart ... & Optimierung s. Vorgehensmodell zum Usability Management, Phase „Go Live & Optimierung“ ... und Support 82, 83 Grundsätze der Dialoggestaltung s. DIN EN ISO 9241, Teil 110 Gruppeninterviews 160

H Handlungsspielraum (Leitsätze zur Aufgabengestaltung nach DIN EN ISO 9241-2) 59, 168 Hardwaregestaltung 56 High-Fidelity-Prototypen s. Prototypen

I IEEE Standard 1233 169 Implementation Roadmap 81, 82 Implementierungsphase 37, 351 Individualisierbarkeit (Grundsätze der Dialoggestaltung nach DIN EN ISO 9241-110) 67, 73, 74, 76, 104, 266 Individualsoftware 333 Informations- und Kommunikationswege 129 Informationskanäle, informelle 139

inkrementelle Prototypen s. Prototypen integrierte Arbeitsprozesse s. Arbeitsprozesse Interaktionsarchitektur 343, 344 Interaktionselemente s. Controls 349 IsoMetrics (Fragebogen) 279 ISONORM 9241/10 (Fragebogen) 48, 266, 267, 279

K Kernprozesse 115 Key-User 84, 85, 90, 110, 119, 123-125, 138, 214, 215, 231, 234, 241, 243, 245, 246, 252, 323, 326 Kommunikation (Erfolgsfaktor) 318, 328-332 Kommunikationshürden/probleme 43, 46 Konsistenz 65 äußere 65, 66 in Bedienabläufen 166 innere 65 -manager 95, 176-179, 183185, 196 Kontinuierlicher Verbesserungsprozess (KVP) 46, 102, 103, 116, 126, 256, 259, 260, 269-273, 319 Kontrollverlust 69 Kooperationsbeziehungen 137, 139 Koordinations- und Betreuungsteam 261, 264 Koordinator 215, 219, 221, 222, 223, 224, 229, 234 Kosten 4, 5, 12-15, 18, 24 Einsparung von 23, 26, 27, 33-37, 49 von Usability Management 15-17

375

Sachregister Kosten-Nutzen-Verhältnis des Usability Management 17-19 Kundenbesuche 343, 352

L Leitbilder 109, 111, 112 Leitsätze zur Aufgabengestaltung s. DIN EN ISO 9241 Teil 2 Lernförderlichkeit (Grundsätze der Dialoggestaltung nach DIN EN ISO 9241-110) 6769, 77, 141-145, 266 Lernsystem (Baustein im Vorgehensmodell) 100, 101, 240, 247-256, 266 Low-Fidelity-Prototypen s. Prototypen

M Machbarkeit organisatorische 183, 193 technische 183, 193 Machbarkeitssprüfung 173, 179, 184, 185, 192, 201 Machbarkeitsstudie 117, 118 Mängelerhebung 263 Masken s. Bildschirmmasken Maßnahmen zum Gesundheitsschutz 309 Mausarm s. Repetitive Strain Injury 43 Meilensteine, ergonomische s. Ergonomische Meilensteine Meister-Lehrling-Prinzip 153, 154 Mensch-Computer-Interaktion, menschengerechte Gestaltung von 51 Mischarbeitsplätze 200 Mitarbeiterbefragung 265, 267 Monotonie 199

N Nutzungshäufigkeit 140, 163 Nutzungsinformationen 134

376

Nutzungskontext 134-136, 151, 153, 157, 160, 164, 165, 167, 168, 242, 248, 286 Dokumentation des 133, 134 Nutzungskontextanalyse (Baustein im Vorgehensmodell) 91-94, 134, 135-160, 161, 171 Nutzungsszenarien s. Use Cases

O Oberflächengestaltung 178 Organizational Change Management 138, 139, 141, 152, 240

P Papierprototypen s. Prototypen Passung 8, 9, 11, 12, 14, 104, 137, 245, 250, 282, 286, 304 Personalisierung 341, 342 Pluralistic Walkthrough 207 Produktivbetrieb 216, 218, 233, 234, 259, 260 Produktivität VI, 5, 13, 14, 16, 21, 23, 24, 26, 28, 30, 33, 34, 37, 49, 51, 111, 113, 115, 317, 322 Produktivsetzung 2, 3, 33, 82, 86, 97, 100, 103, 123, 239, 240, 247, 248, 256, 259, 261 Produktivstart 24, 30, 33, 35, 47, 109, 110, 111, 123, 214, 235, 247, 248, 260, 273, 318, 319, 323, 330; s. auch Go Live Project Preparation 83 Projekt -abschluss 259, 264, 269, 270, 274 -einstieg s. Vorgehensmodell zum Usability Management, Phase „Projekteinstieg“ -gremien 110, 119-121, 127

Sachregister -planung (Erfolgsfaktor) 318-321, 332 -standards (Baustein im Vorgehensmodell) 88-91, 110, 129-131 -steuerungsgremium 127 -team 149, 157, 160, 161, 169, 176, 182-185, 194, 205, 206, 209, 210 -umfang und Projektaufgaben (Baustein im Vorgehensmodell) 88, 89, 91, 110, 114-118, 130, 131, 127, 130, 131 -vereinbarung 109 -vorbereitung 240 -ziele s. Ergonomische Projektziele Protokollbogen 222, 224, 225, 227-229, 253, 254, 262, 271, 272 Prototypen 24, 217, 218, 259, 266, 320, 328, 330 inkrementelle 218 High-Fidelity- 339, 341, 348, 349 Low-Fidelity- 339, 348 Papier- 181, 183, 187, 188, 194, 207, 209, 339, 340, 341, 348, 349 Rapid Prototyping 306 Wegwerf- 218 Psychosomatische Beschwerden 47-49

R

Q

S

Qualifizierung aller Projektbeteiligten (Baustein im Vorgehensmodell) 86, 100, 240-243 Qualifizierungsmaßnahmen 261, 268 QuickInfos 64, 65

Sammelrollen 197, 198 SAP -Berater 175, 179, 181, 184, 185, 194, 209 Design Guild 352, 354 -Einführungsmethodik s. ASAP -Einführungsprojekt 1, 2, 19, 33, 79, 80, 81, 84, 85, 213,

Rahmenbedingungen 109, 117, 121, 125, 131, 186, 206, 248, 250 Rationalisierungsschutz 122 Reaktionszeiten der Software 178 Realisierung s. Vorgehensmodell zum Usability Management, Phase „Realisierung“ Realisierungsphase 111, 116 Releasefestigkeit 15, 16 Releasewechsel 24 Repetitive Strain Injury 43 Ressourcen 41, 44-47, 49, 51 Review der Anforderungen und der Usability-Ziele 180, 185 der Projektaktivitäten und Ergebnisse 171 -Workshop 206-208 Rollen und Berechtigungen in der SAP-Software s. SAPRollen Rollenzuschnitte s. Ergonomische Rollenzuschnitte Rot-Grün-Blindheit 92 Rückkopplung zu den Benutzern 309 Rückmeldung (Leitsätze zur Aufgabengestaltung nach DIN EN ISO 9241-2) 58, 60, 64, 72, 168

377

Sachregister 216, 218, 239, 240, 243, 249, 260, 275, 277 Roadmap 240 -Rollen 94, 96, 173, 174, 184, 197, 198, 201-203, 205, 206, 210 Solution Manager 82 -Standard 180, 181, 185, 188, 197, 198, 202, 203 Support Portal 351 User-Centered Design-Prozess 333-358 Schnellerfassungsmaske 32 Schulung s. Vorgehensmodell zum Usability Management, Modul „Schulung“ Schulungsunterlagen 261, 266 Screenrecorder 290 Selbstbeschreibungsfähigkeit (Grundsätze der Dialoggestaltung nach DIN EN ISO 9241-110) 63-65, 67, 140, 143, 144, 266 Selbsterklärungsfähigkeit 104 Site Visits s. Kundenbesuche Sollkonzept 33, 35, 44, 95-97, 173-175, 184, 209, 210, 213, 217, 219, 235, 246, 265 Sollkonzeption s. Vorgehensmodell zum Usability Management, Phase „Sollkonzeption“ Soziale Rückendeckung 60 Standardsoftware 333, 334, 336 Stellschrauben s. Ergonomische Stellschrauben Steuerbarkeit (Grundsätze der Dialoggestaltung nach DIN EN ISO 9241-110) 67, 69, 70, 145, 266, 267 Steuerungs-gremium 210 -gruppe 133, 149, 160, 171 -kreis 243-245 Strategische Anforderungen s. Anforderungen

378

Stress s. Belastung / Beansprachung 40 Stresslinie eines Projekts 319 Supportmöglichkeiten 138, 141 Systemanpassung 276, 302-311 Systemgeschwindigkeit 146

T Task Flow Diagrams 345 Technikertermin 303, 307, 308 Technikmerkmale 145, 147, 148, 160, 171 Test im Echtbetrieb und Optimierung (Baustein im Vorgehensmodell) 102, 103, 259-262, 264, 269, 273 Testbare (Teil-)Prozesse (Baustein im Vorgehensmodell) 97, 213, 216, 218, 219, 221, 223, 231, 234, 235 Testphase 261, 262, 269 „Tipps & Tricks“-Schulung 44, 45, 76, 268, 303, 304 „Top 20“-Liste der Verbesserungsvorschläge 298-302 Total Cost of Ownership (TCO) 23 Transparenz über Projektaktivitäten 118

U Übersicht software-ergonomischer Problemfelder 222, 224 Umgebungseigenschaften 134 Umgebungseinflüsse 136 Umgebungsmodell 155, 159 Umschulungen 136 Unterbrechungen 138, 155, 159 Unterbrechungsresistenz 166 Unternehmensstruktur 168 Unterschied zwischen Kunde und Benutzer 334 Unterstützung, soziale 46

Sachregister Usability Care 13, 19, 274, 275315, 329, 330 Usability-Promotor 120 Usability-Ziele 109-116, 119, 131, 174, 175, 179, 180, 183187, 193, 199-201 qualitative u. quantitative 170 Use Cases 338, 339, 345-347 User-Centered Design-Prozess s. SAP-User-Centered Design Prozess User Interface 333, 334, 338, 339, 341, 343, 344, 348-353 User Interface Designs 338, 348

100, 102, 104, 126, 256, 259-274, 277 Phase „Projekteinstieg“ 13, 80, 81, 83, 86, 88-90, 106, 109-131, 133, 137, 171, 259, 260, 264 Phase „Realisierung“ 3, 13, 19, 80, 81, 83, 86, 97-99, 126, 213-236, 239, 240, 247, 259 Phase „Sollkonzeption“ 13, 19, 80, 81, 83, 86, 87, 9496, 111, 126, 160, 166, 167, 171, 173-210, 213, 217, 259, 264 Überblick 86-104

V Verbesserungsprozess, kontinuierlicher s. Kontinuierlicher Verbesserungsprozess Verbindlichkeit (Erfolgsfaktor) 318, 321, 330-332 Verfahrens- und Schutzregelungen 121, 122 Videoanalyse s. Beobachtungsinterviews Vielseitigkeit (Leitsätze zur Aufgabengestaltung nach DIN EN ISO 9241-2) 57, 58, 168, 199 Vorgehensmodell zum Usability Management 13, 79-274, 337 Gesamtdarstellung 79-106 Modul „Schulung“ 13, 80, 83, 8-88, 100, 102, 236, 239256 Phase „Anforderungsanalyse“ 13, 19, 30, 35, 43, 44, 80, 81, 83, 84, 86, 91, 94, 111, 126, 131, 133-171, 173-175, 180, 185, 187, 235, 241, 243, 246, 249, 264, 265, 286, 288 Phase „Go Live & Optimierung“ 13, 80, 81, 83, 86,

W Wartung und Pflege des Lernsystems 250, 251 Wegwerfprototypen s. Prototypen Wireframes 348 Wirkungskontrolle 276, 309-314 der Benutzerschulungen 253-256 Wissen (Erfolgsfaktor) 318, 326-328, 331, 332 Workflow 44, 98, 99, 137, 139, 154, 155, 214, 231 Workshops 126, 164, 166, 167, 169, 170, 175, 176, 179-186, 193-195, 197, 201, 205-210

Z Zeitdruck 23, 37, 40, 43 Zielklarheit (Erfolgsfaktor) 318, 321-326, 332 Zielworkshop 111, 112 Zufriedenheit (der Benutzer) 2, 3, 6, 10, 14, 24, 30-33, 37, 49, 51, 92, 112, 146, 164, 213, 241, 261, 264, 321, 329, 335, 351 Zufriedenstellung 49, 111, 133

379