IAM vs GRC vs IAG: nowoczesny stack zarządzania dostępem SAP (przewodnik integracyjny 2026)

1. Dlaczego to pytanie pojawia się teraz

Większość dużych klientów SAP w 2026 roku ponownie ocenia swój stack zarządzania dostępem z trzech powodów naraz:

1. Koniec wsparcia SAP GRC Access Control 12 w 2027 (wsparcie standardowe) i 2033 (wsparcie przedłużone) wymusza decyzję - zostać, zastąpić lub zunifikować z szerszą platformą IAG.
2. Migracje do S/4HANA wprowadzają licencjonowanie oparte na FUE, gdzie projektowanie ról bezpośrednio napędza koszt - decyzje autoryzacyjne szybko stają się drogie.
3. Nowoczesne narzędzia IAM/IDM (SailPoint, Saviynt, Okta, Microsoft Entra) dojrzały poza uwierzytelnianie i teraz konkurują o warstwę governance, którą historycznie posiadał GRC AC.

Bardzo częsty instynkt na tym rozdrożu: „zbudujmy własne". Uproszczone narzędzie in-house brzmi taniej niż kolejna licencja SAP GRC. Nie jest. Ten artykuł wyjaśnia dlaczego i pokazuje nowoczesny wzorzec integracji, który faktycznie działa.

2. Stack, precyzyjnie

IAM (Identity and Access Management)

Dyscyplina zarządzania tożsamościami i uwierzytelnianiem: kto się loguje, przy użyciu jakich poświadczeń, z jakim MFA. Obejmuje provisioning użytkowników, SSO, zarządzanie sesją. Znane narzędzia: Microsoft Entra ID (dawniej Azure AD), Okta, Ping Identity, ForgeRock, Auth0.

IDM (Identity Management)

Podzbiór IAM dotyczący cyklu życia - procesy joiner, mover, leaver w wielu systemach. Natywne dla SAP: SAP IdM (obecnie w trybie utrzymania), SAP Cloud Identity Services. Cross-application: SailPoint IdentityNow, Saviynt EIC, Omada.

SAP GRC Access Control

Moduł GRC firmy SAP dedykowany ryzyku dostępu. Jego rdzeniem jest dojrzały silnik SoD analizujący dostęp na poziomie obiektu autoryzacji (nie tylko roli lub transakcji), plus dowody audytowe, zarządzanie dostępem awaryjnym i workflow wniosków o dostęp z kontrolami SoD. W użyciu w środowiskach SAP klasy enterprise od 15+ lat, znany każdemu audytorowi SAP - ale jest to duża, droga platforma on-premise. Wsparcie standardowe kończy się w 2027, przedłużone w 2033. Zdolność, którą zapewnia, ma znaczenie; rozmiar instalacji to to, czego większość klientów chce się pozbyć.

IAG (Identity and Access Governance)

Wyłaniająca się kategoria łącząca IAM/IDM (cykl życia) z GRC (governance, SoD, audyt) w jednej platformie - jeden dashboard dla wniosków, kontroli, provisioningu i dowodów. Przykłady: SailPoint IdentityIQ (szerszy), Saviynt EIC (szerszy), smartGRC (SAP-focused).

smartGRC

Nowoczesny silnik SoD dla systemów SAP i non-SAP - lekki następca tego, co dostarcza SAP GRC AC, bez ciężkiego footprintu platformy. Historia zaczyna się w SAP (gdzie SoD na poziomie obiektu autoryzacji jest najtrudniejszy); dziś ten sam silnik analizuje także aplikacje non-SAP (Salesforce, ServiceNow, Workday, aplikacje custom) i wykrywa toksyczne kombinacje cross-application - konflikty pojawiające się, gdy osoba kumuluje uprawnienia w SAP + non-SAP razem. Dostarczany jako usługi z REST API: klasyfikacja ról świadoma FUE, agenci AI do projektowania ról i rozwiązywania konfliktów, automatyzacja kampanii przeglądu. Wdróż tam, gdzie potrzebujesz: chmura (SaaS) lub on-premise (prywatne wdrożenie) - ten sam produkt, to samo API. To jest „czarna skrzynka", którą platforma IAG (Omada, SailPoint, Saviynt) wywołuje, by uzyskać werdykty SoD dla całego majątku aplikacyjnego - a nie kolejna ciężka platforma do zainstalowania.

