Business und Technologie widersprechen sich. Wer entscheidet?

Der Widerspruch ist oft sachlich

‹Technisch bereit› und ‹betrieblich nicht bereit› können gleichzeitig wahr sein. Architektur, Performance und Fehlerlage können innerhalb technischer Toleranzen liegen, während Prozesse, Kontrollen, Schulung, Daten oder Support noch nicht tragfähig sind. Eine Abstimmung per Mehrheitsentscheid verdeckt diese unterschiedlichen Evidenzbereiche.

Eine gemeinsame Behauptungsstruktur

Das Gremium sollte jede strittige Aussage in Behauptung, Evidenz, Unsicherheit, Abhängigkeit und Konsequenz zerlegen. So wird sichtbar, ob Funktionen über dasselbe Risiko sprechen oder nur verschiedene Teile des Systems bewerten.

Die Orange-Book-Prinzipien verlangen, Risiko in Entscheidungen zu integrieren und Rollen sowie Accountabilities klar zuzuordnen. Der Risikoeigner darf technische Grenzen nicht ignorieren; Technologie darf den geschäftlichen Risikoentscheid aber auch nicht stillschweigend übernehmen.

Evidenz zu prüfen

Benötigt werden gemeinsame Exit-Kriterien, Ende-zu-Ende-Tests, Betriebs- und Supportfähigkeit, Daten- und Kontrollnachweise, bekannte Defekte, Workarounds, Volumenannahmen und ein klares Residual-Risk-Statement. Abweichende Bewertungen müssen mit Quellen und Entscheidungsauswirkung dokumentiert werden.

Warnzeichen

Warnzeichen sind getrennte Statusberichte, unterschiedliche Definitionen von ‹ready›, ein Go-live-Datum ohne benannten Risk Owner, oder eine Eskalation, die nur die lautere Funktion belohnt.

Managementfragen

Welche konkrete Behauptung ist strittig? Welche Evidenz würde sie widerlegen? Wer akzeptiert das Restrisiko? Welche Folgen trägt der Betrieb? Welche Entscheidung ist reversibel und welche nicht?

Wann ein unabhängiger Review hilft

Ein Review hilft, wenn Funktionen ihre eigenen Beweise produzieren und das Steuerungsgremium keine gemeinsame Entscheidungsbasis mehr hat. Er testet nicht, welche Funktion ‹recht› hat, sondern welche Aussage für die Entscheidung ausreichend getragen ist.