SAP Profile Management, quanto conta?

Posted by Massimo Manara on Oct 4, 2023 8:00:00 AM
Massimo Manara
Find me on:

È normale dover rivedere periodicamente il modello autorizzativo definito in azienda (in particolare in SAP)? Ogni quanto va fatto?

 

SAP Review

Perché serve e cosa serve?

Cosa è un modello autorizzativo SAP?

Iniziamo dal nome, infatti, esistono diversi termini/sinonimi:

  • SAP Authorization Concept
  • SAP Authorization Model
  • Modello autorizzativo SAP

 

In generale con questo termine ci si riferisce a tutte le scelte fatte per progettare e definire come saranno abilitati gli utenti (tutti, finali, utenze tecniche, esterni/interni etcc) a svolgere le loro mansioni. Dal punto di vista tecnico ma anche dal punto di vista funzionale.

 

Questo è maggiormente enfatizzato nel contesto S/4HANA specialmente nel caso dell'adozione dell'interfaccia Fiori.

 

Ma si applica anche ai sistemi Cloud. O più in generale si può adottare anche in sistemi non SAP all'interno dell'azienda. Uno degli aspetti fondamentali è la naming convention di un modello. Guarda qui il video dedicato all'argomento.

 

 

Ma un modello autorizzativo è per sempre?

Riprendendo un noto slogan commerciale, potremmo a mio avviso dire "ni". In altre parole, il modello può restare il medesimo per molti anni anche a fronte di eventi importanti, ad esempio, fusioni ed acquisizioni societarie o scorpori (merge and acquisition o carve-in o carve-out). 

 

Ma questo non significa che non subisca modifiche. Alcune di queste sono fisiologiche altre meno.

 

Sarebbe, forse, preoccupante se non ci fossero modifiche da fare nel corso del tempo. Quindi può essere assolutamente normale rivedere (o fare alcuni aggiustamenti) il modello. Ma forse può avere senso entrare un po' più in dettaglio, vediamo quali sono le situazioni fisiologiche:

  • modificare il contenuto o la composizione dei ruoli 
  • cambiare la naming, se limitata ad alcuni aspetti minori rispetto al totale 
  • cambiare alcuni aspetti legati all'attribuzione dei ruoli (ad esempio a valle dell'introduzione di nuove segregazioni, che magari richiedono raggruppamenti puntuali e diversi rispetto al passato)

 

Guarda questo video per capire in quali casistiche può avere senso ripensare o rivedere il modello.

 

 

Ecco alcuni esempi:

  • Quando la gestione delle richieste è particolarmente complessa e soggettiva
  • Quando non è possibile effettuare dei controlli automatici sul modello, per finalità appunto di controllo e governo del modello
  • Quando nessuno ne ha più il controllo, del modello autorizzativo
  • Quando sono definiti diversi concetti autorizzativi nel sistema, dovuti a progetti o diverse mani, non coordinate tra loro nella definizione
  • Quando il numero delle figure professionali template supera il 30% degli utenti definiti a sistema. Leggi qui le metriche di un modello autorizzativo: SAP Role and User Administration: quali sono le metriche?
  • Quando il sistema definito inizialmente e profondamente cambiato così come le eventuali normative alle quali essere conformi

 

Ma quale modello autorizzativo è il migliore?

 

Non c'è sempre un unico vincitore in questi casi, tuttavia, la nostra esperienza ci ha portato a capire quali sono i modelli che funzionano meglio. Che non sono i migliori in tutti casi, ma quelli che si adattano meglio all'evoluzione dell'azienda. Su diverse prospettive, non solo quelle legate all'operation ma anche alla governance e compliance.

 

Mi capita in alcuni casi di sentire "ma così facendo serve più tempo per definire e mantenere il modello" è vero in alcuni casi l'investimento iniziale è maggiore rispetto ad altri. Ma credo che il guadagno reale non sia nel tempo impiegato nel momento della definizione/costruzione del modello. Ma sia nella sua governance e manutenzione.

 

Attenzione. Nel caso della manutenzione non sempre c'è un vincitore unico. Ti faccio un esempio molto estremo ma allo stesso tempo pratico.

 

Immagina di essere una società dove non ci sia alcun vincolo legato alla separazione dei compiti aziendale. Ed in questo momento ci siamo 400-500 utenti in SAP definiti. Quindi una società relativamente piccola. Posso definire dei ruoli per utente o per ufficio.

 

Sicuramente è una strada tecnicamente lecita e possibile.

 

Ma cosa succede nel momento in cui:

  • viene acquisita una società di 1000 o 2000 utenti SAP, che si aggiungono ai precedenti
  • la società decide di ristrutturare l'organizzazione definendo diverse ulteriori società oltre a quella principale per gestire diverse linee di business (con nuove divisioni, organizzazioni etcc)
  • devo gestire delle logiche di separazione dei compiti
  • devo introdurre delle logiche di gestione delle identità aziendali
  • non sono più io la persona che ha "ideato" il modello a metterci mano, ma altri colleghi o personale esterno (magari da diversi paesi). Più persone che ci mettono mano con modi e mentalità/sensibilità diverse dalla mia
  • devo iniziare a controllare gli aspetti di cyber security anche in SAP così come sono soggetto a revisioni interne o esterne alle quali devo rispondere

 

Nei casi sopra è probabile che il modello definito deragli o comunque comporti una manutenzione così elevata da portare la perdita del controllo o costi di gestione molto elevati.

 

Di conseguenza un risparmio di tempi iniziale si è rivelato poi un dispendio di energie notevole a seguito (nel gestire o rivedere tutto quanto).

 

Hai dei dubbi su come impostare un modello autorizzativo o vuoi capire in quale situazione ti trovi? Contattaci!

 

Sì, desidero contattarvi!

 

 

Topics: pfcg, authorization concept

Voglio iscrivermi!

Blog Aglea, cosa puoi trovare?

Ogni mercoledì pubblichiamo articoli, interviste e documenti relativi alla security SAP.

Cosa puoi trovare:

  • Suggerimenti su come mettere in sicurezza i sistemi SAP
  • Come fare a … (How To)
  • Checklist
  • Gli errori comuni che spesso vengono fatti in ambito Security SAP
  • Interviste con esperti del settore
  • Chi è AGLEA quale è la nostra vision security SAP

Post recenti

Post By Topic

Visualizza tutti