Summary (4-5)

Organizational Informatics

Organizational Informatics - Kling 2000

Funktion von Computerisierung bei Gestaltung von Organisationsstrukturen

Begriffe

Institution

zB Ehe, Familie

geregeltes Zusammenwirken

soziale Strukturen mit etablierter Ordnung

geleitet von Regeln - standardisierte Handlungsmuster

Organisation

zB Firmen, Kirche, Finanzamt, Sportverein

haben Ziele, Rollen, Hierarchien

hierarchische Autoritätsstrukturen

Verteilung von Macht, Rollen, Ressourcen

Kommunikaitons, Kooperationsstrukturen

Formalisierung von Regeln, Erwartungen, Pflichten

Beispiel: Universität

Institution, da:

instutionalisierte Reflexion

gesellschaftliche Einrichtung zur wissenschaftlichen Reflexion

Organisation, da:

Ziele, Rollen, Hierarchien

Information

Daten + Interpretation = Kontextgebundene, kontextabhängige Bedeutung

Zweckgebundene Interpretation

Interpretation unterschiedlich je nach Intention

Bias

Definition

Systemrationalisierung

falsches Konzept.

Systeme als rationale Systeme mit formalen Zielen und abläufen

Prozesse und Ziele sind in Wirklichkeit vielschichtig, nuanciert, komplex

Einsatz von ICTs in Organisationen

= Soziotechnisches Informationsnetzwerk STIN

zB Telearbeit, Professor, System Manager

braucht aktives Change Management

"Systemrationalismus" stimmt nicht

Systeme sind nicht rationale Systeme die man formalisieren kann

Das ist eine vereinfachte technische Perspektive

Organizational Informatics (Sawyer 2008)

situated / Situertheit = (STIN + Einsatz-Kontext)

ICTs sind socially embedded in institutionelle und organisatorischen Kontexten.

Interpretation von Daten passiert beim Nutzer

Technikaneigung

Technik wird fĂĽr neue ursprĂĽnglich nicht vorgesehene Zwecke verwendet.

Politische Konsequenzen = Organizational Policy

Informationszugang bedeutet Macht

bedeutet UnterstĂĽtzung, Widerstand, Sabotage von Entwicklungen

Beeinflussung von Struktur und Politik der Organisation (Machtverteilung, Ressourcenverteilung)

Konsequenzen des Einsatzes von ICTs (Sproull/Kisler)

Neues Kommunikationsverhalten, soziale Handlungen und Beziehungen

Vorteile

Mehr Egalität, Demokratie, Offenheit, Beteiligung

Weniger Statusunterschiede

Erhöhte Transparenz

Neue Arbeitsplätze und Abläufe

Sprachlose Koordinierung, enge Kopplung, Schichtenarbeitsplätze

Nachteile

Ineffizienz, Flaming, Indifferenz, Hate speech, zu viel Auswahl

Intransparente, implizite Regeln und Biases

Integrierte Sicht und Dokumentation aller Abläufe kann zu Überwachung führen

Beispiel: System- und Softwareentwicklung als STINs

Akteure = Gruppen, Personen, Abteilungen, Organisationen

Technische Artefakte = Software

Praktiken = Handlungen, Kommunikation

Arbeitsaufgaben, Prozesse

Ressourcen

Gesetzliche Rahmenbedingungen, Vorschriften

Entwicklung von STINs

🔧 Technikfokussierte Perspektive

Entspricht der Produktionssicht

Vorgegebene Probleme

formalisierte Anwendung

Eigenschaften

Systemrationalismus

linearer Workflow

BerĂĽcksichtigt nicht genug:

Einsatzkontext, Sozialkontext, Userneeds, Folgen, Ethik

zB Aufgaben, Handlungspraxis bei der Nutzung, organisatorisches Umfeld

Geht dadurch am Bedarf des Users vorbei

Ablauf

Auftraggeber → Informatiker → Computerartefakt ohne Kontextbezug, Einbettung

Requirements → Technische Umsetzung → Produkt

