Gli IT manager e i CIO lo sanno bene: non è questione di “se”, ma di “quando”. A meno che non si abbia la precisa intenzione di abbandonare SAP per rivolgersi a un altro vendor, la conversione a S/4 Hana è inevitabile. Nel 2025 infatti, il colosso dell’Intelligent enterprise cesserà di sviluppare e rilasciare upgrade e aggiornamenti di sicurezza per le piattaforme legacy come ECC, concentrandosi sulla soluzione ERP destinata a catalizzare tutte le funzionalità dell’ecosistema di servizi e applicazioni che SAP continua a estendere attraverso acquisizioni e attività interne di R&D. Un vero arsenale di strumenti che dalla gestione degli oggetti connessi al CRM, passando per l’experience management punta a digitalizzare tutte le attività aziendali con un approccio olistico e facendo leva sul Cloud. Prospettiva interessante per molti decisori di business. Gli stessi che, al netto di imprevisti, decideranno per l’appunto di continuare a servirsi dell’offerta di SAP.
Opportunità e rischi per le imprese che scelgono S/4 Hana
Si pone a questo punto un ostacolo non indifferente: SAP S/4 Hana non è il semplice potenziamento di un’architettura già esistente. Contempla, di fatto, un nuovo approccio tecnologico con diversi elementi di innovazione che generano una totale discontinuità anche rispetto alle ultime release di SAP. “Prima di ogni altra cosa, S/4 Hana introduce il database in memory, che risulta perfomante e capace di portare valore al business solo se declinato in modo abilitante”, sottolinea Stefano Segale, Head of Delivery ERP/SAP Integration di Exprivia, che insieme a Italtel forma un grande gruppo italiano specialista dell’innovazione tecnologica in ambito Ict. “Cambia letteralmente il paradigma attraverso cui si legge il dato e si sviluppa la reportistica. Il prodotto SAP S4Hana è stato completamente riscritto per migliorare e fluidificare i processi di business. Grazie alle informazioni erogate dalle app analitiche in real time è spesso possibile evitare il layer di disaccoppiamento del tradizionale data warehouse”. Secondo Segale, le aziende sono fondamentalmente consapevoli delle opportunità insite in questa svolta. “La conversione a S/4 Hana è un leit motiv che gira da anni nell’ambiente, ma abbiamo a che fare con utenti culturalmente più evoluti, più attenti agli aspetti innovativi – che comprendono anche front-end e interfacce semplificate, Web based – e altri meno consapevoli. Le domande che tutti, comunque, si stanno ponendo in questo scenario, sono: quanto il mio attuale ERP supporta il mio business? Quanto è progredito insieme ai processi aziendali?”
L’importanza dell’assessment in un progetto di conversione efficace
Sono di solito CIO e CFO a confrontarsi su questi temi, e a scontrarsi prima di ogni altra cosa con stratificazioni sul piano dei prodotti già installati e specialmente delle customizzazioni, che rendono estremamente complessa la valutazione degli aspetti tecnici di un’eventuale conversione. “Una corretta misurazione in tal senso fornisce la quantificazione dell’effort necessario ad avviare e sostenere un progetto di conversione da ECC a S/4 Hana, che risulterà tanto più complicato quanto più la piattaforma di partenza è stata personalizzata. E su questo, molto spesso, i clienti non hanno proprio il polso della situazione”, avverte Segale, facendo riferimento a un caso vissuto in prima persona. “Un mese fa, il CIO di un’impresa nostro cliente, durante un incontro preliminare all’avvio di un progetto di conversione, mi assicurava che in azienda erano presenti al massimo due-tre programmi con elementi custom. Ebbene, dopo aver effettuato un’analisi approfondita, abbiamo scoperto che questi programmi erano in realtà 580. Probabilmente il numero di quelli realmente utilizzati è assai inferiore, ma ciò non significa che non si debba tenere conto di tutti gli altri nel momento in cui si decide di passare a S/4 Hana. Anzi, è forse vero il contrario: bisogna prestare ancora più attenzione”.
Segale spiega che questo tipo di assessment – che di solito dura fino a due settimane – è parte integrante della value proposition di Exprivia Italtel sul fronte della system integration. “È un lavoro da artigiano esperto”, dice il manager. “Il mercato offre diversi tool per fare in autonomia il censimento dei cosiddetti programmi zeta, ma poi la differenza la fa l’esperienza consulenziale: gli strumenti possono identificare i programmi, ma non dicono in che modo saranno impattati da una conversione, il che rende questo approccio inadatto a fornire una fotografia nitida della roadmap da adottare”.
Approccio ‘brownfield’ o ‘greenfield’? Esiste anche una terza via
C’è poi la questione fondamentale dei dati da trasferire: vale davvero la pena di trasbordarli tutti sul nuovo sistema? Se si considera che le aziende che utilizzano ECC da un decennio arrivano a ospitare tera e tera di informazioni sui propri database, la domanda merita una risposta approfondita. “Convertire anche la base dati e portare l’intero storico su S/4 Hana è possibile, naturalmente”, precisa Segale. “Basta adottare un approccio ‘brownfield’ e i giusti strumenti di conversione, considerando però che S/4 Hana richiede un’architettura più impegnativa, e quindi più onerosa al crescere dei dati importati. Questo significa incrementare i costi da subito. È dunque un’azione a mio avviso da intraprendere se non ci sono alternative. Penso, per esempio, alle aziende che rispondono a un contesto normativo dove vige l’obbligo della conservazione di tutto lo storico”. Ma se non ci sono esigenze di questo tipo, suggerisce Segale, convertire l’intero data base potrebbe rivelarsi addirittura uno svantaggio. “Per questo in molti casi conviene puntare su un approccio ‘greenfield’: in altre parole, nel nuovo S/4 Hana porto solo ciò che mi serve, come l’anagrafica dei clienti e le partite aperte, e faccio ripartire le attività da zero sul nuovo sistema”.
Esiste però una terza strada, quella dell’approccio ‘bluefield’, che prevede di gestire la conversione basandosi su tool tipici del ‘brownfield’, ma con un escamotage: effettuare una shell copy, ovvero copiare l’ambiente software (ma non nella sua interezza, eliminando per esempio i programmi zeta inutilizzati) e soprattutto senza il database. “Una logica di conversione ibrida, che permette di trovare il giusto compromesso tra le esigenze di business e quelle dell’IT”, conferma Segale, che evoca un’ibridazione anche sul piano delle aree di interesse e competenza tra i due fronti.
“Nonostante la prospettiva dell’IT sia per forza di cose tecnica, con un orizzonte livellato sulle aspettative degli utenti più esigenti rispetto alla customizzazione degli applicativi, sempre di più si assiste a una trasformazione delle competenze all’interno del dipartimento Sistemi informativi: non ci si limita più alla mera expertise tecnologica, ma si ha buona familiarità anche dei processi aziendali. D’altra parte”, chiosa Segale, “quando si tratta di predisporre un assessment, ci confrontiamo anche con i rappresentanti del business: dalla logistica al finance, passando per funzioni verticali, ciascun responsabile descrive nel dettaglio cosa si aspetta di ottenere in seguito alla conversione, aiutandoci a individuare i gap e a tracciare una roadmap ben precisa, che in qualche caso può portare alla reingegnerizzazione di alcuni processi. Il coinvolgimento del cliente è imprescindibile per un system integrator: il buon esito del progetto dipende in larga parte dall’approccio metodologico identificato in base alle esigenze degli utenti finali”.
