Der Analytics Agent arbeitet bereits in Ihrem Unternehmen

Menschen als inoffizielles Gedächtnis der Datenlandschaft

Über die Zeit werden diese Menschen zum inoffiziellen Gedächtnis der Datenlandschaft.

Sie wissen, welcher Quelle Finance vertraut, während Sales trotzdem eine andere nutzt. Sie erinnern sich an die Definition, die im vergangenen Jahr geändert wurde, aber noch immer in alten Reports auftaucht. Sie wissen, wann eine Zahl technisch korrekt und trotzdem für die anstehende Entscheidung unbrauchbar ist. Sie wissen, welches Dashboard alle zuerst öffnen, obwohl auch alle wissen, dass es Einordnung braucht.

Und oft genug sind sie die einzige Person im Raum, die mit Sicherheit sagen kann: „Das können wir beantworten, aber nicht mit diesem Datensatz.“

Jeder, der im Umfeld von BI, ERP, CRM oder Legacy Reporting gearbeitet hat, kennt eine Version davon.

Der IT-Gatekeeper für System X verlässt das Unternehmen. Der Kollege, der die alte Mapping-Logik verstanden hat, ist weg. Die Person, die wusste, warum aus dem „temporären“ Workaround eine dauerhafte Lösung wurde, ist vor drei Jahren in eine andere Abteilung gewechselt.

Plötzlich wird etwas, das wie ein System aussah, zu einem Gedächtnisproblem. Die Daten sind noch da. Die Reports sind noch da. Die Tabellen sind noch da. Aber die Bedeutung ist aus dem Gebäude gegangen.

‍

Warum Governance nach dem Aufräumen nicht endet

Etwas Ähnliches passiert nach vielen Governance-Initiativen.

Eine Zeit lang sieht alles sauberer aus. Definitionen sind abgestimmt. Ownership ist vergeben. Reports sind konsolidiert. Der Katalog ist aktualisiert. Alte Logik ist dokumentiert. Einige Menschen schützen die Struktur mit echter Aufmerksamkeit.

Dann verlassen ein oder zwei zentrale Owner das Unternehmen, wechseln die Rolle oder haben schlicht nicht mehr genug Zeit, das System zu verteidigen. Und langsam wächst das Alte wieder nach.

Ein lokaler Report entsteht, weil der zentrale zu lange braucht. Ein neues Feld wird außerhalb des vereinbarten Modells ergänzt, weil jemand schnell eine Antwort benötigt. Ein temporärer Workaround wird Teil des Prozesses. Eine Kennzahl wird in einer Abteilung angepasst und in einer anderen nicht. Der Katalog existiert noch, aber er ist nicht mehr der Ort, an dem die Realität gepflegt wird.

Niemand zerstört das System mit einem dramatischen Schritt. Es wächst einfach wieder an den Regeln vorbei. Deshalb endet Governance selten mit einem einzigen Aufräumprojekt. Dieses Aufräumen ist wichtig. Natürlich ist es das. Aber der schwierigere Teil besteht darin, die Bedeutung danach zu schützen. Datenlandschaften bleiben nicht von selbst geordnet.

‍

Wenn Analytics dialogfähig wird, braucht es mehr als Antworten

Das wird relevant, sobald Unternehmen über Conversational oder Agentic Analytics sprechen.

Die eigentliche Arbeit liegt selten in der Frage, die jemand in ein Interface tippt. Die eigentliche Arbeit liegt im Urteilsvermögen, das nötig ist, bevor eine belastbare Antwort gegeben werden kann.

In klassischer BI blieb ein großer Teil dieses Urteilsvermögens bei Menschen. Ein Dashboard grenzte die Frage bereits ein, bevor der Nutzer kam. Ein Report enthielt schon Entscheidungen über Quellen, Filter und Definitionen. Eine Analystin ergänzte im Meeting die Einschränkung. Ein Projektteam wusste, welche Zahl offiziell war, welche näher an der operativen Realität lag und welche erst einen Anruf brauchte, bevor darauf eine Entscheidung aufgebaut werden sollte.

Unordentlich, aber vertraut.

Jetzt soll mehr von dieser mittleren Ebene in Systeme wandern.