3. Koniec wsparcia SAP GRC AC: trzy opcje - i ta, o której większość zespołów zapomina

Wsparcie standardowe SAP GRC Access Control 12 kończy się w 2027 (przedłużone w 2033). SAP GRC AC wykonuje realną pracę od 15+ lat, ale to ciężka platforma on-premise ze znaczącymi kosztami licencji, infrastruktury i operacyjnymi. Deadline EOL napędza teraz każdego dużego klienta SAP do podjęcia decyzji. Wybór jest zazwyczaj przedstawiany jako „zostać czy zastąpić" - ale to ujęcie ukrywa realne pytanie: zdolność silnika SoD musi przetrwać; ciężka platforma nie musi.

Trzy realne opcje

Dlaczego opcja 1 (zastąpienie) jest droższa niż się wydaje

Nowoczesne narzędzia IAG jak Omada czy SailPoint są doskonałe w orkiestracji cyklu życia - joiner, mover, leaver, provisioning cross-application, workflow zatwierdzeń. Czym nie są, to silnikiem SoD na poziomie obiektu autoryzacji SAP. Ich wbudowana analiza ryzyka dobrze radzi sobie z toksycznymi kombinacjami cross-application („ta osoba jest adminem w SAP ORAZ adminem w Salesforce"), ale nie sięga głęboko w obiekty autoryzacji SAP i ich wartości - poziomu, na którym żyją realne konflikty SoD w SAP.

Więc w momencie wycofania SAP GRC AC masz lukę. Albo:

• Przedłużasz SAP GRC AC do 2033 (płatne wsparcie przedłużone) tylko po to, by silnik SoD działał obok nowego IAG - płacisz teraz za oba
• Budujesz wewnętrzny analizator SoD - wpadasz w opcję 2 powyżej
• Korzystasz z modułu ryzyka w IAG i akceptujesz, że nie sięga do poziomu obiektu - trudna sprzedaż audytorowi

Ukryty koszt opcji 1 to nie licencja IAG. To luka SoD, której IAG nie zamyka.

Dlaczego opcja 2 (budowa) rzadko się opłaca

Instynkt zbudowania prostszego narzędzia in-house jest realny. Zazwyczaj przegrywa, gdy rozłożysz to, co narzędzie SoD faktycznie zawiera:

90%, które jest drogie i trudne do odbudowania

Dwa fakty zmieniają sposób myślenia o „build vs buy":

• Wartość narzędzia SoD to z grubsza 90% ruleset + silnik na poziomie obiektu, 10% UX i raportowanie. Projekt budowy własnego atakuje dokładnie te trudne 90%.
• Ruleset to nie projekt kodowania - to lata skumulowanej wiedzy o modułach SAP mapującej setki do tysięcy funkcji biznesowych na ich wzorce obiektów autoryzacji. Budowa wewnętrzna oznacza odtworzenie tej bazy wiedzy.

Co faktycznie kosztuje, kiedy budujesz

Z realnych projektów transformacyjnych (skala dużego przedsiębiorstwa: kilka instancji SAP, tysiące użytkowników, 20 000+ ról, miliony obiektów autoryzacji):

• Konfigurowalny silnik workflow (ekwiwalent MSMP) - warunkowy routing, delegowanie, eskalacja, powiadomienia, zatwierdzenia 1-5 stopni w kilkunastu typach procesów
• Silnik SoD na poziomie obiektu - tryby wsadowy + symulacja, kontrole mitygujące, reguły organizacyjne
• Silnik zarządzania rolami - derywacja na poziomie org, wielosystemowe role biznesowe, generowanie ról w systemie docelowym
• Warstwa provisioningu i integracji - konektory do każdego systemu docelowego, integracja z CUA/HCM, synchronizacja
• Dostęp awaryjny z rejestrowaniem logów - skorelowane ścieżki audytu z każdego systemu źródłowego
• Odtworzenie treści SoD - sam ruleset (najwyższy ukryty koszt, niezależny od technologii)
• Workflowy zarządzania zmianą wokół SoD - zarządzanie zmianą funkcji i ryzyk, zarządzanie zmianą katalogu mitygacji
• Provisioning wyzwalany zdarzeniami HR - joiners/movers/leavers z HCM do wszystkich systemów downstream

Realistyczny budżet: 12+ miesięcy developmentu, podwójny koszt licencji podczas przejścia, brak gwarancji parytetu wyników z audytowanym baseline'em we wczesnych wydaniach oraz trwałe przeniesienie odpowiedzialności za bezpieczeństwo i utrzymanie na zespół wewnętrzny. I nadal musisz udowodnić audytorom, że Twój silnik produkuje te same liczby ryzyka co silnik SAP GRC, którego wszyscy używali wczoraj.

Co zostaje jako nieredukowalny rdzeń

Nawet po uproszczeniu każdego peryferyjnego elementu, nieredukowalnym rdzeniem rozwiązania SoD pozostaje silnik analizy SoD na poziomie obiektu autoryzacji - ten, który weryfikuje, czy konkretne obiekty autoryzacji i wartości pojawiają się w rolach, a nie ten oparty na opisach biznesowych. To poprawne podejście z perspektywy kontroli. Budowa od zera, w opisanej skali, jest elementem o najwyższym koszcie i najwyższym ryzyku - i to on, nie komponenty peryferyjne, determinuje koszt i ryzyko ścieżki budowy.

Skarga „wyjście GRC jest zbyt techniczne" jest realna. Ale to problem warstwy raportowania, nie problem silnika analizy. Można go rozwiązać, umieszczając warstwę prezentacji (w tym asystenta AI) nad istniejącym wyjściem silnika - nieproporcjonalnie taniej niż odtwarzanie silnika. To powinno więc być kryterium wyboru narzędzia, a nie uzasadnieniem jego budowy.

Dlaczego opcja 3 (SoD-as-a-Service) to odpowiedź, o której większość zespołów zapomina

Pułapka ujęcia „zastąp vs zbuduj" polega na tym, że obie opcje zakładają, że posiadasz silnik SoD. Gdy zaakceptujesz, że silnik SoD to dojrzała, standaryzowana zdolność - jak obliczanie podatku, konwersja waluty czy walidacja adresu - staje się oczywiste, że możesz subskrybować go zamiast posiadać.

Co zastępuje SoD-as-a-Service

• Zamiast wsparcia przedłużonego SAP GRC AC - tylko koszt subskrypcji, żadnego legacy narzędzia do utrzymania przy życiu
• Zamiast budowy własnego analizatora SoD - silnik istnieje, ruleset istnieje, audyt już ufa metodologii bazowej
• Zamiast płacenia za dwa narzędzia - IAG zostaje IAG (orkiestracja), usługa SoD robi analizę SoD. Żadnej duplikacji.
• Zamiast niejasnego „modułu ryzyka IAG" - analiza na poziomie obiektu mapująca na obiekty autoryzacji i wartości SAP, poziom oczekiwany przez audytorów

Dlaczego to lepszy model ekonomiczny niż licencjonowanie

Porównaj w perspektywie 5 lat dla średniej wielkości przedsiębiorstwa SAP (~3 000 użytkowników):

Jak smartGRC dostarcza SoD-as-a-Service

smartGRC oferuje dokładnie ten model: analiza SoD na poziomie obiektu dla SAP (obiekty autoryzacji + pola + wartości) + analiza na poziomie uprawnień dla aplikacji non-SAP + wykrywanie toksycznych kombinacji cross-application, klasyfikacja ról świadoma FUE, zarządzanie kontrolami mitygującymi i dowody audytowe - wszystko dostarczane jako usługi z REST API. Twoja platforma IAG wysyła scenariusz wniosku o dostęp, smartGRC zwraca werdykt ryzyka. Żadnej równoległej instalacji, żadnego rulesetu do utrzymania.

Obsługiwane konkretne scenariusze API:

• Kontrola what-if SoD - „użytkownik X + proponowana rola Y, jakie konflikty SoD się pojawiają, na jakim poziomie ryzyka?"
• Walidacja roli - „czy ta proponowana kompozycja roli tworzy konflikty sama w sobie?"
• Analiza populacji - „w całej populacji użytkowników, kto ma ten konkretny konflikt teraz?"
• Wpływ klasyfikacji FUE - „jeśli sprovisionujemy tę rolę, jak zmieni się klasa FUE użytkownika?"
• Przypisanie kontroli mitygującej - „konflikt nieunikniony - którą kontrolę należy przypisać, z jakim właścicielem?"
• Dane do przeglądu uprawnień - „dla użytkownika X, jaki ma dostęp i jakie są ryzyka SoD?"
• Eksport dowodów audytowych - „wygeneruj pakiet audytorski za ten okres"

Platforma IAG (Omada, SailPoint itp.) nigdy nie musi znać wewnętrznych szczegółów obiektów autoryzacji SAP. Wysyła scenariusz biznesowy, dostaje odpowiedź, zapisuje decyzję. Złożoność specyficzna dla SAP zostaje w usłudze specyficznej dla SAP.

4. Nowoczesny wzorzec integracji - best of each vendor

Zamiast stacku jednego dostawcy, wzorzec, który działa w 2026 roku, jest modularny:

Filozofia: wziąć najlepsze od każdego dostawcy, zintegrować przez API, nie duplikować.

5. Jak smartGRC się wpina - integracja REST API

smartGRC nie ma na celu zastąpić silnika SoD SAP GRC Access Control ani warstwy provisioningu narzędzia IAM. Wpina się jako warstwa usług przez REST API, która dodaje zdolności, których żadne z pozostałych dwóch nie zapewnia dobrze:

Wsparcie projektowania ról podczas wniosków o dostęp

Gdy narzędzie IAM otrzymuje wniosek o dostęp, może wywołać REST API smartGRC z pytaniem: „dla żądanej funkcji biznesowej, jaka jest minimalna kompozycja roli, świadoma bieżącego wpływu klasy FUE i implikacji SoD?" smartGRC zwraca rekomendację roli (istniejąca rola pasująca lub minimalny zestaw autoryzacji do zbudowania nowej). Narzędzie IAM następnie rutuje rekomendację przez własny workflow zatwierdzania.

Symulacja what-if SoD przed provisioningiem

Zanim narzędzie IAM faktycznie zrobi provisioning, może wywołać endpoint what-if smartGRC z docelowym użytkownikiem i proponowanym zestawem ról. smartGRC zwraca wpływ SoD (włącznie ze zmianą klasy FUE i efektem na populacji użytkowników). Jeśli ryzyko jest akceptowalne, provisioning przebiega; jeśli nie, uruchamiana jest mitygacja - wszystko przez API, bez konieczności ręcznego logowania do GRC AC.

Zarządzanie kampaniami przeglądu uprawnień

Okresowe przeglądy tradycyjnie działają w SAP GRC lub Excelu. smartGRC może pobrać bieżący stan przez API, uruchomić kampanię przeglądu (listy zadań per manager, zbieranie dowodów, śledzenie sign-off) i wypchnąć decyzje z powrotem do narzędzia IAM do wykonania. GRC AC pozostaje źródłem prawdy audytowej; smartGRC dodaje nowoczesny UX przeglądu.

Analiza świadoma FUE dla projektów S/4HANA

SAP GRC AC nie rozumie natywnie licencjonowania FUE (Full User Equivalent). smartGRC rozumie - mapuje autoryzacje użytkownika na klasyfikację FUE (Core, Advanced, Developer Use) używając rulesetu SAP. W workflow wniosków o dostęp oznacza to „zaraz przeniesiesz tego użytkownika z Self-Service do Advanced Use - to sześciocyfrowa kwota rocznie" - sygnał, którego sam SAP GRC AC nie może dostarczyć. Zobacz nasze FUE by Design case study po pełną technikę.

Agenci AI do odkrywania wzorców

19 agentów AI smartGRC (rozwiązywanie konfliktów SoD, wykrywanie nakładania się ról, wykrywanie anomalii w użyciu Firefighter i więcej) działa nad danymi, które IAM i GRC AC już zbierają. Zamiast równoległej infrastruktury danych, smartGRC czyta przez API i dodaje warstwę analityczną.

6. Praktyczne scenariusze integracji

Scenariusz A: przedsiębiorstwo z SailPoint + SAP GRC AC (zostają do EOL)

Częsty w dużych usługach finansowych i produkcji, które jeszcze nie zeszły z SAP GRC AC. SailPoint obsługuje cykl życia użytkownika we wszystkich systemach non-SAP (Salesforce, ServiceNow, Workday, aplikacje custom). SAP GRC AC obsługuje SoD specyficzne dla SAP. smartGRC dodaje warstwę projektowania ról świadomą FUE podczas migracji do S/4HANA - element, którego brakuje zarówno SailPointowi, jak i legacy SAP GRC AC. To wzorzec pomostowy - działa dzisiaj, ale zależność od SAP GRC AC musi zostać wycofana przed końcem wsparcia przedłużonego.

Scenariusz B: średniej wielkości organizacja SAP-centryczna zastępująca SAP GRC AC 12

Koniec wsparcia standardowego SAP GRC AC 12 w 2027 popycha wielu średniej wielkości klientów do konsolidacji. Zamiast licencjonować pełny nowy stack SailPoint plus przedłużać wsparcie SAP GRC AC, subskrybują smartGRC jako silnik SoD (przez REST API) i parują go z lekkim IAM (Microsoft Entra ID) do SSO cross-app, jeśli potrzebne. Jedna usługa SoD. Jeden IAM. Żadnej ciężkiej platformy GRC on-prem do utrzymania.

Scenariusz C: przedsiębiorstwo z Saviynt EIC + custom narzędzia SAP

Niektóre organizacje zbudowały przez lata częściowe wewnętrzne narzędzia zarządzania dostępem SAP - proste kontrole SoD w raportach, katalog ról w wiki. Saviynt obsługuje cykl życia. smartGRC wpina się jako warstwa analityczna specyficzna dla SAP, której wewnętrzne narzędzie nie jest w stanie zapewnić (analiza FUE, świadomość katalogu Fiori S/4HANA, agenci AI). Bez odbudowy Saviynt ani wewnętrznych narzędzi.

Scenariusz D: hybryda ze zmierzchającym SAP IdM

SAP IdM jest w trybie utrzymania. Klienci go używający potrzebują następcy. smartGRC może operować obok SAP IdM w okresie przejściowym (SAP IdM obsługuje legacy provisioning, smartGRC obsługuje nowe wnioski o dostęp i przeglądy), stopniowo przejmując odpowiedzialność za cykl życia w miarę budowania zaufania.

Scenariusz E: przedsiębiorstwo OMADA-centryczne wycofujące SAP GRC (realny wzorzec klienta)

Wzorzec, który widzimy wielokrotnie: duże przedsiębiorstwo z heterogenicznym, hybrydowym krajobrazem SAP - S/4HANA on-prem jako system wiodący (tysiące użytkowników, 15+ podmiotów), plus SAP BTP i SAP SuccessFactors w chmurze - decyduje się stopniowo wycofać SAP GRC (typowo do 2028, zgodnie z końcem wsparcia standardowego) i oprzeć tworzenie kont oraz nadawanie uprawnień na Omada jako centralnej platformie IGA.

Strategiczne pytanie w tym wzorcu to nie „które narzędzie zastępuje SAP GRC end-to-end". To: jak wnieść kompetencję po stronie SAP do stacku orkiestrowanego przez Omada, tak aby architektura autoryzacji, provisioning ról i analiza SoD nadal działały poprawnie w SAP w chmurze + on-prem?

Krytyczna decyzja w tym scenariuszu: gdzie odbywa się analiza SoD?

Trzy opcje, każda z kompromisami:

1. SoD po stronie Omada - buduj reguły SoD w ramach własnej analizy ryzyka Omada. Działa dla governance cross-application, ale Omada nie rozumie natywnie obiektów autoryzacji SAP na głębokość, jaką rozumie SAP GRC. Nie wykrywa konfliktów SoD na poziomie obiektu. Niewystarczające dla SoD SAP klasy audytowej.
2. SoD po stronie SAP (warstwa usług) - wywołuj silnik SoD świadomy SAP (resztka SAP GRC AC, smartGRC przez REST API lub odpowiednik) podczas workflow wniosków o dostęp Omada. Omada dostaje wynik ryzyka i uwzględnia go w swojej logice decyzyjnej. Analiza na poziomie obiektu zostaje tam, gdzie należy (przy silniku znającym SAP). To wzorzec działający dla regulowanych przedsiębiorstw.
3. Model mieszany - Omada obsługuje ryzyko cross-application (np. „ta osoba ma admina w SAP ORAZ admina w Salesforce - toksyczna kombinacja"), silnik po stronie SAP obsługuje SoD na poziomie obiektu SAP. Oba karmią ślad audytowy Omada.

Pragmatyczna odpowiedź to opcja 2 lub 3, z analizą SoD utrzymywaną po stronie SAP. To dokładnie wzorzec integracji, do którego zbudowano REST API smartGRC - Omada wywołuje smartGRC przed zatwierdzeniem dostępu SAP, smartGRC zwraca wpływ SoD (włącznie ze zmianą klasy FUE dla S/4HANA), Omada używa tego w swoim przepływie zatwierdzania.

Rola ekspertyzy po stronie SAP w tej tranzycji

Wycofanie SAP GRC nie jest lift-and-shift. Zdolności po stronie SAP, które historycznie tkwiły w GRC AC, muszą zostać redystrybuowane:

• Architektura autoryzacji: katalog ról, derywacja na poziomie org, kompozycja ról biznesowych - zostaje po stronie SAP, wywoływana przez Omada
• Przepływy provisioningu ról: jak przypisanie roli zamienia się w konkretne nadanie obiektów autoryzacji - konfigurowane w Cloud Identity Services lub bezpośrednich konektorach SAP
• Analiza SoD: opcja 2 lub 3 powyżej
• Dostęp awaryjny (ekwiwalent Firefighter): zostaje po stronie SAP z rejestrowaniem logów; Omada zapisuje workflow zatwierdzania, ale faktyczna sesja uprzywilejowana działa w SAP

To jest profil pracy, który wyspecjalizowane firmy praktyki SAP (jak nasza siostrzana firma GRC Advisory) wnoszą do programów prowadzonych przez Omada: architektura autoryzacji SAP, konfiguracja provisioningu ról dla S/4HANA + BTP + SuccessFactors oraz jasna rekomendacja, gdzie w nowej architekturze ląduje analiza SoD.

7. Dlaczego „zbudujmy prostsze narzędzie" prawie zawsze przegrywa

Instynkt jest zrozumiały: SAP GRC AC wydaje się ciężki, jego UX jest przestarzały, a koszt licencji znaczący. Budowa lżejszego wewnętrznego zamiennika brzmi, jakby powinna być tańsza. W praktyce:

• 90%, które jest drogie, pozostaje drogie. Ruleset i silnik na poziomie obiektu to nie to, co rozwiązuje prostszy UX. Nadal ich potrzebujesz.
• Zaufanie audytorów nie jest darmowe. Nowe wewnętrzne narzędzie musi udowodnić audytorom, że jego kalkulacje ryzyka pasują do liczb, które widzieli rok temu. Rozbieżność z audytowanym baseline'em to realne ryzyko compliance.
• Zobowiązanie utrzymania przenosi się trwale. SAP aktualizuje swoje obiekty autoryzacji, dostarcza nowe transakcje, zmienia katalogi Fiori. Każda zmiana wpływa na ruleset. Zewnętrzny dostawca wchłania ten koszt; wewnętrzny zespół posiada go na zawsze.
• Wydajność w skali to realny problem inżynierski. Miliony obiektów autoryzacji w kilku instancjach wymagają zoptymalizowanego przetwarzania danych. W dojrzałych produktach jest to rozwiązane out of the box.
• Czytelność wyjścia to problem prezentacji, nie problem silnika. Najczęstsza skarga na SAP GRC AC („wyjście jest zbyt techniczne dla użytkowników biznesowych") jest odpowiadana dodaniem warstwy raportowania lub AI, a nie przepisaniem silnika.

Poprawne ujęcie to nie „zbuduj tańszy GRC", ale „użyj silnika SAP GRC AC, dodaj lepszy UX i AI na wierzchu przez API". To wzorzec smartGRC.

8. Framework decyzyjny

Zostaw SAP GRC AC + dodaj warstwę usług jeśli:

• Duży majątek SAP (tysiące użytkowników, dziesiątki ról, wiele instancji)
• Silna historia audytowa z już dostrojonym rulesetem SAP GRC AC
• Branża regulowana, gdzie zaufanie audytorów ma znaczenie
• Migracja do S/4HANA w toku (potrzeba analizy FUE)

Skonsoliduj do zunifikowanego IAG (smartGRC lub podobnego) jeśli:

• Średniej wielkości organizacja SAP-centryczna
• Presja końca wsparcia SAP GRC AC 12 i brak apetytu na migrację do SAP GRC 15/następnego
• Priorytet uproszczenia - jedna platforma zarządzania dostępem SAP bije dwie

Dodaj narzędzie IAM obok jeśli:

• Wiele systemów non-SAP w zakresie (Salesforce, ServiceNow, aplikacje custom)
• Potrzeba SSO/MFA we wszystkich aplikacjach biznesowych
• Wymagania compliance poza SAP

NIE buduj własnego silnika SoD, chyba że:

• Bardzo mały footprint SAP (mniej niż 200 użytkowników, jedna instancja)
• Kontekst nieregulowany bez zewnętrznego audytu
• Masz nietypowe, dobrze zdefiniowane wymagania SoD, których żaden dostawca nie pokrywa

Nawet w tych przypadkach uczciwa kalkulacja typowo przemawia za kupnem.

9. Podsumowanie

Debata ujęta jako „IAM vs GRC" to niewłaściwa debata. Oba są potrzebne. Realne pytanie brzmi jak je zintegrować kosztowo efektywnie przy zachowaniu zaufania audytorów.

Nowoczesna odpowiedź to integracja best-of-breed: SAP GRC Access Control jako silnik SoD (nie odbudowuj), narzędzia IAM/IDM dla cyklu życia we wszystkich systemach (SailPoint, Saviynt, Okta) i warstwa usług jak smartGRC przez REST API dla elementów, których żadne z nich nie zapewnia dobrze - projektowanie ról napędzane AI, analiza świadoma FUE, nowoczesne kampanie przeglądu. Weź najlepsze od każdego dostawcy. Zintegruj, nie duplikuj. I nie spędzaj 12 miesięcy na odbudowie tego, czemu audytorzy już ufają.