System-Beratung-Klüppelberg

Wie im Teil 1 begonnen, geht es auch in diesem 2. Teil um die Rollendokumentation.

Wenn Sie die Idee aufgreifen, dass die die Rolle in einem Word-Dokument erstellen wollen, und auf einem Laufwerk ablegen wollen, dann ergeben sich hierbei einige Forderungen und Vorraussetzungen:

Wenn der Rollenname dem des Worddokuments entsprechen soll, dann müssen Sie auch dafür Sorge tragen, dass man das Worddokument auch speichern kann. D.h. der Rollenname muss als Dateiname des Word-Dokuments auch im Windows speicherbar sein. Damit fallen Gestaltungmöglichkeiten wie “<” “>”-Zeichen im Rollennamen weg. Der Name der Rolle muss  den Konventionen des Windows-Betriebssystems genügen!

Diese Forderung wirkt sich somit auf Ihr Rollenrahmenkonzept aus. Doch sind Sonderzeichen wie “:”, “>” oder Klammern wirklich so selbsterklärend, dass sie die Rolle  besser erklären? Man könnte ja “>” als Zeichen für eine abgeleitete Rolle nach einem Buchungskreis bezeichnen (XXX_DEBIOREN_BUCHH>1000)! Sieht ja interessant aus, doch müssen Sie jedem neuen Admin erklären, dass das “>”-Zeichen die Ableitung einer Rolle bedeutet. Kann man das nicht auch als Typ A einer Rolle darstellen? Also z.B. XXX_A_DEBITOREN_BUCHH_1000 !

Doch kommen wir zum Inhalt unserer Dokumentation:

Klar ist, dass Sie für jede Änderung an der Rolle, die ja ggf. durch eine Fehlermeldung, eine Entwicklung erforderlich wird, eine neue Version der Rollendokumentation erstellen sollten.  Sie können dies entweder durch eine neue Word-Datei oder durch eine Versionsabfolge in einem Word-Dokument realisieren. Bei Rollen mit vielen Änderungen werden diese “inside Versionierungen” aber schnell unübersichtlich, da  Sie fast nur mit blättern in der Dokumentation beschäftigt sein werden, wenn Sie die Historie einer Rolle betrachten wollen.

Bleibt m.E. nur, die Versionen als Dateinamen zu unterscheiden. D.h. Sie gehen von einer Version 01.00 aus und schreiben diese Verisonen fort. Man kann sich da ja die alte Releasekennzeichnung von SAP^® zunutze machen, in dem man mit der 1. Bezeichnung die Version und nach dem Punkt einen gewissen Korrekturstand .01 bezeichnet. Dies meint, Sie haben einen Dateinamen wie z.B. “XXX_A_DEBITOREN_BUCHH_1000_V03_05.doc”.  Bei neuen Releaseständen des Systems (Patches) und anderen weitgreifenden Änderungen zählen Sie die Versionsnummer hoch, ansonsten desn Korrekturstand.

Wir brauchen eine Tabellierung der Transaktionen einer Rolle in der Dokumentation. Dabei sollte die Tabelle nicht nur den T-CODE sondern auch den T-CODE-Text enthalten.  Auch ist es sinnvoll,  eine Spalte Zugang und Abgang einer Transaktion vorzusehen, um deutlich zu machen, was an der Rolle wann  geändert wurde.

Wie können Sie die Transaktionen einer größeren Rolle übernehmen? Es gibt die Transaktion S_BCE_68002041 mit der Sie für eine Rolle die Transaktionen der Rolle auflisten und nach Excel exportieren können. [Menü: Werkzeuge | Administration | Benutzerpflege | Infosystem | Transaktionen ]. Mit ein wenig Aufbereitung in Excel können Sie die Tabelle ins Word einkopieren.

Sie brauchen weiterhin eine Tabelle für die Organisationsebenen der Rolle. Auch diese können Sie im Excel vorformatieren und nach Word kopieren. Auch bei dieser Tabelle sollten Sie Zu- und Abgang dokumentieren.

