Sappiamo che i clienti che vogliono passare da SAP ECC a SAP S/4HANA hanno di fronte tre possibili approcci: Conversione, Nuova implementazione o Trasformazione.
La scelta dell’approccio migliore va presa valutando una serie di elementi con molto anticipo, così da poter disegnare correttamente una strategia ed evitare di correre rischi inutili. Se si è già deciso di procedere con un progetto di conversione, quindi portando tutta la propria implementazione, i processi di business, la customizzazione e il codice custom su SAP S/4HANA, allora vale la pena di iniziare a pianificare quelle attività che possono - o che devono - essere effettuate nel sistema originale, per ridurre la complessità del progetto, gli elementi di rischio e l’impegno delle risorse interne in un periodo temporale a volte troppo concentrato.
In questo articolo vedremo alcune di queste attività e capiremo quali vantaggi possono portare.
Attività tecniche propedeutiche riguardanti la Conversione
All’interno di un progetto di conversione ci sono molte attività tecniche obbligatorie che è bene anticipare anche nella fase preparatoria, ma che comunque devono necessariamente essere effettuate durante le varie fasi esecutive del progetto. Ci sono poi delle attività non obbligatorie ma fortemente raccomandate, che possono rendere il progetto più semplice e più sicuro.
Statistiche e utilizzo del sistema
I tool SAP che vengono eseguiti prima e durante il progetto di conversione basano molta della propria intelligenza sull’utilizzo che facciamo del sistema SAP. Molte delle informazioni di base per le analisi vengono estratte dalle statistiche che solitamente consultiamo attraverso la transazione ST03N. Molto spesso i sistemi dei clienti hanno un’impostazione di default delle statistiche che prevede un periodo di registrazione delle stesse per soli 3 mesi. E’ evidente come un’impostazione così limitata impedisca di poter fare un’analisi affidabile dell’utilizzo del sistema, portando a potenziali importanti deviazioni in base al periodo dell’anno in cui l’analisi viene effettuata. L’aumento del numero di mesi storicizzati è quindi la prima, semplicissima, attività da effettuare nel sistema, che però va fatta al più presto. Noi suggeriamo di portare il periodo a 12 mesi, almeno fino all’avvio del progetto ed è importante sottolineare che il cambio dell’impostazione non è retroattivo: se oggi aumentiamo il parametro da 3 a 12 mesi, solo fra 9 mesi avremo lo storico dei 12 mesi desiderati.
Individuazione codice custom non usato
In tutti i sistemi SAP esiste una certa quantità di codice custom che cresce in funzione della complessità dell’implementazione e all’anzianità della stessa. Spesso capita che del codice custom scritto in passato venga sostituito da nuove versioni del software o abbandonato perché il processo o l’azienda hanno subito un’evoluzione, e così ci si ritrova con un numero significativo di oggetti che non servono più. Tutti questi oggetti solitamente restano all’interno del repository perché non danno nessun fastidio o perché “magari possono tornare utili in futuro”.
Purtroppo il codice custom può rappresentare un elemento significativo nel costo di un progetto di conversione SAP S/4HANA, soprattutto se durante la conversione si decide anche di approcciare un sotto progetto di adeguamento alle semplificazioni introdotte da SAP o anche solo di implementazione di tutte le correzioni suggerite per migliorare le performance.
Attivando il tool ABAP Call Monitor (SCMON) è possibile tracciare accuratamente l’utilizzo di tutto il codice custom ed individuare tutto quello che non è più utilizzato all’interno del sistema ECC. L’individuazione del codice non utilizzato ci consente di escluderlo dalle attività di conversione, risparmiando tempo nell’adattamento e nel test, ottenendo al contempo un sistema convertito più pulito.
Tramite i tool di conversione è possibile selezionare gli oggetti individuati come non utilizzati per i quali si decide l’eliminazione. Gli oggetti marcati per l’eliminazione vengono eliminati solo durante l’effettiva conversione del sistema tramite il tool SUM, senza nessun intervento manuale da parte degli sviluppatori.
Archiviazione
Uno degli aspetti centrali e di maggiore complessità in un progetto di conversione a SAP S/4HANA è rappresentato dalla conversione dei dati di business. Nel webinar del 16 Giugno, riguardo la conversione a SAP S/4HANA, abbiamo visto alcuni passaggi cruciali nella conversione dei dati di business e come è necessario valutare alcune operazioni da intraprendere per mitigare il rischio.
La mole dei dati da trasferire, seppure in uno scenario di rischio mitigato, rappresenta comunque un fattore determinante sia per la definizione del tempo necessario alla conversione, sia per il dimensionamento della macchina futura, influenzando quindi il costo del progetto di conversione e soprattutto il costo di esercizio del nuovo sistema.
Per tutte queste ragioni, e in considerazione del fatto che un progetto di conversione converte tutto quello che è online nel sistema SAP originale, consigliamo vivamente di valutare e possibilmente eseguire un’archiviazione dei dati, prima di avviare il progetto stesso. Teniamo presente che fra i dati “on line” ci sono, ad esempio, anche tutti i clienti e i fornitori su cui abbiamo impostato il flag di cancellazione, ma che non sono stati cancellati. Tutti questi clienti e fornitori dovranno essere non solo convertiti a SAP S/4HANA, ma anche gestiti all’interno dell’attività di Customer Vendor Integration (CVI) di cui parleremo tra poco.
Readiness Check
Fra i tool disponibili per la conversione ma non obbligatori c’è il SAP Readiness Check. Pur non essendo obbligatorio questo tool è estremamente utile e va assolutamente eseguito, anche più di una volta lungo il percorso verso S/4Hana. Oltre a darci indicazioni sulla dimensione del DB HANA, sull’impatto della conversione sul codice custom, sulle funzionalità Fiori suggerite, sulle semplificazioni rilevanti per la nostra azienda e molto altro ancora, questo tool può evidenziare potenziali problemi gravi (ad esempio fra gli add-on installati) che potrebbero addirittura impedire la conversione. Un’esecuzione del tool con largo anticipo ci consente di evidenziare questi possibili impedimenti e gestirli avendo a disposizione un tempo adeguato per l’individuazione delle soluzioni, senza correre il rischio di ritardare il progetto o, addirittura, di metterlo in discussione.
Il SAP Readiness Check è uno di quei tool che basa l’analisi sulle statistiche presenti nel sistema. Se mettiamo insieme il potenziale problema legato ad un’impostazione delle statistiche troppo limitata con i possibili problemi che possono essere evidenziati dall’esecuzione del tool, capiamo perché è necessario iniziare a fare i primi passi molto prima di avere davvero sul tavolo il progetto di conversione.
Attività propedeutiche sui dati di business
Quello che ormai dovrebbe essere chiaro è che uno dei vantaggi principali di una conversione a SAP S/4HANA è poter contare, al termine del lavoro, su un sistema che contiene tutti i dati di business del sistema originale. Quello che invece forse non tutti sanno è che la conversione dei dati di business è un’attività che richiede un grande lavoro preparatorio nel sistema originale. Questo lavoro può essere fatto durante il progetto di conversione o parzialmente anticipato, magari cogliendo l’occasione per iniziare ad utilizzare alcune innovazioni che in SAP ECC sono disponibili e facoltative e che in SAP S/4HANA diventano obbligatorie.
Ricordiamo, inoltre, che SAP suggerisce di gestire il progetto di conversione seguendo l’approccio delle “innovazioni incrementali”: determinate funzionalità non sono attivabili durante la conversione stessa mentre altre innovazioni devono essere adottate obbligatoriamente.
Vediamo meglio nel dettaglio di cosa stiamo parlando.
Adozione delle innovazioni
Secondo la metodologia suggerita da SAP e anche in base alla nostra esperienza, possiamo dire che l’approccio delle “innovazioni incrementali” è quello più efficace per un progetto di conversione. Questo modello il progetto di conversione viene gestito in modo simile ad un upgrade e in fase di go live si attivano solo le innovazioni obbligatorie, lasciando ad una fase successiva l’adozione delle innovazioni facoltative, in base al rapporto costo/beneficio che viene comunque determinato in fase di assessment e ri-attualizzato durante il progetto. Oltre che essere una metodologia suggerita, questa è anche una regola che va obbligatoriamente eseguita per determinate innovazioni. Se ad esempio volessimo convertire il nostro “Classic General Ledger” nello “Universal Journal” (innovazione obbligatoria) adottando contemporaneamente la funzionalità di “Document Split” (innovazione non obbligatoria), saremmo obbligati a cambiare i nostri piani, perché questa casistica rientra nelle combinazioni impossibili.
Anche per questa ragione è necessario approcciare il progetto con una chiara visione futura della nostra azienda e supportati da un partner che riesca a districarsi fra la miriade di regole e possibilità, così da essere in grado di scegliere la strada migliore e possibilmente ridurre il rischio insito in un progetto eccessivamente complesso e articolato. Tornando all’esempio si potrebbe valutare la possibilità di attivare il “New General Ledger” nel sistema da convertire e quindi iniziare immediatamente ad utilizzare il Document Split. Questo ci consentirebbe di passare allo Universal Journal con la nuova funzione già attivata, testata e pronta per l’utilizzo.
I Business Partner
Fra le innovazioni obbligatorie che devono essere immediatamente adottate su SAP S/4HANA ci sono i business partner. Semplificando, l’oggetto business partner consolida in un unico sistema di anagrafiche oggetti fino ad oggi totalmente separati, come ad esempio clienti e fornitori. Grazie al business partner si possono gestire semplicemente i collegamenti e le sinergie fra quelle che in SAP ECC erano trattate come anagrafiche completamente distinte, ma che in realtà rappresentavano un unico soggetto e un unico partner della nostra azienda. La funzionalità abbatte la ridondanza dei dati, semplifica le quadrature e riduce la complessità del sistema, contribuendo a migliorarne le performance.
Quello che non tutti sanno è che l’oggetto Business Partner non è un’innovazione di SAP S/4HANA. Su SAP S/4HANA è divenuto soltanto obbligatorio ma è disponibile ed utilizzabile in SAP ECC da molto tempo, tant’è che tutta l’attività di preparazione alla conversione, denominata Customer Vendor Integration (CVI), va necessariamente eseguita nel sistema da convertire. L’attivazione del CVI in alcune aziende potrebbe risultare particolarmente complicata e richiedere molto tempo per poter arrivare alla configurazione più efficace possibile. In compenso, visto che la funzionalità è già disponibile, l’attivazione potrebbe essere fatta indipendentemente dal piano di conversione, così da eliminare dal percorso critico un’attività onerosa, ed iniziare da subito a sfruttare i benefici della gestione dei Business Partner. Questo semplificherebbe anche l’attività di change management perché gli utenti potrebbero iniziare da subito ad utilizzare la nuova transazione “BP” (che sostituisce tutte le vecchie transazioni per la gestione di clienti e fornitori) avendo quindi una cosa in meno da dover apprendere a seguito della conversione.
Conversione dei dati contabili
La conversione dei dati contabili rappresenta una delle maggiori sfide della conversione a SAP S/4HANA. Per poter essere trasferiti nel nuovo data model semplificato i dati contabili devono essere profondamente trasformati e questa attività può evidenziare delle inconsistenze che devono essere corrette. Anche un sistema perfetto, senza modifiche allo standard, senza interventi manuali nel database e senza sintomi apparenti, può presentare delle inconsistenze in contabilità che non consentono una corretta conversione a SAP S/4HANA. Basta un solo aggiornamento incompleto del database avvenuto per una qualsiasi ragione nel corso degli anni (ricordiamo che la conversione riguarda tutti i dati online presenti nel sistema), per trovarsi di fronte ad un problema che va assolutamente risolto. Solitamente i problemi da gestire e risolvere sono numerosi.
La conversione dei dati contabili avviene in due fasi. La prima fase viene eseguita all’interno del sistema SAP ECC e consente di individuare una parte delle possibili inconsistenze. La seconda parte viene effettuata al termine della conversione e consente di correggere tutte quelle inconsistenze che possono essere individuate solo nel momento in cui abbiamo a disposizione il database semplificato e convertito. Nel webinar che abbiamo affrontato il 16 Giugno, abbiamo descritto nel dettaglio tutte le attività necessarie nelle varie fasi della conversione dei dati contabili. Per ora è però importante sottolineare che la prima fase di analisi delle inconsistenze può essere avviata in anticipo rispetto all’effettivo progetto di conversione e questo può permettere di farci una prima idea dell’impatto dell’adattamento dei dati contabili sul progetto stesso, migliorando l’affidabilità della pianificazione delle risorse e del costo dell’iniziativa.
Conclusione
La conversione a SAP S/4HANA può essere affrontata utilizzando una serie di strumenti standard estremamente consolidati, che garantiscono il successo dell’operazione. Nonostante questo, il progetto da affrontare è complesso e ricco di insidie che vanno prevenute, evitate e, come ultima ratio, affrontate e gestite nel momento in cui si presentano. E’ quindi di fondamentale importanza affidarsi ad un partner che sappia aiutarci ad eliminare dal percorso critico tutto quello che può essere anticipato e suggerirci le giuste decisioni per evitare di incorrere in problemi evitabili. Poi sicuramente degli imprevisti durante il progetto ci saranno ma chi ha saputo consigliarci il meglio per la fase propedeutica, saprà anche trovare brillanti soluzioni per toglierci dai guai e procedere secondo i piani sulla strada verso SAP S/4HANA. Se vuoi scoprire qual è la strada giusta per adottare al meglio la nuova business suite SAP S/4HANA, scarica gratuitamente il nostro webinar on demand!