đź«‚ Soziotechnische Perspektive

Man muss die soziotechnische Perspektive einnehmen.

Vernachlässigung bedeutet kognitivistische und rationalistische Sicht auf Design - Systemrationalismus

Es gibt keinen "besten Weg" in der Umsetzung. → Systemrationalismus vermeiden.

Die Gestaltung ist ein

wechselseitiger konstruktiver und kommunikativer Prozess in Bezug auf veränderliche Nutzungs- und Einsatzkontexte

Eigenschaften

Iterativ

Schrittweise, zirkuläre annäherung

Partizipativ

BerĂĽcksichtigung von Einsatz-Kontext, User needs, Folgen

Social, Contextual Inquiry

Ethische Ăśberlegungen

Erkundung des Kontexts als empirisch-soziale Herangehensweise

ICT-Entwickler als agents of change

mit Gestaltungsspielraum

Ablauf

Auftraggeber → Informatiker ↻\circlearrowright → STINs, keine Computerartefakt

Requirements → Iterative Schritte ↻\circlearrowright → Ergebnis, embedded im Einsatz-Kontext


Iterative Schritte:

Problemanalyse und Definition

Technische Umsetzung

ĂśberprĂĽfung

Verbesserung, Verfeinerung


Dabei mit einbezogen:

dynamischer, kommunikativer Prozess

Auftraggeber, User, Experten (interdisziplinär)


BerĂĽcksichtigt und exploriert :

Einsatzkontext, User Needs, Folgen


Nicht problem-solving sondern problem-setting

Problemstellung und Problemdefinition ist nicht gegeben sondern wird erarbeitet und iterativ ĂĽberarbietet.

Es wird bestimmt welche Probleme am wichtigsten sind und welche Perspektive eingenommen wird.

Es gibt keine einzige richtige Lösung

Es wird durch informatisches Handeln einer der vielen möglichen Lösungen gewählt

Gestaltung von STINs

(Sommerville 2008)

Pragmatische Akzeptanz

davon dass Menschen irrational sind

von Zielen die im Konflikt zu einander stehen

davon dass es widersprĂĽchliche Meinungen gibt darĂĽber wann ein ICT-System erfolgreich ist

Vielfalt von Prozessen

Falsche Ansicht:

Alle User sind gleich und mĂĽssen sich an technischen Vorgaben und Prozesse orientieren.

Keine Rücksicht auf UX/UI, Nützlichkeit, Unterstützung der User bei Problemlösung

Richtige Ansicht:

real-world-Prozesse sind vielfältig, kontingent, kontextabhängig

Menschen nutzen ICTs basierend auf ihren eigenen Erfahrungen und Kompetenzen

Gestaltung von ICTs

Entwicklung, Gestaltung, Designprozess

Menschen verstehen

  • contextual inquiries

    Einsatz-Kontext verstehen

  • Social inquiries

    Bedürfnisse, Präferenzen in STINs erkennen

    • Partizipativ

      Co-Design, Co-Evolution

      Fieldwork, Partizipative Methode → Einbeziehung der Nutzer

      Betroffene Menschen bei Entwicklung mit Einbeziehen → Beteiligte verstehen ihre Domäne

    • Tacit Knowledge

      Domain/Prozesskenntnisse als Expertise

      Prozesswissen, Fertigungsskills der Betroffenen

      Ist implizit und nicht formalisierbar


Handeln, Arbeitsabläufe verstehen

Reale Arbeitsabläufe in Organisation beobachten

Was kann verbessert werden, was sollte so bleiben?


Ziele berĂĽcksichtigen

UserbedĂĽrfnisse vs. Ziele der Organisation, soziokulturelle Normen


integrierte Technik-Folgenabschätzung

integrierte Technikbewertung

Mögliche Konsequenzen nach Einführung voraussagen

Anpassungsmöglichkeit bei Wandel von User und Organisation im Laufe der Zeit

ZukĂĽnftiger Einsatz-Kontext

Konsequenzen durch Nutzung der Computerartefakte

