<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=451519968711544&amp;ev=PageView&amp;noscript=1">

3 diversi approcci al passaggio SAP S/4HANA

Sub Heading

SAP S/4HANA è il nuovo gestionale nato nel 2015 per rimpiazzare l’ormai storica soluzione SAP ERP che tanta fortuna ha avuto in Italia e nel mondo. Nella volontà di SAP, fin dalla prima progettazione, c’è stato l’obiettivo di realizzare un software di nuova generazione, “digital ready”, aperto all’integrazione verso il cloud e fruibile in maniera nativa dal cloud, che potesse sfruttare al meglio le potenzialità del database in memory HANA. 

Il nuovo ERP nasce quindi sulla base della precedente soluzione ma subisce un’evoluzione talmente radicale, a livello di struttura dati, codice sorgente e disegno dei processi, da non poter essere definito come un successore del precedente. SAP S/4HANA è un nuovo prodotto, con tutte le implicazioni che questo comporta.

Quando si parla di S/4HANA è sempre necessario distinguere fra la soluzione on premise (che può essere implementata effettivamente on premise o presso uno dei tantissimi provider cloud) e la soluzione cloud (che può essere implementata nella versione Single Tenant o Multi Tenant, esclusivamente in modalità Software as a Service). Dal punto di vista delle funzionalità le due soluzioni sono molto simili. SAP parla di “single code line”, per descrivere la sostanziale simmetria nel codice sorgente. Quello che cambia notevolmente fra le due soluzioni sono le possibili modalità di adozione, di personalizzazione e di fruizione.

In questo articolo ci concentreremo solo sulle possibili modalità di adozione, lasciando gli altri temi ad ulteriori approfondimenti.

Oggi, qualunque responsabile IT di un’azienda che utilizza SAP ERP, si è sicuramente già domandato come fare ad adottare S/4HANA. Molti hanno già un’idea più o meno chiara delle possibilità, ma tanti brancolano ancora nel buio, persi fra comunicazioni spesso poco chiare e, altrettanto spesso, troppo tecniche per poter fugare ogni dubbio. Cerchiamo quindi di fare un po’ di ordine.

 

SAP S4HANA Iimplementazione o conversione

Partiamo dalle basi. Esistono tre differenti scenari di transizione per passare a S/4HANA. Alcune opzioni sono possibili in tutte le condizioni, ma è necessario comprendere a fondo le implicazioni di ogni scelta prima di decidere qual è la propria via:

  • Nuova implementazione;
  • Conversione;
  • Trasformazione.

Vediamole nel dettaglio.

 

Nuova implementazione

Evidentemente una nuova implementazione (nota anche come “Greenfield”) è sempre possibile. Oggi sono disponibili strumenti innovativi ed acceleratori di progetto (come le best practice verticalizzate per industry line o la SAP Model Company) che consentono di realizzare una nuova implementazione di SAP S/4HANA in una frazione del tempo impiegato con le vecchie metodologie, garantendo la realizzazione di un sistema più stabile e con una soluzione molto più vicina allo standard rispetto alle esperienze passate. La nuova implementazione è possibile sia nella soluzione On Premise sia nella soluzione Cloud e la ripresa dati storici è possibile sia partendo da un sistema SAP ERP, sia da qualsiasi altro gestionale. SAP ha sviluppato una serie di strumenti estremamente sofisticati per la ripresa dati che consentono di recuperare velocemente le informazioni dal vecchio gestionale e di eseguire agevolmente tentativi di ripresa dati in differenti configurazioni, per capire qual è la scelta giusta per ogni singola azienda.

Per i clienti che già hanno SAP la scelta di una nuova implementazione è quella probabilmente più giusta quando:

  • L’azienda non ha ancora installato la release 6.0 di SAP ERP e di conseguenza, per convertire il sistema a S/4Hana dovrebbe prima affrontare un costoso e complesso progetto di upgrade (ECC 6.0 è la release minima da cui è possibile partire per la conversione diretta a S/4HANA);
  • Il sistema di partenza è di vecchia implementazione, con molto codice custom e soluzioni di cui si è persa la visione complessiva; alcune funzionalità vengono usate perché “funziona così” e non per il valore che portano al business ed è difficile immaginare come i processi così implementati possano servire al business del futuro. In questi casi una nuova implementazione serve a ridefinire processi più standard e in linea con le reali esigenze del business, ridisegnare una soluzione ERP che guadi alla strategia dell’azienda piuttosto che al suo passato e consenta di fare pulizia di tutta la stratificazione di software e customizzazione non più utili;
  • La scelta aziendale è di andare verso la soluzione Cloud; non esistendo tool di conversione la scelta di una nuova implementazione in questo caso è obbligata.

 

Conversione

La bella notizia è che, diversamente da quanto successo a chi in passato ha adottato soluzioni ERP prodotte da aziende internazionali di primaria importanza, i clienti SAP possono contare su una serie di tool estremamente efficaci che garantiscono la possibilità di convertire un’implementazione ECC 6.0 in S/4HANA.

