Oltre il “Codice Z”: Il Clean Core come Unica Via per l’Innovazione Sostenibile in SAP.

Negli ultimi tempi, confrontandomi con società sia clienti che fornitori dell’ecosistema SAP, parlando di Clean Core ho avuto l’impressione che l’importanza di questa strategia sia nettamente sottostimata.   Ho generalmente visto come tutto il focus sia portato sulla contrattualistica e sulla migrazione e meno su cosa ci aspetta a migrazione avvenuta.  Nell’offerta RISE with SAP, che viene proposta in forma molto aggressiva rispetto al vecchio on-premise, il ruolo del clean core viene riportato addirittura nel contratto. In effetti l’aggiornamento annuale del sistema è obbligatorio, ma affinché questo possa avvenire in tempi brevi e in modo sostenibile dal team di supporto di SAP, è necessario che il core sia il più possibile pulito dal codice custom.  In una situazione di clienti consolidati è normale che vi sia tanto codice custom: programmi Z, user exit, tabelle Z,  fino a inopportune modifiche del codice delle transazioni standard SAP.   Il processo di migrazione più diffuso, il “Brownfield” conservativo, non è compatibile con il concetto di Clean Core, accorcia i tempi di progetto perché evita i lunghi e complessi impatti organizzativi, ma poi al primo upgrade cosa succede?  Probabilmente il solito progetto lungo e costoso, solo da farsi ogni anno, una frequenza sconosciuta in passato. Almeno con l’on-premise quest’obbligo non c’è.  La spinta commerciale propone il “lift and shift”  prima passa al cloud poi metterai a posto le cose.  L’esperienza mi dice che una volta eseguita la migrazione andare a rivedere il codice per renderlo “pulito”  è un’attività che oltre a non trovare budget (consumato dalla migrazione) non trova le ragioni se non dopo un upgrade riuscito molto male. 

Una tabella che spiega la differenza tra situazione RISE e On-Premise 

Il Cuore del Problema é che il Clean Core NON è un’Opzione, ma un Imperativo, NON è un “nice to have” è il Fondamento della Nuova Delivery SAP: RISE with SAP.

Vediamo alcune caratteristiche: 

Contratto e SLA: Con RISE, SAP si assume la responsabilità tecnica di mantenere il sistema aggiornato. Questo è contrattualmente ed economicamente sostenibile per SAP solo se il core è standard. Un “Dirty Core” renderebbe ogni aggiornamento un progetto a sé, rischioso e costoso, facendo fallire l’intero modello a subscription. 

Velocità di Innovazione: Il valore di S/4HANA Cloud non è la singola release, ma il flusso costante di innovazioni (due major release all’anno). Un “Dirty Core” blocca l’azienda, costringendola a saltare gli aggiornamenti per paura di rompere il codice custom. Di fatto, si paga per un’innovazione continua che non si riesce ad assorbire.

Time-to-Market: Oggi il business chiede di implementare nuove idee (un nuovo modello di pricing, un’integrazione con un partner, una nuova app per i venditori) in settimane, non in mesi. Con un “Dirty Core”, ogni modifica richiede analisi di impatto infinite, test a tappeto e regression test. Con il Clean Core, le estensioni sulla SAP Business Technology Platform (BTP) o su altri modelli di integrazione basati su API  sono disaccoppiate e possono essere sviluppate e modificate rapidamente, senza toccare il “cuore” del sistema.

 Il Debito Tecnico si Paga con gli Interessi: Il “Dirty Core” è debito tecnico. Ogni riga di codice custom è un costo nascosto che si manifesta a ogni upgrade, a ogni patch di sicurezza, a ogni nuova richiesta di modifica.

 Focus delle Risorse: Invece di spendere il 70% del budget IT per “tenere le luci accese” (manutenzione del custom code), il Clean Core permette di spostare risorse e investimenti sull’innovazione che crea valore e differenziazione (le app su BTP o su altri modelli di integrazione).

Dati tutti questi elementi che fare?   Vediamo una tabella di decisione: