Implementazione SAP e rollout: differenze e quando sceglierli

Un'implementazione SAP costruisce il sistema dove non ce n'è uno. Un rollout prende un sistema SAP che già gira da qualche parte nel gruppo e lo estende a un nuovo paese, a una nuova entità o a una nuova business unit. Quasi tutti pensano che un rollout sia solo un'implementazione più piccola. Questa convinzione causa più rilavorazioni, su questi programmi, di qualsiasi decisione tecnica.

Una volta ho lasciato credere a un CFO che un rollout SAP regionale sarebbe stato plug-and-play. Gli ho spiegato i rischi, ma non ho insistito. Usavamo un template globale e lui dava per scontato che ogni sede si sarebbe allineata senza grande fatica. Non è andata così. Una regione richiedeva una gestione fiscale aggiuntiva. Un'altra aveva campi obbligatori sui dati dei dipendenti per via delle leggi locali. Quello che sembrava un copia e incolla ha richiesto vera personalizzazione.

La scelta cambia quindi il modo in cui si assegnano le risorse, si costruisce il budget e si conduce il lavoro. Se si sbaglia, il sistema può comunque andare in produzione, ma non come era stato pianificato.

Un'implementazione parte da zero. Si definiscono il perimetro, si mappano i processi, si configura, si migrano i dati e si costruiscono le integrazioni. Vale quando un'organizzazione non ha SAP, oppure sostituisce del tutto un sistema legacy.

Un rollout riutilizza un design che già funziona: processi, configurazione, standard dei dati anagrafici. Il lavoro sta nel divario tra quel template e ciò che serve alla nuova sede. Fiscalità, reportistica statutaria, valute, lingue, integrazioni locali e le persone che lo useranno.

1. 05Utenti localiFormazione adattata al processo locale, nella lingua locale
2. 04Integrazioni localiBanche, sistemi di dichiarazione fiscale e di logistica nel nuovo paese
3. 03Dati localiDati di clienti, fornitori e materiali mappati sugli standard globali
4. 02Requisiti localiImposte, reportistica statutaria e campi obbligatori. Solo requisiti, non preferenze
5. 01Template globaleProcessi, configurazione e standard dei dati anagrafici che già funzionano

Ecco come i due approcci si confrontano nella pratica:

Ambito	Implementazione SAP	Rollout SAP
Punto di partenza	Nessun SAP, oppure un sistema legacy da sostituire	SAP già operativo nella sede centrale o in un'altra entità
Design	Nuovo design, fit-to-standard	Template globale con scostamenti locali controllati
Durata tipica	Da 12 a 24 mesi, di più per i grandi gruppi	Da 6 a 12 mesi per sede
Rischio principale	Incognite su ogni filone di lavoro	Localizzazione e prontezza locale
Dati	Caricamento completo dai sistemi legacy	Dati locali mappati sugli standard dei dati anagrafici globali
Test	Ciclo completo: unit test, integrazione, UAT, prestazioni	Localizzazione, interfacce locali, UAT
Change management	Programma completo da zero	Materiali esistenti adattati ai team locali

Un'implementazione è indicata quando:

1. L'organizzazione non ha mai usato SAP.
2. Il sistema attuale non regge e va sostituito nel suo insieme.
3. Una fusione, un'acquisizione o un nuovo modello operativo rendono superato il vecchio design.
4. Arriva per la prima volta una soluzione di settore, come SAP for Utilities o SAP for Public Sector.
5. Nessun template esistente copre il perimetro che serve.

Le implementazioni richiedono più tempo e costano di più all'inizio. In cambio si ottiene un design che corrisponde al proprio business e un team che capisce ogni scelta che c'è dietro. Le aziende che corrono sui requisiti finiscono per spendere dal 30 al 50 per cento in più per correggere gli errori in seguito. L'ho visto succedere più e più volte.

Un rollout è indicato quando SAP gira già bene da qualche parte nel gruppo, i processi centrali sono stabili e il template è abbastanza flessibile da accogliere i requisiti locali senza rompersi. Se una di queste tre condizioni è fragile, va sistemato il template prima di portarlo altrove.

