Warum scheitern Automatisierungsprojekte häufig an Schnittstellen?

Automatisierungsprojekte scheitern häufig an Systemübergängen, wenn Datenhoheit, Feldbedeutungen, Fehlerbehandlung und Zuständigkeiten ungeklärt bleiben. An den Übergängen zwischen ERP-System, Dokumentenmanagement, Fachanwendung und Workflow treffen unterschiedliche Datenmodelle und Verantwortungsbereiche aufeinander. Im Angebot bilden diese Übergänge meist nur einen kleinen Posten, tragen jedoch einen erheblichen Teil des Projektrisikos. Erfolgreiche Automatisierung erfordert deshalb eine fachlich und organisatorisch geplante Systemintegration.

Eine Schnittstelle übermittelt Daten zwischen Systemen. Beide Seiten müssen die Informationen jedoch fachlich gleich interpretieren. Zudem muss feststehen, welches System Daten anlegt, verändert und im Konfliktfall als maßgeblich behandelt.
Die Schnittstellen für die Automatisierung liegen damit an einer kritischen Stelle des Gesamtprozesses. Beispielsweise verwaltet ein Dokumentenmanagementsystem Rechnungen und Prüfstatus, das ERP-System dagegen Kreditoren, Sachkonten, Kostenstellen und Buchungen. Der Ablauf funktioniert nur mit einheitlichen fachlichen Regeln und einem nachvollziehbaren Datenaustausch.
Viele Projektpläne behandeln diese Übergänge hauptsächlich als technische Aufgabe. Eine erfolgreiche Testübertragung reicht jedoch nicht aus. Im Betrieb ändern sich Stammdaten, Pflichtfelder bleiben leer oder ein System interpretiert einen Feldinhalt anders. Automatisierungsprojekte benötigen deshalb vor der Umsetzung ein gemeinsames fachliches Datenmodell.

Zu Beginn muss feststehen, welches System Kreditoren, Sachkonten, Kostenstellen, Zahlungsbedingungen und Bearbeitungsstatus federführend verwaltet. Unabhängige Änderungen in mehreren Systemen können den Prozess blockieren oder falsche Ergebnisse auslösen.
Die Entscheidung über die Datenhoheit ist keine reine IT-Frage. Einkauf, Buchhaltung, Controlling und Fachabteilungen müssen gemeinsam bestimmen, wo Daten gepflegt werden und welche Regeln für Änderungen gelten. Erst danach kann die technische Systemintegration im Mittelstand diese Festlegungen zuverlässig abbilden.
Ein Beispiel verdeutlicht das Risiko: Ein vorgelagertes System ermittelt anhand der Rechnung einen neuen Kreditor, das ERP akzeptiert jedoch nur zentral geprüfte Datensätze. Eine ungeprüfte Anlage umgeht die fachliche Freigabe. Eine kommentarlose Ablehnung stoppt die Rechnung. Daher muss feststehen, welche Stelle den Kreditor prüft, welches System ihn anlegt und wie der Prozess bis zur Freigabe weiterläuft.

Auch vertraute Begriffe sind nicht immer eindeutig. Das Feld „Belegdatum“ kann Rechnungs-, Eingangs- oder Buchungsdatum meinen. Technisch lassen sich alle Werte als Datum übertragen, weshalb eine einfache Prüfung den Bedeutungsunterschied möglicherweise nicht erkennt.
Erst spätere Auswertungen machen den Fehler sichtbar. Ein Bericht zu Bearbeitungszeiten liefert falsche Ergebnisse, wenn er das Rechnungsdatum als Eingangsdatum verwendet. Deshalb müssen die Beteiligten für jedes relevante Feld Bedeutung, Format und zulässige Werte dokumentieren.
Eine belastbare ERP-Integration im Mittelstand prüft daher nicht allein, ob ein Feld technisch befüllt ist. Sie berücksichtigt auch, ob der Inhalt zur vorgesehenen Verwendung passt. Diese fachliche Zuordnung bildet die Grundlage für verlässliche Buchungen und Auswertungen.

Im Projekt konzentriert sich die Aufmerksamkeit häufig auf den fehlerfreien Standardfall. Eine Rechnung durchläuft die Prüfung, die Schnittstelle übermittelt die Daten und das ERP bestätigt die Buchung. Im Alltag treten jedoch Verbindungsabbrüche, Zeitüberschreitungen, abgelehnte Datensätze und doppelte Übertragungsversuche auf. Ohne festgelegte Reaktion bleibt unklar, ob der Vorgang erneut gesendet, manuell geprüft oder vollständig zurückgesetzt werden muss.
Ein Fehlerkonzept beantwortet deshalb bereits vor dem Produktivstart zentrale Fragen:

