Template del perimetro di un progetto SAP: cosa definire ed escludere

Un template di perimetro per un progetto SAP definisce che cosa il programma consegnerà, che cosa non consegnerà di proposito, chi è responsabile di ciascuna parte e come il perimetro può cambiare. Le nove sezioni qui sotto lo coprono. Le due più importanti sono quelle che i team saltano: le esclusioni esplicite e il perimetro della migrazione dei dati. Compili il template prima che inizi la configurazione e lo faccia firmare dallo sponsor e dai responsabili di processo.

A volte i team compilano un template di perimetro e passano oltre. Quella parte sembra facile. Settimane dopo, in fase di progettazione o di realizzazione, qualcuno segnala un processo che era «dato per incluso nel perimetro». La conversazione diventa scomoda. Nessuno l'aveva scritto. Nessuno voleva lasciarlo fuori. Ho visto succedere questo troppe volte. Poche ipotesi non verificate all'inizio fanno slittare il progetto di settimane, in silenzio.

Il compito del documento di perimetro non è registrare ciò che le persone hanno detto in sala. È imporre chiarezza prima che la configurazione fissi ipotesi costose da annullare.

Queste sono le nove sezioni, con ciò a cui ciascuna deve rispondere.

1. Obiettivi

Perché si fa questo lavoro e che cosa vedrà il business quando sarà finito? Colleghi ogni obiettivo a un risultato misurabile: ridurre di tre giorni la chiusura mensile, eliminare le riconciliazioni manuali su tre entità, una vista unica delle scorte su tutti i plant. Obiettivi vaghi producono criteri di successo vaghi, e il disaccordo emerge nel test di accettazione utente (UAT).

2. Definizione del perimetro

Moduli, entità giuridiche, plant, paesi, lingue, integrazioni e modello di deployment. Sia preciso. «Finance» non è un perimetro. «Contabilità finanziaria e controlling (FI/CO) che copre contabilità fornitori, contabilità clienti, contabilità generale e contabilità dei centri di costo per l'entità giuridica degli Emirati Arabi Uniti su S/4HANA Cloud Private Edition» è un perimetro.

3. Esclusioni

È qui che la maggior parte dei template di perimetro fallisce. Se qualcosa non è scritto come escluso, qualcuno darà per scontato che sia incluso. Esclusioni da scrivere per nome:

1. Paesi o entità rinviati a una fase successiva.
2. Integrazioni legacy mantenute così come sono, per ora.
3. Dati storici precedenti a una data di cutoff definita.
4. Report spostati in un elenco di evolutive post go-live.
5. Requisiti normativi rinviati in attesa di conferma legale.

Indichi per ogni esclusione la fase in cui viene spostata, se c'è. Un'esclusione firmata trasforma una discussione di due settimane in una breve conversazione.

4. Perimetro della migrazione dei dati

Un punto cieco costante. Risponda per iscritto a tre domande:

1. Che cosa viene migrato? Solo le partite aperte, o anche lo storico? Tutti i clienti e i fornitori, o solo quelli attivi? I materiali di ogni plant, o solo quelli delle entità del go-live?
2. Quali sono le regole di cutoff? La data di riferimento per gli ordini di acquisto, di vendita e di lavoro aperti, e che cosa succede agli elementi in corso al momento del cutover.
3. Che cosa viene archiviato invece? Le regole legali di conservazione per lo storico e per quanto tempo il sistema legacy resta consultabile.

Le ipotesi lasciate non documentate qui diventano controversie durante la realizzazione. Il mio articolo su perché la migrazione dei dati SAP fallisce approfondisce la pianificazione.

5. Perimetro non funzionale

In pianificazione vengono lasciati cadere e poi emergono come elementi bloccanti, a test ormai avanzati. Li inserisca nel perimetro:

1. Disponibilità e finestra di manutenzione. In RISE, faccia riferimento ai termini di disponibilità del suo contratto.
2. Prestazioni al picco di carico, per esempio la chiusura mensile.
3. Audit logging: quali transazioni vengono tracciate e per quanto tempo si conservano i log.
4. Sicurezza e controllo degli accessi per ruolo.
5. Latenza del reporting: in tempo reale, quasi in tempo reale o giornaliera.

