These III

Die elektronische Unterstützung von Geschäftsprozessen geht einher mit Änderungen im Vokabular und in der Terminologie. Wird das nicht berücksichtigt, können Nutzungsprobleme die Folge sein.

2.3.3.1 Beispiel: E-Procurement-System (User-Interface-Metapher)

Das bisherige innerbetriebliche Beschaffungswesen großer Unternehmen unterliegt vielen Regeln und Hierarchiestufen. Bildet man einen solchen Prozess im Rahmen eines Intranets elektronisch ab, ändern sich nicht nur Regeln und Hierarchiestufen werden abgeschafft, sondern es ändert sich auch das Vokabular das den Arbeitsprozess beschreibt. Beschaffungsprozess ist die Bezeichnung eines Geschäftsprozesses aus Management-Sicht. Dieser Prozess besteht vereinfacht gesehen aus den Schritten: Anforderung Æ Genehmigung Æ Bestellung. Alle drei Schritte werden von unterschied-lichen Abteilungen verantwortet (Abb.10 links):

Abbildung 10: Terminologie im traditionellen und elektronischen Geschäftsprozess

Der neue E-Procurement-Prozess, im vorliegenden Fall in einem Telekommunikationsunternehmen, ist nun so konzipiert, dass die Person, die etwas bestellen will, sich die Ware aus einem elektro-nischen Katalog selbst heraussucht (Abb.13, S. 33) und in einen Einkaufskorb übernimmt. Zusätzlich muss der Nutzer Angaben zur Kostenstelle, Lieferadresse u.ä. machen Dieser Vorgang (hier Einkaufswagen benannt) wird dann auf den vorgesehenen Genehmigungsweg geschickt. Die bisher für Bestellungen zuständige Einkaufsabteilung erhält die Bestellung in der Regel nur noch zur Kenntnisnahme. Im Gegensatz zum bisherigen Geschäftsprozess besteht die Aufgabe der Einkaufs-abteilung darin, Rahmenverträge mit Lieferanten zu verhandeln. Innerhalb dieser Rahmenverträge bestellen die Endnutzer, wie oben beschrieben, selbst. Die Vermischung von Fachvokabular des herkömmlichen Prozesses und des heute durchgängig IT-gestützten E-Procurement-Prozesses in der Anforderungsdokumentation und für Interface-Elemente führt zu Nutzungsproblemen. Denn die jeweiligen Benennungen repräsentieren auch die Logik der jeweiligen Arbeitsabläufe und die Hierarchie der Informationen. Die Fachabteilung spricht bisher von Anforderung, die Einkaufs-abteilung von Bestellung. Im E-Procurement-Prozess bestellen jetzt Nutzer der FachEinkaufs-abteilung selbst.

Zwar gibt es, wie bisher, einen hinterlegten, aber wesentlich verschlankten Genehmigungsprozess, aber die Aktivität „anfordern“ gibt es nicht mehr. Stattdessen beginnt der Prozess mit der Aktivität

„Bezugsquelle finden“, da es sein kann, dass ein Artikel von verschiedenen Herstellern angeboten wird. Diese Auswahl war früher der Einkaufsabteilung vorbehalten. Bezugsquellen sind verschiedene elektronische Kataloge, weshalb umgangssprachlich von „Katalogbeschaffung“ gesprochen wird. Für den Fall, dass der Nutzer keine Bezugsquelle kennt oder findet, ist eine Freitextbestellung vor-gesehen. Hierfür muss eine Anforderung ausführlich textuell beschrieben werden. Diese Freitext-bestellungen gehen dann zur Bearbeitung an die Einkaufsabteilung, sind jedoch nicht gerne gesehen.

Die Übernahme der im E-Business verbreiteten Metapher des Einkaufswagens impliziert sprachliche und handlungslogische Probleme. So müssen Nutzer den Status eines Einkaufswagens prüfen oder neben Waren auch Personen in den Einkaufswagen legen, wenn es sich um eine Dienstleis-tungsanforderung handelt (z.B. einen Programmierer mit Java-Kenntnissen für Projekt X). Denn das E-Procurement-System wird für Bestellungen im weitesten Sinn verwandt. Es können Waren ebenso bestellt, wie für Projekte damit Personen und Ausstattung zusammengestellt werden.

Irritationen entstehen auch durch einen Vermischung von fachlichen und eher funktional motivierten Benennungen. So ist die Bedeutung der unter dem Bestellformular (Abb.11) angeordneten Schalt-flächen Bestellen, Merken, Aktualisieren und Prüfen für Nutzer, die eine Bestellung abschließen wollen, eher verwirrend. Dem Nutzer stellen sich hier Fragen, die ihn bei der Bearbeitung seiner eigentlichen Aufgabe, nämlich eine Bestellung aufzugeben, hindern. Die Funktionalität der Schalt-flächen bestimmt den Status, den Warenkörbe im elektronischen Prozess zugewiesen bekommen.

