Quanti errori ricevi durante il go-live di un sistema SAP?

Ricevere tanti errori ha una connotazione negativa? Gestire parecchi errori o problemi (legati agli aspetti di sicurezza del sistema) durante un rilascio significa che qualcosa durante il progetto non ha funzionato?

E, invece, non riceverne affatto significa che tutto ha funzionato correttamente e possiamo stare tranquilli?

Errori SAP che si presentano dopo il rilascio

Esistono diverse casisitche di errore. Un aspetto importante è quello di poter classificare queste problematiche. 

Può essere rilevante farlo, non solo per finalità statistiche del rilascio stesso ma anche per impostare in maniera corretta un supporto continuativo (AMS SAP). Ecco qualche caso:

1. Mancanza di un ruolo ad un utente
2. Mancanza di una funzionalità (transazione o APP Fiori) in un ruolo e/o ad utente
3. Mancanza di una specifica abilitazione tecnica (autorizzazioni SAP)
4. Mancanza di una configurazione che innesca controlli autorizzativi. Infatti in diversi casi le autorizzazioni si attivano solo dopo aver effettuato determinate configurazioni applicative. Può capitare che queste non vengano portate o implementate nel sistema produttivo e quindi, pur avendo configurato tutto il sistema correttamente dal punto autorizzativo qualcosa non funzioni come dovrebbe

Sono alcuni degli esempi più comuni e classici, ma ne esistono diversi altri chiaramente.

Errori SAP, di chi è la colpa?

In generale è importante, prima di identificare il colpevole, trovare la causa del problema stesso, andando ad arginare una eventuale situazione di "problem" (come definito ad esempio dalla certificazione ISO20000) ovvero una molteplicità di richieste derivanti tutte dalla medesima causa.

In generale può essere che la mancanza di ruoli assegnati alle utenze sia da attribuire a chi decide chi fa cosa in azienda.

Una mancata funzionalità o una dimenticanza di questo tipo può essere fisiologica (anche se può avere ripercussioni su molte utenze). Questo caso potrebbe rientrare nella situazione di "problem" descritta sopra.

In generale quello che abbiamo visto nel corso del tempo come problema ricosivo è la mancanza dei test.

Infatti, l'unico modo per evitare che durante i rilasci ci siano problemi di natura autorizzativa (quindi legati agli aspetti applicativi) è effettuare i test.

La qualità dei test che viene effettuata dal team di progetto, quindi solitamente cliente e system integrator, determina la numerosità di richieste che si avranno durante il rilascio di un progetto.

Al momento infatti non esiste alcun modo per verificare che quanto fatto (senza fare prove) sia sufficiente. 

Purtroppo in svariate situazioni il tempo da dedicare a questa fase può essere rilevante e quindi si tente a sottovalutare questa fase (specialmente per gli aspetti relativi alla sicurezza applicativa). Spostando di fatto questo passaggio durante il rilascio effettivo della soluzione.

Esistono dei benchmark?

Non esistono benchmark ufficiali chiaramente, tuttavia, escludendo i casi ottimali e quelli peggiori, possiamo dire che generalmente una media di una decina di richieste (indipendentemente dalla tipologia) nei primi 15 - 20 giorni dal rilascio può essere una buona media. Ipotizzando un rilascio completo, non graduale ad esempio per i vari moduli o geografie.

Il benchmark può chiaramente cambiare andando a classificare in maniera più fine le richieste. Ovvero se per una determinata richiesta ad un utente manca una determinata abilitazione questa non si tratta di una problematica "tecnica".

Possiamo quindi pensare di indicare penali sulla numerosità delle richieste? Credo sarebbe interessante farlo. Ma non così semplice nell'attuazione. Proprio perché la classificazione, sotto questo punto di vista, dei problemi potrebbe non essere così semplice e cadere spesso nel proprio campo.

Cosa fare quindi?

1. Effettua o fai effettuare tutti i test possibili
2. I test autorizzativi devono essere svolti per ruolo professionale, non con utenti reali (che hanno la somma di più abilitazioni)
3. I test dovrebbero avere una duplice veste. Test positivi (riesco a fare quello che formalmente sono autorizzato a fare) e test negativi (verifico che non posso fare quello che non sono stato autorizzato a fare). Da un punto di vista di continuità del business solitamente sono privilegiati i test positivi, tuttavia anche quelli negativi hanno la loro rilevanza
4. Semplifica se puoi. Con più richiedi un modello autorizzativo complesso (con tante segregazioni) con più sarà costoso e difficile gestire il tutto. Sotto ogni fase del progetto