La Composable architecture e le sfide della migrazione SAP S4/Hana: come gestire il codice custom nell’ottica “Clean Core”
I clienti che ancora utilizzano l’ERP di SAP nelle versioni ECC sono sollecitati a migrare alle versioni S4/HANA entro il 2027. Il contesto in cui questa cosa avviene è descrivibile come segue:
1. I tempi sono stretti.
2. La disponibilità dei Team specializzati in questa attività è limitata, ottimizzare i loro tempi di intervento è una necessità.
3. La scelta su quale modello di migrazione: “brown, blue, green”, pone problemi di implementazione che vanno analizzati con cura.
4. Le aziende che utilizzano l’ERP di SAP sono normalmente avanti rispetto alla trasformazione digitale per cui sono preoccupate per gli imprescindibili tempi di down dei sistemi e per le relative interruzioni del business.
5. SAP ha annunciato che, per garantire la manutenzione del sistema, sarà necessario un aggiornamento annuale obbligatorio per le applicazioni in “private cloud” o on-premise, mentre per i sistemi “public” saranno richiesti aggiornamenti trimestrali. Per aderire, senza problemi, a queste frequenze SAP suggerisce l’adozione della strategia “Clean Core”, una strategia volta ad eliminare dal “core” di SAP tutto ciò che è “custom” per il cliente o inutilizzato dal cliente.
6. Tutto quello che non è “Core” viene suggerito di gestirlo “fuori” adottando gli strumenti e gli scenari implementabili con l’infrastruttura BTP di SAP o con altri analoghi meccanismi.
In questo contesto, complicato da altre scelte come il CLOUD e le nuove tipologie di licenza, come si possono orientare i clienti SAP che devono eseguire una migrazione dal sistema ECC al sistema S4/Hana e contemporaneamente erogare servizi indispensabili al funzionamento del Business?
L’analisi del “valore” delle applicazioni per il business
Nel tempo ci siamo abituati a considerare il “di più” applicativo come qualcosa di ininfluente rispetto alla erogazione dei servizi. La filosofia “Lean” considererebbe questo come “spreco” e, come tale, da eliminare. La complessità del codice SAP sconsiglia di avventurarsi senza una guida sicura, in eliminazione di codice che potrebbe comportare gravi problemi di inaffidabilità.
Il primo consiglio è quello di verificare l’uso della applicazione attraverso l’analisi “quali transazioni per quali utenti” e di formare uno schema ABC dell’uso delle transazioni riportando le medesime alle fasi di processo che implementano. Questa analisi metterà a fuoco ciò che è realmente importante per l’azienda e quindi ciò di cui occorre occuparsi. La medesima analisi ci renderà chiaro quale sia la parte “Custom” più utilizzata, su cui impostare i ragionamenti.
Il secondo aspetto, “questo da standard”, è la verifica del codice SAP rispetto ai programmi/function module, rilevanti per l’organizzazione. La produzione di una documentazione semiautomatica di questo contesto è frutto dello studio di Peer Network rivolto alla ottimizzazione dei tempi di analisi.
Rendere “esterne” le applicazioni Custom
Come suggerito dalla strategia “clean core” un modo per “salvare” l’esecuzione personalizzata di certi processi è quella di metterli all’esterno del “core” e di farli funzionare attraverso l’uso di API. Le nuove architetture composable e a microservizi tendono a realizzare queste specifiche, non solo, tendono anche a specificare con maggiore chiarezza quali sono le componenti applicative che hanno più valore e soprattutto a delimitarne il campo di azione producendo una user experience dedicata a quella fase di processo. In un colpo solo si ottiene il risultato di “esfiltrare” il codice custom SAP sgradito e allo stesso tempo ottenere una funzionalità più adatta alla esecuzione del compito.
Cosa c’entra tutto questo con la migrazione verso S4/Hana ?
Nella tabella che segue vengono indicati elementi di vantaggio e/o criticità portati da questa scelta:
| Modalità di migrazione | Vantaggi/Opportunità | Criticità |
|---|---|---|
| Brown Field | Ottimizzazione dei tempi di migrazione, sia dei tempi di progetto, sia dei tempi di system-down il team di migrazione si deve preoccupare meno delle problematiche custom. Diminuzione dei costi del progetto di migrazione perché il TDM non dovrà analizzare tutto il custom per capire come gestirlo in fase di migrazione. Diminuzione della complessità della migrazione. Esternalizzando il codice si può migliorare la user experience e ottimizzare il processo che nella versione UI-first normalmente ha qualche limite. | Gestire bene i tempi, le esternalizzazioni di processo devono essere attive prima del upgrade. Necessaria una fattiva collaborazione fra i diversi team che operano sul progetto. |
| Blue Field | Oltre ai vantaggi già presenti nel brown field, la considerazione maggiore riguarda i processi che si vogliono mantenere perché essendo basati su codice esterno potranno essere già ampiamente testati nella fase di implementazione dei nuovi sistemi. Si potrà mantenere attivo il vecchio sistema per recuperare dati che diversamente andrebbero persi. L’applicazione composable è in grado di leggere i dati dal vecchio sistema assieme a quelli del nuovo, senza complicazioni applicative. | Gestire bene i tempi, gestire bene la collaborazione fra i diversi team al lavoro. |
| Green Field | Il Green Field prevede comunque un progetto di reingegnerizzazione in senso BPR, qui molto può aiutare pensare a processi custom-core già esternalizzati e funzionanti secondo user-experience dedicate e quindi senza necessità di change management. Anche in questo caso la presenza attiva dei vecchi sistemi può essere fondamentale per mantenere snello il nuovo sistema e non perdere profondità storica di dati necessari al processo. | Gestire bene i tempi, gestire bene la collaborazione fra i diversi team al lavoro. |
Conclusioni
Fin dalla nascita delle soluzioni SAP il “mantra” è sempre stato: “fai le cose come prevede lo standard e adatta la tua organizzazione a quello che lo standard propone”.
Le riunioni di progetto erano interminabili processi agli utenti che non volevano cambiare le proprie attività. Da qui il fallimento degli obiettivi di tanti progetti. I fatti dimostrano che, nella maggior parte dei casi di successo, si è passati da una visione estremamente rigida a una visione più flessibile. In pratica, si è adottato lo standard per tutte le soluzioni che potevano essere risolte in questo modo. Per le problematiche che non potevano essere risolte con lo standard, si sono utilizzati sviluppi “custom” o soluzioni di terze parti integrate nel modo migliore possibile, tenendo conto dei processi di business del cliente e della sua organizzazione.
Il Business non si adatta, ma diventa centrale nella scelta delle funzionalità applicative
Fonte: Gartner Research Predicts 2023
Una visione aggiornata di tutto questo pone il problema di definire un ecosistema applicativo disegnato secondo le specificità del business e strumenti di integrazione API-based che fanno vedere l’insieme, anche eterogeneo, come una cosa sola.
Questo è il fondamento della trasformazione digitale.
Ora le applicazioni “composable” offrono una architettura di riferimento per questo ecosistema, il processo di migrazione deve diventare un’occasione di ripensamento verso l’API-first e quindi dell’uso delle funzionalità applicative, tra loro integrate, più idonee a rappresentare le necessità del business attraverso user-experience (una volta interfaccia utente) dedicata alla fase di processo che deve essere eseguita. Vedendo poi i vantaggi che questo approccio propone per il progetto di migrazione, diventa una cosa da fare prima o mentre, piuttosto che “ci pensiamo dopo”; come recita Gartner: “Composable is better” prima ci arrivi e meglio è!