La parte tecnica di solito si chiude nei tempi. I ritardi nascono dalle persone e da ipotesi che nel nuovo paese non reggono.

Un template imposto ai team locali

Ciò che ha funzionato bene per il Nord America può non bastare in Asia o in Medio Oriente. Strutture fiscali, flussi approvativi e regole di inserimento dei dati sono diversi. Ho lavorato con un'azienda convinta che il proprio template europeo sarebbe andato bene in Medio Oriente. Ha causato ritardi, riscritture e parecchia tensione. I processi di business erano semplicemente troppo diversi.

La soluzione è dare alla nuova sede un business owner con l'autorità di decidere. Quando i team della sede centrale decidono i processi per luoghi che non conoscono, escono design che falliscono al primo contatto con gli utenti locali.

La localizzazione scoperta nei test

Gestione fiscale, report statutari e campi dati obbligatori vanno confermati prima dell'avvio del design. Ho assistito un cliente in cui una semplice differenza nella configurazione fiscale ha ritardato il go-live di oltre un mese. Non era una questione di tecnologia. Nessuno aveva convalidato le esigenze locali abbastanza presto.

Dati anagrafici che non combaciano

Codici prodotto, numeri cliente e classificazioni dei fornitori devono rispettare gli standard globali. I disallineamenti scoperti dopo il go-live costano cari da correggere e rompono il reporting consolidato. I dati locali vanno mappati sul modello globale durante il design, non in UAT.

Una formazione che spiega il sistema globale, non quello locale

I rollout tendono a riutilizzare la formazione dell'implementazione originale. Quel materiale spiega come funziona il sistema nella sede centrale. Non spiega gli adattamenti locali. Gli utenti che non capiscono perché la loro versione è diversa si costruiranno soluzioni di ripiego.

Il quadro appena descritto resta valido. Il modello di deployment del template cambia una parte dei costi e le regole sulle estensioni.

Su RISE with SAP (Private Edition), ogni nuovo paese aggiunge utenti a una sottoscrizione calcolata in full user equivalent (FUE). Il costo è prevedibile e c'è meno lavoro sull'infrastruttura. Il costo, però, continua anche dopo il go-live: conviene quindi confrontare le opzioni su più anni, non solo sul primo.

Su GROW with SAP (Public Edition), si verifica prima di tutto se SAP fornisce una versione locale per il paese. A febbraio 2024 SAP elencava versioni locali per 59 paesi e regioni. Per gli altri paesi, il programma di localizzazione self-service di SAP permette ai partner di costruire una versione locale del cliente con il Configuration Localization Tool, attualmente tramite un percorso early adopter (SAP Learning). Se non vale nessuna delle due strade, si ha un problema di perimetro, non un rollout.

Il Clean Core vale per ogni scostamento locale. La Public Edition accetta estensioni solo tramite interfacce rilasciate. Sulla Private Edition è una scelta di governance, ma ogni modifica locale che si consente è un oggetto in più da ritestare a ogni upgrade, moltiplicato per ogni paese. La disciplina che sostengo è semplice: leggi fiscali, reportistica statutaria e obblighi normativi giustificano uno scostamento. Le preferenze locali no.

Prima di fissare una data per il paese successivo, serve un sì su ciascuno di questi punti. Ognuno ha un responsabile.

1. Business owner locale (nuovo paese): nominato, con l'autorità di approvare il design locale.
2. Consulente fiscale e legale: imposte, reportistica statutaria e campi dati obbligatori documentati prima dell'avvio del design.
3. Responsabile del template (sede centrale): elenco degli scostamenti proposti, ciascuno classificato come requisito o preferenza.
4. Responsabile dei dati: dati locali di clienti, fornitori e materiali mappati sugli standard globali.
5. Responsabile delle integrazioni: sistemi locali da collegare, come banche, dichiarazioni fiscali o logistica, identificati e con perimetro definito.
6. Responsabile del change: formazione adattata al processo locale, nella lingua locale, con esempi locali.
7. Direttore di programma: una sede alla volta, con le lezioni dell'ultimo go-live riportate nel successivo.

