Come evitare lo scope creep in un'implementazione SAP

Si evita lo scope creep in un'implementazione SAP rendendo ogni modifica visibile e costosa da approvare. Scriva ciò che è fuori perimetro con la stessa cura con cui scrive ciò che è dentro. Faccia passare ogni richiesta dal change control, con una valutazione d'impatto su tempi, costi e qualità. Richieda un compromesso per ogni aggiunta. Fissi una data di scope freeze con il sostegno del vertice e porti la stessa disciplina nel contratto con il system integrator (SI). Questa guida è per i direttori di programma, gli sponsor e i PMO dei programmi S/4HANA. Usi la tabella del costo della modifica e le clausole contrattuali qui sotto nel suo prossimo steering pack.

La maggior parte dei progetti SAP sfora il budget e supera le scadenze, e lo scope creep è il motivo più comune. Ho lavorato con decine di aziende i cui progetti SAP sono sfuggiti di mano, e tre segnali compaiono prima che lo sforamento arrivi nel report dello steering. Le piccole modifiche si accumulano senza valutazione d'impatto. Il change control funziona sulle relazioni personali invece che su un'autorità documentata. E lo sponsor approva davanti a un caffè cose di cui il team di progetto viene a sapere una settimana dopo.

Un cliente farmaceutico era partito con una timeline chiara di 18 mesi. Tre anni dopo stava ancora implementando e i costi erano raddoppiati. Il CIO di un'azienda manifatturiera mi ha detto che il suo team aveva scartato interi moduli configurati in mesi di lavoro, perché i requisiti continuavano a cambiare. Il perimetro era cresciuto così tanto che nessuno riconosceva più il piano originale.

Non sono casi limite. Sono il modo più comune in cui i programmi SAP falliscono.

Inizia in modo innocente. Un responsabile di business chiede «solo una piccola modifica». Poi un'altra. La frase «già che ci siamo, basta solo...» ha fatto deragliare più implementazioni SAP di qualsiasi sfida tecnica.

Ho lavorato con un cliente retail con cui eravamo partiti puliti: Finance di base e gestione materiali di base. Sei mesi dopo il CMO voleva l'analisi dei clienti. Poi il COO ha chiesto funzioni avanzate di magazzino. La timeline originale di nove mesi era a rischio. Ho fatto resistenza e ho respinto entrambe le richieste. Quella disciplina è il lavoro.

Non ogni modifica è scope creep. A volte si scoprono lacune critiche nel design che nessuno aveva previsto. A volte le normative cambiano a progetto avviato. Sono casi legittimi, e seguono un processo con aggiustamenti di timeline e budget. Lo scope creep semplicemente compare, di solito dopo una conversazione in corridoio.

Un cliente manifatturiero era partito con 10 report personalizzati e ne ha chiusi 47, ciascuno con tempi aggiuntivi di design, sviluppo e test. Il solo filone di lavoro sul reporting ha sforato il budget del 200%.

200%

sforamento del budget del filone di reporting dopo che la deriva del perimetro ha portato i report personalizzati da 10 a 47

Fonte: Programma di un cliente manifatturiero

Segnali d'allarme

Questi sono i segnali che osservo, con la risposta a ciascuno:

Segnale d'allarme	Causa sottostante	Risposta
«Ancora una cosa» diventa il linguaggio di tutti i giorni	Confini del perimetro poco chiari	Rifissare la baseline con i responsabili di business; applicare un change control formale
I responsabili di business aggiungono funzionalità in modo informale	Nessuna comprensione dell'impatto a valle	Far passare ogni richiesta da una valutazione d'impatto; mostrare il costo
La timeline si allunga senza una ripianificazione formale	Espansione silenziosa del perimetro	Tenere checkpoint sul perimetro; ripianificare con l'approvazione del change board
La documentazione non corrisponde più a ciò che è stato costruito	Gestione informale del perimetro, nessun controllo di versione	Aggiornare specifiche e piani a ogni modifica approvata
Il consumo di budget supera l'avanzamento	Effort nascosto dovuto a modifiche non documentate	Tracciare l'effort rispetto ai work package; indagare sugli scostamenti
Il team lavora di notte e nel weekend per recuperare	Il perimetro supera la capacità	Fare escalation al change board; forzare una decisione sul perimetro
Colpe rimpallate tra business, IT e partner	Il perimetro è già sfuggito al controllo	Congelare il perimetro, fare una revisione delle cause radice, ristabilire la baseline

Tutto è collegato

SAP tiene tutto insieme. La finanza influisce sulla supply chain. Le HR toccano la payroll. Le vendite si collegano alle scorte. Una modifica può rompere dieci cose.

