A un responsabile finanziario viene chiesto di rinviare la transizione da ECC perché «il supporto SAP dura abbastanza a lungo». Prima di accettare la proposta, il CIO deve accertare quali release installate siano coperte, in base a quale accordo e se il percorso di migrazione previsto resti realizzabile. Una data di fine manutenzione, da sola, non risponde a nessuna di queste domande.
Il risultato concreto della pianificazione della manutenzione SAP ECC deve essere un registro della copertura residua e una scadenza per la decisione sul finanziamento. Considera copertura del fornitore, sostenibilità operativa, obblighi di sicurezza e preparazione alla migrazione come approvazioni distinte. Il rinvio è credibile solo se queste approvazioni lo giustificano; l’avvio della migrazione è credibile solo se il programma ha un perimetro e un calendario realizzabili.
Accertare la copertura della singola release, non affidarsi alla scadenza generale
La sintesi commerciale SAP sulla manutenzione estesa distingue le release di SAP ERP 6.0: per i sistemi precedenti all’enhancement package 6, il supporto mainstream termina il 31 dicembre 2025, mentre gli enhancement package 6–8 hanno supporto mainstream fino al 31 dicembre 2027. Non attribuire la data successiva a ogni installazione ECC.
Parti da un inventario dei prodotti installati, sotto la responsabilità del team applicativo SAP. Registra la versione esatta del prodotto e l’enhancement package, quindi verifica la relativa scheda di manutenzione. SAP indica la Product Availability Matrix, o PAM, come riferimento per verificare le tempistiche di manutenzione dei singoli prodotti e delle relative versioni. Conserva la scheda utilizzata, la versione del documento quando disponibile e la data della verifica.
Usa la seguente scheda per ogni prodotto installato o dipendenza. Mantieni visibili le voci irrisolte, anziché assegnare una scadenza presunta all’intero parco sistemi.
| Campo del registro | Evidenze da conservare | Ruolo responsabile |
|---|---|---|
| Perimetro installato | Prodotto, release, enhancement package, installazione e processi aziendali supportati | Responsabile applicativo SAP |
| Stato della manutenzione | Scheda PAM corrispondente, date di copertura confermate e data della verifica | Responsabile della piattaforma SAP |
| Copertura contrattuale | Accordo di supporto applicabile, addendum, perimetro coperto e condizioni commerciali | Acquisti e ufficio legale |
| Situazione operativa e di sicurezza | Copertura delle dipendenze, requisiti di controllo, evidenze di ripristino ed eccezioni accettate | Responsabili operativi e della sicurezza |
| Dipendenze irrisolte | Impedimento, evidenze necessarie, responsabile della risoluzione e scadenza | Responsabile della migrazione |
| Calendario decisionale | Ultima data utile per decidere responsabilmente, scadenza per l’approvazione dei fondi e ipotesi alla base di entrambe | CIO e responsabile finanziario |
Le evidenze specifiche per versione devono guidare anche qualsiasi proposta di migliorare ECC rinviando la migrazione. Il quadro decisionale per investire nel miglioramento o nella sostituzione dell’ERP richiede prove riferite alla versione installata e alle condizioni commerciali pertinenti, anziché accettare una dichiarazione generica secondo cui il prodotto supporta un determinato flusso di lavoro. Applica lo stesso rigore alle affermazioni secondo cui il parco sistemi attuale può restare in servizio in sicurezza.
Distinguere la copertura acquistabile da una proroga presunta
La sintesi pubblicata da SAP descrive una manutenzione estesa opzionale dal 1° gennaio 2028 al 31 dicembre 2030. Per i clienti on-premises, richiede un addendum separato a un accordo di supporto SAP attivo e si applica all’intero perimetro commerciale delle applicazioni core di Business Suite 7. La disponibilità di un’opzione non dimostra che l’azienda l’abbia contrattualizzata.
La distinzione sul prezzo conta per il business case. SAP descrive un incremento di due punti percentuali sulla base di calcolo della manutenzione delle applicazioni core e degli add-on coperti, non un semplice aumento del due per cento della fattura di supporto esistente. Chiedi all’ufficio acquisti di riconciliare la base quotata e il perimetro coperto con il registro. Una voce di budget per il «supporto esteso» priva di spiegazioni non è un’ipotesi sufficiente.
Tieni separati gli accordi per la transizione successiva. Nelle sue indicazioni sulla pianificazione oltre la manutenzione estesa, SAP descrive Transition Option for SAP ERP come un abbonamento soggetto a condizioni, destinato a clienti grandi e complessi che soddisfano i requisiti e hanno già avviato la trasformazione, pensato per coprire il periodo 2031–2033. I sistemi devono essere trasferiti a SAP ERP, private edition su SAP HANA prima del 31 dicembre 2030; si applicano ulteriori requisiti di ammissibilità e sono escluse le funzionalità dipendenti da Java.
Non si tratta di una proroga incondizionata per un parco ECC on-premises lasciato invariato. Se una proposta di rinvio dipende da questa opzione, richiedi conferma di ammissibilità, disponibilità all’ordine, prezzo, funzionalità coperte e condizioni vincolanti prima di inserirla nel calendario approvato.
Ottieni poi decisioni distinte sul piano operativo e su quello della sicurezza. Chiedi ai responsabili operativi di dimostrare la capacità di ripristino e l’assegnazione delle responsabilità sulle dipendenze critiche. Chiedi alla sicurezza di identificare le correzioni e i controlli necessari, verificando se l’accordo di supporto proposto fornisca quanto richiesto da tali obblighi. Non lasciare che il diritto alla manutenzione sostituisca una di queste approvazioni.
Pianificare a ritroso dai vincoli del percorso di migrazione
L’ultima data utile per finanziare responsabilmente il programma va calcolata a partire dalle attività e dai vincoli, non sottraendo una durata generica di migrazione dalla scadenza della manutenzione. Definisci prima il percorso di transizione previsto e l’ambiente di destinazione. Richiedi poi al team di progetto di identificare prerequisiti, stime, sequenze e incertezze per quello specifico parco sistemi.
Un vincolo sul percorso di migrazione può essere decisivo indipendentemente dal diritto al supporto. SAP afferma che gli strumenti di conversione per i sistemi Business Suite 7 su database di terze parti saranno disponibili solo prima della scadenza dei relativi accordi di rivendita e supporto nel 2030. Successivamente saranno supportati soltanto scenari di transizione greenfield. Per un parco sistemi interessato da questo vincolo, una proposta di rinvio deve quindi spiegare se la conversione prevista resti realizzabile entro tale limite.
Chiedi al team di produrre un calendario basato sulle dipendenze che comprenda:
- Verifiche di compatibilità delle release e dell’ambiente di destinazione, inclusi add-on installati e applicazioni collegate.
- Valutazione del codice personalizzato e decisioni sul suo futuro, assegnando ai responsabili le decisioni aziendali ancora irrisolte.
- Preparazione dei dati, modifiche alle interfacce ed evidenze di accettazione end-to-end.
- Infrastruttura, approvazioni commerciali, capacità del personale interno e impegni di esecuzione.
- Prove di migrazione, finestre di cutover consentite, pianificazione del ripristino e stabilizzazione.
Sono requisiti di valutazione, non affermazioni secondo cui ogni programma richiede le stesse attività. Per le funzionalità personalizzate da mantenere, usa una valutazione separata della collocazione delle estensioni SAP per stabilire dove debbano essere eseguite. Riporta nel calendario gli impedimenti irrisolti e le relative stime, senza trasformare la pianificazione della manutenzione in una progettazione architetturale di dettaglio.
Procedi a ritroso lungo le dipendenze critiche, prevedendo margini esplicitamente approvati per le attività irrisolte. Registra quando devono essere resi disponibili i fondi, non soltanto quando dovrebbe terminare il programma. Se un prerequisito non ha un responsabile o una stima credibile, la data decisionale risultante resta provvisoria.
Scegliere tra l’avvio immediato e un rinvio a tempo determinato
Avviare ora è la scelta più solida quando la copertura verificata o i vincoli del percorso di migrazione lasciano spazio insufficiente al piano basato sulle dipendenze, oppure quando i requisiti per proseguire l’operatività non possono essere soddisfatti a condizioni accettabili. «Avviare» non significa necessariamente autorizzare subito l’intera implementazione. Quando un’incertezza rilevante potrebbe cambiare il percorso, finanzia una valutazione circoscritta con un risultato definito e un punto di decisione.
Un rinvio a tempo determinato è giustificabile quando la copertura contrattuale è confermata, i responsabili operativi e della sicurezza accettano gli obblighi residui e un calendario credibile costruito a ritroso preserva il percorso di transizione previsto. L’approvazione dovrebbe identificare che cosa guadagna l’azienda aspettando, che cosa deve finanziare durante il rinvio e quali eventi imporrebbero di anticipare la decisione.
Valuta entrambe le opzioni rispetto agli stessi risultati aziendali richiesti e allo stesso orizzonte di pianificazione. Nel caso del rinvio, includi gli interventi intermedi, la prosecuzione dell’operatività e la transizione futura. Per l’avvio immediato, richiedi ipotesi esplicite sulla capacità interna e sulle dipendenze di esecuzione, anziché considerare una partenza anticipata come prova di una minore esposizione.
Alla prossima decisione sul finanziamento, affianca il registro al calendario costruito a ritroso. Approva la migrazione, approva un rinvio con scadenza e condizioni oppure commissiona una valutazione circoscritta dell’incertezza specifica che impedisce di decidere. Non approvare una data di scadenza priva di riscontri.
Se devi tradurre questa decisione in pacchetti di lavoro funzionali e tecnici, confrontati sul parco sistemi, sulle dipendenze e sui requisiti di migrazione con gli specialisti SAP di Digiventi.
