Einheit 3 Verst

1
Einheit 3Verständnis von Arbeit Kooperation
2
INHALT DER VORLESUNG
ICH als BERATER/ENTWICKLERin in EDV-PROJEKTEN
mit MENSCHEN
Arbeit mit Gruppen
EDV -Design in Gruppen
Angestrebte Rolle
Projekte
Inhalte
Vermarktung
Projektziele
Verantwortung
Vereinbarungen
Projektdesign
Rolle Berater
Anbote
Projektcontrolling
...
Kalkulation
Qualifizierung
...
...
EIGENE Annahmen(Kommunikation, Fairneß, Moral )
THEORETISCHE KONZEPTE
3
The problem
4
SPEZIALISIERUNG
Ruth (Text Joh) 000207
ProduktionLeistungserbringung
Human Resource Management
Personalbeschaffung Auswahl
Kapazitätsplanung
Leistungsbeurteilung
.
Arbeitszeitgestaltung
Entgeltgestaltung
Konflikte BR X GF
Personalentwicklung
Führung
5
LEISTUNGEN IN DER BERATUNG
Karin 000214 Layout
Fachberatung
Prozeßberatung
Vorgehen Projektorganisation
Planungstechniken
Moderation
Ergonomie
...
Abrechnung
Recht
...
Software Werkzeuge
6
BALANCE DER SPEZIALISIERUNG AUF BEREICHE
Joh 991108 Ruth Layout
Vorteile der Spezialisierung (Methoden-
Fach-wissen, 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

7
Ein gut organisierter Schreibtisch
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
• gt gemischtes Ergebnis des Ansatzes

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
• 12 es ist grundsätzlich möglich
• 1 --gt 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

10
Übersicht

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.

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
  workmans 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)

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ö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 GeschichtenEs gibt
  kein Wissen an sich, sondern nur
  aussagenproduzierende und interpretierende
  Personen

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 braucheWer bezeichnet
  wann was wie?Was für Handlungszusammenhänge
  werden damit bezeichnet?

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

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

17

• Freie Markt
• unsichtbare Hand invisible hand
• es braucht auch (Verweis auf sogar noch weiteren
  Zusammenhang)
• invisible hand-shake

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 gt ???

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

20
VORGEHEN

• KLASSISCH
• Wasserfall
• Projektphasen
• PRESKRIPTIV ---gt 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

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

22
Bsp. Aufgabe

• gt Klassische Herangehensweisen
• Automatisierung
• backtracking
• genetisches Programmieren
• ....
• basierend auf
• wohldefinierter Aufgabenstellung
• klaren Optimierungskriterien
• festen Elementen
• klaren Anforderungen
• sowie Lernmöglichkeiten (Zeit, Stabilität)
• gt Was tun, wenn diese Voraussetzungen nicht
  gegeben sind?
• Auf Interaktion ausgelegte Systeme z.B.
• Szenariodefinitionen
• Analysewerkzeuge
• Visualisierung

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.

24
Spezifikation

• Spezifikation lt--gt 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 lt--gt Technik
• Anforderungen hinsichtlich Implementierung (Was
  soll das System tun, aber nicht, wie es es tun
  soll!)
• Woher kommen Probleme?

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

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

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

28
Ein klein wenig Ketzerei

• The retroperspective character of
  requirements...
• ...
• Another basic principle of social theory of
  information may be an extension of Suchmanns
  (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)

29
Sichtweisen von Konflikten

• Klassische Methoden
• unproblematisch
• müssen vom Auftraggeber geklärt werden
• Akzeptanzproblem
• ...
• Partizipative Gestaltung
• wichtiges Element --gt 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 !?

30
Problem processing
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

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