Zu allererst sollten Sie aber den Sinn und Zweck der Rolle kurz erklären, auch für wen sie erstellt wurde, also z.B.: “Rolle für Zahlungslauf-Einstellungen für Mandant….”. Auch eine kurze Erwähnung der Kritikalität der Rolle, sollte ggf. nicht fehlen. Also eine Information für bspw. den Benutzeradministrator, um zu wissen, wem er die Rolle zuordnen kann.

Kommen wir nun zum Rolleninhalt:

Hier sollten Sie in etwa folgendermaßen vorgehen. Sie fügen bspw. eine Transaktion in das Menü der Rolle in. Dann wechseln Sie in den Expertenmodus der Berechtigungsdarstellung. Hier erhalten Sie den Überblick, was Ihre Änderung bewirkt hat. Und genau das sollten Sie dokumentieren (also alle mit “neu” bezeichneten B-Objekte!).

Dabei genügt es Bildschirmausschnitte von den Änderungen und Auswirkungen zu machen. Sie sollten den Stand nach Einfügen der Transaktion festhalten und die einzelnen geänderten B-Objekte in die Dokumentation stellen. Danach führen Sie die Bewertung der gelben Objekte durch und dokumentieren die Bewertungen. Sonderdinge wie bestimmte Inaktivierungen von Objekten, sollten Sie in einem eigenen Kapitel der Dokumentation erwähnen. Sie sollten alles dokumentieren und mit Bildern belegen, was Sie wie bewerten. Ggf. sollten Sie auch kurze Begründungen angeben. Z.B. “Inaktivierung S_GUI, weil mit anderer Rolle dem Benutzer zugeordnet wird.”

Letztlich sollten Sie die Rolle so dokumentieren, dass Sie und vorallem Ihre Kollegen jederzeit nachvollziehen können, welche Änderungen Sie wegen einer Entwicklung xy an der Rolle vorgenommen haben. Je besser Sie das tun, um so weniger werden Sie in der Zukunft zusätzliche Eruierungen durchführen müssen, um zu wissen, welche Auswirkungen diese Entwicklung auf  Ihre Rollen hatten.

Wie geschrieben, das Worddokument ist nur eine Idee, wenn Sie andere Ideen der Gestaltung haben, dann schreiben Sie mir doch.

Gruß

Bernd Klüppelberg

Filed under: Dokumentation | No Comments »

Hallo,
heute soll es um die Rollendokumentation gehen! Wie halten Sie es mit der Dokumentation einer Rolle?

Es gibt einen alten Wahlspruch: “Alles ist dokumentiert, findet man keine F1-Doku, dann schaut man in den Quellsource”. Sie werden mir recht geben, wenn ich sage, das genau nach diesem Grundsatz viele Rollen dokumentiert sind.

Eine Rolle wird erstellt. Sie wird mehrmals geändert und transportiert. Warum, nun eine Änderung gemacht wurde, warum ein bestimmtes Objekt so und nicht anders bewertet wurde, ist nach einiger Zeit nicht mehr nach zu vollziehen.

Vielleicht wissen Sie als Rollenadministrator noch, warum diese Bewertung so gemacht wurde, aber andere? Ihre Urlaubsvertretung, Ihre Kollegen? Diese müssen dann nachfragen, und das Rätselraten beginnt.

Zugegeben, das System lässt wenig Platz für eine nachvollziehbare Dokumentation, denn der Bereich der Rollenbeschreibung in der PFCG ist nicht unbedingt der optimale Platz für die Doku! Was aber kann man tun, um auch noch nach einigen Monaten oder Jahren herauszubekommen, warum eine Objektbewertung gemacht wurde?

Oftmals finden Sie in der PFCG nur einen Zeitstempel, der aussagt, dass die Rolle zu einem bestimmten Datum geändert wurde. Mehr aber meist nicht.

Oft finden Sie in der PFCG-Beschreibung seitenlange Einträge, die unformatiert einiges über die Rolle aussagen, doch wer liest diese Dokumentation, wer erhält sie am Leben?

