Ein generisches Datenmodell für Organigramme

Als IT-Berater waren Volker und ich viele Jahre auch im Bereich Ressourcen- und Personalplanung tätig. Auf diesen Erfahrungen haben wir ein generisches Datenmodell für Organigramme entwickelt, das gerade im Bezug zur Ressourceplanung sehr gut funktioniert.

Im Folgenden stelle ich die grundlegenden technischen Anforderungen für das Datenmodell vor. Die fachlichen Anforderungen dahinter sollten direkt einleuchten, in Einzelfällen weise ich explizit darauf hin.

Ziel ist es ein hierarchisches Organigramm so flexibel wir möglich abzubilden, um die jeweiligen Organisationseinheiten und deren Hierarchien als Grundlage für die Klammerung von Personal, Ressourcen und Berechtigungen zu verwenden.

• O1: Eine Organisation wird in Organisationseinheiten untergliedert, im Folgenden auch Personengruppen.
• O2 a: Diese Personengruppen können in beliebig verschachtelten Hierarchien angeordnet sein, müssen es aber nicht
  • z.B. Firma Softcom → Hauptabteilung IT-Services → Abteilung Hosting → Unterabteilung Administration → Gruppe DBA
• O2 b: Eine Person kann mehreren Gruppenhierarchien angehören. Insbesondere sind auch Querschnittsgruppen erlaubt.
  • z.B. ein abteilungsübergreifendes Projekt
• O2 c: Dasselbe gilt für Personengruppen

  Die Anforderungen O2 a – O2 c verdeutlichen die fachlichen Hintergründe, lassen sich aber zu einer Anforderung O2 zusammenfassen:

• O2: Personen und Personengruppen sollen wie „Emailverteiler“ strukturiert sein
  • Eine Person oder eine Personengruppe kann also mehreren Personengruppen angehören.
  • Dies ermöglicht auch hierarchische Strukturen, ist aber wesentlich flexibler.
  • Die Struktur kann über eine einfache Intersection Table von Personengruppen / Personen zu Personengruppen implementiert werden. Es empfiehlt sich Hierarchische Views für diese Struktur anzulegen.

• R1: Ressourcen werden auch den Organisationseinheiten zugeordnet (in unserem Sprachgebrauch also den Personengruppen).

• E1: Ein Ereignis kann einer Person zugeordnet sein (z.B. ein „Dienst“).
• E2: Ein Ereignis kann auch einer Ressource zugeordnet sein.
• E3: Ein Ereignis hat ein Start- und ein Ende-Zeitpunkt.
• E4: Ein Ereignis kann ein Mutterereignis besitzen
  • Dadurch kann u.a. eine beliebig detaillierte Projektplanung implementiert werden: Für das Ereignis „IT-Messe“ an den Tagen 1 und 2 werden z.B. die Personen „Meier“ für Tag 1 und 2, „Müller“ für Tag 2 und die Ressourcen „PC“ und „Beamer“ für Tag 1 und 2 geplant.
• E5: Ein Ereignis besitzt immer einen Ereignistypen
  • Ereignistypen können z.B. Dienstarten in der Personalplanung sein (z.B. Urlaub, Bereitschaft, Arbeitszeit).
• E6: Ereignistypen werden auch den Organisationseinheiten zugeordnet (in unserem Sprachgebrauch also den Personengruppen). Dabei stehen Ereignistypen übergeordneter Gruppen in der Regel auch den untergeordneten Gruppen zur Verfügung (s.u.).
  • Beispiel: Zur Gruppe DBA gehört die spezielle Dienstart „Bereitschaft DBA“

     

    Die volle Flexibilität zeigt sich erst durch geeigneten Berechtigungen:

• B1: Lese- und Schreibrechte werden hierarchisch gemäß den Personengruppen vergeben und vererbt
  • Im oberen Beispiel etwa: Schreibrechte für Ereignisse der Hauptabteilung IT-Services beinhalten auch immer Schreibrechte auf die jeweiligen Abteilungen, Unterabteilungen und Gruppen.
  • Die Granularität „Personengruppe“ ist hier wesentlich: So werden Rechte nicht für jede Ressource einzeln festgelegt. Durch die Zuordnung einer neuen Ressource zur Personengruppe, werden automatisch die Berechtigungen der anderen Ressourcen der Gruppe übernommen.
