Methodenberg und Sprachbarrieren hemmen die Benutzerintegration, Folge 2:

Dialog im Frühstadium senkt Projektfolgekosten

29.10.1982

Von Tilman Greiner und Hans-Friederich Jacobi*

Methoden, Verfahren oder Werkzeuge zur Entwicklung computerunterstützter Informationssysteme erscheinen in erster Linie dafür ausgelegt, den Spezialisten, also den Systemanalytiker, den Anwendungs- oder Organisationsprogrammierer zu unterstützen. Darüber hinaus fordern sie nach Angaben ihrer Hersteller die Effizienz des Entwicklungsprozesses und führen zu konsistenten, übersichtlichen, transparenten und damit auch bequem zu wartenden Systemen. Was allerdings dabei oft nicht in Betracht gezogen wird, sind die Akzeptanzprobleme, die bei der organisatorischen Implementierung der Systeme und bei deren anschließenden Betrieb auftreten.

Die Akzeptanzprobleme führen nicht selten zu umfangreichen und in der Regel teuren Änderungsmaßnahmen, die sich überdies mehrmals wiederholen können. Der Benutzer kann sich oft mit dem System nicht identifizieren, er lehnt es ab, umgeht es, boykottiert es sogar teilweise oder arbeitet mit ihm nur unter großer Unzufriedenheit.

Derartige Reaktionen sind im allgemeinen darauf zurückzuführen, daß der Benutzer während der Entwicklung des Systems gar nicht oder nur als Informationslieferant beteiligt wurde. Neben vielen anderen Einflußgrößen mag das daran liegen, daß die notwendigen Entwicklungsinstrumente fehlen, die die Einbeziehung des künftigen Benutzers eines Systems besonders berücksichtigen.

In diesem Zusammenhang erscheint es deshalb sinnvoll, bestehende Verfahren, Methoden und Werkzeuge dahingehend zu untersuchen, ob sie die Beteiligung des Benutzers an dem Systementwicklungsprozeß unterstützen.

Zwei Fragen sind von besonderem Interesse:

1. Wird dem Benutzer ein durch aufbau- beziehungsweise ablauforganisatorische Regelung innerhalb des untersuchten Verfahrens abgesichertes Mitentscheidungsrecht eingeräumt?

2. Entsprechen die Systementwicklungsinstrumente der Gedankenwelt des Benutzers?

Die erste Frage bezieht sich überwiegend auf die institutionell und funktionell wirkenden Modelle und Verfahren zur Organisation des Entwicklungsprozesses. Insbesondere die herkömmlichen Methoden der institutionellen Organisation wie beispielsweise Adaptive Team, Chief Programmer Team oder teilautonome Gruppen bieten kaum die Möglichkeiten für eine konstruktive Benutzerbeteiligung. Hierbei handelt es sich meist um Modelle, mit denen die Arbeit von Spezialisten der Systementwicklung institutionell geregelt werden soll. Die Methode des Chief Programmer Teams etwa orientiert sich an der Struktur der zu entwickelnden Software. Die Softwarebausteine markieren die Kompetenz- und Verantwortungsbereiche der an der Entwicklung beteiligten Personen. Nur der Team-Leiter besitzt einen vollständigen Überblick. Die Kommunikation der Mitglieder erfolgt nach der Art des Dienstweges.

Die Übertragung derartig formaler Organisationsmethoden auf die Entwicklung betrieblicher, computerunterstützter Informationssysteme, bei der der Benutzer mitwirken soll, erscheint mehr als fraglich. Entwicklungsverfahren, in denen hierarchische Strukturen festgeschrieben sind, verleiten die Systemeigner leicht dazu, den Benutzer, wenn überhaupt, auf der untersten Ebene mitarbeiten zu lassen. Dort hat er dann bei der Konzeption eines engen, abgegrenzten Aufgabenbereiches (Modul) mitzuwirken. Im Hinblick auf einen reibungslosen Projektverlauf wird ihm eine Teilaufgabe zugeteilt, die seiner bisherigen Arbeit entspricht. Ihm bleibt dann oft nur die Rolle des Informationslieferanten.

Modell zur Benutzerpartizipation

Auf Benutzerpartizipation zugeschnitten sind Systementwicklungsmodelle, wie sie beispielsweise Kubicek /5/ nennt. Hier werden unter anderem vier Entwicklungsmodelle vorgeschlagen, die einen unterschiedlichen Ausprägungsgrad der Benutzerbeteiligung besitzen:

- Modell "Kontrollierte Spezialistenarbeit"

Die Gestaltung wird ausschließlich von Spezialisten durchgeführt. Ihre Arbeit aber wird der Planung, Steuerung und Kontrolle durch den Lenkungsausschuß unterworfen. Im Lenkungsausschuß wirken Vertreter aller Interessengruppen mit.

- Modell "Gemischte Projektgruppen"