Un cliente ha aggiunto un solo campo al processo dell'ordine di acquisto. Sembrava banale. Ha rotto tre interfacce e ha richiesto la riscrittura dei report in più reparti. Un altro cliente ha chiesto una «minuscola modifica» al suo schema di calcolo dei prezzi, che si è rivelata richiedere la riconfigurazione dell'intera struttura dei prezzi: tre settimane di lavoro e 40.000 dollari di costi di consulenza, per una minuscola modifica.

La pressione del «una volta per decennio»

La maggior parte delle aziende implementa SAP una volta ogni 10-15 anni. Ogni reparto sa che non avrà un'altra occasione per un decennio. Nessuno vuole sentir parlare di «fase 2», che nella maggior parte delle organizzazioni significa mai. Così tutto viene spinto nel progetto in corso, e l'elenco del perimetro diventa una lista dei desideri.

Che cosa cambia il Clean Core

Il Clean Core mette un freno tecnico alla personalizzazione. In S/4HANA Cloud Public Edition non è possibile modificare il core: le estensioni passano da API rilasciate, on-stack o side-by-side su SAP BTP. In Private Edition e on-premise la modifica è ancora possibile, ma le indicazioni di SAP la considerano l'ultima risorsa, perché ognuna aggiunge lavoro di upgrade.

Un effetto collaterale utile è la disciplina sul perimetro. Una richiesta del tipo «aggiungiamo solo questo passaggio di approvazione al processo standard order-to-cash» smette di essere una chiacchierata informale di configurazione e diventa un'estensione con un proprio costo di design, sviluppo e test. Metta un forum di revisione delle estensioni sotto lo steering committee, con un architetto che può approvare o respingere, e molte di queste richieste si fermano prima di entrare nella baseline. I programmi on-premise senza quel forum ricadono nei vecchi schemi. La mia guida al Clean Core spiega come impostarne uno.

1. Definire il perimetro con esclusioni esplicite. Documenti ciò che è fuori perimetro con la stessa cura con cui documenta ciò che è dentro, e ottenga l'approvazione su entrambi. L'ambiguità è il punto in cui iniziano le discussioni.
2. Applicare un change control formale con conseguenze. Ogni modifica richiede una valutazione d'impatto su costi, tempi e qualità, visibile a chi approva.
3. Comunicare i confini del perimetro a ogni steering meeting. Mostri lo stato del perimetro con una semplice vista rosso, giallo, verde. Molta deriva è un malinteso.
4. Scrivere un piano di gestione del perimetro. Stabilisca come le modifiche vengono valutate, approvate, portate in escalation e tracciate, così che ogni filone di lavoro le gestisca allo stesso modo. Il mio template di perimetro per progetti SAP offre una struttura di partenza.
5. Dare priorità con MoSCoW. Must have, Should have, Could have, Won't have (questa volta). Faccia pressione perché i Must Have restino pochi.
6. Tenere sotto controllo di versione ogni decisione. Ogni modifica approvata aggiorna la baseline. Ogni modifica respinta viene registrata con il motivo.
7. Richiedere compromessi. Se arriva un nuovo requisito, qualcos'altro esce. I must-have diventano presto opzionali quando costano qualcosa.

Tre tecniche che ho usato fanno sì che tutto questo regga.

Disciplina della firma. Faccia firmare ai responsabili di business i requisiti approvati. In un programma, un responsabile di business giurava di non aver mai approvato un certo flusso di processo. Abbiamo prodotto il documento con la sua firma e la discussione è finita. La firma non è burocrazia. Impedisce che la stessa discussione ricominci sei mesi dopo.

Mostrare gli effetti a catena. Ho costruito per un cliente una dimostrazione che mostrava come la modifica di un solo campo di un ordine di vendita avrebbe inciso su 14 aree, dal reporting alle interfacce ai ruoli di sicurezza. Il comportamento è cambiato. Educare costa ore. Non capire gli effetti a catena costa mesi.

Mostrare il costo della modifica. Una modifica in fase di design può costare 5.000 dollari. La stessa modifica in fase di test può costarne 50.000. Metta davanti alle persone un semplice grafico di questo e le richieste casuali rallentano.

Questi sono intervalli indicativi del costo della modifica per i programmi S/4HANA sul mercato USA. Variano con la complessità e il partner. Li usi come ancore, non come preventivi.

Fase	Costo tipico di una piccola modifica	Costo tipico di una modifica media
Explore (design)	da 2 a 10 mila $	da 10 a 30 mila $
Realize iniziale	da 5 a 20 mila $	da 20 a 80 mila $
Realize intermedia (sviluppo)	da 15 a 50 mila $	da 50 a 200 mila $
Realize finale (test)	da 30 a 100 mila $	da 100 a 400 mila $
Deploy e cutover	da 80 a 300 mila $	da 300 mila $ a 1 milione $ e oltre
Hypercare (dopo il go-live)	da 150 a 500 mila $	da 500 mila $ a 2 milioni $ e oltre

