Fasi di un progetto di implementazione di SAP: la realizzazione (4 di 4 – le migrazioni)

Benvenuti all’ultimo post sulla fase realizzativa: lo studio e la realizzazione della migrazione dei dati.

Cos’è la migrazione? Si tratta del trasferimento massivo di tutte le anagrafiche e di tutte le posizioni aperte nel giorno del passaggio dal vecchio sistema al nuovo sistema SAP.

“Posizioni aperte” sono ad esempio gli ordini di vendita aperti (non ancora spediti), le consegne in lavorazione, gli ordini di acquisto non ancora chiusi, le partite contabili aperte (crediti verso clienti e debiti verso fornitori) non ancora pareggiate, etc.

Quali strumenti ci mette a disposizione SAP per effettuare la migrazione di questi dati?

Ne esistono diversi – l’ultimo in ordine cronologico è il Legacy Transfer Migration Cockpit (LTMC), che in italiano suona come “Cabina di pilotaggio per la migrazione dei dati dal sistema informatico che verrà dismesso”.

Per usare il Migration Cockpit non serve scrivere codice di programmazione. Si gestisce da una schermta lanciata in SAP con il T-Code “LTMC”.

Questo strumento lavora caricando dei file XML creati con un template (una “struttura modello”) che è possibile scaricare direttamente dalla LTMC.

Il consulente dovrà compilare il file modello (idealmente scaricandolo dal vecchio sistema con lo stesso formato richiesto) e caricarlo tramite le funzionalità previste nella LTMC.

Un secondo strumento è l’LSMW – Legacy System Migration Workbench (“Piattaforma per la migrazione dei dati dal sistema informatico che verrà dismesso”).

Si tratta di uno strumento meno recente del precedente ma comunque molto efficace (l’ho utilizzato varie volte).

Prevede vari strumenti di migrazione e permette all’utente di creare automaticamente (anche senza conoscenza di programmazione) un programma di caricamento semplicemente “registrando” tutte le operazioni che il programma dovrà eseguire.

Poniamo ad esempio che sia necessario caricare dei materiali in anagrafica.

l’LSMW prevede in uno step la possibilità di creare in test la creazione dell’anagrafica, specificando quali campi sono fissi (non variano nei record da caricare, per esempio il canale distributivo è sempre 10), quali campi devono variare secondo una logica (per esempio per un certo tipo di materiale il settore merceologico è 10, per un altro tipo di materiale il settore merceologico è 20), e quali campi sono variabili e saranno oggetto di caricamento massivo (per esempio la descrizione del materiale sarà specifica di ogni materiale).

SAP creerà automaticamente un programma basato sulla registrazione che specifica il modello di file (cioè quali sono i campi, il formato, le posizioni, etc.) che si aspetta al momento del caricamento massivo.

Qualche consiglio sulla fase realizzativa della migrazione.

Prima di tutto riconfermo quello che ho detto nei precedenti post sulla necessità di preparare sempre le analisi funzionali. In questo caso il documento viene chiamato “Strategia di migrazione”.

Nella strategia di migrazione vengono definiti ad esempio

• Quali oggetti verranno migrati (anagrafiche clienti, anagrafiche fornitori, stock, partite aperte, etc.)
• La modalità con cui verranno migrati i dati (tramite LTMC, LSMW, programmi creati ad hoc, inserimento manuale da parte dell’utente, etc.)
• Quali sono le varie strategie di migrazione, per esempio verrà eseguita una prima migrazione di prova entro questa data sul sistema di test di SAP, poi una seconda migrazione sempre di prova entro un’ulteriore data sul sistema di test
• Quando verrà eseguita la migrazione nel sistema effettivo
• La modalità di approvazione (validazione del dato) da parte dell’utente
• Come verrà ottenuta tale modalità (magari solo con dati campione quando ci sono migliaia di record da migrare)
• Entro quando deve avvenire tale approvazione

Quando sorge la necessità di creare uno sviluppo ad hoc è buona pratica creare delle analisi tecniche per evitare i problemi descitti nei precedenti post: occorre definire il perimetro dello sviluppo e condividerlo con la persona che si occuperà dell’attività, spiegando il documento, raccogliendo i suoi contributi e rettificando lo stesso rendendolo sempre aggiornato nel caso che lo sviluppatore in corso d’opera esegua delle modifiche rispetto a quanto precedentemente concordato.

Anche per questa attività occorre verificare che i campi da migrare e i campi nuovi siano stati “accoppiati” correttamente secondo la logica dei nuovi processi e non con una mappatura che manterrebbe la vecchia visione dei processi aziendali (per capire meglio l’importanza di questo concetto potete leggere il post sulle interfacce).

Un ulteriore suggerimento che vi voglio dare e che può sembrare banale ma è molto importante è di limitare al massimo gli oggetti da migrare. Meno oggetti ci sono da migrare, meglio andrà la gestione di questa fase.

In che modo raggiungere questo obiettivo?

Innanzitutto è buona pratica “chiudere” più posizioni aperte possibili. Molto spesso per farlo occorre condividere la decisione con i clienti e i fornitori o con altri partner commerciali che ruotano attorno al cliente.

Per esempio se abbiamo delle consegne in fase di elaborazione, sarebbe opportuno smaltire tutte le consegne già create ma non ancora completamente evase definitivamente entro l’ultimo giorno di utilizzo del vecchio sistema. In questo modo elimineremo un oggetto da migrare migrazione (le consegne).

Un altro esempio possono essere le fatture passive da registrare. Specie se la partenza del sistema (“Go Live”) viene fissata per il primo giorno di un mese sarebbe molto utile chiedere ai fornitori di inviare le fatture che corrispondono a tutti gli ordini di acquisto aperti.

Inoltre si possono migrare alcuni oggetti con la creazione manuale. Questa soluzione è possibile soprattutto per oggetti che hanno pochi record da caricare.

Questa soluzione ha anche il vantaggio di incentivare l’utente nell’imparare ad utilizzare rapidamente SAP prima del Go Live.