Come scegliere un partner per la migrazione a S/4HANA

Per scegliere un partner per la migrazione da SAP ECC a S/4HANA, usi le designazioni dei partner SAP per costruire una long list, poi decida su due elementi: referenze di migrazioni simili alla Sua e la progettazione di alto livello del partner per la Sua azienda. Scarti qualsiasi partner che dia risposte generiche, e tenga Lei il controllo del perimetro.

Risposta breve: il badge porta un partner nella Sua lista. Sono le referenze e la progettazione a fargli ottenere il contratto.

Questo articolo è una parte della mia guida alla migrazione da ECC a S/4HANA, che tratta percorsi, tempi e scadenze. Qui tratto solo la scelta del partner. È la decisione che plasma la maggior parte di ciò che segue, perché il partner che sceglie proporrà il percorso, il piano e il perimetro.

Un partner di migrazione non è lo stesso acquisto di un partner di implementazione. In una conversione brownfield compra competenza nella conversione tecnica, correzione del codice custom, preparazione dei dati e un cutover che funzioni al primo colpo. In un greenfield compra anche la progettazione dei processi.

La maggior parte dei processi di selezione non lo coglie. Confrontano tariffe giornaliere e slide sulla metodologia, quando il lavoro vero sta in pochi punti che le slide mostrano di rado:

1. Codice custom. Nella mia esperienza è la fase della migrazione che sfora più spesso, e il costo nascosto che le aziende dimenticano di più.
2. Dati. La migrazione dei dati assorbe dal 30 al 40 percento dell'effort nei programmi che ho visto.
3. Cutover. In un brownfield pianifico tre mock conversion prima di quella vera, e il fermo che ho visto va da un weekend a una settimana.
4. Progettazione. Le scelte di progettazione che il partner propone nei primi mesi decidono i Suoi costi per gli anni successivi.

Quindi la domanda non è «quale partner è il migliore». È quale partner sa mostrarLe, con prove, come gestirà queste quattro aree per il Suo sistema.

SAP gestisce il suo programma partner, SAP PartnerEdge, su un framework di competency. Quando SAP lo ha introdotto nel 2022, ha definito sette competency con tre livelli ciascuna, essential, advanced ed expert, con specializzazioni a livello di prodotto o di processo all'interno di ogni competency. I partner le ottengono in base a conoscenza esperta, successo dei clienti e competenza dimostrata.

Queste designazioni compaiono in SAP Partner Finder, dove si possono cercare e filtrare i partner. Nel suo aggiornamento di PartnerEdge di gennaio 2025, SAP ha detto che la competenza pesa ora ancora di più nel determinare i livelli dei partner.

Per RISE with SAP esiste un riconoscimento separato. Il riconoscimento RISE with SAP Validated Partner, introdotto a giugno 2024, richiede il livello expert in diverse competency. Tra queste ci sono RISE with SAP S/4HANA Cloud Private Edition, SAP Business Technology Platform e SAP Business Process Transformation.

La descrizione del riconoscimento pubblicata da SAP a luglio 2025 aggiunge il lato della delivery. Chiede la RISE with SAP Methodology in tutti i team di delivery, persone certificate nei ruoli chiave e quality gate di Clean Core documentati in SAP Cloud ALM.

Ecco cosa Le dice, e cosa non Le dice, ciascun segnale:

Segnale	Cosa conferma	Cosa non conferma
Livello di competency (essential, advanced, expert)	La società ha la conoscenza, i progetti consegnati e i risultati sui clienti che SAP misura in quell'area	Che le persone proposte per il Suo programma abbiano fatto quel lavoro
Specializzazione	Risultati in un prodotto o processo SAP specifico	Profondità nel Suo settore o nel Suo tipo di migrazione
RISE with SAP Validated Partner	Competency expert, la metodologia RISE e i gate di Clean Core in SAP Cloud ALM	Che il partner capisca il Suo codice custom, i Suoi dati o la Sua chiusura contabile
Presenza in SAP Partner Finder	La società è un partner SAP registrato con designazioni visibili	Nulla sull'adeguatezza

Usi i badge come filtro. Un partner senza alcuna competency pertinente non dovrebbe stare in una lista per una grande migrazione. Un partner con tutti i badge deve comunque superare i due test qui sotto.

Come condurrei la scelta del partner

1. 01

   Valutare

   Esegua il SAP Readiness Check e dimensioni codice custom e dati prima di andare sul mercato.

2. 02

   Possedere il perimetro

   Scriva il perimetro e le decisioni che vuole prendere, così i partner rispondono ai Suoi fatti.

