Valutazione dei rischi di un progetto SAP: la versione pratica

Una valutazione dei rischi di un progetto SAP elenca ciò che potrebbe far deragliare il programma e valuta ogni rischio per probabilità e impatto. Ogni rischio ha un solo responsabile con nome e cognome e una risposta concordata prima che si verifichi, e l'elenco viene rivisto ogni settimana. I rischi che affondano i programmi SAP raramente sono sorprese: migrazione dei dati, integrazione, disponibilità delle persone, deriva del perimetro e adozione. Questa guida è per i program manager e gli sponsor che vogliono un registro dei rischi che cambia le decisioni invece di restare in una cartella. Fornisce una matrice con punteggi, un modello di registro, tre fallimenti pubblici come esempi concreti e i rischi che RISE with SAP e il Clean Core aggiungono. Cominci assegnando un responsabile con nome e cognome a ogni rischio che ha già.

La maggior parte delle valutazioni dei rischi SAP viene costruita prima del primo steering committee, rivista una volta e mai più toccata. Questa non è gestione del rischio. È un documento.

Ho visto rischi ignorati perché troppo scomodi da sollevare presto. Quel silenzio quasi sempre costa di più dopo. Quello che comincia come un piccolo problema di integrazione in Materials Management all'improvviso blocca la Finanza. Un report che nei test sembrava a posto si rompe dopo un aggiornamento del sistema. L'ho visto succedere più di una volta.

I rischi non erano sorprese. Erano documentati. Nessuno ha agito.

Perimetro. Il progetto parte con i moduli standard. Poi qualcuno aggiunge «solo un altro report», poi una dashboard, poi qualche potenziamento. Il pericolo sono le modifiche di perimetro introdotte in modo informale in workshop, e-mail e conversazioni nei corridoi, di cui il project manager viene a sapere solo a configurazione conclusa. La mia guida su come evitare lo scope creep tratta i controlli.

Risorse. L'architetto viene dirottato su un problema in produzione. Uno sviluppatore chiave se ne va. Gli utenti di business saltano i cicli di test perché il loro lavoro quotidiano non si ferma. Si ottenga la disponibilità per iscritto. Le promesse verbali evaporano sotto la pressione sugli organici.

Tecnico. Mappature dei campi mai convalidate rispetto alla struttura di destinazione. Interfacce che superano il test unitario e si rompono con i volumi reali di transazioni. Codice custom che sembra a posto finché non arriva il carico di produzione. Sono rischi prevedibili, se si sa dove guardare.

Tempistica. Un blueprint in ritardo comprime i test, ma la data di go-live resta fissa. UAT, formazione e preparazione dei dati vengono fatti di corsa. Lo stesso schema compare in quasi ogni programma che salta un phase gate senza spostare il piano a valle.

Adozione. Le persone rifiutano ciò che non capiscono. Una formazione debole o tardiva produce scappatoie, le scappatoie degradano i dati e si dà la colpa al sistema per un fallimento del change management.

Questi casi sono pubblici e ben documentati. Gli schemi si ripetono a ogni scala.

Lidl: circa 500 milioni di euro in sette anni

Lidl avviò il suo progetto eLWIS su SAP for Retail nel 2011, andò in produzione in alcuni paesi più piccoli e lo abbandonò nel 2018 a un costo riportato di circa 500 milioni di euro. Una causa riferita da molte fonti: Lidl valutava le scorte ai prezzi d'acquisto, mentre il modello retail standard di SAP usa i prezzi di vendita al dettaglio. Lidl scelse di personalizzare invece di cambiare la prassi, e l'azienda dichiarò che gli obiettivi originali non erano raggiungibili con uno sforzo ragionevole.

Lezione: un disallineamento tra il Suo modello di dati e lo standard SAP è un rischio della prima settimana, non una scoperta del quinto anno.

HP: circa 400 milioni di dollari di ricavi persi

