PD
Partizipation & Gestaltung von Mensch-Computer-Systemen
Einheit 3
Verständnis von Arbeit & Kooperation
1
PD
Partizipation & Gestaltung von Mensch-Computer-Systemen
INHALT DER VORLESUNG
ICH als BERATER/ENTWICKLERin in
EDV-PROJEKTEN mit MENSCHEN
Angestrebte Rolle
Inhalte
Verantwortung
Rolle Berater
...
EIGENE Annahmen
(Kommunikation, Fairneß, Moral …)
Arbeit mit Gruppen
EDV -Design in Gruppen
Projekte
Vermarktung
Projektziele
Vereinbarungen
Projektdesign
Anbote
Projektcontrolling
Kalkulation
Qualifizierung
...
...
THEORETISCHE
KONZEPTE
2
PD
Partizipation & Gestaltung von Mensch-Computer-Systemen
The problem
Attention on
problem solving
‘problem’
What are the requirements?
Are these requirements complete?
What are the design options?
How to work on it - factual
perspective.
Factual dimension
Attention on
problem definition
How comes this is a problem & for
whom?
Is this the problem?
How do the participants work on it?
How to work on it - social perspective?
Process dimension
3
Ruth: PD
(Text
Joh)
Partizipation & Gestaltung von Mensch-Computer-Systemen
000207
SPEZIALISIERUNG
Human Resource
Management
Produktion
Leistungserbringung
Personalbeschaffung
& Auswahl
Kapazitätsplanung
Leistungsbeurteilung
….
Arbeitszeitgestaltung
Entgeltgestaltung
Personalentwicklung
Konflikte
BR X GF
Führung
4
Karin:PD Partizipation & Gestaltung von Mensch-Computer-Systemen
000214 Layout
LEISTUNGEN IN DER BERATUNG
Fachberatung
Prozeßberatung
Planungstechniken
Vorgehen &
Projektorganisation
Ergonomie
Moderation
Abrechnung
...
Recht
...
Software &
Werkzeuge
5
Joh: PD Partizipation & Gestaltung von Mensch-Computer-Systemen
991108 Ruth
Layout
BALANCE DER SPEZIALISIERUNG AUF
BEREICHE
Vorteile der
Spezialisierung
(Methoden- & Fachwissen, Tools, … )
Nachteile der
Spezialisierung
(Blindheit, … )
Ist es wirklich z.B. Arbeitszeit?
Arbeitszeit als Trigger?
KRITISCH:
• Rollenklärung & Verantwortung
• Checks Review (intern & mit Kunden)
• interne Procedures für Annahme // Ablehnung & Ausrichtung von Projekten
• Kooperationsnetze & Supervision, breite Weiterbildung
6
PD
Partizipation & Gestaltung von Mensch-Computer-Systemen
Ein “gut organisierter” Schreibtisch
7
PD
Partizipation & Gestaltung von Mensch-Computer-Systemen
Schreibtisch
• Geschichte
– Beginn 20 Jahr
– Höhepunkt des Taylorismus
• Vermutungen
– Monotonie
– Es kann nicht funktionieren, weil jeder richtet Schreibtisch her wie er es
braucht
– Beispiel für sinnlose Richtlinien - Monitore
– Henry Ford - Fließband
– ==> gemischtes Ergebnis des Ansatzes
8
PD
Partizipation & Gestaltung von Mensch-Computer-Systemen
Tayloristischer Ansatz
Warum funktioniert es nicht immer?
– 1) Weil die falschen Leute Richtlinien erstellt haben?
– 2) Voraussetzungen stimmen nicht immer - kleineres Übel?
– Dahinter liegende Annahmen:
• 1+2 es ist grundsätzlich möglich
• 1 --> Verweis auf Personen
Alternative: Verweis auf Verfahren
• 2 eher falsch vorgegangen wurde oder wird
– 3) Theorie ist nur sehr beschränkt anwendbar - sie ist weitgehend falsch
9
PD
Partizipation & Gestaltung von Mensch-Computer-Systemen
Übersicht
10
PD
Partizipation & Gestaltung von Mensch-Computer-Systemen
Sichtweisen von qualifizierter Arbeit
(Knudsen 1993)
Scientific Management
(System Theoretical Tradition)
–
–
–
–
Die meisten Arbeitsprozesse können auf Regeln und Formeln reduziert werden.
Arbeiter haben nur theoretisches Wissen
Aufgaben = Plan, Definition, Konstruktion, Kontrolle.
Human Factors unabhängig vom EDV-System.
Socio-Technical Tradition
–
–
–
Soziale Aspekte werden in der Planung berücksichtigt.
Job satisfaction als Teilziel.
Soziales wird in das "System integriert".
Critical Tradition
–
–
–
Loyalität der Entwickler zu Betroffenen.
Tacit knowledge hat hohe Bedeutung.
Ziel wird durch Gruppe definiert.
11
PD
Partizipation & Gestaltung von Mensch-Computer-Systemen
Taylor/Ford
First, Taylor assumed that it is possible to ”gather together all of the
traditional knowledge which in the past has been possessed by the workman
and then classifying, tabulating, and reducing this knowledge to rules, laws,
an formulae which are immenesly helpful to the workmen in doing their daily
work”...
Second, the work of every individual employee “is fully planned out by
management at least one day in advance...describing in detail the task which
he is to accomplish as well as the means to be used in the work done”...
Third, “the science which underlies each workman´s act is so great and
amounts to so much that the workman who is best suited to actually do the
work is incapable (either through lack of education or through insufficient
mental capacity) of understanding this science.”...
Taylor (1947 zitiert nach Cotton 1993)
12
PD
Partizipation & Gestaltung von Mensch-Computer-Systemen
Kernbegrife
Kernbegriffe
–
–
–
–
–
Gather all knowledge
Knowledge possessed by somebody
classifying, tabulating, and reducing this knowledge
fully planned
fully planned by management - workman uncapable
THESE 1: das ist nur sehr beschränkt/zu Teil möglich
THESE 2: Sehr viele Konzepte der Informatik versuchen nur mit der
einen Dimension (Taylor) des Wissens zu arbeiten
EBENE vorher
–
–
Für Taylor ist das WISSEN ausschlaggebend
KONFLIKTTHESE: Es gibt nur relativ wenig Faktenwissen (Naturgesetzen -- ??) und primär
handelnde Personen
TEXT 1: Gather all knowledge possessed by somebody
–
Konfliktthese: Menschen konstruieren und interpretieren Aussagen und Geschichten
Es gibt kein Wissen an sich, sondern nur aussagenproduzierende und interpretierende
Personen
13
PD
Partizipation & Gestaltung von Mensch-Computer-Systemen
Workflow
• Wissen & Arbeitsabläufe vollständig abzubilden
• Meilensteine, etc… können beides sein
– Ablaufdiagramm
– DIMENSION 1: vollständige und korrekte Beschreibung der Abläufe
– DIMENSION 2: Ein Rahmen der Interaktionen ud Rollen und Verbindungen
definiert
• Ontologies (Ordnungssysteme des Seienden)
zB Projekt
– Wissensdimension 1: A ist Teil von B, A ist B oder C…
– Wissensdimension 2: Was brauche
Wer bezeichnet wann was wie?
Was für Handlungszusammenhänge werden damit bezeichnet?
14
PD
Partizipation & Gestaltung von Mensch-Computer-Systemen
Konzeptionalisierung
… (vereinfacht)
in welchen Kategorien denke ich über die Welt
BEISPIEL 1:
– Ansatz 1: tyaloristisches Wissen ODER wissen als Konstruktionsleistung
– Ansatz 2: Dimension von Wissen
• tayloristische Wissensdiomension
• konstruuiierende Wissensdimension
Beispiel 2: Nicht sagen
–
–
–
Ansatz 1: Furcht
Ansatz 2: Gruppenprozeß
Anatz 3: Herausforderung …
Beispiel 3:
–
–
werden inzwischen selbst versuchen diese Themen aufzugreifen & durchzusetzen
Hitchhikers guide - zu deppert
15‘ … Konflikte um Macht un Anerkennung
15
PD
Partizipation & Gestaltung von Mensch-Computer-Systemen
Fließbandarbeit
– Standardisierung
– Argumentationslinie 1: Arbeitsorganisation
• Unternehmen bemühen sich um „mitdenkende Mitarbeiter“
• Jobrotation
• KVP … Kontinuierlicher Verbesserungsprozeß
• Gruppenarbeit
• neue Probleme … fast nie in Vorschriften ...
• Kommmunikation, Gruppenarbeit, Moderation
– Argumentationslinie 2
• Wieso kann BMW, Opel.. In Österreich so erfolgreich sein
Hotline = Auskunft beim Telefon
– 20-40% nicht Standardaufgaben
16
PD
Partizipation & Gestaltung von Mensch-Computer-Systemen
Freie Markt …
– unsichtbare Hand … invisible hand
– es braucht auch (Verweis auf sogar noch weiteren Zusammenhang)
• invisible hand-shake
17
PD
Partizipation & Gestaltung von Mensch-Computer-Systemen
Dimensionen von Wissen
Dimension 1: Zahlen, Daten, Fakten
– Konsequenz für SW: Checklist, Pflichteneft
Dimension 2:
– es gibt kein Wissen an sich
– sondern Personen die handeln & über ihr Handel reflektieren, dieses erklären
…
– KONSEQUENZ: Meetings, Testen, ...
• es genügt nicht zu fragen
• es geht um handeln
STUDIEREN BEGINNEN
MIXTURE immer
– ob sich das zeitlich aufschlüsseln läßt ==> ???
18
PD
Partizipation & Gestaltung von Mensch-Computer-Systemen
Beispiel: Software für
Marketingunterstützung
Fragen - Dimension 1:
– Benutzer
– technische Infrastruktur
– ...
Fragen - Dimension 2:
– Wie haben sie es bisher getan
– Geh zeigens mir amal wie sie das tun
19
PD
Partizipation & Gestaltung von Mensch-Computer-Systemen
VORGEHEN
KLASSISCH
–
–
–
–
Wasserfall
Projektphasen
PRESKRIPTIV ---> vorschreibend
REALITÄT ist IN ALLEN UNTERSUCHTEN PROJEKTEN
REALISTISCHER
– Designs die von Anfang auf derartiges Vorgehen Rücksicht nehmen
– ABLAUF
– GRUPPENBILDUNG
• Statt Entwickler, UI, Tester …
• Gruppenbildung entlang Interaktionen
20
PD
Partizipation & Gestaltung von Mensch-Computer-Systemen
Auf die Uni gehen
• Strikt Tayloristisch: Wissensbasiert
• Strikt gegenteil: Aussagen = nachträgliche Rekonstruktion
plausibler Gründe
• Diskussion Wissensmanagement
–
Position 1: Vermittlung von Wissen & Fähigkeiten
• Wissensdatenbank … für die Weitergabe von „Wissenseinheiten“
• EXCEL
•
•
•
•
–
Einabefelder
Formattierung
einfache Berechnungen
…
Position 2: Projekte (Zusammenarbeit,…. Und auch Excel)
• DB II: Als Hilfe Personen zu identifizieren, die Erfahrung haben mit dem Thema
• Gedächtnis
–
–
Taylor: Da/Nicht da … fehlerhaft
Konstruktion: Versuch ich plausibel Dinge zu rekonstruieren
21
PD
Partizipation & Gestaltung von Mensch-Computer-Systemen
Bsp. Aufgabe
> Klassische Herangehensweisen:
Automatisierung
• backtracking
• genetisches Programmieren
• ....
basierend auf:
• wohldefinierter Aufgabenstellung
• klaren Optimierungskriterien
• festen Elementen
• klaren Anforderungen
• sowie Lernmöglichkeiten (Zeit, Stabilität)
> Was tun, wenn diese Voraussetzungen nicht gegeben sind?
Auf Interaktion ausgelegte Systeme: z.B.
• Szenariodefinitionen
• Analysewerkzeuge
• Visualisierung
22
PD
Partizipation & Gestaltung von Mensch-Computer-Systemen
Informatik = Automatisierung !?
Ein Blick zurück:
Zentrale Anwendungsfelder waren
–
–
–
–
Militär
Einfache Aufgaben der Verwaltung
Automatisierung von
..
Die ersten Aufgaben und die Interessen der Auftraggeber
“rechtfertigten” die ‘scientific management’ Sichtweise.
Zugang paßt in manchen Bereichen, aber in vielen auch nicht.
23
PD
Partizipation & Gestaltung von Mensch-Computer-Systemen
Spezifikation
Spezifikation <--> Anwendung
Was soll das System aus Sicht der AnwenderInnen leisten hinsichtlich:
• Funktionalität
• Arbeit mit dem System
• ...
Das System soll diese Anforderungen unter den konkreten, jeweiligen
Bedingungen erfüllen.
Spezifikation <--> Technik
Anforderungen hinsichtlich Implementierung (Was soll das System tun, aber
nicht, wie es es tun soll!)
Woher kommen Probleme?
24
PD
Partizipation & Gestaltung von Mensch-Computer-Systemen
Voraussetzungen fehlerfreier Spezifikation
Fehlerfreie Spezifikation würde nur funktionieren, wenn...
– es keine Sprachbarrieren gäbe,
– die Perspektiven der Beteiligten “was das Problem ist” sowie “was erreicht werden soll” ident
wären und es daher keine Widersprüche zwischen den Anforderungen der einzelnen
Beteiligten gäbe,
– es möglich wäre, die Anforderungen vollständig zu beschreiben,
– die Systemgrenzen scharf wären,
– die Anforderungen stabil wären (keine Lernprozesse, keine Veränderung der Umgebung, kein
Vergessen...),
– Synchronisation einfach wäre
– ...
Leider ist dies kaum der Fall.
Am ehesten noch bei:
– Klassischer Automatisierung eng definierter Aufgaben
– Mathematischen Fragestellungen
– “Spiel”-Problemen
25
PD
Partizipation & Gestaltung von Mensch-Computer-Systemen
Überspitzte Positionen
(Extreme Formulierungen um unterschiedliche Orientierungen zu verdeutlichen.)
Wenn die Beteiligten fehlerfrei und offen am Projekt mitarbeiten, die
Anforderungen fehlerfrei zusammengestellt und umgesetzt werden,
kommt es zu einer erfolgreichen Systementwicklung =
Automatisierung.
(Orientierung: Programmverifikation, CASE-Tools, ...)
Wenn es gelingt, einen systematischen Lernprozeß über
Anforderungen, Nutzungsmöglichkeiten... zu organisieren, in dem
das entwickelt wird, was die Benutzer brauchen und unterschiedliche
Anforderungen geklärt bzw. vereinheitlicht werden, kommt es zu
einer erfolgreichen Systementwicklung = nützlichen Werkzeuge.
(Orientierung: Prototyping, Partizipative Systementwicklung...)
26
PD
Partizipation & Gestaltung von Mensch-Computer-Systemen
“Anforderungen”?
“The requirement engineer is said (among other things) to ‘capture’,
‘specify’, ‘elicit’ or ‘construct’ requirements. It is interesting to note
the position on the nature of requirements implicit in each term....
There is no term as yet in current use which suggests the ongoing
evolution of requirements from processes of interaction, both social
and technical, continuing through the whole lifecycle...”
(Jirotka and Goguen, 1994)
capture = einfangen,
elicit = herauslocken
27
PD
Partizipation & Gestaltung von Mensch-Computer-Systemen
Ein klein wenig Ketzerei
“The retroperspective character of requirements...
...
Another basic principle of social theory of information may be an
extension of Suchmann´s (1987) work on plans to the broader claim
that only post hoc explanations for situated events appear to attain
relative stability and independence from context; let us call this the
retroperspective hypothesis.”
(Goguen in Jirota and Goguen, 1994)
28
PD
Partizipation & Gestaltung von Mensch-Computer-Systemen
Sichtweisen von Konflikten
Klassische Methoden
•
•
•
•
unproblematisch
“müssen vom Auftraggeber geklärt werden”
“Akzeptanzproblem”
...
Partizipative Gestaltung
•
•
•
•
•
wichtiges Element --> Lernen aus Konflikten
konstruktiver Umgang
Raum für Konflikte schaffen
Hören auf das, was nicht gesagt wird
....
Was ist das Ziel? - Konfliktregelung oder Konfliktlösung
Konflikte im Projekt abbilden !?
29
PD
Partizipation & Gestaltung von Mensch-Computer-Systemen
Problem processing
Attention on
problem solving
‘problem’
What are the requirements?
Are these requirements complete?
What are the design options?
How to work on it - factual perspective.
Factual dimension
Attention on
problem definition
How comes this is a problem & for whom?
Is this the problem?
How do the participants work on it?
How to work on it - social perspective?
Process dimension
30
PD
Partizipation & Gestaltung von Mensch-Computer-Systemen
ANGEBOT
Was können wir annehmen über das Umfeld:
• Interesse
• Aufgabe ist klar definiert, weil Aufwand klar begrenzt ist (XX) - abzuschätzen
ODER weil sie problem definition beeinflussen
• man kann es selbst und hat die Zeit
• es geht von hocgradig geklärten Rollen aus - kooperativer Zielfestlegung
Was ist gut daran - für kooperatives Zusammenarbeiten?
– Definieren wodurch mehr Kosten entstehen können
Was ist nicht gut daran - für kooperatives Zusammenarbeiten?
– Nicht definiert wie viel Varianten berücksichtigt sind
• Anderer Ansatz erfordert eine Möglichkeit Varianten zu definieren
• setzt wenig auf problem definition auf
– Nicht definiert Zeittraum für Kapazitätssteuerung & für Kunden
31
PD
Partizipation & Gestaltung von Mensch-Computer-Systemen
Zusammenfassung - Reasons for Consulting
•
•
•
•
Why do people call in consultants (and pay for them)? From a classical perspective,
consultants are called in for factual reasons, like
 getting expertise in dealing with specific problems
 getting specific external views
 establishing new business contacts and linkages
 developing a plan for action
 getting an update on new trends and methods
 getting additional resources
Further reasons are cited in Titscher 97 & Kubr 93
 trying to change/improve the understanding of a problem
 view of impartial third party
 helping to initiate/push through some kind of change
 a general ‘health check’ of the organisation
 helping to justify cruel measures, getting legitimisation
 helping to justify no change – (“You see: even the consultant is not able to develop! How
could I …”).
Luhmann builds his analysis upon well-known shortcomings of consultants and views them as
functional.
 Consultants help organisations to forget prior experiences & to allow for change (p.40).
Correspondingly consultants have to be changed often, young consultants with little
experience are useful.
 Consultants have to bring in new perspectives on existing conflicts. (The use of “new”
does not necessarily imply better.)
Important further categories to describe consulting activities are:
 externality of the consultant
 independence and neutrality: (Kubr 1996, p.8) quoted in (Titscher 1997, p.31)
distinguishes 5 dimensions of independence: technical, financial, administrative, political,
and emotional.
 the degree of fuzziness of aims (before the project starts) and the degree of fuzziness of
methods (before the project starts)
32
 Size & length of projects

Document