Zum Hauptinhalt springen
Rocket Routine OSRocket Routine
DE
Sven steht an einer dunklen Wand mit vier ansteigenden Kreidelinien wie ein Höhendiagramm. Ein heller Bernstein-Marker liegt auf der zweiten Linie von unten, seine Hand ruht darauf, nachdem er ihn nach unten verschoben hat. Auf der Linie darüber ist ein halb verwischter Kreideschatten sichtbar, wo der Marker vorher stand.

Auf welcher Stufe steht dein Unternehmen? Und warum die meisten sich zu hoch einschätzen.

Die meisten Gründer können sagen, wie es ihrem Unternehmen geht. Die wenigsten können sagen, auf welcher operativen Stufe es steht, und fast alle schätzen sich eine zu hoch ein. Der Unterschied zwischen den Stufen entscheidet darüber, welcher nächste Schritt überhaupt etwas bringt.

Sven O. Rimmelspacher

Kurz gesagt: In der Frage nach den Daten stecken zwei Fragen. Wo verarbeitet wird, beantwortet dein Anbieter. Was das System anfassen darf, entscheidest du selbst, pro Tool und getrennt nach Lesen und Schreiben.

Frag zehn Gründer, wie gut ihr Unternehmen operativ läuft, und du bekommst zehn Antworten, die sich nicht vergleichen lassen. "Ganz ordentlich." "Wir sind besser geworden." "Chaotisch, aber es funktioniert." Das sind Stimmungen, keine Standortbestimmungen.

Operative Reife lässt sich präziser fassen, und zwar in vier Stufen: Ad hoc, Governed, Verified, Compounding. Ich habe sie in einem eigenen Artikel beschrieben. Hier geht es um etwas anderes, nämlich um die Frage, welche davon auf dich zutrifft, und warum diese Frage schwerer ist, als sie aussieht.

Die eigene Stufe zu kennen ist kein Etikett. Sie bestimmt, welcher nächste Schritt überhaupt etwas bringt.

Die vier Stufen, und woran du sie im Alltag erkennst

Ad hoc. Das Unternehmen läuft, weil bestimmte Menschen es am Laufen halten. Wissen steckt in Köpfen, Qualität schwankt je nachdem, wer die Aufgabe übernommen hat, und Standards sind besprochen oder gar nicht vorhanden. Der verlässlichste Indikator ist nicht Unordnung, sondern Abhängigkeit: Wenn eine bestimmte Person zwei Wochen ausfällt, verschiebt sich Arbeit oder sie bleibt liegen.

Governed. Die Regeln stehen. Entscheidungsrechte sind explizit zugeordnet, Routinen sind dokumentiert, Verantwortung ist benannt. Was fehlt, ist der Nachweis: "fertig" ist eine Behauptung, die niemand gegen einen definierten Standard prüft. Hier bleiben die meisten OKR- und Lean-Einführungen stehen, und hier fühlt sich Struktur zum ersten Mal nach Aufwand ohne Ertrag an.

Verified. "Fertig" wird belegt. Es gibt eine definierte Prüfung gegen einen definierten Standard, und die FTT (First Time Through) macht sichtbar, wie viel davon im ersten Anlauf hält. Der spürbare Unterschied im Alltag: Vertrauen wird zur Eigenschaft des Systems statt zur Eigenschaft einer Person. Du musst nicht mehr wissen, wer es gemacht hat, um zu wissen, ob es stimmt.

Compounding. Wenn etwas schiefgeht, ändert sich das steuernde Artefakt selbst, also die Routine, der Standard, der Role Contract. Derselbe Fehler nimmt nicht zweimal denselben Weg. Das ist der Punkt, an dem ein Learning tatsächlich etwas verändert, statt in einem Protokoll zu landen.

Warum die ehrliche Antwort meist eine Stufe tiefer liegt

Wer diese vier Beschreibungen liest, ordnet sich fast immer zu hoch ein. Das ist keine Eitelkeit, es hat einen strukturellen Grund: Wir bewerten uns nach unserer Absicht, und das System arbeitet mit Evidenz.

