Recupero di progetti SAP: salvare un programma fuori rotta

Recuperare un progetto SAP significa fermare una migrazione o un'implementazione fuori rotta, scoprire cosa sia davvero vero al riguardo e ripianificare a partire da quella verità. La prima settimana decide se funziona: valutare lo stato del programma, esaminare la progettazione e valutare ciò che è davvero rilasciato nel sistema.

Risposta breve: se queste tre verifiche concordano tra loro e con il piano, il programma ha bisogno di una spinta, non di un salvataggio. Se non concordano, nessuno sforzo aggiuntivo sul piano attuale lo sistemerà, e serve un recupero formale con una nuova baseline.

Questo articolo parla di quella diagnosi e di ciò che segue. È uno dei capitoli della mia guida alla migrazione da ECC a S/4HANA, che tratta percorsi, tempi e scadenze. Qui la domanda è più ristretta: il Suo programma è in difficoltà, e adesso?

La maggior parte dei programmi in ritardo non ha bisogno di essere salvata. Ha bisogno di decisioni prese più in fretta, di un key user liberato da altri impegni o di un vendor tenuto a rispettare una data. Questa è una spinta.

Un salvataggio è un'altra cosa. I segnali vengono dalle stesse tre verifiche che faccio nella prima settimana, e il segnale è semplice: stato, progettazione e ciò che è rilasciato non concordano tra loro o con il piano.

Alcuni schemi che tratterei come segnali di salvataggio:

1. Lo stato è verde, il sistema no. I report dicono che la maggior parte della realizzazione è fatta, ma il sistema di test non riesce a eseguire un order to cash di base.
2. La progettazione è firmata, la realizzazione la ignora. La configurazione è stata fatta dagli appunti dei workshop, non dalla progettazione approvata.
3. Il piano ha una data di go-live, nessuno sa spiegare come arrivarci. Test, caricamenti dei dati e prove di cutover non hanno uno spazio realistico.
4. Il perimetro non fa che crescere. La lista WRICEF (report, interfacce, conversioni, enhancement, form e workflow) continua a salire molto dopo la fase Explore.

Ciascuno di questi si può risolvere con una spinta. Due o più insieme, di solito no.

La prima settimana serve a scoprire cosa è vero. Non a correggere, non a cercare colpevoli e non a scrivere un nuovo piano. Valuto tre cose, in quest'ordine: lo stato, la progettazione e ciò che è davvero rilasciato.

Ecco cosa copre ciascuna verifica e cosa Le dice un disaccordo:

Verifica	Cosa guardo	La domanda a cui risponde	Se non concorda con le altre
Stato del programma	Piano, report di stato, RAID log, change request aperte, spesa rispetto al budget	Cosa crede di sé il programma?	Il reporting è ottimista o scollegato dalla delivery
Progettazione	Progettazione dei processi di business, output del fit-to-standard, lista WRICEF, decisioni di progettazione aperte	Cosa è stato promesso al business?	La realizzazione si è allontanata da quanto concordato, o la progettazione non è mai stata finita
Ciò che è rilasciato	I sistemi di sviluppo e di test, configurazione, trasporti, codice custom, caricamenti dei dati fatti finora	Cosa esiste davvero oggi?	Sono stati riportati progressi su lavoro che non è nel sistema

La terza verifica è quella che la maggior parte delle revisioni salta. Significa sedersi davanti al sistema ed eseguire i processi, non leggere documenti sul sistema.

Report di stato e documenti di progettazione sono affermazioni. Il sistema è una prova.

Chi dovrebbe fare le verifiche

Chi ha scritto i report di stato non dovrebbe essere chi li verifica. Non è un'accusa. È lo stesso motivo per cui i revisori non revisionano il proprio lavoro.

Affiderei la prima settimana a qualcuno indipendente dal partner di implementazione, con pieno accesso ai sistemi e il diritto di parlare con chiunque nel programma. Se non è possibile, faccia almeno in modo che il partner Le mostri il sistema rilasciato dal vivo, non in slide.

Nel 2018 ho lavorato al recupero di un programma nel settore aereo. I moduli erano stati rilasciati, ma nulla era stato configurato in base ai requisiti di business.

È proprio la situazione che le tre verifiche della prima settimana servono a far emergere. Moduli rilasciati non equivalgono a una progettazione funzionante, e solo guardare dentro il sistema mostra la differenza.

Le compagnie aeree legano strettamente manutenzione, acquisti e finanza, quindi una lacuna in un'area si propaga. Spiego come SAP si adatta a quel settore nella mia pagina su SAP per il settore aereo.

