Perché può essere importante farlo e come?
Quali sono i punti di attenzioni e le sviste più comuni?
Ma per quale motivo dovrei testare le autorizzazioni SAP? Per chi è all'inizio del percorso di adozione di un sistema SAP può essere una domanda lecita.
Ovvero, se vado a definire le abilitazioni per gli utenti mi aspetto che rilasciando una certa funzionalità (transazioni o applicazioni SAP), chi la riceva sia in grado di utilizzarla in modo completo.
Non è sempre così, purtroppo. Ma proviamo a capire assieme perché e per quale motivo una scelta di svolgere i test in un determinato modo o un altro può determinare il successo o fallimento di questa fase.
Si è sempre portati a trovare un "colpevole" durante le attività progettuali. Tuttavia è importante identificare le cause più e comprenderne le motivazioni, per anticipare o mitigare problemi.
Proviamo assieme a fare un esempio. Devo abilitare una applicazione (Fiori) oppure una transazione SAP ad un utente. I passaggi per svolgere questa operazione (semplificando) sono i seguenti:
Tutto molto semplice. Il risultato atteso è che l'utente dopo aver ricevuto il ruolo possa usare tutte le funzionalità che sono state autorizzate.
Purtroppo non è sempre così, perché?
Ma allora qualcuno ha lavorato male? Chi ha fatto i ruoli? Chi ha indicato le applicazioni/transazioni SAP da aggiungere? Si tratta di un errore SAP?
Dove sta il problema?
La risposta in realtà potrebbe essere una somma dei punti procedenti o uno di questi. Proviamo a capire assieme.
In generale una transazione oppure applicazione SAP contiene una media di diverse decine di controlli autorizzativi. Questi controlli (che sono presenti nel linguaggio di programmazione) si possono attivare a seconda delle configurazioni applicative che sono state svolte dal cliente o dal system integrator di turno.
La SAP quindi propone (nel caso dei controlli nel contesto S/4HANA ad esempio) una coppia di tabelle chiamate USOBT_C e USOBX_C l'elenco di tutti i potenziali controlli presenti nei servizi (delle applicazioni Fiori) o nelle transazioni.
Semplificando, esistono due tipologie di stati in queste tabelle:
Ecco quindi che abbiamo un primo caso di spiegazione. La SAP rilascia una configurazione (proposta di oggetti autorizzativi legati ad APP/Transazioni) che potremmo definire "pronta" all'80%.
Ad esempio se nel progetto attivo il modulo della Profitability Analysis CO-PA, questi oggetti autorizzativi potrebbero non essere attivi da subito (ma sta al cliente attivarli, la SAP li ha in qualche modo già classificati, ma non sono attivi per default su tutti i clienti) vanno attivati durante l'implementazione.
Ma allora non può farlo chi gestisce le autorizzazioni oppure il system integrator stesso?
Ecco, è molto complesso a priori sapere quali oggetti/valori attivare (sono migliaia, ormai gli oggetti autorizzativi definiti) moltiplicati per i possibili valori e transazioni/app sono esponenziali le possibili combinazioni. Ecco quindi che allora, conviene provare e vedere se manca qualcosa per poi fare integrazioni. Costa molto meno.
Ma allora conviene anche integrare il tutto senza farsi troppi problemi? Potrebbe essere certamente una strada (anche assegnare SAP_ALL risolverebbe molti problemi) ma non è detto sia quella adeguata. Anche, ad esempio, in relazione al modello di licensing basato sul Full Use Equivalent (FUE) che viene basato, semplificando su "quanti oggetti autorizzativi hai e di che tipo". Oppure ad altri vincoli ad esempio quello legato alla separazione dei compiti (o molti altri scenari).
Chiaramente possono esserci anche errori di chi crea i ruoli o mancanze di chi fornisce quali abilitazioni andare ad aggiungere.
Ma in un progetto è normale e fisiologico (almeno fino ad un certo punto) che ci siano questi casi (nello stream progettuale legato alle autorizzazioni SAP).
Oltre al dover testare, spesso questa fase può essere anticipata da una passaggio di "unit test" eseguito dal team funzionale (specifico sugli aspetti autorizzativi).
Il decidere chi fa cosa è solo del cliente. Il system integrator di turno può supportare, suggerire, ma non decidere in generale.
Quindi se propongo di assegnare un ruolo delle vendite ad un utente, e quest'ultimo dovrà svolgere anche le scritture contabili. In questo caso l'errore sarà di mancata attribuzione di un ruolo (non un errore "tecnico").
L'assegnazione di un ruolo potrebbe essere anche non essere corretta non dal punto di vista del contenuto in sé come sopra, ma anche della declinazione. Es. il tuo ruolo è quello delle vendite ma non solo per l'Italia, ma anche per la Francia. In questo caso quindi il tutto funziona come previsto ma c'è stata una mancanza di attribuzione di un ruolo declinato per le esigenze organizzative richieste.
Non sottovalutare quindi questo aspetto che spesso viene ridotto per esigenze di budget o gare. Per esperienza tutto il costo che si può immaginare risparmiato viene poi impiegato (con gli interessi) anche in questa fase.