Die meisten Projekte zur intelligenten Automatisierung scheitern nicht an der Automatisierungsplattform, sondern am Legacy-System selbst. Es gibt keine dokumentierte API, keinen Event-Stream, und die entscheidende Geschäftslogik steckt in Datenbanken, Bildschirmmasken und jahrelangen undokumentierten Anpassungen. Herkömmliche Automatisierungsansätze führen deshalb ohne gründliche Vorarbeit selten zum Ziel.
Viele Unternehmen betreiben ihr Kerngeschäft weiterhin auf SAP ECC, IBM AS/400, IBM z/OS, Oracle E-Business Suite oder eigenen monolithischen Anwendungen. Während ringsum Cloud-Plattformen und moderne Anwendungen entstanden sind, blieb die Kerninfrastruktur im Wesentlichen unverändert. Genau deshalb verlangt intelligente Automatisierung von Legacy-Systemen eine andere Integrationsstrategie als moderne Software.
Dieser Leitfaden erläutert vier bewährte Integrationsmuster für Umgebungen ohne saubere API und beschreibt die Vorarbeit, die teure Fehler verhindert, bevor die Umsetzung beginnt.
- Legacy-Software lässt sich über vier Integrationsmuster automatisieren: UI-Scraping, Change Data Capture (CDC), Read-only-Shadow-Datenbank und Strangler Fig.
- RPA ohne API sollte als Übergangslösung behandelt werden, nicht als langfristige Architektur.
- Dokumentieren Sie Prozesse, Datenformate und Ausnahmepfade, bevor Sie Automatisierung ausrollen.
- Das Strangler-Fig-Muster ist die sicherste langfristige Modernisierungsstrategie.
- Realistische Zeitpläne: UI-Scraping 6–10 Wochen, CDC 3–6 Monate, Strangler Fig 12–24 Monate.
Warum Legacy-Systeme die üblichen Automatisierungsrezepte sprengen
Die meisten Ansätze zur Automatisierung von Legacy-Software setzen moderne Anwendungen mit gut dokumentierten APIs voraus. Legacy-Plattformen erfüllen diese Erwartung selten. Die größten Hürden sind fehlende APIs, in Datenbanken vergrabene Geschäftslogik und undokumentierte Geschäftsprozesse.
Systeme auf COBOL, IBM z/OS, IBM AS/400, SAP ECC und Oracle E-Business Suite enthalten häufig Anpassungen aus Jahrzehnten. Selbst mit Plattformen wie UiPath oder Automation Anywhere bleibt UI-Scraping fragil. Ein kleines Interface-Update oder ein Session-Timeout kann alle Bots gleichzeitig stoppen. Laut Forrester ist unterschätzte Ausnahmebehandlung eine der Hauptursachen für Budgetüberschreitungen in Automatisierungsprojekten; Gartner empfiehlt, die Integrationsarchitektur zu bewerten, bevor eine RPA-Plattform ausgewählt wird.
Eine Prozess- und Anforderungsanalyse an dieser Stelle hilft, Zugriffsbeschränkungen, Prozessrisiken und den passenden Modernisierungspfad zu validieren. Erst danach sollten Werkzeuge für die RPA-Anbindung an Legacy-Systeme ausgewählt werden.
Mit unseren Leistungen zur Softwaremodernisierung identifizieren Sie den sichersten Integrationsansatz und vermeiden teure Umbauten im späteren Projektverlauf.
Was vor dem Automatisierungslayer standardisiert werden muss
Die erfolgreichsten Projekte beginnen nicht mit dem Schreiben von Bots, sondern mit Standardisierung. In Unternehmensumgebungen ruht die Stabilität der Automatisierung auf drei Fundamenten: dokumentierte Geschäftsprozesse, konsistente Datenformate und klar definierte Ausnahmebehandlung. Bleiben diese Elemente undokumentiert, reproduziert die Automatisierung lediglich die bestehenden operativen Probleme. Vor der Einführung jeder Automatisierungstechnologie sollten Organisationen diese drei Bereiche standardisieren.
Jede Prozessvariante in BPMN dokumentieren, bevor ein einziger Bot entsteht
Die meisten Teams dokumentieren nur den Happy Path. In der Praxis genügt das selten. Selbst ein vergleichsweise einfacher Auftragsabwicklungsprozess umfasst typischerweise vier bis sieben Varianten. Jede undokumentierte Abweichung erhöht die Wahrscheinlichkeit von Automatisierungsfehlern.
Dokumentieren Sie zunächst jeden Prozess mit BPMN 2.0. Camunda Modeler, Lucidchart und Signavio bieten dafür geeignete Modellierungsfunktionen, während UiPath Process Mining und Celonis die tatsächlichen Ausführungspfade direkt aus Event-Logs rekonstruieren. Process Mining bringt häufig Prozessvarianten zum Vorschein, von deren Existenz die Fachbereiche nichts wussten.
Nach unserer Erfahrung gehen die ersten beiden Umsetzungssprints meist dafür auf, verborgene Prozessvarianten zu entdecken und Ausnahmeszenarien zu dokumentieren. Das Ergebnis sollten BPMN-Diagramme für jede Prozessvariante sein, zusammen mit einem Ausnahmeregister, das Häufigkeit, Verantwortlichkeit und Geschäftsauswirkung beschreibt.
Alle Datenformate an jeder Systemgrenze inventarisieren
Der nächste Schritt ist eine vollständige Inventarisierung jedes Datenformats, das über Systemgrenzen hinweg ausgetauscht wird.
Legacy-Umgebungen stützen sich selten allein auf moderne Standards. Häufig kommen EBCDIC, Flat Files mit fester Satzlänge, EDI, mehrere CSV-Varianten, Anbindungen über JDBC, ODBC, IBM MQ und JMS sowie undokumentierte Datumsformate und gemischte Zeichenkodierungen zusammen.
Wir empfehlen, ein zentrales Data Format Registry aufzubauen, das für jeden Integrationspunkt Quellsystem, Ziel, Datenformat und erforderliche Transformationsregeln erfasst. Diese Dokumentation wird unverzichtbar, sobald Automatisierungsabläufe Informationen über mehrere Plattformen hinweg austauschen.
Aus unseren Integrationsprojekten im Unternehmensumfeld wissen wir: Probleme bei der Datentransformation verbrauchen durchgängig einen erheblichen Teil des Umsetzungsaufwands. Datenformate vor der Automatisierung zu standardisieren senkt die Integrationsrisiken im späteren Projektverlauf drastisch.
Jeden Ausnahmepfad und seinen heutigen manuellen Bearbeiter erfassen
Der letzte Vorbereitungsschritt ist die Dokumentation jedes Ausnahmeszenarios. Fachanwender kennen in der Regel den Standardablauf. Das wertvollste operative Wissen liegt jedoch meist bei den Mitarbeitenden, die Ausnahmen täglich manuell auflösen. Strukturierte Interviews mit diesen Fachleuten sind oft der einzige verlässliche Weg, undokumentierte Geschäftsregeln zu verstehen.
Jede Ausnahme sollte als wiederholbar, fachlich oder systembedingt klassifiziert werden. Die Dokumentation sollte außerdem die geltenden SLAs, zuständigen Teams, Häufigkeiten und Eskalationswege festhalten.
Technologien wie BPMN Error Events, zentrales Exception-Logging, die Dead Letter Queue von IBM MQ und ServiceNow bilden eine solide Grundlage für eine Ausnahmebehandlung auf Unternehmensniveau. Das entstehende Ausnahmeregister ist die Blaupause für einen robusten Automatisierungslayer, der intelligente Automatisierung auch ohne API in komplexen Legacy-Umgebungen tragen kann.
Vier Integrationsmuster für intelligente Automatisierung von Legacy-Systemen
Sind Prozesse, Daten und Ausnahmebehandlung standardisiert, folgt die Wahl der richtigen Integrationsstrategie. Eine universelle Lösung gibt es nicht. Der beste Ansatz hängt von der Architektur der Legacy-Plattform, den fachlichen Anforderungen, den Umsetzungsfristen und dem akzeptierten Risiko ab. In den meisten Unternehmensumgebungen entscheidet über den Erfolg das Integrationsmuster, nicht die Automatisierungsplattform. Die folgenden vier Muster haben sich für Organisationen, die Legacy-Systeme ohne Austausch der Kerninfrastruktur modernisieren, wiederholt bewährt.
UI-Scraping als temporäre Brücke
RPA-Werkzeuge wie UiPath oder Blue Prism automatisieren Legacy-Software über die Oberfläche und imitieren menschliche Handlungen mit Screen Scraping, OCR und Tastatureingaben. Dieser Ansatz, häufig eingesetzt bei IBM-3270-Terminals, ermöglicht die RPA-Anbindung an Legacy-Systeme, wenn keine verlässliche API existiert.
Er funktioniert gut für einen Proof of Concept über 6 bis 10 Wochen, für ältere Webanwendungen oder für Mainframes. Attended Bots unterstützen Anwender, Unattended Bots übernehmen regelbasierte Aufgaben. Ohne API-Zugriff lässt sich mit RPA ein Business Case schnell validieren, bevor tiefer integriert wird.
Die Grenzen des UI-Scrapings machen es allerdings zur schlechten Wahl für hohe Volumina, für mehr als 500 Transaktionen pro Tag oder für instabile Oberflächen. Die Wartungskosten steigen schnell, und Upgrades können Bots zerstören. Behandeln Sie die RPA-Anbindung als temporäre Brücke: Reservieren Sie 20 bis 30 Prozent der Teamkapazität für Support und definieren Sie einen Migrationsplan.
Event-Streaming-Adapter über Change Data Capture (CDC)
Steht Datenbankzugriff zur Verfügung, ist Change Data Capture die robustere Integrationsstrategie gegenüber UI-Automatisierung. Statt mit der Anwendungsoberfläche zu interagieren, überwacht CDC die Transaktionsprotokolle der Datenbank. Werkzeuge wie Debezium, SQL Server CDC und Oracle GoldenGate erfassen Änderungen und publizieren sie über Kafka Connect an Apache Kafka. Eine CDC-Pipeline erlaubt es, ereignisgesteuerte Automatisierung aufzubauen, ohne die Anwendung selbst zu verändern.
CDC lässt die Legacy-Anwendung unberührt. Die Automatisierung kann Geschäftsereignisse nahezu in Echtzeit verarbeiten, ohne Anwender zu stören oder die Anwendungsschicht zusätzlich zu belasten. Es erfordert enge Zusammenarbeit mit den Datenbankadministratoren und ein klares Verständnis von Schemata, Transaktionsprotokollen und Replikation. Weil einige älteren Datenbanken CDC nur eingeschränkt unterstützen, ist Architekturplanung unverzichtbar. Die Umsetzung dauert drei bis fünf Monate, liefert aber eine skalierbare, ereignisgesteuerte Basis für Automatisierung und Modernisierung.
Read-only-Shadow-Datenbank
Nicht jedes Automatisierungsprojekt braucht Schreibzugriff auf die Legacy-Anwendung. Eine Read-only-Shadow-Datenbank bietet eine sichere, lesende Integration, indem sie eine synchronisierte Replik der Produktionsdaten vorhält. Technologien wie SQL Server Replication, Oracle Data Guard, PostgreSQL Logical Replication und AWS RDS Read Replicas unterstützen dieses Modell.
Automatisierungsdienste, Reporting-Werkzeuge und Analyse-Workloads greifen auf die Replik zu statt auf die operative Datenbank. Plattformen wie Snowflake und Elasticsearch sowie dbt können die replizierten Daten über SQL, APIs oder Dashboards bereitstellen, ohne die Produktionsleistung zu beeinträchtigen.
Der zentrale Vorteil ist Isolation: Reporting, KI-Modelle und Automatisierung laufen unabhängig, während das Legacy-System den Tagesbetrieb trägt. Der Preis dafür ist Replikationslatenz, die für Prozesse mit sofortiger Konsistenzanforderung ungeeignet sein kann. Schemaänderungen müssen sorgfältig gesteuert werden. Eine einfache Shadow-Datenbank lässt sich in 6 bis 12 Wochen bereitstellen und bietet damit einen risikoarmen Modernisierungspfad.
Strangler Fig – schrittweiser Ersatz von Legacy-Funktionen
Das Strangler-Fig-Muster ersetzt Legacy-Funktionen allmählich, anstatt einen riskanten Komplettneubau zu erzwingen. Für diese Art der Modernisierung stellen Sie eine Fassade oder ein API-Gateway wie Kong oder AWS API Gateway vor den Monolithen. Neue Funktionen entstehen als eigenständige Dienste, und der Verkehr wird über Feature Toggles oder ereignisgesteuertes Routing schrittweise umgelenkt.
Ein API-Wrapper um das Legacy-System kann als erste Fassade dienen. Er stellt ausgewählte Funktionen des Monolithen bereit, während neue Dienste sie nach und nach übernehmen. Damit erhalten Automatisierungsplattformen stabile APIs, statt auf Legacy-Masken oder direkten Datenbankzugriff angewiesen zu sein. Die alte Anwendung bleibt in Betrieb, störende Umstellungstermine entfallen.
Dieser Ansatz erfordert höhere Anfangsinvestitionen als RPA: Die ersten Funktionen brauchen drei bis vier Monate, eine vollständige Modernisierung kann Jahre dauern. Im Gegenzug senkt er technische Schulden, verbessert die Wartbarkeit und schafft eine belastbare Grundlage für intelligente Automatisierung.
Vermeiden Sie kostspielige Architekturfehler. Unser Team schneidet zuerst die Integration zu – mit KI-Lösungen für die Prozessautomatisierung und mit KI-Integration für unstrukturierte Daten.
Legacy-Automatisierungsmuster im Vergleich: wann welches passt
Die Muster unterscheiden sich in Umsetzungsgeschwindigkeit, Risiko, Zugriffsanforderungen und Eignung für langfristige Modernisierung. Die richtige Wahl hängt von der bestehenden Architektur, dem Prozessvolumen, den Integrationsbeschränkungen und den geschäftlichen Prioritäten ab.
| Muster | Zeit bis zum ersten Ergebnis | Risiko | Datenbankzugriff nötig | Langfristige Eignung |
|---|---|---|---|---|
| UI-Scraping (RPA) | 6–10 Wochen | HOCH (fragil) | nein | nein – nur temporäre Brücke |
| Event-Streaming (CDC) | 3–5 Monate | MITTEL | ja (Log lesen) | ja – stabiles Event-Backbone |
| Read-only-Shadow-DB | 6–12 Wochen (Basis) | NIEDRIG | ja (Replikation) | teilweise – nur lesende Szenarien |
| Strangler Fig | 3–4 Monate (erste Funktion) | NIEDRIG–MITTEL | optional | ja – vollständiger Modernisierungspfad |
In der Praxis kombinieren die meisten Unternehmensteams die Muster: UI-Scraping verschafft Zeit, während parallel die CDC-Infrastruktur entsteht. Eine Read-only-Shadow-Datenbank kann Reporting und Analytik tragen, ohne die Produktion zu berühren, und das Strangler-Fig-Muster verlagert kritische Funktionalität allmählich auf moderne Dienste. Dieses stufenweise Vorgehen liefert kurzfristigen Nutzen und schafft gleichzeitig eine belastbarere Architektur für die intelligente Automatisierung von Legacy-Systemen.
«Die größte Herausforderung bei der Automatisierung von Legacy-Systemen ist zu verstehen, wie das System nach Jahren undokumentierter Änderungen tatsächlich arbeitet. Bei Elinext beginnen wir deshalb mit der Kartierung von Geschäftsprozessen, Integrationspunkten und Ausnahmebehandlung, bevor wir eine Automatisierungsstrategie empfehlen. Das senkt die Umsetzungsrisiken und schafft ein tragfähiges architektonisches Fundament für die weitere Modernisierung, ohne neue technische Schulden aufzubauen.»
— Maxim Dadychyn, Leiter Generative KI bei Elinext
Fünf Fehler, die intelligente Automatisierung auf Legacy-Systemen ausbremsen
Nach meiner Erfahrung scheitern Projekte zur Legacy-Automatisierung häufig, bevor der erste Bot oder die erste Integration gebaut ist. Ich habe Teams erlebt, die UI-Scraping wählten, ohne vorher zu messen, wie oft sich die Masken ändern; die eine CDC-Pipeline entwarfen, bevor der Zugriff auf Transaktionsprotokolle bestätigt war; oder die einen Prozess automatisierten, ohne die Ausnahmen zu kartieren, die Mitarbeitende manuell abarbeiten. In solchen Situationen validiere ich diese Randbedingungen zuerst mit den Systemverantwortlichen und den Anwendern an der Front. Das kostet vorab zusätzliche Zeit, verhindert aber Nacharbeit, fragile Abläufe und eskalierende Supportkosten nach dem Release.
Fehler 1: Automatisieren, bevor dokumentiert ist
Der teuerste Fehler, den ich sehe, ist die Automatisierung des Happy Path, bevor kartiert wurde, was passiert, wenn ein Fall vom Standardweg abweicht. Ein Bot erledigt vielleicht 70 Prozent der Transaktionen korrekt und scheitert dann stillschweigend an Ausnahmen wie fehlenden Feldern, Duplikaten, Freigabesperren oder ungewöhnlichen Kontostatus. Im schlimmsten Fall schreibt er unvollständige oder falsche Daten, ohne dass es jemandem auffällt – bis zur Abstimmung.
Bevor ein Bot entsteht, empfehle ich, echte Prozessprotokolle zu prüfen und mit den Mitarbeitenden zu sprechen, die Ausnahmen täglich auflösen. Dokumentieren Sie jeden Entscheidungspunkt, jede Eskalationsregel und jede Korrekturmaßnahme. Wenn ein Ablauf nicht erklären kann, was der Bot bei einem Fehler tun soll, ist er nicht reif für Automatisierung.
Fehler 2: UI-Scraping als Dauerlösung behandeln
UI-Scraping kann nützlich sein, wenn es keine API, keinen Datenbankzugriff und kein Budget für tiefere Integration gibt. Ich behandle es aber als Brücke, nicht als architektonisches Fundament. Ein SAP-Support-Package, ein Update des Terminalemulators, eine verschobene Feldposition oder eine geänderte Feldbezeichnung kann viele Bots gleichzeitig zerstören – häufig ohne Vorwarnung.
Je mehr Abläufe von Selektoren auf Bildschirmebene, OCR und Tastaturnavigation abhängen, desto höher wird die Wartungslast. Nutzen Sie UI-Automatisierung für kurzfristigen Nutzen, dokumentieren Sie ihre technischen Schulden aber ab dem ersten Tag. Jedes Projekt braucht einen Exit-Plan – etwa den Wechsel zu SAP GUI Scripting, CDC, APIs oder Ersatzdiensten, sobald diese Optionen verfügbar sind.
Fehler 3: Auf die Inventarisierung der Datenformate verzichten
Integrationsteams gehen oft davon aus, dass Legacy-Daten mit moderner Automatisierungs-Middleware ohne Weiteres kompatibel sind. In der Praxis nutzen Legacy-Systeme möglicherweise Kodierungen jenseits von UTF-8, inkonsistente Datumsformate, mehrfach belegte Felder, Datensätze mit fester Satzlänge und Schemata, die ohne Dokumentation gewachsen sind. Ein Wert, der in einem System gültig aussieht, kann im anderen falsch gelesen oder abgewiesen werden.
Probleme bei der Datentransformation verursachen einen erheblichen Anteil der Fehlschläge in Legacy-Integrationsprojekten, häufig auf 35 bis 50 Prozent geschätzt. Ich beginne mit einem Inventar der Datenformate: Feldbeschreibungen, Kodierungen, Null-Regeln, Datums- und Währungsformate, Identifikatoren und bekannte Ausnahmen. Diese Arbeit ist weniger sichtbar als der Bau eines Bots, verhindert aber Produktionsfehler, die sich später schwer zurückverfolgen lassen.
Fehler 4: Zeitbedarf für Datenbankzugriff unterschätzen
CDC-basierte Automatisierung setzt Leserechte auf die Transaktionsprotokolle der Datenbank voraus – diesen Zugriff zu bekommen, ist selten eine schnelle technische Aufgabe. In regulierten Unternehmensumgebungen müssen unter Umständen Sicherheitsteams, Datenbankadministratoren, Compliance-Verantwortliche und Anwendungsteams zustimmen. Diese Prüfungen dauern regelmäßig 6 bis 10 Wochen, besonders bei Produktivsystemen mit sensiblen Daten.
Teams entwerfen ihre Lösung häufig um CDC herum und stellen erst danach fest, dass der Log-Zugriff eingeschränkt, nicht verfügbar oder nur mit zusätzlicher Infrastruktur möglich ist. Ich empfehle, die Zugriffsanforderungen in der Discovery-Phase zu validieren, nicht nach der Architekturfreigabe. Nehmen Sie Vorlaufzeiten für Genehmigungen, Sicherheitsprüfungen und Replikationstests in den Projektplan auf, statt sie als Nebensache zu behandeln.
Fehler 5: Auf einem undokumentierten Monolithen bauen, ohne Exit-Plan
Einen Automatisierungsmonolithen um undokumentierte Legacy-Logik zu bauen, beseitigt keine technischen Schulden – es schafft eine weitere Schicht davon. Versteht niemand die Abhängigkeiten, Datenregeln, Batch-Jobs und Fehlermodi des Systems, erbt die Automatisierung dieselbe Fragilität wie die Anwendung, die sie umhüllt. Mit der Zeit kann jede Legacy-Änderung Anpassungen sowohl am Monolithen als auch am Automatisierungslayer erfordern.
Bevor ich stark investiere, suche ich nach einem realistischen Modernisierungspfad: CDC für verlässliche Ereignisse, eine API-Fassade oder eine Roadmap nach dem Strangler-Fig-Muster. Ziel ist nicht nur, den heutigen Prozess schneller zu machen, sondern zu vermeiden, dass sich die Organisation morgen in einer noch schwerer wartbaren Architektur wiederfindet.
Wichtigste Erkenntnisse
- Vier Muster funktionieren, wenn keine saubere API vorhanden ist: UI-Scraping (schnell, aber fragil, 6–10 Wochen) und CDC-Event-Streaming über Debezium und Apache Kafka (stabil, 3–5 Monate). Eine Read-only-Shadow-Datenbank (risikoarm, 6–12 Wochen) und das Strangler-Fig-Muster (langfristig, 12–24 Monate) vervollständigen die Liste.
- Dokumentieren Sie jede Prozessvariante in BPMN, inventarisieren Sie jedes Datenformat und kartieren Sie jeden Ausnahmepfad, bevor irgendein Automatisierungswerkzeug ausgerollt wird. Dieser Schritt zu überspringen ist die häufigste Ursache für Projektabbrüche.
- UI-Scraping mit UiPath oder Automation Anywhere auf Legacy-Masken ist eine brauchbare Brücke, sollte aber als temporär gelten. Planen Sie den Ausstieg zu einem stabileren Muster vom ersten Tag an.
- Realistische Zeitpläne: bis zur Produktion 4 bis 5 Monate für UI-Scraping-Automatisierung, 6 bis 9 Monate für CDC-basierte Event-Integration und 6 bis 12 Monate bis zum ersten Strangler-Fig-Meilenstein.
- Die meisten Legacy-Automatisierungsprojekte scheitern in den ersten sechs Wochen – bei Scoping und Dokumentation, nicht auf der Integrationsschicht.
Fazit
Keines der vier Muster ist grundsätzlich besser. Die richtige Wahl hängt davon ab, worauf Sie Zugriff haben – Datenbankprotokolle, ein Netzwerk-Gateway oder nur den Bildschirm – und wie viel Zeit Sie haben. Beim Aufbau intelligenter Automatisierung auf Legacy-Systemen fahren die meisten Unternehmen zwei Muster parallel: eine schnelle Brücke für unmittelbare Erfolge und darunter ein langsameres, dauerhafteres Fundament.
Die Teams, die Erfolg haben, behandeln Dokumentation als Phase Null, nicht als Nachgedanken. Sie planen Zeit für Genehmigungen der Datenbankadministratoren, für die Kartierung von Ausnahmen und für Formatinventare ein, bevor ein einziger Bot in Produktion geht. Diese Disziplin unterscheidet – mehr als jedes einzelne Werkzeug – einen Rollout über sechs Monate von einem Projekt, das nach achtzehn Monaten immer noch nicht fertig ist.
Wenn Sie einen Rollout planen und eine zweite Meinung zur Musterwahl wollen, lohnt sich dieses Gespräch, bevor Werkzeuge eingekauft werden. Unsere Umsetzung beginnt mit einer zweiwöchigen technischen Bewertung Ihres konkreten Legacy-Stacks, nicht mit einem allgemeinen Rezept. Wie eine saubere Integrationsschicht aussieht, zeigt unsere Backend-Entwicklung.
FAQ
Was ist intelligente Automatisierung auf Legacy-Systemen?
Intelligente Automatisierung verbindet RPA, KI und Integration für Plattformen wie IBM z/OS, SAP ECC und AS/400. Anders als moderne Automatisierung muss sie die Grenzen des Legacy-Systems über CDC, einen API-Wrapper oder das Strangler-Fig-Muster umgehen. Die zentralen Schichten sind Integrationsoberfläche, Prozessautomatisierung und Ausnahmebehandlung. UiPath und Automation Anywhere sind gängige Werkzeuge.
Lässt sich RPA auf Legacy-Systemen ohne API einsetzen?
Ja. UiPath, Automation Anywhere und Blue Prism können UI-Scraping, OCR und Attended Automation mit einem IBM-3270-Terminalemulator nutzen. Die SAP GUI Scripting API ist verlässlicher als das Abgreifen von SAP-Masken. Für Proofs of Concept ist der Ansatz geeignet, für hohe Volumina oder kritische Prozesse riskant.
Was ist das Strangler-Fig-Muster in der Legacy-Automatisierung?
Es ersetzt einen Monolithen schrittweise, statt ihn in einem Zug neu zu bauen. Eine Fassade oder ein API-Gateway – etwa Kong oder AWS API Gateway – wird vor das Altsystem gestellt; neue Funktionen entstehen als eigene Dienste, und der Verkehr wird über Feature Toggles oder ereignisgesteuertes Routing umgelenkt. Die erste Funktion braucht typischerweise drei bis vier Monate, die vollständige Modernisierung 12 bis 24 Monate.
Was ist Change Data Capture und wie hilft es bei der Legacy-Automatisierung?
CDC liest das Write-Ahead-Log oder Redo-Logs, um Datenbankänderungen als Ereignisstrom bereitzustellen. Debezium, Oracle GoldenGate, SQL Server CDC, Kafka Connect und AWS DMS publizieren Ereignisse, auch aus IBM DB2. Zu den Grenzen zählen der Datenbankzugriff, Schemaänderungen und Einschränkungen bei DB2 for i. Typische Einführungsdauer: 6 bis 9 Monate.
Wie lange dauert die Einführung intelligenter Automatisierung auf einem Legacy-System?
Typische Zeitpläne: UI-Automatisierung mit UiPath oder der SAP GUI Scripting API 4 bis 5 Monate, eine Shadow-Datenbank 3 bis 5 Monate, CDC mit Debezium/Kafka oder Oracle GoldenGate 6 bis 9 Monate und der erste Strangler-Fig-Meilenstein 6 bis 12 Monate. BPMN-Kartierung, Datenbankgenehmigungen, Ausnahmen und Lizenzen verzögern die Lieferung häufig.
Was unterscheidet RPA von intelligenter Automatisierung bei Legacy-Systemen?
RPA-Werkzeuge wie UiPath, Automation Anywhere und Blue Prism führen deterministische Schritte auf strukturierten Daten aus. Intelligente Automatisierung ergänzt das um Werkzeuge wie UiPath Document Understanding oder ABBYY, um LLM-APIs sowie um Process Mining mit Celonis oder UiPath Process Mining – für Rechnungen, E-Mails und die Weiterleitung von Ausnahmen.
Sprechen Sie unser Team an und erhalten Sie 25 % Rabatt auf Ihr erstes Projekt mit Elinext.