Contrariamente alla nuova implementazione la conversione (nota anche come “Brownfield”) è possibile solo ed esclusivamente partendo da un sistema SAP ERP in release 6.0 e solo verso la soluzione on premise. Oltretutto il sistema deve essere già in Unicode e non deve avere un doppio stack Abap + Java. Se è presente uno stack Java questo deve essere rimosso prima della conversione. Fatte queste precisazioni possiamo aggiungere che fortunatamente non è necessario avere implementato nessun Enhancement Package specifico (va bene anche l’EHP0) né avere già implementato il database HANA. La conversione del database in HANA può avvenire durante la fase di conversione del sistema, anche se richiede un leggero allungamento del periodo di downtime.

In un progetto di conversione tutto il proprio modello di business, tutti i propri dati storici, tutta la customizzazione fatta e tutto il software custom viene adattato e portato sulla nuova piattaforma che, al netto delle innovazioni obbligatorie e di quelle che si potrà decidere di implementare, continuerà a funzionare secondo gli schemi noti e consolidati. Solitamente questo genere di progetto si affronta con il modello delle innovazioni incrementali: la prima fase (conversione) viene trattata quasi come un upgrade tecnico che comporta l’adozione delle sole innovazioni rese obbligatorie in S/4 (come ad esempio alcune funzionalità nel mondo della contabilità), mentre la seconda fase vede l’implementazione delle funzionalità innovative in considerazione della valutazione di valore per il business e impatto nell’implementazione. Questo consente di non dover cambiare in un colpo solo la soluzione informatica e l’intera operatività del business, diluendo l’impegno nel change management e valutando, anche con l’utilizzo, le effettive opportunità di miglioramento offerte da S/4HANA.

Per i clienti che sono nelle condizioni di affrontarla, la scelta di un progetto di conversione è quella probabilmente più giusta quando:

  • Il business non può operare adeguatamente se non ha online tutti i dati storici con cui è abituato ad operare nel vecchio sistema (la migrazione integrale di tutti i dati storici piò essere ragionevolmente affrontata solo con un progetto di conversione)
  • Il sistema di partenza risponde adeguatamente alle esigenze del business attuale e non presenta significative aree grigie; il software custom non è preponderante sullo standard ed è adeguato alle esigenze attuali. In questa condizione un progetto di conversione con l’adozione rapida delle principali innovazioni a maggior valore aggiunto può fungere da acceleratore della trasformazione digitale dell’azienda
  • Il sistema di partenza è integrato con un considerevole numero di sistemi esterni che dialogano tramite interfacce standard e custom; un numero importante di interfacce il cui funzionamento deve essere solido e garantito, comporta un notevole dispendio di tempo in adattamento e test durante un progetto di nuova implementazione ed introduce un elemento di rischio che può essere ridotto da un progetto di conversione

 

Trasformazione

Lo scenario di una Trasformazione (o meglio di una “landscape transformation”) è solitamente quello in cui il cliente decide di approfittare della discontinuità per intervenire anche sul proprio landscape gestionale. Il caso classico (ma non l’unico) è quello di un cliente che ha diversi sistemi gestionali, anche non solo SAP, e che vuole cogliere l’opportunità di un consolidamento dei sistemi nel nuovo SAP S/4HANA.

Questo può avvenire partendo con un approccio greenfield (e quindi anche verso una soluzione Cloud) oppure brownfield (e quindi esclusivamente verso una soluzione on premise). Partendo con un approccio greenfield si implementa il disegno aziendale su S/4HANA e poi si trasferiscono porzioni di business (o intere legal entity) prelevandole dai sistemi gestionali originali. Partendo con un approccio brownfield si decide quale dei sistemi originali convertire su S/4HANA e poi, sul sistema convertito, si importano le porzioni di business (o intere legal entity) in base alla strategia di business.

Ne consegue che questo genere di progetto ha un percorso di adozione molto più graduale dei precedenti e solitamente non si conclude con il primo go live, ma comporta una serie di reiterazioni e rollout fino a giungere al completamento del disegno complessivo.

 

Conclusione

Come abbiamo visto ci sono molte vie per arrivare a S/4Hana e il percorso va tracciato sempre tenendo conto di ogni specifica realtà. Quelle che abbiamo esposto, sebbene siano le principali, sono solo alcune delle considerazioni e delle valutazioni che è necessario fare prima di individuare la propria via. Si tratta di una decisione importante che influenzerà la vostra azienda per i decenni futuri e va quindi presa a seguito di un’attenta valutazione, supportati da un partner che sappia aiutarvi ad individuare la via, senza tentare di imporre o anche solo caldeggiare una strategia di adozione per pigrizia o maggiore confidenza.

 

Articolo da Stefano Rizzi, Metisoft Business Development Manager

 

CTA_SapS4hana(1)

 

Share This Post:
Stefano Rizzi

Stefano Rizzi

    Tags