Montagmorgen im Finance-Team: Das ERP läuft stabil, die Buchhaltung liefert verlässliche 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 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 Modernisierungsstrategie verbindet deshalb Architektur, Prozessdesign, Governance und Fähigkeiten im Unternehmen.
Warum Legacy-Systeme Ihre KI-Pläne 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 den nächsten Prozessschritt anstoßen. Der Wunsch ist verständlich. In der Praxis findet die KI aber keinen verlässlichen Datenfluss vor.
Das ERP kennt den Auftrag, DATEV die Buchung, das CRM den Kundenkontakt, und eine Branchensoftware enthält die operative Zusatzinformation. Dazwischen liegen manuelle Exporte, alte Dateiablagen und individuelle Excel-Logik. Oft weiß 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 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.
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, ergänzt um eine konkrete System- und Prozessanalyse.
Was in der Produktion nicht funktioniert, ist ein Big Bang aus neuem ERP, neuer Datenplattform und neuen Agenten zur gleichen Zeit. Das bindet Fachkräfte, vergrößert 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.
Wo österreichische Unternehmen stehen
Österreichs Unternehmen stehen nicht am Anfang der Digitalisierung, aber die Reife ist ungleich verteilt. Laut Statistik Austria erreichten 2025 73 % der kleinen und mittleren Unternehmen zumindest ein grundlegendes Digitalisierungsniveau. Das EU-Ziel für 2030 liegt bei 90 %. Kleine Unternehmen mit 10 bis 49 Beschäftigten lagen bei 71 %, große Unternehmen bei 98 %. Die Produktionswirtschaft kam auf 67 %, der Dienstleistungsbereich auf 77 %.
Bei KI zeigt sich ein ähnliches Gefälle. 2025 nutzten 30 % der Unternehmen mit mindestens zehn Beschäftigten KI-Technologien, im Produzierenden Bereich 24,1 %, im Dienstleistungsbereich 32,6 %, wie die Publikation IKT-Einsatz in Unternehmen 2025 zeigt.
Zwischen Grundreife und echter Prozessfähigkeit
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. 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.
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.
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 von 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 spielen in unterschiedlichen Unternehmen sehr verschiedene Rollen. Ein funktionierendes ERP mit stabiler Buchungslogik muss nicht automatisch ersetzt werden. Ein weniger sichtbares Zusatztool kann dagegen der größere 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. Das Ergebnis ist eine priorisierte Systemkarte. 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 | Eignung für den Mittelstand |
|---|---|---|---|---|
| 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äßig belastet. Es scheitert aber oft an unterschätzten Sonderregeln. Die neue Anwendung bildet den Standardprozess sauber ab, während die tatsächliche Organisation auf über 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.
Eine MCP-Schicht ergänzt diese Connectoren um einen einheitlichen Rahmen für Tools, Identitäten, Richtlinien, Protokollierung und Modellzugriff. So entsteht keine lose Sammlung einzelner KI-Skripte, sondern 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 schrittweiser Weg belastbarer, weil er Lernen und Wertlieferung verbindet.
Schrittweise Migration mit KI-Connectoren und MCP-Schicht
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. Wie KI konkret mit dem ERP zusammenarbeitet, beschreibt der Beitrag KI in ERP-Systemen.
Custom Connectoren mit klaren Grenzen
Bauen Sie zuerst einen 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.
Zwei technische Details entscheiden dabei oft über die Stabilität. Erstens die Authentifizierung: Der Connector arbeitet mit einem eigenen, eng berechtigten Service-Konto oder einem delegierten Zugriff über OAuth2, SAML oder Zertifikate, nicht mit dem persönlichen Login eines Mitarbeiters. Zweitens die Idempotenz: Schreibende Aufrufe müssen so gebaut sein, dass eine Wiederholung nach einem Timeout keine doppelte Buchung oder zweite Bestellung erzeugt, etwa über eindeutige Vorgangsschlüssel.
Danach wird die MCP-Schicht als Governance-Ebene eingeführt. Sie kontrolliert, welche Modelle und Agenten welche Tools verwenden dürfen, trennt Rollen, protokolliert Aufrufe, erzwingt Freigaben und macht nachvollziehbar, ob eine Antwort aus einem ERP, CRM oder Dokument stammt.
Ein Enterprise-Automation-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, Zugriffsrichtlinien, Protokollierung und Modellwahl festlegen.
- Pilotbetrieb: Agenten zunächst mit menschlicher Freigabe und klarer Rückfallroute einsetzen.
- Schrittweise Umstellung: 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.
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 die MCP-Schicht 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?
Kompetenz aufbauen statt Abhängigkeit einkaufen
Modernisierung braucht Trainings-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.
Der Bedarf ist groß: Laut dem WU-Report Austria's AI Workforce 2026 beschäftigen 97 % der österreichischen Unternehmen keine KI-Spezialisten. Für Legacy-Projekte heißt das: Der Kompetenzaufbau ist kein Nebenprojekt, sondern Teil 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 die MCP-Schicht, definieren Sie Protokollierung und Freigaben und setzen Sie einen internen Agenten unter menschlicher Kontrolle ein. Bewerten Sie danach nicht nur die technische Funktion, sondern auch Akzeptanz, Prozessqualität, Auditierbarkeit und den Aufwand für den laufenden Betrieb.
Für den Anfang 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.
Sprechen Sie mit uns
Wenn Sie Ihren Modernisierungspfad an einem konkreten Prozess besprechen und den ersten Connector sauber definieren wollen, sprechen Sie mit uns.