Problemów jest kilka i pochodzą z różnych obszarów, a najbardziej oczywisty z nich polega na tym, że te role dają za dużo. I nie jest to błąd, tylko założenie, bo mają pokazać maksimum tego, co da się zrobić w danym obszarze, a nie dokładnie tyle, ile potrzebuje konkretna osoba. Taka nadmiarowość uderza w dwa miejsca naraz: w portfel i w bezpieczeństwo.

Nadmiarowe role podnoszą koszt licencji FUE

Portfel najłatwiej pokazać każdemu, bo w S/4HANA płacisz za poziom dostępu użytkownika, a miarą są licencje FUE. Im szerszy dostęp, tym drożej. Nadmiarowa rola to więc nie tylko ryzyko, ale też wyższa faktura za aplikacje, których nikt nigdy nie użyje. Ten argument trafia do każdego, kto pilnuje budżetu.

Przykład z praktyki prowadzących: przy analizie FUE u klienta, który miał wdrożone role standardowe, 44 z 47 użytkowników miało najwyższą licencję.

Rozdział obowiązków (SoD) nie pasuje do ról stanowiskowych

Druga strona to bezpieczeństwo, a konkretnie rozdział obowiązków (SoD, segregation of duties). Ta sama osoba nie powinna móc na przykład założyć dostawcy i od razu zrobić sobie przelewu, bo to prosta droga do nadużycia. Role standardowe łamią tę zasadę, ponieważ zbudowano je wokół szerokiego stanowiska: cała rola w jednym kawałku.

Rozdział obowiązków tnie w poprzek stanowiska, a role standardowe obejmują całe stanowisko procesowe naraz. Gdy próbujesz rozbić taką rolę na dwie osoby, żeby nikt nie miał wszystkiego, okazuje się, że jej elementy są ze sobą tak sklejone, że nie da się ich czysto rozdzielić.

Mit bezpiecznych ról od producenta

Najczęstszy mit w tym temacie brzmi tak: role od SAP są bezpieczne i czyste pod kątem konfliktów, bo dostarczył je sam producent systemu. Jest dokładnie odwrotnie. Właśnie dlatego, że mają pokazać wszystko, konflikty SoD mają zaszyte w środku.

Czy wystarczy przyciąć rolę standardową?

Naturalny odruch brzmi: wezmę rolę, przytnę ją i zostawię tylko to, co potrzebne. Kierunek jest dobry, ale otwiera inny, głębszy problem, bo wszystko zależy od tego, na jakich założeniach przycinasz.

Transakcje to nie wszystko, zostają katalogi Fiori

Żeby poprawnie przyciąć rolę, nie wystarczy usunąć z niej transakcji, bo zostaje Fiori. Katalogi Fiori trzeba zbudować na nowo, ponieważ role SAP używają katalogów standardowych, których za bardzo nie da się modyfikować. Zostajesz z pytaniem, co jest lepsze: przebudowa czy budowa od nowa.

Grupy czy Spaces and Pages?

Dochodzi do tego nawigacja: role standardowe w dużej mierze opierają się na grupach, a SAP odchodzi od grup na rzecz Spaces and Pages (po polsku: strony i przestrzenie). Prowadzący mówią wprost, że SAP grupy wycofał, a w rolach opartych na grupach widzą ogromne problemy wydajnościowe. Nowe wdrożenia powinny więc opierać się wyłącznie na Spaces and Pages. Z doświadczenia prowadzących wynika jednak, że w rolach standardowych Spaces and Pages nie są dobrze zbudowane.

Pułapka generowania ról przez task list

Jest też mechanizm, który potrafi wygenerować role standardowe masowo, hurtem: task list. Wygodne rozwiązanie, tylko że z haczykiem: wszędzie tam, gdzie wartość jest pusta, generator wstawia gwiazdkę. A gwiazdka w uprawnieniach oznacza mniej więcej wszystko dla wszystkich.

Klikasz „generuj”, widzisz gotowe role i zamykasz temat. W rzeczywistości rozdałeś dostęp do wszystkiego i nawet o tym nie wiesz.

Czego brakuje w rolach standardowych?

Skoro role standardowe są tak szerokie, łatwo przeoczyć, że czegoś w nich brakuje. Chodzi o role display, przeznaczone tylko do wyświetlania danych. Potrzebuje ich każda organizacja: dla audytora, członka zarządu, stażysty na start. W standardzie takiej roli po prostu nie ma, więc musisz ją zbudować sam, a to wcale nie jest proste.

Własne role zamiast standardu

Czy to znaczy, że ról standardowych nie wolno dotykać? Z doświadczenia Kacpra i Kamila wynika, że najczęściej nie warto na nich budować. W wielu projektach wyrzucają je do kosza i tworzą nowy koncept od zera, bo przerabianie standardu się nie opłaca. Lepiej zaprojektować nowe role dopasowane do organizacji, z uwzględnieniem ryzyka SoD.

Puenta jest prosta: SAP daje klientowi przepis na proces, ale nawet dobry przepis na proces nie jest jeszcze dobrym przepisem na uprawnienia. Ról standardowych nie powinno się wdrażać na produkcji, bo role mają być własne i dopasowane do organizacji, a standard niech zostanie na DEV.

Obejrzyj odcinek i daj znać w komentarzu

Ten tekst powstał na podstawie odcinka „Role standardowe. Każdy zna, nikt nie potrzebuje”. Kacper i Kamil pokazują w nim role standardowe SAP z perspektywy projektów: od presji przed go-live, przez licencje FUE i konflikty SoD, po gwiazdki w rolach generowanych hurtem. Temat grup, Spaces and Pages i upgrade’u takich ról zostawili na osobny odcinek. Obejrzyj rozmowę na kanale GRC Ninja i napisz w komentarzu, czy chcesz zobaczyć bardziej techniczny odcinek o rolach standardowych.

Planujesz przegląd uprawnień albo budowę własnych ról w S/4HANA? Skontaktuj się z GRC Advisory i porozmawiajmy o Twoim projekcie.