Un progetto di revisione delle autorizzazioni (SAP Authorization Review) è uno dei progetti più rilevanti e spesso sottovalutati nell'ambito della sicurezza e della governance dei sistemi SAP. Nel corso degli anni abbiamo affrontato centinaia di iniziative di questo tipo, per organizzazioni con qualche decina di utenti fino a realtà con decine di migliaia di utenze distribuite su più geografie/società.

Uno degli errori più frequenti non è tecnico: è non sapere chi coinvolgere e quando. In questo articolo rispondiamo a questa domanda in modo pratico, partendo da cosa si intende per Authorization Review e da quali sono le ragioni reali per avviarla.

Cos'è una SAP Authorization Review?

Nel progetto di SAP Authorization Review si rivede integralmente il modello autorizzativo definito nel sistema SAP, analizzando tutte le utenze attive.

L'obiettivo è ripristinare una governance chiara e strutturata degli accessi, sostituendo la stratificazione disorganizzata di permessi che si accumula nel tempo.

Nella maggior parte dei casi questo si traduce nell'introduzione del paradigma Role Based Access Control (RBAC): invece di assegnare permessi utente per utente,  spesso copiando le abilitazioni di un "utente di riferimento", si definiscono figure professionali formali che rispecchiano i ruoli aziendali reali, e si assegnano agli utenti in base alla loro funzione.

Senza questo approccio, la situazione tipica è che nel corso degli anni nessuno sa più con precisione chi fa cosa nel sistema: ogni nuovo collaboratore eredita permessi dall'utente di riferimento, i ruoli si stratificano, e la gestione quotidiana delle abilitazioni diventa sempre più lenta, soggettiva e rischiosa. Questo vale per qualsiasi sistema SAP: da SAP ERP a S/4HANA e qualsiasi altro componente dell'ecosistema.

Perché avviare un progetto di SAP Authorization Review: le ragioni più comuni

Le motivazioni per avviare una revisione del modello autorizzativo SAP variano a seconda di chi sponsorizza il progetto: Internal Audit, CIO, CISO o CFO; e dei problemi specifici che l'organizzazione sta vivendo. Queste sono le situazioni più frequenti che incontriamo in consulenza:

• Perdita di controllo del sistema. I ruoli non sono più comprensibili, la creazione o modifica di un utente richiede uno sforzo sproporzionato, e la responsabilità del "chi fa cosa" è caduta interamente sull'IT senza una logica di business sottostante.
• Assenza di linguaggio comune tra business e IT. Chi gestisce i processi aziendali e chi amministra le abilitazioni parlano lingue diverse. Il risultato è un ciclo continuo di inefficienze nella gestione di ruoli e permessi.
• Richieste dei revisori di bilancio. I revisori esterni chiedono regole più precise sulle abilitazioni, l'introduzione di controlli di Segregation of Duties (SoD) verificabili e, in molti casi, l'adozione di sistemi di governo degli accessi come SAP GRC Access Control.
• Blocco nell'implementazione di un Identity Management. L'integrazione dei sistemi SAP in un progetto di Identity Management aziendale richiede un modello autorizzativo pulito e strutturato come prerequisito. Senza, il progetto si blocca.
• Gestione concentrata su una sola persona. Le autorizzazioni SAP sono gestite in modo soggettivo da un'unica risorsa. L'azienda vuole definire regole oggettive che permettano a più persone — interne ed esterne, in paesi diversi — di gestire il modello in modo standardizzato, ad esempio nell'ambito di un servizio AMS SAP Security.
• Incertezza sulla situazione di sicurezza complessiva. Si sa che la gestione dei ruoli non è l'unico aspetto della SAP security, ma non si ha una visione chiara di quali altri controlli mancano o siano insufficienti.

Spesso non si tratta di una singola ragione, ma di una combinazione cumulativa di queste situazioni. In ogni caso, un progetto gestito con gli obiettivi chiari può portare un ritorno concreto: riduzione dei tempi di gestione, maggiore controllo, e una base solida per le iniziative di compliance e sicurezza successive.

