Der Anwender als Interviewpartner, Ideenlieferant, Betroffener(Folge 1):

Benutzer-Partizipation in der Systementwicklung

22.10.1982

Seit etwa 1965 werden unliebsame Erscheinungsformen infolge von Software-Anwendungen mit dem Begriff "Softwarekrise" umschrieben. In dem folgenden Beitrag wird das Spannungsfeld zwischen Software-Entwicklungsteam und Benutzer analysiert. Mögliche Lösungswege aus diesem mehr als "Benutzerkrise", denn als "Softwarekrise" zu benennenden Problemkreis fordern eine Integration des Anwenders in die Systementwicklung und den konsequenten Dialog der beteiligten Parteien.

Eine Auswertung von Literaturstellen im Hinblick auf den Begriff "Softwarekrise" führte zu dem Ergebnis, daß bei den jeweiligen Autoren sehr unterschiedliche Auffassungen über die Bedeutung und den Gebrauch des Begriffs festzustellen waren/1/.

Der Begriff "Softwarekrise" wird angewandt, wenn zum Ausdruck gebracht werden soll, daß zum einen die Ergebnisse der eigentlichen Softwareproduktion unbefriedigend sind (Qualität, Kosten, Zeit) und zum anderen das mit der Produktion in Wechselbeziehung stehende Umfeld eine denkbar schlechte Voraussetzung für eine optimale Systementwicklung bietet.

Im Mittelpunkt jüngster Betrachtungen standen vor allem die Umfeld-Faktoren, die die Stellung des Benutzers im Entwicklungsprozeß bestimmen. Denn durch die verstärkte Einbeziehung der Interessen und Anforderungen des Software-"Abnehmers" sollte vermieden werden, daß zukünftig nicht nur von der "Softwarekrise", sondern darüber hinaus von der "Benutzerkrise" gesprochen werden muß (Bild 1).

Diese Hinwendung zum "Benutzer" führt bereits ein weiteres Mal zu definitorischen Schwierigkeiten. In der Literatur sind nämlich für diesen Begriff zusätzliche Ausdrücke wie Endbenutzer, naive Benutzer oder Anwender gebräuchlich. Es war daher notwendig, aus der Sicht der Software-Empfänger (hier: Fachabteilungen eines Industriebetriebes) die Eigenschaften eines "Benutzers" zu beschreiben, um so einen konkreten Bezug für die zu untersuchende Situation des Benutzers im Hinblick auf die EDV-Systemgestaltung zu erhalten (Bild 2).

Bei der Entwicklung und beim Einsatz computerunterstützter Informationssysteme setzt sich der Benutzer positiven und/oder negativen Veränderungen aus.

Anspruchsformulierung bedingt Interessendefinition

Um es nicht zu negativen Veränderungen kommen zu lassen, sind aus der Sicht der Benutzer "Anforderungen" im Hinblick auf die Systemgestaltung aufzustellen. "Anforderungen stellen" heißt, nach etwas verlangen, einen Anspruch geltend machen. Bevor jedoch Ansprüche formuliert werden können, muß Klarheit darüber bestehen, welche Interessen mit der Anmeldung der Ansprüche verfolgt werden sollen. Ausgangspunkt für das Aufstellen von Benutzeranforderungen ist demnach das Bewußtsein, Benutzerinteressen zu haben und wahrnehmen zu können.

Wenn die Forderungen der Benutzer an die Systementwicklung oder im Zusammenhang mit dem Systemeinsatz erfüllt werden, dann kann diese Vorgehensweise als "benutzerfreundliche" Systemgestaltung und -anwendung bezeichnet werden. In Bild 3 wird der Zusammenhang von Benutzerinteressen, Benutzeranforderungen und Benutzerfreundlichkeit dargestellt. Folglich ist es nicht vertrauenserweckend, von "benutzerfreundlichen" Modellen, Systemen und Bildschirmen zu sprechen, wenn der Begriff "benutzerfreundlich" nicht jeweils im Beziehungszusammenhang erklärt wird.

Die eigentliche EDV-Systementwicklung unterliegt ähnlich wie bei der Entwicklung eines neuen Produktes einer Planungs- und Realisierungslogik. Diese Logik wird in einem entsprechenden Planungskonzept wirksam. Die Gliederung des Planungskonzeptes in sogenannte "Phasen" hat zum Ziel,

- insbesondere komplexe Aufgaben in logisch aufeinanderfolgenden Einzelschritten konkret zu beschreiben und den mit der Lösung der Aufgabe verbundenen Aufwand anzugeben,

- eine Möglichkeit zu bieten, die Fertigstellung der Phasenschritte nachprüfbar zu machen und je nach Prüfungsergebnis die Entscheidungsfindung über die Fortsetzung des Projektes zu unterstützen sowie

- die gegenseitig eingegangenen Verpflichtungen der Projektbeteiligten (Auftraggeber, Benutzer, Systementwickler) phasenbezogen festzuhalten.