Wünschenswert wären doch Versionen von Rollen, die die Änderungen dokumentieren und begründen. Nun lässt das System aber keine Rollenversionen zu wie das bspw. bei Reports der Fall ist. Also muss man sich selbst etwas ausdenken.

Was sollte eine derartige Dokumentation enthalten?

1. Der „Sinn“ der Rolle: Was beinhaltet sie, für wen ist sie gedacht?
2. Die Historie der Rolle: Was wurde wegen was geändert (Problemtickets, Fehler etc.)
3. Wer hat die Änderungen gemacht
4. Welche Transaktionen besitzt die Rolle
5. Welche Organisationsebenenbewertungen hat die Rolle
6. Welche Objekte wurden wie bewertet und warum.
7. Sonderausprägungen der Rollen

Bei so vielen Informationen reicht der kleine editierbare Bereich der PFCG-Beschreibung bei Weitem nicht aus, da werden Sie mir Recht geben! Was kann man also tun?

Mein Vorschlag, auf den ich im Weiteren eingehen möchte, ist der einer eigenen Datei für die Rollendokumentation. Lassen Sie mich eine Dokumentationsmöglichkeit entwickeln, mit der Sie arbeiten können.

Klar Dokumentation hält auf, ist unbeliebt, um nicht zu sagen: ist lästig!

Doch bedenken Sie, dass die Revision und/oder die Wirtschaftsprüfer von Ihnen verlangen, Rollen zu dokumentieren und 10 Jahre aufzuheben. Manche gehen sogar soweit, dass Sie fordern, die Historie einer Rolle aufzeigen zu können. Vor allem aber mit der Dokumentation zu begründen, warum es diese Rolle gibt, für wen sie ist, und warum Änderungen an ihr gemacht wurden.

Sie können nicht alle Begründungen in Ihr Rollenkonzept schreiben. Das Rollenkonzept stellt aber eigentlich nur einen Rahmen dar, wie die Rollen aufgebaut sind, und welche Dinge generell für sie gelten. Die Ausprägung der Rolle selbst, können Sie aus Übersichtlichkeitsgründen nicht in das Konzept mit aufnehmen.

Also bleibt nur die externe Dokumentation. Wie aber soll diese organisiert werden? Es gibt zwar auf dem Markt Rollendokumentations-Tools, diese sind aber meist mit Kosten, eigenen Systemen und Einarbeitungszeiten verbunden, die eine leichte Wiederfindbarkeit und Bedienung erschweren. Was gesucht wird, wäre eine einfache Grundlage der Dokumentation.

Sie alle werden in Ihrer Unternehmung interne nur bestimmten Personen zugängliche Laufwerke im Netz haben. M.E. ist das genau der Platz, um eine Dokumentation einer Rolle zu speichern, die es leicht macht, wieder gefunden zu werden.

Das Mittel dazu ist ganz simpel Word und ein Screen-Printer-Programm wie z.B. SnagIt oder ein kostenlose Programm wie printScreen44. Man erspart sich dabei die Schulungskosten in andere Systeme und hat viel mehr Freiheitsgrade.

Es genügt schon ein Verzeichnis auf einem Laufwerk zu haben, wo man die Dokumente ablegen kann. Ein solches Verzeichnis könnte den Rollennamen als Unterverzeichnis haben. Innerhalb der Unterverzeichnisse stehen die einzelnen Versionen der Rollendokumentation als Worddateien.

Lassen Sie mich in den nächsten Artikeln auf eine derartig  leichte Dokumentationsmöglichkeit eingehen. Diese soll nur ein Vorschlag – eine Möglichkeit – aufzeigen. Das Umfeld ist sicherlich vielschichtig. Deshalb bin ich anderen Organisationsformen bzgl. der Rollendokumentation nie verschlossen, und halte meinen Vorschlag nicht als allein gültig.

Wenn Sie andere Organisationsformen besitzten, dann zögern Sie bitte nicht, mir diese zu schreiben.

Viele Grüße

Bernd Klüppelberg

