Wie lässt sich Automatisierungssoftware in bestehende Systeme integrieren?

Automatisierungssoftware lässt sich in bestehende Systeme integrieren, indem vorhandene Prozesse und Datenflüsse zuerst dokumentiert, dann über definierte Schnittstellen angebunden und schließlich in kleinen, messbaren Ausbaustufen produktiv gesetzt werden. Der technische Anschluss an ERP, MES, CAQ, DMS oder QMS ist dabei nur ein Teil der Aufgabe. Entscheidend ist, ob Freigaben, Verantwortlichkeiten und Nachweise nach der Automatisierung noch genauso belastbar sind wie vorher.

In der Praxis scheitern Integrationsvorhaben selten an der Software. Sie scheitern daran, dass ein Prozess nie eindeutig beschrieben war, dass Stammdaten in drei Systemen unterschiedlich gepflegt werden oder dass niemand festgelegt hat, wer eine automatisch erzeugte Abweichung bewertet. Wer Automatisierung als bereichsübergreifendes Veränderungsvorhaben plant und nicht als Softwareinstallation, vermeidet die häufigste Folge halbherziger Projekte: neue Medienbrüche zwischen Systemen, die eigentlich verbunden werden sollten.

Der folgende Leitfaden beschreibt das Vorgehen, das sich in Industrieprojekten bewährt hat: von der Zieldefinition über die Analyse der Systemlandschaft bis zum überwachten Betrieb. Der Blick bleibt dabei auf qualitätskritischen Prozessen, in denen Auditierbarkeit und Rückverfolgbarkeit nicht verhandelbar sind.

Das Wichtigste in Kürze: Klare, messbare Integrationsziele entscheiden früher über den Projekterfolg als die Toolauswahl. Ohne dokumentierte Prozesse, saubere Stammdaten und definierte Schnittstellen entstehen automatisierte Fehler statt automatisierter Abläufe. Schrittweise Einführung, klare Verantwortlichkeiten und laufendes Monitoring halten Automatisierungen dauerhaft stabil und auditfähig.

Bevor eine Schnittstelle programmiert wird, lohnt der nüchterne Blick auf den Ist-Zustand. Die erste Frage lautet nicht, welches Tool passt, sondern ob der betroffene Prozess überhaupt eindeutig beschrieben ist. Wo Mitarbeitende auf die Frage nach dem Ablauf einer Reklamationsbearbeitung drei verschiedene Antworten geben, automatisiert man Uneinigkeit.

Bewährt hat sich eine kurze Bestandsaufnahme entlang von vier Punkten:

• Prozessklarheit: Sind Auslöser, Entscheidungspunkte, Freigaben und Ausnahmen dokumentiert?
• Datenlage: Woher kommen die benötigten Daten, wie oft entstehen sie und wer pflegt sie?
• Schmerzpunkt: Wo entstehen heute Mehrarbeit, Doppelerfassung, Wartezeiten oder Fehler?
• Nachweispflichten: Welche Anforderungen aus ISO 9001, IATF 16949, ISO 13485 oder Kundenvorgaben betreffen den Prozess?

Ziele sollten sich in Zahlen ausdrücken lassen. "Weniger Papier" ist kein Ziel. "Prüfergebnisse aus der Fertigung erscheinen ohne manuelle Nacherfassung im CAQ-System, Durchlaufzeit von der Messung bis zur Freigabemeldung unter 15 Minuten" ist eines. Solche Formulierungen erlauben später eine ehrliche Bewertung.

Zieldimension	Beispielhafte Messgröße
Effizienz	Bearbeitungszeit pro Vorgang, Anzahl manueller Eingaben
Qualität	Fehlerquote bei der Datenübernahme, Zahl der Nacharbeiten
Transparenz	Zeit bis zur Verfügbarkeit einer Kennzahl
Auditfähigkeit	Vollständigkeit der Änderungshistorie, Nachweisaufwand pro Audit

Ebenso wichtig: die Grenzen benennen. Manche Prozesse sind zu selten oder zu variantenreich, um eine Automatisierung wirtschaftlich zu rechtfertigen. Diese Entscheidung früh zu treffen, spart mehr Geld als jede Lizenzverhandlung.