In der Literatur gehen die Meinungen über die einen Entwicklungsprozeß bestimmende Phasengliederung in der Systematik und in der Sprache weit auseinander /1/. Dieses Ergebnis einer Literaturuntersuchung kennzeichnet folgende mißliche Situationen (Bild 4):

- Ein Softwarehaus bietet eine problembezogene Softwareleistung an die nach anbieterspezifischen Phasen gegliedert ist. Der Softwareabnehmer ist dann kaum in der Lage Preis-/Leistungsvergleiche mit anderen Anbietern anzustellen, da diese Anbieter ebenfalls eigene hausinterne Phasengliederungen ihrem Angebot zugrundelegen.

- Aus der Sicht der späteren Benutzer (Fachabteilungen einer Branche) werden die zu treffenden Vereinbarungen über eine phasenbezogene Beteiligung bei der Entwicklung und/oder bei der Systemanwendung erschwert, da Erfahrungswerte (Benutzeranforderungen, Kosten, Zeit) inhaltlich ähnlicher Projekte kaum vergleichbar vorliegen und somit als Grundlage künftiger Vereinbarungen nicht herangezogen werden können. Es bleibt beim Benutzer das Gefühl des "Ausgeliefertseins" gegenüber dem EDV-System.

Bei der inhaltlichen Bestimmung der heute gebräuchlichen Phasengliederung wird in einigen Phasenschritten der spätere "Benutzer" erwähnt. Beispielsweise tritt der Benutzer als Interviewpartner bei der Ist-Analyse, als Ideenlieferant bei der Soll-Konzeption sowie als Betroffener bei der Systemeinführung auf. Diese, insbesondere in der Vergangenheit übliche nebensächliche Einstufung des Benutzers bei der EDV-Systemgestaltung ist nicht zuletzt ein Grund für die Software- und Benutzerkrise. In jüngster Zeit wurde deshalb an unterschiedlichen Stellen (Forscher, Ministerien, Gewerkschaften, Softwarehäuser) darüber nachgedacht, wie man den Benutzer bewußter an dem Systementwicklungs- und Anwendungsprozeß partizipieren lassen kann. Letztendlich soll das Betreiben eines EDV-Systems für die in Betracht kommenden verschiedenen Interessenvertreter effizienter gestaltet werden, um so einen entscheidenen Beitrag zur Senkung der "Gesamt"-Kosten eines EDV-Systems zu liefern.

In der deutschen betriebswirtschaftlichen Literatur hat es dabei den Anschein, als würde der Terminus "Partizipation" eher für nicht gesetzlich vorgeschriebene Formen der Teilnahme am Entscheidungsprozeß Verwendung finden, während die Bezeichnung "Mitbestimmung" sich mehr für die formale, juristisch-institutionelle Diskussion durchsetzt. Beim Gebrauch des Begriffs "Partizipation" sind insbesondere die Voraussetzungen für eine Beteiligung und die Formen der Partizipation zu berücksichtigen. Als Voraussetzungen werden beispielsweise angegeben:

- Bildungsbarrieren sind vor dem Entwicklungsprozeß abzubauen.

- Das Zeitbudget ist ausreichend zu bemessen.

- Ein Recht auf Beteiligung muß geltend gemacht werden.

Die im betrieblichen Alltag vorkommenden Formen der Partizipation lassen sich unterscheiden:

- im Teilnehmerkreis,

- in den Legitimitätsgrundlagen,

- in organisatorischen Normen und Regelungen sowie

- in den Absichten, mit denen sie eingeführt werden /2/.

Das Ergebnis einer durchgeführten Literaturrecherche zeigte, daß die Autoren "Partizipation" sehr unterschiedlich definieren /1/. Hierbei gibt die von /3/ angegebene Beschreibung der Funktion "Partizipation" am ehesten eine brauchbare Erklärung dieses Begriffes wieder:

Partizipation hat zwei Funktionen:

- Mitarbeit und Mitentscheidung; die Beteiligten erarbeiten gemeinsam Ergebnisse und entscheiden gemeinsam.

- Kontrolle; die Beteiligten achten auf die Wahrung eigener Interessen.

In Analogie zu den Systementwicklungsphasen bietet es sich unter der besonderen Einbeziehung des Partizipationsgedankens an, ein Partizipationsphasenschema zu entwickeln (Bild 5). In Anlehnung an die von /4/ vorgeschlagene Abstufung von Beteiligung (Peiner Modell) wurde dieses auf die EDV-Systementwicklung und -anwendung bezogene Phasenschema mit dem Ziel entwickelt, die bekannten EDV-Systementwicklungsphasen und die Partizipationsphasen abzustimmen, um so für den Benutzer die Möglichkeit zu schaffen, in definierten Entwicklungsschritten seine Interessen zum Ausdruck zu bringen, Anforderungen zu stellen und so insgesamt die Qualität des entstehenden Softwareprodukts

zu erhöhen. Forsetzung folgt