Kapitel 17 · Die Einwände
Was wir in diesem Kapitel diskutieren: Diese Theorie gewinnt ihre intellektuelle Glaubwürdigkeit aus den Einwänden, die sie aushält. Sechs gewichtige Gegenpositionen in ihrer stärksten Form, die jeweilige Antwort dieser Architektur und die ausdrücklich offen bleibenden Restfragen stellen die Kategorie auf den Prüfstand.
Dein Hebel als Entscheider: Nutze dieses Kapitel als neutrale Einkaufshilfe: Jeden Anbieter dieser neuen Kategorie (aiio ausdrücklich eingeschlossen) solltest Du an diesen sechs Einwänden messen. Wer keinen davon gelten lässt, verkauft ein Marketingetikett; verbleibende Restfragen zeigen methodische Sorgfalt.
Ein wichtiger Hinweis zur Dramaturgie dieses Kapitels: Wir formulieren jeden Einwand so scharf und fundiert, wie ihn sein klügster Kritiker in einer Vorstands- oder Aufsichtsratsdebatte vortragen würde, fernab bequemer Strohmann-Argumente. Darauf folgt die systematische Antwort dieser Theorie, bevor wir präzise benennen, was derzeit noch unbeantwortet bleibt. Wenn Du in Deiner Führungspraxis vor Investitionsentscheidungen in dieser Kategorie stehst, liefert Dir dieses Kapitel das Werkzeug für die kritische Prüfung. Einige der verbleibenden Restfragen münden als offene Forschungsfragen direkt in Kapitel 18.
17.1 "Das ist Knowledge Management in neuem Gewand"
Die starke Form: Wenn Du in einer Vorstands- oder Aufsichtsratssitzung das Konzept einer zentralen Konsolidierungsschicht für organisatorisches Selbstwissen auf den Tisch legst, lässt das Urteil des erfahrensten Mitglieds selten lange auf sich warten: "Wir haben das Ende der Neunzigerjahre alle schon einmal erlebt: Wissensmanagement-Datenbanken, Wissens-Silos auflösen, Lotus Notes, SharePoint, Gelbe Seiten. Am Ende wurden Milliarden an Beratungs- und Softwarekapital verbrannt, niemanden hat die Pflege im operativen Alltag interessiert, und nach zwei Jahren lagen die Systeme verwaist brach." Dieser Einwand kommt nicht aus Trägheit, sondern aus bitterer Erfahrung. Selbst ein herausragender Theoretiker der Wissensorganisation wie Ikujiro Nonaka würde berechtigt fragen, warum die kognitive Externalisierung von implizitem zu explizitem Wissen diesmal gelingen sollte, wenn sie doch erneut an menschlicher Disziplin hängt und nicht an der Architektur.
Die Antwort: Dieser Einwand trifft die traditionelle Dokumentations-Epoche ins Mark – und zwar völlig zu Recht. Diese Theorie unterscheidet sich jedoch an genau den zwei neuralgischen Punkten, an denen das klassische Wissensmanagement gescheitert ist. Erstens war die kontinuierliche Datenpflege damals mühsame Handarbeit gegen den operativen Alltag: Mitarbeiter sollten nach Feierabend Formulare ausfüllen, ohne direkten Nutzen für ihre eigene Arbeit. In unserer Architektur übernehmen automatische Extraktion und Abgleich den Löwenanteil des Aufwands, sodass menschliche Entscheider nur noch bei echten Konflikten und Abweichungen eingreifen müssen (Kapitel 7 und 8). Zweitens fehlte den alten Systemen ein klarer Wahrheitsbegriff für den Wissensbestand; jede Information galt gleich viel, wodurch Dokumentenfriedhöfe entstanden und am Ende alles wertlos wurde. Erst eine präzise Konflikt-Semantik mit expliziten Freigaben und operativen Geltungsansprüchen schafft die erforderliche strukturelle Differenz.
Offen bleibt: Ob diese deklarierte Pflege über viele Jahre trägt, wenn die anfängliche Transformationsenergie verbraucht ist, kann heute noch niemand seriös belegen. Das bleibt eine empirische Kernfrage an laufende Kundenprojekte.
17.2 "Process Mining leistet das bereits"
Die starke Form: In der CFO- und CIO-Runde wird sofort der Verweis auf etablierte datengetriebene Werkzeuge fallen: "Mit Process Mining haben wir bereits ein hochgradig messendes, unbestechliches Verfahren im Einsatz. Wenn wir wissen wollen, wie unsere Prozesse ablaufen, ziehen wir die Event-Logs aus SAP, Salesforce oder ServiceNow. Was kümmert uns, was in geduldigen Dokumenten oder Qualitäts-Handbüchern steht? Die unbestechliche Wahrheit liegt in den transaktionalen Ereignisdaten, nicht in theoretischen Soll-Deklarationen." Dieser Einwand stützt sich auf die fundamentale Arbeit von Wil van der Aalst und der gesamten Process-Mining-Community. Warum also noch eine Schicht für deklariertes Selbstwissen aufbauen?
Die Antwort: Wir stimmen diesem Befund im Kern vollkommen zu, präzisieren jedoch den Anwendungsumfang. Event-Logs bilden menschliches und systemisches Verhalten exzellent ab: Sie zeigen unbestechlich, was geschehen ist und wie lange es gedauert hat. Doch drei fundamentale Klassen organisationalen Selbstwissens tauchen in keinem Log-File der Welt auf: erstens die normative Geltung (welche Regel soll gelten), zweitens die Zuständigkeit (wer darf eine Abweichung freigeben oder entscheiden) und drittens die Begründung (aus welchem strategischen oder regulatorischen Grund verfahren wir so). Die in diesem Buch analysierte Reklamationsfrage der Muster AG (Kapitel 11) scheitert in der Praxis keineswegs an fehlenden Prozess-Logs im ERP, sondern an drei widersprüchlichen Soll-Deklarationen in unterschiedlichen Dokumenten. Process Mining und Organizational Intelligence stehen daher in keiner Konkurrenz; sie sind strikt komplementär. Kapitel 13 modelliert ihre Koexistenz explizit nach den Standards der Process-Mining-Community: Log-Daten liefern die Ist-Evidenz, während der Wissensbestand die Soll-Governance und Entscheidungskontexte bereitstellt.
Offen bleibt: Die nahtlose operative Verbindung beider Welten, bei der beobachtetes Log-Verhalten als automatische Evidenz gegen deklarierte Claims geführt wird, ist zwar konzeptionell skizziert, aber noch nicht flächendeckend produktiv erprobt.
17.3 "Organisationen verstehen nicht – das ist Anthropomorphismus"
Die starke Form: In akademischen Beiräten oder grundlegenden Strategiedebatten wird der Begriff selbst angegriffen: "Ihr sprecht von 'organisationalem Selbstverständnis' und behauptet, dass Organisationen etwas 'verstehen' oder 'wissen'. Das ist billiger Anthropomorphismus. Echtes Verstehen setzt ein individuelles Bewusstsein, Nervenzellen und kognitive Subjektivität voraus. Eine Organisation ist ein soziales System, kein biologischer Organismus. Wer korporativen Akteuren kognitive Fähigkeiten zuschreibt, verkauft eine literarische Metapher als wissenschaftliche Theorie." Bereits James G. March und die klassische Organisationsforschung haben solche Begriffsübertragungen als gefährlichen Kategorienfehler entlarvt.
Die Antwort: Dieser Einwand ist vollkommen berechtigt, und diese Theorie akzeptiert seine grundlegende Prämisse ohne jeden Vorbehalt. An keiner Stelle dieses Buchs wird einer Organisation ein internes Seelenleben, ein Bewusstsein oder mystisches Erleben angedichtet. Der Begriff "Verstehen" wird hier durchgängig operational und funktional definiert: als messbare Auskunfts- und Entscheidungsqualität innerhalb eines soziotechnischen Gesamtsystems (Definitionen 5.2, 5.3 und 8.1). Edwin Hutchins hat mit seiner Theorie der Distributed Cognition das tragfähige Fundament geliefert: Kognitive Prozesse können effektiv über Menschen, Artefakte, Dokumente und technische Werkzeuge verteilt sein, ohne dass an irgendeiner Stelle ein zentrales Bewusstsein entsteht. Ein modernes Flugzeugcockpit "weiß" seine Flughöhe und Anflugroute in genau diesem verteilten, relationalen Sinne, nicht weil die Instrumente oder die Piloten für sich allein das Gesamtsystem bilden, sondern weil das Zusammenspiel unvollständiger Komponenten fehlerfreie Handlungen ermöglicht. Wenn Du Dich an der Metapher störst, kannst Du jedes "Verstehen" in diesem Buch mühelos durch "belegbare relationale Auskunftsfähigkeit" ersetzen; die Argumentation und der operative Nutzen bleiben dadurch vollumfänglich intakt.
Offen bleibt: An dieser Stelle bleibt theoretisch wenig offen, da der Einwand am Kern unserer Position vorbeigeht. Er behält dennoch seinen Platz im Kapitel, weil der Softwaremarkt die anthropomorphe Fassung tatsächlich gewinnbringend verkauft und gewissenhafte Entscheider sie kritisch prüfen müssen.
17.4 "Das nächste System, das alle anderen ersetzen will"
Die starke Form: Der Enterprise-Architekt und der Head of IT heben im Lenkungskreis warnend die Hand: "Wir haben bereits ein ERP-System für Finanz- und Materialflüsse, ein CRM für Kundenbeziehungen, ein ECM für Dokumente, Confluence für Wikis, SharePoint für Richtlinien und ein Service-Desk-Tool für Tickets. Jedes einzelne davon wurde uns einst als die 'Single Source of Truth' verkauft. Nun kommt die nächste Kategorie und verspricht eine Konsolidierungsschicht über allem. Warum sollte hier nicht genau das passieren, was immer passiert: erst eine millionenschwere, hochkomplexe Einführungsphase und danach ein neues, gigantisches Softwaresilo, das zusätzlichen Pflegeaufwand verursacht?"
Die Antwort: Dieser Einwand beschreibt ein extrem reales Fehlschlagmuster der IT-Geschichte. Unsere Architektur zieht daraus zwei konsequente Konsequenzen. Erstens: Diese Schicht ersetzt keineswegs bestehende Quellsysteme und fordert keine Migration bestehender Daten. Sie konsolidiert das darin enthaltene Selbstwissen über flexible, verlesende Adapter, wodurch etablierte Fachwerkzeuge voll produktiv bleiben. Fall B (Kapitel 11 und 13) demonstriert genau diese friedliche Koexistenz: Werkzeuge wie Confluence, SharePoint oder CAQ bleiben in den Fachbereichen bestehen, während die Konsolidierungsschicht lediglich die Widersprüche auflöst und Querverweise herstellt. Zweitens ist die zugrundeliegende Referenzarchitektur vollkommen herstellerneutral konzipiert, nach dem Muster offener Internet- und Datenstandards. Was diese Antwort allerdings nicht aushebelt: Auch eine Konsolidierungsschicht kann schleichend verwahrlosen, wenn ihre Governance vernachlässigt wird. Der Unterschied liegt darin, dass sie ihren eigenen Verfall nicht leise kaschiert, sondern durch veraltete Versionen und offene Konflikte präzise dokumentiert.
Offen bleibt: Vollständig standardisierte Austauschformate zwischen unterschiedlichen Software-Implementierungen existieren derzeit noch nicht (siehe Herausforderung H6 in Kapitel 18).
17.5 "Datenschutz und Mitbestimmung machen das unmöglich"
Die starke Form: In der Vorbereitung des Rollouts schaltet sich der Gesamtbetriebsrat gemeinsam mit dem Datenschutzbeauftragten ein: "Ein IT-System, das zentral konsolidiert, wer welches Wissen besitzt, wer welche Entscheidungen trifft und wo die operative Alltagspraxis von offiziellen Vorgaben abweicht, ist ein hochgefährliches Instrument zur Verhaltens- und Leistungskontrolle. Wir werden die Einführung blockieren oder so stark reglementieren, dass das System nutzlos wird."
Die Antwort: Dieser Einwand verdient tiefen Respekt statt oberflächlicher Beschwichtigung, weshalb unsere Antwort mit einer klaren Gegenstandsabgrenzung beginnt. Der Wissensbestand führt ausschließlich Prozess-, Struktur- und Regelwissen, jedoch keinerlei personenbezogene Leistungs- oder Verhaltensdaten. Die kleinste Analyseeinheit ist die Aussage über die Organisation (der Claim), niemals das Verhalten eines einzelnen Mitarbeiters. Wo Rollen und Zuständigkeiten sichtbar werden, handelt es sich um ohnehin öffentlich deklarierte Funktionen im Organigramm oder in der Ausführungsmatrix. Dennoch entstehen unvermeidbare Graubereiche, etwa wenn organisatorische Konfliktentscheidungen Rückschlüsse auf die Prozessqualität bestimmter Abteilungen zulassen. Aus diesem Grund gehört die Mitbestimmung von Beginn an in das Einführungsprojekt: Beteiligung der Arbeitnehmervertreter ab der ersten Scope-Entscheidung, klare Auswertungsgrenzen per Betriebsvereinbarung sowie vollständige Transparenz über alle Abfrageklassen (Kapitel 14 und 15). Governance by Design ist hier kein Lippenbekenntnis, sondern die harte Bedingung der betrieblichen Erlaubnis.
Offen bleibt: Eine in der breiten Praxis erprobte Muster-Betriebsvereinbarung für diese neuartige Systemklasse liegt aktuell noch nicht vor (siehe Herausforderung H5).
17.6 "Und was ist bei euch selbst schiefgegangen?"
Die starke Form: Am Ende der Präsentation blickt Dich der Vorstandsvorsitzende direkt an und stellt die persönlichste aller Fragen: "Ihr erzählt uns sehr viel über die theoretische Eleganz und den operativen Nutzen dieses Konzepts. Aber wo seid Ihr mit euren eigenen Kundenprojekten auf die Nase gefallen? Was sind die realen Scheitergründe in der Praxis?" Schließlich hat Harold L. Wilensky bereits 1967 in seiner klassischen Studie über Organizational Intelligence eindrücklich gezeigt, dass Organisationen ihre eigenen kognitiven Pathologien und Ausblendungsmechanismen am schwersten erkennen.
Die Antwort: Diese Antwort speist sich aus den laufenden Projektretrospektiven. Zu den dort dokumentierten Lernmustern zählen ein zu groß geschnittener Erst-Scope, unterschätzter Review-Aufwand und Governance ohne aktiven Sponsor; die ausgearbeiteten Fallschilderungen werden hier mit dem Fortschritt der Vorhaben nachgezogen. Ein Buch mit diesem hohen Anspruch, das keine eigenen Irrtümer einräumen kann, hätte seine wissenschaftliche und beratende Glaubwürdigkeit im selben Moment verspielt.
17.7 Was offen bleibt
Vier wesentliche Restfragen haben die kritische Prüfung dieses Kapitels überlebt: die langfristige Adoption im Alltag (17.1), die operative Kopplung von Log-Evidenz und Claim-Bestand (17.2), herstellerneutrale Austauschformate (17.4) sowie praxiserprobte Mitbestimmungsmuster (17.5). Wenn Du diese Liste durchgehst, erkennst Du, dass diese Punkte keineswegs zufällige Lücken darstellen, sondern die systematischen Entwicklungsgrenzen der heutigen Praxis markieren. Sie wandern nun als präzise adressierte Herausforderungen mit klaren Prüfkriterien direkt in Kapitel 18. Dass wir diese Fragen offen stehen lassen, unterscheidet ein seriöses Forschungsprogramm von einer bunten Werbebroschüre und schlägt zugleich die Brücke zum folgenden Kapitel.
💡 Das haben wir diskutiert
In diesem Kapitel hast Du erlebt, wie sich die Architektur gegenüber den sechs stärksten Gegenargumenten der Praxis behauptet.
Die Einwände (vom verwaisten Wissensmanagement bis zum Software-Silo) kommen dabei in ihrer schärfsten Form zu Wort und werden Argument für Argument beantwortet.
Zugleich werden ungelöste Aspekte nicht geglättet, sodass verbleibende Restfragen zur langfristigen Nutzung, zur Log-Anbindung sowie zur betrieblichen Mitbestimmung sichtbar bleiben.
Diese verbliebenen Hürden bilden keineswegs ein Scheitern, sondern leiten als konkrete Arbeitsaufträge direkt über zur wissenschaftlichen Forschungsagenda des nächsten Kapitels.