Berechtigungskonzept 2.0 bei der Umstellung auf SAP S/4HANA – Teil1

Im IT Bereich müssen wir uns täglich neuen Herausforderungen stellen. Neue Technologien erfordern ein entsprechendes Handeln, um die aktuelle Systemlandschaft immer auf dem neuesten Stand zu halten, die Position am Markt zu stärken und natürlich um sich gegenüber anderen Mitbewerbern einen technologischen Vorsprung zu erarbeiten. Dies macht sich auch in der entsprechenden SAP Systemlandschaft bemerkbar. Lesen Sie in der zweiteiligen Blogreihe, wieso ein Berechtigungskonzept so früh wie möglich in einer Projektphase berücksichtigt werden sollte – vor allem bei der Umstellung auf SAP S/4HANA.

Über die Wichtigkeit des Berechtigungskonzept bei der Umstellung auf SAP S/4HANA

Viele Unternehmen konvertieren gerade ihre aktuellen SAP Systeme von einem ERP Stand auf ein SAP S/4HANA System. Durch diese Konvertierung kommen auf die jeweiligen Unternehmen viele technische und auch organisatorische Komponenten zu. Hierbei ist der Zeitfaktor zur Ermittlung, Organisation und Implementierung der notwendigen Komponenten nicht zu unterschätzen.

Der Bereich Security wird hierbei oft gedanklich vernachlässigt, kann aber im Nachhinein zu großen Problemen und ggf. imagebedingten Schäden – und daraus resultierenden finanziellen Einbußen – führen. Daher sollte die Implementierung eines vollumfänglichen Berechtigungskonzeptes so früh wie möglich innerhalb der Projektphase berücksichtigt werden, da hier mehrere Komponenten ineinandergreifen.

Wichtige Komponenten im Berechtigungskonzept

Wichtig ist, dass ggf. die Datenbank auf eine SAP S/4HANA Datenbank umgestellt wird. Außerdem müssen diverse technische Systemkomponenten analysiert und an die neue Umgebung angepasst werden.. Aber auch auf organisatorischer Ebene müssen Umstrukturierungen durchgeführt werden.

So muss u.a. das „alte“, bzw. aktuelle, Berechtigungskonzept analysiert, bewertet und ggf. grundlegend überarbeitet werden. Durch den Wechsel von SAP R/3 nach SAP S/4HANA sind hier u.a. folgende Komponenten zu berücksichtigen:

Es gibt komplett neue Transaktionen unter SAP S/4 HANA
Alte Transaktionen werden durch neue Transaktionen ersetzt
Es gibt obsolete Transaktionen und Objekte, die nicht mehr genutzt werden
Neue Berechtigungsprüfungen auf Objekt Ebene werden implementiert
Objektkonstellationen ändern sich
Prozesse ändern sich, aufgrund der oben benannten neuen Konstellationen

Hierdurch ist eine grundlegende Prüfung und Überarbeitung des Berechtigungskonzeptes zwingend notwendig, um dieses Konzept an die neue Konstellation und Systemumgebung anzupassen und dieses weiter lauffähig und wartbar zu halten.

Das Berechtigungskonzept in der FIORI Oberfläche umsetzen

Wird dann unter SAP S/4HANA die FIORI Oberfläche eingesetzt, müssen auch hier die zusätzlichen Komponenten berücksichtigt werden.

Berechtigungen werden dem User nicht mehr über „Transaktions-Einträge“ im Menü einer Rolle zur Verfügung gestellt. Stattdessen kommen hier nun Kataloge und Gruppen zum Einsatz. Diese werden, ähnlich der „Transaktions-Einträge“ im Menü einer Rolle hinterlegt und dem User zugeordnet.

Diese Kataloge müssen allerdings vorab im sog. „Launchpad Designer“ mit entsprechenden Kacheln befüllt werden. Hierbei ist darauf zu achten, dass immer alle relevanten Komponenten (Kachelkomponente und Zielzuordnungskomponente(n)) mit im Katalog hinterlegt werden.

