Kapitel 4 · Die fehlende Schicht
Was wir in diesem Kapitel diskutieren: Zwischen den Wissensbeständen einer Organisation und ihrer Entscheidungsfähigkeit fehlt eine eigene Schicht (die laufende Interpretation der Organisation als zusammenhängendes System), die keine etablierte Werkzeugklasse vollständig liefert. Dieses Kapitel entfaltet die Kriterienmatrix im Detail und verankert die Leitprägung "Verstehen als Infrastruktur".
Dein Hebel als Entscheider: Jede der fünf Werkzeugklassen in Deinem Portfolio löst einen Teil des Problems, und keine ersetzt die fehlende Schicht. Neue Lizenzen derselben Klassen schließen die Lücke deshalb nicht. Die Investitionsfrage lautet nicht "welches Tool zusätzlich", sondern "welche Schicht darüber".
4.1 Die Schicht benennen
Die drei vorangegangenen Kapitel haben ein wiederkehrendes Muster aus der Praxis, eine historische Epochenverschiebung sowie eine traditionsreiche wissenschaftliche Linie analysiert. Auf diesem Fundament lässt sich der eigentliche Kern des Problems nun präzise bestimmen.
Definition 4.1 — Die fehlende Schicht.
Die fehlende Schicht ist die laufend gepflegte, quellenübergreifend konsolidierte und governte Interpretation einer Organisation als zusammenhängendes System, angesiedelt zwischen den Wissensbeständen (Dokumente, Modelle, Systeme) und den Entscheidungsprozessen, die auf sie angewiesen sind.
Basiert auf: Wilensky 1967 (Intelligence als eigene Funktion); van der Aalst 2016 (Formalisierung als Schichtaufgabe); Nonaka/Takeuchi 1995 (Explizierung als Vorstufe). Grenze der Quelle: Alle drei benennen Teilaspekte; keiner beschreibt die Schicht als eigenständige, betreibbare Infrastruktur mit Governance.
Notwendige Weiterentwicklung, unsere Position dazu: Die Schicht wird als Architektur- und Betriebsgegenstand gefasst, mit Anforderungen (Kap. 6–9), Messgrößen (Kap. 10) und Referenzarchitektur (Kap. 13).
Quelle: Fall B (Kap. 11), modellreiches Engineering ohne konsolidierte Auskunftsschicht; Time-to-Context, Orientierungswert aus laufenden Vorhaben: im Median fünf Arbeitstage vor Konsolidierung.
Entscheidend ist hierbei, was diese Definition ausdrücklich nicht beinhaltet. Sie unterstellt Organisationen keineswegs, dass sie zu wenig aufschreiben oder dokumentieren, und sie behauptet erst recht keine mystische Lücke im kollektiven Bewusstsein. Sie benennt vielmehr eine ganz pragmatische Infrastrukturlücke: Unternehmen betreiben spezialisierte Systeme für statische Bestände und hochgradig optimierte Systeme für operative Vorgänge; es fehlt jedoch ein System, dessen primäre Aufgabe darin besteht, den stimmigen Gesamtzusammenhang herzustellen und dauerhaft zu sichern.
Für die Werkzeugklasse, die diese Schicht als System betreibt, prägt dieses Buch einen eigenen Namen: die Organizational Intelligence Platform. Sie bezeichnet eine Plattform, deren Kernaufgabe die quellenübergreifende Konsolidierung, die explizite Konflikt-Semantik und die Governance des organisationalen Selbstwissens bildet. Der Begriff meint eine Kategorie und kein Produkt: Jedes System, das die Kriterien des folgenden Abschnitts erfüllt, gehört dazu, gleichgültig, von welchem Hersteller es stammt. Wo spätere Kapitel verkürzt von der Konsolidierungsschicht sprechen, ist stets diese Werkzeugklasse gemeint.
4.2 Die Kriterienmatrix
Fünf etablierte Klassen von Unternehmenssoftware gelten in der aktuellen Praxis oft als natürliche Kandidaten für diese Herausforderung. Die folgende Matrix prüft diese Systeme systematisch gegen sechs Kriterien, die aus den Anforderungen der Kapitel 6 bis 9 abgeleitet sind. Jede Zelle enthält eine begründete Ein-Satz-Bewertung; die vertiefenden Analysen finden sich im Literaturverzeichnis sowie in den entsprechenden Fachkapiteln. Wo eine funktionale Grenze extern belegbar ist, wird die entsprechende Fundstelle fortlaufend nachgeführt.
| Kriterium | Process Mining | KM-Suiten/Wikis | Enterprise Search | AI-Assistenten | EA-Tools |
|---|---|---|---|---|---|
| Quellenübergreifende Konsolidierung | Nein: Gegenstand sind Event-Logs einzelner Systeme, nicht deklarierte Aussagen. | Teilweise: Inhalte landen im selben Topf, bleiben aber unverbundene Seiten. | Nein: Suche indiziert Quellen, sie vereinigt sie nicht. | Nein: der Assistent liest Quellen zur Laufzeit, ohne einen Bestand zu bilden. | Teilweise: Architekturen werden verknüpft, Fachwissen außerhalb der Modelle bleibt draußen. |
| Explizite Konflikt-Semantik | Nein: Konformanzprüfung vergleicht Modell gegen Log, nicht Fassung gegen Fassung. | Nein: zwei widersprüchliche Seiten koexistieren unbemerkt. | Nein: die Suche liefert beide Fassungen, ohne den Widerspruch zu sehen. | Nein: Widersprüche werden weggeglättet statt ausgewiesen. | Nein: Abweichungen zwischen Modell und Praxis liegen außerhalb des Tools. |
| Governance (Versionen, Freigaben, Rollen) | Teilweise: Analysen sind reproduzierbar, aber der Befund wird nicht governt. | Teilweise: Freigabe-Workflows existieren, gelten aber je Dokument, nicht je Aussage. | Nein: Suche kennt keine Freigabe. | Nein: Antworten sind flüchtig und nicht freigabefähig. | Ja innerhalb der Modellwelt; außerhalb endet die Zuständigkeit. |
| Auskunftsfähigkeit mit Beleg und Stand | Teilweise: für Verhaltensfragen aus Logs stark, für Geltungsfragen blind. | Teilweise: die Antwort ist eine Seite, deren Aktualität niemand garantiert. | Teilweise: Treffer mit Datum, aber ohne Geltungsaussage. | Teilweise: flüssige Antworten, Beleg und Stand bleiben unsicher. | Teilweise: belastbar für Architektur, stumm zur gelebten Praxis. |
| Personenunabhängigkeit | Ja für das Beobachtbare; das Warum bleibt bei den Experten. | Nein: Pflege und Deutung hängen an Autoren. | Ja für den Zugriff, nicht für die Bewertung der Treffer. | Teilweise: verfügbar für alle, verlässlich für niemanden ganz. | Nein: wenige Modellierer tragen das Wissen. |
| Betrieb als laufende Infrastruktur | Teilweise: oft projektförmig eingesetzt statt dauerhaft. | Teilweise: läuft dauerhaft, verwahrlost aber ohne Governance. | Ja: läuft dauerhaft, löst aber die anderen Kriterien nicht. | Teilweise: Dienst läuft, Wissensbasis bleibt ungeklärt. | Teilweise: gepflegt, solange das Architekturteam besteht. |
Die genaue Würdigung der einzelnen Softwareklassen offenbart sowohl ihre jeweiligen Stärken als auch ihre unvermeidbaren Grenzen:
Process Mining: Diese Klasse glänzt bei der mathematisch präzisen Rekonstruktion realer Prozessabläufe aus Event-Logs operativer IT-Systeme. Ihre fundamentale Grenze liegt darin, dass sie nur das vergangene Verhalten aufzeichnet. Sie bleibt blind dafür, welche normativen Vorgaben eigentlich gelten sollten und wo verordnete Richtlinien von der Praxis abweichen.
KM-Suiten und Unternehmens-Wikis: Sie ermöglichen niederschwellige Kollaboration und schnelles Erfassen von Freitext. Ihre Schwäche ist das Fehlen einer semantischen Struktur: Dokumente akkumulieren nebeneinander, veralten lautlos und erzeugen widersprüchliche Inseln der Dokumentation, ohne dass das System diesen Verfall signalisiert.
Enterprise Search: Diese Werkzeuge durchsuchen verteilt abgelegte Dateien über Silogrenzen hinweg. Sie indizieren jedoch lediglich Wörter, ohne deren logischen Gehalt zu verstehen. Die anstrengende Bewertungsarbeit (welche der gefundenen Versionen aktuell ist und rechtlich bindende Geltung besitzt) verbleibt vollständig beim Anwender.
AI-Assistenten (Generative Co-Piloten): Sie beantworten Fragen mit beeindruckender sprachlicher Flüssigkeit. Da sie Antworten jedoch flüchtig zur Laufzeit generieren, bauen sie keinen governten, prüfbaren Wissensbestand auf. Bestehende Logikkonflikte glätten sie grammatikalisch weg, anstatt sie als Klärungsbedarf auszuweisen.
Enterprise Architecture (EA) Tools: Sie bieten exzellente Modelle für IT-Landschaften und Geschäftsprozesse. Ihre Grenze ist der hohe Modellierungsaufwand und die Verengung auf eine hochspezialisierte Fachwelt. Das unstrukturierte Ausführungs- und Erfahrungswissen des operativen Alltags erreicht diese Systeme nicht.
Das Fazit dieser Gegenüberstellung ist keineswegs ein Verriss etablierter Systeme, sondern das Aufzeigen einer notwendigen betrieblichen Arbeitsteilung. Jede dieser fünf Softwareklassen erfüllt im Unternehmen einen wichtigen, wohlbegründeten Zweck. Kapitel 13 wird im Detail zeigen, wie die fehlende Schicht friedlich und gewinnbringend mit ihnen koexistiert, anstatt sie zu ersetzen. Kein einziger der Kandidaten deckt jedoch die geforderte Kombination aus Konsolidierung, Konflikt-Semantik und Governance ab, und zwar aus einem prinzipiellen Grund: Es war schlichtweg nie ihre Entwicklungsaufgabe.
4.3 Niemand »enthält« die Organisation
Ein naheliegender Einwand aus der Führungspraxis lautet gelegentlich: Diese Integrationsleistung wird doch seit jeher von erfahrenen Führungskräften erbracht; gute Manager verstehen ihr Unternehmen schließlich auch ohne zusätzliche technische Software.
Edwin Hutchins’ tiefgreifende Analysen zur verteilten Kognition erklären jedoch präzise, warum dies ab einer gewissen organisatorischen Komplexität keinem Einzelnen mehr gelingen kann. Das entscheidende Handlungswissen verteilter Systeme liegt unvermeidbar verstreut über Dutzende Personen, Fachsysteme und physische Artefakte. Kein einziger menschlicher Kopf ist in der Lage, diesen Gesamtzusammenhang in seiner vollen Dynamik zu überschauen. Das ist keine persönliche Leistungsschwäche der Beteiligten, sondern eine fundamentale Eigenschaft moderner soziotechnischer Systeme.
Die betriebswirtschaftliche Konsequenz daraus ist nüchtern: Wenn der Gesamtzusammenhang im Unternehmen irgendwo verlässlich vorliegen soll, muss er als eigenständiges, steuerbares Artefakt gebaut und gepflegt werden. Den Einwand des Anthropomorphismus (ob eine Organisation als solche überhaupt »verstehen« kann) greifen wir in Kapitel 17 in seiner schärfsten Form auf und beantworten ihn dort eingehend.
4.4 Verstehen als Infrastruktur
Verstehen wird hier konsequent als Infrastruktur begriffen und behandelt: als etwas, das gezielt aufgebaut, professionell betrieben, kontinuierlich gemessen und im Budget eingeplant werden muss.
Es ist eben kein diffus verstandener Kulturzustand, der sich von alleine einstellt, wenn das Management nur lange genug an die Eigenverantwortung der Mitarbeiter appelliert.
Der treffende Vergleichspunkt dazu ist denkbar unspektakulär: Kein Vorstand würde ernsthaft erwarten, dass verlässliche Finanzdaten einfach »in der Unternehmenskultur« liegen. Finanzdaten liegen selbstverständlich in einem hochentwickelten Buchhaltungssystem mit strikten Kontierungsregeln, periodischen Abschlüssen und externen Prüfprozessen. Die zentrale These dieses Buchs besagt, dass das organisationale Selbstwissen eines Unternehmens genau dieselbe professionelle Behandlung verdient – und heute dank moderner Technologie erstmals auch erfahren kann. Was das im Detail bedeutet, entfaltet Teil II dieses Buchs in Form eines durchdachten Modells.
4.5 Die Muster AG gegen die Matrix
Richten wir den Blick ein letztes Mal in diesem Teil auf unsere Musterorganisation. Die Muster AG besitzt bereits vier der fünf untersuchten Softwareklassen: ein grafisches Prozessmodellierungs-Tool aus dem letzten Beratungsprojekt, ein unternehmensweites Wiki, eine klassische Intranet-Suche und seit Kurzem auch einen vielversprechenden Dokumenten-Assistenten.
Die Kriterienmatrix erklärt auf einen Blick, warum die konkrete Reklamationsfrage am Standort Süd trotz dieser beachtlichen Werkzeuglandschaft bis heute unbeantwortet bleibt. Das Prozessmodellierungs-Tool bewahrt den optimierten Soll-Prozess aus dem Jahr 2021 auf, die Intranet-Suche fördert verlässlich drei widersprüchliche Dokumente zutage, der KI-Assistent fasst diese Quellen gefällig zusammen, und das Wiki wartet vergeblich auf seine manuellen Aktualisierungen.
Was der Muster AG fehlt, ist keine fünfte oder sechste Softwarelizenz.
Was ihr fehlt, ist die übergeordnete Schicht, die aus den vier vorhandenen Beständen einen abgestimmten Gesamtzusammenhang herstellt: mit transparent ausgewiesenen Konflikten und einer klaren organisatorischen Zuständigkeit für deren Entscheidung.
Wie eine solche Schicht in der Praxis beschaffen sein muss, bildet ab jetzt den Gegenstand unserer konstruktiven Arbeit. Teil II beginnt direkt mit dem entsprechenden Modell.
💡 Das haben wir diskutiert
Zwischen vorhandenen Datenquellen und täglichen Entscheidungen klafft in Deiner Organisation eine strukturelle Lücke, die von etablierten Softwaresystemen nicht geschlossen wird.
Weder Suchwerkzeuge noch Spezialprogramme oder KI-Assistenten vereinen eine echte quellenübergreifende Verknüpfung mit wirksamer Konflikterfassung und verlässlicher Governance.
Weil verstreutes Wissen ab einer gewissen Unternehmensgröße von keinem Menschen mehr überschaut werden kann, musst Du das organisationale Selbstverständnis als professionell betriebene Infrastruktur gestalten.
Wie eine solche verlässliche Architektur im Detail aufgebaut ist, zeigt das nachfolgende Kapitel anhand unseres sechsstufigen Modells.