Montagmorgen im Finance-Team: Das ERP läuft stabil, die Buchhaltung liefert verlässlich Zahlen und das CRM enthält die Kundendaten. Trotzdem bleibt die neue KI-Initiative nach dem ersten Workshop stecken. Die Rechnung liegt in DATEV, der Auftrag im ERP, die Gesprächshistorie im CRM und die Freigabe in einer Excel-Datei, die niemand offiziell besitzt. Ein Sprachmodell kann Texte erzeugen, aber es kann keinen belastbaren End-to-End-Prozess steuern, solange diese Systeme nicht sicher miteinander sprechen.
Genau hier liegt der Kern einer Legacy-Modernisierung für ERP- und CRM-Systeme. Es geht nicht zuerst um einen kompletten Austausch. Es geht darum, bestehende Abläufe kontrollierbar zu verbinden, Wissen aus alten Systemen zugänglich zu machen und KI dort einzusetzen, wo sie operative Arbeit tatsächlich reduziert. Eine tragfähige Legacy Modernization Strategy verbindet deshalb Architektur, Prozessdesign, Governance und Fähigkeiten im Unternehmen.
Inhaltsverzeichnis
- Warum Legacy-Systeme Ihre KI-Strategie blockieren
- Der aktuelle Zustand der Digitalisierung im Mittelstand
- Systemlandschaft analysieren und Modernisierungsbedarf bewerten
- Modernisierungsansätze im Vergleich
- Schrittweise Migration mit KI-Connectoren und MCP-Layer
- Governance und Change Management als Erfolgsfaktoren
- Ihr 90-Tage-Fahrplan für die Legacy-Modernisierung
Warum Legacy-Systeme Ihre KI-Strategie blockieren
Ein mittelständischer Industriebetrieb möchte eingehende Bestellungen automatisch prüfen lassen. Die KI soll erkennen, ob Preise, Lieferbedingungen und Kundendaten plausibel sind, Abweichungen markieren und bei einfachen Fällen sogar den nächsten Prozessschritt anstossen. Der Wunsch ist verständlich. In der Praxis findet die KI aber keinen verlässlichen Datenfluss vor.
Das ERP kennt den Auftrag, DATEV kennt die Buchung, das CRM kennt den Kundenkontakt und eine Branchensoftware enthält die operative Zusatzinformation. Zwischen diesen Systemen liegen manuelle Exporte, alte Dateiablagen und individuelle Excel-Logik. Oft weiss nur eine langjährige Mitarbeiterin, welche Spalte vor dem Import umbenannt werden muss. Fällt sie aus, wird aus einem Automatisierungsprojekt schnell eine Rückfragekette zwischen Finance, Operations und IT.
Praktische Regel: Automatisieren Sie keinen Prozess, dessen Datenverantwortung und Übergaben niemand eindeutig benennen kann.
Der Medienbruch ist das eigentliche Problem
Viele Teams starten mit einem isolierten KI-Tool. Es fasst E-Mails zusammen, erstellt CRM-Notizen oder beantwortet interne Fragen. Der Nutzen bleibt begrenzt, wenn das Ergebnis danach wieder manuell in ein Legacy-System übertragen werden muss. Die KI hat dann zwar einen Text erzeugt, aber keinen Prozess abgeschlossen.
Besonders sichtbar wird das bei Angeboten, Auftragsänderungen, Mahnungen und Monatsabschlüssen. Ein Agent müsste Daten lesen, Regeln anwenden, Berechtigungen prüfen, eine Aktion auslösen und jeden Schritt nachvollziehbar protokollieren. Ohne Connectoren und eine kontrollierte Integrationsschicht kann er höchstens Empfehlungen liefern.
Auch kleinere Branchenlösungen zeigen, warum die Systemgrenze nicht mit der Unternehmensgrenze übereinstimmt. Wer sich mit modularer Software für Autohäuser beschäftigt, erkennt schnell, dass Verkauf, Werkstatt, Kundenkommunikation und Administration unterschiedliche Datenobjekte und Rollen verwenden. Die gleiche Logik gilt im produzierenden Mittelstand, im Handel und bei Dienstleistungsunternehmen.
Warum KI allein nicht reicht
Eine belastbare KI-Strategie beginnt deshalb nicht mit der Auswahl des Sprachmodells. Sie beginnt mit der Frage, welche Kernsysteme welche Aktionen erlauben, welche Daten als verbindlich gelten und wo ein Mensch die Entscheidung behalten muss. Der Leitfaden zur Entwicklung einer KI-Strategie ist dafür ein sinnvoller Ausgangspunkt, sofern er um eine konkrete System- und Prozessanalyse ergänzt wird.
Was in der Produktion nicht funktioniert, ist ein Big Bang aus neuem ERP, neuer Datenplattform und neuen Agents zur gleichen Zeit. Das bindet Fachkräfte, vergrössert die Abhängigkeiten und verschiebt Fehler in eine Phase, in der sie teurer werden. Funktionieren kann dagegen eine schrittweise Modernisierung, bei der zuerst ein klar abgegrenzter Prozess über einen Connector zugänglich wird.
Der aktuelle Zustand der Digitalisierung im Mittelstand
Österreichs Unternehmen stehen nicht am Anfang der Digitalisierung, aber die Reife ist ungleich verteilt. Laut Statistik Austria zur IKT-Nutzung 2023 nutzten 2023 47,0 % aller Unternehmen fortgeschrittene IKT-Technologien. 35,6 % setzten Cloud-Services ein, 23,9 % Data Analytics und 10,8 % KI. Wien lag bei fortgeschrittenen IKT-Technologien bei 55 %, während Österreich im EU-Vergleich im unteren Drittel lag.
Diese Werte beschreiben kein reines Infrastrukturproblem. Sie zeigen, dass viele ERP-, Finanz- und Prozesslandschaften noch nicht für moderne Datenflüsse, Automatisierung und KI vorbereitet sind. Eine KI-Anwendung kann nur so gut in den Betrieb eingreifen, wie die zugrunde liegenden Daten zugänglich, verständlich und berechtigt nutzbar sind.
Zwischen Grundreife und echter Prozessfähigkeit
Die österreichische Digitale Dekade 2025 berichtet, dass rund 58 % der österreichischen KMU zumindest ein grundlegendes Niveau digitaler Intensität erreichen. Zugleich verfügen nur etwas über 90 % der KMU über wenigstens ein Basisniveau digitaler Reife. Rund 36 % der Unternehmen nutzen Cloud Computing, und 72,8 % aller Haushalte haben gigabitfähigen Internetzugang.
Für die Modernisierung bedeutet das: Die technische Grundlage wächst, aber digitale Präsenz und integrierte Abläufe sind nicht dasselbe. Ein Unternehmen kann Cloud-Speicher einsetzen und trotzdem Bestellungen per Excel zwischen CRM und ERP übertragen. Es kann Online-Services anbieten und interne Freigaben weiterhin über unstrukturierte E-Mails organisieren.
Bei KI zeigt sich ein ähnliches Gefälle. Laut Statistik Austria zur IKT-Nutzung 2024 nutzten 2024 bereits 20 % der Unternehmen mit mindestens zehn Beschäftigten KI-basierte Technologien, nach 11 % im Jahr 2023. Im Dienstleistungssektor war der Einsatz stärker, während die Produktionswirtschaft bei 15 % lag.
Der Frontoffice-Vorsprung reicht nicht aus
Die Erklärung liegt häufig in der Nähe zum sichtbaren Kundennutzen. Marketing, Vertrieb und Wissensarbeit können KI schneller einsetzen, weil sie mit Texten, Anfragen und Recherche arbeiten. Operative Kernprozesse benötigen dagegen verlässliche Stammdaten, transaktionale Berechtigungen, Ausnahmen, Buchungslogik und Audit-Trails.
Der Digital-Decade-Bericht der österreichischen Bundesregierung nennt für KMU ein deutliches Abstand zum EU-Ziel: Nur zwei Drittel erreichen zumindest ein Basisniveau digitaler Intensität, während das EU-Ziel bei 90 % liegt. Cloud- und Datenanalyse-Nutzung liegen unter dem EU-Durchschnitt, für KI nennt der Bericht 10,8 %.
Warten löst diese Lücke nicht. Der sinnvollste Startpunkt ist ein begrenzter Prozess, in dem der Nutzen klar ist und die Risiken beherrschbar bleiben. KI wird dann nicht als Chat neben der Arbeit eingesetzt, sondern als kontrollierte Fähigkeit innerhalb des bestehenden Betriebs.
Systemlandschaft analysieren und Modernisierungsbedarf bewerten
Eine gute Modernisierungsentscheidung beginnt mit einer Landkarte, nicht mit einer Produktdemo. Erfassen Sie ERP, CRM, Buchhaltung, Dokumentenablage, Branchensoftware, Datenbanken, Dateiimporte und manuelle Übergaben. Entscheidend ist nicht nur, welche Systeme installiert sind, sondern welche Geschäftsentscheidung auf ihren Daten basiert.
Beginnen Sie mit vier Perspektiven:
- Geschäftsrelevanz: Welche Prozesse hängen vom System ab? Was passiert, wenn die Anwendung ausfällt oder Daten verspätet eintreffen?
- Technische Belastung: Ist die Lösung dokumentiert, testbar und wartbar? Gibt es veraltete Schnittstellen, individuelle Anpassungen oder Abhängigkeiten zu einzelnen Personen?
- Integrationsfähigkeit: Welche APIs, Exporte, Ereignisse oder Datenbankzugriffe existieren? Sind Schreibzugriffe möglich oder nur lesende Abfragen?
- KI-Eignung: Liegen die Daten strukturiert vor? Lassen sich Regeln, Berechtigungen und erwartete Ergebnisse eindeutig beschreiben?
Nicht jedes alte System ist ein schlechter Kandidat
BMD, Navision, Exact und weclapp können in unterschiedlichen Unternehmen sehr verschiedene Rollen spielen. Ein funktionierendes ERP mit stabiler Buchungslogik muss nicht automatisch ersetzt werden. Ein weniger sichtbares Zusatztool kann dagegen der grössere Engpass sein, wenn es zentrale Informationen nur als unstrukturierte Dateien weitergibt.
Bewerten Sie jedes System im Kontext des Prozesses. Fragen Sie nicht nur, ob die Software alt ist, sondern:
- Datenbesitz: Welches System ist für Kunden, Artikel, Aufträge und Buchungen verbindlich?
- Abhängigkeiten: Welche anderen Anwendungen lesen oder verändern diese Daten?
- Ausnahmen: Welche Sonderfälle werden heute manuell behandelt?
- Betriebsrisiko: Welche Änderung könnte Produktion, Lieferung, Zahlung oder Abschluss stören?
- Wissensrisiko: Welche Abläufe kennt nur eine kleine Gruppe im Unternehmen?
- Modernisierungspfad: Reicht ein Connector, braucht es eine neue Plattform oder ist eine Ablösung wirtschaftlich sinnvoller?
Eine Priorisierung, die im Betrieb standhält
Technische Schulden allein ergeben keine Reihenfolge. Priorisieren Sie dort, wo ein Prozess hohen manuellen Aufwand, klare Fehlerfolgen und einen zugänglichen Datenbestand verbindet. Ein automatisierter Statusabgleich zwischen Auftrag und Kundenkommunikation ist oft ein besserer Pilot als die komplette Erneuerung des Finanzsystems.
Dokumentieren Sie pro Kandidat das gewünschte Ergebnis, die erlaubten Aktionen, die Datenquellen, die menschlichen Freigaben und den Rückfallprozess. Ein Überblick zu Application-Intelligence-Plattformen kann bei der Einordnung helfen, ersetzt aber keine fachliche Prozessaufnahme.
Das Ergebnis sollte eine priorisierte Systemkarte sein. Sie zeigt, wo ein Connector kurzfristig Wert schafft, wo Replatforming sinnvoll erscheint und wo ein Ersatzprojekt erst nach weiterer Klärung verantwortbar wäre.
Modernisierungsansätze im Vergleich
Die vier Ansätze unterscheiden sich vor allem darin, wie stark sie den Kern eines Systems verändern. Replacement ersetzt die Anwendung. Replatforming verschiebt oder erneuert technische Schichten, ohne die Geschäftslogik vollständig neu zu bauen. Refactoring verbessert den Code und seine Struktur. Der Connector-Ansatz lässt den Kern zunächst bestehen und macht ausgewählte Daten und Aktionen über eine Integrationsschicht verfügbar.
| Ansatz | Aufwand | Risiko | Zeitrahmen | Mittelstand-Eignung |
|---|---|---|---|---|
| Replacement | Hoch, inklusive Prozess- und Datenmigration | Hoch, besonders bei vielen Sonderfällen | Langfristig | Sinnvoll, wenn das System fachlich oder technisch nicht mehr tragfähig ist |
| Replatforming | Mittel, abhängig von Infrastruktur und Schnittstellen | Mittel, da die Kernlogik bestehen bleibt | Mittelfristig | Geeignet, wenn Betrieb, Skalierung oder Wartung der Engpass sind |
| Refactoring | Mittel bis hoch, mit starkem Testbedarf | Mittel bis hoch, wenn Abhängigkeiten unklar sind | Mittelfristig | Geeignet für wertvolle Anwendungen mit beherrschbarer Codebasis |
| Connector-Ansatz | Niedrig bis mittel, fokussiert auf konkrete Prozesse | Niedriger, wenn Berechtigungen und Rückfallpfade sauber sind | Kurz- bis mittelfristig | Besonders geeignet für schrittweise KI- und Automatisierungsvorhaben |
Replacement ist nicht automatisch Fortschritt
Ein Ersatzprojekt kann richtig sein, wenn der Herstellerpfad endet, zentrale Anforderungen nicht mehr abbildbar sind oder die laufende Wartung den Betrieb unverhältnismässig belastet. Es scheitert aber oft an unterschätzten Sonderregeln. Die neue Anwendung bildet den Standardprozess sauber ab, während die tatsächliche Organisation auf Jahrzehnte gewachsene Ausnahmen angewiesen ist.
Replatforming bietet einen ruhigeren Weg, wenn Datenbank, Betriebssystem, Hosting oder API-Schicht die Einschränkung verursachen. Der Ansatz verbessert die technische Basis, löst aber keine unklaren Verantwortlichkeiten und keine schlechten Prozesse.
Refactoring eignet sich für Systeme, deren fachlicher Wert hoch ist und deren Code verstanden werden kann. Ohne Regressionstests und Domänenwissen wird es schnell zu einer teuren Umstrukturierung mit unklarem Ergebnis.
Connectoren als pragmatischer Einstieg
Der Connector-Ansatz ist stark, wenn der Kern stabil bleiben muss, aber ein konkreter Prozess moderne Fähigkeiten benötigt. Ein Connector kann beispielsweise Kundendaten aus dem CRM lesen, Auftragsinformationen aus Navision abrufen oder Buchungsstatus aus DATEV und BMD für einen kontrollierten Workflow bereitstellen. Schreibaktionen sollten zunächst begrenzt, validiert und mit Freigaben versehen werden.
Ein MCP-Layer ergänzt diese Connectoren um einen einheitlichen Rahmen für Tools, Identitäten, Policies, Protokollierung und Modellzugriff. So entsteht keine lose Sammlung einzelner KI-Skripte. Es entsteht eine erweiterbare Integrationsarchitektur, in der jedes neue Tool nach denselben Sicherheits- und Governance-Regeln behandelt wird.
Der Big Bang ist nur dann vertretbar, wenn Geschäftsführung, Fachbereiche und IT die Migration gemeinsam tragen und Daten, Prozesse sowie Rückfalloptionen ausreichend verstanden sind. In vielen Mittelstandsorganisationen ist ein inkrementeller Weg belastbarer, weil er Lernen und Wertlieferung verbindet.
Schrittweise Migration mit KI-Connectoren und MCP-Layer
Eine schrittweise Modernisierung beginnt nicht mit einem autonomen Agenten. Sie beginnt mit einem Connector für einen klar begrenzten Prozess. Das Team legt fest, welche Daten gelesen werden, welche Funktionen aufgerufen werden dürfen und an welcher Stelle ein Mensch entscheidet.
Analyse der Legacy-Schnittstellen
In der Discovery-Phase werden die realen Integrationsmöglichkeiten geprüft. Bei DATEV, BMD oder Navision können das offizielle APIs, vorhandene Exporte, Datenbankzugriffe oder bestehende Middleware sein. Entscheidend ist, nicht nur die technische Verbindung zu testen, sondern auch Semantik und Berechtigungen zu klären.
Ein guter Connector kennt die Unterschiede zwischen Kundennummer, Debitor, Auftrag und Buchungsbeleg. Er validiert Eingaben, behandelt fehlende Daten und liefert strukturierte Fehler zurück. Freitext allein ist keine belastbare Schnittstelle.
Custom Connectoren mit klaren Grenzen
Bauen Sie zuerst einen Custom Connector für den Prozess mit dem besten Verhältnis aus Nutzen, Datenzugang und Risiko. Beispiele sind die Prüfung eingehender Aufträge, die Vorbereitung einer Kundenantwort oder die Zuordnung eines Dokuments zu einem Vorgang. Der Connector sollte keine unbeschränkte Datenbankabfrage anbieten, sondern fachliche Funktionen mit definierten Ein- und Ausgaben.
Danach wird der Enterprise MCP-Layer als Governance-Schicht eingeführt. Er kontrolliert, welche Modelle und Agents welche Tools verwenden dürfen. Er trennt Rollen, protokolliert Aufrufe, erzwingt Freigaben und macht nachvollziehbar, ob eine Antwort aus einem ERP, CRM oder Dokument stammt.
Ein Enterprise-Automation-Platform-Ansatz ist besonders dann hilfreich, wenn mehrere Systeme und Teams beteiligt sind. Die Plattform darf dabei nicht zum neuen Monolithen werden. Jedes Tool braucht einen klaren Besitzer, eine dokumentierte Schnittstelle und einen definierten Lebenszyklus.
Von der Assistenz zum internen Agenten
Der erste produktive Einsatz sollte beobachtbar bleiben. Der Agent liest Daten, erstellt einen Vorschlag und legt eine prüfbare Aktion vor. Erst wenn Ergebnisse, Fehlerbilder und Ausnahmefälle verstanden sind, kann das Team bestimmte Schritte automatisieren.
Ein zuverlässiger Ablauf sieht so aus:
- Discovery: Prozess, Datenquellen, Rollen und Ausnahmefälle dokumentieren.
- Connector-Prototyp: Einen lesenden Use Case mit Testdaten und realistischen Berechtigungen umsetzen.
- MCP-Integration: Tool-Verträge, Zugriffspolitik, Protokollierung und Modellwahl festlegen.
- Pilotbetrieb: Agenten zunächst mit menschlicher Freigabe und klarer Rückfallroute einsetzen.
- Inkrementeller Cutover: Weitere Aktionen und Systeme einzeln ergänzen, ohne den gesamten Kernprozess gleichzeitig umzubauen.
Sicherheit entsteht nicht dadurch, dass ein Modell im Unternehmen betrieben wird. Sie entsteht durch minimale Rechte, geprüfte Tool-Aufrufe, getrennte Umgebungen, nachvollziehbare Logs und klare Verantwortlichkeiten. Der Agent muss jederzeit erklären können, welche Daten er verwendet und welche Aktion er vorbereitet oder ausgeführt hat.
Governance und Change Management als Erfolgsfaktoren
Technologie kann eine Schnittstelle herstellen. Sie kann aber nicht entscheiden, wer fachlich für einen Kundenstatus verantwortlich ist oder ob eine Buchung automatisch freigegeben werden darf. Diese Entscheidungen gehören in eine Governance, die Fachbereich, IT, Datenschutz, Informationssicherheit und interne Kontrolle gemeinsam tragen.
Der österreichische Länderbericht 2026 nennt Legacy-IT und fragmentierte Datenstandards als Interoperabilitätshemmnisse. Die österreichische Roadmap umfasst 85 Massnahmen mit insgesamt 4,07 Mrd. EUR, rund 0,84 % des BIP 2025. Diese Grössenordnung zeigt, dass Interoperabilität eine strukturelle Aufgabe ist, nicht nur ein einzelnes Schnittstellenprojekt.
Ownership muss im Unternehmen bleiben
Jeder Connector braucht einen technischen und einen fachlichen Owner. Der technische Owner verantwortet Betrieb, Versionierung, Tests und Sicherheitsupdates. Der fachliche Owner definiert Datenbedeutung, Freigaben und akzeptable Ergebnisse.
Für den MCP-Layer sollten mindestens diese Regeln schriftlich feststehen:
- Tool-Zugriff: Welcher Agent darf welche Funktion aufrufen?
- Datenumfang: Welche Felder sind für den konkreten Zweck notwendig?
- Freigaben: Welche Aktionen erfordern eine menschliche Bestätigung?
- Nachvollziehbarkeit: Welche Eingaben, Ergebnisse und Änderungen werden protokolliert?
- Ausnahmen: Was passiert bei fehlenden, widersprüchlichen oder veralteten Daten?
- Ablösung: Wann wird ein Tool deaktiviert oder durch eine neue Version ersetzt?
Skills statt Abhängigkeit einkaufen
Der WIFO-Bericht zur Digitalisierung der österreichischen Wirtschaft beschreibt ein gemischtes Bild, mit guten Werten in der Industrie, Schwächen im Servicesektor, niedriger Adoption in Mikro- und Kleinbetrieben und einem Bedarf an besseren ICT-Skills. Der OECD-Bericht zur KI in Deutschland nennt fehlende Fähigkeiten als wichtige Barriere für KI-Adoption.
Deshalb braucht Modernisierung Training Sprints für Führungskräfte, Engineers und Prozessverantwortliche. Teams sollten wiederholbare Pattern Playbooks erhalten, etwa für Connector-Design, Tool-Berechtigungen, Testfälle und Agentenfreigaben. Die internen Spezialisten müssen verstehen, wie die neue Architektur funktioniert, sonst bleibt das Unternehmen vom ursprünglichen Implementierungspartner abhängig.
Die State-of-AI-Austria-2026-Auswertung zeigt, dass nur 2,6 % von 123.226 österreichischen Firmen mit identifiziertem Konzernhintergrund überhaupt eine Person in einer KI-Rolle beschäftigen. 97 % haben demnach keine KI-Mitarbeitenden. Für Legacy-Projekte ist das ein klares Signal: Der Kompetenzaufbau ist kein Nebenprojekt, sondern ein Bestandteil der Zielarchitektur.
Ihr 90-Tage-Fahrplan für die Legacy-Modernisierung
Die ersten 90 Tage sollten kein Mammutprojekt starten. Sie sollten Klarheit schaffen, einen belastbaren Connector liefern und zeigen, ob ein Agent im Alltag sicher arbeiten kann.
Tage 1 bis 30
Erstellen Sie das Systeminventar, wählen Sie einen Prozess und benennen Sie fachliche sowie technische Verantwortliche. Dokumentieren Sie Datenquellen, Berechtigungen, Ausnahmefälle und den manuellen Aufwand. Das wichtigste Ergebnis ist eine priorisierte Entscheidung, nicht eine lange Analyse.
Tage 31 bis 60
Bauen Sie einen lesenden Connector für DATEV, BMD, Navision, Exact, weclapp oder das tatsächlich relevante System. Testen Sie Datenqualität, Fehlerbehandlung und Berechtigungen mit Finance und Operations. Der Pilot sollte einen konkreten Arbeitsschritt verbessern, ohne sofort produktive Schreibzugriffe zu verlangen.
Tage 61 bis 90
Integrieren Sie den Connector in den MCP-Layer, definieren Sie Protokollierung und Freigaben und setzen Sie einen internen Agenten unter menschlicher Kontrolle ein. Bewerten Sie danach nicht nur technische Funktion, sondern auch Akzeptanz, Prozessqualität, Auditierbarkeit und den Aufwand für den laufenden Betrieb.
Am Montagmorgen reicht ein erster Termin mit Finance, Operations und IT. Wählen Sie einen Prozess, bei dem alle Beteiligten den Datenfluss beschreiben können, und halten Sie fest, welche Aktion der erste Connector sicher unterstützen soll.
Specialty Tokens unterstützt Unternehmen mit eingebetteten Senior Engineers bei System- und Datenanalysen, Custom Connectoren für ERP-, CRM- und Buchhaltungssysteme sowie einem verwalteten Enterprise-MCP-Layer für sichere Agents. Besprechen Sie Ihren konkreten Modernisierungspfad und besuchen Sie Specialty Tokens, um den ersten produktionsnahen Use Case zu definieren.