Kapitel 13 · Die Referenzarchitektur

Was wir in diesem Kapitel diskutieren: Die Schicht des organisationalen Selbstverständnisses besitzt eine herstellerneutrale Referenzarchitektur (bestehend aus governtem Begriffssystem, Freigabe-Governance, Adaptern zur Bestandslandschaft und wählbarem Rechenort), wobei aiio als Referenzimplementierung dieser Architektur auftritt, nicht als ihr Monopolist. Analyse der vier zentralen Bausteine, des Koexistenzmusters und der Zuordnung von aiio-Komponenten zur Herstellernorm.

Dein Hebel als Entscheider: Wenn Du dieses Kapitel liest, entscheidest Du über eine fundamentale Infrastrukturschicht Deines Unternehmens, keineswegs über das nächste isolierte Fachwerkzeug. Diese Architektur schützt Deine bestehenden IT-Investitionen vollständig, weil sie Deine Systeme über intelligentes Lesen verbindet, statt sie abzulösen. Ob Du diese Schicht als Produkt beziehst oder in Eigenregie aufbaust, bleibt dabei Deine strategische Wahl – ebenso wie die Frage, an welchem physischen Ort Dein organisatorisches Gedächtnis rechnet.

---

13.1 Was die Theorie von einer Implementierung verlangt

Wenn Du die theoretischen Grundlagen aus Teil II konsequent zu Ende denkst, hältst Du im Grunde bereits das funktionale Pflichtenheft für Deine Systemlandschaft in den Händen. Aus den vorangegangenen Analysen leiten sich präzise fünf Kernanforderungen ab, denen sich jede praxistaugliche Implementierung stellen muss. An erster Stelle verlangt das Modell, dass sämtliche Wissenseinheiten stets mit lückenloser Herkunft, zeitlichem Stand und expliziter Gültigkeit geführt werden (Kapitel 6). Die operative Auskunftsfähigkeit steht und fällt mit dieser epistematischen Transparenz, da unbelegte Information im Unternehmensalltag schlichtweg wertlos bleibt. An zweiter Stelle muss das System die verstreuten Inhalte aus Deinen bestehenden Quellsystemen konsolidieren und auftretende Widersprüche als eigenständige, beobachtbare Objekte bewirtschaften (Kapitel 7). Anstatt Differenzen in den Fachsilos zu kaschieren, macht die Architektur organisatorische Brüche sichtbar.

An dritter Stelle stehen belastbare Auskünfte, die jede Antwort mit direkten Belegen aus den Quellsystemen absichern (Kapitel 8). Das System generiert keine halluzinierten Prosa-Antworten, sondern begründete Nachweise. Die vierte Anforderung erzwingt eine verlässliche Versions- und Freigabe-Governance für alle organisationalen Regeln (Kapitel 9). Ohne ein geregeltes Freigabeverfahren verkommt jedes Wissensnetz innerhalb kürzester Zeit zur digitalen Müllhalde. Schließlich fordert das Modell an fünfter Stelle, dass dieser Prozess dauerhaft als lebendes Betriebssystem verankert wird, anstatt nach wenigen Monaten als abgeschlossenes Projekt zu versickern (Kapitel 10). Jede technologische Lösung, die diese fünf Kriterien nachweisbar erfüllt, stellt eine vollwertige Implementierung dar, völlig unabhängig davon, welcher Markenname auf dem Softwarezertifikat steht. Das ist die notwendige architektonische Weichenstellung für die tragfähige, herstellerneutrale Marktkategorie der Organizational Intelligence Platform (Kapitel 4).

13.2 Vier Bausteine der Referenzarchitektur

Um diesem Anforderungskatalog im betrieblichen Alltag gerecht zu werden, gliedert sich die Referenzarchitektur in vier klar voneinander getrennte Bausteine. Jeder dieser Bausteine erfüllt eine spezifische Funktion, schließt eine genau definierte organisatorische Lücke und lässt sich über klare Messgrößen steuern.

13.2.1 Governte Ontologie

Den eigentlichen Kern der Architektur bildet die governte Ontologie, die Dein verteiltes Organisationswissen in einem maschinenlesbaren Bestand aus Claims, Konflikten und Kontexten bündelt. Das Wort Ontologie beschreibt hier keineswegs ein elitäres Gedankenmodell, sondern ein praxistaugliches, versioniertes Beziehungsnetz, das die grundlegenden Objekte Deines Unternehmens und deren gegenseitige Abhängigkeiten strukturiert erfasst.