Non sono funzionalità. Sono vincoli che il sistema deve rispettare. Se non sono nel perimetro, nessuno li progetta.

6. Ruoli e responsabilità

Ogni workstream ha bisogno di un responsabile lato consulenza e di una controparte di business con potere decisionale, entrambi indicati per nome. La lacuna che vedo più spesso riguarda la responsabilità sull'UAT: chi può firmare che un processo è stato testato e accettato? Lo decida prima che inizi la realizzazione, non due settimane prima del go-live.

7. Controllo delle modifiche

Non «le modifiche richiedono un'approvazione formale». Un processo preciso: che cosa genera una richiesta di modifica, chi ne valuta l'impatto su tempi e budget, chi approva e che cosa viene registrato. Senza di esso, «possiamo aggiungere anche questo?» diventa «pensavamo fosse incluso» e poi una proroga di tre settimane che nessuno aveva pianificato.

8. Regole di estensione

Come verranno approvati gli sviluppi custom. SAP classifica ora le estensioni dal livello A, solo API rilasciate, al livello D, modifiche al core (SAP News, agosto 2025). Su Public Edition in GROW il sistema consente solo interfacce rilasciate. Su Private Edition in RISE e on-premise il core può ancora essere modificato, quindi il perimetro deve indicare il livello obiettivo e chi approva le eccezioni. La mia guida al clean core spiega i livelli.

9. Ipotesi e vincoli

Elenchi le ipotesi su cui poggia il perimetro, così che qualcuno debba verificarle. Poi i vincoli: scadenze normative che fissano una data di go-live, tetti di budget, persone disponibili solo part-time e date di dismissione dei sistemi legacy.

La personalizzazione è la forma di scope creep che ci mette più tempo a mostrarsi. Un report custom approvato diventa cinque. Un'eccezione a un workflow diventa il precedente per ogni richiesta successiva.

Classifichi ogni richiesta prima di approvare qualunque cosa:

Categoria	Criterio	Che cosa fare
Essenziale	Il processo non può funzionare, per legge o operativamente, senza di essa	Approvare, con l'estensione più economica che sia sicura per gli upgrade
Importante, non critica	Migliora l'efficienza ma non è bloccante	Approvare solo con un'analisi costi-benefici chiara
Non necessaria	Una preferenza, o la copia di come funzionava il sistema legacy	Metterla in discussione, poi respingerla o rinviarla

La maggior parte delle personalizzazioni non necessarie esiste perché qualcuno non voleva cambiare il proprio modo di lavorare, non perché SAP non potesse supportare il processo. E il costo di realizzazione è solo l'inizio. Ogni oggetto custom aggiunge test, formazione, documentazione e lavoro di upgrade per tutto il tempo in cui esiste.

Fissi un change freeze. Scelga una data, di solito da quattro a sei settimane prima del go-live, dopo la quale non si accettano nuove richieste per quel rilascio. Tutto ciò che arriva dopo va nel backlog post go-live. Il freeze ha bisogno della firma del comitato direttivo. Una data annunciata solo dal project manager verrà scavalcata la prima volta che un responsabile di funzione farà pressione.

1. 01Richiesta presentataChe cosa conta come modifica si definisce in anticipo
2. 02ClassificataEssenziale, importante o non necessaria
3. 03Impatto valutatoTempi e budget, a cura di un valutatore indicato per nome
4. 04DecisioneUn approvatore indicato per nome approva, respinge o rinvia
5. 05Perimetro versionatoNuovo numero di versione e un elenco di ciò che è cambiato

Dopo il change freeze, le nuove richieste vanno nel backlog post go-live

L'analytics è il punto in cui le conversazioni sul perimetro si scaldano. Tutti vogliono report e nessuno dice quanti.

Concordi un elenco fisso di report durante la progettazione. Chieda alle persone di che cosa hanno bisogno, non che cosa potrebbero desiderare. Indichi per ogni report se è un output standard SAP o uno sviluppo custom e faccia firmare l'elenco insieme al resto del perimetro. I report standard costano una frazione di quelli custom. Individui nello stesso momento le fonti dati di ciascun report: un report che attinge a tre sistemi è un requisito di integrazione. Se dashboard e pianificazione rientrano nel perimetro, la mia guida a SAP Analytics Cloud spiega che cosa chiarire per primo.