Nei 21 programmi SAP che ho guidato o salvato, l'errore più grande che vedo è non pianificare bene all'inizio dell'implementazione. Un salvataggio spesso è quella pianificazione mancata, fatta tardi e sotto pressione.

Altre due cause ricorrono di continuo:

1. Il vendor controlla il perimetro. Quando è il system integrator a scrivere il perimetro, descrive ciò che l'integrator intende consegnare. Le lacune arrivano dopo come change request, quotate dallo stesso vendor.
2. Il codice custom sfora. Nella mia esperienza il codice custom è la fase della migrazione che sfora più spesso, ed è anche il costo nascosto che si dimentica di più.

Il lato del budget, compreso il motivo per cui è nella fase Explore che i costi fanno il salto, è trattato nel mio articolo sul perché i progetti SAP sforano il budget. Non lo ripeterò qui.

Un controllo debole è l'altro filo comune. Se il programma non ha mai avuto un ritmo settimanale di monitoraggio, escalation e change control, il salvataggio deve introdurlo. La mia guida a pianificazione e controllo dei progetti SAP definisce quella cadenza con i relativi responsabili.

Una volta che sa cosa è vero, il recupero ha una sequenza chiara. Saltare un passo di solito significa fare il salvataggio due volte.

La sequenza di recupero di un programma SAP

1. 01

   Diagnosticare

   Stato, progettazione e ciò che è rilasciato, confrontati tra loro.

2. 02

   Riprendere il perimetro

   Perimetro di proprietà del cliente, congelato, con ogni modifica quotata.

3. 03

   Nuova baseline

   Un unico nuovo piano costruito sulle prove, con la contingency dalla Sua parte.

4. 04

   Gate sulle fasi

   Un quality gate alla fine di ogni fase rimanente.

5. 05

   Provare ed eseguire il cutover

   Prove generali complete prima di confermare una data di go-live.

1. Riprendersi la responsabilità del perimetro

Prima che qualcuno ripianifichi, decida chi è responsabile del perimetro. Se la risposta è ancora il vendor, il nuovo piano fallirà nello stesso modo del vecchio.

Scriva il perimetro dalla parte del cliente, lo confronti con ciò che è rilasciato e lo congeli. Da quel momento, ogni modifica è una decisione quotata con un responsabile.

2. Una nuova baseline, una volta sola, sulla base delle prove

Un recupero ha una sola nuova baseline, non una serie di piccoli slittamenti. La costruisca da ciò che mostra il sistema, non da ciò che sperava il vecchio piano.

Ristimi per primo il codice custom, perché è da lì che arrivano più spesso gli sforamenti. Poi i dati, dato che la migrazione dei dati vale dal 30 al 40 percento dell'effort e in un programma in difficoltà di solito è in ritardo.

Tenga dal 10 al 20 percento di contingency dalla Sua parte, rilasciata solo a fronte di rischi specifici. Il mio articolo collegato sui costi della migrazione a S/4HANA spiega cosa determina i numeri.

3. Un quality gate alla fine di ogni fase

I programmi in difficoltà di solito sono passati da una fase all'altra in base alle date e non alle prove. Corregga questo punto.

In SAP Activate, la fase Explore prevede i workshop fit-to-standard, e i requisiti delta approvati entrano nel product backlog per Realize. Se il programma è uscito da Explore senza una progettazione finita, torni indietro e la finisca. SAP Cloud ALM supporta i quality gate come checkpoint con checklist, visibili nella panoramica del progetto, quindi il gate non deve vivere in un foglio di calcolo.

4. Provare prima di impegnarsi su una data

In una conversione brownfield pianifico tre mock conversion prima del cutover. I programmi in difficoltà spesso tagliano le prove per guadagnare tempo, il che sposta il rischio sul weekend del go-live.

Il fermo del cutover che ho visto va da un weekend a una settimana. Un programma salvato dovrebbe conoscere il proprio numero da una prova, non da una stima.

5. Verificare la scadenza a cui si lavora davvero

Per SAP ERP 6.0 sugli enhancement package da 6 a 8, la manutenzione standard termina il 31 dicembre 2027, con manutenzione estesa opzionale fino alla fine del 2030 a fronte di una maggiorazione di due punti percentuali (SAP News). Un recupero che spinge una migrazione da ECC oltre il 2027 dovrebbe mettere apertamente a budget la manutenzione estesa.

Non lasci che la data del 2027 imponga un go-live che le prove non sostengono. Un go-live in ritardo costa canoni di manutenzione. Uno fallito costa molto di più.