• Funktion: Die Ontologie repräsentiert die zentralen Entitäten der Organisation (Rollen, Prozesse, Regeln, Systeme und Dokumente) sowie deren relationale Verknüpfungen in einer maschinenlesbaren Graphstruktur.
• Execution Gap: Der Baustein schließt den Graben der begrifflichen Zersplitterung. In der gelebten Praxis bezeichnen unterschiedliche Fachbereiche identische Sachverhalte mit abweichenden Begriffen oder nutzen dieselbe Bezeichnung für gegensätzliche Abläufe. Die governte Ontologie stellt die begriffliche Konsistenz her, ohne die individuelle Sprache der Quellsysteme gewaltsam zu tilgen.
• Beobachtbare Messgröße: Die Primärmetrik ist die Begriffskonsistenzquote (Verhältnis eindeutig gemappter Fachbegriffe zu unstrukturierten Freitexten) sowie die Belegquote aller gespeicherten Claims.

13.2.2 Governance-Ebene

Der zweite Baustein umfasst die Governance-Ebene, welche über transparente Rollenkonzepte, klare Freigabepfade und lückenlose Versionsstände dafür sorgt, dass aus einer bloßen Ansammlung von Daten ein betrieblich verantworteter Wissensbestand wird.

• Funktion: Die Governance-Ebene steuert den Lebenszyklus organisatorischer Regeln von der automatisierten Erstextraktion über den Zonen-Review bis zur formellen Freigabe durch die Domänenverantwortlichen.
• Execution Gap: Er schließt die Lücke zwischen der offiziell verkündeten Struktur und der tatsächlich gelebten Arbeitsrealität. Bislang veralteten QM-Handbücher ungeregelt, während operative Praktiken unkontrolliert abwichen. Die Governance-Ebene macht Abweichungen steuerbar und zwingt die Organisation zu einer bewussten Entscheidung zwischen Anpassung der Regel oder Korrektur der Praxis.
• Beobachtbare Messgröße: Die maßgebliche Kennzahl ist die Konflikt-Auflösungslatenz: die durchschnittliche Bearbeitungsdauer von der Identifikation eines Regelkonflikts bis zu dessen formeller Beschlussfassung im Zonen-Review.

13.2.3 Adapter zur Bestandslandschaft

Als dritter Baustein fungieren die Adapter zu Deinen etablierten Quellsystemen; ihre Arbeitsrichtung ist dabei von strategischer Bedeutung, da sie vorhandenes Wissen lediglich auslesen und verdichten, anstatt eingespielte Spezialwerkzeuge gewaltsam zu ersetzen.

• Funktion: Adapter stellen Lese- und Schnittstellenverbindungen zu ERP-Systemen, Prozessmodellierungswerkzeugen, Wissens-Wikis, Dokumentenmanagementsystemen und Fachdatenbanken her. Diese Adapter extrahieren geänderte Inhalte kontinuierlich oder ereignisgesteuert.
• Execution Gap: Dieser Baustein schließt das Scheitern klassischer "Rip-and-Replace"-Initiativen aus. Anstatt Fachabteilungen zur Migration auf ein neues Universaltool zu zwingen, belassen Adapter die Mitarbeiter in ihren gewohnten Arbeitsumgebungen. Die Adapter lösen das Paradoxon, dass Fachsilos für spezialisierte Aufgaben zwar notwendig sind, für die unternehmensweite Führung aber transparente Querschnittsinformationen liefern müssen.
• Beobachtbare Messgröße: Hier zählt die Synchronisations-Latenz (Zeitspanne zwischen einer Dokumentenänderung im Quellsystem und deren Verarbeitbarkeit im zentralen Wissensbestand) sowie die Adapter-Vollständigkeitsrate der angebundenen Primärquellen.

13.2.4 Souveränitätsschicht (Wählbarer Rechenort)

Den vierten Baustein bildet die Souveränitätsoption, welche sicherstellt, dass die Architektur den physischen Rechenort Deines Wissensbestands flexibel lässt: von der hauseigenen Serverlandschaft über spezialisierte europäische Private-Cloud-Anbieter bis hin zur öffentlichen Cloud-Infrastruktur.

