Nei progetti di implementazione SAP la gestione di ruoli e autorizzazioni è una delle parti più complesse, e quasi sempre quella che emerge tardi. Le scelte di impianto e i criteri per impostarla sono raccolte nel report scaricabile «Migrare a S/4 HANA senza impatti sul business».
Perché i ruoli poco chiari fermano un progetto
Un’attività senza un responsabile dichiarato non si blocca subito. Rallenta. Passa fra due persone che la considerano dell’altro, arriva al test senza approvazione e torna indietro quando il progetto ha già consumato il margine. In un progetto SAP il problema si presenta due volte, sulle attività di progetto e sulle autorizzazioni a sistema.
Che cos’è la matrice RACI?
| Lettera | Chi è | Che cosa fa nel progetto |
|---|---|---|
| R — responsible | La persona che esegue il lavoro. | Configura, scrive, prova. Può essere più d’una su attività ampie. |
| A — accountable | Chi supervisiona e approva il lavoro svolto. | Risponde del risultato. Su ogni riga ne esiste una sola, ed è il vincolo che rende utile la matrice. |
| C — consulted | Chi viene consultato sulle questioni specifiche. | Un referente interno o un consulente esterno, interpellato prima della decisione. |
| I — informed | Chi non partecipa ma deve sapere. | Tipicamente gli stakeholder, informati sull’avanzamento senza essere coinvolti. |
Come si costruisce la matrice in un progetto SAP?
Sulla parte sinistra della matrice si elencano tutti i processi e le attività implementati sul gestionale, insieme al team di progetto. L’elenco non è teorico: esce dalle attività reali del piano, perché una matrice costruita sulle macro-fasi non aiuta nessuno.
Poi si determinano le persone o le posizioni richieste, comprese quelle che useranno le app Fiori assegnate per ruolo. È il passaggio in cui serve l’interazione con le risorse umane dell’azienda, perché alcune responsabilità non coincidono con l’organigramma: chi approva una modifica al ciclo attivo non è sempre chi ha il ruolo più alto nell’area.
Che rapporto c’è fra RACI e autorizzazioni a sistema?
Sono due piani diversi che vanno tenuti allineati. La matrice dice chi fa che cosa nel progetto, le autorizzazioni dicono che cosa ciascuno può fare dentro SAP una volta avviato il sistema.
In fase di progettazione delle autorizzazioni il riferimento sono i ruoli operativi, cioè la figura professionale, non la singola persona. L’obiettivo è evitare ruoli costruiti ad personam, con duplicazioni e transazioni ridondanti. Come ordine di grandezza, il numero di figure professionali dovrebbe stare fra il 10% e il 30% degli utenti definiti nel sistema.
La separazione fine la fanno gli oggetti di autorizzazione, che distinguono le specificità dentro le transazioni: sulla creazione di un ordine di vendita, per esempio, si possono separare i ruoli che gestiscono alcuni tipi di documento da quelli che possono solo vederli. Lo stesso criterio vale sui flussi autorizzativi degli acquisti, dove il flexible workflow lega l’approvazione al ruolo e non alla persona. In SAP esistono oltre 3.000 oggetti di autorizzazione.
Quando la matrice RACI non serve
Su un progetto piccolo, con poche persone che si parlano ogni giorno, la matrice diventa un documento da aggiornare che nessuno guarda. Il costo di mantenerla supera il beneficio quando le attività sono poche e i ruoli evidenti.
C’è poi un modo tipico di sbagliarla: mettere due accountable sulla stessa riga per non scontentare nessuno. Una matrice con due approvatori per attività non risolve l’ambiguità, la certifica, e in fase di test produce esattamente il rimpallo che doveva evitare.
Domande frequenti sulla matrice RACI nei progetti SAP
Quando si costruisce la matrice?
Nella fase di analisi, prima che partano le configurazioni. Costruirla a progetto avviato significa assegnare responsabilità su attività già in corso, e di solito serve a stabilire di chi è la colpa di un ritardo, non a prevenirlo.
Chi la mantiene aggiornata durante il progetto?
Il project manager, con revisione a ogni passaggio di fase, in parallelo agli altri documenti di metodo del progetto. Una matrice scritta all’inizio e mai più toccata descrive un progetto che non esiste più dopo il primo cambio di perimetro.
Vale anche per le attività dei consulenti esterni?
Sì, ed è uno degli usi più utili. Sulle righe che riguardano il fornitore, la A resta quasi sempre al cliente: l’esecuzione può essere esterna, l’approvazione del risultato no.
Che cosa succede alla matrice dopo il go live?
Le righe di progetto decadono, le responsabilità sui processi restano e confluiscono nel presidio del sistema. È il momento di definire chi raccoglie le segnalazioni e chi le autorizza nel contratto di assistenza.
Serve anche in un progetto di roll out?
Serve, e cambia di contenuto: nei progetti di roll out la matrice deve dire soprattutto chi decide quando una specificità locale si configura e quando invece si allinea al modello del gruppo.
Parliamo del vostro progetto
Il team di Software Business affianca le aziende del mid-market nei progetti SAP, dalla definizione dei ruoli di progetto al disegno delle autorizzazioni a sistema. Se state impostando un’implementazione o un’estensione, scriveteci: si parte da come lavorano oggi le vostre aree, non da un modello di matrice da compilare.
Le tre metodologie di migrazione a confronto, i tre numeri che decidono quale conviene, la lista di controllo del Readiness Check e le date di fine manutenzione.