SAP HCM: Strukturelle Berechtigungen

Sie wollen im HR-Bereich Berechtigungen vergeben, die auch dann noch funktionieren, wenn eine Abteilung wächst oder sich Strukturen im Unternehmen ändern? Strukturelle Berechtigungen können hier das Mittel der Wahl sein – wenn Ihre Mitarbeiter in einem Verantwortungsbereich ausschließlich eine einzige Funktion innehaben. Worauf Sie achten müssen und wie strukturelle Berechtigungen funktionieren, erklären wir hier.

Nehmen wir an, Sie arbeiten für ein mittelständisches Unternehmen. Die Strukturen sind vergleichsweise einfach, doch das Unternehmen wächst kontinuierlich und die Unternehmensorganisation verändert sich deshalb immer wieder. Mit allgemeinen Berechtigungen kommen Sie nicht mehr weiter, weil die stets von Hand nachgepflegt werden müssen, wenn sich die Struktur von Abteilungen oder Teams ändert. Sie entscheiden sich für strukturelle Berechtigungen.

Die kommen aber nicht nur in der Personaladministration zum Einsatz, sondern auch für:

  • Anzeige und Pflege von Objekten des Organisationsmanagements
  • Anzeige und Pflegen aller HCM-Objekten, die aus HRP-Tabellen angelegt sind

Wichtig: Strukturelle Berechtigungen funktionieren nur im Zusammenspiel mit den allgemeinen Berechtigungen. Um Berechtigungen zu erteilen, muss die Prüfung in den strukturellen und den allgemeinen Berechtigungen positiv sein.

Um strukturelle Berechtigungen zu nutzen, müssen Sie strukturelle Profile anlegen (Transaktion OOSP).

Profile werden – wie Rollen – zunächst userunabhängig angelegt und den Usern anschließend zugewiesen. Achten Sie darauf, möglichst eindeutige Namen für Ihre eigenen Profile zu vergeben.

Mit Doppelklick auf das Profil (Achtung, die Zeile muss ausgewählt sein!), öffnen Sie die Pflegeparameter des Profils und können das Profil ausprägen:

  • Planvariante
  • Objekttyp (in der Regel interne HCM-Objekte, etwa P (Person) oder AP (Bewerber))
  • Objekt-ID (kennzeichnet das Wurzelobjekt)
  • Pflege (erlaubt Pflege des Objekts, wenn das in der Tabelle T77FC so vorgesehen und die Pflege auch über die allgemeinen Berechtigungen erlaubt ist)
  • Auswertungsweg
  • Statusvektor (1 = aktiv, 2 = geplant, 3 = beantragt, 4 = genehmigt, 5 = abgelehnt)
  • Tiefe (Anzahl der berechtigten Ebenen unterhalb des Wurzelobjekts, 0 oder Leerzeichen umfasst alle Ebenen)
  • Vorzeichen (kehrt die Richtung für die Tiefe um, die Zahl der berechtigten Ebenen wird also nicht mehr vom Wurzelobjekt aus abwärts gezählt, sondern von der letzten Ebene aufsteigend zum Wurzelobjekt)
  • Zeitraum (legt fest, ob der User direkt zum Stichtag oder nur in einem Zeitraum (etwa Monat oder Jahr) um den Stichtag berechtigt sein muss: D = Stichtag, M = laufender Monat, Y = laufendes Jahr, P = Vergangenheit, F = Zukunft)
  • Funktionsbaustein

Um die Berechtigungen zu definieren, die über ein strukturelles Profil vergeben werden, sind die wichtigsten Felder der Auswertungsweg und die Objekt-ID bzw. der Funktionsbaustein.

Auswertungswege bestimmen die Berechtigungsprüfung

Strukturelle Berechtigungen folgen vorher festgelegten Auswertungswegen, zum Beispiel dem Weg O-O-S. O steht dabei für Organisationseinheiten wie Abteilungen oder Teams, S sind die Planstellen im Unternehmen. Alternativ kann der Weg zum Beispiel auch O-S-P lauten, dann sind zusätzlich zu den Planstellen auch die Personen umfasst, die diese Planstellen besetzen. Jede Organisationseinheit, Planstelle und Person ist ein Objekt mit einer eignen Objekt-ID.