• B2: Die Anwendergruppen und deren Berechtigungen können analog zu den Organisationseinheiten / Personengruppen strukturiert sein, müssen es aber nicht.
  • Dies muss näher erläutert werden: In der Regel werden die hinterlegten Personen des Organigramms auch Anwender des Systems sein. In der Unterabteilung Administration kann es eine Gruppe „Disponenten“ geben, die die gesamte Personal- und Ressourcenplanung für die ganze Abteilung Hosting durchführt. Den Disponenten können also Planungsrechte für alle Ereignisse der übergeordneten Abteilung Hosting vergeben werden, obwohl sie laut Organigramm nur einer Untergruppe der Abteilung zugeordnet sind.
  • Dadurch lässt sich etwa auch folgendes Konstrukt abbilden: Der Spediteur „Lieferschmidt AG“ hat alle LKWs in die „Lieferschmidt Ressourcen GmbH“ outgesourct. Die Gruppe „Disponenten“ in der Lieferschmidt AG haben trotzdem die Berechtigungen LKWs aus der GmbH für die Touren der AG-Mitarbeiter zu planen.
• B3 a: Die Berechtigung bestimmte Ereignistypen zuzuweisen wird in der Regel in umgekehrte Richtung zu den Gruppenhierarchien vererbt.
  • Allgemeine Dienstarten wie „Arbeitszeit“, „Urlaub“ oder „Mutterschutz“ können also übergeordnet Firma Softcom zugeordnet werden. Die verschiedenen Disponentengruppen der einzelnen Abteilungen können alle diese Dienstarten vergeben, zusätzlich zu den speziellen Dienstarten den Untergruppen.
• B3 b: Im Gegensatz dazu kann die Berechtigung bestimmte Ereignistypen zuzuweisen auch auf die direkt zugeordnete Gruppe eingeschränkt werden.
  • Disponenten dieser Personengruppe können also nur die Ereignistypen ihrer Disponenten-Gruppe zuweisen.
• B4: Wurde ein Ereignis angelegt, ist die Gruppe des Ereignistypen maßgeblich für die Berechtigungen zur weiteren Bearbeitung
  • Hat ein Messeplaner einen Mitarbeiter der Gruppe „DBA“ für das abteilungsübergreifende Projekt „IT-Messe“ mit der Dienstart „Präsentation Messe“ eingeplant, kann nur ein anderer Messeplaner dies ändern. Ein Disponent der Gruppe DBA hat keine Schreibrechte auf den Dienst.
  • Damit solche Messeplaner dadurch keine Schreibrechte auf übergeordnete Dienste wie Urlaub erhalten, erhalten sie nur die eingeschränkten Rechte aus B3 b.
  • Dadurch werden die Berechtigungen auch von den Bewegungsdaten entkoppelt. Kommt es zu einer Neustrukturierung der Organisation, müssen nur die Stammdaten geändert werden, im besten Fall sogar nur die Bezeichnung der Personengruppen und die Hierarchien.

Für eine umfassende Personal- und Ressourcen-Planung gehören natürlich noch eine Vielzahl weiterer Anforderungen. Themen wie „Workflows“, „Schicht-Plan“ oder „Serienereignisse“ habe ich weggelassen. Ziel war es lediglich das Konzept der Personengruppen zu erläutern und wie man es exemplarisch in der Ressourceplanung einsetzen kann, um möglichst generisch Berechtigungen zu vergeben.

Es empfiehlt sich übrigens für den Zweck weitere Views anzulegen, die die Hierarchien auflösen, um z.B. Aspekte wie den folgenden zu kapseln: Für welche Personengruppen hat Mitarbeiter Meier Schreibrechte auf Dienste?

Man sollte darauf achten, dass das hierarchische Konzept mit Personengruppen nicht dazu mißbraucht wird, die relationale Idee auszuhebeln: Letztendlich könnten alle Personenattribute durch Gruppen wie „Frauen“ oder „Männer“ ersetzt werden