Warum die Integrationsfrage vor dem KI-Modell kommt
Ein guter Entwurf muss wissen, wo die verlässlichen Stammdaten liegen, welche Informationen gelesen oder geschrieben werden dürfen und wer Fehler korrigiert. Ohne diese Klärung entsteht eine zusätzliche Insellösung statt eines belastbaren Prozesses.
Unklare Datenquelle
Kunde, Auftrag, Objekt, Artikel oder Preis können in mehreren Systemen unterschiedlich geführt sein.
Fehlende Schnittstelle
Nicht jede Version oder jedes Modul stellt dieselben APIs, Exporte oder Schreibrechte bereit.
Zu breite Berechtigung
Ein Prototyp erhält mehr Zugriff als für den abgegrenzten Prozess tatsächlich notwendig wäre.
Keine Fehlerroute
Unklare, doppelte oder widersprüchliche Daten haben keinen definierten Weg zur menschlichen Klärung.
Sechs Architekturentscheide vor der Integration
- 1System of Record bestimmen
Für Kunde, Auftrag, Preis, Dokument und Status wird die führende Quelle benannt.
- 2Lesen und Schreiben trennen
Der Pilot startet wenn möglich mit lesendem Zugriff oder kontrolliertem Export.
- 3Schnittstelle prüfen
API, Dateiimport, Export, Webhook oder Zwischenablage werden technisch und vertraglich verifiziert.
- 4Daten minimieren
Nur die für den Prozess notwendigen Felder werden übertragen und angemessen geschützt.
- 5Freigabe einbauen
Schreibende oder verbindliche Schritte benötigen Rolle, Prüfung und nachvollziehbaren Status.
- 6Betrieb planen
Monitoring, Fehlerbehandlung, Versionsänderungen, Support und Rückfallprozess werden dokumentiert.
Vier Integrationswege mit unterschiedlichen Risiken
API
Gut für strukturierte, wiederholbare Übergaben, sofern Endpunkte, Rechte, Limits und Versionierung verfügbar sind.
Import und Export
Oft ein pragmatischer Pilotweg, wenn Dateiformat, Validierung, Freigabe und Rückmeldung klar definiert sind.
Dokumentenablage
Geeignet für Suche oder Extraktion, sofern Version, Zugriff, Aufbewahrung und Quellenanzeige kontrolliert werden.
Zwischenoberfläche
Sinnvoll, wenn ein Mensch Vorschläge prüfen soll, bevor Daten in das Kernsystem übernommen werden.
Klare Grenze: Eine namentliche Systemnennung ist keine Integrationszusage. Produkt, Version, Mandant, Module, Berechtigungen und Vertrag müssen im konkreten Projekt geprüft werden.
Integration mit geringstem sinnvollem Risiko starten
Read-only prüfen
Mit Export oder lesendem Zugriff Datenstruktur, Qualität und Zuordnung untersuchen.
Entwurf ausserhalb
Vorschläge zunächst in einer separaten Prüfansicht erzeugen und fachlich abnehmen.
Kontrollierte Übergabe
Nur freigegebene Datensätze über einen begrenzten Import oder Endpunkt übertragen.
Betrieb testen
Fehler, Duplikate, Ausfälle, Änderungen und Rückfallweg mit repräsentativen Fällen prüfen.
Beweisstandard: Diese Seite beschreibt ein Prozess- und Entscheidungsmodell. Konkrete Wirkung wird erst nach Baseline, repräsentativen Testfällen und dokumentierter Messung beurteilt.
Weitere HLKS-Entscheidungsseiten
Fragen vor dem Pilot
Kann KI mit SORBA oder Abacus verbunden werden?
Möglicherweise. Entscheidend sind konkrete Produktversion, Module, verfügbare Schnittstellen, Berechtigungen und der gewünschte Prozess. Das wird vor einer Zusage technisch geprüft.
Ist eine API immer die beste Lösung?
Nein. Für einen begrenzten Pilot kann ein kontrollierter Export und Import sicherer und wirtschaftlicher sein. Die Wahl hängt von Volumen, Aktualität und Risiko ab.
Soll der Pilot direkt ins ERP schreiben?
Wenn möglich startet er lesend oder mit einer Prüfansicht. Schreibender Zugriff folgt erst nach validierten Regeln, Berechtigungen und Fehlerwegen.
Wie werden doppelte oder falsche Datensätze verhindert?
Mit eindeutigen Schlüsseln, Validierung, Protokollierung, Wiederholschutz und einem definierten Klärungsprozess für unsichere Fälle.
Wer ist für die Daten verantwortlich?
Die Rollen werden je Datenart und Prozessschritt benannt. Technik kann Prüfungen unterstützen, ersetzt aber nicht die fachliche und organisatorische Verantwortung.