Drei Verwechslungen passieren dabei besonders oft.

Die erste: dokumentiert wird für geregelt gehalten. Ein Prozess existiert, weil ihn jemand einmal aufgeschrieben hat. Ob danach gearbeitet wird, wenn es eng wird, ist eine andere Frage. Ad hoc mit guter Dokumentation ist immer noch Ad hoc.

Die zweite, und das ist die teuerste: geprüft wird für verifiziert gehalten. Jemand schaut vor dem Ausliefern drüber, also fühlt sich das nach Qualitätssicherung an. Aber wenn kein definierter Standard existiert, gegen den geprüft wird, ist es ein aufmerksamer Mensch, kein Verfahren. Fällt der Mensch aus oder wird es hektisch, fällt die Prüfung mit aus. Das ist Governed, nicht Verified, und es ist genau die Stufe, auf der Struktur teuer wird, ohne sich zu bezahlen.

Die dritte: gelernt wird für verbessert gehalten. Es gab eine Retrospektive, alle waren ehrlich, es war ein gutes Gespräch. Wenn danach kein Artefakt anders aussieht, hat sich nichts verändert außer der Stimmung.

Wir bewerten uns nach unserer Absicht. Ein System bewertet nach Evidenz. Die Lücke zwischen beidem ist fast immer genau eine Stufe.

Die Stufe gilt pro Domain, nicht pro Unternehmen

Noch ein Grund, warum die schnelle Selbsteinschätzung selten trägt: Es gibt gar keine einzelne Stufe für ein ganzes Unternehmen. Der Vertrieb kann Ad hoc sein, während die Buchhaltung längst Verified ist, weil dort ein Steuerberater und gesetzliche Fristen einen Standard erzwungen haben.

Eine Gesamtnote verdeckt genau das, was du wissen musst. Interessant ist nicht der Durchschnitt, sondern das Gefälle: welche Domain am weitesten zurückliegt, und ob das die ist, die gerade dein Wachstum begrenzt.

Company 0

Ich kann das an unserem eigenen Betrieb zeigen, und zwar ehrlich, also mit der Einschränkung dazu.

Die Content-Produktion bei Rocket Routine liegt auf Compounding, und ich kann genau sagen, warum: Es gibt dokumentierte Regeln, aktuell dreizehn Edit-Patterns, es gibt eine definierte Prüfung vor jeder Freigabe, und wenn im Review etwas auffällt, ändert sich nicht der einzelne Artikel, sondern die Regel, die für alle folgenden gilt. Genau das ist die vierte Stufe.

Die Einschränkung: Das gilt für eine Domain, mit einem Menschen und einem AI-Operator. Andere Bereiche bei uns sind nicht dort, und ich würde nicht behaupten, dass ein Unternehmen mit dreißig Leuten dieselbe Bewegung in derselben Zeit macht. Aber es zeigt das Muster, um das es hier geht: Reife entsteht domainweise, nicht als Ganzes, und sie entsteht dort zuerst, wo jemand die Prüfung tatsächlich definiert hat.

Warum die genaue Stufe zählt

Der praktische Grund, warum sich diese Frage lohnt: Jede Stufe hat einen anderen nächsten Schritt, und der Schritt der falschen Stufe verpufft.

Stehst du auf Ad hoc, bringt dir eine Qualitätskennzahl nichts, weil es noch keinen Standard gibt, den sie messen könnte. Der nächste Schritt ist, Entscheidungsrechte und Routinen überhaupt aufzuschreiben. Stehst du auf Governed, ist mehr Dokumentation der teuerste Fehler, den du machen kannst. Der nächste Schritt ist eine definierte Prüfung für genau einen Output. Stehst du auf Verified, ist der nächste Schritt kein weiterer Standard, sondern der Rückweg vom Fehler ins Artefakt.