Systemlandschaft, Prozesse und Schnittstellen analysieren

Gewachsene IT-Landschaften in produzierenden Unternehmen sehen selten so aus wie das Architekturdiagramm im Intranet. Typisch sind ein ERP-System als Datenherz, ein MES für Fertigungsaufträge, ein CAQ-System für Prüfpläne und Reklamationen, ein DMS für Dokumente und Freigaben, dazu Excel-Dateien, Access-Datenbanken und Maschinensteuerungen mit eigenen Exportformaten. Genau diese Zwischenschichten verursachen den Aufwand.

Die Analyse beginnt mit einer Inventur: Welche Systeme existieren, welche Version läuft, wer ist fachlich und technisch verantwortlich, welche Schnittstellen bestehen bereits? Anschließend werden die Datenflüsse entlang eines konkreten Prozesses aufgenommen, nicht abstrakt, sondern am realen Vorgang. In Wertstromanalysen zeigt sich dabei regelmäßig, dass dieselbe Information vier bis fünf Mal erfasst wird, oft mit leichten Abweichungen.

Besonders aufschlussreich sind drei Fragen an jeder Systemgrenze:

1. Wer ist der führende Datenhalter? Ohne diese Festlegung entstehen widersprüchliche Wahrheiten.
2. Wie wird übertragen? REST-API, Datenbankzugriff, Dateiexport, manuelle Übertragung?
3. Was passiert im Fehlerfall? Wird ein Abbruch bemerkt oder läuft der Prozess still weiter?

Für die Bewertung hilft eine einfache Matrix aus Datenqualität, technischer Anbindbarkeit und Prozesskritikalität. Systeme mit hoher Kritikalität und schlechter Anbindbarkeit sind die eigentlichen Engpässe. Ältere Maschinensteuerungen ohne dokumentierte Schnittstelle gehören meist dazu, ebenso Altsysteme, deren Hersteller keinen Support mehr leistet.

Aus der Analyse entsteht ein Schnittstellenkatalog: Quelle, Ziel, Datenobjekte, Feldzuordnung, Übertragungsfrequenz, Fehlerbehandlung, Verantwortlicher. Dieses Dokument ist später die Grundlage für Tests, Abnahme und Auditnachweise. Wer es sich spart, baut zweimal.

Passende Integrationsarchitektur und Automatisierungsgrade wählen

Erst nach der Analyse fällt die Architekturentscheidung. Sie hat langfristige Folgen, weil sie bestimmt, wie viel Aufwand jede künftige Anbindung kostet.

Die gängigen Muster unterscheiden sich deutlich in Aufwand und Beherrschbarkeit:

Ansatz	Passend für	Grenzen
Punkt-zu-Punkt-Schnittstelle	Zwei stabile Systeme, klarer Datenfluss	Bei mehr als drei bis vier Systemen entsteht ein unwartbares Geflecht
Middleware oder Integrationsplattform	Heterogene Landschaft mit mehreren Konsumenten derselben Daten	Zusätzliche Komponente, die Betrieb und Know-how erfordert
API-first mit Service-Schicht	Systeme mit dokumentierten Schnittstellen, wachsende Anforderungen	Setzt moderne Systemversionen und interne Entwicklungskompetenz voraus
Robotic Process Automation	Altsysteme ohne Schnittstelle, kurzfristige Überbrückung	Bricht bei Oberflächenänderungen, schwer auditierbar
Ereignisgetriebene Kopplung	Fertigungsnahe Prozesse mit hoher Taktung	Anspruchsvolles Monitoring und Fehlerhandling

RPA verdient eine nüchterne Einordnung: Als Brücke zu einem Altsystem, das in zwei Jahren ersetzt wird, ist es sinnvoll. Als Dauerlösung in einem qualitätskritischen Freigabeprozess ist es riskant, weil die Nachvollziehbarkeit der Verarbeitungslogik leidet.

