Sicuramente la collaborazione tra il Project Manager ed il team SAP Security deve essere un “must have” fin dal inizio del progetto.
Nella nostra realtà siamo diverse persone a seguire le tematiche di SAP Security, per un landscape di diverse decine di sistemi SAP e parecchie migliaia di utenti.
Come e perché il coinvolgimento del SAP Security team è importante?
Il team SAP Security conosce bene il modello autorizzativo implementato in azienda ed insieme al Project Manager può concordare la possibilità di modificare/utilizzare ruoli autorizzativi già esistenti oppure crearne di nuovi dedicati, durante i progetti.
Le esigenze del business ed i vincoli imposti dalla Segregation of Duties devono essere condivisi con il team di SAP Security per consentire un’analisi di dettaglio che potrebbe evidenziare eventuali problematiche non gestibili tramite lo standard SAP.
In questi casi deve essere valutata la possibilità di ricorrere alla personalizzazione del sistema ("custom SAP") che, tuttavia, può avere alcuni effetti negativi oltre a richiedere generalmente tempi di configurazione realizzazione maggiori.
Il team SAP Security, insieme al Project Manager è in grado di:
- Indicare ai programmatori la tipologia dei controlli autorizzativi necessari
- Valutare l'implementazione per garantire una corretta Segregation of Duties che potrebbe, se opportunamente collaudata e validata, essere aggiunta alla gestione standard aziendale dei profili autorizzativi
È sconsigliata la creazione di una nuova transazione custom senza avere almeno un controllo autorizzativo. Nella maggior parte dei casi si utilizzano degli oggetti autorizzativi standard, ma può capitare che particolari esigenze richiedano un oggetto autorizzativo custom. Per entrambi i casi il programmatore deve essere in contatto con il team SAP Security per valutare gli impatti della personalizzazione e concordare la soluzione ottimale nel rispetto delle regole SoD.
Nella fase di test, da non sottovalutare, il team SAP Security definisce le utenze di test per le varie figure professionali e modifica i profili autorizzativi aggiungendo le eventuali autorizzazioni mancanti per garantire lo svolgimento del ruolo e l’utilizzo delle funzionalità all'interno del processo.
Evita se puoi l’utilizzo di utenze da amministratore di sistema per testare le nuove funzionalità. Queste utenze hanno dei diritti particolari e non consentono un reale separazione dei compiti. Questo implica che il risultato dei test può essere falsato e non rappresentare una corretta esecuzione/simulazione delle funzionalità come un reale end-user.
Il valore aggiunto della collaborazione con il team SAP Security nei progetti (3 suggerimenti positivi)
Perché dovresti valutare un coinvolgimento maggiore già nelle prime fasi del progetto?
Partecipando a diversi progetti in azienda, dai più semplici a quelli molto complessi, ho avuto modo di vedere parecchie casistiche a riguardo.
Riassumo in questi tre punti le ragioni.
- Dare una visione del progetto che permette alle persone del team di SAP Security di gestire con la priorità corretta le richieste inerenti agli specifici processi. In questo modo viene anche garantito un rapido intervento qualora si presentino “blocchi autorizzativi” sia nella fase di implementazione che nel post Go-live
- Consente una maggior efficienza d’intervento per i progetti con estensione World Wide dove spesso può essere prevista/programmata una disponibilità d’intervento al di fuori dell'orario lavorativo standard
- È indubbio che un coinvolgimento puntuale delle risorse del team SAP Security genera delle competenze ulteriori e/o specifiche di processo. Queste, aggiunte alle competenze e alle esperienze sui vari progetti, consentono al team di agire in velocità e suggerire possibili soluzioni o alternative a supporto del Project Manager. Innesca un circolo virtuoso.
Cosa può succedere nel Go-Live se il team SAP Security non è stato coinvolto? (3 punti di attenzione da considerare)
Purtroppo può capitare. Penso sia utile tuttavia, se stai leggendo questa parte, metterti in guardia su cosa potrebbe accadere.
- Il caso più evidente è un dilatamento dei tempi di risoluzione dei “blocchi autorizzativi” non previsti o non individuati nella fase di collaudo
- Se le modifiche implementate contengono nuove transazioni standard o custom non precedentemente condivise con il team del SAP Security la risoluzione dei problemi si complica con effetti immediati sui tempi di risoluzione e in casi più critici sul business
- Un coinvolgimento del team SAP solo nell’ultima fase pre-Go-live, ad esempio per la sola creazione dell’utenza, può essere rischioso. Va ricordato che in alcuni casi la creazione dei ruoli autorizzativi può necessitare un tempo di analisi ed elaborazione elevato, e questo rappresenta un potenziale rischio di poter pregiudicare il Go-live. Senza una corretta pianificazione e coinvolgimento tra Project manager e il team SAP security non si può garantire la corretta gestione dei profili autorizzativi nel rispetto dei tempi di rilascio della soluzione.
Quando devi coinvolgere il team SAP Security?
Coinvolgi il team SAP security nei progetti già nelle fasi iniziali di progettazione, una volta definita l’architettura della nuova funzionalità.
Ecco la check-list di quando serve coinvolgere il team SAP Security.
- Creazione nuova transazione custom. È sconsigliata la creazione di una nuova transazione senza avere almeno un controllo autorizzativo altrimenti le logiche previste dalla Segregation of Duties potrebbero non essere ottemperate
- Creazione di nuovo livello organizzativo (nuova società, nuova divisione ecc). In questo caso serve concordare con il team SAP Security chi deve utilizzare il nuovo livello organizzativo per garantire che l'authorization concept definito sia coerente
- Creazione nuovo tipo documento (es.: ordini di vendita o richieste di acquisto ecc)
- Creazione nuovo flusso/modifica del flusso
- Creazione nuova figura professionale
- Modifica di una figura professionale esistente
