AI in bestehende Finance-Systemlandschaften integrieren: Übergangsarchitekturen, Schnittstellen und Betriebsfragen nüchtern betrachtet
Ein typisches Szenario im Finance Shared Service: Das ERP-System bildet den Kern für Buchungen, Stammdaten und Standardberichte. Neue AI-Funktionen kommen meist als Ergänzung hinzu – entweder als integriertes Modul oder als externe Anwendung. Auf dem Whiteboard zeichnet das Team zunächst die heutige Landschaft: Eingänge über E-Mail, Portale oder Scans, Workflows für Freigaben, Buchungen im Kernsystem, Auswertungen im Reporting. Dann wird markiert, wo AI ansetzen soll, etwa bei der Belegerkennung in der Kreditorenbuchhaltung oder bei Vorschlägen für Kontierungen. Die zentrale Frage lautet: Wo liegen künftig welche Daten und wer ist für sie verantwortlich. Eine Variante sieht vor, dass das AI-Modul direkt an das ERP angebunden ist, Belegdaten dort abgreift und Vorschläge zurückschreibt. In diesem Fall bleibt das ERP führend, während das Modul nur temporäre Verarbeitungsschritte übernimmt. Eine andere Variante nutzt eine separate Plattform, die Belege aus unterschiedlichen Quellen sammelt, verarbeitet und Ergebnisse an mehrere Systeme verteilt. Diese Lösung bietet Flexibilität, erhöht aber die Komplexität der Datenflüsse. Für deinen Alltag entscheidend ist, dass jede Variante eine klare Zuordnung von Verantwortlichkeiten und Protokollen erhält: Wer überwacht Schnittstellen, wer pflegt Stammdaten, wie werden Fehler behandelt und wie stellst du sicher, dass bei Systemänderungen keine versteckten Abhängigkeiten übersehen werden. Erst wenn diese Fragen beantwortet sind, wird aus einer Skizze eine tragfähige Übergangsarchitektur.
Im nächsten Schritt vertieft das Team die Schnittstellenfrage. Auf dem Tisch liegen Ausdrucke mit Prozessdiagrammen, Systemlisten und bestehenden Schnittstellenbeschreibungen. Ziel ist ein einfaches Muster, das für mehrere AI-Anwendungsfälle im Finance Shared Service wiederverwendbar ist. Drei Grundtypen von Schnittstellen stehen im Raum. Erstens der klassische Batch-Import und -Export, bei dem Daten in festen Intervallen ausgetauscht werden. Er eignet sich für Szenarien, in denen Ergebnisse nicht in Echtzeit benötigt werden, etwa Analysen für Reporting oder monatliche Abstimmungen. Zweitens ereignisgesteuerte Schnittstellen, bei denen bestimmte Aktionen – wie das Eintreffen einer Rechnung – unmittelbar eine Verarbeitung auslösen. Sie sind sinnvoll, wenn Durchlaufzeiten im Tagesgeschäft relevant sind. Drittens Abfragen auf Anfragebasis, bei denen ein System bei Bedarf Vorschläge oder Bewertungen anfordert, etwa bei der Anlage neuer Stammdaten. Für jeden Typ werden konkrete Fragen notiert: Welche Daten werden übertragen, wie werden sie validiert, wie gehst du mit Fehlersituationen um, und wo werden Protokolle gespeichert. Finance steuert dabei fachliche Anforderungen bei, IT beschreibt technische Möglichkeiten und Grenzen. Das Ergebnis ist kein perfektes Integrationskonzept, sondern ein Set wiederkehrender Muster, das sich an unterschiedlichen Stellen anwenden lässt. So vermeidest du, für jeden neuen Use Case individuelle Sonderwege zu bauen, die später schwer zu warten sind.
Zum Abschluss rückt die Frage in den Fokus, wie AI-Integrationen in die bestehende Änderungssteuerung eingebettet werden. Auf einer Pinnwand hängen Karten mit laufenden und geplanten Systemänderungen: ERP-Updates, Anpassungen von Workflows, neue Schnittstellen zu Partnern, Sicherheitsanforderungen. AI-Vorhaben sind nur ein Teil dieser Liste. In der Runde sitzen Finance-Verantwortliche, IT, Vertreterinnen der internen Kontrolle und gelegentlich externe Dienstleister. Gemeinsam wird bewertet, welche Änderungen zwingend sind, welche verschiebbar und welche von anderen Projekten abhängen. Für AI-Funktionen bedeutet das: Sie müssen sich in bestehende Release-Zyklen einfügen, Testaufwände mit anderen Anpassungen teilen und Governance-Anforderungen erfüllen. Das Team diskutiert, ob eine neue AI-Unterstützung in der Kreditorenbuchhaltung im gleichen Release umgesetzt werden kann wie ein ERP-Upgrade, oder ob eine Entkopplung sinnvoller ist. Ebenso wird geklärt, wie Rückfalloptionen aussehen, falls eine Integration im Betrieb Probleme verursacht. Diese Diskussionen mögen aufwendig wirken, verhindern aber, dass AI-Lösungen als Sonderprojekte mit eigenen Regeln laufen. Stattdessen werden sie Teil der regulären Systementwicklung – mit definierten Verantwortlichkeiten, Teststufen und Dokumentationsanforderungen. So stellst du sicher, dass Automatisierung nicht nur technisch funktioniert, sondern auch langfristig in deine Finance-Systemlandschaft passt.
Wenn du AI nicht als eigenständige Insel, sondern als Baustein deiner bestehenden Finance-Systemlandschaft behandelst, werden Integrationsentscheidungen nüchterner. Statt jedem neuen Werkzeug eigene Daten, eigene Workflows und eigene Auswertungen zu überlassen, prüfst du, wie sich Funktionen in ERP, bestehende Plattformen und definierte Schnittstellen einfügen. Die Beispiele für Übergangsarchitekturen zeigen, dass es selten die perfekte Lösung gibt, wohl aber Varianten mit klaren Konsequenzen für Betrieb, Governance und Kosten. So triffst du bewusste Entscheidungen: Wo ein Satellit sinnvoll ist, wo eine Erweiterung ins Kernsystem gehört und wo du zunächst an Prozessen oder Daten arbeiten musst, bevor zusätzliche Technik wirklich trägt.