Lo schema coincide con ciò che la ricerca rileva da decenni. Uno studio della NASA sull'escalation dei costi degli errori ha rilevato che un errore nei requisiti individuato in integrazione e test costava da 21 a 78 volte di più da correggere rispetto a uno individuato durante la fase dei requisiti, e molto di più una volta che il sistema era in esercizio. La governance del perimetro esiste per tenere le modifiche sul lato economico di quella curva.

Clausole contrattuali che contano

I contratti vaghi creano problemi costosi. Ho visto un cliente firmare un contratto che diceva soltanto «implementare S/4HANA». Il partner ha poi sostenuto che certi processi erano add-on soggetti a costi aggiuntivi, e il cliente ha finito per pagare il doppio. Queste clausole lo evitano:

Clausola	Scopo
Perimetro con esclusioni esplicite	Limita ciò che copre il prezzo fisso ed elimina l'ambiguità sugli add-on
Tariffe concordate in anticipo per le modifiche comuni	Blocca i prezzi di report, interfacce e modifiche di configurazione prima che arrivi la pressione
Continuità dei consulenti	Impedisce che nuovi consulenti riaprano decisioni già chiuse e allarghino il perimetro
Autorità di approvazione su entrambi i lati	Impedisce che consulenti junior promettano funzionalità che nessuno ha autorizzato
Fatturazione a milestone	Lega il pagamento ai deliverable approvati, non al tempo trascorso
Criteri di accettazione per ogni deliverable	Definisce il «completato» prima che qualcuno ne discuta
Clausola sulle estensioni Clean Core	Richiede che le estensioni usino API rilasciate o SAP BTP; evita rilavorazioni al primo upgrade importante

I miei appunti sulla negoziazione dei contratti ERP spiegano come far concordare queste clausole.

Change control board

Un change board funziona quando ha le persone giuste. Il mio lo costruisco con tre ruoli: un decisore di business che si preoccupa della funzione, un project manager che si preoccupa della timeline e un responsabile finanziario che si preoccupa del budget. Questo equilibrio impedisce che una sola priorità domini.

1. 01Richiesta presentataPer iscritto, non davanti a un caffè
2. 02Valutazione d'impattoTempi, costi e qualità, prima che qualcuno approvi
3. 03Compromesso definitoQualcos'altro esce per fare spazio
4. 04Il change board decideBusiness, progetto e finanza al tavolo
5. 05Baseline aggiornataModifiche respinte registrate con il motivo

Il perimetro si muove solo attraverso il board

Il board ha bisogno di vera autorità. In un programma nessuna modifica di perimetro è avvenuta senza la sua approvazione. Nemmeno una. Gli accordi in corridoio sono finiti. Quando il VP vendite ha provato a infilare nuovi requisiti, il team aveva una matrice di approvazione documentata a cui fare riferimento.

La maggior parte delle decisioni dovrebbe restare a livello di board. Solo le vere controversie vanno allo sponsor, il che lo mantiene coinvolto senza sommergerlo. Tenga una revisione del perimetro con i responsabili dei filoni di lavoro ogni due settimane e riporti le richieste presentate, approvate e respinte. Quando le persone vedono «crescita del perimetro del 15% questo mese» in un report di stato, il comportamento cambia.

Alcune modifiche sono necessarie. Un mio cliente farmaceutico è stato colpito da nuove normative FDA a implementazione in corso. Dovevano entrare. Non è scope creep. È la realtà.

Quando arriva una modifica legittima, faccia due domande. Qual è la correzione più piccola che funzionerà? E, a chi la chiede: che cosa è disposto a togliere per fare spazio? L'urgenza cala in fretta quando una richiesta costa qualcosa.

Le opzioni sono estendere la timeline, aggiungere budget, tagliare altri requisiti, aggiungere persone, o un mix. Qualunque cosa scelga, la documenti e aggiorni tutti i documenti di baseline in una volta. I documenti obsoleti creano il prossimo round di problemi di perimetro.

Oggi l'AI aiuta con la parte documentale. Assistenti come Microsoft Copilot riassumono lunghe catene di richieste di modifica in una sintesi pronta per la decisione del board, e SAP Cloud ALM mantiene collegati requisiti, modifiche e test, così l'impatto di una modifica è più facile da tracciare. L'AI può mostrare che una modifica tocca 14 aree. Non può dire al COO che la sua richiesta significa che quella del CFO non si farà. Quella conversazione resta sua.

