Pianificazione e controllo dei progetti SAP: tenerli in rotta

La maggior parte dei programmi SAP ha un piano. Molti meno hanno il controllo. La pianificazione definisce perimetro, tempistiche, budget e rischi. Il controllo è il lavoro settimanale di monitorare l'avanzamento rispetto a quel piano, gestire le dipendenze, fare escalation in anticipo e valutare ogni modifica prima che venga approvata. Questa guida è per direttori di programma, PMO e sponsor il cui programma SAP sta andando alla deriva, o che vogliono impedire che ci vada. Spiega com'è fatto il controllo, tre fallimenti pubblici che mostrano cosa succede senza, e una cadenza settimanale di controllo con responsabili che si può adottare già questa settimana.

Agli inizi ho lavorato a un programma SAP che sulla carta sembrava ottimo. Tempistiche, registri dei rischi, registri delle modifiche, tutto quello che ci si aspetta. Nessuno lo seguiva. Il comitato direttivo si riuniva di rado. La finanza aspettava la migrazione dei dati. L'IT non era ancora partito. Nessuno monitorava le dipendenze. Ognuno dava per scontato che qualcun altro tenesse il programma in rotta.

Al sesto mese metà del progetto era in ritardo e stavamo rincorrendo i nostri stessi errori. La parte peggiore era che nessuno l'aveva visto arrivare.

Non era un problema di pianificazione. Era un problema di controllo. Non c'era una vera allocazione delle risorse, né una mitigazione dei rischi adeguata, né un percorso di escalation. Il piano era stato prodotto una volta e poi abbandonato a favore delle riunioni.

La pianificazione copre perimetro, tempistiche, budget, risorse, registro dei rischi e impegni sulle milestone. La maggior parte dei team la produce. La domanda è se qualcuno la usa da una settimana all'altra.

Il controllo copre il monitoraggio dell'avanzamento effettivo rispetto al piano, l'emersione tempestiva degli scostamenti, la gestione delle dipendenze, l'escalation quando le cose slittano e l'aggiornamento della baseline quando perimetro o tempistiche cambiano formalmente. La maggior parte dei team lo fa male.

1. 01Monitorare l'avanzamentoEffettivo rispetto al piano, per work package
2. 02Far emergere gli scostamentiQualsiasi attività in ritardo di tre giorni
3. 03Verificare le dipendenzeChi resta bloccato se questa slitta
4. 04Fare escalationSu un percorso concordato in anticipo
5. 05Valutare le modifichePrima di tutto tempi, costi e risorse
6. 06Aggiornare la baselineSolo dopo una modifica formale

Ogni settimana, con responsabili nominati

Ecco cosa si rompe quando manca il controllo:

Cosa si rompe senza controllo	Perché succede
Le scadenze slittano in silenzio	Nessuno controlla tra una revisione delle milestone e l'altra
Le ipotesi restano non verificate	Ogni team si aspetta che un altro gestisca la dipendenza
Il perimetro si espande in modo informale	Modifiche approvate in riunione senza valutazione dell'impatto
I rischi vengono ignorati finché non si materializzano	Registro dei rischi aggiornato ogni trimestre invece che ogni settimana
I costi superano il budget	Lo sforzo sta nei timesheet ma non è associato ai work package
I team smettono di comunicare	Le riunioni di stato diventano aggiornamenti senza azioni

Sono casi pubblici, non storie di clienti. Le loro cause radice sono quelle che vedo ripetersi nel lavoro di advisory.

Lidl: circa sette anni e una spesa stimata di 500 milioni di euro, poi lo stop

Lidl ha avviato il progetto eLWIS su SAP Retail nel 2011. La sua prassi di valorizzazione delle giacenze differiva dal modello standard di SAP, e Lidl ha scelto di adattare il software invece della prassi. Nel 2018 il sistema era in produzione in Austria, Irlanda del Nord e Stati Uniti, ma il consiglio ha concluso che gli obiettivi originali non erano raggiungibili a un costo ragionevole. Lidl ha fermato il progetto ed è tornata a sviluppare il proprio sistema interno. La stampa di settore ha stimato la spesa intorno ai 500 milioni di euro, e il membro del consiglio responsabile dell'IT aveva lasciato nel 2017. Heise ha riportato la decisione nel luglio 2018. La lezione: anni di personalizzazione per proteggere una prassi legacy sono un fallimento di controllo, non un fallimento del software.

Hershey: circa 100 milioni di dollari di ordini di Halloween non consegnati

