Quando un gruppo apre uno stabilimento, una società estera o una nuova divisione commerciale, il sistema informativo deve seguirla. Le scelte di metodo, e i criteri per capire quale strada conviene, sono raccolte nel report scaricabile «Migrare a S/4 HANA senza impatti sul business».
Perché ripartire da zero costa più del dovuto
Una nuova unità che implementa SAP come se fosse la prima volta rifa tre lavori già fatti: il disegno dei processi, la configurazione di base e la formazione sui concetti. In più introduce il rischio peggiore per un gruppo, cioè due sedi che lavorano sullo stesso dato in modi diversi, con una consuntivazione che a fine anno non si riconcilia.
Che cos’è un progetto di roll out?
In ambito SAP si parla di roll out quando un modello consolidato viene applicato a un ambito nuovo. Il caso tipico è l’apertura di una società controllata, ma lo stesso vale per strutture interne, dove l’unità organizzativa cambia senza che cambi l’entità giuridica. Quando invece il sistema di partenza è ancora su SAP ERP, la domanda precede il roll out ed è un’altra: la conversion a SAP S/4HANA.
Quali fasi si accorciano rispetto a una nuova implementazione?
Un progetto SAP da zero attraversa analisi, realization, formazione, test e avvio in produzione, secondo le metodologie consolidate. Nel roll out tutte queste fasi restano, ma cambiano di peso: l’analisi verifica invece di disegnare e la realization adatta invece di costruire.
Si accorcia anche la formazione. In un’azienda che usa SAP da anni esistono già utenti esperti, e i key user della sede possono affiancare i colleghi della nuova struttura durante l’avvio. È il motivo per cui il roll out funziona meglio dove la prima implementazione è andata bene, perché eredita anche le competenze e non solo la configurazione.
Il roll out obbliga tutte le sedi a lavorare allo stesso modo?
No, e qui si gioca la riuscita del progetto. La scalabilità di SAP permette di tenere le specificità di ogni unità dentro un modello comune: un’aliquota fiscale diversa, una modalità di spedizione locale, un ciclo di approvazione proprio, una gestione del magazzino diversa da quella della sede.
| Caso | Che cosa comporta | Quando conviene |
|---|---|---|
| Roll out completo | Il template viene esteso su tutti i moduli attivi nella sede di riferimento. | Quando la nuova unità opera nello stesso settore con processi confrontabili. |
| Roll out parziale | Si estendono solo i moduli trasversali, tipicamente l’area amministrativa; il resto resta a progetto. | Quando il business della nuova realtà è diverso ma il consolidato deve restare unico. |
| Nuova implementazione | Analisi e disegno dei processi da zero, con il gruppo che gestisce due modelli. | Quando il settore merceologico o la normativa locale rendono il template inservibile. |
Il lavoro di analisi serve proprio a separare ciò che è davvero specifico da ciò che è solo abitudine della sede. La prima categoria si configura, la seconda si allinea al modello, e la matrice delle responsabilità serve proprio a decidere chi ha l’ultima parola su ciascuna voce. È la discussione più difficile del progetto, e si fa all’inizio.
Quando il roll out non è la strada giusta
Se la nuova realtà ha processi distanti da quelli del modello esistente, l’adattamento costa più di un’implementazione dedicata. Succede con un settore merceologico diverso, con una normativa estera che cambia il ciclo attivo, con un business model non confrontabile. In quel caso il roll out si valuta per i soli moduli trasversali.
C’è poi un limite nel punto di partenza. Se il modello della sede principale è pieno di sviluppi su misura non documentati, il roll out li porta con sé e li moltiplica. Prima di estenderlo conviene sapere quanti sviluppi esistono e quanti servono ancora, altrimenti si replica un debito tecnico su una sede in più.
Domande frequenti sui progetti di roll out
Quanto dura un progetto di roll out?
Dipende dal numero di moduli coinvolti e dalla distanza fra i processi. È una stima che si fa in analisi, sul perimetro reale: una media di settore non dice nulla, perché due roll out con lo stesso numero di moduli possono differire di mesi.
Si può fare un roll out su una società estera?
Sì. Vanno gestiti gli aspetti locali — regime fiscale, valuta, adempimenti dichiarativi, lingua — che SAP tratta come configurazioni della società, non come sistemi separati. La complessità sta nella normativa, non nell’architettura.
Che cosa succede al sistema della sede principale?
Resta in esercizio. Il roll out aggiunge unità organizzative alla struttura esistente e non richiede di fermare chi già lavora sul sistema. Le finestre di fermo interessano i rilasci, non il progetto nel suo insieme.
Serve rifare l’analisi dei processi?
Serve, ma circoscritta: non ridisegna il modello, verifica quali processi della nuova unità rientrano in quello esistente e quali richiedono configurazione dedicata. Saltarla è l’errore che fa emergere le differenze in fase di test.
Chi segue il sistema dopo l’avvio della nuova sede?
Il presidio va esteso anche alla nuova unità, altrimenti le sue segnalazioni si accodano a quelle della sede principale senza priorità proprie. È una voce da mettere nel contratto di assistenza prima dell’avvio, non dopo.
Parliamo della vostra prossima apertura
Il team di Software Business, partner SAP Open Ecosystem, affianca i gruppi del mid-market nei progetti di roll out, dall’analisi del perimetro all’avvio in produzione. Se avete un’apertura in programma, scriveteci: si parte dai processi della nuova unità e dal modello che avete oggi, non da una presentazione di metodologia.
Le tre metodologie di migrazione a confronto, i tre numeri che decidono quale conviene, la lista di controllo del Readiness Check e le date di fine manutenzione.