Um zu verstehen, was Kombo leistet, hilft ein Blick auf den Begriff Unified API. Eine gewöhnliche API ist die Programmierschnittstelle eines einzelnen Systems – jedes HR-System, jedes Bewerbermanagement, jede Lohnsoftware hat ihre eigene, mit eigenen Datenfeldern, eigener Authentifizierung und eigenen Eigenheiten. Wer eine Software an zehn solcher Systeme anbinden will, baut klassisch zehn getrennte Integrationen. Eine Unified API legt eine vereinheitlichende Schicht darüber: Sie bietet eine einzige Schnittstelle mit einem gemeinsamen Datenmodell und übersetzt im Hintergrund zwischen dieser einheitlichen Schnittstelle und den vielen individuellen Systemen. Für das anbindende Unternehmen sieht es so aus, als spreche es nur mit einer einzigen Schnittstelle – Kombo kümmert sich darum, dahinter die vielen unterschiedlichen Zielsysteme zu bedienen.
Drei Eigenschaften prägen den Ansatz im Markt:
Die primäre Zielgruppe von Kombo sind Software-Unternehmen. Wer ein HR-nahes Produkt entwickelt – etwa eine Recruiting-Lösung, ein Weiterbildungstool, ein People-Analytics-Werkzeug, eine Zeiterfassung oder eine Benefits-Plattform – steht regelmäßig vor der Anforderung, die eigene Software an die HR-Systeme der Kunden anzubinden. Diese Kunden nutzen die unterschiedlichsten Systeme, und ohne funktionierende Integrationen bleibt jede noch so gute Software eine Insellösung. Kombo adressiert genau diesen Bedarf: Der Software-Anbieter baut einmal gegen die Unified API und kann seinen Kunden damit die Anbindung an viele HR-Systeme anbieten. Daneben ist Kombo auch für HR- und IT-Teams größerer Organisationen interessant, die ihre eigenen Systeme untereinander oder mit selbst entwickelten Anwendungen verbinden wollen. Der Nutzen ist in beiden Fällen derselbe: weniger eigener Integrationsaufwand, schnellere Anbindung neuer Systeme und ein verlässlicher, standardisierter Datenfluss.
Aus Beratungssicht ist eine Unified API wie Kombo dann eine naheliegende Wahl, wenn ein Unternehmen nicht nur ein einzelnes System einmalig anbinden will, sondern viele Systeme anbinden muss oder künftig anbinden wird – und wenn diese Integrationen ein dauerhaftes, sich veränderndes Thema sind. Das ist typischerweise beim Software-Anbieter der Fall, dessen Kunden über die Zeit die unterschiedlichsten HR-Systeme mitbringen. Weniger im Zentrum steht eine Unified API, wenn ein Unternehmen dauerhaft nur genau zwei Systeme verbinden muss und diese Verbindung stabil bleibt – dann kann eine direkte Einzelintegration einfacher und günstiger sein. Der Wert von Kombo entfaltet sich mit der Vielfalt und der Veränderlichkeit der anzubindenden Systeme: Je mehr unterschiedliche Zielsysteme und je stärker der laufende Wartungsbedarf, desto größer der Hebel einer vereinheitlichenden Schicht.
Für einen Software-Anbieter, dessen Produkt mit HR-Daten arbeitet, ist die Integration selten eine einmalige technische Aufgabe, sondern ein Dauerthema. Jeder neue Kunde bringt möglicherweise ein anderes HR-System mit. Jedes dieser Systeme hat eine eigene Schnittstelle mit eigenen Datenfeldern, eigenen Authentifizierungsmechanismen, eigenen Grenzen und eigenen Eigenheiten. Eine einzelne Integration zu bauen, ist machbar; die Herausforderung liegt in der Menge und in der Wartung. Schnittstellen ändern sich, Systeme werden aktualisiert, neue Systeme kommen hinzu. Was als überschaubares Projekt beginnt, wächst zu einem dauerhaften Wartungsaufwand, der Entwicklungskapazität bindet, die eigentlich in das Kernprodukt fließen sollte.
Der wahre Kostenblock von Integrationen liegt selten im ersten Bau, sondern in der Summe und im Betrieb. Angenommen, ein Software-Anbieter will seinen Kunden die Anbindung an viele verbreitete HR-Systeme anbieten: Dann müssen viele Integrationen gebaut, getestet, dokumentiert und dauerhaft gepflegt werden. Jede einzelne bindet Entwicklungszeit, jede kann brechen, wenn sich das Zielsystem ändert, und jede muss überwacht werden. Hinzu kommt, dass die Datenmodelle der Systeme sich unterscheiden – dasselbe Konzept, etwa der Beschäftigungsstatus oder die Kostenstelle, ist in jedem System anders benannt und strukturiert. Der Aufwand steigt damit nicht linear, sondern überproportional, weil zu jeder Anbindung die Übersetzung in das eigene Datenmodell und die laufende Anpassung hinzukommen. Für viele Software-Anbieter ist das der Grund, warum Integrationen chronisch hinter dem Bedarf zurückbleiben und zum Engpass im Vertrieb werden – ein fehlendes System auf der Integrationsliste kann ein Geschäft kosten.
Genau hier setzt das Kernversprechen einer Unified API an: die Reduktion vieler Integrationen auf eine. Statt für jedes Zielsystem eine eigene Anbindung zu bauen, entwickelt das Unternehmen einmal gegen die einheitliche Schnittstelle von Kombo. Die Übersetzung in die vielen unterschiedlichen Systeme, den Umgang mit deren Eigenheiten und einen wesentlichen Teil der laufenden Wartung übernimmt der Unified-API-Anbieter. Für das anbindende Unternehmen bedeutet das dreierlei: erstens einen deutlich geringeren initialen Aufwand, weil nur eine Anbindung entsteht; zweitens eine schnellere Erweiterung, weil neue Zielsysteme über dieselbe Schnittstelle erreichbar werden, ohne dass jedes Mal von vorn begonnen wird; und drittens weniger laufende Wartung, weil ein Teil der Pflege beim Anbieter liegt. Wichtig ist die realistische Einordnung: Eine Unified API nimmt einen großen Teil der Komplexität ab, sie löst sie aber nicht restlos auf – die Eigenheiten einzelner Systeme, die Tiefe der jeweils verfügbaren Daten und die konkrete Abdeckung bleiben ein Thema, das im Einzelfall zu prüfen ist.
Das eigentliche Herzstück einer Unified API ist ihr Datenmodell. Der wahre Schmerz bei Integrationen entsteht nicht nur daraus, dass jedes System eine eigene technische Schnittstelle hat, sondern daraus, dass dieselben fachlichen Konzepte in jedem System anders abgebildet sind. Was in einem HR-System „Mitarbeiter“ heißt, trägt im nächsten einen anderen Namen, hat andere Felder und eine andere Struktur; Abwesenheiten, Verträge, Kostenstellen oder Beschäftigungsstatus sind je System unterschiedlich modelliert. Kombo normalisiert diese Vielfalt in ein gemeinsames, standardisiertes Schema: Das anbindende Unternehmen arbeitet mit einem einheitlichen Modell für Mitarbeiterstammdaten, Abwesenheiten, Stellen, Bewerbungen und weitere HR-Objekte, unabhängig davon, aus welchem konkreten System die Daten ursprünglich stammen. Diese Normalisierung ist der eigentliche Wert – sie erspart es dem Entwicklerteam, für jedes System die Übersetzungslogik selbst zu bauen und zu pflegen. Welche Datenobjekte in welcher Tiefe und für welche Systeme verfügbar sind, unterscheidet sich allerdings; die konkrete Abdeckung gehört zu den wichtigsten Prüfpunkten und sollte anhand der eigenen Anforderungen beim Anbieter geklärt werden.
Ein einheitliches Datenmodell wäre wenig wert, wenn die Daten nur einmalig übertragen würden. Deshalb gehört die laufende Synchronisation zu den zentralen Fähigkeiten. Kombo hält die Daten zwischen den angebundenen Quellsystemen und der eigenen Software aktuell, sodass Änderungen – ein neuer Mitarbeiter, eine geänderte Rolle, eine erfasste Abwesenheit – verlässlich ankommen. Ergänzt wird dies durch Webhooks: Statt dass die anbindende Software ständig nachfragen muss, ob sich etwas geändert hat, meldet die Plattform relevante Ereignisse aktiv. Das reduziert unnötige Abfragen, hält die Daten zeitnah aktuell und ermöglicht ereignisgesteuerte Abläufe – etwa dass ein Prozess automatisch startet, sobald ein neuer Mitarbeiter im HR-System angelegt wird. Zusammen sorgen Synchronisation und Webhooks dafür, dass die integrierten Daten nicht nur einmal, sondern dauerhaft verlässlich fließen. Die genauen Mechanismen, Frequenzen und Grenzen hängen auch vom jeweiligen Quellsystem ab und sind im Einzelfall zu betrachten.
Frühe Unified APIs waren häufig auf das Auslesen von Daten beschränkt; moderne Ansätze unterstützen zunehmend auch schreibende Zugriffe, also das Anlegen oder Aktualisieren von Datensätzen im Zielsystem. Das erweitert den Nutzen erheblich, weil sich damit nicht nur Daten beziehen, sondern auch Prozesse anstoßen lassen. Zugleich ist bei aller Abstraktion ein realistischer Blick angebracht: Eine Unified API kann nur das anbieten, was die dahinterliegenden Systeme über ihre Schnittstellen zulassen. Ist ein bestimmtes Datenobjekt in einem Zielsystem nicht verfügbar oder erlaubt es keinen schreibenden Zugriff, kann auch die beste vereinheitlichende Schicht das nicht ändern. Die Abdeckung ist deshalb je nach Datenobjekt und je nach System unterschiedlich – und genau das ist der Punkt, an dem die Prüfung im konkreten Fall entscheidet. Aus Beratungssicht lohnt es sich, vor einer Festlegung die tatsächlich benötigten Datenobjekte und Schreibvorgänge gegen die Abdeckung der relevanten Systeme abzugleichen, statt sich allein auf das Versprechen der Vereinheitlichung zu verlassen.
Der Zusammenhang lässt sich auf einen einfachen Grundsatz bringen: Automatisierung und KI sind nur so gut wie die Daten, mit denen sie arbeiten. HR-Automatisierungen – vom automatischen Onboarding über Erinnerungen bis zu Freigabeprozessen – und HR-KI – etwa People Analytics, Prognosen oder assistierende Auswertungen – setzen voraus, dass die zugrunde liegenden Daten aktuell, vollständig und in einer verlässlichen, vergleichbaren Struktur vorliegen. Genau diese Grundlage ist im fragmentierten HR-Stack der Engpass: Wenn Daten in vielen Systemen unterschiedlich strukturiert, teils veraltet und nur mit Mühe zusammenführbar sind, scheitern Automatisierung und KI nicht an den Algorithmen, sondern an der Datenbasis. Eine Unified API adressiert diesen Engpass, indem sie die Daten vereinheitlicht und aktuell hält.
Der wichtigste Beitrag einer Unified API zum Thema KI liegt nicht in eigenen KI-Funktionen, sondern in der Datengrundlage. Ein People-Analytics-Werkzeug etwa kann nur dann sinnvolle Auswertungen liefern, wenn es verlässlich und in vergleichbarer Form auf die Personaldaten aus dem HR-System zugreift; ein KI-gestütztes Recruiting-Tool braucht sauberen Zugang zu Bewerbungs- und Stellendaten aus dem Bewerbermanagement. Über eine Unified API wie Kombo erhalten solche Anwendungen die benötigten Daten in einem standardisierten Modell und aktuell gehalten – unabhängig davon, welches konkrete Quellsystem der jeweilige Kunde einsetzt. Das ist der eigentliche, indirekte KI-Bezug: Die Unified API schafft das Fundament, auf dem KI- und Analytics-Anwendungen breit und verlässlich einsetzbar werden, weil sie nicht mehr für jedes Kundensystem eine eigene Datenanbindung bauen müssen. Ob und in welchem Umfang der Anbieter darüber hinaus eigene, unterstützende KI-Funktionen bereitstellt, entwickelt sich in diesem Feld schnell weiter und sollte direkt beim Anbieter geprüft werden.
So sehr eine Unified API die Datengrundlage verbessert, so wichtig ist die realistische Einordnung ihrer Grenzen bei der Datenqualität. Die Plattform vereinheitlicht und übermittelt die Daten – sie kann aber die inhaltliche Qualität der Daten im Quellsystem nicht besser machen, als sie dort ist. Sind Angaben im HR-System unvollständig, veraltet oder fehlerhaft gepflegt, werden sie auch über die Unified API in dieser Qualität ankommen. Eine vereinheitlichende Schicht sorgt für Struktur und Aktualität der Übertragung, nicht für inhaltliche Richtigkeit. Für Automatisierung und KI folgt daraus eine wichtige Sorgfaltspflicht: Die Pflege der Quelldaten bleibt Aufgabe der Organisation, und automatisierte oder KI-gestützte Ergebnisse sind nur so verlässlich wie die dahinterliegenden Daten. Aus Beratungssicht gehört zur Einführung deshalb immer auch der Blick auf die Datenqualität in den Quellsystemen – eine gute Integrationsschicht ist eine notwendige, aber keine hinreichende Bedingung für belastbare Automatisierung und KI.
Die gemeinsame Idee hinter allen Kategorien ist dieselbe: die im jeweiligen Bereich verbreiteten Systeme über eine einheitliche Schnittstelle erreichbar zu machen. Was sich unterscheidet, ist die Art der Daten – Personalstammdaten im HRIS, Bewerbungs- und Stellendaten im Recruiting, Abrechnungsdaten in der Payroll. Für die Auswahl ist die entscheidende Frage, welche Systemkategorien für das eigene Vorhaben relevant sind und ob die konkret benötigten Systeme in ausreichender Tiefe abgedeckt werden.
Die drei tragenden Systemkategorien einer HR-Unified-API sind das HR-Informationssystem, das Bewerbermanagement und die Lohn- und Gehaltsabrechnung. Das HRIS ist für die meisten Anwendungen die wichtigste Quelle, weil hier die grundlegenden Personaldaten liegen – wer ist beschäftigt, in welcher Rolle, in welcher Abteilung, mit welchen Abwesenheiten. Das Bewerbermanagement ist relevant für alle Anwendungen im Recruiting-Umfeld, die mit Stellen, Kandidaten und Bewerbungen arbeiten. Die Payroll schließlich ist die sensibelste Kategorie, weil sie hochvertrauliche Vergütungs- und Abrechnungsdaten berührt und in vielen Ländern besonderen Anforderungen unterliegt. Aus Beratungssicht ist entscheidend, welche dieser Kategorien für das eigene Vorhaben tatsächlich gebraucht werden und ob die konkret benötigten Systeme innerhalb der Kategorie in ausreichender Tiefe abgedeckt sind. Eine breite Kategorienabdeckung nützt wenig, wenn ausgerechnet das für die eigenen Kunden zentrale System fehlt oder nur oberflächlich unterstützt wird.
Ein struktureller Vorteil eines deutschen Anbieters liegt in der Nähe zum DACH-Markt. Der deutschsprachige Raum hat eine eigene, teils sehr fragmentierte HR-Systemlandschaft mit vielen lokal verbreiteten Lösungen, die international ausgerichtete Anbieter nicht immer mit derselben Priorität abdecken. Für ein Unternehmen, dessen Kunden überwiegend im DACH-Raum sitzen und entsprechend lokale HR- oder Lohnsysteme einsetzen, kann die gute Abdeckung genau dieser Systeme den Ausschlag geben. Umgekehrt sollte ein Unternehmen mit stark internationaler Kundschaft prüfen, ob auch die international relevanten Systeme in der benötigten Breite unterstützt werden. Wie bei jeder Unified API gilt: Die abstrakte Aussage „viele Systeme abgedeckt“ ersetzt nicht die konkrete Prüfung, ob die für die eigenen Kunden entscheidenden Systeme dabei sind – mit dieser Prüfung sollte jede Auswahl beginnen. Eine belastbare, aktuelle Übersicht der unterstützten Systeme gibt es nur beim Anbieter selbst.
Die Punkt-zu-Punkt-Integration ist der klassische, direkte Weg: Zwei Systeme werden unmittelbar miteinander verbunden, individuell und ohne Zwischenschicht. Ihr Vorteil ist die maximale Tiefe und Kontrolle – die Integration lässt sich exakt auf die Eigenheiten der beiden Systeme zuschneiden und kann alles nutzen, was deren Schnittstellen hergeben. Ihr Nachteil zeigt sich in der Menge: Wer viele Systeme anbinden will, baut viele solcher Punkt-zu-Punkt-Verbindungen, jede einzeln zu entwickeln und dauerhaft zu warten. Die Unified API kehrt diese Rechnung um: Sie bietet eine einzige Anbindung für viele Systeme und ein gemeinsames Datenmodell, verzichtet dafür aber auf die maximale, individuelle Tiefe jeder einzelnen Verbindung. Aus Beratungssicht ist die Punkt-zu-Punkt-Integration der richtige Weg, wenn genau ein System dauerhaft und in großer Tiefe angebunden werden soll; die Unified API ist überlegen, sobald es um viele Systeme geht oder um Systeme, die man vorab gar nicht alle kennt – wie beim Software-Anbieter, dessen Kunden unterschiedliche Systeme mitbringen.
Eine Integrationsplattform, oft als iPaaS bezeichnet, ist ein anderes Werkzeug für ein anderes Bedürfnis. Sie stellt eine Umgebung bereit, in der Nutzer domänenübergreifend Datenflüsse und Automatisierungen zwischen vielen unterschiedlichen Anwendungen zusammenstellen – vom Marketing über den Vertrieb bis zur Buchhaltung. Ihre Stärke ist die Breite und die freie Gestaltbarkeit: Fast alles lässt sich miteinander verbinden und in Arbeitsabläufe gießen. Der Preis dafür ist, dass die eigentliche Integrationslogik – das Zusammenführen und Übersetzen der Daten – weitgehend selbst gebaut werden muss und dass es kein fertiges, tiefes Datenmodell für eine bestimmte Domäne gibt. Eine Unified API wie Kombo ist demgegenüber bewusst spezialisiert: Sie konzentriert sich auf eine Domäne – hier den HR-Bereich – und liefert dafür ein fertiges, standardisiertes Datenmodell und eine tiefe, gepflegte Abdeckung der Systeme dieser Domäne. Für ein Unternehmen, das genau HR-Systeme in Software integrieren will, ist der spezialisierte Ansatz meist der direktere Weg; wer dagegen breite, domänenübergreifende Automatisierungen über beliebige Geschäftsanwendungen sucht, ist mit einer iPaaS oft besser bedient. Beide Ansätze schließen sich nicht aus – sie lösen unterschiedliche Probleme.
Eine hilfreiche Orientierung für die Auswahl ist das Muster des Integrationsbedarfs. Geht es um eine einzelne, dauerhafte, sehr tiefe Verbindung zwischen zwei bekannten Systemen, spricht viel für Punkt-zu-Punkt. Geht es um viele, teils vorab unbekannte Systeme innerhalb einer Domäne – der klassische Fall des Software-Anbieters im HR-Markt –, ist die Unified API in ihrem Element. Geht es um breite, domänenübergreifende Automatisierungen über sehr unterschiedliche Geschäftsanwendungen hinweg, ist die iPaaS das passende Werkzeug. In der Praxis kommen auch Mischformen vor: Eine Unified API für den HR-Bereich kann neben einer iPaaS für andere Domänen und neben einzelnen tiefen Punkt-zu-Punkt-Verbindungen für besonders kritische Systeme stehen. Aus Beratungssicht sollte die Wahl nicht ideologisch, sondern nach dem konkreten Muster des Bedarfs getroffen werden – die Frage ist nicht, welcher Ansatz grundsätzlich der beste ist, sondern welcher zum jeweiligen Integrationsproblem passt.
Als Software-as-a-Service entfällt bei Kombo der klassische Installationsaufwand: Die Plattform wird als Cloud-Dienst über die API genutzt, die Pflege der einzelnen Systemanbindungen übernimmt der Anbieter im Hintergrund. Die eigentliche Arbeit liegt darin, die eigene Software einmal sauber gegen die Unified API zu entwickeln und den Betrieb der Integrationen zu organisieren. Dabei unterscheiden sich die beiden Zielgruppen: Für den Software-Anbieter ist es ein Produktentwicklungsthema – die Integrationen werden Teil des eigenen Produkts, das die Kunden nutzen. Für ein HR- oder IT-Team, das eigene Systeme verbindet, ist es eher ein internes Integrationsprojekt. In beiden Fällen gilt: Die Technik ist das eine, die Klärung von Abdeckung, Datenschutz und Zuständigkeiten das entscheidende andere.
Die häufigste Ursache für Enttäuschung bei Unified-API-Projekten ist nicht die Technik der Plattform, sondern eine unzureichende Prüfung der Abdeckung. Der Ansatz verspricht, viele Systeme über eine Schnittstelle erreichbar zu machen – aber die Tiefe, in der ein konkretes System und ein konkretes Datenobjekt unterstützt werden, variiert. Wenn ein Unternehmen die Integration aufbaut und erst spät feststellt, dass ausgerechnet das für seine wichtigsten Kunden zentrale System oder das entscheidende Datenfeld nur eingeschränkt verfügbar ist, war die Vorarbeit unvollständig. Umgekehrt zahlt sich eine gründliche Abdeckungsprüfung über die gesamte Nutzungsdauer aus. Aus Beratungssicht lohnt es sich, vor der Festlegung die tatsächlich benötigten Systeme und Datenobjekte explizit zu benennen und gegen die aktuelle Abdeckung des Anbieters abzugleichen – idealerweise mit einem Test gegen die real relevanten Systeme. Diese Sorgfalt am Anfang erspart teure Überraschungen im Betrieb.
Ein Charakteristikum des Unified-API-Modells ist die geteilte Verantwortung im Betrieb. Der Anbieter übernimmt einen wesentlichen Teil der Wartung – die Pflege der einzelnen Systemanbindungen, den Umgang mit Änderungen an deren Schnittstellen, die Aufrechterhaltung der Verbindungen. Das ist einer der größten Vorteile, weil es genau die laufende Last abnimmt, die bei Einzelintegrationen so aufwendig ist. Zugleich verbleibt Verantwortung beim anbindenden Unternehmen: die eigene Software gegen die API sauber zu entwickeln und zu pflegen, den Verbindungsprozess für die Endkunden zu gestalten, das Monitoring zu betreiben und auf Fehler zu reagieren, und – besonders wichtig – die datenschutzrechtliche Ausgestaltung im eigenen Verantwortungsbereich zu sichern. Aus Beratungssicht sollte diese Aufteilung von Beginn an klar sein: Eine Unified API reduziert den Betriebsaufwand erheblich, macht ihn aber nicht zu null. Wer die verbleibenden Aufgaben – Monitoring, Fehlerbehandlung, Datenschutz – von Anfang an einplant, betreibt die Integration stabil.
Der gemeinsame Nenner dieser Unternehmen ist, dass sie einen echten Integrationsbedarf haben, aber nicht die Entwicklungsressourcen eines Konzerns, um beliebig viele Einzelintegrationen zu bauen und zu pflegen. Für den mittelständischen Software-Anbieter ist die HR-Integration oft geschäftskritisch – ohne die Anbindung an die Systeme der Kunden bleibt das Produkt schwer verkäuflich, doch jede zusätzliche Integration bindet knappe Entwicklungszeit, die im Kernprodukt fehlt. Für das mittelständische HR-Team wiederum ist die Verbindung der eigenen Systeme häufig ein wiederkehrendes Ärgernis, das intern kaum sauber zu lösen ist. Genau in diesem Spannungsfeld liegt die Kernbegründung für eine Unified API, die den Integrationsaufwand bündelt und beherrschbar macht.
Der Nutzen lässt sich konkret benennen, auch ohne pauschale Prozentversprechen: Eine Unified API senkt die Schwelle, überhaupt viele Systeme anzubinden, weil sie den wiederkehrenden Bau und die Pflege von Einzelintegrationen ersetzt. Für den mittelständischen Software-Anbieter bedeutet das schnellere Integrationen, eine breitere Systemabdeckung als Verkaufsargument und mehr freie Entwicklungskapazität für das Kernprodukt. Für das HR- oder IT-Team bedeutet es einen verlässlichen, standardisierten Datenfluss ohne die Last, jede Verbindung selbst dauerhaft zu warten. Zugleich stehen diesen Vorteilen laufende Kosten und die Abhängigkeit von einem Integrationspartner gegenüber – auch das gehört ehrlich in die Abwägung. Ob und wie stark sich der Einsatz lohnt, hängt von der Zahl der anzubindenden Systeme, der Veränderlichkeit des Bedarfs und dem Wert der eingesparten Entwicklungszeit ab. Diese Abwägung sollte anhand der eigenen Situation getroffen werden, nicht anhand allgemeiner Versprechen.
Für viele Mittelständler ist die eigentliche Entscheidung nicht die zwischen zwei Produkten, sondern die grundsätzlichere Frage: die Integrationen selbst bauen und pflegen oder über eine Unified API beziehen? Eine hilfreiche Orientierung: Je mehr unterschiedliche Systeme angebunden werden müssen, je stärker sich dieser Bedarf über die Zeit verändert und je knapper die eigene Entwicklungskapazität, desto eher spricht es für die Unified API. Je konzentrierter der Bedarf auf ein einzelnes, stabil bleibendes System und je größer die geforderte individuelle Tiefe, desto eher kann eine eigene, direkte Integration sinnvoll sein. Häufig ist auch hier ein Nebeneinander tragfähig: eine Unified API für die Breite der Systeme und eine tiefe Eigenintegration für ein besonders kritisches System. Aus Beratungssicht sollte diese Grundsatzentscheidung bewusst getroffen werden – anhand der Zahl und Vielfalt der Systeme, des Werts der eigenen Entwicklungszeit und der eigenen Datenschutzanforderungen.
Kombo wird als cloudbasierte Plattform bereitgestellt. Die Preislogik solcher Unified-API-Dienste orientiert sich typischerweise am Umfang der Nutzung – etwa an der Zahl der aktiven Verbindungen, der angebundenen Endkunden oder dem Nutzungsvolumen –, häufig ergänzt um unterschiedliche Pläne je nach Funktionsbedarf. Konkrete Beträge und die genaue Staffelung sind hier bewusst nicht genannt, weil sie sich ändern und vom individuellen Zuschnitt abhängen; die aktuellen Konditionen sollten direkt beim Anbieter eingeholt werden. Belastbare Zahlen ergeben sich erst aus dem eigenen Anwendungsfall – aus der Zahl der Verbindungen, den benötigten Systemkategorien und dem gewünschten Funktionsumfang. Wirtschaftlich sinnvoll ist die Betrachtung nicht des reinen Plattformpreises, sondern des Vergleichs mit der Alternative: dem Aufwand, die entsprechenden Integrationen selbst zu bauen und dauerhaft zu pflegen.
Die Kosten einer Unified API bestimmen sich vor allem aus dem Umfang der Nutzung, den benötigten Systemkategorien und dem gewünschten Funktionsumfang. Im Internet kursierende Richtwerte sind mit Vorsicht zu genießen, weil sie diese Faktoren und die individuellen Pläne selten sauber abbilden. Aus Beratungssicht ist der entscheidende Schritt nicht das Vergleichen von Listenpreisen, sondern die ehrliche Gegenüberstellung mit dem Eigenbau: Was würde es kosten, die benötigten Integrationen selbst zu entwickeln – und, viel wichtiger, dauerhaft zu warten? Gerade der laufende Wartungsaufwand vieler Einzelintegrationen wird regelmäßig unterschätzt, weil er nicht als einmalige Investition, sondern als dauerhafte Belastung der Entwicklungsteams auftritt. Für Unternehmen mit vielen und sich verändernden Systemen ist eine Unified API in dieser Gesamtbetrachtung häufig deutlich wirtschaftlicher; bei nur einem einzigen, stabilen System kann sich die Rechnung umkehren. Konkrete Konditionen sollten stets direkt beim Anbieter eingeholt und im Verhältnis zur eigenen Situation bewertet werden.
Über eine HR-Unified-API fließen personenbezogene Daten von Beschäftigten – teils bis hin zu hochsensiblen Vergütungs- und Abrechnungsdaten. Datenschutz ist hier keine Nebensache, sondern eine Kernanforderung. Genau an diesem Punkt liegt ein struktureller Vorteil von Kombo: Als deutscher, in der EU verankerter Anbieter kann Kombo die Verarbeitung personenbezogener Daten im europäischen Rechtsraum anbieten und die DSGVO-Konformität sowie die Datenhoheit als Kernversprechen führen. Viele bekannte Unified-API-Anbieter im HR-Bereich stammen aus dem außereuropäischen Ausland; bei ihnen stellen sich zusätzliche Fragen zum Verarbeitungsort und zu einem möglichen Drittlandtransfer. Ein EU-Anbieter mit Verarbeitung im europäischen Raum hat hier strukturell weniger zu erklären – die europäische Datenverarbeitung ist aus DSGVO-Sicht die konformere Ausgangslage. Für europäische Unternehmen, denen die Souveränität über ihre HR-Daten wichtig ist, kann das ein entscheidendes Auswahlkriterium sein. Gleichwohl bleibt die konkrete Ausgestaltung wichtig: Ein Auftragsverarbeitungsvertrag, die klare Festlegung des Verarbeitungsorts, ein durchdachtes Zugriffs- und Löschkonzept und die technisch-organisatorischen Maßnahmen sind unabhängig von der Herkunft des Anbieters zu regeln und zu dokumentieren.
Über die rein rechtliche Konformität hinaus verdient die Datenhoheit eine strategische Betrachtung. Wer personenbezogene HR-Daten über eine Integrationsschicht bewegt, gibt diese Daten durch die Hände eines Dienstleisters – die Frage, welchem Rechtsraum dieser Dienstleister unterliegt und wo die Daten verarbeitet werden, ist damit keine technische Detailfrage, sondern eine strategische. Für viele europäische Unternehmen, gerade im Mittelstand, gewinnt die digitale Souveränität an Bedeutung: die bewusste Entscheidung, kritische Datenflüsse nicht von außereuropäischen Diensten und deren Rechtsrahmen abhängig zu machen. Ein deutscher, EU-verankerter Anbieter wie Kombo bedient genau dieses Bedürfnis und kann die EU-Souveränität als Stärke ins Feld führen. Aus Beratungssicht ist dies ein legitimes und zunehmend wichtiges Auswahlkriterium – es sollte allerdings gemeinsam mit den funktionalen Kriterien wie Systemabdeckung und Datentiefe abgewogen werden, nicht anstelle davon. Die konkrete datenschutzrechtliche Bewertung des Einzelfalls gehört in fachkundige Hände.
