Das Wichtigste in 30 Sekunden
Nicht jeder Datenaustausch braucht eine laufende Schnittstelle. Entscheidend ist, wie schnell eine Änderung im zweiten System ankommen muss und wie viel Handarbeit ein Export verursacht.
- Definiere Datenumfang und benötigte Aktualität.
- Lege je Feld ein führendes System fest.
- Bestimme, wer Fehler erkennt und den Abgleich verantwortet.
Wann lohnt sich eine Schnittstelle und wann reicht ein Export?
Eine Schnittstelle lohnt sich, wenn dieselben Daten mehrmals täglich in beiden Systemen aktuell sein müssen. Ein Export reicht, wenn ein Abgleich pro Tag oder pro Woche genügt und der Umfang überschaubar bleibt. Entscheidend ist nicht die Menge, sondern wie schnell eine Änderung ankommen muss.
Diese Frage klingt technisch und ist eine Ablauffrage. Ein Kandidat, dessen Verfügbarkeit sich ändert, muss im Vertrieb sofort sichtbar sein. Eine Stammdatenänderung beim Kunden verträgt einen Tag. Beides über denselben Weg zu lösen, ist entweder zu teuer oder zu langsam.
Auf einen Blick
| Weg | Trägt bei | Kostet | Typischer Fehlerfall |
|---|---|---|---|
| Dauerhafte Schnittstelle | mehrfach täglicher Abgleich, beidseitige Änderungen | Einrichtung und laufende Pflege | Fehler wirken sofort in beiden Systemen |
| Regelmäßiger Export | täglicher oder wöchentlicher Abgleich, eine Richtung | wenig, aber wiederkehrende Handarbeit | Der Export wird vergessen und niemand merkt es |
| Manuelle Übertragung | Einzelfälle und Ausnahmen | Zeit je Vorgang | Tippfehler und veraltete Stände nebeneinander |
Die dritte Zeile ist die teuerste und die häufigste. Sie taucht in keiner Rechnung auf, weil sie als Arbeitszeit anfällt und nicht als Position. Deshalb bleibt sie oft jahrelang bestehen.
Es lohnt sich, sie einmal zu beziffern. Zähl, wie oft eine Angabe pro Woche von Hand von einem System ins andere übertragen wird und multipliziere mit der benötigten Zeit und dem internen Stundensatz.
Diese Zahl ist meist höher als die Einrichtungskosten einer Verbindung. Sie fällt außerdem jedes Jahr erneut an, während die Einrichtung einmalig ist.
Wo entsteht Doppelpflege im Alltag?
Überall dort, wo dieselbe Angabe an zwei Stellen gepflegt wird, ohne dass eine davon führend ist. Typisch sind Kandidatenstammdaten zwischen Recruiting und Abrechnung, Kundendaten zwischen Vertrieb und Faktura sowie Einsatzorte, die im einen System als Adresse und im anderen als Textfeld geführt werden.
Der Schaden zeigt sich selten sofort. Er zeigt sich, wenn zwei Stände auseinanderlaufen und niemand weiß, welcher stimmt. Ab diesem Punkt prüft jeder Mitarbeitende sicherheitshalber beide Systeme und der Zeitgewinn aus der Verbindung ist aufgebraucht.
Die Lösung ist unspektakulär und liegt vor der Technik. Je Datenfeld wird ein führendes System festgelegt. Alles andere ist eine Kopie und wird dort nicht bearbeitet.
Dokumentiert diese Festlegung je Datenbereich und prüft sie anhand konkreter Änderungen. Der verlinkte Beitrag Schnittstellen planen beschreibt das Vorgehen im Detail.
Besonders klar wird das beim Einsatzort. In der Zeitarbeit hat ein Kunde häufig mehrere Werke mit unterschiedlichen Anfahrten. Wird der Ort im einen System als eigener Datensatz und im anderen als freier Text geführt, lässt er sich nicht abgleichen.
Der Einsatzort ist der tatsächliche Arbeitsort beim Kunden. Er muss für Suche, Anfahrt und Einsatzplanung eindeutig hinterlegt sein.
Was gehört vor der Einrichtung geklärt?
Vier Punkte: welches System für welches Feld führend ist, in welcher Richtung Daten fließen, was bei einem Fehler passiert und wer ihn bemerkt. Der vierte Punkt wird am häufigsten vergessen und verursacht den größten Teil des Ärgers im laufenden Betrieb.
Fehler sind bei einer Verbindung zwischen zwei Systemen der Normalfall und kein Ausnahmezustand. Ein Feld ändert sein Format, ein Pflichtwert fehlt, eine Kennung ist doppelt vergeben. Entscheidend ist nicht, dass das nie passiert, sondern dass es jemand am selben Tag sieht.
Ohne diese Rückmeldung entsteht der schlimmste Fall: Die Verbindung läuft scheinbar, überträgt aber seit Wochen nichts. Dieselbe Logik gilt für Feeds an Jobbörsen. Ein Jobfeed überträgt strukturierte Stelleninformationen an einen Kanal. Prüfe Annahme, Fehlermeldungen und die Aktualität veröffentlichter Stellen.
Der vierte Punkt betrifft die Zuständigkeit im Fehlerfall. Zwei Anbieter zeigen im Zweifel aufeinander. Deshalb gehört vor der Einrichtung festgelegt, wer bei einer Störung den ersten Anruf bekommt und wer den Vorgang bis zur Lösung führt.
Dieser Punkt gehört in den Vertrag und nicht in eine E-Mail. Er kostet in der Verhandlung nichts und spart im ersten Störungsfall mehrere Tage. Wer ihn offenlässt, verhandelt ihn genau dann, wenn das System steht und alle unter Druck sind.
Wie sieht das an einem konkreten Beispiel aus?
Ein Beispiel aus dem Alltag
Bei zvoove ist die Schnittstellendokumentation für Recruit nach dem Login über die eigene Adresse mit dem Zusatz /swagger erreichbar. Der API-Schlüssel wird im Hub unter Kundenbereich, Service, API-Schlüssel erstellt. Im Paket ist ein Basiskontingent an Aufrufen enthalten, weitere Pakete sind buchbar.
Beides steht in der Dokumentation des Anbieters. Zur Erreichbarkeit heißt es bei zvoove: „Eine ausführliche Schnittstellendokumentation rufen Sie nach erfolgtem Login in zvoove Recruit auf, indem Sie dazu Ihre URL mit /swagger ergänzen.“
Die Produktseite zur zvoove API nennt Personaldaten, Einsatzpläne, Abrechnungsinformationen, Bewerberprofile, Zeiterfassungsdaten, Dispositionsinformationen und CRM-Daten als Bereiche.
Das Kontingent ist dabei die Größe, die in der Planung am häufigsten übersehen wird. Eine Verbindung, die jede Änderung einzeln überträgt, verbraucht mehr Aufrufe als eine, die einmal pro Stunde abgleicht.
Diese Entscheidung gehört an den Anfang und nicht in den ersten Monat nach der Einrichtung. Wie eine solche Konstellation aussieht, steht unter Integrationen.
Was ändert sich durch die neue Rechtslage?
Beim Wechsel eines Anbieters entfällt eine Kostenposition. Ab dem 12. Januar 2027 entfallen die vom Data Act erfassten Wechselentgelte einschließlich der Entgelte für den Datenabfluss.
Ob der konkrete Dienst und die verlangte Leistung darunterfallen, ist vorab zu prüfen. Daraus folgt kein kostenloses Gesamtprojekt: Einführung, Datenbereinigung und eigenständige Zusatzleistungen müssen gesondert betrachtet werden.
Das betrifft allerdings nur den Auszug und nicht die laufende Verbindung zwischen zwei Systemen im Betrieb.
Die beiden Daten stehen in der Erläuterung der Europäischen Kommission zum Data Act, der seit dem 12. September 2025 gilt. Für die laufende Schnittstelle ändert sich dadurch nichts. Was du dafür zahlst und welche Kontingente gelten, bleibt Vertragsgegenstand.
Praktisch heißt das: Die Frage nach der Verbindung und die Frage nach dem Auszug sind zwei verschiedene Verhandlungen. Wie sich die zweite ab Januar 2027 verändert, behandelt Was der EU Data Act für Softwarewechsel praktisch verändert.
Was solltest du zuerst festlegen?
Nimm die fünf Felder, die in deinem Betrieb am häufigsten doppelt gepflegt werden. Bestimme für jedes ein führendes System. Danach entscheide je Feld, ob eine Schnittstelle nötig ist oder ein täglicher Export genügt. Diese Reihenfolge spart Geld, weil sie die Zahl der nötigen Verbindungen senkt.
- Führendes System je Feld. Ohne diese Festlegung erzeugt jede Verbindung neue Konflikte statt weniger Arbeit.
- Richtung festlegen. Einseitig ist einfacher, günstiger und in den meisten Fällen ausreichend.
- Fehlerweg benennen. Wer wird informiert, wie schnell und wer führt den Vorgang.
- Kontingent prüfen. Bei API-basierten Verbindungen gehört die Zahl der Aufrufe von Anfang an in die Planung und nicht in die erste Rechnung.
Eine ergänzende Einordnung mit Vorgehen und Checkliste steht im verlinkten Beitrag Schnittstellen planen. Hier steht nur, wann welcher Weg trägt.
Welche Quellen liegen der Einordnung zugrunde?
Die Angaben zur zvoove API stammen aus der Dokumentation des Anbieters, die Datumsangaben zum Data Act aus der Erläuterung der Europäischen Kommission. Die Einordnung zu Aufwand und Fehlerfällen ist eine betriebliche Einschätzung und kein Messergebnis.
- zvoove: Schnittstellendokumentation für zvoove Recruit · Zugang über
/swagger - zvoove API · API-Schlüssel, Basiskontingent und abgedeckte Datenbereiche
- Data Act explained · Europäische Kommission · Geltung und Wegfall der Wechselentgelte
