Come gestire i cambiamenti su un sistema SAP installato e funzionante

Sarebbe bello se una volta installato un software gestionale finisse il lavoro e non ci fosse più bisogno di interventi.

Purtroppo (o per fortuna, se lavorate come consulenti SAP) è necessario apportare regolarmente al sistema in produzione (ossia usato quotidianamente dall’impresa) vari tipi di modifiche e aggiornamenti: correzione di piccoli problemi, installazione di nuovi moduli e funzionalità, etc.

Una strategia usata spesso è quella di accorpare tutti i cambiamenti in diverse “releases” – termine che non ha un esatto equivalente italiano, ma suona come “rilascio”.

Una release è un insieme di cambi ai processi, l’hardware, il software, la documentazione o altri componenti del gestionale per implementare una o più modifiche che sono state approvate da chi ha l’autorità necessaria.

Chi ha l’autorità di gestire il sistema ERP dovrà scegliere quali cambiamenti approvare tenendo a mente gli obiettivi globali della società, consigliando i vari dipartimenti e valutando tutti i requisiti richiesti a SAP. Nel caso di un’organizzazione molto complessa, si possono introdurre più livelli di autorità – ad esempio regionale o funzionale e globale.

I contenuti di ogni release sono gestiti, testati e distribuiti come se si trattasse di un unico cambiamento.

Le releases permettono di lavorare in modo organizzato, dando la priorità ad alcuni cambi e ritardandone altri meno urgenti.

Le releases possono introdurre nell’organizzazione cambiamenti numerosi e rilevanti. Per ridurre il loro impatto sul corretto funzionamento dell’impresa, la necessità di aggiungere nuove funzionalità deve essere bilanciata con il rischio associato all’introduzione di queste modifiche in un ambiente in produzione.

Inoltre, è buona prassi introdurre un insieme coerente di strategie e regole aziendali per la gestione delle release.

Queste strategie, regole e politiche devono essere definite dalla società per consentire:

• Una gestione delle releases con tempistiche chiare e contenuti dei cambi noti a tutti coloro che saranno interessati ai cambiamenti che si faranno al sistema.
• La riduzione al minimo delle interruzioni del funzionamento del sistema (il cosiddetto “downtime”).
• Ambienti di test e produzione stabili.
• Uso efficace delle risorse, minimizzando il consumo di ore di consulent, programmatoria ABAP, etc.

Tutti i cambiamenti da implementare in SAP devono essere considerati calcolando il loro valore (quanto potranno far guadagnare e/o risparmiare) ed il loro costo di implementazione, idealmente con uno specifico business case che consideri anche il livello di rischio (il costo per l’impresa se qualcosa dovesse andare storto) e quanto siano complicati i test.

Inoltre è opportuno considerare che a volte il cambio è esclusivamente locale, mentre in altri casi la soluzione può essere applicata globalmente.

È quindi buona pratica definire chiaramente tre processi distinti:

1. Processo decisionale per approvare o respingere un cambiamento nel sistema

2. Processo da seguire per comunicare il cambiamento ai colleghi interessati

3. Processo di implementazione del cambiamento

È infine importante definire chiaramente chi sarà il responsabile dei costi associati al cambio (ad esempio IT, o la funzione aziendale o il dipartimento che richiede il cambio).