Nel corso degli anni abbiamo affrontato centinaia di progetti di questo tipo. Per società con qualche centinaio di utenti fino a società con decine di migliaia di utenze.

Ovvero la revisione completa del modello autorizzativo SAP, per tutte le utenze coinvolte nel sistema o sistemi.

Ma in alcuni casi era chiaro chi coinvolgere, in altri no. Quindi se hai intenzione di far partire delle iniziative di questo tipo meglio sapere prima chi servirà.

SAP Authorization Review cosa è?

Si tratta di una iniziativa progettuale che va a rivedere il modello autorizzativo definito a sistema in questo momento.

Nel contesto di SAP questo si traduce nella maggior parte dei casi nell'introduzione del paradigma Role Based Access Control (RBAC) e quindi nell'introduzione di figure professionali aziendali che saranno poi assegnate alle utenze.

Infatti, non è così scontato che quando arrivi in azienda un nuovo collaboratore si sappia esattamente cosa dovrà fare, anzi spesso si chiede un utente di riferimento come esempio (pratica non necessariamente sbagliata), senza ragionare sulla figura che dovrà ricoprire.

Questo può portare alla stratificazione dei permessi o abilitazioni assegnate alle utenze e nel corso degli anni far perdere il controllo del "chi fa cosa" in azienda.

Perché dovrei fare un progetto di questo tipo?

Sono molteplici i motivi di questa scelta. E dipendono anche dallo sponsor di questa iniziativa ad esempio (non ordinati per importanza e solo qualche esempio):

• Interna Audit
  
  
• Dipartimento dei sistemi informativi (CIO - Chief Information Officer)
  
  
• Sicurezza aziendale (CISO - Chief Information Security Officer)
  
  
• Dipartimento amministrazione finanza e controllo (CFO - Chief Financial Officer)

Non necessariamente tutti gli attori sopra coinvolti hanno lo stesso scopo.

C'è chi privilegerà gli aspetti di IT operation, ovvero di semplificazione del modello per risparmiare tempo nei momenti di gestione quotidiana del modello autorizzativo.

C'è chi privilegerà gli aspetti di controllo del modello autorizzativo, chi avrà un focus più sulla sicurezza del sistema e chi infine vedrà questi aspetti, spesso, come un obbligo dovuto a regolamenti normativi per finalità di approvazione di bilancio. 

Più in generale potremmo effettuare un sommario delle principali ragioni nel modo seguente.

• Abbiamo perso il controllo del sistema. Non sappiamo più come sono organizzati i ruoli. Ogni volta che dobbiamo creare o modificare un utente facciamo una fatica estrema a capire cosa quella persona deve o dovrebbe fare. Spesso la scelta del chi fare cosa ricade prettamente sull'IT
  
  
• Non c'è un linguaggio comune tra chi è nell'area operativa di business e chi gestisce le abilitazioni (IT) questo comporta che anziché fare sinergia avendo una lingua comune, non ci si capisca, generando inefficienze a cascata sull'aspetto di gestione ruoli ed abilitazioni
  
  
• I revisori di bilancio chiedono regole più precise sulla gestione delle abilitazioni e l'introduzione di verifiche di separazione dei compiti aziendali (Segregation Of Duties) o sull'introduzione di sistemi di governo degli accessi (ad esempio SAP GRC Access Control)
  
  
• Vogliamo introdurre un sistema di Identity Management aziendale ma siamo arrivati all'integrazione dei sistemi SAP e ci siamo bloccati
  
  
• Sappiamo che la gestione dei ruoli profili in SAP non è l'unico aspetto della security SAP ma non siamo sicuri sia tutto come dovrebbe
  
  
• Ad oggi la gestione delle autorizzazioni SAP è "in mano" ad una sola persona che gestisce in maniera soggettiva tutto quanto. Vorremmo definire un gruppo (non necessariamente dello stesso paese) che possa mettere mano alla gestione dei ruoli. Quindi avere un modello con regole oggettive che permetta di essere gestito da persone diverse, in paesi diversi o da risorse interne così come risorse esterne. Ovvero standardizzare i progetti di gestione applicativa dei ruoli (AMS SAP Security)

Ognuno degli aspetti sopra può essere visto come una prospettiva a sé. Non necessariamente la ragione può essere una di quelle elencate sopra, ma spesso sono richieste "cumulative". Chiaramente quanto sopra vale per i sistemi ERP, ad esempio, S/4HANA o per qualsiasi altro sistema SAP.

In ogni caso se questa iniziativa viene gestita con lo scopo previsto, può portare un ritorno (anche di riduzione dei costi e tempi di gestione di questi aspetti).

Ma chi devo coinvolgere in azienda e quando?

Questo è uno degli aspetti fondamentali. Se pensi che arrivi la società di consulenza e dopo settimane o mesi di studi/analisi ti consegni le chiavi per avviare il nuovo sistema, stai commettendo un pericoloso errore.

1. Credi davvero che una società esterna conosca i dettagli dei tuoi processi?
   
   
2. Credi davvero che una società esterna possa decidere "chi fa cosa" nella tua azienda?
   
   
3. Credi davvero che, soprattutto nei sistemi SAP, sia un processo prettamente tecnico la revisione del modello autorizzativo? 

Ecco se hai risposto sì ad almeno una delle domande sopra, conviene che prosegui nella lettura.

• Assicurati che siano chiari gli obiettivi del progetto (è un progetto prettamente IT? Giusta o sbagliata la scelta. Oppure è un progetto business or HR?)
  
  
• Coinvolgi i responsabili delle aree coinvolte e descrivi loro gli obiettivi. So che a volte il consulente o società di turno (non ho ancora capito la ragione in questi casi) è visto come "persona più importante" rispetto agli interni (che magari lavorano da anni in azienda). Ma se questa fase viene fatta da te direttamente è molto più efficace a mio avviso
  
  
• Per non perdere tempo agli incontri (e non far perdere tempo alle persone coinvolte) serve avere al tavolo persone che conoscano il processo aziendale e conoscano il sistema SAP, se possibile avendo chiare le transazioni che sono usate nei rispettivi processi di competenza. Il supporto IT di area in questi momenti può essere di aiuto

Ricordati che la società di turno può dare sicuramente dei suggerimenti e delle proposte. Ma la definizione del "chi fa cosa" in azienda è solo dell'azienda stessa.

Può essere un progetto di questo tipo governato solo dall'IT. Sì ma a patto che l'IT sia forte. Che cosa intendo. Che l'IT deve conoscere tutti i processi coinvolti a livello funzionale e tecnico oltre a sapere cosa di fatto fanno le persone. Ci è capitato di farlo in alcuni contesti e nel medio lungo periodo ha portato i medesimi vantaggi di averlo fatto con il business direttamente. Contattaci per scoprire ulteriori dettagli!

Quanto durerà un progetto di questo tipo?

Questo chiaramente dipende dai volumi. Stiamo parlando di una società di 100 utenze SAP oppure di una società con decine di migliaia di utenti sparsi per diverse geografie e con molta complessità nelle proprie strutture?

Ovviamente sono due scenari diversi. E quindi è plausibile passare da qualche mese ad un anno o poco più di progetto.