Errore	Che cosa provoca	Come evitarlo
Obiettivi non misurabili	Dispute in UAT su che cosa significhi «funzionante»	Fissare risultati misurabili all'inizio
Esclusioni non scritte	Lavoro assorbito senza approvazione	Elencare per nome ciò che è fuori perimetro
Perimetro della migrazione dei dati vago	Volumi sbagliati, cutover in ritardo, rilavorazioni	Definire che cosa viene migrato, i cutoff e l'archiviazione
Requisiti non funzionali assenti	Problemi di audit e di prestazioni al go-live	Mettere nel perimetro disponibilità, prestazioni, logging e sicurezza
Nessun responsabile UAT indicato per nome	I test si trascinano, nessuno può firmare	Indicare persone con autorità decisionale
Nessun controllo delle modifiche	Aggiunte informali, test compressi	Scrivere il processo di modifica nel perimetro
Nessuna firma di approvazione	Perimetro contestato più avanti senza responsabilità	Sponsor e responsabili di processo firmano
Analytics rimandata a dopo	Richieste di report due settimane prima del go-live	Concordare l'elenco dei report durante la progettazione
Modello di deployment o regole di estensione aperti	Il dibattito si trascina fino alla fase di realizzazione	Decidere entrambi prima della firma del perimetro

Riesamini il perimetro a ogni phase gate di SAP Activate e dopo ogni modifica approvata, con un numero di versione e un elenco di ciò che è cambiato. Il perimetro va richiamato per riferimento nel project charter, così i due documenti raccontano la stessa storia.

Che cosa deve includere un template di perimetro per un progetto SAP?

Nove sezioni: obiettivi con risultati misurabili, definizione del perimetro (moduli, entità, paesi, integrazioni, modello di deployment), esclusioni esplicite, perimetro della migrazione dei dati, requisiti non funzionali, ruoli indicati per nome, controllo delle modifiche, regole di estensione, e ipotesi con vincoli. Le esclusioni sono la sezione che manca più spesso.

Come si previene lo scope creep nei progetti SAP?

Scrivendo le esclusioni in modo esplicito, facendo passare ogni modifica da una richiesta formale con valutazione dell'impatto e un approvatore indicato per nome, classificando le personalizzazioni prima di approvarle e fissando un change freeze firmato da quattro a sei settimane prima del go-live. L'obiettivo non è rifiutare ogni cambiamento. È rendere le modifiche visibili, valutate e autorizzate.

Che cos'è il perimetro della migrazione dei dati in un progetto SAP?

La definizione di quali dati confluiscono in SAP e con quali regole: quali oggetti (clienti, fornitori, materiali, ordini aperti, storico), le date di cutoff e che cosa viene archiviato invece di essere migrato. Determina impegno e tempi, e decide per quanto tempo i sistemi legacy devono restare accessibili.

Che cos'è il perimetro non funzionale nei progetti SAP?

I vincoli che il sistema deve rispettare, a differenza dei processi che supporta: disponibilità, prestazioni al picco di carico, audit logging, sicurezza e controllo degli accessi, latenza del reporting. Spesso vengono lasciati fuori dal perimetro e poi scoperti durante i test. Nei settori regolamentati, l'audit logging è un obbligo di legge.

Come vanno gestite le personalizzazioni nel perimetro?

Classificando ogni richiesta come essenziale, importante o non necessaria. Per ciascuna richiesta approvata si registrano il requisito, il motivo per cui lo standard SAP non lo soddisfa, l'impegno, l'impatto sui test, il costo di manutenzione e l'approccio di estensione. Su Private Edition e on-premise si indicano il livello clean core obiettivo e chi approva le eccezioni.

Quando va riesaminato il perimetro di un progetto SAP?

A ogni phase gate di SAP Activate, dopo ogni richiesta di modifica approvata e ogni volta che cambiano budget, risorse o tempistiche. Si conserva ogni versione con una data, un numero di versione e una sintesi di ciò che è cambiato. Questa cronologia protegge il team quando il perimetro viene contestato più avanti.