Nel 2004 HP migrò parte della propria attività server su un sistema consolidato di ordini e supply chain basato su SAP. Gli ordini si perdevano tra il front end legacy e SAP e richiedevano interventi manuali, e l'arretrato raddoppiò. L'amministratore delegato di HP disse che i problemi erano costati al gruppo server e storage circa 400 milioni di dollari di ricavi e 275 milioni di dollari di utile operativo, lasciando un arretrato di 120 milioni di dollari. Il CIO di HP disse poi che il team aveva pianificato tre settimane di disagi e avrebbe dovuto prevedere una contingenza da quattro a sei.

Lezione: si dimensioni la contingenza su un cutover andato male, non su uno medio, e si costruiscano scorte o buffer di canale prima del passaggio.

Nike: oltre 100 milioni di dollari di vendite perse

Nel 2000 Nike andò in produzione con il software di pianificazione della domanda di i2 prima del suo programma ERP SAP. Il software era stato personalizzato in modo massiccio per funzionare con i sistemi legacy di Nike, girava lentamente e andava in crash con il volume di prodotti. Ordinava troppe scarpe di alcuni modelli e troppo poche di altri. Nike perse oltre 100 milioni di dollari di vendite e il suo titolo calò di circa il 20%. In seguito Nike spostò in SAP la pianificazione a breve e medio termine.

Lezione: non si dia mai per scontato che un'integrazione funzioni finché non ha girato con volumi di produzione e dati reali.

Una valutazione costruita su ipotesi è peggio di nessuna, perché crea una falsa sicurezza. Contano sei input:

1. Documentazione del perimetro: charter, perimetro approvato e requisiti firmati. Se non esistono, il rischio di perimetro è già alto.
2. Impegni di risorse: impegni scritti dai responsabili di funzione, una matrice delle competenze per i ruoli critici e un sostituto con nome e cognome per ogni posizione chiave.
3. Budget e tempistica: budget approvato con contingenza e una tempistica confrontata con programmi analoghi. Sei mesi e fondi minimi per un rollout completo sono un rischio da segnalare subito.
4. Impegni dei fornitori: contratti con livelli di servizio e penali. Con RISE, le responsabilità di SAP e il percorso di escalation.
5. Landscape tecnico: compatibilità con i sistemi legacy, complessità della migrazione dei dati, modello di deployment e un piano Clean Core per ogni sviluppo custom.
6. Registri di progetti passati: registri dei rischi, registri dei problemi e post-mortem di programmi SAP o ERP precedenti. La maggior parte dei rischi non è nuova.

Si valuti ogni rischio per probabilità e impatto da 1 a 5 e si moltiplichino i due valori. L'esempio qui sotto è un tipico punto di partenza per un programma S/4HANA; i Suoi punteggi saranno diversi.

Rischio	Probabilità (1-5)	Impatto (1-5)	Punteggio	Priorità
Fallimento della migrazione dei dati	4	5	20	Alta
Ritardi nell'integrazione	4	4	16	Alta
Vincoli di risorse	4	4	16	Alta
Sforamento del budget	3	5	15	Media
Codice custom nel core che blocca gli aggiornamenti	3	5	15	Media
Scope creep	4	3	12	Media
Lacune nella copertura dei test	3	4	12	Media
Prestazioni sotto carico di picco	3	4	12	Media
Lacune di compliance	2	5	10	Media
Nessun percorso di escalation verso SAP (RISE)	2	5	10	Media
Bassa adozione da parte degli utenti	3	3	9	Media
Esposizione ai costi di sottoscrizione o licenza	2	4	8	Media
KPI non monitorati	3	2	6	Bassa

I punteggi da 16 in su richiedono un responsabile con nome e cognome e un'azione subito. I punteggi da 8 a 15 richiedono monitoraggio con un trigger di escalation definito. Sotto 8, il rischio resta nel registro senza dedicargli tempo prioritario. I punteggi sono un punto di partenza, non un verdetto: una lacuna di compliance valutata 10 può diventare 25 in un settore regolamentato.

