Benutzer denken anders als Systementwickler, Folge 3:

Methodenprofil steuert den Partizipationsgrad

05.11.1982

Akzeptanzprobleme vollständig formalisierter Beschreibungsmittel entfallen, wenn der Benutzer unmittelbar mit dem Gestaltungsmedium Computer in Kontakt tritt. Im Forschungs- und Entwicklungsbereich tritt dieser Fall häufig auf. Aber auch in anderen Betriebsbereichen verfügt der Benutzer in zunehmendem Maße über das Know-how und die entsprechende Hard- und Software, um mit Hilfe vollständig formalisierter Beschreibungsmittel seine eigenen Systeme selbständig entwickeln zu können.

Dieses Vorgehen stellt die ideale Benutzerpartizipation dar, da hierbei der Systemspezialist kaum oder, wenn Oberhaupt darin nur beratend in die Entwicklung eingreift. Allerdings darf man nicht übersehen, daß derartige Gestaltungsmöglichkeiten den wenigsten Benutzern zur Verfügung stehen und bisher nur für Spezialprobleme realisiert wurden.

Auch universelle Programmiersprachen zur Lösung einfacher Aufgaben, wie beispielsweise APL oder Basic, bieten dem Benutzer die Möglichkeit, selbständig Lösungen zu implementieren. Da jedoch diese Sprachen keinen ausgesprochen problembezogenen Charakter besitzen, ist vom Benutzer die zusätzliche Leistung zu erbringen, die EDV-Eignung von Teilproblemen seiner Arbeit zu erkennen.

Generiersprachen zur Entwicklung ganzer Anwendungssoftware-Systeme, mit Hilfe derer sich der Benutzer aus der Fachabteilung sein auf seine Bedürfnisse zugeschnittenes System selbst zusammenstellen kann, bieten ein Höchstmaß an Benutzerbeteiligung bei der Systementwicklung. Derartige Systeme befinden sich aber zum größten Teil noch im Experimentierstadium und benötigen noch einen langen Reifeprozeß, um wirkungsvoll durch den Benutzer eingesetzt zu werden.

Konstrukte problematisch

Prozedurale Sprachen wie etwa Pseudocode erfordern erhebliches EDV-Verständnis, da sie auf den Konstrukten Selektion, Iteration und Sequenz aufbauen. Da diese künstlichen aus der EDV stammenden Beschreibungsweisen nicht im beruflichen Alltag üblich sind und zudem nicht immer die ideale Abbildung von Sachverhalten darstellen, sind sie für eine Einbeziehung des Benutzers in den Entwicklungsprozeß ungeeignet. Das Gleiche gilt für nicht prozedurale Software-Systembeschreibungssprachen, wie beispielsweise PSA/PSL. Sie sind in der Regel nicht zu kommunikativen Zwecken entworfen worden, sondern beruhen auf der Idee, Konsistenz und Vollständigkeitsprüfungen bereits zum Entwurfszeitpunkt automatisch durchfuhren zu können, um so Entwurfsfehler zu entdecken, bevor das System programmiert wird.

Mathematische Beschreibungssprachen des technisch-organisatorischen Gesamtsystems, wie sie hauptsächlich von der organisationstheoretischen Forschung vorgeschlagen werden, sind für eine Einbeziehung des Benutzers vollkommen ungeeignet.

Das Polaritätsprofil des Bildes 1 stellt den Übereinstimmungsgrad bestimmter Entwurfsprinzipien, wie sie zum Teil auch Österle /6/ nennt, mit der Gedankenwelt und der Interessenslage des Benutzers dar.

Wendet man das Entwurfsprinzip der Dekomposition an, dann wird ein, entwickelndes System in Teilsysteme zerlegt. Diese Teilsysteme können en verhältnismäßig unabhängig voneinander entwickelt werden. Geht man vom Grundsatz der partiellen Betrachtung aus, so wird ein System im ganzen, jedoch unter verschiedenen Aspekten, in Angriff genommen. Letztere Vorgehensweise ist für den Benutzer interessanter. Seinen eigenen Mikrobereich (Subsystem), an dessen Bearbeitung er bei der Anwendung des Dekompositionsprinzips nach Ansicht der Systemgestalter und -eigner sinnvollerweise beteiligt wird, kennt er zur Genüge. Neue Erkenntnisse zur Verfolgung seiner Interessen gewinnt er aber nur, wenn er an der Gestaltung des gesamten Systems mitwirkt.

"Top down" oder "Bottom up"

Darüber hinaus ist es durch die partielle Betrachtung eines Systems möglich, neben fachlichen Aspekten wie Datenfluß, Ablauf und Datenstruktur auch Gesichtspunkte wie Benutzerfreundlichkeit oder organisatorische Flexibilität über das gesamte System im Auge zu behalten.

Der "Top-down-Entwurf" ist zwar übersichtlich und systematisch, er fordert aber auch einen großen Erfahrungsschatz und Kenntnisse über Theorien und Modelle aus dem Fachbereich und der Informatik. Gerade diese Voraussetzung bringt der Benutzer in der Regel nicht mit.

Bei ausschließlicher Anwendung des "Bottom-up-Ansatzes" tritt dagegen die systembezogene Schwierigkeit auf, die ungeordnete Menge von Informationssystemelementen zu übergeordneten Systemen zusammenzufassen. Dies ist jedoch vorwiegend ein Nachteil in den Augen von Systemspezialisten. Aus diesen Gründen wird aus der Sicht des Benutzers der Bottom-up-Ansatz zumindest abschnittsweise vorzuziehen sein.