Die einzelnen Interessengruppen entsenden zusätzlich Mitarbeiter in die Projektgruppen, in denen die Gestaltung durchgeführt wird. Benutzer und Spezialisten arbeiten gemeinsam unter der Kontrolle des Lenkungsausschusses.

- Modell "Interessenspezifische parallele Arbeitsgruppen"

Dieses Modell besteht aus einer gemischten Projektgruppe, doch zusätzlich werden interessenspezifische Arbeitsgruppen gebildet, in denen dem notwendigen Willensbildungs- und Abstimmungsprozeß in den einzelnen Interessengruppen Rechnung getragen werden kann.

Die in den Arbeitsgruppen erarbeiteten Ergebnisse einer Situations- und Bedürfnisanalyse werden durch die in die Projektgruppen entsandten Vertreter in die dort zusammen mit Spezialisten stattfindende Gestaltungsarbeit eingebracht.

- Modell "Koordinierte Arbeitsgruppen"

Hier bildet jede Interessengruppe eine Arbeitsgruppe, die teils für sich, teils zusammen mit anderen Arbeitsgruppen alle Analyse-, Planungs- und Gestaltungsaufgaben wahrnimmt. Spezialisten gehören diesen Arbeitsgruppen nicht automatisch an, sondern bei Bedarf wird deren gezielte Beratung oder Mitwirkung angefordert.

Mehr aus dem Gebiet der Organisationstheorie kommen die soziotechnischen Ansätze der Systementwicklung. In ihnen wird davon ausgegangen, daß ein Organisationssystem aus einem technischen und einem sozialen Subsystem besteht und beide Systeme aufeinander abgestimmt werden müssen, wenn das Organisationssystem Bestand haben soll. Durch das technische Subsystem sollen logische Konsistenz und ökonomische Effizienz sichergestellt werden. Durch das soziale Subsystem sollen die Bedürfnisse der Organisationsmitglieder befriedigt werden. Dazu wird jeweils die Arbeitszufriedenheit der Betroffenen gemessen. Im Bild sind einige wichtige "sozial-orientierte

Entwicklungsverfahren wiedergegeben, zusammen mit ihren Autoren und dem Entwicklungsland. Auf die entsprechende Literatur, dazu wird in /1/ verwiesen.

Hilfsmittel dieser Art haben in der Bundesrepublik noch keinen großen Anwenderkreis gefunden. Deshalb soll hier nicht näher darauf eingegangen werden. Die Vermutung liegt nahe, daß gerade Systemeigner dem Einsatz dieser Hilfsmittel ihre Zustimmung wegen der Betonung des sozialen Aspekts versagen.

Wenn man bedenkt, daß etwa die in den skandinavischen Ländern entwickelten Hilfsmittel dort vor einem von der Bundesrepublik erheblich abweichenden politischen und gesellschaftlichen Hintergrund, der eben auch Auswirkungen auf das Zielsystem von wirtschaftlichen Unternehmen hat, entstanden sind, so erheben sich doch einige Zweifel an der Übertragbarkeit dieser Hilfsmittel auf deutsche Verhältnisse.

Derartige Verfahren, die den Benutzer fest in den Entwicklungsprozeß einbinden, ihn sogar zum Mittelpunkt erklären, haben nur dann eine Chance, eingesetzt zu werden, wenn mindestens zwei Voraussetzungen erfüllt sind:

1. Der Benutzer muß bereit sein, die von ihm getroffenen Entscheidungen und deren Auswirkung auf das System von zu verantworten, das heißt auch die Folgen eventueller Schwächen, die das entstandene System aufweist, mitzutragen.

2. Der Systemeigner muß von der Wirtschaftlichkeit dieser Methoden überzeugt sein. Wenn beispielsweise nachgewiesen werden könnte, daß dadurch die Wartung von Softwaresystemen erheblich gemindert werden könnte, würden diese Entwicklungsverfahren an Bedeutung gewinnen. In Schätzungen wird erwartet, daß sich die Kosten einer DV-Installation 1985 nur noch zu zehn Prozent aus Hardwarekosten, zu 90 Prozent aber aus Softwarekosten zusammensetzen. Die Softwarekosten teilen sich wieder in 75 Prozent Wartungskosten und 25 Prozent Entwicklungskosten auf. Wenn man bedenkt, daß über 40 Prozent dieses Wartungsaufwandes für Erweiterungen aufgrund von nachträglichen Benutzeranforderungen aufgebracht werden müssen, so ist es durchaus zulässig, davon auszugehen, daß derartige Verfahren helfen, die Wartungskosten zu senken.

Methodenberg abbauen

Neben diesen insbesondere unter dem Aspekt der Benutzerbeteiligung entworfenen Entwicklungsinstrumenten gibt es eine große Anzahl von Systementwicklungsmethoden, für die die Ziele "Effizienz" in der Systementwicklung und -anwendung, "Korrektheit" und "Flexibilität" allein maßgeblich sind. Gerade in der augenblicklichen konjunkturellen Lage, in der Investitionen besonders kritisch beurteilt werden, ist die Nachfrage nach effektiven Entwicklungsinstrumenten groß. Die Anbieter reagieren darauf entsprechend. Dies führt zu einem Methodenberg und zu einer Vielzahl von Entwicklungsinstrumenten, deren Vor- und Nachteile kaum vergleichend darstellbar sind.