Chi coinvolgere in azienda e quando: l'errore da non commettere

Questo è l'aspetto più critico; e quello su cui si commettono più errori. Il presupposto sbagliato più comune è credere che la società di consulenza esterna possa fare tutto: analizzare il sistema, proporre un modello e consegnare le "chiavi" del nuovo assetto autorizzativo.

È un approccio che non funziona, per una ragione molto semplice: nessuna società esterna conosce i dettagli dei tuoi processi aziendali, e nessuna può decidere "chi fa cosa" al posto tuo. La consulenza può fornire metodo, strumenti e best practice, ma la definizione dei ruoli è e resta una responsabilità interna all'azienda.

Chi deve essere al tavolo

• I responsabili delle aree di business coinvolte. Devono conoscere i processi aziendali di competenza e, idealmente, le transazioni SAP utilizzate nel loro perimetro. Coinvolgerli direttamente; senza delegare questa fase alla consulenza, è molto più efficace e accelera significativamente il progetto.
• Il supporto IT di area. Negli incontri di definizione dei ruoli, avere una figura IT che conosce il sistema e può tradurre le esigenze funzionali in termini tecnici è un acceleratore importante.
• Lo sponsor del progetto. Che sia l'Internal Audit, il CIO, il CISO o il CFO, è fondamentale che gli obiettivi siano chiari fin dall'inizio e condivisi con tutti i partecipanti. Un progetto senza uno sponsor forte tende a rallentare o fermarsi alla prima resistenza organizzativa.

Prima di iniziare: tre cose da fare

1. Chiarisci gli obiettivi del progetto. È un progetto prevalentemente IT, oppure ha una dimensione business o HR? La risposta cambia il perimetro, i tempi e i partecipanti necessari.
2. Coinvolgi i responsabili di area in prima persona. Presentare il progetto direttamente — senza delegare alla consulenza questa fase — aumenta il senso di ownership e riduce le resistenze durante l'esecuzione.
3. Porta al tavolo persone che conoscono sia il processo sia il sistema. Incontri con persone che non conoscono SAP o non hanno chiari i processi di competenza allungano i tempi senza produrre valore.

Può essere gestita solo dall'IT?

Sì, ma a una condizione precisa: che il team IT abbia una conoscenza approfondita di tutti i processi aziendali coinvolti, sia a livello funzionale sia tecnico, e sappia con precisione cosa fanno le persone nel sistema. In questi contesti, un progetto guidato interamente dall'IT produce nel medio-lungo periodo gli stessi risultati di un coinvolgimento diretto del business.

Se questa condizione non è soddisfatta, il coinvolgimento dei responsabili di area non è un'opzione: è un prerequisito.

Quanto dura un progetto di SAP Authorization Review?

La durata dipende principalmente da due variabili: il numero di utenze coinvolte e la complessità organizzativa dell'azienda.

• Organizzazioni con ~100 utenze SAP: qualche mese, se il coinvolgimento dei referenti di business è garantito fin dall'inizio.
• Aziende con decine di migliaia di utenti, più geografie e processi complessi: da un anno a poco più, con fasi di rollout progressive per area o paese.

La componente che incide di più sulla durata non è quella tecnica, ma quella organizzativa: la disponibilità effettiva dei referenti di business a partecipare alla definizione dei ruoli e la chiarezza degli obiettivi fin dal via.

Vuoi capire come impostare correttamente il tuo progetto di Authorization Review?

Abbiamo affrontato progetti di SAP Authorization Review in contesti molto diversi: da società monoprodotto con poche centinaia di utenti a gruppi multinazionali con architetture SAP complesse. In ognuno di questi contesti, il fattore determinante per il successo non è stato lo strumento, ma il metodo e il coinvolgimento delle persone giuste al momento giusto.

Contattaci per scoprire come abbiamo affrontato situazioni simili alla tua e quali approcci potrebbero funzionare nel tuo contesto.