SAP sposa la Composable Architecture e lancia il suo “Composable ERP” : sarà questo il vero motivo per affrontare la migrazione a S/4HANA ?

Ci sono sicuramente molte ragioni dietro il “forcing” orchestrato da SAP per convincere i clienti soddisfatti del sistema ECC a migrare comunque verso il nuovo S4Hana entro il 2027.  La più visibile ai clienti è il nuovo business model basato su Subscription e cloud per alcuni visto come una liberazione dalle problematiche tecnologiche, per altri, con la perdita della proprietà del bene, come un rischio e un costo difficilmente accettabile.   A ben vedere però questo è solo un aspetto della nuova architettura proposta da SAP e forse il meno interessante sotto il profilo organizzativo e tecnologico.  Ad una analisi più attenta la nuova architettura dei sistemi SAP mette a disposizione gli elementi attraverso i quali le aziende possono affrontare meglio la loro trasformazione digitale.  Per andare in concreto: trasformazione digitale significa quote di realtà aziendale che passano dal trattamento analogico o comunque mediato al trattamento immediato digitale.  Per esemplificare la fatturazione elettronica consente la registrazione dei documenti fattura in immediato dal software senza la mediazione di una persona che prima leggeva un documento e successivamente registrava la parte di quel documento necessaria a completare il processo contabile.  Come spesso accade è Gartner che classifica questi nuovi modelli come “Composable architecture”  in cui la soluzione software è basata su componenti di business I PBC “Packaged Business Capabilities” che costituiscono i mattoni standardizzati con cui costruire le applicazioni in un ambiente basato su microservizi.  Non è che si è cominciato ieri ad utilizzare architetture a microservizi basate su API, semplicemente Gartner ha sistematizzato questa modalità dandogli dignità tecnologica, descrivendo le caratteristiche che questi modelli devono avere e la spiegazione del perché sono molto più utili allo sviluppo del Business.  Il problema per le aziende clienti è che questa nuova modalità ha bisogno di una interpretazione molto diversa rispetto alle soluzioni “monolitiche” come il vecchio ERP di SAP, piuttosto che i vetusti sistemi AS400 però ancora usatissimi in tante aziende.  C’è bisogno di una nuova “vision” dello sviluppo dell’ecosistema digitale delle aziende, di nuove competenze, della partecipazione attiva del Business alle scelte che poi l’IT dovrà gestire.   A questa difficoltà si aggiunge il fatto che la migrazione “forzatamente” comprende un progetto molto complesso e rischioso per la continuità di servizio richiesta dal business. La migrazione può mettere in discussione il precedente ecosistema digitale magari basato su interfacce che potrebbero non essere più compatibili con il nuovo sistema migrato.  Paradossalmente i clienti che arrivano a SAP S4Hana da precedenti sistemi diversi da SAP si trovano in una situazione migliore quantomeno di prospettiva.  A questo punto le scelte, differenti per ciascuna azienda, sono tra una migrazione conservativa che meglio garantisce la continuità del business e una fortemente innovativa più rischiosa ma che immediatamente apre a tutte le peculiarità non solo funzionali, che il nuovo sistema comprende oltre a cancellare i refusi del passato. Diversamente dai periodi precedenti in cui l’analisi delle funzionalità disponibili era l’architrave delle scelte e il processo di adattamento organizzativo la parte più difficile e conseguente, con questi nuovi modelli si passa ad un ambiente in cui la tecnologia consente meno problemi di adattamento perché le funzionalità saranno disegnate per come il Business ha deciso che devono funzionare e la modularità consente una componibilità indipendente e implementabile in tempi diversi.  Purtroppo, il peso del progetto di migrazione, il costo ad esso associato, la difficoltà di farne comprendere le ragioni (se fa le stesse cose perché lo devo cambiare?)  toglie prospettiva, progettualità e convinzione.  Per arrivare al composable ERP si possono però percorrere altre strade magari più lunghe però di prospettiva, più facilmente giustificabili, meno rischiose lato business: si tratta di iniziare da subito a scomporre l’applicazione, magari iniziando dal codice custom la cui revisione è comunque obbligatoria, magari iniziando da processi “core” dell’azienda che hanno da subito necessità di essere ridefiniti, magari per iniziare a perseguire la strategia del “Clean Core” utilissima nella fase di migrazione e obbligatoria dopo.    E’ una strada perseguibile con gli strumenti di SAP e/o con gli strumenti di terze parti.  Diciamo che non è nelle corde dei “team di migrazione”  perché vedono il problema secondo il concetto di un task da svolgere nel migliore dei modi e in un tempo il più breve possibile.  Se però l’obiettivo è il COMPOSABLE ERP questa soluzione non solo è possibile, ma direi auspicabile.   Pensare diverso non è peccato!