Post on 12-Jan-2016
description
PD Partizipation & Gestaltung von Mensch-Computer-Systemen
1
Einheit 3
Verständnis von Arbeit & Kooperation
PD Partizipation & Gestaltung von Mensch-Computer-Systemen
2
ICH als BERATER/ENTWICKLERin in EDV-PROJEKTEN mit MENSCHEN
INHALT DER VORLESUNG
Angestrebte Rolle
Inhalte
Verantwortung Vereinbarungen
Anbote
Kalkulation
Projekte
Vermarktung
Projektdesign
Projektcontrolling
Arbeit mit Gruppen
Qualifizierung
Projektziele
EDV -Design in Gruppen
Rolle Berater
... ...
EIGENE Annahmen(Kommunikation, Fairneß, Moral …)
THEORETISCHE KONZEPTE
...
PD Partizipation & Gestaltung von Mensch-Computer-Systemen
3
The problem
‘problem’
Attention onproblem 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?
Attention onproblem solvingWhat are the requirements?Are these requirements complete?What are the design options? How to work on it - factual perspective.
Process dimension
Factual dimension
PD Partizipation & Gestaltung von Mensch-Computer-Systemen
4
SPEZIALISIERUNG
Human Resource Management
Personalbeschaffung & Auswahl
Leistungsbeurteilung
Arbeitszeitgestaltung
Personalentwicklung
ProduktionLeistungserbringung
Führung
Konflikte BR X GF
….
Kapazitätsplanung
Entgeltgestaltung
Ruth: (Text Joh)
000207
Ruth: (Text Joh)
000207
PD Partizipation & Gestaltung von Mensch-Computer-Systemen
5
LEISTUNGEN IN DER BERATUNG
Fachberatung
Planungstechniken
Ergonomie
Abrechnung
Recht
Prozeßberatung
... Software & Werkzeuge
Moderation
Vorgehen & Projektorganisation
...
Karin:
000214 Layout
Karin:
000214 Layout
PD Partizipation & Gestaltung von Mensch-Computer-Systemen
6
BALANCE DER SPEZIALISIERUNG AUF BEREICHE
Vorteile der Spezialisierung
(Methoden- & Fach-wissen, Tools, … )
Nachteile der Spezialisierung(Blindheit, … )
KRITISCH:• Rollenklärung & Verantwortung• Checks Review (intern & mit Kunden)• interne Procedures für Annahme // Ablehnung & Ausrichtung von Projekten • Kooperationsnetze & Supervision, breite Weiterbildung
Ist es wirklich z.B. Arbeitszeit?Arbeitszeit als Trigger?
Joh:
991108 Ruth Layout
Joh:
991108 Ruth Layout
PD Partizipation & Gestaltung von Mensch-Computer-Systemen
7
Ein “gut organisierter” Schreibtisch
PD Partizipation & Gestaltung von Mensch-Computer-Systemen
8
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
PD Partizipation & Gestaltung von Mensch-Computer-Systemen
9
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
PD Partizipation & Gestaltung von Mensch-Computer-Systemen
10
Übersicht
PD Partizipation & Gestaltung von Mensch-Computer-Systemen
11
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.
PD Partizipation & Gestaltung von Mensch-Computer-Systemen
12
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)
PD Partizipation & Gestaltung von Mensch-Computer-Systemen
13
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öglichTHESE 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
PD Partizipation & Gestaltung von Mensch-Computer-Systemen
14
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?
PD Partizipation & Gestaltung von Mensch-Computer-Systemen
15
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 deppert15‘ … Konflikte um Macht un Anerkennung
PD Partizipation & Gestaltung von Mensch-Computer-Systemen
16
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
PD Partizipation & Gestaltung von Mensch-Computer-Systemen
17
Freie Markt … – unsichtbare Hand … invisible hand– es braucht auch (Verweis auf sogar noch weiteren Zusammenhang)
• invisible hand-shake
PD Partizipation & Gestaltung von Mensch-Computer-Systemen
18
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 ==> ???
PD Partizipation & Gestaltung von Mensch-Computer-Systemen
19
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
PD Partizipation & Gestaltung von Mensch-Computer-Systemen
20
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
PD Partizipation & Gestaltung von Mensch-Computer-Systemen
21
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
PD Partizipation & Gestaltung von Mensch-Computer-Systemen
22
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
PD Partizipation & Gestaltung von Mensch-Computer-Systemen
23
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.
PD Partizipation & Gestaltung von Mensch-Computer-Systemen
24
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?
PD Partizipation & Gestaltung von Mensch-Computer-Systemen
25
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
PD Partizipation & Gestaltung von Mensch-Computer-Systemen
26
Ü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...)
PD Partizipation & Gestaltung von Mensch-Computer-Systemen
27
“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
PD Partizipation & Gestaltung von Mensch-Computer-Systemen
28
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)
PD Partizipation & Gestaltung von Mensch-Computer-Systemen
29
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 !?
PD Partizipation & Gestaltung von Mensch-Computer-Systemen
30
Problem processing
‘problem’
Attention onproblem 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?
Attention onproblem solvingWhat are the requirements?Are these requirements complete?What are the design options? How to work on it - factual perspective.
Process dimension
Factual dimension
PD Partizipation & Gestaltung von Mensch-Computer-Systemen
31
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
PD Partizipation & Gestaltung von Mensch-Computer-Systemen
32
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)
Size & length of projects