Je nachdem, was Sie berechtigen möchten, wählen Sie eins der Objekte als Wurzelobjekt für Ihren Auswertungsweg. Die ID des Wurzelobjekts tragen Sie in das strukturelle Profil ein. Alle anderen Objekte, die innerhalb des Auswertungsweges unter dem Wurzelobjekt folgen, sind damit automatisch ebenfalls berechtigt.

Ein Beispiel: In Ihrem Unternehmen gibt es den Vertrieb als Abteilung und darin 5 Teams. Sie wollen nun ein Berechtigungsprofil anlegen, mit dem der Abteilungsleiter die organisatorische Zuordnung (Infotyp 0001) aller Vertriebsmitarbeiter sehen kann. Des Weiteren brauchen Sie ein Profil, mit dem die Teamleiter die Gehaltsdaten der Mitarbeiter einsehen können. Allerdings soll das nur für das jeweils eigene Team möglich sein.

Sie entscheiden sich für den Auswertungsweg O-O-S. Für das Abteilungsleiter-Profil wird die Abteilung Vertrieb (O1) zum Wurzelobjekt. Berechtigt sind damit alle Teams und Planstellen unterhalb der Abteilung (graue Felder):

Für das Teamleiter-Profil werden die Teams (O2 – O5) zu Wurzelobjekten und die darunterliegenden Planstellen werden mitberechtigt (beispielhaft für Team 2 graue Felder):

Das Problem hierbei: Sie müssen für jeden Teamleiter ein eigenes Profil anlegen, weil jeder von ihnen ein anderes Wurzelobjekt für seine Berechtigungen braucht. Je nachdem, wie groß Ihr Unternehmen ist und wie weit Sie die Berechtigungen ausdifferenzieren müssen, kann das zu einer unüberschaubaren Menge an Profilen führen.

Using function modules instead of object IDs

To avoid this, you can work with function modules – instead of the individual object ID. Function modules read the position of a user within the organizational structure and thus dynamically determine the required root object. But beware: This only works if you have a really seamlessly maintained org management!

You can program your own function modules or use the standards that SAP already provides.

In our example of sales team leaders, for example, the standard function module RH_GET_MANAGER_ASSIGNMENT works. So you just create an authorization profile for all team leaders and enter the function module instead of the object ID of a root object. The function module now reads out which position is occupied by the user to whom the profile is assigned and to which organizational unit in the company this position is assigned as manager. (Important: If you have not maintained the position assignment properly, i.e. the team leaders do not appear as leaders in Org Management, the function module will not work). The function module automatically uses the organizational unit as a root object and checks the authorizations along the stored evaluation path. In this way, you only need one profile for all team and department managers and still ensure that everyone only has access to salary data for their own team.

Assign structural profiles to the user

You assign structural profiles to users using transaction OOSB. Enter the profile names here and define the validity period.

You can use the exclusion indicator to reverse the authorization: If it is activated, you use your entries to define which objects (from the profiles) the user is NOT allowed to see.

The assignment of profiles to users is recorded in table T77UA. If no profile is assigned to a user in it, the authorization check is automatically performed on the user SAP*.

By default, user SAP* has the structural profile ALL, i.e. full structural authorization for all object types. Alternatively, you can delete the entry for user SAP* in table T77UA. In this case, users who are not assigned to a structural profile will not receive any structural authorizations. You can achieve the same effect by creating an empty profile – for example, a profile containing only objects that are not used by you – and assigning it to user SAP*.

Structural authorizations in Personnel Administration

If you also want to use structural authorizations in Personnel Administration, i.e. for type P objects, a few prerequisites must be met:

  • Organizational Management must be maintained 100% correctly.
  • The authorization main switch ORGPD in the group AUTSW (transaction OOAC) must be activated (value between 1 and 4).
  • The evaluation path must contain the object type P.
  • What is to be authorized via the structural profiles must also be allowed via the general authorizations. Only if both checks are successful, the user gets access to the requested data.

If these prerequisites are met, the use of structural authorizations also simplifies work in Personnel Administration. For example, you can dispense with maintaining the „Organizational key“ field in object P_ORGIN and using the administrator ID in object P_ORGXX, and thus also need fewer roles.

Ein Kommentar zu “SAP HCM: Strukturelle Berechtigungen

Kommentare sind geschlossen.