Come creare un project charter per un'implementazione SAP

Un project charter per l'implementazione SAP è il documento breve che autorizza formalmente il programma. Stabilisce per iscritto che cosa il programma consegnerà e che cosa no, chi decide, come si misura il successo e entro quando. Lo scriva prima che vengano firmati gli statement of work dei fornitori, ne affidi la titolarità allo sponsor del cliente e lo renda abbastanza specifico da chiudere una discussione. Qui sotto trova uno schema sezione per sezione.

I team entrano nei kick-off SAP con sicurezza. Poi scoprono che i ruoli erano definiti in modo vago, che i confini del perimetro non sono mai stati concordati e che nessuno sa dire che aspetto abbia il successo. Un charter dovrebbe evitarlo. La maggior parte dei charter non ci riesce, perché nasce per soddisfare un requisito di governance e non per dare un ancoraggio al lavoro.

Ho visto project charter dall'aspetto ordinato che non si collegavano ai piani reali. La versione che funziona è quella su cui le persone discutono mentre la si scrive. È così che si capisce che è onesta.

In ogni grande programma SAP si confondono tre documenti. Svolgono compiti diversi.

Documento	Scopo	Redatto da	Quando
Proposta di progetto	Giustificare perché il progetto debba partire	Sponsor di business	Prima dell'approvazione
Project charter	Autorizzare il progetto; fissare perimetro, obiettivi, responsabili indicati per nome e governance	Sponsor insieme al program manager	All'avvio
Piano di progetto	Definire come si svolge il lavoro: attività, risorse, dipendenze	Program manager	Dopo l'approvazione del charter

Il charter è il documento di governance. Traccia i confini. Se il suo programma S/4HANA copre più moduli, paesi e fornitori, è nel charter che si decide che cosa è incluso, prima che ognuno cominci a fare le proprie ipotesi.

Obiettivi legati a un risultato di business

Non «ammodernamento dei sistemi». Ogni obiettivo ha bisogno di un numero. Il test: riesce a spiegare la visione a un membro del consiglio di amministrazione in 30 secondi, senza slide?

Ho lavorato a programmi SAP in cui al go-live tutti hanno festeggiato e due mesi dopo nessuno sapeva dire se avessero portato il valore promesso. Un cliente manifatturiero ha speso oltre 4 milioni di dollari e non è riuscito a dimostrare alcun ritorno. Il CFO ha chiesto delle metriche. Nessuno le aveva, e questo ha fatto slittare il successivo round di finanziamento.

Lo confronti con un cliente retail che ho affiancato. Il suo charter definiva i KPI fin dal primo giorno. Hanno mostrato un calo del 32% dei costi di elaborazione degli ordini, e la fase 2 è stata approvata subito.

Perimetro con esclusioni esplicite

È la sezione più trascurata. I team scrivono elenchi dettagliati di ciò che rientra nel perimetro e omettono le esclusioni, ed è proprio lì che nascono le discussioni.

Ho lavorato con un'azienda sanitaria che ha mantenuto così il proprio rollout SAP concentrato sull'essenziale. Il responsabile marketing voleva aggiungere analytics per il monitoraggio delle campagne durante il test di accettazione utente (UAT). Il charter non lasciava spazio a questa richiesta e lo steering committee l'ha segnalata subito. Quella sola decisione ha fatto risparmiare 850.000 dollari ed evitato un ritardo di sei settimane.

Persone indicate per nome, non reparti

«Team Finance: fornisce input sul reporting» non rende responsabile nessuno. «Responsabile Finance, [nome]: definisce i requisiti di reporting, approva formalmente la configurazione FI/CO, dà il via libera alla preparazione della migrazione dei dati» sì.

Milestone come impegni

Un cliente retail ha rinviato il go-live di quattro mesi. All'origine c'era uno slittamento di tre settimane nella raccolta dei requisiti che nessuno ha riportato nel piano. Hanno dato per scontato di poterlo recuperare più avanti. Invece hanno speso 1,8 milioni di dollari in sforamenti.

Funziona anche al contrario. In un incarico nel manifatturiero il team si è attenuto al piano pubblicato. Quando il team di migrazione dei dati ha segnalato un ritardo, lo steering committee ha autorizzato subito un rinforzo di personale, perché il charter rendeva visibile la milestone. Quella decisione ha fatto risparmiare sia tempo sia 600.000 dollari.

Budget, rischi e dipendenze

Un budget di alto livello, i tre o quattro rischi che potrebbero far deragliare il programma e gli altri programmi che si contendono le stesse persone e lo stesso denaro. Un cliente retail ha speso 3,2 milioni di dollari per un'implementazione che non è mai andata live. La riprogettazione della finanza e il progetto SAP sono andati avanti in parallelo con le stesse risorse e nella stessa finestra di budget, e nessuno dei due charter citava l'altro. La direzione se n'è accorta troppo tardi.