Il nuovo sistema SAP, Siebel e Manugistics di Hershey doveva andare in produzione ad aprile 1999, un mese tranquillo per il settore dolciario. È slittato di tre mesi ed è partito a luglio, proprio mentre cominciavano ad arrivare gli ordini per Halloween. Gli ordini non riuscivano ad arrivare dal sistema ai magazzini. Il CEO ha detto agli analisti che i problemi avrebbero impedito a Hershey di consegnare circa 100 milioni di dollari di prodotto per Halloween, e le vendite del terzo trimestre sono calate del 12,4%. Il resoconto di CIO magazine attribuisce il vero fallimento ai tempi. Un controllo del calendario che proteggesse l'alta stagione avrebbe imposto un'altra data di go-live.

Revlon: uno stabilimento in difficoltà e una carenza sostanziale nei controlli

Revlon ha attivato SAP nel suo stabilimento di Oxford, North Carolina, il suo maggiore sito produttivo, nel febbraio 2018. Le interruzioni del servizio hanno colpito la produzione e le spedizioni verso i grandi rivenditori statunitensi. Nel marzo 2019 Revlon ha dichiarato una carenza sostanziale (material weakness) nel controllo interno legata al rollout, indicando l'assenza di una valutazione continua ed efficace dei rischi e troppo poche persone formate nelle operazioni interessate. Gli investitori hanno fatto causa; TechTarget ha seguito la causa, che sosteneva che circa 64 milioni di dollari di spedizioni non fossero stati evasi.

Nessuno di questi progetti è fallito perché SAP era la scelta sbagliata. Sono falliti sui fondamentali di pianificazione e controllo che esistono da decenni.

Work breakdown structure

Una work breakdown structure (WBS) scompone il perimetro totale in deliverable con responsabili chiari. Senza, il lavoro è invisibile finché non è in ritardo. Per un programma SAP copre progettazione dei processi, configurazione, migrazione dei dati, integrazione, test, formazione e cutover, ciascuno scomposto in attività con un responsabile e una scadenza.

Il valore non sta nel documento. Obbliga a parlare di cosa va fatto, da chi e da cosa dipende. Sono le dipendenze a far morire i progetti. Un ritardo nella migrazione dei dati blocca i test di integrazione, che bloccano lo UAT, che stringe la finestra di cutover. Una WBS rende visibile quella catena.

Gestione delle tempistiche

Le tempistiche falliscono per ragioni prevedibili. Le persone vengono dirottate. Le stime erano sbagliate. Le decisioni richiedono più tempo del previsto. Prevedere una contingenza fin dal primo giorno, come buffer esplicito accanto alle attività che più probabilmente ne avranno bisogno, non come margine sparso ovunque.

Monitorare il piano ogni settimana. Un ritardo di una settimana alla quarta settimana è una conversazione. Un ritardo di quattro settimane alla sedicesima è una crisi. Stesso problema, costo di correzione molto diverso.

Trattare i tempi del go-live come una decisione a sé. Mai andare in produzione in un periodo di picco dell'attività. La lezione di Hershey vale per ogni azienda.

Controllo del budget

I budget si rompono per tre ragioni: modifiche di perimetro non gestite, migrazione dei dati sottostimata e costi di hypercare superiori alle stime iniziali. Monitorare la spesa effettiva rispetto al piano dalla prima settimana. Quando uno scostamento arriva al comitato direttivo, di solito è troppo tardi per correggerlo senza traumi.

Il controllo delle modifiche è la principale protezione del budget. Ogni modifica di perimetro riceve una valutazione dell'impatto su tempi, costi e risorse prima dell'approvazione. Se la valutazione arriva dopo l'approvazione, la modifica ha aggirato il budget. La mia guida su come evitare lo scope creep nelle implementazioni SAP approfondisce il comitato per le modifiche.

Gestione dei rischi

Un registro dei rischi mantenuto ogni trimestre è teatro. I rischi vanno rivisti ogni settimana, con responsabili nominati e piani di risposta. Inserire questi in ogni programma SAP: qualità dei dati scoperta in ritardo, ritardi di integrazione, lacune nella disponibilità delle risorse, compressione della finestra di cutover e scarsa adozione da parte degli utenti.

Un cliente ha perso tre mesi quando il fornitore della migrazione dei dati ha mancato una scadenza dopo l'altra. Continuavamo a sentirci dire «ancora due settimane» finché è stato troppo tardi per cambiare fornitore senza far saltare il budget. Un rischio con un responsabile e una data di attivazione avrebbe forzato quella decisione mesi prima. La mia matrice di valutazione dei rischi SAP offre un modello per valutare e assegnare questi rischi.

Comunicazione ed escalation

