Wie Sie die Integration zweier Systeme planen

Für die erste Schätzung einer Integration brauchen Sie noch kein fertiges technisches Lastenheft. Entscheidend ist die verständliche Beschreibung eines konkreten Datenflusses: Welches Ereignis löst ihn aus, wo entstehen die Daten, wohin sollen sie gelangen, wie wird derselbe Datensatz in beiden Systemen erkannt und wer reagiert, wenn ein Vorgang fehlschlägt?

Beginnen Sie daher nicht mit dem Satz „Wir möchten zwei Systeme verbinden“, sondern mit einem überprüfbaren Ergebnis. Zum Beispiel: „Nach Eingang einer Bestellung sollen Kunden- und Positionsdaten ohne erneute Eingabe und ohne Duplikate an die Anwendung für die Auftragsabwicklung übergeben werden.“

Damit ist noch nicht entschieden, ob eine API, ein Webhook, ein regelmäßiger Dateiimport oder eine kleine Middleware die richtige Lösung ist. Die Beschreibung grenzt jedoch eine sinnvolle erste Etappe ab und zeigt, was vor einer belastbaren Schätzung geprüft werden muss.

Beginnen Sie mit einem Prozess, nicht mit dem ganzen Unternehmen

In einem Unternehmen können Onlineshop, CRM, Buchhaltung, Lagerverwaltung, ein Lieferantenportal und mehrere Tabellen parallel im Einsatz sein. Wer alle denkbaren Verbindungen auf einmal erfassen möchte, erhält schnell eine Wunschliste ohne klaren Anfang und Abschluss.

Wählen Sie für die erste Etappe einen Datenfluss, der:

• regelmäßig wiederkehrt;
• manuelle Übertragung oder wiederholte Kontrolle erfordert;
• einen erkennbaren Auslöser und ein klares Ergebnis hat;
• bei Fehlern oder Verzögerungen ein konkretes Problem verursacht;
• einer verantwortlichen Person zugeordnet ist.

Das kann die Übergabe einer Bestellung vom Shop an die Auftragsabwicklung sein, die Anlage eines CRM-Vorgangs nach dem Absenden eines Formulars oder die Rückmeldung eines Versandstatus. Ein sauber beschriebener Ablauf ist für das erste Gespräch wertvoller als der allgemeine Wunsch, die gesamte Systemlandschaft zu synchronisieren.

Wenn Sie zunächst den Umfang der Handarbeit einschätzen möchten, helfen der Beitrag Wann lohnt sich die Automatisierung manueller Dateneingabe? und der Rechner für Arbeitszeit und Automatisierungsszenarien.

Erstellen Sie eine Datenflusskarte

Dafür ist keine Programmiersprache nötig. Beschreiben Sie in jeder Zeile den heutigen Zustand und das gewünschte Ergebnis. Offene Punkte dürfen ausdrücklich offenbleiben: Sie sind Prüfaufträge und kein Fehler im Briefing.

Die Tabelle ist auch sinnvoll, wenn der heutige Ablauf über CSV-Dateien oder Tabellen funktioniert. Wichtiger als der Name der Technik ist die Frage, wer in jeder Phase für die Information verantwortlich ist.

Legen Sie die führende Quelle für jede Information fest

„Synchronisation in beide Richtungen“ klingt bequem, führt ohne klare Regeln jedoch zu Konflikten. Wird ein Preis gleichzeitig im Shop und im Lagerprogramm geändert, muss die Integration wissen, welcher Wert gilt.

Die führende Quelle muss nicht für den gesamten Datensatz dieselbe sein. Beispielsweise kann:

• der Shop für den Inhalt einer vom Kunden abgegebenen Bestellung maßgeblich sein;
• die Lagerverwaltung die Produktverfügbarkeit bestimmen;
• die Buchhaltung Nummer und Status eines Dokuments führen;
• das CRM die Zuständigkeit für die Kundenbeziehung verwalten.

Notieren Sie vor dem ersten Gespräch die wichtigsten Felder und das System, in dem sie geändert werden dürfen. Wenn Mitarbeitende dieselben Daten heute an mehreren Stellen korrigieren, unterscheiden Sie außerdem zwischen dem offiziellen Prozess und einem Behelf, der nur wegen bestehender Grenzen entstanden ist.

Bestimmen Sie, wie beide Systeme denselben Datensatz erkennen

Kundenname, E-Mail-Adresse oder Produktbezeichnung reichen für eine sichere Zuordnung oft nicht aus. Solche Werte können sich ändern, mehrfach vorkommen oder unterschiedlich geschrieben sein. Nötig ist eine stabile Kennung oder eine klar vereinbarte Zuordnungsregel.

Die Beschreibung sollte festhalten:

• die Kennung im Quellsystem;
• die vom Zielsystem vergebene Kennung;
• den Speicherort der Verbindung zwischen beiden;
• die Regel für nicht eindeutig zuordenbare Datensätze;
• die Erkennung eines wiederholten Vorgangs.