3. 03

   Long list

   Usi le designazioni SAP e Partner Finder per trovare società con competency pertinenti.

4. 04

   Verificare

   Verifichi le referenze e chieda a ogni partner in shortlist una progettazione di alto livello.

5. 05

   Contratto

   Leghi pagamenti e modifiche del perimetro alla progettazione che ha verificato.

Quando do consulenza sulla scelta di un partner, per me decidono due cose: le referenze e la progettazione di alto livello del partner. Tutto il resto nella proposta è materiale di supporto.

Referenze di migrazioni simili alla Sua

Una referenza è utile solo se corrisponde alla Sua situazione. Una referenza di un greenfield in un altro settore dice ben poco a un'azienda manifatturiera che fa un brownfield.

Chieda referenze che corrispondano su tre aspetti, poi le chiami Lei stesso:

1. Il percorso. Brownfield, greenfield o selettivo, lo stesso del Suo.
2. La scala. Un numero simile di società, paesi e oggetti custom.
3. Le persone. Chieda alla referenza chi ha guidato il lavoro, poi verifichi se quelle persone sono nella Sua proposta.

Durante la chiamata, chieda quanti oggetti custom c'erano all'inizio e alla fine, quante mock conversion sono state eseguite e cosa è andato storto al cutover. Una referenza che non sa rispondere a queste domande non era abbastanza vicina al lavoro.

La loro progettazione di alto livello per la Sua azienda

Il secondo test consiste nel chiedere a ogni partner in shortlist una progettazione di alto livello del Suo sistema S/4HANA di destinazione prima di firmare. Consegni loro i risultati del Readiness Check e il perimetro che ha scritto, poi chieda come gestirebbero i Suoi processi, il Suo codice custom e i Suoi dati.

Una buona progettazione di alto livello nomina le Sue società, i Suoi processi critici e gli oggetti custom che contano. Dice cosa dismetterebbero, cosa terrebbero e perché. Mostra come strutturerebbero i caricamenti dei dati e il cutover.

È anche qui che vede se il partner sa mantenere un Clean Core. Le personalizzazioni vanno ridotte al minimo e governate bene. Se la progettazione cerca di far funzionare SAP come il Suo vecchio sistema, quella è l'abitudine che fa salire i costi a ogni upgrade futuro.

Il segnale d'allarme che mi fa andar via è l'informazione generica. Una proposta, o risposte alle Sue domande, che non sono specifiche per la Sua azienda.

La riconoscerà. La proposta descrive la metodologia nel dettaglio e la Sua azienda in un paragrafo. Alle domande sul Suo codice custom si risponde parlando di «acceleratori».

Il piano ha le stesse fasi e le stesse durate che ha visto il mese scorso nella presentazione di un'altra società.

Le risposte generiche significano una di due cose. Il partner non ha fatto il lavoro per capirLa, oppure non intende farlo prima che Lei firmi. In entrambi i casi, la vera progettazione verrà fatta con il Suo budget durante Explore.

Il test è semplice. Prenda ogni risposta e sostituisca il nome della Sua azienda con quello di un concorrente. Se si legge ancora correttamente, non era stata scritta per Lei.

La causa di fondo che vedo dietro la maggior parte dei problemi di budget delle migrazioni è lasciare che siano i vendor a controllare il perimetro. I budget vengono colpiti nella fase Explore, man mano che crescono gli oggetti WRICEF (workflow, report, interfacce, conversioni, enhancement e form). Il partner che scrive il perimetro scrive anche le change request.

Non è questione di cattive intenzioni. L'incentivo commerciale di un partner è partire, e aggiungere lavoro quando lo trova. Il Suo incentivo è finire entro il numero che ha dato al consiglio di amministrazione.

Sono mestieri diversi, e il perimetro spetta alla parte che paga.

In pratica, tenga la responsabilità del perimetro dalla Sua parte in quattro modi:

1. Scriva il perimetro prima di andare sul mercato. Lo basi sul Suo Readiness Check e sulla Sua analisi del codice custom, non sul workshop di discovery del partner.
2. Istituisca una design authority. Business e IT insieme, con il diritto di approvare o respingere ogni nuovo oggetto WRICEF.
3. Fissi una baseline della lista WRICEF. Conti gli oggetti alla firma del contratto e riporti il conteggio a ogni steering committee.
4. Leghi il contratto alla progettazione che ha verificato. Le modifiche rispetto a quella progettazione passano dal change control, con una motivazione e un costo.