I dirigenti hanno bisogno dei titoli. I team di delivery hanno bisogno dei dettagli. I project manager hanno bisogno dei dati sugli scostamenti. Un solo aggiornamento per tutti non serve a nessuno.

Documentare e provare i percorsi di escalation prima di una crisi. In un'implementazione SAP, l'IT dava per scontato che la finanza stesse rivedendo la configurazione e la finanza dava per scontato che lo facesse l'IT. Nessuno l'ha segnalato finché il go-live era a tre mesi e mancavano approvazioni critiche; la soluzione è stata una corsa dell'ultimo minuto, un costo aggiuntivo e un rollout in ritardo. Un'altra azienda l'ha fatto bene: il reporting era strutturato e collegato alle azioni, così quando emergeva un problema tutti sapevano chi ne era responsabile, quale fosse l'impatto e come sarebbe stato risolto.

È sul perimetro che l'escalation si guadagna il pane. Ho lavorato con una compagnia aerea che era partita da un semplice aggiornamento delle prenotazioni. Sei mesi dopo aveva aggiunto modifiche al loyalty, alla pianificazione degli equipaggi e ai moduli finanziari. Nessuna era urgente. Nessuno ha detto di no. I tempi sono raddoppiati e i costi sono saliti del 70%.

Il playbook on-premise non sopravvive a RISE with SAP senza cambiamenti. Tre cose sono diverse.

RISE cambia a chi si fa escalation

