Konfigurationstiefe von HR-Software: Wo endet Einstellung, wo beginnt Customizing?

Was bedeutet „Konfigurationstiefe“ bei HR-Software genau?

Konfigurationstiefe beschreibt, wie umfassend sich eine HR-Software an unternehmensspezifische Prozesse anpassen lässt, ohne dass dafür Programmcode außerhalb der vom Hersteller vorgesehenen Einstellungswerkzeuge geschrieben werden muss. Eine hohe Konfigurationstiefe bedeutet, dass Rollenmodelle, Workflows, Formularfelder und Auswertungen von Fachanwenderinnen und Fachanwendern selbst über Admin-Oberflächen eingerichtet werden können. Eine geringe Konfigurationstiefe zeigt sich daran, dass für vergleichsweise einfache Anpassungen bereits externe Entwicklungsressourcen benötigt werden. Der Begriff ist damit ein praktisches Kriterium für die technische Zukunftssicherheit einer Softwareentscheidung, nicht nur ein Vertriebsargument. Er gilt für Enterprise-Suiten wie Mittelstands-typische Systeme gleichermaßen, auch wenn das erwartbare Ausgangsniveau unterschiedlich ist.

Was ist der genaue Unterschied zwischen Konfiguration und Customizing?

Konfiguration nutzt ausschließlich vom Hersteller dokumentierte, im Lieferumfang enthaltene Einstellungsmechanismen wie Rollen-Editoren, Workflow-Designer oder Business-Rules-Oberflächen und bleibt dabei innerhalb des unterstützten Datenmodells. Customizing erzeugt zusätzlichen, individuellen Programmcode außerhalb dieser Mechanismen (etwa eigene Skripte, Datenbankerweiterungen oder Middleware-Logik), selbst wenn dieser Code technisch innerhalb der Softwareoberfläche eingegeben wird. Der entscheidende Test ist, ob die Anpassung beim nächsten Release automatisch mitgeführt wird (Konfiguration) oder erneut manuell angepasst und getestet werden muss (Customizing).

Warum gilt starke Konfiguration bei Cloud-HR-Software als vorteilhafter als Customizing?

Cloud-HR-Systeme werden zentral vom Hersteller mehrfach jährlich aktualisiert: Workday etwa mit zwei verpflichtenden Hauptreleases pro Jahr im März und September, SAP SuccessFactors mit vergleichbaren Halbjahresreleases (Beispielbezeichnung: 1H/2H, konkrete Termine variieren je Release). Konfigurationen, die innerhalb der offiziellen Werkzeuge liegen, werden vom Hersteller bei diesen Updates automatisch mitgetestet und migriert. Individueller Code außerhalb dieser Werkzeuge muss dagegen bei jedem Release erneut manuell geprüft und angepasst werden, was laufende Kosten und Ausfallrisiken erzeugt, die bei der ursprünglichen Kaufentscheidung selten eingepreist werden. Das gilt grundsätzlich auch für Mittelstands-typische Systeme mit regelmäßigen Cloud-Updates, auch wenn deren Release-Rhythmus und Konfigurationswerkzeuge oft weniger granular dokumentiert sind als bei Workday oder SAP SuccessFactors.

Wie erkenne ich im Vertriebsgespräch oder Demo, ob eine Funktion konfiguriert oder programmiert wurde?

Ein klares Warnsignal ist, wenn der Anbieter für die Umsetzung eines gewünschten Prozesses einen separaten Entwicklungsauftrag, ein technisches Presales-Team oder eine gesonderte Aufwandsschätzung in Personentagen benötigt. Konfiguration lässt sich dagegen in der Regel im laufenden Demo-Termin durch Klicken in der Admin-Oberfläche zeigen. Ein weiterer Test: Bitten Sie darum, dass die Änderung von Ihrem eigenen Fachteam im Testsystem selbst durchgeführt wird, statt sie sich nur vorführen zu lassen. Lässt sich das nicht ohne Entwicklerunterstützung umsetzen, handelt es sich vermutlich um Customizing.

Welche Rolle spielt eine Workflow-Engine für die Konfigurationstiefe?

Die Workflow-Engine ist häufig der Bereich mit der größten sichtbaren Konfigurationstiefe, weil sich darüber mehrstufige Genehmigungsprozesse, Eskalationsregeln und Vertretungslogik ohne Programmierung abbilden lassen: bei Workday etwa über das „Business Process Framework“. Entscheidend ist, wie komplex Verzweigungen sein dürfen, bevor die Engine an ihre Grenzen stößt und auf eingebettete Skriptsprachen zurückgegriffen werden muss. Visuelle Flow-Builder nach dem Vorbild von Microsoft Power Automate gelten hier als Referenzstandard, weil sie auch komplexe Bedingungslogik grafisch statt in Code abbilden.

Wie tief lassen sich Rollen- und Berechtigungsmodelle in modernen HR-Systemen konfigurieren?

Etablierte HR-Suiten bieten heute granulare Role-Based-Access-Control-Modelle (RBAC), bei SAP SuccessFactors offiziell „Role-Based Permissions“ (RBP) genannt, in denen sich Sichtbarkeits- und Bearbeitungsrechte pro Datenfeld, Objekt und Organisationsebene ohne Code einrichten lassen. Die Konfigurationstiefe zeigt sich vor allem daran, ob Berechtigungen kontextabhängig vergeben werden können, etwa nur für direkt unterstellte Mitarbeitende statt für die gesamte Organisationseinheit. Muss für solche Differenzierungen Individualcode geschrieben werden, ist das Rollenmodell in der Praxis weniger tief konfigurierbar, als es im Verkaufsgespräch dargestellt wird.