• Verbindungsabbruch: Das System muss erkennen, ob die Übertragung vollständig, teilweise oder gar nicht erfolgt ist.
• Doppelbuchung: Eine eindeutige Vorgangskennung muss verhindern, dass ein erneuter Versand denselben Geschäftsvorfall zweimal bucht.
• Ablehnung: Die Rückmeldung muss den fachlichen oder technischen Grund verständlich benennen und an die zuständige Stelle gelangen.
• Wiederholung: Festgelegte Regeln bestimmen, welche Fehler das System automatisch erneut verarbeitet und wann ein Mensch eingreift.
• Nachvollziehbarkeit: Protokolle müssen erkennen lassen, welche Daten zu welchem Zeitpunkt übertragen, verändert oder abgelehnt wurden.

Diese Regeln sind für die Schnittstellen und ihre Wartbarkeit ebenso wichtig wie für den ersten Projektstart. Ohne verständliche Rückmeldungen müssen Fachabteilungen und IT bei jeder Störung mühsam rekonstruieren, was geschehen ist. Das verlängert Ausfallzeiten und erhöht das Risiko manueller Korrekturen.

Bei Systemen verschiedener Anbieter betrachtet jeder Dienstleister häufig nur den eigenen Bereich. System A hat gesendet, System B hat die Daten nicht verarbeitet und beide Seiten melden einen technisch korrekten Zustand. Der Geschäftsprozess bleibt trotzdem unterbrochen.
Eine klare Gesamtverantwortung verhindert solche Zuständigkeitslücken. Diese Stelle betrachtet die Schnittstelle über beide Systemgrenzen hinweg, koordiniert die Fehleranalyse und hält Dokumentation sowie Ansprechpartner aktuell. Sie entscheidet auch, welche Änderungen getestet werden müssen, wenn ein System ein Update erhält oder sich fachliche Anforderungen ändern.
Eine dauerhaft wartbare Anbindung benötigt dokumentierte Datenfelder, Versionen, Abhängigkeiten, Fehlercodes und Wiederanlaufverfahren. Dadurch bleibt die Integration auch nach einem Personalwechsel, Systemupdate oder Prozessumbau nachvollziehbar.

Im Mittelstand ist die Systemlandschaft häufig heterogen: ERP, DMS, Finanzanwendung, E-Mail, Portale und Fachanwendungen folgen unterschiedlichen Datenstrukturen. Eine vollständige Neuimplementierung kommt meist nicht infrage. Unternehmen müssen daher vorhandene Systeme in einen gemeinsamen Prozess einbeziehen und Insellösungen vermeiden.
Eine tragfähige Integrationsarchitektur berücksichtigt drei Bereiche:

1. Prozessbezug: Der Grundsatz Prozessintegration statt Punkt-zu-Punkt-Anbindungen betrachtet den vollständigen Geschäftsvorgang einschließlich Statusmeldungen und Fehlerbehandlung.
2. Datenaustausch: Die Datenintegration zwischen ERP und DMS umfasst Belegdaten, Buchungsinformationen, Freigabestatus, Fehlermeldungen und Archivverweise.
3. Erweiterbarkeit: Eine API-Integration stellt standardisierte Zugriffe auf Daten und Funktionen bereit. Beim Ansatz API-first werden die benötigten APIs und Datenstrukturen bereits vor oder parallel zur Systemumsetzung definiert.

Standardisierte Übergaben, eine zentrale Dokumentation und klar geregelte Zuständigkeiten erleichtern spätere Anpassungen an weitere Belegarten, Gesellschaften, Standorte und Systemversionen.

IBS ITsolutions betrachtet Systemübergänge als festen Bestandteil des gesamten Belegprozesses. Die Planung beginnt bei den fachlichen Abläufen, Datenquellen und Zuständigkeiten. Darauf aufbauend legt der Digitalisierungspartner Datenhoheit, Feldbedeutungen, Übergabepunkte, Statusmeldungen und Fehlerwege gemeinsam mit den beteiligten Fachbereichen fest.
Der Ansatz berücksichtigt Integration als Standardfall. Dokumentierte Übergänge, definierte Verantwortlichkeiten und eine geplante Fehlerbehandlung begleiten die Umsetzung von Beginn an. Der Digitalisierungspartner bezieht vorhandene ERP-, DMS- und Finance-Systeme ein und richtet die technische Umsetzung am tatsächlichen Geschäftsprozess aus. Dadurch bleibt die Automatisierung auch bei Abweichungen, Systemänderungen und wachsendem Belegvolumen steuerbar.