Pianifichi comunque gli sforamenti. Terrei una contingency dal 10 al 20 percento, e ricordi che i servizi valgono dal 35 al 50 percento del costo totale del programma. La mia guida ai costi della migrazione a S/4HANA mostra cosa determina il numero per percorso, e le mie note sulla negoziazione dei contratti ERP trattano le condizioni commerciali.

La mia risposta qui è breve: dipende dalle referenze.

Un SI globale senza una referenza brownfield comparabile nel Suo settore è una scelta più debole di una boutique che ne ha fatte tre. Una boutique senza referenze alla Sua scala è una scelta più debole di un SI che ne ha. La dimensione della società Le parla di profondità della squadra e di copertura, e le referenze Le dicono se le persone sanno fare la Sua migrazione.

Ho scritto a parte sui partner di implementazione SAP negli Stati Uniti per fascia, con i punti di forza di ciascuna fascia e dove tende a cedere. Non ripeterò qui gli elenchi, e non stilo classifiche di partner. Usi quell'articolo per capire i compromessi, poi applichi i due test qui sopra a chiunque sia nella Sua shortlist.

Un'ultima osservazione sulla dimensione. Molti grandi programmi usano più di un partner, per esempio un prime per la migrazione principale e uno specialista per la selective data transition o il codice custom. Funziona quando il perimetro è Suo e un solo partner è responsabile dell'integrazione.

Prima di inviare una sola richiesta di offerta, esegua l'assessment. Un SAP Readiness Check e un assessment di migrazione Le danno i fatti su codice custom, dati e simplification item a cui i partner dovrebbero rispondere. Senza, ogni partner colma il vuoto con le proprie ipotesi, e Lei non può confrontare le risposte.

Se ha già firmato e il programma sta slittando, le domande sono diverse. La mia guida al recupero dei programmi SAP spiega cosa verificare per primo.

Nei 21 programmi SAP che ho guidato o salvato, l'errore più grande che vedo è non pianificare bene all'inizio. La scelta del partner è il punto in cui quella pianificazione comincia. Se desidera un parere indipendente su una shortlist o su una proposta, aiuto le organizzazioni proprio in questo, e può contattarmi qui.

Come scegliere un partner per la migrazione a SAP S/4HANA?

Usi le competency di SAP e Partner Finder per costruire una long list di partner con competenze pertinenti. Poi decida in base a referenze di migrazioni simili alla Sua e alla progettazione di alto livello di ciascun partner per la Sua azienda. Scarti i partner che danno risposte generiche, e mantenga la responsabilità del perimetro.

Che cos'è un RISE with SAP Validated Partner?

È un riconoscimento che SAP ha introdotto nel 2024 per i partner che realizzano progetti di cloud ERP grandi e complessi. I partner validati hanno il livello expert in diverse competency SAP, tra cui RISE with SAP S/4HANA Cloud Private Edition. SAP si aspetta anche la RISE with SAP Methodology, persone certificate nei ruoli chiave e quality gate di Clean Core documentati in SAP Cloud ALM.

Per una migrazione a S/4HANA conviene un grande SI o una boutique?

Dipende dalle referenze. Scelga la società le cui persone hanno fatto una migrazione simile alla Sua, sullo stesso percorso, a una scala simile e in un settore simile. La dimensione della società Le parla di profondità della squadra e di copertura, non di quanto il team sappia fare la Sua migrazione.

Quali domande porre a un partner SAP prima di firmare?

Chieda referenze di migrazioni comparabili e le chiami Lei stesso. Chieda una progettazione di alto livello del Suo sistema di destinazione, basata sui risultati del Readiness Check e sul Suo perimetro. Chieda come dimensioneranno e ridurranno il codice custom, quante mock conversion prevedono e chi, esattamente, lavorerà sul Suo programma.

Quali sono i segnali d'allarme nella scelta di un partner di implementazione SAP?

Il principale è l'informazione generica: una proposta o risposte che potrebbero valere per qualsiasi azienda. Altri sono un piano identico a tutti gli altri, risposte vaghe su codice custom e dati, e un partner che vuole definire il perimetro nel proprio workshop di discovery dopo la firma.

Un badge di partner SAP expert garantisce una migrazione riuscita?

No. I livelli di competency SAP confermano conoscenza, progetti consegnati e risultati sui clienti a livello di società. Non confermano che le persone proposte per il Suo programma abbiano fatto quel lavoro, né che il partner capisca il Suo codice custom e i Suoi dati.

Usi i badge per filtrare, poi verifichi referenze e progettazione.