Le fasi primissime fasi di un progetto di implementazione SAP: il Kick off e la fase di analisi dei processi esistenti

In questo articolo presento due importanti momenti nell’implementazione di SAP in una impresa: il Kick off (in Italiano “Calcio di Inizio”) e la fase di analisi.

Nel Kick off, il momento “ufficiale” nel quale inizia il progetto, trovano spazio le seguenti attività:

1. Presentazione della squadra di progetto: il team di consulenti esterni, il team di specialisti interni del cliente ed altri eventuali stakeholders (un termine generale per indicare tutte le persone che possono favorire od ostacolare l’implementazione) hanno modo di conoscersi
2. Presentazione degli obiettivi del progetto: dove vogliamo arrivare implementando SAP? Gli obiettivi devono essere definiti chiaramente ed essere condivisi da tutti
3. Presentazione della metodologia: come vogliamo raggiungere gli obiettivi, quali saranno i passaggi principali e quali strumenti useremo

Il mio suggerimento per la gestione di questa primissima fase è di farlo presenzialmente, organizzando una riunione “plenaria” ed invitando tutte le persone direttamente coinvolte nel progetto e se possibile il senior management dell’azienda cliente.

L’obiettivo non è solo quello di comunicare nel modo più chiaro possibile obiettivi e metodologia ma anche di motivare la squadra: un progetto di implementazione SAP dura solitamente da sei mesi a oltre due anni e in alcuni momenti il ritmo di lavoro può diventare stressante.

La successiva fase di analisi è per me tra i momenti più importanti: qui si disegnano infatti i nuovi processi che verranno utilizzati da SAP.

È importante sapere che non sempre tutti i processi esistenti nell’impresa vengono “migrati” nella nuova piattaforma.

L’implementazione di SAP serve infatti anche per fare una “pulizia” di processi obsoleti o non ottimali.

Molte volte sono arrivato da un cliente dove si lavorava in un certo modo solo perché “si è sempre fatto così…”, senza mai fermarsi a pensare se esistesse un modo più efficiente di raggiungere lo stesso obiettivo.

Una seconda ragione per ripensare i processi è che è possibile scegliere di utilizzare dei processi standard predefiniti da SAP, magari anche solo parzialmente diversi da quelli attuali.

Così facendo, oltre a sfruttare l’esperienza accumulata da SAP negli anni, si possono anche ottenere dei vantaggi economici (ad esempio minori costi di manutenzione rispetto ad una implementazione altamente personalizzata, minor tempo di implementazione, etc.).

Come motivare i dipendenti di un’azienda a cambiare i processi con i quali hanno sempre lavorato?

Un primo metodo è mostrare un sistema SAP funzionante, dove sono stati già installati dei processi standard (idealmente specifici del settore del cliente). Questo esempio pratico può aiutare gli utenti finali a sentirsi parte del processo e a collaborare con il loro input.

Un secondo metodo è quello di coinvolgere la dirigenza, soprattutto se gli utenti coinvolti nel progetto hanno delle mansioni puramente operative e non hanno la necessaria visione di insieme.

I processi aziendali sono infatti strettamente correlati ed esiste il rischio di avere una visione troppo “settoriale”: occorre cioè avere una visione “ad alta quota”, per capire meglio dove intervenire e come migliorare le operazioni in azienda.

Il coinvolgimento del senior management permette inoltre di concentrare gli sforzi sull’individuazione, l’analisi ed il miglioramento dei processi critici.

Un processo critico è un processo che genera un alto valore aggiunto per l’azienda.

Ad esempio un’azienda che sta implementando SAP potrebbe avere diversi processi di vendita (per esempio telefonico, online, in negozi fisici, etc.). Se uno di essi produce una percentuale preponderante del fatturato di tutta l’azienda si tratterà di un processo critico e la fase di analisi dovrà ovviamente concentrarsi su di esso.

Dopo aver individuato tutti i processi ed aver definito quale è il sottoinsieme di processi critici occorre discutere ed analizzare gli stessi durante gli incontri.

Durante le riunioni è opportuno prendere note e riportare quanto detto e deciso in delle minuta. Le minute dovrebbero anche riportare le azioni successive (chi farà cosa e quando) e i punti rimasti aperti.

La stesura di una minuta permette di evitare che le decisioni possano essere dimenticate o fraintese. Consiglio di usare gli ultimi minuti di ogni incontro per fare una prima versione della minuta che verrà successivamente spedita a tutti i partecipanti al meeting.

Durante la fase di analisi vengono realizzate le Business Blueprint (BBP – traducibile in italiano come “Modello Aziendale”). Di cosa si tratta? Si tratta di un documento che spiega come funzionerà l’azienda dopo l’avvio di SAP.

La stesura viene eseguita dalla società di consulenza che raccoglierà in esso tutto quello che è stato discusso e deciso durante gli incontri (e condiviso tramite le minute!), descrivendo nel dettaglio il funzionamento dei processi aziendali che verranno implementati su SAP.

Una volta completato il documento verrà inviato al team del cliente per verifica, revisione e approvazione finale.

Anche in questo caso risulta molto utile organizzare un incontro preliminare dove verrà presentato il business blueprint, spiegando perché viene creato e come sarà strutturato.

La definita approvazione del business blueprint da parte del cliente indica la chiusura di questa importante fase del progetto.

Per il momento è tutto! Vi invito a vedere i prossimi post che parleranno delle altre fasi progettuali.

Un saluto a tutti!