Die Mauer zwischen Analytik und operativem Geschäft einreißen:
ein Praxisleitfaden zur Konvergenz

Gastbeitrag im Auftrag von InterSystems
Stellen Sie sich einen Chemiebetrieb vor, dessen Analysesystem die Verschleißmuster von Pumpen auswertet und vorhersagt, wann eine Wartung fällig ist. Die Sensordaten landen allerdings nur alle vier Stunden im System. Um 14:00 Uhr beginnt eine Pumpe zu vibrieren, ein klares Zeichen für einen bevorstehenden Ausfall. Das operative Team erfährt davon erst um 18:00 Uhr aus dem Analysebericht. Um 19:30 Uhr fällt die Pumpe aus, und die gesamte Produktionslinie steht still. Eine ungeplante Notfallwartung kostet ein Vielfaches einer planmäßigen Instandhaltung, und der Produktionsausfall führt zu verspäteten Lieferungen.

Mit einer Auswertung in Echtzeit hätte das Team die Warnsignale sofort erkannt und die Pumpe schon am frühen Nachmittag planmäßig gewartet. Die Produktion liefe weiter, die Kosten blieben kalkulierbar, die Lieferungen pünktlich.

Genau so schließen konvergente Workflows die Lücke zwischen Wissen und Handeln. Sie sorgen dafür, dass analytische Signale (Prognosen, Modelle, Regeln und so weiter) zuverlässig operative Maßnahmen auslösen, und zwar schnell genug, um in dynamischen Märkten Chancen zu nutzen und Risiken zu begrenzen. Dieser Beitrag zeigt, woraus konvergente Workflows bestehen, benennt die fünf häufigsten Hürden und liefert einen praxisnahen Leitfaden, um sie zu überwinden.

Über Jahrzehnte haben Unternehmen operative und analytische Systeme strikt getrennt betrieben.

• Operative Systeme wie ERP, POS, CRM, Supply Chain und E-Commerce führen Transaktionen aus und automatisieren Geschäftsprozesse auf Datenbanken. 

• Analytische Systeme wie BI-Werkzeuge und Machine-Learning-Anwendungen gewinnen Erkenntnisse, indem sie Daten in Data Warehouses oder Lakehouses verarbeiten. 

Verbunden wurden beide Welten über ETL- bzw. ELT-Pipelines (Extract, Transform, Load), die in festen Intervallen, alle paar Stunden oder Minuten, Datenkopien aus den operativen in die analytischen Systeme überführen. Dieses Modell funktioniert, solange Entscheidungen warten können. Es versagt, sobald der Wert einer Information rasch verfällt, etwa wenn Betrug erkannt werden muss, bevor eine Transaktion durchläuft, oder wenn die Kosten der Datenbewegung zu hoch werden.

Konvergente Workflows lösen das Zeit- und das Kostenproblem zugleich. Sie rücken Analytik, Entscheidungslogik und KI näher an die operativen Daten, die transaktionalen Workloads und den fachlichen Kontext, sodass Maßnahmen unmittelbar innerhalb der Geschäftsprozesse erfolgen. In der Praxis bewegen sich konvergente Workflows auf einem Spektrum:

• Entscheidungsunterstützung: Das System empfiehlt, der Mensch entscheidet. 

• Geführte Automatisierung: Das System handelt innerhalb definierter Leitplanken und eskaliert Ausnahmen an den Menschen. 

• Autonome Orchestrierung: Das System steuert Entscheidungen und Maßnahmen durchgängig, der Mensch überwacht und greift bei Anomalien ein. 

Werden Daten über Silos hinweg kopiert, erhöht jede Kopie die Latenz durch zusätzliche Aktualisierungszyklen und das Risiko von Abweichungen oder uneinheitlichen Definitionen. Eine KI, die auf veralteten oder widersprüchlichen Kopien trainiert wird, liefert Ergebnisse, auf die kein Verlass ist. Gefährlich wird das, sobald diese Ergebnisse automatisch Maßnahmen auslösen. 

ETL sollte ursprünglich Produktivsysteme vor analytischen Lasten schützen. Der Preis dafür ist verlorene Zeit: Die aktuellsten „analysebereiten“ Daten hinken der Realität immer mindestens einen Pipeline-Durchlauf hinterher. Bei zeitkritischen Anwendungsfällen kann diese Verzögerung das Geschäft ausbremsen. 

Getrennte Teams und Werkzeuge führen zu uneinheitlichen Regeln für Zugriff, Datenherkunft und Datenqualität zwischen operativer und analytischer Welt. Nutzt eine KI Daten mit unklarer Herkunft oder unzureichenden Kontrollen, wird die Automatisierung fragil und riskant. 

