People & HR · Global

Soll-Stunden: wann das Modul im Produktalltag Sinn ergibt.

Soll-Stunden, Zielwerte und Monatsregeln verwalten. Das Modul wird in der passenden Verwaltungs- oder Arbeitsoberflaeche freigeschaltet und genutzt.

  • Soll-Stunden erklärt kompakt, wofür der Bereich gedacht ist und wann er im Arbeitsalltag relevant wird.
  • Der Bereich spielt in der Praxis besonders mit Abwesenheit und Stunden zusammen.
  • Rollen, Sichtbarkeit und angrenzende Bereiche bestimmen, wie gut das Modul im Alltag funktioniert.
Modulzweck

Wofuer das Modul gedacht ist

Soll-Stunden ist Teil des aktiven Modul-Katalogs und deckt einen klaren Ausschnitt des Produktalltags ab.

Soll-Stunden, Zielwerte und Monatsregeln verwalten. Im tenantweiten Kontext sorgt der Bereich dafuer, dass wiederkehrende Entscheidungen, Stammdaten oder Uebersichten nicht in Nebensysteme ausweichen muessen.

Soll-Stunden ist als eigenstaendiger Produktbaustein gedacht. Gerade deshalb lohnt sich ein Blick darauf, wie der Bereich mit Rollen, Datenkontext und angrenzenden Modulen zusammenspielt.

Das Modul wird in der passenden Verwaltungs- oder Arbeitsoberflaeche freigeschaltet und genutzt.
Praxisbezug

Typische Einsatzfaelle

Diese Situationen zeigen, wann der Bereich in einem sauberen Rollout oder im laufenden Betrieb konkret Mehrwert liefert.

Self-Service entlasten

Mitarbeitende koennen wiederkehrende Personalthemen direkt im passenden Ablauf bearbeiten.

Genehmigungspfade klaeren

Antraege, Korrekturen und Zielwerte bleiben transparent, sobald die zustaendigen Rollen sauber gesetzt sind.

Kapazitaet planbar machen

Das Modul ist besonders wertvoll, wenn Abwesenheit, Soll-Werte und Stunden gemeinsam gedacht werden.

Modulverbindungen

Wie das Modul mit anderen Bereichen zusammenspielt

struct-i-vio ist als zusammenhaengende Plattform gedacht. Diese Module liegen fachlich am naechsten bei diesem Bereich.

Sichtbarkeit

Berechtigungen und Sichtbarkeit

Die oeffentliche Dokumentation beschreibt die Logik auf Produktniveau - nicht als technische Policy-Liste, sondern als Rollout-Leitfaden.

Die Sichtbarkeit wird tenantweit bzw. organisationsweit freigeschaltet und sollte zu Rolle und Verantwortungsbereich passen.
Das Modul hat keinen eigenstaendigen Hauptmenuepfad. Zugriff und Aktionen greifen direkt in den jeweiligen Verwaltungs- oder Projektoberflaechen.
Self-Service, Genehmigung und manuelle Korrektur sollten getrennt vergeben werden, damit sensible Personaldaten nicht unnoetig breit sichtbar sind.
Empfohlener Einsatz

Best Practices

So bleibt der Bereich bei Einfuehrung und Nutzung anschlussfaehig an den restlichen Produktfluss.

Antrags- und Genehmigungswege bewusst definieren, bevor das Modul tenantweit ausgerollt wird.
Personalseitige Regeln mit Stunden- und Kapazitaetsprozessen abstimmen, damit Teams nicht in Parallelstrukturen arbeiten.
Korrekturen und Overrides immer auf einen kleinen, nachvollziehbaren Kreis begrenzen.