Ein Modell kann eine Antwort erzeugen. Dieser Teil ist weniger beeindruckend geworden. Die schwierigere Frage ist, ob diese Antwort überhaupt das Recht hat, selbstbewusst zu klingen.

‍

Die eigentliche Frage ist nicht, ob das System antworten kann

Wenn jemand nach Marge fragt, braucht das System mehr als eine Spalte, die relevant aussieht. Es muss wissen, welche Margenlogik die Organisation in diesem Kontext tatsächlich verwendet, ob bestimmte Kostenelemente enthalten sind, welche Umsatzlogik gilt, welche Quelle als vertrauenswürdig gilt, wer das Datenprodukt verantwortet und ob die fragende Person die zugrunde liegenden Details überhaupt sehen darf.

Wenn sich die Definition im vergangenen Jahr geändert hat oder bekannte Ausnahmen existieren, muss auch dieses Wissen verfügbar sein. Das sind alte BI-Fragen. Sie lassen sich schwerer ignorieren, wenn das Interface einfacher zu bedienen wird.

An dieser Stelle werden Kataloge, semantische Schichten, Lineage, Ownership, Berechtigungen und Dokumentation zu mehr als Governance-Vokabular. In einem Conversational- oder Agentic-Analytics-Setup werden sie Teil des Arbeitskontexts des Systems.

‍

Der Katalog wird zum Arbeitsgedächtnis des Systems

Nehmen wir Unity Catalog oder eine andere ernstzunehmende Katalogschicht.

In einem normalen Daten-Setup hilft sie dabei, Zugriff, Lineage, Metadaten, Ownership und Berechtigungen zu organisieren. Je nach Organisation ist sie gut gepflegt, halb gepflegt oder wird als etwas behandelt, das Governance einmal eingefordert hat und das niemand wirklich nutzt.

Sobald ein System stärker agentisch arbeiten soll, werden die Konsequenzen größer.

Das System braucht etwas Verlässliches, worauf es sich stützen kann, wenn eine fachliche Frage mehrdeutig, schlecht dokumentiert oder politisch aufgeladen ist. Es muss verstehen, welche Quelle für eine bestimmte Art von Frage vertrauenswürdig ist, welche Definition aktuell ist, welche Annahmen dokumentiert wurden, wo Lineage relevant ist und an welcher Stelle Berechtigungslogik eine Antwort stoppen sollte, bevor sie irreführend wird.

Ein schwacher Katalog ist in klassischer BI bereits störend. In Agentic Analytics wird er zu schwachem Gedächtnis.

‍

Brain, Memory und Skills müssen operativ gedacht werden

In Enterprise Analytics ist das „Brain“ selten nur das Modell. Es ist das Modell zusammen mit semantischem Kontext, Quellenprioritäten, Berechtigungen, Geschäftsregeln, Retrieval-Logik und der umgebenden Architektur.

Ohne diesen Kontext kann das System flüssig klingen und fachlich trotzdem falsch liegen.

Memory sollte keine zufällige Chat-Historie sein. Nützliches Memory bedeutet kontrollierter organisationaler Kontext:
‍
- freigegebene Definitionen,
- korrigierte Annahmen,
- Projektentscheidungen,
- bekannte Ausnahmen,
- Nutzerfeedback
- und all das, was die Organisation bereits auf die harte Tour gelernt hat.

Auch Skills brauchen Grenzen. Ein Skill kann ein Datenprodukt abfragen, eine Kennzahl erklären, Lineage prüfen, ein Mapping vorschlagen, einen Test erzeugen, ein Ticket erstellen, ein Datenqualitätsproblem markieren oder eine Folgeanalyse entwerfen.

All das kann nützlich sein.

Es bedeutet aber auch, dass jemand entscheiden muss, wo diese Skills enden.

‍

Manchmal ist keine Antwort die bessere Antwort

An diesem Punkt wird das Thema operativ.

Manchmal sollte das System antworten. Manchmal sollte es zeigen, dass die Definition unklar ist. Manchmal sollte es darauf hinweisen, dass zwei Quellen nicht übereinstimmen. Manchmal sollte es eine Ownership-Entscheidung einfordern. Manchmal sollte es sich weigern, eine Zahl zu erzeugen, die präzise wirkt, aber nicht entscheidungsreif ist.

