Eine Funktionsarchitektur kann nicht die Summe eines Kundenportfolios sein.
Das ist eine Überzeugung, die mir mehrere Projekte zur Funktionsarchitektur hinterlassen haben, in unterschiedlichen Größenordnungen, national und international.
Jedes Unternehmen hat seine eigene Geschichte, seine eigene Kultur, seine eigenen Geschäftsfelder, seine eigene Logik der Entwicklung. Und doch sieht man zuweilen Vorschläge für Raster, die auf dem beruhen, was anderswo entwickelt wurde. Die Methodik ist ambitioniert, die Auslieferung sorgfältig, aber die Struktur sagt nichts Spezifisches über das Unternehmen aus, das sie darstellen soll.
Hier verlieren aus meiner Sicht viele Projekte ihren Wert.
Statt eine Wunscharchitektur zu errichten, die die Organisation später einholen muss, ziehe ich es vor, von der Organisation auszugehen, wie sie ist, und sie Schritt für Schritt zu dem zu führen, was sie werden möchte.
Eine Einschränkung ist nötig: In manchen Unternehmen ist ein vorgegebenes Raster verpflichtend (Tarifverträge, paritätische Kommissionen, regulierte Branchen). Das Prinzip bleibt gültig, wird aber im Rahmen des Spielraums ausgeübt, der dem Unternehmen verbleibt: Positionierung der Funktionen, interne Karrierepfade, Entwicklungskriterien innerhalb der vorgegebenen Ebenen.
Eine Organisation hat ihre eigene Kultur, und diese Kultur geht den Werkzeugen voraus. Ein Werkzeug, das sie ignoriert, prallt an ihr ab. Eine Funktionsarchitektur bildet keine Ausnahme.
Deshalb muss sie vom Unternehmen aus, durch das Unternehmen und mit dem Unternehmen aufgebaut werden.
Vom Unternehmen aus
Man geht von dem aus, was wirklich existiert, nicht von einem theoretischen Modell. Die realen Titel, die realen Berichtslinien, die tatsächlich gelebten Ebenen. Das ist länger, politischer, unbequemer. Es ist auch das, was die Struktur bei den Führungskräften glaubwürdig und gegenüber den Mitarbeitenden vertretbar macht.
Durch das Unternehmen
Methodische Entscheidungen sind Unternehmensentscheidungen, keine externen Standards. Wie viele Karrierepfade, wie viele Entwicklungsebenen, wo Ebenen geöffnet und geschlossen werden, wo Grenzen zwischen Populationen gezogen werden, wie Funktionen gruppiert werden, wie Kategorien benannt werden: das sind Entscheidungen, die der Organisation gehören.
Es gibt viele Methoden zur Funktionsbewertung, und jede beleuchtet einen anderen Aspekt. Ein analytischer Punktwertansatz zerlegt jede Funktion in messbare Kriterien, Kompetenzen, Verantwortlichkeiten, Wirkung, und vergibt eine Bewertung. Ein Klassifizierungsansatz ordnet die Funktionen vordefinierten Ebenen zu. Ein Rangordnungsansatz stellt sie in eine Reihenfolge zueinander. Auch wenn ich mit den ersten beiden vertrauter bin, bin ich überzeugt, dass keine an sich falsch ist, solange sie erklärbar bleibt und interne Konsistenz sichert. Aber alle sind Werkzeuge im Dienst einer Unternehmensentscheidung, keine Rezepte, die mechanisch das richtige Raster hervorbringen.
Diese Nuance wird heute entscheidend. Die EU-Richtlinie 2023/970 zur Entgelttransparenz verlangt in ihrem Artikel 4, dass Unterschiede in Ebene und Vergütung anhand objektiver, geschlechtsneutraler und für die Organisation spezifischer Kriterien begründbar sind. Dieser letzte Punkt ändert alles. Ein aus einem anderen Kontext übernommenes Raster oder eine Methode, die ohne Anpassung an das Unternehmen angewendet wird, kann ein technisch sauberes Ergebnis liefern und dennoch unhaltbar bleiben, weil sie nichts Spezifisches über die Organisation aussagt, die sie darstellen soll. Der Unterschied existiert, er ist beziffert, aber das Unternehmen kann ihn nicht von Fall zu Fall erklären. Und nunmehr liegt es am Unternehmen, ihn zu erklären: eine Architektur, die nicht in der realen Organisation verwurzelt ist, lässt das Unternehmen ohne Antwort, sobald eine Entscheidung hinterfragt wird.
Mit dem Unternehmen
Führungskräfte, HR Business Partner und Arbeitnehmervertreter müssen die Argumentation nachvollziehen, hinterfragen und bestätigen können. Eine Architektur, die allein von der Funktion Comp & Ben validiert wurde oder, schlimmer, aus einem Kundenportfolio übernommen ist, übersteht den ersten Beförderungszyklus nicht.
Ja, dieser Ansatz erfordert mehr Arbeit. Mehr Gespräche, mehr Iterationen, mehr Entscheidungen, zu denen man steht. Aber genau diese Arbeit macht aus einem Raster ein Steuerungswerkzeug und aus einem Projekt eine dauerhafte Governance.
Das Wesentliche
Eine Funktionsarchitektur muss das Unternehmen und seine Entscheidungen widerspiegeln. Sie wird aus der realen Organisation heraus aufgebaut, durch das Unternehmen, das seine eigenen Abwägungen verantwortet, und mit ihm: Führungskräfte, HR Business Partner und Arbeitnehmervertreter müssen die Argumentation hinterfragen, bestätigen und mittragen können.
Nur unter dieser Bedingung bleibt sie erklärbar, und ihre Entscheidungen bleiben nachvollziehbar an dem Tag, an dem eine Entscheidung hinterfragt wird.
Was ist dann der Ausgangspunkt? Diesem Thema widme ich einen weiteren Artikel dieser Serie, [[revising-functions-where-to-start]].
Die Plattform HDH (HR Decision Hub) hilft jedem Unternehmen, seine eigenen Entscheidungen zu klären, indem es seine eigene Architektur aufbaut und überarbeitet und die Nachvollziehbarkeit der Entscheidungen von Anfang bis Ende bewahrt.