Abbildung 11: Semantisch inkonsistente Benennung von Schaltflächen (EBEST, SAP/T-Systems)

Das Auslösen der Schaltfläche Bestellen führt im Gegensatz zu Merken zu einer „SAP-Bestellung“.

Die Bezeichnung „SAP-Bestellung“ assoziiert, dass es noch andere Bestellungen geben könnte.

Merken löst das Speichern ausgewählter Waren oder Dienstleistungen für eine spätere oder erneute Bestellung aus. Allerdings schließt sich, nicht erwartungskonform, das Fenster bei Betätigen der Schaltfläche. Erschwerend kommt hinzu, dass Einkaufswagen (= Bestellungen), deren Inhalte sich Nutzer merken wollen, in einer anderen Maske mit alle, die noch keine SAP Bestellung haben bezeichnet sind. Die beiden anderen Schaltflächen Aktualisieren und Prüfen konnte kaum ein Nutzer schlüssig erklären.

Die Formulierung des Hilfetextes in Abb.12 verdeutlicht das sprachliche Dilemma. Wie kann man einen Einkaufswagen drucken oder fertigstellen? Wieso muss man fertigstellen über die Benennung Status prüfen auslösen und was ist der Unterschied zwischen fertigstellen und Bestellen? Die sprachlichen Mängel werden noch kombiniert mit einer inkonsistenten Interaktionsgestaltung. Die genannten Aktionen werden hier in Form von Links angeboten, statt wie an anderer Stelle über Schaltflächen.

Abbildung 12: Metapherkonträrer Hilfetext (EBEST, SAP/T-Systems)

Neben der mangelhaft reflektierten Übernahme der Einkaufswagen-Metapher wurden auch Benen-nungen gängiger kommerzieller Web-Anwendungen „abgeguckt“. Die Benennung eines Menütitels Einkaufen für mich (Abb.9) ist der Personalisierungsfunktion kommerzieller Websites entlehnt und assoziiert, dass man noch für jemand anderen einkaufen kann, was definitiv nicht geht. Die Abfolge der unter diesem Menütitel angeordneten Menüelemente ist syntaktisch fragwürdig. Die Unterpunkte Einkaufen und Einkaufswagen könnte man synonym verstehen. Gemeint ist hier die initiale Aktivität eine Bestellung aufzugeben (einkaufen) und das Prüfen von bereits bestellten Waren oder Dienst-leistungen, die in einem Objekt Einkaufswagen zusammengefasst sind. Der Nutzer könnte auf die Idee kommen, dass man, wie in der realen Welt, zum Einkaufen zuerst einen Einkaufswagen nimmt, würde damit aber zum falschen Dialogfenster geführt. Das ebenfalls dort angeordnete Menüelement Status prüfen bezieht sich auf den Stand einer Bestellung, hier eines Einkaufwagens. Diese Vermischung von Aktivitäten und Objekten führt zu Irritationen hinsichtlich der Handlungsabläufe aus Sicht der Nutzer.

2.3.3.2 Beispiel: E-Procurement-System und elektronischer Katalog

Zunehmend sind Nutzer damit konfrontiert zur Bearbeitung einer Aufgabe mehrere Applikationen im Wechsel benutzen zu müssen. Dies sind z.B. Bestellsysteme und dazugehörige elektronische Waren-kataloge; fast alle gängigen E-Procurement-Systeme sind mit elektronischen Katalogen gekoppelt.

Hierbei handelt es sich entweder um Multi-Supplier- (integrierte Produkte mehrerer Lieferanten) oder Single-Supplier-Kataloge (je Lieferant ein Katalog). Die Applikationen kommen oft von unterschied-lichen Herstellern, die über kein validiertes Nutzungskonzept verfügen und damit unterschiedliche Benennungen im User Interface verwenden. Zwar findet für Multi-Supplier-Kataloge eine

ent-sprechende Datenaufbereitung¹⁶ statt, aber ein abgestimmtes Nutzer-Objekt-Modell gibt es zwischen den großen Herstellern dieser Softwareprodukte nicht. Indiz, wenn auch primär nur für eine Lokalisierung kritisch, ist die Verwendung der Benennungen Warenkorb und Einkaufswagen.

In Abb.13 ist das User Interface des E-Procurement-Systems zu sehen. Dieses ist für den Benutzer der Einstieg. Nachdem er sich hier angemeldet hat und dann etwas bestellen möchte, wechselt er von hier aus in die Applikation (elektronischer Warenkatalog) eines anderen Softwareherstellers (Abb.14) ohne dass ihm diese vielleicht bewusst ist. Dort ist die Navigation über zwei Register (Suche Æ Warenkorb) realisiert, wohingegen im User Interface des E-Procurement-Systems (Abb.13) die Navigation (Ware auswählen Æ Einkaufswagen Æ Vervollständigen und Bestellen) über die links vertikal angeordneten Optionen erfolgt. Abhängig von der ausgewählten Option wird rechts ein entsprechendes Formular angezeigt.