Ebenso wichtig wie die Architektur ist der Automatisierungsgrad je Prozessschritt. Nicht jeder Schritt gehört vollautomatisiert. In der Praxis bewährt sich eine Abstufung: Daten sammeln und aufbereiten vollautomatisch, Bewertung und Freigabe mit menschlicher Entscheidung, Dokumentation und Weitergabe wieder automatisch. Bei Reklamationen, Sperrentscheidungen oder Änderungsfreigaben bleibt die fachliche Bewertung bewusst beim Menschen, das System liefert die Grundlage und protokolliert die Entscheidung.

Ein Kriterium, das oft zu spät auftaucht: Kann die Lösung papierlose Qualitätssicherung durchgängig abbilden, oder erzeugt sie an einer Stelle wieder einen Ausdruck mit Unterschrift? Genau dort entstehen die neuen Medienbrüche, die man eigentlich abschaffen wollte.

Datenqualität, IT-Sicherheit und Compliance absichern

Automatisierung verstärkt vorhandene Datenprobleme. Was ein Mitarbeiter beim Blick auf eine Liste stillschweigend korrigiert, übernimmt eine Schnittstelle unverändert und verteilt es in vier Zielsysteme. Deshalb gehört die Stammdatenbereinigung vor die Inbetriebnahme, nicht danach.

Bewährt haben sich Prüfungen an drei Stellen: an der Erfassung, an der Schnittstelle und im Zielsystem. Konkret bedeutet das Pflichtfelder und Wertelisten statt Freitext, Plausibilitätsregeln beim Übertragen (Toleranzgrenzen, Formatprüfungen, Dublettenerkennung) und regelmäßige Abgleiche zwischen führendem und empfangendem System. Fehlerhafte Datensätze landen in einer Quarantäne mit klarer Zuständigkeit, nicht in einem Log, das niemand liest.

Sicherheitsseitig zählen die Grundlagen mehr als Spezialwerkzeuge:

• Technische Benutzer mit minimalen Rechten je Schnittstelle, keine Sammelkonten mit Vollzugriff
• Verschlüsselte Übertragung und Schlüsselverwaltung mit dokumentierter Rotation
• Netzsegmentierung zwischen Office-IT und Fertigungsnetz, besonders bei MES-Anbindungen
• Rollenkonzept, das Freigabeberechtigungen aus dem QMS sauber abbildet
• Protokollierung aller automatisierten Änderungen mit Zeitstempel und auslösendem Ereignis

Regulatorisch wird es dort anspruchsvoll, wo automatisierte Verarbeitung qualitätsrelevante Aufzeichnungen erzeugt. Für ISO 9001 und IATF 16949 muss nachweisbar sein, wer welche Freigabe erteilt hat und auf welcher Datenbasis. In der Medizintechnik nach ISO 13485 kommt die Validierung der eingesetzten Software hinzu, inklusive dokumentierter Testfälle und Änderungskontrolle. Auch NIS2-relevante Anforderungen und Lieferkettenpflichten wirken auf Schnittstellen zu externen Partnern.

Ein praktischer Hinweis aus Auditvorbereitungen: Wer die Schnittstellenlogik und die Berechtigungsvergabe von Beginn an dokumentiert, verkürzt die Nachweisführung im Audit erheblich. Nachträgliche Rekonstruktion kostet meist mehr Zeit als die ursprüngliche Dokumentation.

Die Einführung schrittweise steuern und Mitarbeitende einbinden

Der Big-Bang-Rollout hat in gewachsenen Industrielandschaften eine schlechte Bilanz. Sinnvoll ist ein abgegrenzter Pilot: ein Prozess, eine Linie, ein Standort, eine Produktgruppe. Wichtig ist, dass der Pilot repräsentativ ist und trotzdem beherrschbar bleibt. Ein Prozess mit mittlerer Komplexität und spürbarem Schmerzpunkt eignet sich besser als der einfachste oder der kritischste.

Ein tragfähiger Ablauf umfasst folgende Stufen:

1. Konzeptabnahme: Fachbereich, IT und Qualitätsmanagement bestätigen Prozessdesign, Feldzuordnung und Verantwortlichkeiten schriftlich.
2. Testumgebung mit echten Daten: Anonymisierte Produktivdaten decken Sonderfälle auf, die Testdaten nie zeigen.
3. Parallelbetrieb: Alter und neuer Weg laufen befristet gemeinsam, Ergebnisse werden verglichen und Abweichungen geklärt.
4. Abnahme mit definierten Kriterien: Vorher festgelegte Schwellen entscheiden über die Freigabe, nicht das Bauchgefühl im Statusmeeting.
5. Kontrollierte Ausweitung: Erst nach stabilem Betrieb folgt die nächste Linie oder der nächste Standort.

Die organisatorische Seite entscheidet häufiger über den Erfolg als die technische. Ein kleines Steuerungsteam aus Prozessverantwortlichem, IT-Ansprechpartner und QM-Vertreter trifft Entscheidungen schnell und verbindlich. Schlüsselanwender aus der Fertigung sollten früh mitgestalten, denn sie kennen die Ausnahmen, die in keiner Verfahrensanweisung stehen.

Bei Schulungen zahlt sich Konkretheit aus: nicht Funktionsschulung am Bildschirm, sondern Arbeit am eigenen Vorgang mit den eigenen Daten. Ebenso wichtig ist die offene Ansprache von Sorgen. Wer erklärt, welche Tätigkeit wegfällt und welche Aufgabe an ihre Stelle tritt, erhält belastbarere Rückmeldungen als jede anonyme Umfrage. In Projekten begleiten wir bei Kontor Gruppe diese Einführungsphasen bewusst in kleinen Schritten, weil so Fehler früh sichtbar bleiben und Korrekturen bezahlbar sind.

Betrieb überwachen und Automatisierungen kontinuierlich optimieren

Mit dem Go-live beginnt die Arbeit, sie endet nicht. Automatisierte Abläufe fallen bei Störungen leise aus: Ein Zertifikat läuft ab, ein Feld wird im ERP umbenannt, ein Update ändert ein Antwortformat. Ohne Überwachung bemerkt das oft erst der Kunde.

Ein tragfähiges Monitoring deckt drei Ebenen ab. Technisch: Verfügbarkeit der Schnittstellen, Laufzeiten, Fehlerquoten, Warteschlangenlängen. Fachlich: Anzahl verarbeiteter Vorgänge, Quote manueller Eingriffe, Bestände in der Fehlerquarantäne. Wirtschaftlich: die zu Projektbeginn definierten Kennzahlen im Zeitverlauf. Jeder Alarm braucht einen benannten Empfänger und eine dokumentierte Reaktion, sonst entsteht Alarmmüdigkeit.

Bewährte Routinen im laufenden Betrieb:

• Monatlicher Kurzreview: Fehlerprotokolle und manuelle Eingriffe gemeinsam durchsehen, wiederkehrende Muster benennen.
• Ursachenanalyse statt Nachkorrektur: Häufen sich Abweichungen, hilft eine strukturierte Analyse mit Ishikawa oder den 5 Whys mehr als eine weitere Prüfregel.
• Änderungsmanagement für Schnittstellen: Jedes Update an ERP, MES oder CAQ wird auf Schnittstellenwirkung geprüft, bevor es eingespielt wird.
• Jährliche Wirksamkeitsprüfung: Passt der Automatisierungsgrad noch zum Prozess, oder haben sich Mengen und Varianten verschoben?

Interne Audits sind dafür ein gutes Instrument, wenn sie den Datenfluss prüfen und nicht nur die Dokumentenlage. Eine typische Feststellung: Ein Prozess ist automatisiert, aber die zugehörige Verfahrensanweisung beschreibt noch den alten manuellen Weg. Solche Lücken kosten im Zertifizierungsaudit unnötig Zeit.

Optimierung heißt nicht automatisch mehr Automatisierung. Manchmal ist die richtige Entscheidung, eine Regel zu vereinfachen, eine Ausnahme bewusst manuell zu lassen oder eine Schnittstelle abzuschalten, deren Nutzen den Wartungsaufwand nicht rechtfertigt. Diese Ehrlichkeit hält die Landschaft beherrschbar.