Dieses Verweigerungsverhalten ist keine Schwäche. Es ist Teil dessen, was das System nützlich macht.

‍

Was Demos oft nicht zeigen

Viele saubere Demos überspringen genau diesen Teil.

Sie zeigen die Frage und die Antwort. Sie zeigen selten den Kompromiss im Quellsystem hinter der Kennzahl, den Report, den alle nutzen, aber niemand vollständig vertraut, die Definition, die in einem Steering Committee geändert wurde und nie im semantischen Modell angekommen ist, oder das Berechtigungsproblem, das erst sichtbar wird, wenn jemand aus der falschen Rolle heraus fragt.

Diese Details entscheiden, ob eine Antwort brauchbar ist. Die alte BI-Arbeit ist nicht weg. Sie steht nur plötzlich unter mehr Druck.

Eine schwache semantische Schicht wird zu fragilen Antworten. Unklare Ownership lässt das System raten. Unsaubere Berechtigungen werden durch natürliche Sprache leichter auslösbar. Ein veralteter Katalog gibt dem System weniger Kontext, als während der Demo alle angenommen haben. Politische Definitionen werden nicht neutral, nur weil ein Modell die Antwort sauber formuliert.

Der Widerspruch wird vielleicht einfach schneller sichtbar.

Das kann nützlich sein. Es kann aber auch unangenehm werden, weil es die Lücke zwischen dem offenlegt, was die Organisation für explizit hält, und dem, was tatsächlich nur sozial verstanden wird.

‍

Auch Agentic Analytics braucht Pflege

Und dann bleibt noch das Wartungsproblem.

Wenn ein agentisches System aus Korrekturen, Feedback und freigegebenen Definitionen lernt, muss jemand dieses Lernen schützen. Sonst wiederholt sich das alte Muster.

Das System startet sauber, Menschen arbeiten darum herum, Ausnahmen sammeln sich an, Ownership wird unscharf und nach einer Weile ist niemand mehr ganz sicher, ob die Antwort die vereinbarte Logik widerspiegelt oder nur den neuesten Workaround.

Das ist der Teil, den niemand in der Demo sieht. Aber er entscheidet, ob das System sechs Monate später noch nützlich ist.

Kontext braucht Pflege. Memory braucht Ownership. Skills brauchen Grenzen.

Und das System braucht die Fähigkeit zu sagen: „Ich weiß darüber nicht genug, um verantwortungsvoll zu antworten.“

‍

Die alte BI-Schwäche wird sichtbarer

Gute BI-Teams wissen das bereits.

Bedeutung muss geschützt werden. Definitionen verfallen, wenn niemand sie verantwortet. Governance scheitert nicht nur, weil das Framework falsch war. Sie scheitert oft, weil die wenigen Menschen, die sie schützen, irgendwann nicht mehr die Zeit, die Autorität oder das Mandat haben, genau das weiter zu tun.

Agentic Analytics setzt diese Schwäche stärker unter Druck.

Die Organisation hat heute bereits Analytics Agents. Es sind die Menschen, die die Einschränkungen, die Historie, die Ausnahmen und die inoffiziellen Regeln rund um die Zahlen kennen.

Der nächste Schritt besteht darin zu entscheiden, welche Teile dieses Wissens sicher in Systeme überführt werden können, welche Teile besser dokumentiert werden müssen, welche Teile in Kataloge und semantische Schichten gehören und welche Teile weiterhin menschliches Urteilsvermögen brauchen.

‍

Das Eingabefeld ist nur der sichtbare Teil

Die schwierige Arbeit beginnt früher: bei den Definitionen, dem Katalog, der Ownership, den Berechtigungen, dem Gedächtnis früherer Entscheidungen und den Grenzen dessen, was das System tun darf.

Jeder, der erlebt hat, wie eine Datenlandschaft nach einem Governance-Projekt wieder verwässert, weiß, warum das wichtig ist.

Alte Unschärfe verschwindet nicht, nur weil das Interface besser wird.

Sie wird nur schneller verteilt.