Un'azienda manifatturiera con cui ho lavorato ha concluso il progetto SAP nei tempi, cosa più rara di quanto dovrebbe. Ha fissato presto una data di scope freeze, e qualunque modifica successiva richiedeva l'approvazione personale del CEO. Il progetto si è chiuso con budget residuo, e al go-live nessuno lavorava nei weekend.

Un altro cliente ha usato un sistema a gettoni: a ogni reparto erano assegnati tre gettoni di modifica per l'intero progetto. Vuole una modifica? Spenda un gettone. Le persone hanno riflettuto a fondo su ciò che contava, e i «must-have» sono stati riconsiderati quando sono costati una valuta limitata.

Nessuno dei due approcci è complicato. Entrambi richiedono disciplina e il sostegno della leadership. Il test di qualsiasi processo di perimetro è il giorno in cui il COO entra nella sala di progetto con «solo una piccola modifica». Lo costruisca per quel giorno.

Che cos'è lo scope creep in un progetto SAP?

La crescita graduale e incontrollata dei requisiti senza adeguamenti corrispondenti di timeline, budget o risorse. In SAP di solito inizia con piccole aggiunte: report in più, campi in più, «solo una piccola modifica al workflow». Ognuna sembra innocua. Insieme aggiungono mesi.

Le modifiche di perimetro legittime seguono un processo e arrivano con aggiustamenti di timeline e budget. Lo scope creep arriva in modo informale e aggira il change control.

Quali sono le cause più comuni dello scope creep nei progetti SAP?

Ne emergono costantemente tre: requisiti iniziali vaghi, per cui di qualsiasi cosa si può sostenere che rientri nel perimetro; nessun change control formale, per cui le modifiche si infilano a ogni livello; e la mentalità del «una volta per decennio», in cui ogni reparto cerca di risolvere anni di problemi in questo progetto.

L'interconnessione di SAP amplifica tutte e tre. Una modifica può rompere dieci processi collegati e, se i responsabili di business non vedono quei collegamenti, l'impatto emerge nei test, quando costa molte volte di più.

In che modo il Clean Core cambia il rischio di scope creep?

Aggiunge un freno tecnico. In S/4HANA Cloud Public Edition il core non si può modificare, quindi ogni gap diventa un'estensione con un proprio costo di design, sviluppo e test. In Private Edition e on-premise la modifica è possibile ma aggiunge lavoro di upgrade, perciò le indicazioni di SAP la sconsigliano.

Un forum di revisione delle estensioni, con un architetto che ha l'autorità di decidere, ferma molte richieste prima che entrino nella baseline. Senza quel forum, i programmi on-premise ricadono nelle vecchie abitudini.

Qual è la differenza tra scope creep e gold-plating?

Lo scope creep viene dal business: richieste oltre ciò che era stato concordato. Il gold-plating viene dal team di delivery: complessità che nessuno ha chiesto.

In termini SAP, il gold-plating è un consulente che costruisce una logica di workflow elaborata dove basterebbe un semplice instradamento. Lo scope creep è il COO che chiede funzioni avanzate di magazzino sei mesi dopo l'avvio di un progetto con perimetro limitato alla gestione materiali di base. Entrambi gonfiano costi e tempi, ed entrambi richiedono la stessa disciplina.

Come si struttura un processo di change control che funziona davvero?

Tre elementi. Ogni richiesta porta con sé una valutazione d'impatto su timeline, budget e risorse. Il board di approvazione include qualcuno che si preoccupa di ciascuno di questi tre aspetti, non solo i responsabili di business, che approverebbero tutto. E ogni aggiunta richiede un compromesso: qualcos'altro esce.

Quest'ultima regola da sola filtra le richieste che non sono davvero critiche.

Si può evitare del tutto lo scope creep?

No. In qualsiasi programma più lungo di pochi mesi le condizioni di business cambiano, le normative cambiano e il design fa emergere lacune.

L'obiettivo è il controllo, non l'eliminazione. Il cambiamento controllato segue un processo documentato, viene valutato per l'impatto e aggiorna la baseline. Il cambiamento incontrollato aggira il processo ed emerge nei test o dopo il go-live come un costo che nessuno aveva pianificato.

Qual è il modo migliore di gestire lo scope freeze in un programma SAP lungo?

Dargli una conseguenza e un sostegno visibile del vertice. La versione più efficace che ho usato: la data di freeze è nel project charter fin dal primo giorno, il processo di modifica definisce che cosa significa «freeze» in pratica, e lo sponsor lo ribadisce pubblicamente allo steering prima che la data arrivi.

Quando il CEO deve approvare personalmente ogni modifica dopo il freeze, l'elenco resta cortissimo.