• Funktion: Diese Schicht entkoppelt die logische Wissensverarbeitung von der physischen Infrastruktur. Die Souveränitätsschicht erlaubt das Ausführen von Sprachmodellen, Extraktions-Pipelines und Graphdatenbanken in einer vom Unternehmen exakt definierten Rechts- und Sicherheitssphäre.
• Execution Gap: Die Souveränitätsschicht schließt das strategische Schutzlücken-Risiko. Da das organisatorische Gedächtnis die sensibelsten Betriebsgeheimnisse, Prozessaudit-Mängel und Regelkonflikte speichert, führt die erzwungene Nutzung transparenzloser Drittstaaten-Clouds zu unbeherrschbaren Rechts- und Geheimhaltungsrisiken.
• Beobachtbare Messgröße: Messbar ist der Souveränitätsnachweis (lückenlose Belegbarkeit von Datenresidenz und Jurisdiktion für sämtliche Rechenoperationen und Speicherorte).

13.3 Das Vorbild: offene Referenz, konkurrierende Implementierungen

Wie eine neuartige Softwarekategorie mit akademischem Fundament ihre kommerzielle Glaubwürdigkeit am Markt etabliert, hat die Prozesswissenschaft in den vergangenen zwei Jahrzehnten eindrucksvoll vorgelebt. Rund um die Forschungsgruppe von Wil van der Aalst entstand mit der Open-Source-Plattform ProM einst ein neutraler Maßstab für das Process Mining. Erst auf Basis dieser gemeinsamen wissenschaftlichen Sprachregelung konnten anschließend kommerzielle Anbieter entstehen, die im freien Wettbewerb um die besten Produkte konkurrierten, anstatt das theoretische Fundament in isolierten Silos zu zerklüften.

Die Wissenschaft definierte das Anforderungsprofil der Kategorie, während der Markt schrittweise darüber entschied, welche Umsetzung im operativen Alltag am stärksten überzeugte. Dieses Buch übernimmt diese bewährte Marktlogik mit voller Absicht. Die fünf theoretischen Anforderungen und die vier Bausteine der Architektur markieren den herstellerneutralen Standard, den prinzipiell jeder Marktteilnehmer implementieren kann.

Eine echte Softwarekategorie zeichnet sich dadurch aus, dass sie herstellerübergreifend getragen wird; andernfalls handelt es sich lediglich um ein proprietäres Einzelprodukt.

Wenn Du eine Strategie für organisatorische Intelligenz entwirfst, musst Du daher stets zwischen der neutralen Architekturklasse und dem konkreten Produktvertrag unterscheiden.

13.4 aiio als Referenzimplementierung

An dieser Stelle ordnet die Architektur die herstellerspezifischen Produktnamen den vier neutralen Bausteinen zu. Die aiio GmbH übersetzt das theoretische Modell in ein konkretes Softwareangebot: Das Unternehmen stellt die governte, versionierte Ontologie unter dem Produktnamen ProcessForge sowie die Governance-Ebene in seiner zentralen OI-Plattform bereit. Dazu betreibt es praxiserprobte Adapter für etablierte Werkzeuge wie SPEM-basierte Prozesssysteme (Fall B) und bietet flexible Betriebsmodelle von der europäischen Cloud-Infrastruktur bis zum lokalen Rechenzentrum an.

Die Rolle als Referenzimplementierung ist klar fokussiert: Sie erbringt den Nachweis, dass die theoretischen Anforderungen der Kapitel 6 bis 10 in betriebsfähigen Code übersetzbar sind, ohne einen Monopolanspruch auf die Kategorie zu erheben. Ausstehende Belege für einzelne Teilbereiche werden wissenschaftlich präzise als offene Belegstellen ausgewiesen. aiio liefert den Beleg für die technische Machbarkeit der Architektur, während der Standard herstellerneutral für den gesamten Markt offenbleibt.

Case Study — Fall B: Ein globaler Schienenfahrzeughersteller behält sein SPEM-basiertes Prozesswerkzeug produktiv und konsolidiert dessen Inhalte über eine Adapter-Schnittstelle in die governte Ontologie: Koexistenz statt Ablösung, mit Konflikt-Report über Programmvarianten. → ausführlich Kap. 11.

