Integration von HR-Systemen

Kunden, die jetzt eine Integration in Erwägung ziehen, sollten sich genau überlegen, wie ihre langfristigen Anforderungen daran aussehen. Die wird immer wichtiger, weil, von Seiten des Marktes, aber auch von dem Gesetzgeber immer komplexere Anforderungen gestellt werden an viele Prozesse, die heute Unternehmen haben. Und auch mit einer großen, bei großen Anbietern sind die Suits nicht in der Lage, all diese Anforderungen abzudecken. Deshalb gibt es immer mehr Nischenanbieter, die spezielle Themen behandeln und das sehr gut. Und hier ist die einzige Lösung, diese Nischenanbieter mit der Suite zu integrieren, um das Ganze einheitlich nutzen zu können. Wenn man das nicht tut, hat man hohe Opportunitätskosten beziehungsweise doppelte Datenpflege oder andere Formen von Kosten. Das ist also teuer. 

Ja, das Problem lässt sich lösen, wenn wir System A mit B reden lassen. Das heißt, auf technischer Ebene sprechen die Systeme miteinander. Das nennt man dann gemeinhin Integration. Ein Beispiel dafür wäre, SuccessFactors User wird angelegt und der wird gleich in dem Reisekostenabrechnungssystem Concur übertragen, damit die beiden miteinander verknüpft sind. Das würde ich heute als das Problem Nummer Eins im IT Business Kontext sehen. 

Hierbei kann es verschiedene Probleme geben, aber im Wesentlichen kämpft man in der Regel damit, dass in den unterschiedlichen Systemen auch unterschiedliche Datenmodelle vorhanden sind, sodass man hier eine Logik finden muss, um diese anzugleichen. HCM ist sicherlich ein Begriff für alle Zuhörer, hat ein Datenmodell, in dem Personen tatsächlich nur einen Vertrag haben können. 

Das heißt also, so eine Person kann nicht mehrere Verträge haben. Wenn dieser Fall, der ja in der Realität durchaus vorkommt, vorhanden ist, dann muss die Person kopiert werden und diese Personen werden miteinander verknüpft. Wenn das HCM System mit SuccessFactors integriert werden soll, hat man dann aber, ein System vor sich, bei dem das durchaus möglich ist. Da gibt es Personenobjekte, die haben mehrere Verträge zugeordnet, das Ganze ist unabhängig voneinander. Das heißt, bei der Integration muss man schauen, wie gleiche ich diese Diskrepanz aus. 

Hier gibt es einige Dinge zu beachten, sogenannte nichtfunktionale Anforderungen. Dazu gehört Wartbarkeit, Erweiterbarkeit, dass das Ganze von einem Team gemanagt werden kann und nicht von einzelnen Personen abhängig ist. Sicherheit ist ein großer Punkt.

Klassischerweise gibt es die Integrationsmodelle Point-to-Point und Middleware. Point-to-Point ist, System A redet direkt mit System B ohne Umwege. Middleware ist ein System, was immer zwischen solchen Integrationen ist. Das heißt, das Thema A redet mit Middleware, Middleware redet mit System B. Neben diesen klassischen Ansätzen gibt es auch einige Anbieter, die mit neueren Ansätzen experimentieren. API-first sei hier als Stichwort genannt, aber das würde jetzt hier den Rahmen sprengen. Wichtig ist in dem Kontext, dass man, klar sagen kann Middleware ist der Point-to-Point Verbindung überlegen. 

Also als Fazit kann ich sagen, Kunden, die jetzt eine Integration in Erwägung ziehen, sollten sich genau überlegen, wie ihre langfristigen Anforderungen daran aussehen. Und hier ist es klar, besser umsetzbar mit einer Middleware, denn diese gibt einem Rahmenbedingungen vor, um die nichtfunktionalen Anforderungen gut umzusetzen. Und wenn man das nicht beachtet, dann ist es eben so, dass in der Regel die Point-to-Point Verbindungen, die intuitiv gemacht werden, später noch einmal integriert werden müssen über die Middleware. Und dabei kann man leider nicht eins zu eins die Entwicklung übernehmen, sondern muss sie nochmal neu integrieren, sodass recht große Aufwände entstehen. Das heißt, da sollte man sich von vornherein Gedanken machen und gleich die richtige Lösung wählen.