GrĂĽnde fĂĽr Gestaltung von STINs

Dieser Ansatz ist teuer.

  1. Qualitätssteigerung

    Durch BerĂĽcksichtigung von

    Domain-Prozesskenntnisse und Expertise der Nutzerinnen

    zukĂĽnftigen Nutzungskontexts

    Konsequenzen im Designprozess


    Bessere Usability, UX, Effektivität in der Unterstützung bei der Aufgabe die das System erfüllen soll.

    Alle Möglichkeiten der Nutzung werden realisiert.

  1. Erhöhung der Akzeptanz und Zufriedenheit bei Nutzern

    Realistische Erwartungen

    Weniger Widerstand gegen Veränderung

  1. Verbesserte "Time to Value"

    Time-to-Value

    Zeit bis effektiver Mehrwert und Nutzen erzeugt wurde.

    Abhängig von Beauftragung, Entwicklungszeit, Einsatz und vor allem: Assimilation und Akkomodation


    Assimilations-Periode (Aufwand von Entwicklern)

    Anpassung des ICT-Systems bis nĂĽtzlich

    Akkomodations-Periode (Aufwand von Organisation)

    Änderung der Organisationsstruktur um ICT-System optimal nutzen zu können

Wenn man Assimilations & Akkomodations Zeit verkürzt: ↓\small \downarrow Time to value aber der Brauchbarkeits-Gap bleibt gleich

Schritte

ICT-Entwickler gestalten nicht Technik sondern ein STIN

Partizipative Herangehensweise = User-Involvement

participatory design

user-centered design

human-centered design

  1. Fieldwork und Partizipative Methoden

    social inquiries, contextual inquiries

    Einbeziehung der Nutzer

    Verstehen vom Status Quo

    Exploration der Vielfalt des Feldes, der Tätigkeiten, Abläufe in ihrem Einsatzkontext durch

    Teilnehmende Beobachtung, Interviews

    Unterschiede zwischen Menschen und Gruppen feststellen

    Regeln fĂĽr gutes Beobachten:

    Vorurteile vermeiden, urteilsfrei Erfahrungen sammeln

    Zurückhalten und sich nicht in den Vordergrund drängen

    Aufmerksam sein, Details beachten

    Offene Fragen stellen

    Im Vorab informieren und vorbereiten

    Resultate mit Projektteam teilen

    Vertraut werden mit

    Domäne, Tätigkeiten, Aufgaben, Handlungen, Arbeits-Abläufe, Prozesse, benutzte Technologien, Routinen, soziale Interaktionen, Teamarbeit


  1. Discovery Process - Gemeinsamer Erkenntnisprozess

    Werte, Ziele, erwĂĽnschte Outcomes

    zB durch organizational games, role-playing games, future workshops, storyboarding

    Phasen

    1. Critique Phase

      Identifikation von Problemen

    1. Fantasy Phase

      Utopie entwickeln

      unkonventionelle Lösungsvorschläge

      Gemeinsame Überlegung wo ein ICT unterstützen könnte

      ergebnisoffener Rahmen, out-of-the-box-thinking, Brainstorming

    1. Realization Phase

      Realisierbarkeit ĂĽberprĂĽfen und bewerten

      Einigung auf nächsten Schritte


  1. Prototyping

    Iterativ - Zwischenergebnisse immer diskutieren in einfacher Sprache

    Mockups, Paper prototyping

AusmaĂź an Partizipation

Ziel: Verbesserung der Akzeptanz

Grade

Keine Partizipation

Nichts, Information, schriftliche Datenerhebung

Fieldwork und Exploration

Consulting, Dialog

Mitwirkung, Mitbestimmung

Formen

Direkte Beteiligung ( User-Involvement )

Domänenwissen von User, erhöhte Akzeptanz

Kann bei zu viel Beteiligung die ICT-Entwickler irritieren

Direkte Beteiligung von bestimmten Usern

ausgewählte User und Gruppen

Key-User

Repräsentative Beteiligung in Unternehmen