Der letzte Punkt verhindert Duplikate. Das Zielsystem kann Daten bereits gespeichert haben, obwohl seine Antwort wegen eines Verbindungsabbruchs nicht zurückkommt. Eine einfache Wiederholung könnte dann einen zweiten Datensatz erzeugen. Die Integration muss den bereits ausgeführten Vorgang erkennen oder den unklaren Fall zur Prüfung vorlegen.

Richten Sie die Häufigkeit am tatsächlichen Bedarf aus

Nicht jeder Prozess muss sofort reagieren. Ein Bestellstatus kann innerhalb weniger Minuten erforderlich sein, während ein Sammel-Export für einen Bericht einmal täglich genügt. Die Forderung nach „Echtzeit“ erhöht die Abhängigkeit von der Verfügbarkeit beider Systeme und schafft nicht automatisch zusätzlichen Nutzen.

Beschreiben Sie die zulässige Verzögerung und mögliche Ausnahmen. Ein Datenfluss kann:

• nach einem konkreten Ereignis starten, etwa nach dem Absenden eines Formulars;
• regelmäßig laufen, beispielsweise alle fünf Minuten oder einmal täglich;
• nach Freigabe durch eine berechtigte Person manuell ausgelöst werden;
• Daten gesammelt als Datei verarbeiten.

Der technische Mechanismus wird erst nach Prüfung beider Systeme gewählt. Eine beworbene API garantiert weder den Zugriff auf die benötigten Daten noch passende Limits oder eine sichere Testumgebung.

Planen Sie Fehler, Wiederholungen und Datenabgleich

Eine Integration ist nicht fertig, nur weil ein Beispieldatensatz korrekt verarbeitet wurde. Es braucht auch Regeln für fehlende Pflichtfelder, nicht erreichbare Systeme, geänderte Datenformate und uneindeutige Ergebnisse.

Klären Sie vier Fragen:

1. Welche Fehler dürfen automatisch und sicher wiederholt werden?
2. Welche Fehler erfordern korrigierte Daten oder eine menschliche Entscheidung?
3. Wer wird wie über das Problem informiert?
4. Wie wird später geprüft, ob alle Vorgänge abgeschlossen wurden?

Wiederholung und Abgleich erfüllen unterschiedliche Aufgaben. Eine Wiederholung versucht, einen einzelnen Vorgang zu Ende zu bringen. Der Abgleich vergleicht beide Seiten und findet Datensätze, die fehlen oder ohne eindeutiges Ergebnis stehen geblieben sind.

Nicht jeder Fehler darf eine Serie automatischer Versuche auslösen. Sind Daten ungültig oder ist eine geschäftliche Entscheidung nötig, löst das erneute Senden desselben Inhalts nichts. Der Vorgang muss für die zuständige Person sichtbar bleiben.

Trennen Sie technischen Zugang von Unterlagen für die Schätzung

Für eine erste Einschätzung genügen die Namen der Systeme, die Arten der Daten, ein anonymisiertes Strukturbeispiel und verfügbare Dokumentation. Senden Sie keine Passwörter, Token, Zertifikate, Kopien produktiver Datenbanken oder echten Kunden- und Mitarbeiterdaten per Nachricht.

Während der Umsetzung stimmen wir gesondert ab:

• die Authentifizierung jeder Verbindung;
• die minimalen Rechte technischer Konten;
• eine Testumgebung oder sichere Beispieldaten;
• den Speicherort für Geheimnisse;
• die Personen, die Zugriffe freigeben dürfen;
• den Entzug der Rechte nach Abschluss der Zusammenarbeit.

Ein Integrationskonto sollte nicht mehr Rechte erhalten, nur weil dies einfacher einzurichten ist. Der Berechtigungsumfang muss aus der vereinbarten Datenflusskarte folgen.

Was muss vor einer belastbaren Schätzung geprüft werden?

Der Produktname allein reicht nur selten aus. Vor der Schätzung kann zu prüfen sein:

• ob der Anbieter einen unterstützten Datenaustausch bereitstellt;
• ob die Dokumentation die benötigten Vorgänge und die aktuelle Version abdeckt;
• welche Anforderungen, Limits und Zugangsbedingungen gelten;
• ob eine Testumgebung vorhanden ist;
• in welchem Zustand Kennungen und historische Daten sind;
• wer bei jedem Anbieter für Änderungen verantwortlich ist;
• ob eine vorhandene Integration repariert oder ersetzt werden sollte.

Bei lückenhafter Dokumentation, vielen Datenausnahmen oder mehreren beteiligten Anbietern kann eine bezahlte technische Voruntersuchung die erste Etappe sein. Ziel und Umfang vereinbaren wir vorab. Das Ergebnis sollen konkrete Entscheidungsgrundlagen sein, nicht nur die allgemeine Feststellung, dass das Projekt komplex ist.

Beispiel einer ausgefüllten Datenflusskarte

