Eine Verbindung ist erst fachlich geklärt, wenn Daten, Auslöser, Rechte und Fehlerwege feststehen. Planen Sie nicht nur den erfolgreichen Durchlauf, sondern auch doppelte Ereignisse, Ausfälle und kontrollierte Korrekturen.
1. Den Vorgang von Anfang bis Ende beschreiben
Nehmen Sie einen konkreten Arbeitsfall statt eine abstrakte Forderung nach „nahtloser Integration“. Beschreiben Sie Auslöser, Eingaben, beteiligte Programme und das erwartete Endergebnis. Bestimmen Sie, an welcher Stelle die fachliche Verantwortung wechselt. Ein technischer Übertragungsnachweis allein bedeutet nicht, dass der Vorgang im Zielsystem richtig verarbeitet wurde. Die Abnahme benötigt deshalb sowohl technische als auch fachliche Kriterien.
2. Die führende Information festlegen
Benennen Sie für wichtige Felder das führende System. Andernfalls können Änderungen in mehreren Programmen miteinander kollidieren. Legen Sie fest, wie Identitäten zusammengeführt werden und was passiert, wenn Werte fehlen oder nicht eindeutig sind. Eine Feldzuordnung sollte neben Namen und Format auch Bedeutung und erlaubte Werte dokumentieren. Der Quellwert „offen“ kann in zwei Anwendungen unterschiedliche fachliche Zustände meinen.
Weitere Formate
Die Textfassung bleibt für technische Workflows und KI-Arbeitsaufträge verfügbar.
3. Tatsächliche Schnittstellen und Grenzen prüfen
Bestätigen Sie, dass die benötigte Funktion im verwendeten Produkt und Tarif zugänglich ist. Dokumentation, Anbieterzusage und eigener Test werden getrennt festgehalten. Berücksichtigen Sie Authentifizierung, Mengenlimits, unterstützte Ereignisse und die Möglichkeit einer bereinigten Testumgebung. Ein Export ist nicht automatisch eine dauerhafte bidirektionale Schnittstelle. Fehlende Funktionen erhalten einen Klärungsauftrag statt einer stillen Annahme.
4. Wiederholungen ohne doppelte Wirkung planen
Eine Integration kann dasselbe Ereignis mehrfach erhalten oder nach einem technischen Fehler erneut senden. Für kritische Vorgänge muss feststehen, wie doppelte Wirkung verhindert oder erkannt wird. Dazu wird ein fachlicher Vorgang eindeutig zugeordnet und sein Verarbeitungsstand nachvollziehbar dokumentiert. Die konkrete Lösung hängt vom System ab. Testen Sie insbesondere Fälle, in denen die Verarbeitung erfolgreich war, ihre Bestätigung aber verloren ging. Gerade dort reicht einfaches erneutes Senden oft nicht.
5. Technische und fachliche Fehler unterscheiden
Ein vorübergehend nicht erreichbarer Dienst braucht einen anderen Weg als ein fachlich ungültiger Datensatz. Definieren Sie begrenzte Wiederholungen und eine Eskalation für technische Probleme. Fachliche Fehler werden an eine zuständige Person übergeben, die korrigieren oder ablehnen kann. Protokolle sollten genügend Informationen zur Bearbeitung enthalten, aber nicht unnötig sensible Daten vervielfältigen. Der Fehlerweg muss im Betrieb erreichbar sein und darf nicht nur im Konzept stehen.
6. KI-Teilschritte durch klare Verträge begrenzen
Verwendet der Ablauf KI zur Einordnung oder Extraktion, wird das erwartete Ergebnisformat festgelegt und technisch validiert. Fehlende Werte dürfen nicht durch unmarkierte Vermutungen ersetzt werden. Für unsichere oder unzulässige Ergebnisse wird ein menschlicher Prüfweg definiert. Ein Sprachmodell entscheidet nicht automatisch darüber, ob es zusätzliche Rechte oder Werkzeuge verwenden darf. Diese Grenzen müssen durch die Anwendung getragen werden.
| Fall | Erwarteter Nachweis |
|---|---|
| Typischer Vorgang | Korrektes fachliches Ergebnis im Zielsystem. |
| Doppeltes Ereignis | Keine unkontrollierte doppelte Wirkung. |
| Ausfall nach Verarbeitung | Verarbeitungsstand sicher klärbar. |
| Ungültige KI-Ausgabe | Kein ungeprüftes Weiterreichen. |
| Fehlende Berechtigung | Aktion wird verhindert und nachvollziehbar gemeldet. |
7. Betrieb und Abnahme dokumentieren
Die Übergabe enthält Feldzuordnung, Zugriffsumfang, Fehlerwege und getestete Fälle. Benennen Sie, wer Änderungen an Quell- und Zielprogrammen beobachtet und die Integration danach prüft. Werden Datenformate oder Pflichtfelder verändert, kann die Verbindung fachlich fehlschlagen, obwohl die technische Anfrage erfolgreich ist. Ein klarer Betreiber und ein wiederholbarer Testsatz machen solche Änderungen besser beherrschbar. Das Konzept selbst ist noch keine live überwachte Integration.
Arbeitsbeispiel: die Methode konkret anwenden
Ein fiktiver Ablauf legt einen Auftrag im Zielsystem erfolgreich an. Die Bestätigung erreicht die aufrufende Anwendung jedoch nicht. Ein einfaches erneutes Anlegen würde möglicherweise einen zweiten Auftrag erzeugen. Der Testsatz muss deshalb prüfen, ob die Integration den bestehenden Vorgang anhand seiner Identität erkennen und dessen Zustand klären kann. Der erwartete Nachweis ist nicht nur ein erfolgreicher HTTP-Status, sondern genau ein fachlich korrekter Auftrag. Dieses Beispiel beschreibt ein Prüfprinzip; die passende technische Realisierung hängt von den tatsächlichen Schnittstellen ab.