Ohne Prüfung beider Seiten einer Verbindung gibt es keinen einzigen seriösen Preis für eine System- oder API-Integration. Die Kosten hängen unter anderem von der verfügbaren Dokumentation, der Richtung des Datenflusses, der Anzahl der Regeln, der Qualität der Kennungen, der Fehlerbehandlung, den Tests und der späteren Wartung ab.
Eine Integration endet nicht mit einer erfolgreich gesendeten API-Anfrage. Sie muss auch sicher reagieren, wenn Daten unvollständig sind, derselbe Datensatz zweimal ankommt, eines der Systeme vorübergehend nicht erreichbar ist oder ein Anbieter die Zahl der Anfragen begrenzt.
Beim Kostenvergleich sollten drei Bereiche getrennt betrachtet werden:
- Vorbereitung und Umsetzung, also Prozessaufnahme, Datenzuordnung, Programmierung, Tests und Inbetriebnahme;
- Gebühren externer Anbieter, falls ein Plan, ein Konnektor, eine Plattform oder der Zugriff auf benötigte Funktionen kostenpflichtig ist;
- laufende Wartung, also Überwachung, Behandlung von Problemen und Anpassungen nach Änderungen an verbundenen Systemen.
Die Aussage „wir möchten unseren Shop mit dem ERP verbinden“ reicht daher für eine verantwortbare Schätzung nicht aus.
Ist die Integration Teil eines größeren Systems, bietet der Artikel Was kostet eine Webanwendung für Unternehmen? den weiteren Zusammenhang.
Warum reichen die Namen zweier Systeme für eine Schätzung nicht aus?
Dieselbe Verbindung kann einen völlig unterschiedlichen Umfang haben. Ein Unternehmen möchte neue Bestellungen vielleicht nur einmal täglich übertragen. Ein anderes erwartet den sofortigen Austausch von Bestellungen, Lagerbeständen, Preisen, Zahlungen und Versandstatus in beide Richtungen.
Im ersten Fall kann ein einfacher Import genügen. Im zweiten müssen unter anderem folgende Fragen beantwortet werden:
- Welches System führt den richtigen Preis und Lagerbestand?
- Was passiert, wenn ein Kunde die Bestellung während der Synchronisierung ändert?
- Wie wird dasselbe Produkt oder derselbe Geschäftspartner auf beiden Seiten erkannt?
- Wie lässt sich eine doppelte Bestellung verhindern?
- Welche Fehler dürfen automatisch erneut verarbeitet werden und wann muss ein Mitarbeiter entscheiden?
- Wie wird kontrolliert, ob die Daten in beiden Systemen weiterhin übereinstimmen?
Die Schätzung hängt somit vom gesamten Ablauf und nicht nur von der Zahl der Programme ab.
Vier Wege zur Verbindung von Systemen
Nicht jede Integration muss als individuelle Lösung von Grund auf entwickelt werden. Zuerst sollte geprüft werden, welcher Weg zum Prozess und zu den technischen Möglichkeiten der Systeme passt.
| Möglicher Weg | Wann er geprüft werden sollte | Was die Kosten beeinflussen kann |
|---|---|---|
| Fertiger Konnektor | Beide Systeme unterstützen eine Verbindung mit ausreichendem Funktionsumfang | Konfiguration, Feldzuordnung, Plan oder Lizenz, Tests und laufende Administration |
| Dateiaustausch | Ein System unterstützt Import und Export, stellt aber keine passende API bereit | Aufbereitung von CSV oder XML, Validierung, Zeitplan, Behandlung fehlerhafter Dateien und Importkontrolle |
| API oder Webhooks | Daten müssen häufiger oder mit geringer Verzögerung ausgetauscht werden | Authentifizierung, Zuordnung, Senden und Empfangen, Limits, Wiederholungen, Tests und Monitoring |
| Eigenes Zwischenmodul | Unterschiedliche Formate, mehrere Systeme oder zusätzliche Unternehmensregeln müssen verbunden werden | Ablaufkonzept, Modulentwicklung, Infrastruktur, Protokolle, Warnungen, Wartung und Weiterentwicklung |
Eine fehlende API schließt Automatisierung nicht immer aus. Dateien oder unterstützte Importfunktionen können eine sichere Lösung ermöglichen. Es muss jedoch geprüft werden, ob Häufigkeit, Vollständigkeit und Fehlerkontrolle den Anforderungen entsprechen.
Woraus setzen sich die Umsetzungskosten zusammen?
Prüfung der Möglichkeiten beider Systeme
Zuerst müssen Programmversionen, verfügbare Module, Dokumentation, Anmeldeverfahren und ein mögliches Testsystem ermittelt werden. Die Dokumentation kann viele Funktionen beschreiben, die im Tarif oder in der eingesetzten Version des Kunden nicht verfügbar sind.
Beschreibung von Prozess und Datenrichtung
Der Umfang muss festlegen, wodurch der Austausch ausgelöst wird, welche Daten in welche Richtung übertragen werden und wie schnell dies geschehen soll. Ebenso wichtig ist die Entscheidung, welches System bei unterschiedlichen Werten als maßgebliche Quelle gilt.
Zuordnung und Umwandlung von Daten
Produktbezeichnung, Adresse, Steuersatz oder Bestellstatus können in jedem System anders gespeichert sein. Die Integration muss diese Unterschiede erkennen und die Daten nach vereinbarten Regeln umwandeln.
Zugriff und Sicherheit
Die Verbindung sollte nur die Berechtigungen erhalten, die sie tatsächlich benötigt. Anmeldeverfahren, Speicherung von Schlüsseln, Rollen und die Möglichkeit, den Zugriff zu widerrufen, gehören ebenfalls zum Arbeitsumfang.
Fehlerbehandlung und Wiederholungen
Fehlende Pflichtwerte, Ausfälle, überschrittene Limits und eine erneute Übermittlung derselben Operation müssen berücksichtigt werden. Eine allgemeine Meldung „Fehler aufgetreten“ genügt nicht. Es muss erkennbar sein, was fehlgeschlagen ist, ob eine sichere Wiederholung möglich ist und wer reagieren soll.
Tests und Inbetriebnahme
Getestet wird nicht nur der korrekte Ablauf. Benötigt werden auch fehlerhafte Daten, Duplikate, teilweise ausgeführte Operationen und die Nichtverfügbarkeit eines Systems. Der Testumfang wächst, wenn Bestellungen, Abrechnungen oder von mehreren Abteilungen genutzte Daten betroffen sind.
Protokolle, Warnungen und spätere Betreuung
Nach dem Start muss nachvollziehbar sein, was passiert ist. Je nach Bedeutung des Prozesses können Protokolle, Benachrichtigungen, Berichte über fehlende Daten oder eine Oberfläche für kontrollierte manuelle Korrekturen erforderlich sein.
Was verändert die Schätzung am stärksten?
Dokumentation und Testumgebung
Klare Dokumentation und Testzugriff erlauben eine frühe Prüfung der technischen Annahmen. Fehlende Unterlagen erhöhen die Zahl der Unbekannten. Mitunter ist auch Kontakt zum Anbieter oder Arbeit auf seiner Seite notwendig.
Einweg- oder Zweiwegsynchronisierung
Neue Bestellungen aus dem Shop an ein ERP zu senden, lässt sich einfacher beschreiben als eine vollständige Synchronisierung in beide Richtungen. Für den Zweiwegaustausch sind Konfliktregeln, die Reihenfolge von Änderungen und eine maßgebliche Datenquelle festzulegen.
Anzahl der Daten und Regeln
Nicht nur die Zahl der Felder ist entscheidend. Formate, Bedingungen, Ausnahmen und Abhängigkeiten spielen ebenfalls eine Rolle. Ein Status kann mehrere Aktionen im zweiten System auslösen, während ein scheinbar einfaches Feld ein Wörterbuch oder zusätzliche Prüfung benötigt.
Qualität der Kennungen und vorhandenen Daten
Hat dasselbe Produkt unterschiedliche Nummern, kommen Geschäftspartner mehrfach vor oder fehlen feste Kennungen, müssen Zuordnung und Kontrollen vereinbart werden. Sonst kann die Integration Duplikate erzeugen oder falsche Datensätze verbinden.
Datenmenge, Häufigkeit und Limits
Einige Datensätze einmal täglich zu senden ist etwas anderes als eine häufige Verarbeitung vieler Vorgänge. Ein API-Anbieter kann außerdem die Zahl der Anfragen begrenzen oder ein bestimmtes Verfahren für größere Datenmengen vorschreiben.
Historische Daten und einmalige Migration
Der Start des laufenden Austauschs umfasst nicht automatisch alle Daten aus vergangenen Jahren. Der Import der Historie benötigt einen eigenen Umfang, eine Prüfung der Datenqualität und eine Entscheidung darüber, welche Informationen noch gebraucht werden.
Ausnahmen, die eine menschliche Entscheidung erfordern
Nicht jedes Problem lässt sich automatisch lösen. Muss ein Mitarbeiter den richtigen Datensatz wählen oder eine ungewöhnliche Bestellung beurteilen, sollte die Integration klare Informationen und einen sicheren Korrekturweg bieten.
Sicherheits- und Nachweisanforderungen
Der Umfang wächst, wenn Vorgänge detailliert protokolliert, Berechtigungen getrennt, wichtige Daten besonders geschützt oder Ursachen einzelner Änderungen später erklärt werden müssen.
Die anfängliche Umsetzung ist nicht der gesamte Integrationsaufwand
Nach der Inbetriebnahme wird die Integration Teil eines Unternehmensprozesses. Vor der Auswahl eines Angebots sollte geklärt werden, wer sie überwacht und was nach einer Änderung eines verbundenen Systems geschieht.
Zu den laufenden Kosten können gehören:
- Gebühren für Tarif, Konnektor, Plattform oder erforderliche Funktionen;
- Server oder andere Infrastruktur für ein Zwischenmodul;
- Monitoring, Aufbewahrung von Protokollen und Benachrichtigungen;
- manuelle Behandlung von Fällen, die nicht automatisch entschieden werden können;
- Änderungen an Schlüsseln, Berechtigungen oder Anmeldeverfahren;
- Anpassungen nach Änderungen an API, Datenformat oder Geschäftsprozess;
- Support und Weiterentwicklung.
Nicht jede Integration benötigt ein Abonnement oder denselben Umfang laufender Betreuung. Dies muss für den konkreten Prozess festgelegt und im Angebot beschrieben werden.
Einen breiteren Vergleich der Betreuungsmodelle finden Sie im Artikel Was kostet die Wartung einer Webanwendung?.
Wie lassen sich zwei Integrationsangebote vergleichen?
Zwei ähnliche Beträge können sehr unterschiedliche Leistungen enthalten. Ein Angebot kann Tests, Fehlerbehandlung und Monitoring umfassen, ein anderes nur die grundlegende Datenübertragung. Vergleichen Sie deshalb Antworten auf dieselben Fragen.
| Vergleichsfrage | Was klar beschrieben sein sollte |
|---|---|
| Welche Systeme und Versionen sind enthalten? | konkrete Produkte, Module, Umgebungen und Abhängigkeiten von Anbietern |
| In welche Richtung fließen die Daten? | Richtung, Häufigkeit, Auslöser und zulässige Verzögerung |
| Welche Daten sind enthalten? | Datensätze, Felder, Status, Anhänge, historische Daten und Ausschlüsse |
| Welches System ist die maßgebliche Quelle? | Regeln für Konflikte und Duplikate |
| Was geschieht bei einem Fehler? | Wiederholungen, Benachrichtigungen, Warteschlange, manuelle Korrektur und Kontrolle fehlender Daten |
| Wie wird die Integration geprüft? | Testdaten, Szenarien, Abnahmekriterien und Zuständigkeiten |
| Was geschieht nach dem Start? | Monitoring, Support, API-Änderungen, Lizenzen, Infrastruktur und Wartungsumfang |
| Was ist nicht enthalten? | Migration, Datenbereinigung, Arbeiten des Anbieters, neue Regeln und spätere Entwicklung |
Fehlen diese Angaben, lässt sich schwer beurteilen, ob die Angebote tatsächlich dieselbe Lösung beschreiben.
Wann ist eine Schätzung möglich und wann wird eine Analyse benötigt?
Ein einzelner, gut beschriebener Ablauf kann geschätzt werden, sobald genügend Informationen vorliegen und die technischen Möglichkeiten geprüft wurden. Mindestens erforderlich sind Systeme, Datenrichtung, Umfang der Datensätze, Häufigkeit, wichtigste Ausnahmen und Art der Abnahme.
Ein kostenloses Qualifikationsgespräch mit Domin Software kann bis zu 20 Minuten dauern. Es dient dazu, Problem, Ziel und benötigte Unterlagen für die weitere Bewertung zu erkennen. Eine kostenlose Diagnose, Planung der Integration oder Erstellung eines Berichts ist nicht enthalten.
Umfasst das Projekt mehrere Systeme, Zweiwegsynchronisierung, ungeordnete Daten oder schwer prüfbare Einschränkungen, kann eine Business-Analyse und Festlegung der ersten Etappe der richtige Einstieg sein. Dies ist eine kostenpflichtige, separat geschätzte Etappe. Führt Domin Software anschließend das daraus entstandene Projekt aus, wird der bereits bezahlte Analysebetrag auf die Gesamtkosten angerechnet.
Was sollte vor dem Gespräch über eine Integration vorbereitet werden?
Sie müssen keine technische Dokumentation selbst verfassen. Bereiten Sie Informationen vor, mit denen wir Ablauf und Unbekannte erkennen können:
- Namen und Versionen der Systeme;
- Links zur Dokumentation, falls vorhanden;
- Angaben zu Testkonten oder Testumgebungen der Anbieter;
- eine Liste der Daten, die in jede Richtung übertragen werden sollen;
- ein anonymisiertes Beispiel einer Datei oder Datenstruktur ohne Kundendaten, Passwörter und Schlüssel;
- Häufigkeit und ungefähre Zahl der Vorgänge;
- die wichtigsten Fehlerfälle und Ausnahmen;
- die Methode, mit der die korrekte Funktion der ersten Etappe bestätigt wird.
Sie können mit dem Planer für Systemintegrationen beginnen. Er hilft, eine Arbeitsübersicht des Ablaufs zu erstellen, erzeugt jedoch keine automatische Schätzung und ersetzt nicht die Prüfung der Dokumentation.
Eine ausführlichere Beschreibung des Ablaufs finden Sie im Artikel Integration zweier Systeme planen.
Was zeigen unsere bisherigen Projekte?
Bei HUB.ITM verarbeiteten wir Daten aus unterschiedlichen Programmen und Formaten und bereiteten sie für den Import in Subiekt-Systeme vor. Dafür waren genaue Zuordnungsregeln und Kontrollen der Datenrichtigkeit erforderlich.
HUB-2-API umfasste den Produktimport, die Integration mit eBay.de und eine API, über die drei Kunden aus Frankreich das Angebot prüften und Bestellungen aufgaben. Das Beispiel zeigt, wie verschiedene Datenrichtungen, Empfänger und Prozesse in einem Projekt zusammenkommen.
In einem historischen Produktimport-System nutzten wir CSV, XML, API und FTP zur Versorgung von Onlineshops. Der Austauschweg richtete sich nach den Möglichkeiten von Quelle und Ziel und nicht nach einem einzigen Werkzeug für jeden Fall.
Diese Projekte sind keine Preisliste und bestimmen nicht die Kosten eines neuen Vorhabens. Sie zeigen, weshalb Formate, Regeln und Fehlerbehandlung vor der Schätzung verstanden werden müssen.
Häufig gestellte Fragen
Kann eine Integration allein anhand der Systemnamen geschätzt werden?
In der Regel nicht. Die Namen erlauben eine erste Prüfung, zusätzlich werden jedoch Richtung, Datenumfang, Häufigkeit, Regeln, Ausnahmen und Fehlerbehandlung benötigt.
Bedeutet eine vorhandene API immer eine einfache und günstige Integration?
Nein. Eine API kann nur einen Teil der benötigten Daten bereitstellen, Limits enthalten oder einen zusätzlichen Tarif erfordern. Dokumentation, Testzugang und konkrete Operationen müssen geprüft werden.
Können Systeme verbunden werden, wenn eines keine API hat?
Manchmal. Dateiimport und -export, ein unterstützter Konnektor oder ein anderer dokumentierter Weg können möglich sein. Machbarkeit und Sicherheit sind für das konkrete System zu prüfen.
Warum erfordert eine Zweiwegsynchronisierung mehr Festlegungen?
Es muss entschieden werden, welches System Vorrang hat, wie Konflikte gelöst werden und was bei gleichzeitigen Änderungen geschieht. Außerdem entstehen zusätzliche Fehler- und Testszenarien.
Gehört der Import historischer Daten zur Integration?
Nur wenn er im vereinbarten Umfang enthalten ist. Die Übernahme der Historie kann eigene Zuordnung, Bereinigung und Kontrolle erfordern.
Muss eine Integration nach dem Start gewartet werden?
Der Umfang hängt von der Bedeutung des Prozesses und den verbundenen Systemen ab. Monitoring, Fehlerbehandlung, Zuständigkeit für API-Änderungen und der Weg für spätere Anpassungen sollten vereinbart werden.
Ist eine Schätzung ohne kostenpflichtige Analyse möglich?
Ja, wenn der Umfang klar genug ist und die technischen Möglichkeiten ohne eigene Etappe geprüft werden können. Ein kurzes Qualifikationsgespräch ersetzt jedoch keine kostenlose Diagnose oder Lösungsplanung.
Kann eine Integration etappenweise umgesetzt werden?
Ja. Man kann mit einem wichtigen Ablauf und klaren Abnahmekriterien beginnen und später weitere Daten oder Systeme ergänzen. Jede Etappe sollte einen eindeutig beschriebenen Umfang haben.
Wählen Sie den passenden nächsten Schritt
Wenn Sie die Anforderungen noch ordnen, beginnen Sie mit dem Planer für Systemintegrationen. Damit erstellen Sie eine Arbeitsbeschreibung von Datenrichtung, Häufigkeit, Ausnahmen und Ergebnisprüfung.
Wenn bereits klar ist, welche Systeme und welcher Prozess verbunden werden sollen, sehen Sie sich unser Angebot für System- und API-Integrationen an. Bei einem größeren Umfang oder vielen Unbekannten können wir mit einer Business-Analyse und Festlegung der ersten Etappe beginnen.
Quellen
- OpenAPI Specification 3.2.1, Zugriff geprüft am 28.10.2026.
- OAuth 2.0, RFC 6749, Zugriff geprüft am 28.10.2026.
- OWASP API Security Top 10, Zugriff geprüft am 28.10.2026.
- GitHub REST API - Anfragelimits, Zugriff geprüft am 28.10.2026. Die GitHub-Dokumentation ist ein Beispiel für die Regeln eines bestimmten Anbieters und keine allgemeine Vorgabe für jede API.