Un punteggio da solo non cambia nulla. Ogni rischio ha bisogno di questi campi, compilati.

Campo	Che cosa scrivere	Esempio
Rischio	L'evento, in una frase	I dati anagrafici dei fornitori non vengono ripuliti prima del mock load 2
Responsabile	Una persona con nome e cognome	Responsabile dei debiti verso fornitori
Punteggio	Probabilità × impatto	4 × 5 = 20
Trigger	Il punto misurabile in cui si agisce	Tasso di duplicati superiore al 5% nell'estrazione del mock 1
Risposta	Evitare, mitigare, trasferire o accettare, con l'azione	Mitigare: due analisti AP sulla pulizia per tre settimane
Prossima revisione	Data	La revisione dei rischi di lunedì prossimo
Stato	Aperto, in corso, chiuso	In corso

Dove può, esprima il costo in termini concreti. «Rischio alto» è vago. «Un ritardo di una settimana nell'UAT costa circa sei cifre in tempo del team e può spostare il go-live di tre settimane» attira l'attenzione.

Il codice custom è una categoria di rischio a sé. Su S/4HANA Cloud Public Edition il codice custom nel core non è possibile. Le estensioni passano per SAP BTP, per API rilasciate o per gli strumenti per key user. Su private cloud e on-premise si può ancora modificare il core, e i partner abituati a farlo lo faranno. Quel debito tecnico emerge al primo aggiornamento importante. Si monitori quante delle personalizzazioni individuate hanno un approccio Clean Core concordato, si verifichi l'esperienza del partner con le estensioni su BTP e si istituisca un forum di revisione entro la fine della fase Explore.

RISE cambia chi è responsabile della disponibilità. SAP gestisce l'infrastruttura, quindi il rischio passa da «la nostra squadra è responsabile della disponibilità» a «è responsabile SAP e ci serve una via d'accesso rapida quando qualcosa si guasta». Si registrino i contatti nominativi di SAP, il percorso di escalation e i livelli di servizio, e un piano per gli incidenti concordato prima del go-live. Senza questi elementi, i problemi che dovrebbero andare a SAP restano troppo a lungo dentro il team di progetto.

L'AI aiuta con le carte, non con il giudizio. Gli assistenti basati su Joule in SAP Cloud ALM e strumenti come Microsoft Copilot possono redigere voci di registro e documenti per lo steering a partire da report di stato, registri dei difetti e verbali. Questo velocizza la manutenzione del registro nei programmi con dati di partenza puliti. Trova rischi già visibili nei dati. Non decide quali rischi meritano un'azione, non spinge i responsabili ad agire e non porta in escalation i rischi che la dirigenza preferirebbe ignorare.

1. Identificare i rischi in tutte e cinque le categorie. Si organizzino workshop con l'IT, il business e i fornitori; ognuno vede rischi diversi. Con RISE, si includano i contatti SAP in almeno uno. I rischi che i team di solito mancano: IT e business che si aspettano cose diverse, integrazioni esterne definite male, responsabili dell'UAT non disponibili e modifiche di perimetro informali.
2. Valutare ogni rischio per probabilità e impatto, con numeri reali dove possibile.
3. Assegnare un responsabile per rischio. Una persona, non un team. Senza responsabile non c'è monitoraggio e non c'è risoluzione.
4. Definire la risposta prima che il rischio si materializzi. Evitare, mitigare, trasferire o accettare. «Monitorare e rispondere» non è un piano. È una decisione rinviata.
5. Rivedere ogni settimana. Si controllino i rischi aperti, si aggiungano quelli nuovi, si rivalutino i punteggi dove le condizioni sono cambiate e si porti in escalation tutto ciò che si avvicina al proprio trigger. Si portino i rischi principali allo steering committee con una proposta di decisione anziché un colore.

