Case Study: Hunderte Stellenanzeigen, halbe Laufzeit — das Geheimnis im Code

Stellen Sie sich vor, Sie sind eine große Unternehmensgruppe mit mehreren Marken, verteilten Standorten und unterschiedlichen Personalabteilungen. Für Bewerbungen nutzen Sie nicht ein System, sondern mehrere. Historisch gewachsen, jede Marke hat ihre eigene Präferenz. Und dann gibt es die Karriereseite, die eigentlich alle Stellen zeigen soll. In Echtzeit. Ansprechend. Durchsuchbar.

Genau dieses Szenario haben wir bei einem unserer Kunden vorgefunden. Hunderte offene Stellen parallel, mehrere Bewerbermanagement-Systeme im Hintergrund, ein hoher redaktioneller Pflegeaufwand und eine Laufzeit je Ausschreibung, die niemand gut fand. Nach der gemeinsamen Arbeit ist die durchschnittliche Laufzeit pro Stellenanzeige halbiert. Das Geheimnis steckt nicht im größeren Budget. Es steckt im Code und in einem sauber automatisierten Prozess.

Ausgangslage

Der Kunde betreibt mehrere Marken unter einem Konzerndach. Für Bewerbungen und Recruiting setzen einzelne Gesellschaften auf unterschiedliche Bewerbermanagement-Systeme — teils aus Lizenzgründen, teils aus historischen Präferenzen der jeweiligen HR-Teams. Die konzernweite Karriereseite lief auf TYPO3 und sollte alle Stellen aus allen Systemen konsolidiert darstellen: filterbar, suchbar, geo­sortiert, mit einheitlichem Look and Feel.

Vor unserem Projekt sah der Alltag so aus: Stellen wurden in den jeweiligen Systemen erfasst. Anschließend wurden sie teilweise manuell, teilweise halbautomatisch auf die Karriereseite übertragen. Dort wurden sie redaktionell nachbearbeitet, mit Marken­bildern versehen und in die passenden Kategorien sortiert. Änderungen in den Quellsystemen landeten oft erst Tage später auf der Karriereseite. Abgelaufene Anzeigen blieben zu lange sichtbar. Die Laufzeit je Stelle war unnötig hoch, weil der Weg vom „Jetzt ausschreiben“ bis zur ersten Bewerbung länger dauerte, als er musste.

Was wir gebaut haben

Ein zentraler Integrations-Layer

Statt für jedes Bewerbermanagement-System einen eigenen Exportweg zu pflegen, haben wir einen zentralen Integrations-Layer geschaffen. Er spricht mit den unter­schiedlichen APIs der HR-Systeme, normalisiert Daten in ein einheitliches Modell — Jobtitel, Standort, Einstieg, Bereich, Kontaktperson, Bewerbungs­link — und legt sie in einer konsolidierten Struktur ab, auf die das TYPO3-System zugreifen kann.

Der entscheidende Punkt: Dieser Layer ist kein neues Fremd­system, für das sich jemand einloggen muss. Er ist Teil der Plattform, standardisiert dokumentiert und Teil unseres Betriebs. Die HR-Teams arbeiten weiter in den Systemen, die sie kennen. Die Brücke zur Karriereseite ist unsichtbar.

Automatisierte Veröffentlichung mit Regeln

Auf Basis des konsolidierten Datenmodells haben wir definierte Regeln implementiert, die festlegen, welche Stellen wann wo sichtbar werden. Dazu gehört der Abgleich mit Marken­zuordnungen, die Berück­sichtigung von Ablaufdaten und die automatische Zuordnung zu Kategorien und Standorten. Stellen erscheinen, sobald sie freigegeben sind, und verschwinden pünktlich — ohne dass jemand daran denken muss.

Multi-Site-Veröffentlichung

Die Karriereseite ist nicht der einzige Ort, an dem die Stellen gezeigt werden. Marken­spezifische Landing Pages, Standort-Mikroseiten und externe Job-Portale werden im selben Zug bedient. Aus einer Datenquelle entsteht der Output für viele Kanäle — ein klassisches Multi-Site-Szenario, das wir als CMS as a Service sauber abgebildet haben.

Automatisiertes Monitoring

Weil im Recruiting jede Stunde zählt, haben wir Monitoring für den gesamten Datenfluss aufgesetzt. Wenn eine API eines Quellsystems ausfällt, bekommt unser Betriebsteam eine Meldung, noch bevor HR oder Redaktion es merken. Wenn eine Anzeige sich nicht erwartungs­gemäß verhält, wird sie sichtbar gemacht.

Ergebnis

Die messbaren Effekte nach Einführung:

Laufzeit je Stellenanzeige halbiert. Vom Erfassen im Quellsystem bis zur Sichtbarkeit auf der Karriereseite und relevanten Portalen verstreichen heute Minuten statt Tage.

Deutlich weniger redaktioneller Aufwand. Das zentrale Team pflegt nicht mehr Inhalte, die es nie erzeugt hat. Korrekturen und Anreicherungen geschehen dort, wo die Daten entstehen.

Höhere Datenqualität. Abgelaufene Stellen werden verlässlich aus der Sichtbarkeit genommen. Dubletten über Kanäle hinweg sind weggefallen.

Mehr Bewerbungen bei gleichem Budget. Schnellere Sichtbarkeit und konsistente Darstellung auf Marken- und Standortseiten haben messbar mehr qualifizierte Bewerbungen ausgelöst.

Was aus unserer Sicht entscheidend war

Zwei Dinge wollen wir betonen, weil sie in vielen ähnlichen Projekten unterschätzt werden. Erstens: Wir haben keine vorhandenen Systeme abgelöst. Wir haben sie verbunden. Jedes HR-System bleibt, wo es ist. Keine neue Lizenz, keine neue Schulung, keine politische Debatte um Marktmacht. Zweitens: Die Automatisierung ist nicht als Einzelprojekt gebaut, sondern als Bestandteil unseres Plattform­betriebs. Wartung, Monitoring und Weiterentwicklung laufen in denselben Prozessen wie Ihr restliches CMS.

Für wen ist das relevant?

Dieses Muster sehen wir nicht nur im Recruiting. Wo immer Sie heute eine konsolidierte Darstellung aus mehreren Quellsystemen brauchen — Produkt­kataloge, Standort­daten, Events, Publikationen — gilt dasselbe Prinzip. Standardisierter Integrations-Layer, klare Regeln, automatisierte Veröffentlichung, Multi-Site-Output.