Filed under: Allgemein, Dokumentation | No Comments »

Das SAP-System arbeitet mit den verschiedensten Organisationsebenen (sog. Org-Ebenen oder Org-Levels). Eine der häufigsten ist der Buchungskreis (BuKrs), aber auch Werk, Einkaufsorganisation, Vertriebsweg etc. gehören dazu.

Über diese Org-Ebenen kann man nun innerhalb einer Masterrolle die Berechtigungen „global“ vergeben, und diese Rolle nach den einzelnen Org-Ebenen ableiten. Es entsteht damit eine abgeleitete Rolle, in der bis auf die Org-Ebenen die gleichen Berechtigungen vorliegen wie in der Masterrolle. Diese Rolle wird dann durch die unterschiedliche Bewertung der Org-Ebene auf bestimmte Benutzer zugeschnitten, die für die Org-Ebenen die Rechte haben sollen.

Die Anzahl der abgeleiteten Rollen zu dem Master ist fast beliebig. Das hat den Vorteil, bei Änderungen des Masters mit nur einem Klick alle abgeleiteten Rollen zu generieren und die Anpassung zu übertragen.

Was ist aber bei Eigenentwicklungen, eigenen Berechtigungsobjekten mit der Verwendung der Org-Ebenen? Kann man eigene Org-Ebenen anlegen?

Es gibt im System einen Report mit dem Namen PFCG_ORGFIELD_CREATE, mit diesem lassen sich auf ein B-Objekt Org-Ebenen definieren.

Doch Vorsicht.

Lassen Sie den Report zunächst nur im sog. Testmodus laufen. Er ermittelt zunächst die Auswirkungen, die Ihr Vorhaben haben wird. Denn was ist mit den Rollen, in denen das B-Objekt schon existiert und das B-Feld schon bewertet ist?

Alle Rollen, bei denen Sie die betroffenen B-Objekte ändern, werden inaktiv und müssen nachbearbeitet werden. Deshalb ist es bei der Konzeption des Rollenkonzeptes so wichtig auch über die Org-Ebenen zu diskutieren.

Noch schlimmer: Das Org-Ebenen-Feld wird mandantenübergreifend angelegt, da die Rollen aber mandantenbezogen sind, müssen Sie in allen Mandanten den Report im Testmodus laufen lassen, um sich einen Überblick über die Auswirkungen zu verschaffen.

Je früher Sie die Entscheidung zur Einführung einer neuen Org-Ebene fassen, um so weniger Nachfolgearbeiten werden Sie haben. Wenn die Berechtigung bisher noch nicht verwendet wurde, dann haben Sie leichtes Spiel.

Auch lassen sich nicht alle Felder in Org-Ebenen umwandeln, so geht das bei der Aktivität (ACTVT) nicht. Bei den Transaktionscodes „TCD“ ist die Org-Ebene auch verboten..

Die Einführung neuer Org-Ebenen lassen sich auch nicht transportieren: Sie müssen in den einzelnen Systemen manuell definieren

Trotz allem kann es für den Rollenadministrator eine erhebliche Hilfe sein, neue Org-Ebenen zu definieren. Auch wenn damit Nacharbeiten an bestehenden Rollen notwendig werden. Denn die Möglichkeit der Ableitung nach einer Org-Ebene überkompensiert die Nacharbeiten.

Die Org-Ebenen sind technisch in der Tabelle USORG gespeichert. Erkennbar sind die Orgebenen im PFCG durch Bewertungen in den B-Feldern die eine $-Variable darstellen – also z.B. $BUKRS. Bitte achten Sie auf diese Bewertungen. Denn falls Sie eine $-Variable überschreiben, gibt das System zwar manchmal eine Meldung aus, nicht immer. In einem solchen Fall ist die Rolle fehlerhaft und lässt sich nach der Generierung nicht mehr reparieren.
.
Ich wünsche Ihnen viel Erfolg bei der Definition Ihrer ersten eigenen Org-Ebene

Bernd Klüppelberg

Filed under: Berechtigungsobjekt, Rollentypen | No Comments »