Das folgende Szenario ist fiktiv. Es zeigt die Methode und ist weder ein fertiges Projekt noch eine Kundenreferenz von Domin Software.

Ein Unternehmen nimmt Bestellungen im Onlineshop an, während das Abwicklungsteam in einer getrennten Anwendung arbeitet. Nach der Zahlung überträgt ein Mitarbeiter Kunden- und Positionsdaten manuell und aktualisiert später den Status im Shop.

Ziel der ersten Etappe: Eine bezahlte Bestellung soll genau einen Vorgang in der Abwicklungsanwendung anlegen. Dessen Nummer wird an den Shop zurückgegeben, damit beide Datensätze verbunden sind.

Führende Quellen: Der Shop ist für den Inhalt der angenommenen Bestellung maßgeblich. Die Abwicklungsanwendung führt Bearbeiter und Arbeitsstatus. Nach der Übergabe verändert die Integration keine Bestellpositionen.

Kennungen: Die Shop-Bestellnummer wird in der Abwicklungsanwendung als externe Kennung gespeichert. Der Shop speichert die zurückgegebene Vorgangsnummer.

Zeitpunkt: Die Zahlungsbestätigung startet den Ablauf. Die zulässige Verzögerung beträgt fünf Minuten.

Fehler: Fehlende Pflichtdaten stoppen den Datensatz und erzeugen eine Aufgabe zur Korrektur. Ein Verbindungsfehler darf wiederholt werden. Zuvor wird geprüft, ob ein Vorgang mit dieser Bestellnummer bereits existiert.

Abgleich: Einmal täglich entsteht eine Liste bezahlter Bestellungen ohne Vorgangsnummer sowie der Vorgänge, deren Status nicht an den Shop zurückgemeldet wurde.

Verantwortung: Der Kundenservice korrigiert fehlende Daten, die Leitung entscheidet in unklaren Fällen. Technische Probleme gehen an den vereinbarten Supportkanal für die Integration.

Auf dieser Grundlage können wir prüfen, ob beide Systeme die nötigen Vorgänge unterstützen, welche Annahmen getestet werden müssen und ob die erste Etappe ohne zusätzliche Voruntersuchung geschätzt werden kann.

Was beeinflusst den Umfang am stärksten?

Nicht nur die Zahl der übertragenen Felder ist entscheidend. Wichtig sind außerdem:

• einseitiger oder beidseitiger Datenaustausch;
• Qualität und Konsistenz der vorhandenen Daten;
• Stabilität der Kennungen;
• Anzahl der Ausnahmen, die eine Entscheidung verlangen;
• erwartete Verzögerung;
• Verfügbarkeit von Dokumentation und Testumgebung;
• Limits und Änderungen externer Dienste;
• erforderliches Monitoring und Bearbeitung von Störungen;
• Migration historischer Daten, falls sie tatsächlich benötigt wird.

Darum können zwei Projekte mit ähnlichen Programmkategorien einen völlig unterschiedlichen Umfang haben. Eine seriöse Schätzung allein anhand der Anwendungsnamen ist nicht möglich.

Was sollten Sie für das erste Gespräch senden?

Bereiten Sie vor:

• Namen und Versionen beider Systeme, soweit bekannt;
• die Beschreibung eines Datenflusses anhand der obigen Karte;
• die in der ersten Etappe unbedingt benötigten Daten;
• das verantwortliche System für jedes wichtige Feld;
• ein anonymisiertes Beispiel einer Datei oder Datenstruktur;
• einen Link oder eine Datei mit offizieller Integrationsdokumentation, sofern vorhanden;
• die Beschreibung der heutigen Handarbeit oder eines bestehenden Fehlers;
• das gewünschte Ergebnis und die zulässige Verzögerung;
• eine Person, die den Prozess kennt und Ausnahmen entscheiden kann.

Sie müssen Protokoll, Warteschlange, Bibliothek oder Architektur nicht selbst auswählen. Diese Entscheidungen ergeben sich aus den Möglichkeiten der Systeme und dem vereinbarten Prozess.

Die Systemintegrationen und Datenflussautomatisierung von Domin Software umfassen unter anderem APIs, Webhooks, Importe und Exporte. Ist die Integration Teil einer größeren Anwendungsänderung, sehen Sie auch unsere PHP- und Laravel-Entwicklung.

Lassen Sie uns den ersten Datenfluss einschätzen

Beschreiben Sie in Ihrer Nachricht die beiden Systeme und einen Prozess, den Sie verbessern möchten. Wenn Sie nicht wissen, ob eine API vorhanden ist oder welches Programm die führende Datenquelle sein sollte, nennen Sie diesen offenen Punkt. Wir prüfen, ob der Umfang direkt bestimmt werden kann oder ob zuerst Dokumentation und Daten untersucht werden müssen.

Wenn Sie die Annahmen zuerst selbst ordnen möchten, verwenden Sie den Planer für die Integration zweier Systeme.

Integration zur ersten Einschätzung beschreiben