HR-Tech Realität: Warum wir uns oft zwischen "Sexy" und "Stabil" entscheiden müssen

"Warum sieht unsere HR-Software eigentlich nicht so aus wie Instagram?" "Warum kann ich dieses eine Feld nicht einfach ausblenden, je nachdem wer draufschaut?"

Diese Fragen höre ich oft. Und sie sind berechtigt! Wir alle sind privat an Apps gewöhnt, die intuitiv, schnell und schick sind. Wenn wir dann im Büro unser HR-System öffnen, fühlt sich das oft an wie eine Zeitreise.

Aber das liegt nicht daran, dass die IT keine Lust auf schöne Oberflächen hat. Es liegt an der Architektur unter der Motorhaube. Um zu verstehen, warum wir an Grenzen stoßen, müssen wir zwei Welten betrachten: Den Monolithen und die Microservices.

Der Tanker vs. der Drohnenschwarm

HR-Kernsoftware (bspw. Loga HR oder das klassisches SAP HCM) ist ein Monolith. Stellt euch einen riesigen Container-Tanker vor.

• Vorteil: Er transportiert unfassbare Lasten sicher von A nach B. Alles ist fest verbaut, der Motor ist riesig, der Rumpf ist stabil.

• Nachteil: Er ist nicht wendig. Wenn man die Farbe der Reling ändern will, muss man gefühlt das ganze Schiff ins Trockendock holen.

Moderne, spezialisierte Recruiting-Tools sind dagegen wie ein Schwarm von Drohnen (Microservices).

• Vorteil: Jede Drohne kann sofort die Richtung ändern, bunt leuchten und Loopings fliegen.

• Nachteil: Sie können keine schweren Container tragen. Und: Jemand muss diesen Schwarm steuern, damit sie nicht zusammenstoßen.

Das Problem mit den "Schweren Daten"

Warum nutzen wir dann nicht einfach die Drohnen (Microservices)? Weil HR nicht nur aus "leichten Daten" besteht.

1. Leichte Daten (Recruiting & Talent): Ein Name, eine E-Mail, ein Lebenslauf. Das sind Daten, die unkritisch sind. Hier wünschen wir uns "Sexy Oberflächen", Drag-and-Drop und bunte Dashboards. Hier glänzen die Microservices.

2. Schwere Daten (Payroll & Zeit): Jetzt wird es kompliziert. Steuerklassen, SV-Nummern, Tarifgruppen, Pfändungsfreigrenzen, Durchschnittsberechnungen für Urlaubsentgelt. Das sind "Schwere Daten". Wenn hier ein Fehler passiert, bekommt der Mitarbeiter kein Geld oder wir bekommen Ärger mit dem Finanzamt.

Das Architektur-Dilemma: In einem Monolithen (unserem Tanker) sind die leichten und die schweren Daten tief miteinander verdrahtet. Es gibt nur eine Datenbank.

Ein bewusst dummes Beispiel (Am Ende findet ihr Reale Beispiele aus der Praxis): Der Fachbereich wünscht sich: "Im Feld 'Eintrittsdatum' soll im Recruiting einfach nur der Monat stehen, der Tag ist noch egal." (Usability-Wunsch).

Die IT sagt: "Können wir nicht machen."

Warum? Weil im Monolithen dieses Feld "Eintrittsdatum" direkt mit der Lohnabrechnungs-Logik verknüpft ist. Wenn wir dort erlauben, nur "April 2025" einzutragen statt "01.04.2025", stürzt im Hintergrund die Berechnung für die anteilige Sozialversicherung ab. Wir opfern also die "Flexibilität der Oberfläche" für die "Stabilität der Abrechnung".

Man kann alles haben – aber es kostet ein Vermögen

Jetzt sagt ihr vielleicht: "Aber Google oder Netflix haben doch auch Systeme, die beides können!"

Ja. Aber diese Unternehmen kaufen keine Standard-Software von der Stange. Sie bauen sich eine Microservice-Architektur. Sie nutzen ein Tool für Payroll, eins für Recruiting, eins für Zeit – und verbinden alles mit einer selbstgebauten Integrationsschicht.

Um so eine Architektur zu betreiben, braucht man aber nicht 3 IT-Admins, sondern ganze Heerscharen von Spezialisten:

• DevOps-Engineers, die die Schnittstellen bauen.

• Frontend-Entwickler, die die Oberflächen designen.

• Security-Experten, die aufpassen, dass beim Datenfluss zwischen den Tools nichts verloren geht.

Fazit: Warum der Tanker oft die klügere Wahl ist

Hand aufs Herz: Die meisten Unternehmen sind nicht Google, Spotify oder Netflix. Wir sind Händler, Produzenten oder Dienstleister. Unser Kerngeschäft ist es, Waren zu verkaufen oder Services anzubieten – und nicht, komplexe Software-Architekturen zu unterhalten.

Für das "klassische Unternehmen" ohne Silicon-Valley-Budget ist die Entscheidung für den Monolithen (den Tanker) keine Entscheidung gegen Innovation, sondern eine Entscheidung für Wirtschaftlichkeit und Sicherheit.

Die Rechnung ist simpel: Eine schicke Microservice-Architektur, in der jedes Feld bunt und flexibel ist, erkauft man sich mit massiven laufenden Kosten für Schnittstellen, Wartung und IT-Personal. Der Monolith hingegen wirkt vielleicht an manchen Ecken starrer und weniger "sexy", aber er garantiert das, was am Ende des Tages zählt: Prozess-Sicherheit zu kalkulierbaren Kosten.

Wir verzichten also bewusst auf die "kreative Freiheit" in der Oberfläche, um sicherzustellen, dass die Lohnabrechnung und die Stammdaten ohne eine Armee von Entwicklern stabil laufen. Wir holen das Beste aus dem Standard heraus – wohlwissend, dass Stabilität in unserer Branche wichtiger ist als App-Design.

Beste Grüße Uwe

Achso, braucht ihr Hilfe, dann meldet euch gerne bei mir :) Hier der Link

...Beispiele aus der Praxis. such dir das aus, das besser zu eurer internen Diskussion passt:

Beispiel: Der "Jobtitel vs. Tarifgruppen"-Klassiker (Mein Favorit)

Dieses Beispiel verstehen Fachbereiche sofort, weil sie oft "coole" Titel für Stellenanzeigen wollen, das System aber im Hintergrund eine starre Logik braucht.

Ein Beispiel aus der Praxis: Der Fachbereich wünscht sich im Recruiting ein Freitext-Feld für den Jobtitel, um flexibel zu sein: "Lass uns da 'Sales Assistant' oder 'Verkaufstalent' reinschreiben können, je nachdem was besser klingt."

Die IT sagt: "Geht nicht. Wir brauchen ein starres Dropdown-Menü."

Warum? Weil im Monolithen der Jobtitel direkt mit der Tarifgruppe und der Stellenbewertung verknüpft ist. Wenn wir dort Freitext erlauben, weiß die Lohnabrechnung im Hintergrund nicht mehr: "Ist das jetzt Tarifgruppe A oder B? Bekommt der Weihnachtsgeld?" Ein "Verkaufstalent" kennt das System nicht – es kennt nur "Verkäufer in Vollzeit, Gr. 2". Wir opfern die kreative Freiheit für die Sicherheit, dass am Ende automatisch das richtige Gehalt überwiesen wird.

---

Beispiel: Das "Jahresgehalt vs. Stundenlohn"-Problem

Das ist super, um zu zeigen, wie komplex Payroll eigentlich ist.

Ein Beispiel aus der Praxis: Ein Recruiter möchte im Einstellungsformular einfach ein Feld "Jahreszielgehalt" haben und dort z.B. "40.000 €" eintragen. Das System soll den Rest machen.

Die IT sagt: "Nein, wir müssen Stundenlohn und Wochenstunden einzeln erfassen."

Warum? Weil der Monolith wissen muss: Sind in den 40.000 € schon Urlaubsgeld und Weihnachtsgeld drin? Wie hoch ist der Grundstundenlohn für die Berechnung von Zuschlägen bei Spätschichten? Würden wir nur die pauschale Summe durchlassen, würde die automatische Berechnung von Nachtzuschlägen in der Payroll crashen. Die "schweren Daten" (Zuschlagsberechnung) diktieren hier, wie wir die "leichten Daten" (Gehaltswunsch) eingeben müssen.