Durchschaubare Modellierung des Arbeitssystems
Einleitung - Steuerbarkeit - Sichtbarkeit -Natürliche Symbole - Umgang mit Fehlern - Einfachheit - Intuitive Bedienung - Anpassbarkeit - Regelungen
Es ist der große Vorteil des grafischen Benutzer-Interfaces, Abläufe und Aufgaben symbolisch-modellhaft darstellen zu können, ganz im Gegensatz zum alphanumerischen Terminal der traditionellen Multi-User-Systeme, die nur Text und Zahlen zeilenweise über ihre Bildschirme abrollen konnten.
Die Einführung eines neuen Anwendungssystems ist immer eine Chance, ein Arbeitssystem neu zu ordnen und neu zu strukturieren. Und hier setzt auch die Kunst wirklich guten Software-Designs an; sie hat Tradition mit Innovation zu verbinden. Die von vielen Arbeitgebern vor allem gegenüber ihren Betriebsräten benutzte Formel
“wir stellen das alte System ja nur 1:1 auf ein neues System um”,
mag zwar als Beruhigungsformel gedacht sein, stellt in Wirklichkeit aber ein Alarmsignal dar, denn wieder einmal wurde die Chance zu einer Neugestaltung und einer damit verbundenen Verbesserung des Arbeitssystems nicht genutzt.
An der traditionellen Vorgehensweise bei der Herstellung von Software ist zu kritisieren, dass sie sich bei der Modellierung des Arbeitssystems an allerlei abstrakten Dingen wie Datenflussplänen und dergleichen orientiert und die Benutzerschnittstelle erst ganz am Schluss ins Visier nimmt, wenn bereits so gut wie alles festgelegt ist. Bei dieser verrichtungs- oder transaktionsorientierten Software sind die Abläufe oft in klein-klein festgelegt, im wahrsten Sinne des Wortes vorprogrammiert, so dass für die Benutzer nur noch die sehr passive Rolle des “Systembedieners” bleibt, durchaus vergleichbar mit einem Arbeiter, der in ein hochautomatisiertes Handhabungssystem Werkstücke einlegt, nur dass die “Werkstücke” beim Computersystem aus abgeforderten Informationen bestehen.
Alle diese - wie wir vermuten nur zum geringeren Teil offenen, überwiegend heimlich-unbewusst verlaufenden - Entscheidungen werden mit dem “Design” des Software-Systems getroffen.
Wie schwer das Modellieren des Arbeitssystems ist, kann man vor allem an einer Flut von sogenannter Branchensoftware für Personal Computer studieren. Programme, die geschrieben waren für Personal Computer als wären sie Großrechner der Achtziger, bestenfalls frühen Neunziger Jahre, mit über die Tastatur “durchzusteuernden” Menüs und Masken, wie gehabt beim traditionellen Multi-User-System, werden modisch flott umgekupfert auf Windows-Oberflächen. Die Masken sind nun bunter geworden, muten mit Hervorhebungen und Versenkungen dreidimensional an, aber sind die alte Anwendung, vordergründig augenfällig verpackt in netten Fensterchen, doch der Benutzer bleibt Menüauswähler und Dateneingeber.
Das Arbeitssystem gut zu modellieren, heißt zuallererst, die Rolle des Menschen im Umgang mit den Arbeitsgegenständen und -prozessen zu bestimmen. Es muss klar erkennbar werden, was quasi automatisch abläuft und was vom Benutzer zu tun ist, in seiner Verantwortung liegt. Die Gegenstände der Arbeit müssen als solche auch leicht erkennbar sein. Wer kennt sie nicht, die unzähligen Programme, in denen man stundenlang Buchungen durchführt, Bestellungen aufgibt oder Wareneingänge bestätigt, ohne auch je nur einen dieser Vorgänge selbst zu Gesicht bekommen zu haben. Man hat immer nur Masken ausgefüllt und Transaktionen ausgelöst und musste sich im übrigen darauf verlassen, dass hinter den Bildschirm-Kulissen der Computer es schon richten wird.
Techniken objektorientierter Programmierung, wie sie jedem grafischen Benutzer-Interface zugrundeliegen, erleichtern die Modellierung des Arbeitssystems immens. Sie legen es nahe, die in der Arbeit vorkommenden Gegenstände und Abläufe auch in den Programmen symbolisch darzustellen. Die mit den “Objekten” anzustellenden Operationen werden abgebildet als Botschaften, die von einem solchen Objekt zu einem anderen geschickt werden und dieses dann veranlassen, etwas zu tun. Auf diese Weise werden Interaktionen abgebildet, nicht Transaktionen. Unterstützt wird die Zusammenarbeit zwischen Menschen, nicht der “Dialogpartner” des Benutzers durch das System ersetzt.
Die Gegenstände der Arbeit und die Aktionen, die man mit ihnen anstellen kann, müssen bei guter Software ohne Anstrengung erkennbar sein, sozusagen auf der Hand liegen, klar sein, ohne logisches oder anderweitig akrobatisches Denken vom Benutzer abzuverlangen, also offenkundig zu erkennen sein wie die meisten Dinge des Alltags. Die Möglichkeit, Gegenstände grafisch-symbolisch darzustellen, ist bei diesem Anliegen eine Hilfe, die kaum hoch genug eingeschätzt werden kann.
Wenn z.B. die Aufgabe darin besteht, im Rahmen einer Auftragsvorbereitung Artikel oder Halbfertigprodukte einzukaufen, so kann dieser Arbeitsvorgang dadurch symbolisiert werden, dass der Artikel als Symbol dargestellt (oder als Photo abgebildet) wird mit allen Angaben über Lieferant, Preise und was sonst noch nützlich ist, über den Artikel zu wissen.
Die Bestellung wird dann z.B. abgewickelt, indem der Benutzer mit Unterstützung des Computers den Bestellbrief erstellt oder ein entsprechendes Formular ausfüllt. Der Computer wählt automatisch einen vom Benutzer voreingestellten Vordruck aus, setzt alle Angaben von Adresse und Ansprechperson angefangen bis zur Bezeichnung des Artikels in das Briefformular ein, der Benutzer gibt die gewünschte Menge ein, der Computer rechnet die Preise (mit oder ohne Mehrwertsteuer usw.) aus, und der Benutzer kann den gesamten Vorgang in allen Phasen kontrollieren, korrigierend eingreifen oder einfach nur bestätigen, was das Programm vorschlägt.
Anschließend wird der Brief entweder sofort gedruckt oder direkt aus dem Computer als Fax oder E-Mail versandt oder in eine Warteschlange gestellt, um zu einem späteren Zeitpunkt zusammen mit vielen anderen Briefen ausgedruckt und abgeschickt zu werden.
Schließlich wird die ganze Aktion in einem elektronischen Logbuch festgehalten, um später z.B. überprüfen zu können, ob die Ware auch termingerecht im Lager eingegangen ist.
Die Transparenz der Arbeitsabläufe, d.h. die einfache, klare Wiedererkennbarkeit der Vorgänge, die es auch erlaubt, die Zusammenhänge zu erkennen, in denen der jeweilige Arbeitsschritt steht, ist eine äußerst wichtige Anforderung an eine Software, die das Prädikat gut verdienen soll.
Wenn man nun die Forderung nach einer “aufgabengerechten” Modellierung des Arbeitssystems aufstellt, so sollte man auch darüber nachdenken, wer denn diese Modellierung durchführen soll. Bei Standardsoftware, so wird man gleich einwenden, erübrigt sich dieses Anliegen, handelt es sich doch um Ware, die man sozusagen “von der Stange” kauft. Ganz so einfach sollte man es sich nicht machen; auch Standardsoftware ist anpassbar an die betrieblichen Abläufe. Geschieht dies nicht, und wird stattdessen der Betrieb an die Software angepasst, so ist das in den allerseltensten Fällen ein sachlicher Zwang, sondern oft Mangel an Nachdenken, Mangel an Phantasie, Mangel an Kompetenz oder alles dies zusammen. Man darf durchaus vermuten, dass die Marktrenner der Standard-Software wie z.B. die Programme der Firma SAP unter anderem dieser “Befreiung” der Anwender-Firma von der lästigen Qual des Nachdenkens seine großen wirtschaftlichen Erfolge verdankt. Denn mit der Software mitgeliefert wird ein Fahrplan für die Einführung, der herunterreicht bis in die Zusammensetzung eines jeden in einer Datei benutzten Schlüssels (siehe ASAP - Accelerated SAP).
Bei einer im Unternehmen selbst entwickelten Software gelten die Entschuldigungen mit dem Verweis auf eingekaufte Standards nur noch sehr bedingt. Man kann schelchterdings nicht alles auf das verwendete Datenbankprodukt abwälzen. Die Verantwortlichen sind also in den eigenen Reihen zu suchen.
Die abstrakte Natur des Computers stellt eine besondere Schwierigkeit, aber auch eine Herausforderung an den Designer oder das Designer-Team dar. Gesteuert wird das Gerät elektronisch, unsichtbar, ohne dass irgend etwas auf die im Innern durchgeführten Operationen hinweist. Entsprechend abstrakt und formal sind auch die “Befehlssprachen”, mit deren Hilfe die dann später Programm genannten Anweisungen an den Computer formuliert werden. Sie erlauben es, exakt und detailliert der Maschine Computer genau zu sagen, was sie wann zu tun hat.
Diese Sprachen sind aber nicht gut geeignet, um die Bedürfnisse der Benutzer zu beschreiben. Die Gestaltung eines Programms erfordert eine Mischung aus Sachkenntnis, die sowohl die technischen Fähigkeiten des Umgangs mit dem “Innenleben” des Computers als auch Kenntnisse der Arbeitsaufgabe umfasst und darüber hinaus Kenntnisse der Bedürfnisse und Fähigkeiten der Benutzer. Vielleicht ist es total falsch, Programmierer überhaupt für die Interaktion zwischen Computer und Benutzer zuständig zu machen. Jedenfalls ist dies keine Fähigkeit, die sie gelernt haben. Es geht kein Weg daran vorbei: Man muss die Beteiligung der späteren Anwender bereits - nein gerade - am Entwurf des neuen computerunterstützten Arbeitssystems irgendwie auf die Reihe bekommen.
tse Hamburg |
239 / 167 |