1. 01IdentificareTutte e cinque le categorie
2. 02ValutareProbabilità × impatto, da 1 a 5
3. 03Assegnare un responsabileUna persona, non un team
4. 04Definire la rispostaEvitare, mitigare, trasferire o accettare
5. 05Rivedere ogni settimanaRivalutare e portare in escalation vicino ai trigger

16 o più: un responsabile con nome e cognome e un'azione questa settimana

Che cos'è una valutazione dei rischi in un progetto SAP?

È il processo con cui si individua che cosa potrebbe andare storto, si valuta ogni rischio per probabilità e impatto, si assegna a ciascuno un responsabile e si concorda una risposta prima che si verifichi. I programmi SAP portano avanti insieme più moduli, integrazioni, una migrazione dei dati, un programma di cambiamento e un go-live a data fissa, quindi la gestione informale dei rischi non regge. Un breve elenco di rischi reali con i responsabili vale più di un lungo documento che nessuno legge.

Come si costruisce una matrice dei rischi per un progetto SAP?

Si elencano i rischi di perimetro, risorse, tecnici, di tempistica e di adozione, più Clean Core e l'escalation verso SAP con RISE. Si valuta ciascuno per probabilità e impatto da 1 a 5 e si moltiplica. Si considera alto 16 e oltre, medio da 8 a 15 e basso sotto 8. A ogni rischio medio e alto si assegnano un responsabile e un trigger misurabile, come «se il completamento dell'UAT è sotto l'80% alla settimana 16, la data di go-live va in revisione». Si rivaluta ogni settimana e a ogni phase gate.

Quali sono i rischi più comuni nelle implementazioni SAP?

Il fallimento della migrazione dei dati, perché i dati legacy sono quasi sempre più disordinati del previsto. I ritardi di integrazione, soprattutto con interfacce legacy non documentate e fornitori terzi. Lo scope creep che comprime test e formazione. I vincoli di risorse, come persone chiave dirottate o utenti non disponibili durante l'UAT a fine mese. La bassa adozione dovuta a una formazione che mostra le schermate invece di simulare il lavoro. Con RISE si aggiungano il codice custom nel core e l'assenza di un percorso di escalation verso SAP.

Quando va fatta la valutazione dei rischi durante un progetto SAP?

Prima dell'avvio del progetto, quando i rischi strutturali, come i disallineamenti del modello di dati o le tempistiche irrealistiche, costano meno da correggere. Prima di ogni phase gate di SAP Activate, perché ogni fase cambia il profilo di rischio. Ogni volta che cambiano perimetro, budget o risorse. E quando un rischio diventa un problema, per verificare che cos'altro coinvolge. Nel frattempo, una revisione ogni settimana.

Chi dovrebbe essere responsabile dei rischi in un programma SAP?

La persona che può agire su di essi. Il responsabile dei dati è responsabile del rischio di migrazione dei dati, l'architetto tecnico del rischio di integrazione, il responsabile del cambiamento del rischio di adozione e il solution architect del rischio Clean Core. Con RISE, il CIO o il direttore del programma è responsabile del percorso di escalation verso SAP. Il program manager tiene sotto controllo lo stato di salute del registro, ma non è responsabile di ogni rischio.

Che cosa succede quando si salta la valutazione dei rischi di un ERP?

Su larga scala si arriva a casi come Lidl, che nel 2018 ha abbandonato il suo progetto SAP retail dopo circa 500 milioni di euro. O HP, la cui migrazione del sistema ordini SAP nel 2004 è costata al suo gruppo server circa 400 milioni di dollari di ricavi. Su scala minore il meccanismo è lo stesso: disallineamenti del modello di dati scoperti tardi, integrazioni che falliscono con i volumi di produzione e fallimenti di adozione dovuti a una formazione debole. I rischi erano individuabili prima che diventassero problemi.