Einheit 3 Verständnis von Arbeit & Kooperation

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. Attention onproblem solvingWhat are the requirements?Are these requirements complete?What are the design options? How to work on it - factual perspective. ‘problem’ Factual dimension Attention onproblem definitionHow 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 The problem

4. Ruth: (Text Joh) 000207 SPEZIALISIERUNG ProduktionLeistungserbringung Human Resource Management Personalbeschaffung & Auswahl Kapazitätsplanung Leistungsbeurteilung …. Arbeitszeitgestaltung Entgeltgestaltung Konflikte BR X GF Personalentwicklung Führung

5. Karin: 000214 Layout LEISTUNGEN IN DER BERATUNG Fachberatung Prozeßberatung Vorgehen & Projektorganisation Planungstechniken Moderation Ergonomie ... Abrechnung Recht ... Software & Werkzeuge

6. Joh: 991108 Ruth Layout BALANCE DER SPEZIALISIERUNG AUF BEREICHE 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 • ==> 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: • 1+2 es ist grundsätzlich möglich • 1 --> Verweis auf PersonenAlternative: 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 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)

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

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 ---> 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 • > 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

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

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

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

30. Attention onproblem solvingWhat are the requirements?Are these requirements complete?What are the design options? How to work on it - factual perspective. ‘problem’ Factual dimension Attention onproblem definitionHow 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 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 • 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