Der HR-Tech-Konflikt: Warum wir bei Software-Demos aufhören müssen, den Boten zu erschießen

Hand aufs Herz: Wer schon einmal in einer Software-Präsentation für ein neues HR-System saß, kennt diese Szene. Vorne schwitzt ein Vertriebler oder Consultant und klickt sich durch das Recruiting-Modul eines großen HR-Suite-Anbieters. Hinten sitzen die Recruiter und verdrehen die Augen.

"Das ist total unübersichtlich!" "Warum sieht das nicht aus wie bei [Name eines hippen Start-up-Tools]?" "Das ist doch nicht State of the Art!"

Die Stimmung kippt, der Vertriebler wird in die Mangel genommen, und am Ende verlässt das HR-Team den Raum mit dem Gefühl: Die haben ja gar keine Ahnung, was wir im Recruiting brauchen.

Aber ist das fair? Nein. Es offenbart vielmehr ein tiefes Missverständnis über Software-Architektur – und einen Mangel an Verhandlungskultur. Zeit, die Dinge ins rechte Licht zu rücken.

Der Apfel-Birnen-Vergleich: Spezialist vs. Full-Vendor

Das Hauptproblem in solchen Terminen ist die Erwartungshaltung. Viele HR-Mitarbeiter kennen aus ihrem Alltag hervorragende Best-of-Breed-Lösungen. Das sind hochspezialisierte Recruiting-Tools, die auf einer modernen Microservice-Architektur basieren. Sie können nichts anderes als Bewerbermanagement, aber das machen sie in Perfektion. Sie sind agil, bunt und intuitiv.

Ein Full-Vendor (also ein integriertes System für Payroll, Zeiterfassung, Stammdaten und eben auch Recruiting) ist hingegen meist ein Monolith. Es ist ein riesiger Tanker, der darauf ausgelegt ist, komplexe "schwere Daten" wie Tarifverträge, Steuerklassen und Pfändungsfreigrenzen unfallfrei zu verarbeiten.

Wenn dieser Tanker nun auch noch eine Kabine für das Recruiting anbauen muss, sieht diese Kabine eben nicht aus wie das Cockpit eines Rennboots. Die Oberflächen sind oft starrer, weil im Hintergrund das Datenmodell der Gehaltsabrechnung dranhängt.

Wer von einem monolithischen Komplettsystem verlangt, dass es im Recruiting exakt so aussieht und funktioniert wie eine isolierte Spezial-Software, hat die Gesetze der IT-Architektur nicht verstanden. Man kann nicht die nahtlose Integration und Prozesssicherheit eines Monolithen fordern, aber gleichzeitig die ungebundene Flexibilität eines Microservices erwarten – jedenfalls nicht, ohne Millionenbudgets für eigene IT-Entwickler in die Hand zu nehmen.

Das Harvard-Konzept: Mensch und Maschine trennen

Genau hier kommt das Problem ins Spiel, das mich an vielen Software-Demos stört: Die persönliche Ebene.

Im weltbekannten Harvard-Konzept des Verhandelns lautet der allererste Grundsatz: "Trenne die Menschen von dem Problem." In der HR-IT heißt das: Trenne den Menschen von der Software-Architektur.

Der Vertriebler oder Consultant, der vorne steht, hat den Monolithen nicht programmiert, um Recruiter zu ärgern. Er präsentiert die Realität eines integrierten Systems, das Kompromisse eingehen muss, damit am Ende des Monats 36.000 Mitarbeiter fehlerfrei ihr Gehalt bekommen. Wenn wir diesen Menschen anfeinden, weil ein Dropdown-Menü nicht dynamisch aufploppt, verhalten wir uns unprofessionell.

Anstatt in eine Abwehrhaltung zu gehen und den "Boten zu erschießen", sollten wir das Problem sachlich angehen.

Wie ein konstruktiver Dialog aussieht

Wenn die Maske im System sperrig ist, sollten wir die Emotionen herausnehmen und uns auf die Interessen konzentrieren (ein weiterer Punkt aus dem Harvard-Konzept!).

• Falsch: "Ihre Software ist eine Katastrophe, da klickt sich doch kein Bewerber durch!"

• Richtig: "Wir sehen, dass die Maske hier Grenzen hat. Unser Interesse ist es, die Absprungrate der Bewerber niedrig zu halten. Welche Workarounds oder Best-Practices haben andere Kunden mit diesem System gefunden, um das zu lösen?"

Fazit: Respekt vor der Komplexität

Die eierlegende Wollmilchsau der HR-IT gibt es nicht. Entweder wir kaufen ein Flickenteam aus Spezialisten und bauen uns für teures Geld die Schnittstellen selbst (und hoffen, dass sie nicht brechen). Oder wir entscheiden uns für das Komplettsystem, den Monolithen.

Wenn wir uns für Letzteres entscheiden, müssen wir akzeptieren, dass Stabilität manchmal auf Kosten der "Sexyness" geht. Und wir sollten den Software-Vertretern, die uns diese komplexen Maschinen erklären, mit dem Respekt begegnen, den sie verdienen. Mensch und Software zu trennen, ist nicht nur fairer – es führt am Ende auch zu viel besseren IT-Projekten.