Der FIORI Katalog dient dazu einem User den technischen Zugriff auf eine Kachel zu ermöglichen. Eine korrespondiere FIORI Gruppe dient dazu, diese Kacheln dem User dann auch optisch zum Zugriff im Launchpad zur Verfügung zu stellen.

Transaktionale und Native oder analytische Kacheln in der FIORI Umgebung

Bei der FIORI Umgebung gibt es grundsätzlich zwei unterschiedliche Arten von Zugriffen über eine Kachel. Zum einen die transaktionalen Kacheln, zum anderen die nativen oder analytischen Kacheln :

Transaktionale Kacheln:

Diese Kacheln stellen den Zugriff auf „alte“ Transaktionen in der FIORI Oberfläche sicher, oder es werden in „alten“ Transaktionen neue Features hinterlegt, die dann nur in der FIORI Oberfläche genutzt werden können, nicht aber in der GUI Oberfläche

Native oder analytische Kacheln:

Diese Kachel funktionieren ausschließlich in der FIORI Oberfläche und sind an die neue Technologie angepasst. Hier werden z.bsp. push Meldungen auf der Kachel angezeigt, oder es werden Kennzahlen, Diagramme etc. angezeigt, die dann per Klick direkt weiterverarbeitet werden können. Diese Kacheln haben keinen direkten GUI Zugriff, bzw. können direkt in der GUI Umgebung nicht genutzt werden

Wie bereits oben erwähnt, wird der Zugriff auf diese Kacheln in einem sogenannten Front-End-System über entsprechende Kataloge und Gruppen zur Verfügung gestellt. Die dahinterliegenden konzeptionellen Berechtigungen (wer darf was innerhalb der Funktionalität der Kachel) folgt aber den gleichen Prozessen wie in der „alten Welt“ beim Transaktions Zugriff.

Die Kachel im Front-End benötigt hier entsprechende abhängige ausgeprägte Berechtigungen (Stichwort:SU24 Abgleich).Im Back-End-System, dann wiederum – analog der „alten“ Welt – über eine Rolle, die im Profilgenerator aufgebaut und auf Objekt und Feld Ebene gepflegt, bzw. eingestellt wird.

Natürlich müssen auch hier dann noch u.a. die Themen wie Update von internen und Third-Party Tools, Integration von Cloud Lösungen, moderne hybride Infrastrukturen, Definition und Betrieb bei laufenden dynamische Veränderungen, usw. berücksichtigt werden.

Fazit

All diese neuen Komponenten sind beim Umbau der bisherigen Prozesse auf die neue System- und Prozesslandschaft zu berücksichtigen.

Werden diese Themen bei einer Konversion nicht entsprechend berücksichtigt, entsteht ein Schiefstand zwischen System und abzusichernden Komponenten, da durch die Änderung der Systemkonstellation neue Komponenten, wie z.bsp. oben erwähnt, zwingend mitberücksichtigt werden müssen. Ansonsten kann es zu einem wirtschaftlichen Schaden und daraus resultierenden Image-Schaden für ein Unternehmen kommen. Ferner kann eine Vernachlässigung gesetzlicher Vorgaben (BDSG, DSGVO, GOB, HGB etc.)¹ zu rechtlichen Maßnahmen oder Schritten führen.

Erfahren Sie im zweiten Teil der Blogreihe, wie Sie anhand einer 5-Konzept-Leitlinie ein vollumfängliches Berechtigungskonzept definieren, implementieren und nachhaltig nutzen können.

¹ ^{BDSG (BundesDatenSchutz Gesetz),DSGVO (DatenSchutz Grund Verordnung), GOB (Grundsaetze Ordnungsgemaesser Buchfuehrung),HGB (Handels Gesetz Buch)}

– von Thomas Leger, SAP Security Expert, NTT DATA Business Solutions AG –
E-Mail: [email protected]