Zum Inhalt springen

Aus einem Bedarf eine Rolle machen

Manchmal findet die Kandidatenliste niemanden — und der Grund ist nicht, dass die Person fehlt, sondern die Rolle. Der Bedarf ist dann der Moment, in dem zum ersten Mal ausgesprochen wird, dass diese Arbeit gebraucht wird.

Eine Rolle ist kein Behälter für alles, was in einem Bedarf stand. Sie ist ein Bündel von Tätigkeiten, die einem gemeinsamen Zweck dienen — deshalb ist purpose am Rollentyp ein Pflichtfeld.

Ein Knopf, der die Tätigkeitenliste eins zu eins in Verantwortlichkeiten kippt, produziert Sammelrollen ohne Zweck und beschädigt das Modell schneller, als er Arbeit spart. Aus einer Liste unzusammenhängender Tätigkeiten muss entweder mehr als eine Rolle werden, oder ein Teil gehört an eine bestehende, oder der Bedarf selbst war in Wahrheit mehrere.

Gesucht wird je einzelner Tätigkeit, nicht je Rolle. Der Zweck ist Konfliktvermeidung:

Eine Tätigkeit, die in zwei Rollen steht, ist ein Rollenkonflikt. Zwei Rollen beanspruchen dieselbe Arbeit, niemand weiß, wer entscheidet. In einem rollenbasierten Modell ist das ein Defekt, kein Schönheitsfehler.

Je Tätigkeit gibt es drei mögliche Befunde:

BefundWas zu tun ist
Bereits abgedecktKeine neue Rolle — den Bedarf mit der bestehenden verknüpfen. Der häufigste richtige Ausgang.
ÄhnlichDer Mensch entscheidet: dasselbe gemeint, oder doch etwas anderes?
Steht nirgendsKandidat für die neue Rolle.

Sind alle Tätigkeiten abgedeckt, führt der Weg gar nicht weiter — dann ist die Rolle schon da.

Die Suche ist eine Hilfe, keine Garantie. Sie findet, was sprachlich ähnlich ist; eine Rolle, die dieselbe Arbeit anders benennt, kann durchrutschen. Ist der semantische Index nicht verfügbar, läuft nur ein Textabgleich — dann steht das ausdrücklich dabei, damit „nichts gefunden” nicht als „es gibt nichts” gelesen wird.

Die verbleibenden Tätigkeiten ordnest du in Gruppen. Je Gruppe ist ein Zweck einzugeben — kein Default, kein aus dem Bedarfsnamen erzeugter Platzhalter.

Wer keinen Zweck formulieren kann, hat keine Rolle gefunden. Der Weiter-Knopf bleibt gesperrt, solange eine Gruppe ohne Zweck oder ohne Tätigkeiten dasteht.

Gruppieren und einen Zweck formulieren ist Sprach- und Musterarbeit — mühsam für Menschen, naheliegend für ein Modell. Über „Gruppierung vorschlagen lassen” liefert rALPH Gruppen, Zweck-Entwürfe und eine Begründung, warum diese Tätigkeiten zusammengehören. Zusätzlich benennt er die Tätigkeiten, die er keiner Gruppe zuordnen kann — oft die wertvollste Aussage, weil sie zeigt, wo der Bedarf selbst unscharf ist.

Der Vorschlag erscheint als vorbelegte, vollständig editierbare Gruppierung, nicht als Ergebnis. Nichts wird gespeichert, bevor du bestätigst; die Zweck-Texte bleiben frei überschreibbar. Und weiter geht es auch hier erst, wenn jede Gruppe einen Zweck trägt — auch einen von rALPH stammenden musst du stehen lassen oder ersetzen.

Ist für den Mandanten keine KI konfiguriert, fehlt der Knopf und der Assistent funktioniert unverändert, nur ohne Vorbelegung. Der Aufruf kostet Tokens und wird deshalb erst auf ausdrückliche Anforderung ausgeführt — nie automatisch beim Öffnen.

Aus einem Bedarf dürfen mehrere Rollen entstehen; genau dafür ist die Gruppierung da. Ergeben sich mehrere Zwecke, ist das zugleich ein Hinweis, dass auch der Bedarf heterogen war — dann lohnt es, ihn zu teilen.

Erst danach öffnet sich je Gruppe das normale Rollen-Anlegen-Formular, vorbefüllt:

Aus der GruppeWird an der Rolle zu
Tätigkeiten der Gruppeaccountabilities
eingegebener Zweckpurpose
Kompetenzanforderungen des BedarfsREQUIRES-Beziehungen

Gespeichert wird über den normalen Entwurfs-Weg. Damit gelten ohne Zutun: die Schreibrechte am Rollentyp, sein Freigabemodus, die Validator-Regeln und das Audit. Ein eigener Abkürzungs-Pfad würde genau diese Kette umgehen.

Nach der Freigabe verknüpfst du die neue Rolle per REQUIRES_ROLE mit dem Bedarf — ab da wirkt die Tätigkeitsachse im Matching.