La mia guida al template del perimetro di progetto aiuta con il punto 3, e la guida al project charter spiega come mettere per iscritto i diritti decisionali.

Un'implementazione greenfield in Egitto. Un'azienda manifatturiera regionale con sede in Egitto era bloccata con sistemi vecchi e scollegati e molto lavoro manuale. Supply chain, tracciamento della produzione e reportistica finanziaria non comunicavano tra loro. Ha implementato SAP S/4HANA da zero e ha collegato finanza, acquisti e produzione in un unico sistema. Ha impostato una pianificazione automatizzata della supply chain e ha formato oltre 5.000 dipendenti in quattro paesi prima del go-live. Non ha avuto fretta. Ha ridotto i costi operativi del 25 per cento e gli errori di previsione del 35 per cento.

Un rollout in 15 mercati. Un'azienda retail aveva già SAP S/4HANA attivo nella sede centrale e lo voleva in 15 nuovi mercati. Ognuno aveva regole fiscali, valute e prassi commerciali diverse. È partita da un template globale, lo ha adattato per sede, ha fatto il rollout a fasi in due anni anziché tutto insieme e ha costruito la formazione per ciascuna regione. Il risultato: consolidamento finanziario più rapido, tracciamento delle scorte in tempo reale nei negozi e un reporting a livello di gruppo più accurato del 20 per cento.

Uno costruiva qualcosa che non esisteva. L'altro estendeva qualcosa che funzionava. Nessuno dei due è stato plug-and-play. Se è all'inizio del primo tipo di percorso, la mia guida su come avviare correttamente un'implementazione SAP è il punto da cui partire.

Qual è la differenza tra implementazione SAP e rollout SAP?

Un'implementazione costruisce SAP da zero: requisiti, design dei processi, configurazione, migrazione dei dati, integrazione, test e go-live. Un rollout estende un sistema SAP esistente e il suo template globale a un nuovo paese, a una nuova entità o a una nuova business unit. Il lavoro del rollout è il divario tra il template e le esigenze locali: fiscalità, reportistica statutaria, lingua, integrazioni locali e formazione.

Quando un'azienda dovrebbe scegliere l'implementazione invece del rollout?

Si sceglie un'implementazione quando non c'è un SAP da estendere o quando un sistema legacy viene sostituito per intero. È anche la strada migliore quando il modello di business è cambiato al punto che il design esistente non va più bene, o quando nessun template copre il perimetro richiesto. Forzare il rollout di un template sbagliato crea più rilavorazioni di un design pulito.

Quanto dura un rollout SAP rispetto a un'implementazione?

Un'implementazione dura in genere da 12 a 24 mesi, di più per i grandi gruppi. Un rollout dura in genere da 6 a 12 mesi per sede, a seconda di localizzazione, integrazioni e dati. La variabile più importante è quanto bene i requisiti locali sono stati convalidati prima dell'avvio del design.

Quali sono le sfide principali di un rollout SAP in più paesi?

Ne tornano quattro, ogni volta. Template imposti ai team locali senza il loro contributo. Requisiti di localizzazione scoperti durante i test. Dati anagrafici che non rispettano gli standard globali. Formazione che spiega il sistema globale invece di quello locale. La maggior parte sono problemi di persone e di pianificazione più che tecnici.

Un rollout SAP costa sempre meno di un'implementazione completa?

Di solito sì, perché il design esiste già ed è collaudato. Il risparmio si riduce quando un paese ha regole fiscali o di payroll complesse, richiede diverse integrazioni locali o ha dati di scarsa qualità. Con RISE with SAP la sottoscrizione per ogni nuovo paese continua dopo il go-live, quindi conviene confrontare i costi su più anni.

Come funziona un template globale in un rollout SAP?

Il template globale è il design SAP documentato e configurato per i processi standard del gruppo. Ogni rollout parte da lì e aggiunge solo le modifiche locali davvero necessarie. Ogni scostamento crea un onere di manutenzione a ogni upgrade, quindi va governato: i requisiti come la legge fiscale giustificano uno scostamento, le preferenze no.