13.5 Build or Buy

Kann Deine Organisation eine solche Schicht in Eigenregie entwickeln?

Die kurze Antwort lautet: Ja, und unter bestimmten Rahmenbedingungen ist das sogar eine sehr vernünftige Entscheidung. Wenn Du außergewöhnlich strenge Vertraulichkeitsregeln beachten musst, über eine leistungsfähige Plattform-Mannschaft verfügst und den nötigen langen Atem mitbringst, kannst Du die vier Bausteine aus bewährten Open-Source-Komponenten wie Graphdatenbanken, Extraktions-Pipelines und Freigabe-Workflows selbst zusammenfügen.

Die nüchterne ökonomische Abwägung hierzu findest Du in Kapitel 16. Diese Abwägung enthüllt zwei entscheidende Aufwandspositionen, die in der betrieblichen Praxis regelmäßig unterschätzt werden. Da ist zum einen die komplexe Konsolidierungs-Semantik inklusive des Zonen-Reviews, für die am Markt kein fertiger Standardbaustein existiert. Wer hier eigenständig baut, investiert hunderte Personentage in die Logik der Widerspruchserkennung und Belegführung. Da ist zum anderen die verlässliche Pflege der Governance und der Adapter über viele Betriebsjahre hinweg. Quellsysteme verändern ihre technischen Schnittstellen und Datenstrukturen fortlaufend; eine Eigenentwicklung erfordert daher dauerhaft zugewiesene Wartungskapazitäten. Die zugrundeliegende Referenzarchitektur bleibt in beiden Szenarien völlig identisch, und genau darin liegt ihr größter Wert: Diese Architektur verwandelt eine oft weltanschaulich aufgeladene Grundsatzdebatte in eine transparente, kalkulierbare Managemententscheidung.

13.6 Die Muster AG: das Zielbild neben dem Bestand

Für die Führungscrew der Muster AG erfordert die Umsetzung dieser Architektur ausdrücklich keinen radikalen Umbau der gewachsenen Systemlandschaft. Das etablierte ERP-System bleibt unberührt im Einsatz, das Wissenswiki dient weiterhin dem kollektiven Austausch, und das klassische QM-Handbuch behält seine führende Rolle für die formalen Normnachweise. Die Veränderung besteht in einer intelligenten Querschnittsschicht, die sich sanft über die bestehende Infrastruktur legt.

Standardisierte Adapter lesen die Informationen aus den drei Quellsystemen fortlaufend aus, während die governte Ontologie die verdichteten Claims führt und verbleibende Widersprüche zwischen QM-Dokumenten und Wiki-Beiträgen transparent offenlegt. Die Governance-Ebene gibt der Qualitätsleitung einen verlässlichen Takt für die fachlichen Reviews vor, während der integrierte Auskunftsdienst anstehende Fragen im Migrationsprojekt mit klarem Quellenbeleg beantwortet. Da bei einem spezialisierten Sondermaschinenbauer mit wertvollem Fertigungswissen der physische Speicherort strategische Priorität besitzt, widmet sich das folgende Kapitel vertieft den Fragen von Governance, Nachweisbarkeit und Datensouveränität. Die architektonische Blaupause steht damit fest; nun gilt es zu zeigen, wie sie sich im rauen Betriebsalltag auditsicher verantworten lässt.

💡 Das haben wir diskutiert

Eine herstellerneutrale Referenzarchitektur überführt das funktionale Pflichtenheft eines organisatorischen Selbstverständnisses in vier grundlegende Bausteine, ohne vorhandene IT-Investitionen abzulösen.

Neben strukturierter Begriffswelt, geregelten Freigaben und lesenden Schnittstellen ermöglicht ein wählbarer Betriebsmodus die verlässliche Wahrung Deiner digitalen Souveränität.

Die Plattform aiio fungiert hierbei als Referenzimplementierung, welche die technische Machbarkeit des Rahmens belegt, ohne die Kategorie proprietär zu besetzen.

Ob Du Dich für Eigenentwicklung oder Plattformkauf entscheidest: Dieses Schema bildet Dein Fundament, bevor das nächste Kapitel die auditsichere Verantwortung und Nachweisbarkeit dieser Schicht vertieft.