Repräsentative Beteiligung der Gesellschaft

Methoden

Interviews

Teilnehmende Beobachtung

Arbeitsanalyse mit den Betroffenen

Future Workshops

Socio-technical Walkthroughs

Dokumentenanalyse (als ergänzende Methode: im Vorfeld der Fieldwork)

Schriftliche Befragungen (nur Notlösung)

Modellierung

Modell ≠ Wirklichkeit

soziale Situationen ≠ formalisierbar

Modell

Vereinfachte Abbildung eines Teilbereiches der Realität zur Abstraktion

Abbildung von Objekten, Eigenschaften, Relationen

Entwicklungsintention, Nutzungskontext


Eigenschaften

  1. Abbildungsmerkmal abbilden
  1. VerkĂĽrzungsmerkmal vereinfachen
  1. Pragmatisches Merkmal eingeschränkte Ausdrucksstärke

    erfĂĽllen bestimmten Zweck fĂĽr ein Subjekt

(Daten-)modelle als soziale Realitätskonstruktion

Sinnrekonstruktion durch Modell basierend auf Interpretation des Subjekts

kanalisiert Wahrnehmung

handlungsanleitend

abhängig von Vorurteilen und politischen Interessen der Modellentwickler

hält die sozial konstruierte Realität aufrecht

Informatische Modellierung

Informatische Modellierung

Modellierung im Entwicklungsprozess von Computerartefakten

Modellierung operationaler Modelle die Computerprogramme ausfĂĽhren

Modell als Ăśbergang, Filter zwischen Wirklichkeit und Formalisierung

Computer und Wirklichkeit

Modell bestimmt wie Computer in Wirklichkeit agiert

Austausches von Umwelt und modellierten Dingen beschränkt.

Die Umwelt des Computers, mit der er in Austausch tritt ist artifiziell - auch wenn es ein natĂĽrlicher, sozialer Kontext ist.

Beispiel: Transrapid - Maglev Zug

Modellierungssituation ≠ Einsatzsituation

Zeit vergeht, Gegenstandsbereich ändert sich

Ist gegen Wartungsfahrzeug gefahren, weil es fĂĽr das Kontrollsystem unsichtbar war.

Modell-Typen

S(pezifikation)-Programm

zB ggt-Algorithmus

technische Perspektive - reine Problemlösung

bereits formal spezifiziert

P(roblem)-Programm

zB Schach-Algorithmus

Wechselwirkung mit Kontext

Problemsicht aus realen Welt flieĂźt ein

E(mbedded)-Programm

zB Airbus-Cockpit Steuerung

Wechselwirkung mit Kontext

Nur mit sozialen Gebrauchskontext, Einsatzkontext verständlich

Ethik

Ethik und Verantwortung in der Informatik

Ethische Dilemmata von advanced computer systems

Darf der Computer Menschen hindern?

Wer ĂĽbernimmt die Verwantwortung von autonomen Systemen?

Kann ein Computer verantwortlich sein?

Verein Deutscher Ingenieure (VDI) → Ethische Grundsätze

Ingeneure sind fĂĽr Folgen ihrere Arbeit verantwortlich

müssen sich über Zusammenhänge und zukünftige Auswirkung im gesellschaftlichen, ökologischen, ökonomischen Kontext bewusst sein

Definition

Moral

Menge an Ăśberzeugungen die Handlungsweisen als gut oder schlecht werten

Bezugspunkt: Normen (verbindlich fĂĽr alle Mitglieder einer Kultur / Gesellschaft)

≠ Benimmstandards und Konventionen

≠ individuelle Vorlieben

Norm

Beschreibt soll-Zustand

Regeln fĂĽr menschliches Handeln

Geltung in Kultur, Gesellschaft usw

Ethische Normen beziehen sich auf moralischen Prinzipien

Ethik

Ethische Theorie dient als BegrĂĽndung fĂĽr moralische Prinzipien

Verantwortung

Rechenschaftspflicht fĂĽr eigene Verhaltensweisen (und deren Folgen)