Dahinter liegt eine zweite Bewegung, die parallel läuft: wie viel Entscheidungsfähigkeit du überhaupt schon abgegeben hast. Ich habe das an anderer Stelle als fünf Entwicklungsstufen beschrieben, und die beiden hängen zusammen: Man klettert die Reifestufen hoch, indem man Entscheidungen und Arbeit schrittweise nach oben abgibt, an Menschen wie an gesteuerte AI-Operatoren.

Deshalb ist eine ungefähre Selbsteinschätzung wenig wert und eine genaue viel. Wer sich eine Stufe zu hoch einordnet, investiert zuverlässig in den übernächsten Schritt und wundert sich, dass nichts davon greift. Das ist der eigentliche Preis der Ungenauigkeit, und er fällt nicht sofort auf, sondern erst nach einem Quartal ohne Wirkung.

Was das für dich heißt

Nimm eine einzige Domain, nicht das ganze Unternehmen. Am besten die, an der gerade am meisten hängt. Und stell ihr eine Frage, die schwerer zu beschönigen ist als "läuft das gut":

Wenn diese Woche in diesem Bereich etwas Fehlerhaftes rausgeht, was genau würde es aufhalten, und würde es das auch dann aufhalten, wenn du im Urlaub bist?

Wenn die Antwort ein Mensch ist, deutet das auf Governed hin, egal wie gut dokumentiert ihr seid. Wenn die Antwort ein definiertes Verfahren ist, spricht das für Verified. Und wenn du sagen kannst, was sich nach dem letzten Fehler dauerhaft geändert hat, weist das in Richtung der vierten Stufe.

Diese eine Frage ist ein grober Schnitt, kein Befund. Sie sagt dir die Richtung, nicht die Stufe, und schon gar nicht, welcher Hebel bei dir der wirksamste wäre. Dafür braucht es mehr als eine Frage, und die Genauigkeit lohnt sich, denn an ihr hängt, ob dein nächstes Quartal etwas bewegt oder nur beschäftigt.

Häufige Fragen

Was ist eine Tool-Access-Policy?

Ein Pflichtbestandteil des Role Contracts: Lese- und Schreibgrenzen, pro Tool definiert, nach dem Least-Privilege-Prinzip. Nicht "hat Zugriff auf unsere Systeme", sondern pro System und pro Richtung festgelegt.

Warum ist der Unterschied zwischen Lese- und Schreibzugriff so wichtig?

Ein Operator mit Lesezugriff kann etwas Falsches ableiten, und das fällt in der Qualitätsprüfung auf. Ein Operator mit Schreibzugriff verändert den Zustand deines Unternehmens. Deshalb ist Schreibzugriff die begründete Ausnahme und nicht die Voreinstellung.

Wo werden meine Daten bei einem AI-Operator verarbeitet?

Das beantwortet der Anbieter, nicht das Betriebssystem. Rocket Routine OS ist bewusst provider-agnostisch gebaut: Welches Sprachmodell darunter arbeitet, entscheidet der Mandant, und die Entscheidung lässt sich wechseln, ohne dass sich die Steuerung darüber ändert.

Wie fange ich mit einer Zugriffsregelung an?

Mit einer Tabelle aus vier Spalten: welches System, lesen oder schreiben, welcher Ausschnitt, und wer es merkt, wenn etwas Falsches geschrieben wurde. Wer sie für die erste Rolle ausfüllen kann, hat eine Tool-Access-Policy.

Willst du das in deinem Unternehmen aufbauen?

Rocket Routine OS ist das Betriebssystem hinter diesen Artikeln, und es ist noch nicht offen verfügbar. Auf der Warteliste erfährst du als Erster, wenn es so weit ist, bekommst alle zwei Wochen einen ehrlichen Bericht darüber, was funktioniert und was nicht, und rückst mit jeder Empfehlung weiter nach vorn.

Auf die Warteliste eintragen

Willst du das ganze System verstehen?

Die gesamte Architektur von Rocket Routine OS als PDF — 20 Seiten, frei verfügbar, kein Formular.

Whitepaper herunterladen (PDF)