È la struttura da cui partirei. Ogni sezione dovrebbe stare in una pagina o meno.

1. Scopo e contesto: perché adesso, che cosa non funziona, che cosa succede se non si fa nulla.
2. Obiettivi e misure di successo: ogni obiettivo con un valore di partenza, un target e una data.
3. Perimetro: moduli, processi, entità legali, paesi, sedi, integrazioni e dati inclusi.
4. Fuori perimetro: scritto con la stessa cura del perimetro, indicando la fase a cui è rinviata ogni voce esclusa.
5. Modello di deployment e regole di estensione: S/4HANA Cloud Public Edition, Private Edition con RISE oppure on-premise, e come verrà approvato lo sviluppo custom.
6. Governance: sponsor, steering committee, design authority, change control, percorso di escalation, con persone indicate per nome.
7. Ruoli e responsabilità: persone indicate per nome per ogni area di processo, dati, test, change e cutover.
8. Milestone: gate di fase con date e criteri per superarli. La mia guida ai quality gate contiene degli esempi.
9. Budget e contingency: il plafond, la contingency e chi può rilasciarla.
10. Rischi, assunzioni e dipendenze: compresi i programmi paralleli e le scadenze normative.
11. Requisiti di compliance: per esempio HIPAA nella sanità statunitense, GxP nel farmaceutico, SOX per le società quotate negli Stati Uniti.
12. Approvazione: sponsor e responsabili di business, con numero di versione e data.

1. 01Chiedere a chi conosce il lavoroSponsor, responsabili di business e utenti finali
2. 02Separare l'indispensabile dal desiderabileNecessario per il go-live, fase 2 o fuori da questo progetto
3. 03Partire da un templatePoi aggiungere integrazione, dati e compliance
4. 04Essere abbastanza specifici da chiudere le discussioniSi può dimostrare che ogni obiettivo è stato raggiunto?
5. 05Ottenere una firma veraLetta, messa in discussione e accettata, sezione per sezione

Un charter a cui rifarsi quando il perimetro viene contestato al terzo mese

1. Chiedere a chi conosce il lavoro

Prima di scrivere qualsiasi cosa, si sieda con sponsor, responsabili di business e utenti finali. Chieda che cosa non funziona e che cosa è già stato provato. Una volta ho lavorato con un cliente manifatturiero che ha sprecato 1,8 milioni di dollari in un'implementazione SAP perché dava per scontato di sapere di che cosa avesse bisogno il reparto produzione. Dopo sei mesi ha scoperto che i veri problemi di flusso di lavoro non venivano affrontati.

In una trasformazione della finanza a cui ho lavorato, l'IT pianificava di introdurre SAP per risolvere problemi di efficienza. Le conversazioni con la finanza hanno mostrato che il vero problema era la scarsa qualità dei dati. Se non l'avessimo chiesto, avremmo speso milioni per risolvere il problema sbagliato.

2. Separare l'indispensabile dal desiderabile prima di scrivere il perimetro

Classifichi ogni input come necessario per il go-live, da rinviare alla fase 2 oppure fuori da questo progetto. Un mio cliente di servizi professionali ha sforato il budget del 40% perché i requisiti stavano in tre posti diversi e continuavano a essere «riscoperti» a mesi dall'avvio del progetto. La mia guida al template del perimetro aiuta in questo passaggio.

3. Partire da un template, poi aggiungere le specificità SAP

Un template generico non coglie ciò che rende costosi i programmi SAP: i punti di integrazione, la responsabilità della migrazione e della bonifica dei dati, le assunzioni sui moduli, i requisiti di compliance e le regole per lo sviluppo custom. Ho sentito parlare di un progetto SAP partito con un charter generico che non menzionava mai la pulizia dei dati. Dopo sei mesi i dati legacy si sono rivelati un disastro, con 750.000 dollari e tre mesi in più.

4. Essere abbastanza specifici da chiudere le discussioni

Ho guidato l'implementazione per un cliente retail a Singapore il cui charter diceva «modernizzare la gestione delle scorte». Metà del team pensava che significasse un'elaborazione più rapida. L'altra metà si è concentrata sulle previsioni. Il risultato: 1,8 milioni di dollari spesi e nessun accordo su che cosa fosse il successo. Per ogni obiettivo, si chieda: posso dimostrare che è stato portato a termine?

5. Ottenere una firma vera