Wer von manuellen Entscheidungen direkt zu vollständig agentischer Autonomie springt, geht erhebliche Risiken ein. Ohne stufenweisen Weg geraten Vertrauens- und Sicherheitsmechanismen aus der Balance: Entweder sind sie überdimensioniert und schmälern den Nutzen, oder sie sind zu schwach und schaffen Governance-Risiken. 

Latenzwerte sagen wenig aus, solange sie nicht mit Geschäftsergebnissen verknüpft sind. Entscheidend sind Time-to-Decision und Cost-per-Decision. Ohne diesen Bezugsrahmen lassen sich keine klugen Abwägungen treffen. 

Diese Hürden lassen sich mit fünf Gestaltungsprinzipien überwinden: eine einheitliche Datenebene aufbauen, die Analytik zu den Daten bringen, Governance durchgängig vereinheitlichen, einer ausgereiften Automatisierungs-Roadmap folgen und die Leistung in Geschäftskennzahlen messen.

IT- und Datenteams sollten eine konsistente Zugriffsebene schaffen, über die operative Anwendungen und Analyse- bzw. KI-Werkzeuge dieselben Governance-Kontrollen nutzen. So lässt sich Qualität an einer Stelle sicherstellen, statt Dutzende Kopien nachträglich zu korrigieren. 

Bei zeitkritischen Workloads sollten Auswertungen direkt auf den operativen Daten laufen, etwa mithilfe von Zero-Copy-konvergenten Datenbanken. Data Warehouses und Lakehouses behalten ihren Wert für eigenständige Analyseprojekte. Doch ETL sollte nicht länger der Standard für jede Entscheidungsschleife sein. 

Unternehmensweite Governance-Richtlinien sollten definiert und mit einheitlichen Qualitätsregeln, Datenherkunft und Zugriffskontrollen über operative wie analytische Anwendungsfälle hinweg durchgesetzt werden. Automatisierung braucht eine Governance, die bis auf die letzte Meile der Ausführung trägt. 

Entscheidend ist, in aufeinander aufbauenden Stufen zu automatisieren: zunächst Entscheidungsunterstützung, dann geführte Automatisierung mit klaren Leitplanken (etwa Schwellenwerte, Konfidenzwerte und Ausnahmewarteschlangen) und schließlich die Ausweitung zur Orchestrierung, sobald Beobachtbarkeit und Vertrauen gereift sind. 

Legen Sie für jeden Anwendungsfall das Entscheidungsfenster fest: Wie lange bleibt ein analytisches Signal wertvoll, bevor die Chance verstreicht oder das Risiko eintritt? Daraus leiten Sie Zielwerte für Time-to-Decision und Cost-per-Decision ab. Messen Sie am Ausgangszustand und verfolgen Sie Verbesserungen als KPI, nicht als kosmetische Infrastrukturkennzahl. 

Hindernisse	Wie sie Konvergenz  behindern	Gestaltungsprinzipien
Datenfragmentierung	Latenz und Inkonsistenzen führen zu unsicheren Erkenntnissen und Maßnahmen.	Einheitliche Datenebene aufbauen  Konsistente Governance sicherstellen
ETL-zentrierte Architektur	Strukturelle Verzögerung: Analysefähige Daten stehen erst zeitversetzt zur Verfügung.	Analytik zu den Daten bringen  Time-to-Decision messen  Zero-Copy-Datenbanken verwenden
Governance-Lücken	Höhere Risiken durch uneinheitliche Regeln für Datenzugriff, Datenherkunft und Datenqualität.	Governance durchgängig vereinheitlichen
Überhastete Automatisierung	Überhastetes Vorgehen kann zu Widerständen im Team und unkontrollierbaren Risiken führen.	Schrittweise Automatisierungs-Roadmap
Fehlende Business-SLAs	Rein technische Kennzahlen werden optimiert, ohne Bezug zu Geschäftsergebnissen.	Time-to-Decision messen  Cost-per-Decision messen

Konvergenz ist kein Produkt, das man installiert. Sie ist ein grundlegender Wandel darin, wie Daten, Governance und Entscheidungen mit der operativen Ausführung verknüpft werden.

Doch wie gelingt Daten- und IT-Verantwortlichen der Einstieg? Wählen Sie einen Workflow, in dem Latenz spürbar wehtut (etwa Preisgestaltung, Bestandsauffüllung, Betrugserkennung oder Service), definieren Sie eine akzeptable Time-to-Decision und bestimmen Sie den Übergabepunkt, an dem eine Erkenntnis zu „jemand anderes Problem“ wird. Genau an dieser Nahtstelle beginnt Konvergenz.

Mehr dazu lesen Sie im neuen, ebenfalls von InterSystems in Auftrag gegebenen BARC-Report
„ Agentic AI and Operations: An Executive Guide to Converged Workflows“.