Funktionale Komplexitätsreduktion
Ein systemischer Designansatz zur Reduktion unnötiger Komplexität — mit dem Ziel klarer Systeme, stabiler Prozesse und wartbarer Software.
Die meisten Systeme werden mit der Frage gebaut: «Wie kann man das besser organisieren?»
FKR stellt eine andere Frage: «Warum existiert diese Komplexität überhaupt?»
Das ist kein kleiner Unterschied. Er verändert den Ausgangspunkt vollständig. Wer organisiert, verwaltet Komplexität. Wer nach dem Warum fragt, eliminiert sie.
Das gilt für Software genauso wie für Prozesse, Infrastruktur und Entscheidungsstrukturen in Unternehmen. Ein Feature das niemand braucht ist technische Schuld. Eine Abhängigkeit die niemand versteht ist ein Ausfallrisiko. Ein Prozess der nur funktioniert weil die richtige Person da ist, ist keine Struktur — er ist eine Schwachstelle.
Nicht verbessern. Nicht organisieren. Nicht erweitern.
Zuerst: eliminieren.
Jedes Element hat eine klare primäre Funktion. Ist sie nicht eindeutig benennbar, gehört das Element nicht ins System.
Optionen werden aktiv begrenzt. Mehr Konfigurationsmöglichkeiten, mehr Codepfade, mehr Zuständigkeiten — jede davon ist eine potenzielle Fehlerquelle und ein Wartungsaufwand. Weniger Optionen bedeuten klarere Systeme.
Wissen über Systeme, Prozesse und Entscheidungen gehört in externe Strukturen — nicht in die Köpfe einzelner Personen. Was nur eine Person weiss, ist keine Ressource. Es ist eine Abhängigkeit.
Wiederkehrendes wird standardisiert. Systeme, die jedes Mal neu durchdacht werden müssen, sind keine Systeme — sie sind versteckte Komplexität.
Qualität ist nicht das, was hinzugefügt wird, sondern das, was übrig bleibt, wenn unnötige Komplexität entfernt wird.
Inspiriert von Bauhaus, Dieter Rams und Robert M. Pirsig.
Wenn zwei Dinge denselben Zweck erfüllen, ist eines zu viel.
Redundanz ist kein Sicherheitsnetz. Sie ist versteckte Komplexität.
Alles, was im Kopf bleibt, ist ein Systemfehler.
Gute Systeme externalisieren Wissen. Schlechte Systeme erzeugen stille Abhängigkeiten — von einzelnen Personen, von undokumentierten Annahmen, von Erfahrungen die nirgends stehen.
Komplexität entsteht von selbst. Klarheit nur durch bewusste Entscheidungen.
Kein System bleibt ohne aktive Pflege klar. Komplexität ist der Standardzustand.
Systeme sollen funktionieren, nicht beeindrucken.
Features, die niemand braucht, sind kein Mehrwert. Sie sind Komplexität mit schönem Namen.
Wenn zwei Dinge denselben Zweck erfüllen, ist eines zu viel.
Jedes Element braucht eine klare primäre Funktion. Ist sie nicht eindeutig, ist das System fehlerhaft.
Was nur im Kopf einer Person existiert — ein Prozessschritt, eine Architekturentscheidung, ein Zugangsdaten — ist eine systemische Abhängigkeit und damit ein Risiko.
Reibung ist ein Hinweis auf unnötige Komplexität. Was regelmässig nervt, gehört überarbeitet oder entfernt.
Zu viele Optionen sind kein Vorteil, sondern eine Belastung. Reduktion schafft Klarheit.
Was nicht sauber ins System passt, gehört nicht ins System.
Komplexität wächst von selbst. Reduktion passiert nur durch bewusste Entscheidungen.
«Die meisten Menschen haben kein Fokusproblem, sondern ein Systemproblem.»
Zu viele offene Aufgaben, Optionen und unklare Zustände erzeugen mentale Last. Fokus kann das kurzfristig überdecken, aber nicht lösen.
«Mehr Tools lösen selten Probleme — sie verschieben sie.»
Neue Tools erhöhen oft die Komplexität, wenn sie nicht in ein klares System integriert sind.
«Organisation ohne Reduktion ist nur gut verwaltete Komplexität.»
Tasks, Listen und Systeme helfen nur begrenzt, wenn die zugrunde liegende Komplexität nicht reduziert wird.
«Wenn ein System erklärt werden muss, ist es zu komplex.»
Gute Systeme sind intuitiv nutzbar und selbsterklärend.
«Effizienz ohne Klarheit erzeugt nur schnelleres Chaos.»
Optimierung macht nur Sinn, wenn das System selbst sinnvoll aufgebaut ist.
«Die meisten Probleme sind keine Probleme, sondern Nebenwirkungen von Komplexität.»
Viele Friktionen entstehen nicht durch fehlende Lösungen, sondern durch zu viele Elemente und Abhängigkeiten.
Ein Tool, eine Aufgabe. Schweizer Fahrzeugtypenscheine abfragen — ohne Registrierungszwang, ohne Upsell, ohne Dashboard das niemand braucht.
Firmenwissen gehört nicht ins Gedächtnis von Mitarbeitenden. Tenkan setzt Prinzip 03 direkt um: ein externes System, das Wissen strukturiert zugänglich macht.
Wir bauen nichts, weil es technisch möglich ist. Jedes Element muss eine klare primäre Funktion haben — oder es kommt nicht rein. Gesetz #2, konsequent.
Kein Docker, wenn systemd reicht. Kein React, wenn HTML funktioniert. Kein Postgres, wenn SQLite die Anforderungen erfüllt. Komplexität muss sich rechtfertigen, nicht Einfachheit.