È molto frequente per società multinazionali oppure gruppi industriali con molte società, a seguito dell'installazione di SAP, effettuare dei rilasci graduali.

In altre parole, inglobare o replicare quanto fatto dalla casa madre, anche nelle filiali estere o altre società del gruppo. Ma quali sono le trappole di questo processo molto comune? E come evitarle?

1) Programmi custom con authority check

Questo è da sempre una nota dolente in tutti i progetti. Non c'è il tempo, non era stato pensato inizialmente, programmi obsoleti che nessuno più conosce.

Alla fine, il risultato di questo processo è che programmi che svolgono azioni critiche a sistema (non necessariamente ad impatto di segregation of duties) non contengano gli oggetti autorizzativi necessari al controllo delle loro funzionalità.

Spesso ci si accorge di questa mancanza quando si va proprio su altre società o all'estero. In quel momento la transazione o programma che viene rilasciato agli utenti delle filiali, non avendo controlli autorizzativi, si rivela problematico.

Quanto costa sistemare queste occorrenze quando è tutto live? Meglio farlo prima!

2) Descrizione dei ruoli

Viene sempre trascurato anche questo aspetto. Le descrizioni dei ruoli sono language dependent.

Significa che se crei i ruoli in lingua italiana, se un tuo collega inglese si collegherà in lingua inglese, non vedrà le descrizioni che hai creato tu in italiano.

Definisci prima di partire, se possibile, il tuo master language e fai in modo che tutte le descrizioni dei ruoli siano in quella lingua. Evita quindi di:

• Evita di usare impropriamente le descrizioni. Es. ruolo in lingua inglese ma con descrizione in italiano
• Evita se puoi le traduzioni. Richiedono molto impegno per essere mantenute, potenzialmente in tutte le lingue
• Se installi delle nuove lingue nel sistema ricordati di eseguire il programma (PRGN_CORRMEN2)

3) Modello autorizzativo comune

Definisci un unico modello autorizzativo (anche su sistemi SAP diversi, dove possibile) che poi sarà declinato nelle società o filiali. Chiaramente dovrà essere adattato (vedi anche punto 8 seguente)

4) Single Sign On

Ancora la password da gestire? Il 40% delle richieste che arrivano durante il supporto help desk  (SAP AMS) sono relative a problemi di accesso. Utilizza un meccanismo unico di autenticazione, centralizzato.

5) Molteplici transazioni per lo stesso processo

Questo punto leggermente diverso dal primo. In alcune situazioni invece di creare una transazione con un oggetto autorizzativo, per la segregazione delle società o del dominio dati, sono create n transazioni per ogni paese. Questo ha diversi svantaggi.

• Più programmi e/o transazioni da gestire
• Non viene definito un oggetto autorizzativo, standard o custom, per gestire la segregazione
• A parità di funzione aziendale, costringe ad usare ruoli tecnicamente diversi. Ad esempio, immagina di avere il ruolo per la gestione dei "periodi contabili SAP" in questo caso la transazione per la gestione di questo processo è una sola (potrebbero essere diverse per SAP, ma concettualmente è la stessa). In questo caso verrebbe gestita in un unico ruolo declinato per società. Creando transazioni diverse andrebbero definiti molteplici ruoli ad hoc per paese o società
• Si parte da un caso come questo e ci si allarga. "Lo abbiamo già fatto in questa situazione, facciamolo di nuovo"

6) Gestione locale IT

Non escluderlo a priori, soprattutto se lavori con fusi orari molto diversi dal tuo e devi garantire una copertura che va oltre le ore lavorative.

Per fare in modo che i colleghi siano allineati e non commettano "errori" il modello autorizzativo deve essere un orologio svizzero. Non devono esserci modi per sbagliare o decisioni soggettive libere.

7) Gestione della SOD locale

Fai in modo che i processi legati alla SoD (Segregation Of Duties) abbiano dei referenti di business ed IT locali. Questo può agevolare la gestione di questo processo.

8) Job role specifici o modello kernel?

Nel caso in cui ci siano delle filiali molto piccole, non sempre è possibile riutilizzare le figure professionali definite per headquarter. Ma quali le soluzioni principali allora?

• Definire dei delle figure professionali ad hoc per la filiale/paese
• Utilizzare un modello Kernel più add-on role

Anche se meno semplice da gestire all'inizio, bisogna familiarizzare un po', a mio avviso il secondo modo è quello migliore.

E tu cosa ne pensi? Anche a te è capitato qualcosa di simile sopra? Altri suggerimenti o punti di attenzione?