Zusammenfassung
In diesem Kapitel wird der Versuch unternommen, diejenigen Probleme aufzudecken, die die Gestaltung von anforderungs- und nutzungsgerechten betrieblichen Informationssystemen behindern. Zu diesem Zweck sind konzeptionelle Überlegungen anzustellen, die sich mit der Ausformung einer effektiven Organisation des Gestaltungsprozesses befassen, und auch solche, die die Akzeptanz des angestrebten Gestaltungsproduktes fokussieren.
This is a preview of subscription content, log in via an institution to check access.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Preview
Unable to display preview. Download preview PDF.
Literatur
In Zangenmeister (1972), S. 200 wird die formale Abbildung von Verknüpfungen bzw. Relationen als “Struktur des Systems” bezeichnet.
Vgl. Ackoff (1972), S. 662.
Bakow/Hesse/Kittlaus/Luft/Scheschonk/Stülpnagel (1989), S. 113. Ein entsprechendes Begriffsverständnis findet sich z.B. auch in Ott (1991), S. 3.
Vgl. z.B. Seibt (1972), S. 27.
Österle (1981), S. 16.
Spinas/Waeber/Strohm (1990), S. 31.
Vgl. Spitta (1989), S. 20–21.
Spinas/Waeber/Strohm (1990), S. 32.
Vgl. Bauer (1975), S. 523; Kimm/Koch/Simonsmeier/Tontsch (1978), S. 12ff.; Schnupp/Floyd (1978), S. 12; Möller (1983), S. 284.
Vgl. Boehm (1976), S. 1226.
Vgl. Grochla (1973), S. 429.
Vgl. Österle (1981), S. 13–14.
So wird in Kelter (1991), S. 215 Software Engineering als “das systematische, methodische und ingenieurmäßige Vorgehen bei der Entwicklung von Software” definiert.
Vgl. Bauer (1975), S. 524 sowie auch Wirtz (1987), S. 306; Gabriel (1990), S. 262.
Vgl. End/Gotthardt/Winkelmann (1979), S. 20–21. Eine detaillierte, katalogartige Beschreibung der Qualitätsmerkmale von Softwareprodukten findet sich in Balzert (1982), S. 11ff.
Entsprechend wird unter “Software Engineering (…) die genaue Kenntnis und gezielte Anwendung von Prinzipien, Methoden und Werkzeugen für die Technik und das Management der Software-Entwicklung und -Wartung auf der Basis wissenschaftlicher Erkenntnis und praktischer Erfahrung sowie unter Berücksichtigung des jeweiligen ökonomisch-technischen Zielsystems verstanden.” Gewald/Haake/Pfadler (1985), S. 26. Vgl. auch Nagl (1990), S. 29.
CASE steht für “Computer Aided Software Engineering” und wird definiert als “alle Software-Produkte, die zumindest einzelne bei der Entwicklung von Software benötigte Funktionen anbieten. (…) »integrierte« Systeme mit einem breiten (…) Funktionsumfang bezeichnet man als Software-Entwicklungsumgebungen [SEU] oder CASE-Umgebungen.” Kelter (1991), S. 215.
Vergleiche verschiedener Phasenkonzepte finden sich bei Möller (1983), S. 284ff. und Ott (1991), S. 13.
Vgl. Pomberger (1990), S. 210–211.
Vgl. Heinrich (1990), S. 208.
Zur Prozeßgestaltung durch Meilensteine vgl. Möller (1983), S. 287.
Seibt (1987), S. 253.
Vgl. End/Gotthardt/Winkelmann (1979), S. 23–24.
Partsch (1987), S. 9. Vgl. auch die umfassende Diskussion von Terminologie, Formalismen und Konzepten des Requirements Engineering in Partsch (1991).
Vgl. z.B. Allerbeck/Helmreich (1985); Müller (1986b); Kemper (1987).
“Das Ziel einer jeden in der betrieblichen Realität durchgeführten Entwicklung eines computergestützten Informationssystems besteht darin, für eine oder mehrere klar abgrenzbare Aufgabenstellungen, die von bestimmten Personen/ Gruppen innerhalb bestimmter organisatorischer Strukturen und unter Nutzung bestimmter vorhandener Technologien gelöst werden, verbesserte, d.h. wirksamere Kombinationen von Personal, Organisationsstrukturen und Technologien für die vorgegebene[n] Aufgabe[n] zu entwerfen und zu realisieren.” Seibt (1980), Sp. 857.
In Seibt (1980) werden drei Bedeutungsinhalte des Implementierungsbegriffs identifiziert. Entweder gehe es um die Entwicklungsphase der Konstruktion von technischen Systemen oder um die Anpassungsaktivitäten der Systemumgebung oder um den gesamten Systementwicklungsprozeß. Daraus ließen sich zwei Definitionen für »organisatorische Implementierung« ableiten. Die eng gefaßte Begriffsvariante umfasse lediglich die zu Beginn des Entwicklungsprozesses vorzubereitende und durchzuführende Benutzerschulung. Dagegen ziele “Organisatorische Implementierung als Gestaltungsansatz zur Realisierung von wirksamen computergestützten Informationssystemen (…) darauf, während des gesamten Systementwicklungsprozesses eine bewußte, zielgerichtete Anpassung, Abstimmung und Integration zwischen den personalen, organisatorischen und technologischen Komponenten dieser Systeme herbeizuführen.” Seibt (1980), Sp. 857.
Vgl. die Darstellung in Seibt (1980) und die in dieser Tradition stehenden Anwendungen für Personalinformationssysteme in Mülder (1984), für ein BTX-gestütztes Informationssystem in Rüschenbaum (1986) bzw. Kommunikationssystem in Anstötz (1991).
Das Akronym »PORGI« steht für “Planungshilfe für die Organisatorische Implementierung computergestützter Informationssysteme”. Oppelland (1983), S. 185. Gebräuchlich ist auch die englische Bezeichnung “Planning Tools for the Organizational Implementation of Computer-based Imformation Systems”. Wollnik (1990a), S. 144.
Der Asymmetriegedanke kann wie folgt interpretiert werden: “Immer dann, wenn ein Dialogpartner A über ein tragfähiges Modell über den jeweiligen Gegenstandsbereich verfügt, ist er der modellstarke Handelnde. Der modellschwache Partner B verfügt über keine Anteile des Gegenstandsbereiches, die nicht Teilmenge von A sind, der ja durch sein Modell den Gegenstandsbereich festgelegt hat. (…) Will B den Dialog aufrechterhalten, ist er gezwungen, sich im Modell von A auszudrücken, was er aber vorher verstehen muß und dabei auf A angewiesen ist. (…) Der Dialogpartner A hat (…) die Modellmacht, die sich aus dem Umstand ergibt, daß er sein Modell simulieren und so für tragfähig erklären kann, (…).” PASCH (1989), S. 47–48.
“Da sie [die Benutzerwünsche und -anforderungen] nicht oder nur unzureichend berücksichtigt werden [können], bestätigen sich die [Vor-]Urteile der Betroffenen [»wir werden nicht gehört« oder »unsere Wünsche werden nicht erfüllt«] und die der Entwickler [»die Benutzer machen keine vernünftigen Vorschläge« oder »die Benutzer kommen immer erst hinterher mit ihren Wünschen«]. Die gegenseitige Frustration ist also systematisch vorprogrammiert.” Oppermann (1989), S. 106.
“Bei den angebotenen Entwicklungssystemen und Entwicklungsumgebungen bleiben (…) wichtige Anforderungen des Benutzers unberücksichtigt, die sich z.B. auf die ersten Arbeitsphasen beziehen. Empirische Untersuchungen stellen eine fehlende Akzeptanz und einen geringen Einsatz in der Praxis fest.” Gabriel (1990), S. 260.
Frese bezeichnet die drei als Einheit aufzufassenden Ebenen des Akzeptanzbegriffs als kognitive, motivational-emotionale und Handlungsaspekte. Vgl. Frese (1987), S. 13.
Balzert(1982), S. 12.
Siehe dazu detailliertere Erläuterungen in Abschnitt 2.2.1.
“Sie reagieren mit Unsicherheit, Ablehnung oder gar mit [zumindest latentem] Widerstand”. Oppermann (1984), S. 1084.
PORGI wurde von 1975–1979 am Betriebswirtschaftlichen Institut für Organisation und Automation an der Universität zu Köln (BIFOA) entwickelt. Eine Zusammenfassung von Konzept, Methode und Instrumentarium findet sich bei Oppelland (1983).
Oppelland (1983), S. 173.
Oppelland (1983), S. 176.
Oppelland (1983), S. 167.
IG Metall (1989), S. 12.
“Ohne Regelung von Entscheidungs- und »Veto«-Rechten für die Beteiligten können Befragungs- und Meinungsäußerungsinstrumente nicht nur ohne Partizipationswirkung sein, sondern sogar die Position der Organisationsmitglieder schwächen.” Und: “Ohne Regelung der Verantwortung für die aus Befragungsergebnissen abzuleitenden Konsequenzen kann auch den befragten Mitarbeitern eine nicht unerhebliche manipulative Macht zugesprochen werden, (…).” Oppelland (1983), S. 184.
Spinas/Waeber/Strohm (1990), S. 36.
Koslowski (1988), S. 67.
O.V. (1989B), S. 5.
Vgl. Budde/Sylla/Züllighoven (1987b), S. 325.
Vgl. Budde/Sylla/Züllighoven (1987b), S. 324.
Vgl. Kozar (1989), S. 205.
Vgl. auch die Auswertung verschiedener aktueller Praxisprojekte in Kieback/ Lichter/SchneiderHufschmidt/Züllighoven(1992).
Vgl. z.B. das Prototyping-Projekt-Modell (»PPM«) in Berblinger (1988) für die Wirtschaftswissenschaften, der (damit nicht zu verwechselnde) »PPM«(Projekt-Prozeß-Methoden)-Ansatz in Kreplin (1986) oder die transaktionsorientierte operationale Methode in Hallmann (1988) für die Informatik.
Vgl. etwa Hallmann (1988); Kreplin (1987); Vorwerk (1991).
»CPEN« steht für “Cics Prototyping Environment”. Vgl. Foidl/Hillebrand/Tavolato (1986), S. 97.
Vgl. Spinas/Waeber/Strohm (1990), S. 34.
Koslowski (1988), S. 167.
Vgl. Floyd/Keil (1983), S. 140.
Gstalter/Kaiser/Strube/Zang-Scheucher (1989), S. 96.
Budde/Kuhlenkamp/Sylla/Züllighoven (1986b), S. 203.
Budde/Kuhlenkamp/Sylla/Züllighoven (1986a), S. 159.
Pomberger (1990), S. 228.
Vgl. Budde/Kuhlenkamp/Sylla/Züllighoven (1986b), S. 203.
Koslowski (1988), S. 169.
Floyd/Mehl/Reisin/Wolf (1987), S. 49.
Blaser/KeppelK(1978), S. 438.
Pomberger (1990), S. 227.
Budde/Kuhlenkamp/Sylla/Züllighoven (1986b), S. 203.
Vgl. Gabler Wirtschafts-Lexikon (1988), Sp. 1083.
Ein derartiges Konzept wird in Abschnitt 2.2.2 diskutiert.
CPEN wurde von DV-Spezialisten der Vereinigten Edelstahlwerke AG in Ternitz (Österreich) entworfen und implementiert. Das Werkzeug umfaßt interaktive Komponenten zum Maskenentwurf, zur Dateidefinition incl. Editor, zur Dokumentenerstellung und -generierung sowie einen Programminterpreter. Eine Zusammenfassung des Konzeptes findet sich bei Foidl/Hillebrand/Tavolato (1986).
Foidl/Hillebrand/Tavolato (1986), S. 96 (Hervorhebung im Original).
Foidl/Hillebrand/Tavolato (1986), S. 96.
Foidl/Hillebrand/Tavolato (1986), S. 97.
Vgl. Streitz (1988a), S. 6–7; Streitz (1988b), S. 7–9.
Vgl. Floyd/Mehl/Reisin/Wolf (1987), S. 12–13.
Eine Organisation wird danach als ein System aufgefaßt, dessen Funktionsfähigkeit von psychologischen und physischen Zufriedenheitsaspekten aller Mitglieder abhängt. Vgl. Davis (1979), S. 98–99.
“Moderne Bürotechnik wird (…) eine Art »elektronischer Werkzeugkasten« zur freien und unabhängigen Nutzung sein.” Helmreich (1984), S. 27. Auch der Werkzeugbegriff ist allerdings interpretationsbedürftig, denn praktisch jeder Gegenstand, der als Mittel zu einem Zweck dient, kann als Werkzeug bezeichnet werden. Vgl. Nake (1986), S. 43ff. Vgl. auch die Diskussion um die Werkzeug- und Werkstattmetapher zur Erläuterung von Nutzungs- und Entwicklungssichten von Informationssystemen in Oberquelle (1991c) und Budde/Züllighoven (1990).
Mehl/Reisin (1989), S. 123.
Vgl. Eason (1982).
“Für die Zukunft ist mit dieser Vorstellung jedenfalls im Sinne einer konstruktiven Utopie die richtige Richtung abgesteckt.” Oppermann (1989), S. 113.
“Langfristiges Ziel dieses Ansatzes ist es, daß nicht die Systemanalytiker, sondern die betroffenen Arbeitnehmer selbst die Ziele eines Systems definieren und die Systemanalyse betreiben und der Systemanalytiker sich beratend und unterstützend im Hintergrund hält.” Mambrey/Oppermann (1985), S. 113.
Vgl. Hattke/Sydow (1982), S. 710.
In einer Untersuchung über die Menschenbilder, die Entwickler ihrer Tätigkeit zugrunde legen, gehen Mumford und Welter der Frage nach, welche Bedürfnisse und Fähigkeiten diese den Benutzern zuschreiben. Auf einer abstrakt theoretischen Ebene sehen Entwickler in dem Betroffenen zwar “ein sehr viel reiferes, entwickelteres Individuum mit einem Verlangen nach Herausforderung und Selbstverwirklichung und mit einem Bedürfnis nach Kontrolle über die eigene Arbeitssituation.” [Mumford/Welter (1984), S. 49]. Dieses Menschenbild können sie jedoch nicht in die praktische Arbeit umsetzen. Dort werden Benutzer “als beschränkte, konservative Menschen gesehen, die innerhalb einer engen Qualifikationsspanne arbeiten und Veränderungen großen Widerstand entgegensetzen.” Mumford/Welter (1984), S. 47.
Zu den verschiedenen Abgrenzungen vgl. auch Koslowski (1988), S. 16ff.; Oppelland (1983), S. 166; Kubicek/Berger (1983), S. 24; Mambrey/ Oppermann/Tepper (1983), S. 289.
Vgl. Mambrey/Oppermann/Tepper (1989), S. 38.
Kißler(1988), S.7.
Vgl. Brose/Corsten (1983), S. 29.
Vgl. Kappler (1980), Sp. 1845.
Vgl. Hattke/Sydow (1982), S. 710.
Zur Palette der institutionalisierten Beteiligung vgl. Mambrey (1985), S. 22.
Fricke versteht unter Beteiligung in diesem Sinne die “Beteiligung von Arbeitnehmern (…) an der Gestaltung ihrer Arbeitsbedingungen nach ihren Interessen”. Fricke (1983), S. 87.
Vgl. Mumford/Land/Hawgood (1978).
Die Abkürzung »ETHICS« steht für “Effective Technical and Human Implementation of Computer Systems” [Wollnik (1990a), S. 144]. Im deutschen Sprachraum hat sich die synonyme Bezeichnung “Erfolgreiche technische und humane Implementierung von Computersystemen” durchgesetzt. Mumford/Welter (1984), S. 90.
Vgl. etwa Mambrey/Oppermann/Tepper (1986), S. 247; Koslowski (1988), S. 66; Anstötz (1991), S. 33.
Vgl. Sydow (1989), S. 17ff.
Konsultative Partizipation sieht die Betroffenenbefragung, repräsentative Formen die Teilnahme von Vertretern und konsentive Teilhabe die diskursive Zielbestimmung des Projektes vor. Vgl. Mambrey/Oppermann/Tepper (1986), S. 15.
Kubicek(1980), S.19.
Vahrenkamp (1986), S. 21.
Kubicek (1980), S. 16–17.
Vgl. Sydow (1989), S. 30.
Die Klassifikation wurde abgeleitet und modifiziert auf Grundlage von Bewertungskriterien für Methoden betroffenenorientierter Systementwicklung in Peschke (1986), S. 180ff. und in Wicke (1988), S. 137ff. Vgl. auch die Partizipationsausprägungen in Heilmann (1981), S. 128, die Diskussion um unterschiedliche Aspekte von Benutzerbeteiligung und Mitbestimmung in Kubicek/Berger (1983), S. 29ff. und in Spinas/Waeber/Strohm (1990), S. 34–35 sowie die Behandlung von Fragen der Partizipationskompetenz in Greifenstein/Jansen/Kißler (1990b).
Greifenstein/Jansen/Kißler (1990B), S. 25.
Mambrey/Oppermann/Tepper (1989), S. 38.
Vgl. Koslowski (1988), S. 22ff.
Zu den Problemen der Benutzerbeteiligung vgl. Kubicek/Berger (1983), S. 33–34.
Oppermann (1984), S. 1084.
Mambrey/Oppermann/Tepper (1989), S. 38.
ETHICS wurde an der Manchester Business School entwickelt und fand in zahlreichen (insbesondere skandinavischen und britischen) EDV-Vorhaben Verbreitung. Das Konzept kann hinsichtlich der Rezeption soziotechnischer Modellvorstellungen als der klassische Ansatz zur partizipativen Systemanalyse, -entwicklung und -bewertung bezeichnet werden. Bereits in den siebziger Jahren kam die Ursprungsfassung von ETHICS zum Einsatz. Vgl. Mumford/Weir (1979). Ein detaillierter Überblick über Vorgehen und Organisation von Systemgestaltungsprojekten nach dem mittlerweile mehrfach modifizierten ETHICS-Konzept findet sich (im Rahmen einer Zusammenstellung von Einzelbeiträgen zu den Themenkomplexen »Partizipation bei der Systemgestaltung« und »Sozio-technische Gestaltungsphilosophie«) bei Mumford/Welter (1984), S. 100–147 und S. 202–285.
Mumford/Welter (1984), S. 102.
Der Effizienzbegriff wird bei ETHICS zwar nicht definiert; der Verwendungskontext weist ihm jedoch einen recht beschränkten Bedeutungsinhalt zu: “Ein Computersystem soll die Einschätzungen der EDV-Spezialisten berücksichtigen, die die Hardware verstehen und wissen, wie sie effizient genutzt werden kann; (…) es muß mit den Bedürfnissen der Manager übereinstimmen, die für eine effiziente Herstellung von Produkten und Dienstleistungen verantwortlich sind”. Mumford/Welter(1984), S. 13.
Die in diesem Textabschnitt (mit Bindestrich) verwendete Schreibweise vom »sozio-technischen System« soll die analytische Trennung zwischen dem sozialen und dem technischen Teilsystem zum Ausdruck bringen. Diese Syntax präferieren auch Mumford/Welter.
Die 15 Einzelschritte betreffen: die Bestimmung der Anlässe und der Ausgangssituation der Veränderung (Schritt 1), die Grenzen des betrachteten sozio-technischen Systems (2), die Input-Output-Analyse des bestehenden sozio-technischen Systems (3), die Basisfunktionen des bestehenden sozio-technischen Systems (4), die Schlüsselziele und Schlüsselaufgaben (5), die notwendigen Schlüsselinformationen (6), die Varianzanalyse (7), die Diagnose der Anforderungen an zufriedenstellende Arbeit (8), die Zukunftsanalyse (9), das Festlegen von technischen, Wirtschaftlichen und sozialen Zielen (10), das Entwickeln alternativer Lösungen (11), das Entwickeln möglicher sozio-technischer Lösungen (12), die detaillierte Ausgestaltung der ausgewählten sozio-technischen Lösung (13), die Implementierung des neuen Systems (14) und die Bewertung des neuen sozio-technischen Systems (15).
Der Bedarfsdiagnose lassen sich die ersten fünf ETHICS-Einzelschritte zuordnen.
Mumford/Welter (1984), S. 106.
Die Zielfestlegung beinhaltet die ETHICS-Schritte 6–10.
“Varianzen sind definiert als die Tendenz eines Systems oder Subsystems, von einer gewünschten Norm bzw. einem Standard abzuweichen”. Mumford/Welter (1984), S. 114.
Mumford/Welter (1984), S. 119. Es “werden fünf Gruppen von Anforderungen bzw. Bedürfnissen unterschieden:
Bedürfnisse bezüglich Nutzung und Weiterentwicklung von Fähigkeiten
psychische Bedürfnisse
Bedürfnisse nach Unterstützung und Kontrolle
Bedürfnisse bezüglich der Aufgabenstruktur
ethische Bedürfnisse.” Mumford/Welter (1984), S. 223.
Auf dieser Grundlage können “Vorschläge zur Nutzungsdauer des Systems sowie zu seiner flexiblen Ausgestaltung erarbeitet werden.” Mumford/Welter (1984), S. 107.
Die Systemgestaltung i.e.S. umfaßt die Schritte 11, 12 und 13.
Mumford/Welter (1984), S. 109.
Zum komplizierten Zielbildungsprozeß vgl. Mumford/Welter (1984), S. 142ff.
“Partizipation ist nicht einfach. Daher müssen Gruppen lernen, wie man partizipiert, und der Prozeß der Partizipation muß entsprechend gehandhabt werden. Dies geschieht nicht ohne Kenntnisse von Gruppenbeziehungen und Gruppenprozessen und ohne die Fähigkeit, Menschen zu interessieren und zu motivieren.” Mumford/Welter (1984), S. 202.
Mumford/Welter (1984), S. 85.
Vgl. Heinrich (1990), S. 201.
“Ganz grundsätzlich kann (…) an der ETHICS-Konzeption die Kritik geübt werden, daß sie keine Methoden zur Unterstützung der beim Software-entwicklungsprozeß notwendigen Entwickler-Benutzer-Kooperation bereitstellt.” Spinas/Waeber/Strohm (1990), S. 36.
Koslowski identifiziert sieben Problembereiche bei der Systementwicklung: Beschreibbarkeitsprobleme komplexer Organisationsstrukturen, Veränderlichkeit von Organisationen und Systemanforderungen, Verschiedenheit von sozialer und technischer Realität, Sprachprobleme zwischen Entwicklern und involvierten Gruppen, Unangemessenheit der softwaretechnischen Darstellungsmittel, Unvorhersehbarkeit von Systemeigenschaften und -auswirkungen und Transformationsprobleme zwischen verschiedenen Beschreibungs- und Konkretisierungsebenen. Vgl. Koslowski (1988), S. 134ff.; vgl. auch Budde/Kuhlenkamp/Sylla/Züllighoven (1987), S. 82–84.
Nullmeier (1986), S. 169.
Vgl. z.B. Spitta (1989) und VDI (1989). Die enge Verwandtschaft zwischen dem evolutionären Prototyping und der zyklischen Vorgehensweise kommt etwa in Budde/Kuhlenkamp/Sylla/ Züllighoven (1986A, 1986b) und Budde/Sylla/Züllighoven (1987a, 1987b) zum Ausdruck. Entsprechend kann zyklische Systementwicklung auch als konsequentes evolutionäres Prototyping aufgefaßt werden.
Das Akronym »STEPS« steht für “Softwaretechnik für evolutionäre, parti-zipative Systementwicklung”. Reisin/Schmidt (1989), S. 94.
Reisin/Schmidt (1989), S. 99.
Reisin/Schmidt (1988), S. 44.
Oppermann (1989), S. 112 (Anmerkung).
Die Bezeichnungen »evolutionäre«, »prozeßorientierte« oder »zyklische« Systementwicklung werden in diesem Zusammenhang weitgehend synonym gebraucht. Vgl. dazu Budde/Sylla/Züllighoven (1987b), S. 325; Wicke/Fuß/ Hagen/Heinrich/Töpler (1989), S. 82; Koslowski (1988), S. 151.
Peschke (1986), S. 95. Das “Vorgehen unterscheidet sich vom Prototyping insofern, als nicht vorläufige Prototypen den Evaluationsgegenstand darstellen, sondern jeweils fertig entwickelte System Versionen.” Spinas/Waeber/Strohm (1990), S. 34.
Floyd/Keil (1983), S. 149.
Im Labyrinthmodell von Lehmann löst sich die Phaseneinteilung völlig auf. Vgl. die Darstellung in Koslowski (1988), S. 160–161.
Budde/Sylla/Züllighoven (1987b), S. 325.
Floyd/Keil (1983), S. 148.
Budde/Kuhlenkamp/Sylla/Züllighoven (1986b), S. 202.
Budde/Kuhlenkamp/Sylla/Züllighoven (1986a), S. 160. “Das übergeordnete Anliegen von Prototypingeinsatz zur Unterstützung kooperativer Gestaltungsprozesse der Benutzerinnen und EntwicklerInnen besteht darin, einen Diskursraum für die Benutzerinnen und EntwicklerInnen auf der Basis von praktischen Erfahrungen herzustellen.” Floyd/Mehl/Reisin/Wolf (1987), S 54.
Eine Zusammenfassung des STEPS-Konzeptes findet sich unter anderem in Reisin/Schmidt (1989).
Reisin/Schmidt (1989), S. 94.
Eine Zusammenfassung des PEtS-Projektes und dessen Ergebnisse findet sich in Floyd/Mehl/Reisin/Wolf (1987). »PEtS« steht als Abkürzung für “Partizipative Entwicklung transparenzschaffender Software für EDV-gestützte Arbeitsplätze”. Floyd/Mehl/Reisin/Wolf (1987), S. 1.
Das STEPS-Ausgangskonzept wird z.B. beschrieben bei Floyd/Keil (1983), S. 137–164. Weitergehende Überlegungen finden sich bei Floyd (1986), S. 106–120.
Reisin/Schmidt (1989), S. 95.
“Als sozialverträglich bezeichnen wir ein in Arbeitszusammenhängen eingebettetes Softwaresystem, wenn es den Ansprüchen der BenutzerInnen hinsichtlich der Arbeitsqualität, der Transparenz der Organisations- sowie der Durchlässigkeit der Entscheidungsstrukturen genügt und darüber hinaus Ansatzpunkte zur Entfaltung von Kreativität bei der Gestaltung der täglichen Arbeitsprozesse aufweist”. Floyd/Mehl/Reisin/Wolf (1987), S. 18.
145 Das STEPS-Verständnis umfaßt Techniken zur Entfaltung und Förderung von Kommunikations- und Lernprozessen zwischen Entwicklern und Benutzern.” Reisin/Schmidt (1989), S. 95–96.
Während des PEtS-Projektes wurden das Datenstrukturmodell, die Darstellung von Arbeitsabläufen und -strukturen der betroffenen Abteilung, die erste Ausbaustufe der Dialogschnittstelle, die Einsatzrechner-Basismaschine, ein Dokumentenzugriffsmodell und der konzeptionelle Rahmen aller in Listenform zu realisierenden Auswertungen des Systems als Haupt-Referenzlinien von den späteren Systembenutzern und der Entwicklergruppe definiert.
Bei PEtS wurden bis zum vorläufigen Projektabschluß (Ende 1988) drei Softwareversionen realisiert. Im Rahmen einer erneuten Revisionsetablierung beschlossen die Forschungsgruppe von der Technischen Universität Berlin und das WSI eine Projektverlängerung bis Ende 1989, um eine vierte Version zu erstellen.
Reisin/Schmidt (1989), S. 101.
Vgl. Floyd/Mehl/Reisin/Wolf (1987), S. 10–11. Grundlegendes zu skandinavischen Systemgestaltungskonzepten findet sich in Floyd/Mehl/Reisin/Schmidt/Wolf (1987) und Mehl/Reisin (1989).
Mehl/Reisin (1989), S. 125. Diese “kommunikationsorientierte Sicht der Systembeschreibung steht im Einklang zu Befunden der pädagogischen Psychologie, wonach den Prozessen des verbalen Austausches beim kooperativen Lernen eine zentrale Bedeutung zukommt und interpersonale Kontroversen eine wichtige Bedingung für die Motivation und für das Hinterfragen eigener subjektiver Sichtweisen darstellen.” Mehl/Reisin (1989), S. 128.
Reisin/Schmidt (1989), S. 96.
Floyd/Mehl/Reisin/Wolf (1987), S. 44.
“(…) eine technisch ausgereifte Prototyping-Umgebung (wird) als unabdingbar angesehen, wenn die Gestaltungskreativität nicht beeinträchtigt, realistische Arbeitssituationen erprobt und der Programmieraufwand in vertretbaren Grenzen gehalten werden soll”. Mehl/Reisin (1989), S. 130.
Floyd/Mehl/Reisin/Wolf (1987), S. 99.
Reisin/Schmidt (1989), S. 97.
Dieser fixierte unter anderem die Leistungen der Universität, diejenigen des WSI, einen groben Terminplan und eine Zusicherung über die Ermöglichung einer kooperativen Systemgestaltung im Sinne von STEPS.
Jansen/Schwitalla/Wicke (1989b), S. 10.
Floyd/Mehl/Reisin/Wolf (1987), S. 100.
Deters/Helten (1992), S. 199.
Greifenstein/Jansen/Kißler (1990S), S. 15.
Rights and permissions
Copyright information
© 1995 Betriebswirtschaftlicher Verlag Dr. Th. Gabler GmbH, Wiesbaden
About this chapter
Cite this chapter
Knittel, F. (1995). Erfolgsprobleme der Systemgestaltung. In: Technikgestützte Kommunikation und Kooperation im Büro. Bochumer Beiträge zur Unternehmungsführung und Unternehmensforschung. Gabler Verlag. https://doi.org/10.1007/978-3-322-86739-1_2
Download citation
DOI: https://doi.org/10.1007/978-3-322-86739-1_2
Publisher Name: Gabler Verlag
Print ISBN: 978-3-409-13784-3
Online ISBN: 978-3-322-86739-1
eBook Packages: Springer Book Archive