Per quale motivo le decisioni a fronte delle richieste di abilitazioni spesso ricadono sull’IT?

Perché deve essere l’IT ad identificare quale ruolo attribuire?

Il business dovrebbe formulare le richieste affinché l’IT sia in grado di processarle senza reiterazioni, oppure mettere a disposizione uno strumento che permetta il provisioning automatico delle abilitazioni, magari a seguito di un workflow approvativo. 

Quanto appena descritto, però, spesso non avviene per svariati motivi, vediamo quali sono!

• Il business, nella maggior parte dei casi, non conosce i ruoli tecnici richiesti per svolgere una certa funzione nei sistemi.
  • Un classico esempio potrebbe essere la necessità di autorizzare un collega del reparto acquisiti alla creazione delle richieste di acquisto. Il manager di turno sa, ovviamente, cosa dovrà fare il collega, ma non sa quale ruolo tecnico del sistema permette di svolgere quell’azione. Ne consegue un coinvolgimento dell’IT per tradurre la richiesta in formato “tecnico”. Tutto ciò comporta un enorme perdita di tempo, soprattutto se moltiplicata per tutte le utenze che effettuano delle richieste di abilitazioni e si trovano nella medesima situazione.
• I ruoli sono degli oggetti sconosciuti e troppo tecnici. Purtroppo, come già detto, non è sufficiente esporre la lista dei ruoli ai vari reparti di business affinché questi siano in grado di tradurre le etichette tecniche in funzionali.
• In azienda i ruoli sono argomento prettamente IT. Soprattutto nelle piccole realtà, tutto viene delegato al dipartimento IT creando delle degenerazioni di responsabilità.

Ma di chi sono i dati nel sistema gestionale? Dell’IT oppure del business?

Quali sono gli owner?

Diciamo subito che non è semplicemente assegnando una etichetta a qualcuno che le problematiche sopra indicate spariranno magicamente. È necessario svolgere un insieme di azioni affinché funzioni nel tempo ed i processi siano più fluidi.

Quali potrebbero essere quindi i concetti di owner da adottare?

• Business area owner, è il responsabile degli utenti di una area aziendale. Ogni utente deve essere infatti assegnato ad un business area owner (Manager).
• Business process owner
  • Definisce come sono costruiti i processi aziendali e da quali attività sono formati.
• Data owner
  • È il responsabile della parte più importante dei processi: i dati. Riveste un ruolo particolarmente importante sulla accountability dei dati.
• Role owner, in questo caso è possibile definire due diverse figure
• Role owner content, ovvero è responsabile del contenuto tecnico dei ruoli. Quali sono le abilitazioni e quindi transazioni SAP che un certo ruolo contiene e quali ulteriori restrizioni devono avere? Role Owner assignment, ovvero chi deve decidere quali utenti devono o meno essere assegnati a quel ruolo.
• SoD rule owner, è la persona incaricata di modificare fisicamente le regole di Segregation of Duties
• SoD risk owner, è responsabile della definizione dei rischi. Contenuto e livello di rischio. In azienda possono essere diversi i risk owner presenti.
• SoD mitigation control owner and tester, è responsabile della progettazione del controllo mitigativo. Il control tester è colui che materialmente effettuerà il controllo.

Come può essere di aiuto il ruolo degli owner?

Nella gestione delle autorizzazioni, ipotizzando di avere un modello di ruoli basato su figure professionali, l’identificazione del role owner (nelle due casistiche possibili) può facilitare:

• La modifica dei ruoli. Il business conosce come sono costruiti i ruoli e cosa dovrebbero contenere. Le richieste verso l’IT sono quindi molto precise.
• L’attribuzione degli utenti. Il business è consapevole di quali utenti devono o meno essere assegnati ai vari ruoli organizzativi aziendali. Anche in questo caso di conseguenza le richieste al supporto sono molto precise e richiedono poche o nulle iterazioni per essere evase.

Lo scenario descritto può essere realizzato tramite iterazioni via mail, o meglio, tramite l’utilizzo di workflow approvativi.

Lo strumento che SAP mette a disposizione per la gestione del ciclo di vita delle utenze e dei ruoli si chiama SAP Governance Risk and Compliance Access Control, in particolare, il modulo Access Request Management (ARQ) e Business Role Management (BRM).

Il modulo ARQ permette, appunto, di definire dei workflow approvativi che governano il ciclo di vita delle utenze in particolare durante le nuove assunzioni, cambi di mansione e cessazione utenze.

Il modulo BRM, invece, permette di definire delle metodologie che devono essere seguite da chi costruisce i ruoli aziendali durante la definizione delle abilitazioni.

Queste metodologie possono contenere degli step approvativi che guidano formalizzano i vari passaggi del ciclo di vita dei ruoli autorizzativi aziendali.

In entrambi gli strumenti viene richiesta una formalizzazione degli owner affinché sia possibile configurare ed utilizzare le funzionalità disponibili.

Non è necessario avere lo strumento SAP GRC Access Control per attivare dei processi di gestione del ciclo di vita delle utenze e dei ruoli, anche se sicuramente è utile.

Definire all’interno della propria realtà degli owner ed utilizzare strumenti già presenti è sicuramente un ottimo passo per facilitare poi l’adozione di strumenti come il GRC Access Control.

Hai ancora dubbi su come definire gli owner? Raccontaci le tue esigenze, abbiamo affrontato parecchi progetti di questo tipo.