Strategie per i rollout dell’ERP

In questo articolo vediamo alcune delle possibili strategie applicabili in un rollout di SAP o di un altro ERP. “Rollout” o “Roll out”, quando parliamo di SAP, si riferisce all’implementazione di SAP in una o più sedi locali. Il termine inglese rollout letteralmente vuol dire “lancio”, “avviamento”.

Nei progetti di implementazione di un ERP SAP in imprese di grandi dimensioni dobbiamo infatti lavorare con varie entità locali.

In questo articolo uso il termine locale per riferirmi a qualcosa che è specifico di una certa regione, un certo paese, una divisione di una impresa o financo una Business Unit che opera in modo differente da ciò che viene fatto “globalmente” nella compagnia.

L’esistenza di differenze che possono essere anche marcate nel modo di lavorare dentro la stessa impresa fa sì che non ci sia un modo ideale di introdurre SAP.

Ci sono infatti varie strategie che è possibile applicare in funzione dei risultati che si vuole ottenere con la implementazione di un ERP come SAP. Tre di esse sono:

L’utilizzo di un modello globale (template) con dei rollout locali. Si tratta della soluzione standard adottata dalle grandi imprese – in pratica consiste nell’avere gli stessi processi (e lo stesso Target Operating Mode, le stesse metodologie di project management, etc.) in tutta l’organizzazione.

Questa soluzione ha vari vantaggi: è più facile ed economica non solo da implementare ma anche da mantenere, permette di lavorare con dati omogenei, può essere facilmente scalata se necessario (ad esempio in caso di fusioni tra imprese ed è molto difficile cambiare i processi una volta che sono implementati – cosa che può essere vantaggiosa in società molto grandi e difficili da governare.

Tra gli svantaggi di questa alternativa il fatto che può essere percepita come molto lenta, in quanto è necessario definire nel dettaglio prima di iniziare i processi, le strutture informatiche, i dati che saranno condivisi tra le varie entità, cosa può essere cambiato localmente e cosa è intoccabile e molto altro: una implementazione può quindi durare vari mesi o anche anni.

Lavorare con progetti individuali. In questo caso si cerca di definire un punto di partenza comune, che poi viene adattato localmente. Questa soluzione ha chiaramente un senso quando i processi aziendali sono molto diversi tra i vari paesi (o aree geografiche, o business units, o società di un gruppo).

Questa soluzione è molto più rapida della precedente (infatti vari progetti possono essere eseguiti in parallelo). E’ inoltre molto facile “separare” parti dell’impresa (cosa che può essere interessante nel caso di spin off, cessioni di rami aziendali o situazioni simili).

Tuttavia ha anche varie controindicazioni: spesso è impossibile copiare le funzionalità tra un progetto e l’altro, l’implementazione è normalmente più cara in quanto le varie entità locali avranno richieste e necessità differenti tra di loro, sarà difficile se non impossibile consolidare i risultati aziendali.

Consolidare unicamente le informazioni – ad esempio condividendo solo il General Ledger, oppure organizzando un data hub dell’impresa. Si tratta evidentemente di una soluzione “estrema”, da adottare nel caso di società costituite da varie realtà locali diversissime – che potrebbero avere diversi modelli di business, e che lavorano in modo autonomo ed indipendente tra di loro.

In questo caso forzare le varie entità a uniformarsi può essere rischioso e controproducente (o financo illegale, se i processi sono diversi a causa di norme locali).

L’integrazione può avvenire con moduli di consolidazione come SAP S/4HANA Central Finance, che permette di gestire con un formato di dati comune le transazioni finanziare anche gestite da prodotti non SAP (ossia di terze parti).

In ultima analisi la scelta della strategia di implementazione dipenderà da quanto sia diversificata l’organizzazione, da quanto siano autonome le unità locali, dal tipo di settore industriale e soprattutto da quali siano gli obiettivi che vogliamo raggiungere con l’ERP.