16 Für Multi-Supplier-Kataloge erfolgt eine technische Datenaufbereitung in Bezug auf vier Aspekte:

• Normalisierung der Daten, d.h. Aufbereitung lieferantenspezifischer Abkürzungen und Begriffe entsprechend einer standardisierten Terminologie; ein einfaches Beispiel wäre die Ersetzung von „schw“ durch „schwarz“.

• Lokalisierungsmaßnahmen, d.h. Anpassung an lokale bzw. nationale Gegebenheiten, z. B. bei der Darstellung von Fließkommazahlen (

„12.5“ wird zu „12,5“).

• Rationalisierung der Daten; in diesem Zusammenhang versteht man darunter eine Anordnung der Artikelbezeichnungen und -merkmale in einer definierten Reihenfolge, die Umwandlung von „schw. Tacker“ in „Klammerhefter, schwarz“ (wobei hier zusätzlich eine Normalisie-rung der Begriffe durchgeführt wurde).

• Integration der Daten in das eigene Klassifikationsschema. Bei der Klassifizierung werden Produkte mit ähnlichen Eigenschaften zu Klassen bzw. Kategorien zusammengefasst, die in einem hierarchischen Schema (Taxonomie) angeordnet werden.

Abbildung 13: User Interface des E-Procurement-Systems (EBEST, SAP/T-Systems)

Abbildung 14: User Interface des elektronischen Katalogs (Premium Business Catalog, Heiler)

Die inkonsistente Realisierung der Navigation stellt ein unnötiges Erschwernis für Nutzer dar. Es kommt hinzu, dass sowohl für Objekte (Warenkorb/Einkaufswagen) als auch für Aktionen (Suchen/Start) in beiden User Interfaces (Abb.15) unterschiedliche Benennungen verwendet werden.

Abbildung 15: Unterschiedliche Benennungen für dieselben Objekte und Aktionen (EBEST, SAP/T-Systems/Premium Business Catalog, Heiler)

These III: Die „Elektrifizierung“ von Geschäftsprozessen führt zur Änderungen von Begriffen und Benennungen, die in User Interfaces nicht konsistent nutzungsgerecht umgesetzt werden.

Der Wandel herkömmlicher Geschäftsprozesse zu elektronischen Geschäftsprozessen ist verbunden mit einer Veränderung von Terminologie und Vokabular. Softwareentwicklungen basieren im ersten Schritt oft auf Beschreibungen von Geschäftsprozessen. Diese dienen dem Management zur Unternehmenssteuerung und Entwicklern zur Modellierung der fachlichen Logik. Derartige Geschäftsprozessbeschreibungen liegen in einigen Fällen in ausführlich dokumentierter, begrifflich konsolidierter Form (ggf. in ARIS) vor. In vielen Fällen liegen jedoch veraltete Beschreibungen von Geschäftsprozessen vor, existieren noch z.B. daraus abgeleitete Arbeitsanweisungen mit ent-sprechendem Vokabular. In vielen Fällen resultiert die sprachliche Qualität dieser Dokumente allein

Unterschiedliche Benennung für dieselbe Funktion Unterschiedliche Benennung desselben Objekts

User Interfaces des elektronischen Katalogs

User Interfaces der E-Procurement-Applikation Unterschiedliche Benennung für dieselbe Funktion

Unterschiedliche Benennung desselben Objekts

User Interfaces des elektronischen Katalogs

User Interfaces der E-Procurement-Applikation

aus der Eloquenz des Verfassers. Die Ebene, auf der Geschäftsprozesse beschrieben werden, ist eher abstrakt, es fehlt ein Abgleich der Benennungen mit anderen zu koordinierenden Prozessen auf Konsistenz, Granularität, Schnittstellen u.a. Problematisch ist, wenn derartige Prozessbeschreibungen in Form eines Lastenheftes Grundlage einer Ausschreibung für eine Softwareentwicklung werden.

Software-Hersteller erstellen daraus ggf. ein Pflichtenheft, das sowohl vertragliche Grundlage für die Softwareentwicklung als auch Grundlage für die im weiteren Verlauf zu erstellende Feinspezifika-tionen ist. Viele Unternehmen verfügen weder über Prozessbeschreibungen noch Darstellungen in Form von sprachlich reduziert beschriebenen Flussdiagrammen.

Wenn nun auch noch IT-getrieben neue elektronische Geschäftsprozesse mit neuen Begriffen ent-worfen und implementiert werden, führt dies bei einer fehlenden Sprachkonsolidierung zu Nutzungsproblemen.