• Es sind alle Rollen erstellt.
• Rollen sind zu Rollengruppen zusammengefasst, dies kann z. B. eine Rollengruppe für AZUBIS 1. Lehrjahr FI Hamburg, AZUBIS 2. Lehrjahr FI Hamburg, AZUBIS 3. Lehrjahr FI Hamburg, Standard Buchhalter Hamburg, Monatsabschluss Buchhalter Hamburg, Jahresabschluss Buchhalter Hamburg, Nur anzeigen Buchhaltung Hamburg, sein.
• User sind zu Usergruppen zusammengefasst, dies kann z. B. eine Usergruppe für AZUBIS 1. Lehrjahr FI Hamburg, AZUBIS 2. Lehrjahr FI Hamburg, AZUBIS 3. Lehrjahr FI Hamburg, Standard Buchhalter Hamburg, Monatsabschluss Buchhalter Hamburg, Jahresabschluss Buchhalter Hamburg, Nur anzeigen Buchhaltung Hamburg, sein.
• Rollen, Rollengruppen, User und Usergruppen werden nun logisch zusammengefasst in einer von uns sogenannten Matrix. Diese Matrix könnte z. B. „FI Hamburg“ heißen und würde die o. g. Rollen- und Usergruppen umfassen. Es könnte zusätzlich auch noch die einzelnen Rollen und User für Hamburg mit aufgenommen werden.

Als nächster Schritt wäre zu definieren, wer welche Rechte auszuüben hat. Sinniger Weise wird ein User für die Antragstellung und einer für die Antragsfreigabe definiert. Es können aber auch weitere „zusätzliche“ Freigeber definiert werden, oder das was für Ihr Unternehmen am Sinnigsten ist.

Spätestens ab diesem Punkt sollte unserer Erfahrung nach der Übergang von den Fachleuten des Berechtigungswesen an die Fachabteilung erfolgen. Die Fachabteilung sollte nun auf Grund der geleisteten Vorarbeiten in der Lage sein, jedem Endanwender die Rechte zuzuordnen die er für seine Tätigkeit benötigt und zwar nach dem Minimalprinzip!

Szenario 1

Wir nennen dieses Vorgehen das klassische Szenario. Jeder SAP R/3 User bekommt vorübergehend einen zweiten User der genau die Rechte / Rollen beinhaltet die er schon immer hatte. Mit diesem neuen R/3 User kann der Endanwender wie bisher all seine Tätigkeiten durchführen und dient als „backup“ für die Testphase. Dieser User ist gesperrt und wird nur bei länger dauernden Änderungen aktiviert. Dieser R/3 User bleibt solange aktiv, bis die Umstellung auf die neuen Rollen in seinem ursprünglichen R/3 User erfolgt und getestet sind. Danach wird dieser temporäre R/3 User wieder gelöscht.
Das Testen der neuen Rollen im ursprünglichen R/3 User obliegt nun dem Endanwender selbst. Dieser wird nun dem Modulbetreuer, Keyuser, Antragsteller mitteilen, ob die ihm zugewiesen Rollen ausreichen. In der Regel werden weitere Rechte / Rollen dem User zugewiesen, wie sollte es denn auch anders sein. Die Aussage: „Das ist zuviel, das brauche ich nicht, weg damit“, wird die Ausnahme darstellen.
Kann der User mit den neuen Rollen arbeiten, so ist die Umstellung erfolgt und der temporäre User kann gelöscht werden. Das Management, die Antragsteller und Freigeber können an Hand der Revisionskommentare nun sehr einfach feststellen, ob sich bei diesem User Rechte häufen, die er nach vorheriger Definition gar nicht haben sollte. Hier ist jetzt im Einzelfall vom Business zu entscheiden wie zu verfahren ist. Spätestens bei der nächsten Prüfung durch Dritte ist dann die Frage zu beantworten, warum dieser User zu viele Rechte / Rollen hat.

Szenario 2

Wir nennen dieses Vorgehen den pragmatischen Weg. Der wesentliche Unterschied zum Szenario 1 besteht darin, dass die Modulbetreuer, Keyuser, Antragsteller für die Abteilung insgesamt den Test übernehmen und bestimmen, wer welche Rechte / Rollen bekommt.
Der Test findet „bottom up“ statt. Es werden zuerst die Rechte / Rollen für die geringste Ausprägung zusammengestellt und ausgetestet. In unserem Beispiel wäre dies der „AZUBI 1. Lehrjahr FI Hamburg“. Ist dieser Test letztendlich erfolgreich durchlaufen, mit oder ohne Änderungen an den Rollen, können diese Rollen den AZUBI’s 1. Lehrjahr zugewiesen werden. Dieser Test wiederholt sich nun für jede Gruppe von Usern in dieser Abteilung bis hin zum „Jahresabschluss Buchhalter Hamburg“.
Vorteile dieses Vorgehens sind, dass sich die Fachabteilung selbst berechtigt, testet und den Zeitpunkt für den Einsatz der neuen Rollen selbst bestimmen kann. Mit dem Keyuser wird ein „Wissender“ mit der Rollenvergabe und den Tests beauftragt. Abstimmungen, dies betrifft mögliche Änderungen an Rollen oder weitere Rollen und Rollengruppen in der Matrix, können mit den Fachleuten für die Berechtigungen (IT), einfacher erfolgen, denn man kennt sich und spricht die gleiche Sprache. Der Keyuser hat einen anderen Blick auf die Rollen- / Rechtevergabe als der Endanwender. Er wird darauf drängen vorher definierte Revisionskommentare beim User auch einzuhalten.

Es sind weitere Szenarien denkbar aber immer mit direktem Bezug zur Kundensituation. Wo sitzen meine Leistungsträger, wer kann was in welchem Umfang leisten, wer muss geschult werden, usw.

In die Teststrategie sollte das BUM Infosystem sowie der BUM Audit mit einbezogen werden.

• BUM Audit

Sie definieren im BUM Audit für Ihr Unternehmen was aus Ihrer Sicht ein Verstoß im R/3 ist. Die Wirtschaftsprüfer und die Revision werden Ihnen dabei bestimmt gerne helfen.

Da die Anforderungen an einen R/3 Audit sich von Unternehmen zu Unternehmen zum Teil stark unterscheiden liefern wir Ihnen ein Template von Verstößen, dass Sie auf Ihr Unternehmen anpassen. Die von Ihnen definierten Verstöße werden dann als Gesamtaudit gegen das gesamte R/3 System mit all seinen Rollen und Usern durchgeführt.

Ferner können Sie bei der Rollenerstellung direkt gegen den Audit verproben und mögliche Verstöße bereits in der Entstehung vermeiden. Gleiches gilt für die Erstellung von Rollengruppen (Sammelrollen). Werden Usern Rollen zugewiesen, wird dies gegen den Audit verprobt und mögliche Verstöße online angezeigt.

Der BUM Audit kontrolliert Ihr gesamtes tun im Prozess der Rollenerstellung, der Rollengruppierung und der Zuweisung zum User nach Ihren definierten Vorgaben. Der BUM - Audit schaft transparenz in Ihrem Berechtigungswesen. Er kann keinen Test ersetzen aber erheblich die Testzeiten reduzieren.