Im folgenden werden zwei entscheidende Aspekte von Systementwicklungsverfahren herausgegriffen, die mit dafür bestimmend sind, ob eine Methode der Gedankenwelt und den Kommunikationsgewohnheiten eines Benutzers gerecht wird:

- Die Wahl des Beschreibungsmittels,

- die Wahl des Entwurfsprinzips.

Im Polaritätsprofil des Bildes 2 wird aufgezeigt, inwieweit sich die Anwendung eines Beschreibungsmittels innerhalb eines Verahrens auf die Benutzerbeteiligung auswirkt. Indirekt soll damit die Eignung von Beschreibungsmitteln zum selbständigen Gebrauch durch den Benutzer dargestellt werden.

Umgangssprache erleichtert Akzeptanz

Der Benutzer neigt zunächst dazu, seine Probleme und Lösungsvorschläge durch die Umgangssprache zu beschreiben. Alle Ansätze einer Formulierung wird er ablehnen, solange er nicht selbst mit dem Automatisierungsmedium in Kontakt tritt und mit diesem gestalten kann. Diese Möglichkeit besteht heute in der "verteilten" und "individuellen" Datenverarbeitung. Doch bei der Entwicklung komplexer Systeme mit einem großen Benutzerkreis hat der Benutzer während der Gestaltung in den seltensten Fällen Kontakt mit dem Gestaltungsmedium Computer. Formalisierungsbestrebungen der Sprache werden hier immer auf erhebliche Akzeptanzschwierigkeiten stoßen.

Formatisierung durchdenken

Zur systematischen Darstellung von Sachverhalten ist jedoch eine gewisse Formatisierung, beispielsweise durch Tabellen, unumgänglich. Dies ist dem Benutzer bekannt und wird von ihm akzeptiert. Jedoch mit wachsendem Formatisierungsgrad des ursprünglich informellen Kommunikationsmittels nimmt der Nutzen des Beschreibungsmittels für Benutzerpartizipation ab. Die konsequente Verwendung von Matrizen erschwert in der Regel die Beteiligung des Benutzers. Sie bringt in den meisten Fällen eine Bearbeitung mittels mathematischer Methoden mit sich und als Voraussetzung dafür eine Quantifizierung der Sachverhalte. Zudem sind sie wenig anschaulich und kaum einprägsam. Konkurrierende Darstellungsmittel wie beispielsweise Baumdiagramme oder netzartige Beschreibungen leisten oft bessere Dienste.

Grafische Beschreibungsmittel, insbesondere für geplante Abläufe, eignen sich sehr gut für die Veranschaulichung zunächst verbal formulierter Sachverhalte. Allerdings sollten diese Hilfsmittel dem Benutzer vertraut und die Anzahl der zu verwendenden unterschiedlichen Symbole beschränkt sein. Im Prinzip trifft dies für die in DIN 66001 genormten Ablaufdarstellungen zu. Sie haben jedoch den Nachteil, daß man sich leicht im "Gestrüpp der Kontrollpfade" verliert.

Fortsetzung folgt

LITERATUR

/1/ Greiner, T.; Jacobi, H.F.; Lay, K.; Scheifele, M.:Grundlagenuntersuchung zur Benutzerpartizipation bei Systementwicklungen. BMFT-Forschungsbericht. Stuttgart: Fraunhofer-Gesellschaft für Produktionstechnik und Automatisierung, 1981.

/2/ Scholl, W.; Gierl, K.; Paul, G.: Bedürfnisartikulation und Bedürfnisberücksichtigung in Unternehmen - Theoretischer Ansatz zur Analyse von Mitbestimmungsregelungen.

In: Arbeitsqualität in Organisationen. Hrsg.: Batölke, Kappler, Laske, Nieder. /3/ Essig, H.; Heibey, H.-W.; Kühn, M.; Rolf, A.:

BENORSY - ein formalisierter Ansatz zur partizipativen und benutzerorientierten Systemrevision.

In: Partizipation bei der Systementwicklung. Hrsg.: Mambrey, P.; Oppermann, R. IPES. 80206, St. Augustin: GMD, 1980.

/4/ Fricke, W.: Thesenpapier zur 2. Arbeitstagung "Partizipation bei der Systementwicklung" St. Augustin: GMD, 1981. /5/ Kubicek, H.: Interessenberücksichtigung beim Technikeinsatz im Büro- und Verwaltungsbereich. Bericht der GMD; Nr. 125; München; Wien: Oldenbourg-Verlag, 1979.

/6/ Österle, A.: Entwurf betrieblicher Informationssysteme. München, Wien: Hanser, 1981.