Ma cosa significa? Hai un modello uniforme di gestione della security SAP oppure ad ogni progetto bisogna inventarsi tutto. Sperando che poi sia almeno simile a quanto già fatto, magari da altri in passato?

Scopriamo in questo articolo se la gestione della Security SAP centralizzata è meglio o peggio. Il direttore d'orchestra è uno o molti?

La security SAP in azienda

La mia idea è che in azienda ci sia un team dedicato che si occupi di security SAP. Il team chiaramente dipende dalle dimensioni dell'azienda.

Può essere composto da una sola persona che si occupa in parte di gestire le autorizzazioni SAP e/o più in generale la security oltre ad altre attività oppure un vero e proprio team di risorse specifiche.

Trovo che sia indispensabile la presenza in azienda di persone formate sull'argomento. Certo non mi aspetto di trovare dei guru della materia in ogni realtà. Ma almeno conosce le logiche.

Delegare qualsiasi cosa all'esterno (anche la governance) a mio avviso è impensabile e rischioso. Mentre può essere corretto esternalizzare la manutenzione del sistema ovvero avere un servizio di AMS SAP Security.

Se il fornitore di turno mi propone qualcosa, voglio capire bene di cosa si tratta nel breve e soprattutto nel lungo periodo. Avrò delle conseguenze dalla scelta fatta nel futuro? Mi sta proponendo qualcosa che risolve una certa problematica ma potrebbe causare difficoltà in futuro.

Come è possibile capire o essere critici (in maniera costruttiva) se non si conosce di che cosa stiamo parlando?

Così come non trovo corretto che la security venga delegata ai vari funzionali di modulo. Ad esempio, i ruoli dell'area acquisiti e magazzino vengono gestiti da chi si occupa, nell'IT, del modulo SAP MM (Material Management) in azienda.

Perché non trovo che sia corretto:

• Il delegare all'esterno completamente tutto, anche il governo del modello, può far perdere all'azienda il know-how sull'argomento (ma come prepararsi per un AMS?)
• Anche dal punto di vista del fornitore questo è un problema. Mi trovo in alcuni casi a dover spiegare dei concetti banali, per svolgere qualsiasi cosa, in quanto nell'azienda si è perso qualsiasi tipo di conoscenza. Questo rende tutto estremamente complesso e lungo da attuare. Anche cose che in altre realtà sarebbero quasi scontate.
• Gli applicativi IT di modulo devono gestire i processi di competenza e concentrarsi sul loro mestiere. Non si possono occupare anche di Security SAP. Certo sono un ottimo aiuto e devono esserci a supporto della security ma non sostituirsi ad essa. Perché?
  Ecco qualche esempio:
• Non è il loro mestiere, non possiamo chiedere che tutti gli applicativi conoscano l'uso del profile generato (transazione PFCG) in ogni aspetto. Certo, chiunque potrebbe usarla. Ma il come gestire un modello che funzioni o meno non è proprio da tutti
• Si possono generare dei conflitti. Cosa intendo? Immagina che la persona IT dell'area finance (FI) crei dei ruoli della sua area. In questi ruoli specifici, dell'area FI, possono essere contenuti oggetti anche di altri moduli, MM, SD, WM etc.. SAP è un sistema integrato. Cosa ti aspetti che faccia? Che si confronti con ogni referente/collega di modulo per capire come gestirli? Quello che accade è che un oggetto autorizzativo sensibile dell'area MM presente nei ruoli FI sarà valorizzato magari con * (asterisco) vanificando altre segregazioni fatte nei ruoli di MM se assegnato allo stesso utente. In SAP le autorizzazioni si sommano.
• L'esempio di prima può portare alla generazione di oggetti autorizzativi custom per evitare situazioni di conflitto, soprattutto se il modello sopra è attivo da molto tempo.
• Ogni applicativo ragiona a modo suo. C'è da creare una transazione? Che naming scegliamo? Potrebbe essere diversa per area. Così come la tipologia stessa di transazione. Sono infatti diversi i modi di realizzare una transazione che richiama un programma o una query

SAP Security per progetti

In azienda si ragiona spesso per progetti, sulle nuove attività da portare avanti. Ma è corretto farlo anche per la gestione della Security SAP? Non credo.

Ma cosa intendo dire?

Durante il progetto di installazione e configurazione del SAP in azienda (anche quello era un progetto, più o meno vicino o lontano nel tempo) si è definito un concetto autorizzativo.

Non entriamo ora a capire se valido o meno. A seguito nascono nuovi progetti:

• Gestione del magazzino automatico
• Attivazione del modulo CO-PA
• Attivazione della tesoreria
• Introduzione delle logiche di RPA
• Aggiornamento del sistema a SAP S/4HANA
• etc..

Queste attività sono spesso seguite da personale interno ma anche da fornitori ai quali (quando ci si ricorda di farlo) si assegna anche la gestione delle autorizzazioni, per quel specifico progetto.

Ecco mi riferisco proprio a quel momento.

Qui, se non esiste un modello comune e condiviso (soprattutto con il fornitore), si rischia di andare a creare n modelli autorizzativi all'interno del sistema. Uno per ogni progetto.

Cosa mi capita di sentire a volte. Si i ruoli che si chiamano ZTR* sono quelli creati durante il progetto per la tesoreria. I ruoli che iniziano con ZCOMP* dove COMP è il nome della società sono quelli realizzati all'inizio del progetto. E così via.

È un modo che funziona? No a mio avviso.

Deve esserci un solo direttore d'orchestra per la Security SAP. Indipendentemente dai progetti che vengono svolti dall'azienda.