Was passiert konkret bei einem Release-Wechsel, wenn viel individuell angepasst wurde?

Individueller Code, der außerhalb der offiziellen Konfigurationswerkzeuge liegt, ist beim automatischen Update des Herstellers nicht automatisch kompatibel und muss vor der Übernahme des neuen Release erneut getestet werden. In der Praxis bedeutet das häufig einen eigenen internen oder mit dem Implementierungspartner abgestimmten Testzyklus vor jedem Pflicht-Update, der bei rein konfigurierten Systemen entfällt, weil der Hersteller diese Tests zentral für alle Kunden durchführt.

Muss der Betriebsrat bei der Konfiguration von HR-Software mitbestimmen?

Ja, in vielen Fällen. § 87 Abs. 1 Nr. 6 Betriebsverfassungsgesetz (BetrVG) räumt dem Betriebsrat ein zwingendes Mitbestimmungsrecht bei technischen Einrichtungen ein, die geeignet sind, Verhalten oder Leistung von Beschäftigten zu überwachen. Da moderne HR-Software durch Workflow-Protokolle, Zeitstempel und Auswertungsfunktionen praktisch immer eine solche Eignung besitzt, betrifft dieses Mitbestimmungsrecht direkt die konkrete Konfiguration, etwa welche Kennzahlen ausgewertet und wer Protokolle einsehen darf. Diese Fragen sollten typischerweise in einer Betriebsvereinbarung geregelt werden, bevor die entsprechende Konfiguration produktiv geschaltet wird.

Muss jede einzelne Konfigurationsänderung erneut durch den Betriebsrat freigegeben werden?

Nicht zwingend jede einzelne Änderung, aber jede Änderung, die die in der ursprünglichen Betriebsvereinbarung geregelten Auswertungs-, Protokollierungs- oder Überwachungsmöglichkeiten erweitert oder verändert. Eine gut formulierte Betriebsvereinbarung definiert idealerweise nicht nur den Ist-Zustand einer Konfiguration, sondern auch einen Rahmen (z. B. zulässige Kennzahlenarten, Zugriffsberechtigte, Aufbewahrungsfristen), innerhalb dessen spätere Konfigurationsanpassungen ohne Neuverhandlung möglich sind. Fehlt ein solcher Rahmen, kann in der Praxis tatsächlich jede relevante Änderung (etwa ein neuer Auswertungsbericht oder ein neu freigeschalteter KI-Agent mit Zugriff auf Leistungsdaten) eine erneute Abstimmung mit dem Betriebsrat erfordern. Das interne Governance-Modell aus Schritt 6 sollte deshalb von Anfang an eine Prüfroutine vorsehen, ob eine geplante Konfigurationsänderung noch vom bestehenden Rahmen gedeckt ist.

Wie verändert sich Konfigurationstiefe durch KI-Funktionen (Agenten, Copilots) in HR-Software?

Generative KI-Funktionen wie SAP Joule, Workday Illuminate/AI Agents oder Personio AI führen eine neue Konfigurationsebene ein, die über klassische Felder, Workflows und Rollen hinausgeht: Konfiguriert wird hier, welche Skills bzw. Agenten für welche Nutzergruppe aktiviert sind, auf welche Datenquellen ein Agent beim „Grounding“ zugreifen darf, und ob Ergebnisse ein verpflichtendes menschliches Review durchlaufen müssen, bevor sie sichtbar werden. Diese Konfigurationsentscheidungen sind zugleich Compliance-Entscheidungen: Sobald ein Agent Aussagen zu Leistung oder Verhalten von Beschäftigten vorbereitet oder trifft, greift in der Regel § 87 Abs. 1 Nr. 6 BetrVG, und die konkrete Freigabe- und Zugriffskonfiguration gehört typischerweise in dieselbe Betriebsvereinbarung wie andere Auswertungsfunktionen.

Wie viel Konfigurationstiefe brauchen kleine und mittlere Unternehmen wirklich?

Das lässt sich nicht pauschal beziffern, aber ein pragmatischer Ansatz hat sich in unserer Beobachtung bewährt: zunächst mit der Standardkonfiguration eines Systems zu starten und Abweichungen erst zu genehmigen, wenn sich ein konkreter, wiederkehrender Geschäftsbedarf zeigt, statt jede historisch gewachsene Abteilungs-Sonderregel von Beginn an nachzubilden. Das reduziert sowohl den initialen Implementierungsaufwand als auch das langfristige Wartungsrisiko bei Release-Wechseln. Wie viel Individualisierung tatsächlich nötig ist, hängt stark von Branche, Tarifbindung und Organisationsgröße ab; belastbare quantitative Studien dazu sind uns nicht bekannt, weshalb dies als Erfahrungswert und nicht als belegte Kennzahl zu verstehen ist.

Können auch No-Code- oder Low-Code-Konfigurationen technische Schulden erzeugen?

Ja. Auch wenn keine klassische Programmierung nötig ist, kann eine unübersichtliche Zahl von Workflow-Regeln, Custom Fields und Business Rules über die Zeit schwer wartbar werden, insbesondere wenn Fachbereiche unkoordiniert eigene Anpassungen vornehmen (Citizen Development) und Änderungen nicht dokumentiert werden. Diese Form technischer Schulden ist zwar in der Regel geringer als bei Individualcode, weil der Hersteller die zugrundeliegenden Mechanismen bei Updates weiterhin unterstützt, sollte aber durch ein internes Change- und Test-Governance-Modell begrenzt werden (siehe Schritt 6 des Auswahlprozesses).