Un salvataggio solleva spesso la domanda se tenere l'attuale system integrator. A volte sostituire il partner è giusto. Spesso il problema più grande è come è stato impostato il programma, e un nuovo partner lo eredita.

Queste sono le domande che farei prima di decidere:

1. Potete mostrarci il sistema rilasciato, dal vivo, rispetto alla progettazione firmata? Non un ambiente demo e non delle slide.
2. Quali oggetti WRICEF sono realizzati, testati e trasportati, e quali sono solo riportati come completati?
3. Qual è la vostra progettazione di alto livello per arrivare in fondo, e quali referenze possiamo chiamare in cui avete recuperato un programma come il nostro? Referenze e progettazione di alto livello sono le due cose che chiedo a qualsiasi partner prima di firmare.
4. Cosa vi serve da noi che non state ricevendo? Decisioni mancanti e key user a tempo parziale sono spesso metà della storia.
5. Per i clienti RISE with SAP: quali problemi dipendono da SAP e non dal partner, e chi ne gestisce l'escalation?

Il segnale d'allarme è lo stesso che mi fa scartare un partner in fase di selezione: le risposte generiche. Se il piano di recupero potrebbe valere per qualsiasi azienda, non è stato scritto per la Sua. La mia guida su come scegliere un partner per la migrazione a S/4HANA tratta il lato della selezione.

Se il programma non ha mai avuto un assessment adeguato del sistema di origine, lo faccia adesso. Il SAP Readiness Check analizza il Suo sistema esistente, e SAP raccomanda di eseguirlo in produzione per avere un quadro accurato dell'uso reale. Il mio articolo su SAP Readiness Check e assessment della migrazione spiega cosa non vede, a partire dagli oggetti custom.

Fissi mezza giornata con il Suo programme director e il responsabile SAP, e chieda loro di mostrarLe tre cose una accanto all'altra: l'ultimo report di stato, la progettazione firmata e il sistema di test che esegue un processo di business completo. Se le tre raccontano la stessa storia, spinga. Se non è così, avvii un recupero formale prima del prossimo steering committee.

Se desidera un parere indipendente su un programma fuori rotta, aiuto le organizzazioni proprio con questo tipo di diagnosi. Può prenotare una chiamata con me.

Che cos'è il recupero di un progetto SAP?

Il recupero di un progetto SAP è il lavoro con cui si riporta sotto controllo un'implementazione o una migrazione SAP fuori rotta. Parte da una diagnosi dello stato del programma, della progettazione e di ciò che è davvero rilasciato, poi riprende la responsabilità del perimetro, fissa un'unica nuova baseline e aggiunge quality gate alle fasi rimanenti.

Come capire se il mio progetto SAP ha bisogno di un salvataggio?

Confronti tre cose: cosa dicono i report di stato, cosa dice la progettazione firmata e cosa è davvero rilasciato nel sistema. Se concordano tra loro e con il piano, il programma ha bisogno di una spinta. Se non concordano, più sforzo sul piano attuale non lo sistemerà e serve un recupero formale.

Cosa dovrebbe succedere nella prima settimana del recupero di un'implementazione SAP?

Solo diagnosi. Valuti lo stato del programma, esamini la progettazione e valuti ciò che è davvero rilasciato, idealmente sotto la guida di qualcuno indipendente dal partner di implementazione. Non scriva il nuovo piano finché queste tre verifiche non sono concluse.

Dobbiamo sostituire il nostro partner di implementazione SAP durante un recupero?

Non automaticamente. Chieda al partner di mostrare il sistema rilasciato rispetto alla progettazione firmata, e di darLe una progettazione di alto livello per arrivare in fondo, con referenze di recuperi simili.

Se le risposte sono generiche, è un segnale forte per cambiare. Se il vero problema è la responsabilità del perimetro o la mancanza di decisioni dalla Sua parte, un nuovo partner lo erediterà.

Perché le migrazioni a SAP S/4HANA vanno fuori rotta?

La causa di fondo più comune che vedo è non pianificare bene all'inizio dell'implementazione. Lasciare che sia il vendor a controllare il perimetro è un'altra, e il codice custom è la fase che sfora più spesso. Anche la migrazione dei dati, che vale dal 30 al 40 percento dell'effort, di solito è in ritardo.

Un recupero spingerà la nostra migrazione da ECC oltre la scadenza del 2027?

Può darsi. La manutenzione standard di SAP ERP 6.0 sugli enhancement package da 6 a 8 termina il 31 dicembre 2027, e la manutenzione estesa opzionale arriva alla fine del 2030 con una maggiorazione di due punti. Metta a budget la manutenzione estesa invece di imporre un go-live che le Sue prove non sostengono.