Bei bestimmten Methoden stellt der ablauforientierte Aspekt die zentrale Komponente (etwa bei Composite Design) dar, bei anderen der aufbauorientierte (etwa bei HIPO). Der Mensch neigt dazu, Aufgaben als Folge von einzelnen Operationen zu verstehen. Dies zeigt die häufige Verwendung von Ablaufdarstellungen. Beispielsweise ist eine in der Praxis sehr weit verbreitete Ablaufdarstellung im organisatorischen Bereich das "Arbeitsablaufschema", eine tabellarische Darstellung der Zusammenhänge zwischen Aktionseinheiten und Tätigkeiten. Erst das Bedürfnis nach Systematik läßt, aufbauorientierte Darstellungen entstehen. Dieses Bedürfnis liegt jedoch zumeist bei den Systemspezialisten und nicht im unmittelbaren Interesse des Benutzers. Insofern eignen sich Methoden, die überwiegend ablauforientiert sind, besser zur Einbeziehung des Benutzers.

Bekannte Entwurfsmethoden (zum Beispiel Jackson) präferieren die datenorientierte Sichtweise, andere die funktionsorientierte (zum, Beispiel Composite Design). Im Sinne von Benutzerbeteiligung ist die erstere vorzuziehen, da sich der Benutzer leichter an Daten als an Funktionen orientiert. Daten sieht er täglich in Form von Listen und Formularen vor sich. Bei der Durchführung einer bestimmten Tätigkeit ist er sich dagegen kaum noch bewußt, eine bestimmte Funktion zu erfüllen.

Da dem Endbenutzer ein Denken in Kontrollkonstrukten wie

- Iteration

- Selektion

- Sequenz

im allgemeinen fremd ist, sind Methoden, die nichtprozedurale Beschreibungsprinzipien besitzen, bei Benutzerpartizipation vorzuziehen.

Synchronisationsschwierigkeiten

Die systematische Einbeziehung paralleler Prozesse in die Betrachtungen wird bisher nur durch wenige Methoden ermöglicht. Die sequentielle Betrachtung von Vorgängen, die in der Wirklichkeit durchaus parallel ablaufen könnten, wird vorgezogen. Dies liegt auch im Interesse des Benutzers, da durch die Einbeziehung paralleler Prozesse in die Betrachtungen vorwiegend Synchronisationsschwierigkeiten und Performance-Verluste vermieden werden sollen. Die höhere Komplexität, die dadurch hingenommen werden muß, entspricht aus der Sicht des Benutzers keiner Verbesserung.

Zwischen den einzelnen Hilfsmitteln sind Unterschiede im Strukturierungsgrad feststellbar. Bestimmte sehr ausgeprägte Hilfsmittel lassen dem Gestalter kaum noch Freiheitsgrade. Jeder Entwurfsschritt ist sehr detailliert vorgeschrieben (zum Beispiel bei HIPO).

Für andere Methoden wiederum gilt das nicht. Composite Design ist ein stark heuristisch ausgerichtetes Verfahren. Die meisten Vorschriften darin sind so unscharf formuliert, daß sie gerade formal orientierte Entwerfer abschrecken /6/.

Eine zu hohe Detaillierung der Vorschriften sowie Regeln einer Methode und die damit verbundene Formalisierung hat nicht nur beim Benutzer eine Minderung der Kreativität zur Folge, sondern kann darüber hinaus für den Benutzer durch die ungewohnte Arbeitsweise zur Demotivation führen.

Der singuläre Systementwicklungsansatz zielt auf das Ausnutzen der Wechselwirkung zwischen sukzessivem Aneignen des Implementierungs- sowie DV-Know-hows durch den Benutzer und der stufenweisen Systemimplementierung ab. Ziel dieses Ansatzes ist es, so rasch wie möglich und ohne umfassende, detaillierte Konzeptionsüberlegungen zu ersten, praktisch nutzbaren Lösungen zu gelangend. Dieses Vorgehen stammt noch aus den Anfangszeiten der EDV.

Lediglich bei der Entwicklung von Informationssystemen im Planungsbereich erfährt diese Methode wieder eine Renaissance (Konzept der "Individuellen Datenverarbeitung"). Der Entwicklungsaufwand erhöht sich durch dieses Vorgehen beträchtlich. Der Ansatz wird also nicht im Interesse des Systemgegners liegen. Dem Benutzer bietet er jedoch durch die Möglichkeit von DV-Know-how und durch schnelle Lösungen erhebliche Vorteile.

Die deduktive Vorgehensweise wirkt von Modellen oder modellartigen Vorstellungen ausgehend auf die Problemlösung ein. Die induktive Vorgehensweise orientiert sich an der Praxis und geht von Erkenntnissen der Ist-Aufnahme und praktischen Erfahrung aus. Mit Gewißheit ist das letztere Entwurfsprinzip bei der Einbeziehung des Benutzers in den Entwicklungsprozeß sinnvoller.

Je näher eine Methode, ein Verfahren oder ein Werkzeug der Systementwicklung dem oben beschriebenen Polaritätsprofil kommt, desto besser ist es dafür geeignet, in Verbindung mit der Benutzerbeteiligung eingesetzt zu werden. Ende

*Tilmann Greiner und Hans-Friedrich Jacobi sind Mitarbeiter des Fraunhofer-Instituts für Produktionstechnik und Automatisierung, Stuttgart

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 formierten 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.