CompanyOS planen: Prozesse, Zuständigkeiten und Systemgrenzen klären

01

Vom Unternehmenswissen zum ausführbaren Prozess

Ein CompanyOS soll Unternehmenswissen so organisieren, dass Menschen und Software damit zuverlässig arbeiten können. Dazu gehören verbindliche Quellen, Zuständigkeiten, aktuelle Arbeitsstände und nachvollziehbare Entscheidungen. Eine geordnete Ablage ist dafür eine Grundlage. Der praktische Nutzen entsteht, wenn sich eine konkrete Frage damit schneller beantworten oder eine Aufgabe verlässlich erledigen lässt.

Eine Herausforderung beim Aufbau ist die unterschiedliche Bedeutung von Wissen und Betrieb. Eine Leistungsbeschreibung erklärt, was ein Unternehmen anbietet. Ein Workflow beschreibt, wie ein Anliegen bearbeitet werden soll. Ein Laufnachweis zeigt, was tatsächlich passiert ist. Werden diese Inhalte gleich behandelt, kann ein Plan wie ein aktueller Zustand wirken oder eine technische Notiz unbeabsichtigt zur Geschäftsregel werden.

Ein sinnvoller Einstieg besteht deshalb darin, zuerst einen wiederkehrenden Arbeitsablauf zu beschreiben. Bei einer Webagentur könnte das die Bearbeitung einer eingegrenzten Websiteänderung sein: Anliegen verstehen, Kundenbezug herstellen, Umfang klären, Änderung ausführen, Ergebnis prüfen und Abschluss nachführen. An diesem Ablauf lässt sich feststellen, welche Informationen und Verantwortungen tatsächlich gebraucht werden.

02

Das sem.-Beispiel: eine verbindliche Quelle je Information

Im sem. CompanyOS wurde Unternehmenswissen von Agenturwissen, Produktwissen, Datenverträgen und technischem Code getrennt. Registries verbinden diese Bereiche über stabile Identitäten und Verweise. Die frühen Architekturentscheidungen sehen vor, dass eine Information genau einen verbindlichen Hauptort besitzt. Registries sollen diesen Ort auffindbar machen und seine Inhalte nicht vollständig duplizieren.

Für eine Websiteänderung bedeutet das: Die fachliche Aussage stammt aus dem zuständigen Geschäfts- oder Produktbereich. Die Gestaltung folgt dem Designsystem. Die technische Implementierung liegt in der registrierten Codebase. Der konkrete Auftrag beschreibt die gewünschte Änderung. Damit werden Verantwortungen getrennt, während der Prozess auf mehrere Quellen zugreifen darf.

Am 6. August 2026 wurde die vollständige physische Konsolidierung freigegeben. Zuvor hatte das Zielmodell zunächst die logische Ordnung betont. Der Fall verdeutlicht einen möglichen Aufbauweg: fachliche Zuständigkeiten festlegen, Quellen zuordnen und erst danach Bestände kontrolliert verschieben. Der Aufwand einer Migration lässt sich so an einer begründeten Zielstruktur ausrichten.

03

Agentenrollen und Betriebsfähigkeit getrennt betrachten

Die Agentenregistry von sem. enthielt am 8. Oktober 2026 insgesamt 29 Rollen: 21 Konzepte, fünf Piloten und drei vorläufig aktive Rollen. Diese Zahlen beschreiben Definitionen und grobe Reifegrade. Sie sind kein Nachweis für 29 produktiv arbeitende Agenten. Für die Planung ist diese Unterscheidung hilfreich, weil sie vorhandene Ideen von nachgewiesenen Fähigkeiten trennt.

Zentrale Rollendefinitionen können wiederverwendbare Aufgaben und Grenzen beschreiben. Fachwissen und lokale Freigaben bleiben beim zuständigen Geschäftsbereich. Daraus muss jedoch nicht für jede Verantwortung eine eigene laufende KI-Instanz entstehen. Koordination, Ausführung und Prüfung sind fachliche Funktionen; ihre technische Aufteilung sollte zum gewählten Prozess und seinem Risiko passen.

Vor einer zusätzlichen Rolle lohnt sich die Frage, welchen konkreten Engpass sie behebt. Eine unabhängige Ergebnisprüfung kann sinnvoll sein. Eine weitere Instanz, die nur bekannte Statusfelder weiterreicht, könnte durch feste Software ersetzt werden. Ob die Trennung trägt, zeigt sich an geprüften Ergebnissen, Bearbeitungszeit und verbleibendem Bedienaufwand.

04

Lösungsansatz: einen vollständigen Ablauf begrenzt aufbauen

Für den ersten Umfang empfiehlt sich ein klar eingegrenzter Aufgabentyp mit erkennbarem Ergebnis. Die Planung benennt seine Quellen, benötigten Zugänge, erlaubten Änderungen und Prüfschritte. Zusätzliche Rollen oder Integrationen kommen hinzu, wenn der Ablauf sie tatsächlich benötigt. So erhält jede Komponente eine überprüfbare Aufgabe.

Ein gemeinsamer Steckbrief pro Prozess kann Ziel, Eingang, verantwortlichen Arbeitsstand und Abschlusskriterium festhalten. Ergänzend wird dokumentiert, welche Information verbindlich ist und wer sie pflegt. Die Architektur bleibt dadurch anschlussfähig für weitere Prozesse, ohne deren vollständige Umsetzung bereits vorauszusetzen.

• Ein Ergebnis definieren, das im Zielsystem oder als nutzbares Artefakt geprüft werden kann.
• Verbindliche Fachquellen und technische Implementierung eindeutig zuordnen.
• Für jede Übergabe Quelle, erwartetes Ergebnis und zuständige Instanz benennen.
• Für wiederholte Eingänge, geänderte Aufträge und Abbrüche einen Fortsetzungsweg vorsehen.
• Neue Agentenrollen mit einer konkreten Fähigkeit und ihrem zusätzlichen Aufwand begründen.

05

Woran sich eine tragfähige Planung erkennen lässt

Ein geeigneter Praxistest führt einen Beispielauftrag durch den vollständigen Ablauf. Dabei sollte erkennbar sein, welche Quelle eine Entscheidung begründet, welche Änderung erlaubt ist und wie das Ergebnis bestätigt wird. Unklare Zuständigkeiten werden so früh sichtbar. Ein technisch erfolgreicher Einzelaufruf reicht als Abnahme eines gesamten Prozesses nicht aus.

Diese Betrachtung ermöglicht eine schrittweise Erweiterung. Die Wissensstruktur kann bereits mehrere Geschäftsbereiche enthalten, während der ausführbare Umfang zunächst klein bleibt. Für Unternehmen mit begrenzter Kapazität ist das ein praktikabler Weg, Grundlagen aufzubauen und den Betriebsnutzen parallel zu prüfen. Der nächste Beitrag untersucht, wie sich ein wachsender Wissensbestand dabei gezielt erschließen lässt.