Zum Hauptinhalt springen

Komplexität vs. Determinismus

Planungsmodelle beruhen auf impliziten Annahmen über die Natur eines Systems.

In der Organisations- und Systemtheorie wird häufig zwischen deterministischen und komplexen Systemen unterschieden.

Diese Unterscheidung ist zentral für das Verständnis von Softwareentwicklung.


Deterministische Systeme

Deterministische Systeme zeichnen sich aus durch:

  • stabile Ursache-Wirkungs-Beziehungen
  • Wiederholbarkeit
  • geringe Varianz
  • planbare Dauer

Beispiele:

  • Serienfertigung
  • standardisierte Produktionsprozesse
  • Routinearbeiten mit bekannten Abläufen

In solchen Systemen funktionieren:

  • präzise Zeitplanung
  • Ressourcenoptimierung
  • Auslastungsmaximierung

Die Dauer eines Vorgangs ist mit hoher Wahrscheinlichkeit vorhersagbar.


Komplexe Systeme

Komplexe Systeme zeichnen sich aus durch:

  • Ursache-Wirkung erst rückblickend erklärbar
  • emergentes Verhalten
  • hohe Kontextabhängigkeit
  • strukturelle Unsicherheit

In komplexen Systemen entsteht Erkenntnis während der Arbeit.

Softwareentwicklung gehört überwiegend in diese Kategorie.

Gründe:

  • Anforderungen sind interpretativ
  • Lösungswege sind nicht vollständig vorab bekannt
  • Architektur beeinflusst Implementierung
  • Wissensunterschiede erzeugen Varianz

Theoretischer Hintergrund

Die Unterscheidung findet sich u. a. in:

  • Snowden & Boone (2007), A Leader’s Framework for Decision Making
  • Stacey (1996), Complexity and Creativity in Organizations
  • Drucker (1999), Knowledge Work

Diese Modelle zeigen:

Planungsinstrumente sind nur dann stabil, wenn sie zum Systemtyp passen.


Konsequenz für Planung

Zeitplanung setzt implizit voraus:

  • stabile Rahmenbedingungen
  • geringe Varianz
  • bekannte Lösungswege

Diese Annahmen treffen in komplexer Wissensarbeit nur eingeschränkt zu.

Das führt zu:

  • scheinbarer Präzision
  • realer Unsicherheit
  • Steuerungsinstabilität

Zentrale Beobachtung

Wenn Organisationen komplexe Arbeit mit deterministischen Modellen steuern,
entsteht ein struktureller Modellkonflikt.

Dieser Konflikt erklärt viele Spannungen in Softwareprojekten
unabhängig vom verwendeten Framework.