Con RISE with SAP, SAP gestisce l'infrastruttura e le operazioni tecniche e mette a disposizione un team di customer success che monitora l'adozione. La struttura di controllo deve includerlo. Per i problemi di piattaforma (prestazioni del sistema, regione dell'hyperscaler, livelli di servizio SAP), il responsabile di programma ha bisogno di un percorso di escalation documentato verso SAP che non passi dal partner di implementazione. Va scritto prima di averne bisogno.

Il clean core dà al controllo del perimetro un supporto tecnico

Ogni gap ora richiede una decisione: configurarlo, estenderlo tramite API rilasciate (on-stack con ABAP Cloud o side-by-side su SAP BTP) oppure rifiutarlo. Su S/4HANA Cloud Public Edition modificare il core non è un'opzione. Su private edition e on-premise è possibile, ma le linee guida clean core di SAP lo trattano come l'ultima risorsa, perché ogni modifica aggiunge lavoro di upgrade.

Questo aiuta il controllo del perimetro. Una richiesta di «ritoccare solo il processo standard order-to-cash» smette di essere una chiacchierata informale sulla configurazione e diventa un'estensione con sforzo di design, sviluppo e test. Metta sotto il comitato direttivo un piccolo forum di revisione delle estensioni, con un architetto che abbia l'autorità di approvare o rifiutare. Senza, ogni discussione sulla personalizzazione finisce al comitato direttivo.

L'AI prepara le bozze dei report, le persone prendono le decisioni

L'AI ora aiuta con la parte documentale del controllo. SAP Cloud ALM, lo strumento di application lifecycle di SAP, contiene attività di progetto, requisiti e stato dei test, e può generare bozze di requisiti dalle trascrizioni dei workshop. Microsoft Copilot prepara le sintesi degli scostamenti per i documenti del comitato direttivo a partire da dashboard e report di stato. Il rilevamento delle anomalie in Power BI o SAP Analytics Cloud segnala i KPI che si discostano dal loro andamento abituale. È utile per l'uso delle risorse, il volume delle richieste di modifica e i ticket di supporto, meno per le metriche che oscillano per natura.

Quello che l'AI non fa è agire. Una dashboard può mostrare in rosso lo slittamento dei tempi per sei settimane. Se il comitato direttivo non fa nulla, lo slittamento continua.

Questo è il ritmo minimo per un programma in fase di delivery attiva. Se manca una riga, la si aggiunga prima di qualsiasi altra cosa.

Controllo	Pratica minima	Responsabile	Frequenza
Work breakdown structure	Ogni attività ha un responsabile, una scadenza e le sue dipendenze	Responsabile PMO	Aggiornata ogni settimana
Revisione delle tempistiche	Segnalare ogni attività in ritardo di più di tre giorni; verificare il percorso critico	Responsabile di programma	Ogni settimana
Monitoraggio del budget	Effettivo rispetto al piano per work package	Responsabile finanziario del programma	Ogni settimana, rendicontato ogni mese
Revisione dei rischi	Ogni rischio attivo ha un responsabile, un trigger e una risposta	Responsabili dei workstream	Ogni settimana
Controllo delle modifiche	Valutazione dell'impatto su tempi, costi e risorse prima dell'approvazione	Presidente del comitato per le modifiche	Ogni settimana o all'arrivo delle richieste
Revisione delle estensioni (RISE e GROW)	Decisione di configurare, estendere o rifiutare per ogni gap	Solution architect	Ogni due settimane
Comitato direttivo	Decisioni, non aggiornamenti di stato; documenti inviati in anticipo	Sponsor esecutivo	Ogni due settimane; ogni settimana in cutover e hypercare

La maggior parte della pianificazione e del controllo fallisce non perché il metodo era sbagliato, ma perché la disciplina è stata abbandonata entro il quarto mese. Tenga la cadenza abbastanza snella da essere ancora applicata dal team al quattordicesimo mese. Per il comitato direttivo in sé, veda la mia guida su come creare un comitato direttivo SAP efficace.

Qual è la differenza tra pianificazione e controllo del progetto?

La pianificazione produce la roadmap: perimetro, tempistiche, budget, risorse e rischi. Dà la direzione all'inizio.

Il controllo è il lavoro continuo di monitorare l'avanzamento rispetto a quel piano, far emergere gli scostamenti, gestire le dipendenze e aggiornare la baseline quando intervengono modifiche formali. Avviene ogni settimana per tutta la vita del programma.

La maggior parte dei programmi SAP investe molto nella pianificazione e troppo poco nel controllo. Quando lo scostamento emerge al comitato direttivo, si sono già accumulate settimane o mesi di costi di recupero.

Perché i progetti SAP falliscono pur avendo un piano di progetto?

Perché nessuno lavora sul piano. Le dipendenze non vengono monitorate, quindi il ritardo di un workstream ne blocca in silenzio un altro. I registri dei rischi sono aggiornati ogni trimestre. Le modifiche di perimetro vengono approvate in modo informale. Il comitato direttivo si riunisce una volta al mese e vede sintesi delle milestone che nascondono ciò che accade sul campo.

Lidl, Hershey e Revlon avevano tutte un piano. Mancava il controllo attivo: monitoraggio onesto, escalation tempestiva e una risposta reale quando sono comparsi i segnali di allarme.

Come gestisco lo scope creep in un programma SAP lungo?

Dia a ogni modifica di perimetro una valutazione scritta dell'impatto prima dell'approvazione: tempi, costi e risorse. Senza, approvare una modifica significa approvare un'incognita.

La regola più efficace: ogni aggiunta deve prendere il posto di qualcos'altro. Quel solo vincolo spinge i responsabili di business a fissare le priorità con onestà.

I dirigenti devono sostenerla. Quando un CFO o un COO sostiene pubblicamente il controllo delle modifiche, le richieste informali calano in fretta. Nei programmi RISE e GROW, la decisione sull'estensione per ogni gap aggiunge un controllo tecnico in più.

Che cos'è una work breakdown structure e perché conta per SAP?

Una WBS scompone il perimetro totale in deliverable, ciascuno con un responsabile e una scadenza. In un programma SAP significa progettazione dei processi, configurazione, migrazione dei dati, integrazione, test, formazione e cutover, tutti scomposti in attività.

Il suo valore pratico è la mappatura delle dipendenze. La migrazione dei dati alimenta i test di integrazione, che alimentano lo UAT, che alimenta il cutover. Quando una slitta, l'impatto a valle è visibile subito.

Come cambia RISE with SAP la pianificazione e il controllo dei progetti?

SAP diventa un partecipante alla delivery. Gestisce infrastruttura e operazioni tecniche, e il suo team di customer success segue una propria cadenza su adozione e valore.

Ne conseguono tre cambiamenti. Serve un percorso di escalation documentato verso SAP per i problemi di piattaforma, che non passi dal partner. Serve un forum di revisione delle estensioni sotto il comitato direttivo per decidere come trattare ogni gap secondo il clean core. E la cadenza di customer success di SAP va integrata nella governance invece di essere condotta in parallelo.

Cosa dovrebbe fare un comitato direttivo in un programma SAP?

Prendere decisioni. Il suo compito è risolvere ciò che il team di programma non può: conflitti di risorse, dispute sul perimetro, modifiche al budget e tutto ciò che richiede un'autorità trasversale. Una riunione del comitato direttivo che finisce senza decisioni era un aggiornamento di stato.

Un comitato direttivo mensile su un grande programma lascia i problemi in attesa fino a quattro settimane. Ogni due settimane è il minimo in fase di delivery attiva, ogni settimana in cutover e hypercare. Inviare i report di avanzamento in anticipo e usare la riunione per le decisioni che sollevano.