Il charter è finito quando chi lo firma lo ha letto, lo ha messo in discussione e ha accettato gli impegni che contiene. Lo ripercorra con lo sponsor e i responsabili di business sezione per sezione. Ho visto clienti retail dedicare tre giorni interi all'allineamento sul charter. Ha fatto loro risparmiare mesi di discussioni e di modifiche al perimetro in seguito.

Errore	Che cosa provoca	Che cosa fare invece
Obiettivi vaghi («migliorare l'efficienza»)	I team tirano in direzioni diverse	Mettere un numero su ogni obiettivo
Nessuna esclusione	Il perimetro cresce in silenzio	Scrivere l'elenco del fuori perimetro con la stessa cura del perimetro
Responsabili indicati solo per ruolo o reparto	Le decisioni vengono rinviate	Indicare le persone per nome
Nessuna misura di successo	Si festeggia il go-live, il valore non viene mai dimostrato	Definire i KPI prima del kick-off
Programmi paralleli non mappati	Collisioni su risorse e budget	Registrare le dipendenze in entrambi i charter
Charter scritto dal partner di implementazione	Il perimetro riflette ciò che il partner vuole consegnare	Il cliente ne è proprietario; il partner contribuisce con i dettagli

Sull'ultimo punto sono fermo. Il partner di implementazione non deve scrivere il suo charter. L'incentivo del partner è avviare il progetto. Il Suo è definirne il perimetro.

Con RISE with SAP (Private Edition) aggiunga due elementi alla sezione sulla governance. Primo, un forum di approvazione del Clean Core. SAP oggi classifica le estensioni dal livello A, solo API rilasciate, al livello D, modifiche (SAP News, agosto 2025). La Private Edition consente ancora di modificare il core, quindi è il forum a impedire che si accumuli debito tecnico. Secondo, un percorso di escalation verso SAP. Con RISE è SAP a gestire l'infrastruttura e le operazioni tecniche. Il CIO deve sapere chi chiamare in SAP quando qualcosa si guasta a livello di piattaforma, non solo presso il partner.

Con GROW with SAP (Public Edition) il charter si accorcia. Le estensioni sono limitate alle interfacce rilasciate, quindi è la piattaforma a imporre il Clean Core al posto suo, e le opzioni di integrazione sono più ristrette. Visione, misure di successo, responsabili indicati per nome ed esclusioni contano altrettanto.

Gli strumenti di AI possono trasformare più in fretta gli appunti delle interviste in una prima bozza. Non possono fare il lavoro politico del charter, cioè far concordare agli sponsor ciò di cui ciascuno è titolare.

Che cos'è un project charter in un'implementazione SAP?

Il documento che autorizza formalmente il programma SAP. Definisce il perimetro e le esclusioni, indica lo sponsor e le persone responsabili, stabilisce le misure di successo, fissa milestone e governance ed elenca i rischi principali. Un charter utile è abbastanza specifico da risolvere un disaccordo sul perimetro o sulla titolarità.

Che cosa deve contenere un project charter SAP?

Scopo, obiettivi con target misurabili, perimetro, esclusioni esplicite, modello di deployment e regole di estensione, governance con persone indicate per nome, ruoli, milestone con criteri di gate, budget e contingency, rischi e dipendenze, requisiti di compliance e approvazione. Lo schema qui sopra illustra ogni sezione.

Qual è la differenza tra un project charter e un piano di progetto?

Il charter autorizza e definisce: perimetro, sponsor, governance e milestone di alto livello. Il piano esegue: attività, dipendenze, risorse e sequenza. Un piano senza charter va alla deriva, perché il perimetro non è mai stato concordato. Ogni impegno del piano dovrebbe poter essere ricondotto al charter.

Chi dovrebbe scrivere il project charter SAP?

Ne è proprietario lo sponsor del cliente e lo redige il program manager, con i responsabili di finanza, IT e operations che forniscono i dettagli. Sconsiglio di lasciarlo scrivere al partner di implementazione. Il suo incentivo è avviare il progetto, non proteggerla da un perimetro di cui non ha bisogno.

Come cambia il project charter con RISE with SAP?

Aggiunga un forum di approvazione del Clean Core che decide quali estensioni sono ammesse e a quale livello. Aggiunga un percorso di escalation verso SAP per i problemi di piattaforma, dato che con RISE è SAP a gestire l'infrastruttura. Con GROW with SAP il charter è più leggero, perché la Public Edition impone tecnicamente il Clean Core.

Il project charter può cambiare durante l'implementazione?

Sì, attraverso il change control. Lo tratti come una baseline. Quando cambiano il perimetro, lo sponsor, il budget o una milestone importante, lo aggiorni con un numero di versione, una nota su che cosa è cambiato e perché, e una nuova approvazione. Non lo lasci rivedere in silenzio ogni volta che il progetto va fuori rotta.