Hallo,

nach längerer Abstinenz, möchte ich Ihnen nun einen kleinen Trick verraten, der dann auftaucht, wenn Sie Rollen umbenennen.

Das eigentliche Umbenennen von Rollen gibt es im Standard nicht. Das heißt Sie müssen die Rolle auf einen neuen Namen kopieren und dann die alte Rolle löschen.

Alles schön und gut! Doch was passiert weiter? Wie kann ich diese Änderung transportieren?

Beim Löschen von Rollen in der Transaktion PFCG erhält man eine Info, dass man zuvor einen Transport mit der zu löschenden Rolle anlegen soll. Danach löscht man die Rolle.

Diesen Transportauftrag kann man nun transportieren, und in den Empfangssytemen wird die alte Rolle gelöscht und die neue angelegt, sofern sie auch in dem Transportauftrag war.

Was aber passiert dabei auf der Empfängerseite mit den zugeordneten Benutzern der alten Rolle? Sie sind ganz einfach weg! Alle Benutzer muß man dann der neuen Rolle wieder zuordnen, oder?

Nein, es gibt einen Trick, mit dem man das vermeiden kann.

Sie gehen vor dem Import des Transportes in das/die Empfangssystem(e) und kopieren dort die alte Rolle auf den neuen Namen. Damit gehen die zugeordneten Benutzer der Rolle mit in die neue Rolle über. Dazu benötigen Sie sicherlich schreibenden Zugriff auf die PFCG (auch im Produktivsystem, was man als temporäre Rolle zeitlich beschränke wohl tolerieren kann.)

Dann importieren Sie den Transport und die neue Rolle wird verändert, die Benutzer bleiben. Danach wird vom Transport die alte Rolle gelöscht und trotzdem ist alles klar.

Denken Sie also bei der Kopie von Rollen an diesen Trick, er lohnt sich.

Dieser Trick geht natürlich auch mit dem vorher geschilderten Trick mit der Umbenennung, schneller Weg

Viele Grüße

Bernd Klüppelberg

Filed under: SAP-Transporte, Tipps und Tricks | No Comments »

Sie haben eine Reihe von Berechtigungsrollen, die Sie aus irgendwelchen Gründen umbenennen wollen.

Im Standard hilft da nur das Kopieren der Rollen mit der PFCG und das Neuanlegen. Diese Methode kann ganz schön arbeitsintensiv sein. Denn stellen Sie sich vor, Sie haben ein Masterrolle und 50 Ableitungen.

Sie sollen nun alle Rollen auf einen neuen Namen kopieren und später die alten jeweils einzeln löschen.

Es gibt aber einen Weg, den Sie nehmen können. Dieser geht entsprechend dem des “Schnelltransport von Rollen zwischen Mandanten”: Der Download und das editieren der Downloaddatei.

Wenn Sie keine Verschiebungen in der Datei fabrizieren, können Sie diesen Weg gehen. Das Löschen der alten Rollen, ist aber weiterhin notwendig.

Gehen Sie also entsprechend dem Blog-Beitrag Schnelltransport von Rollen zwischen Mandanten vor.

Gruß
Bernd Klüppelberg

Filed under: SAP-Transporte, Tipps und Tricks | No Comments »

Hier soll eine kleine Übersicht entstehen, die die wichtigsten Hinweise aus dem SAP®- Marketplace anzeigt.

Die Hinweise beziehen sich meist auf die ECC 6.0.

 

1.  H132615 “Verwendungsnachweis für Berechtigungen”: In diesem Hinweis wird der Verwendungsnachweis des Berechtigungsobjektes im PFCG repariert. Bei hochgeladenen Rollen funktionierte der Nachweis (das Landschaftssymbol) nicht. Der Fehler tritt nur auf wenn man eine Rolle mit Up- und Download in ein System gestellt hat. (VERSION ECC6.0)

 

 

Diese Liste soll fortgesetzt werden

 

Gruß

Bernd Klüppelberg

Filed under: Allgemein, SAP-Hinweise | No Comments »