Perché può essere importante farlo e come?

Quali sono i punti di attenzioni e le sviste più comuni?

Serve fare dei test sulle autorizzazioni SAP?

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.

Di chi è la colpa se le autorizzazioni non funzionano?

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:

1. Creo un ruolo
2. Inserisco la transazione
   • Qui potrebbe esserci la gestione del catalogo/spazio Fiori
3. Genero il profilo (profilo e ruolo SAP non sono la stessa cosa)
4. Attribuisco il ruolo all'utente

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é?

• Manca qualche autorizzazioni
• Manca qualche "pulsante" link nel SAP Fiori Launchpad
• Manca qualche servizio
• etcc..

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:

1. Se inserisci questa transazione questi XY sono gli oggetti autorizzativi che servono per farla funzionare
2. Se inserisci questa transazione questi ZJ sono gli oggetti autorizzativi che di default (non saranno proposti) -> oggetti "dormienti"

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).

Ma il cliente che ruolo ha in questo caso?

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. 

Ecco qui alcuni suggerimenti per evitare mal di pancia in questa fase delicata

1. Evitare di creare dei ruoli ampi su cui far "testare". Questo può essere spesso causa di confusione durante poi le "vere" fasi di test (UAT User Acceptance test)
   • Un conto è poter vedere il sistema, un conto è svolgere la fase di test
   • Il rischio qui è quello di assumere che tutto sia importato correttamente (magari anche come layout Fiori) e poi scoprire molte mancanze a seguito dell'effettivo test (o peggio rilascio in produzione)
2. Definire delle utenze di prova. Questo può essere in realtà realizzato in diversi modi
   • Utenze reali con ruoli reali assegnate
   • Utenze generiche per ruolo
     Il secondo caso è sempre da preferire. Se ho due utenti che hanno a parità di funzione ruoli diversi, il test svolto da uno di questi potrebbe non valere per l'altro. Se invece testo il singolo ruolo sono sicuro che anche in somma o riduzione (rispetto ad altri) funzionerà correttamente
3. Altre modalità esistono es. per processo. In questo caso serve valutare uno specifico effort per realizzarlo
4. Servono script per fare dei test? Se ci sono è utile, altrimenti anche la sola esecuzione delle funzioni principalmente usate può già essere utile per intercettare la maggior parte dei casi di possibili mancanze. Nell'ottica di "Ottieni molto con poco".
   • Ricorda che potrebbe essere importante fare test positivi e negativi
5. Valuta se stai creando ex-novo il tutto oppure se stai facendo una migrazione o revisione, in questo ultimo caso esistono anche strumenti per aiutare (statistiche, trace, log)

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.