Come cambiare il partner di implementazione SAP a progetto in corso

Per cambiare il partner di implementazione SAP a progetto in corso, prima verifichi che il problema sia davvero il partner, poi metta al sicuro ogni documento, design, porzione di codice e accesso ai sistemi prima di comunicarglielo. Solo allora selezioni il sostituto e gestisca un passaggio di consegne pianificato, con un periodo di sovrapposizione.

In breve: cambi quando il partner non riesce a darLe persone di qualità e non riesce a rimediare. Non cambi per sfuggire a problemi che stanno dal Suo lato, perché un nuovo partner li eredita.

Questo articolo fa parte della mia guida su come scegliere un partner di implementazione SAP. Quella guida tratta la scelta del partner all'inizio. Questa tratta che cosa fare quando il partner scelto non funziona.

Ho cambiato un partner durante un programma. Il motivo era la qualità delle risorse: il partner non riusciva a fornire persone di qualità quando il programma ne aveva bisogno.

È il segnale che metterei al primo posto. Un programma può riprendersi da una fase andata male, da una data mancata o da un design debole. Fa fatica a riprendersi da un partner che non riesce a mettere persone capaci sul lavoro.

Questi sono i segnali su cui vale la pena agire, più o meno nell'ordine in cui li peserei:

1. Scarsa qualità delle persone sul campo. I consulenti che fanno il lavoro non sono le persone che Le erano state presentate, oppure non sanno rispondere a domande di base sulla loro area.
2. Ripetuta incapacità di sostituire le persone. Qualcuno se ne va e il sostituto impiega settimane ad arrivare, oppure arriva con meno esperienza.
3. Nessuno sa spiegare l'architettura e il piano. Chieda al lead del partner di illustrarLe il design target e il percorso fino al go-live. Se non ci riesce, nessuno sta guidando la delivery.
4. Deliverable che non reggono a una verifica. Design, script di test e documenti di sviluppo scarni, copiati da un altro cliente o mancanti.
5. Risposte generiche a problemi specifici. Lo stesso segnale d'allarme della selezione: risposte che potrebbero valere per qualsiasi azienda.

Una fase in ritardo, uno sforamento in Explore o un comitato guida teso non sono, da soli, motivi per cambiare.

Prima di sostituire chiunque, scopra se il partner è davvero la causa. La mia guida al recupero di un programma SAP descrive le tre verifiche che faccio per prime: lo stato del programma, il design e ciò che è effettivamente rilasciato nel sistema.

Quella diagnosi mostra spesso che il problema è condiviso. I budget saltano in Explore man mano che cresce la lista WRICEF (workflow, report, interfacce, conversioni, enhancement e form). Se ha lasciato al partner il controllo del perimetro, o se i Suoi key user non sono mai stati liberati per il programma, un nuovo partner finisce nella stessa buca.

Quindi si ponga onestamente due domande:

1. Un team forte di questo partner risolverebbe il problema? Se sì, e il partner può fornire quel team in fretta, un cambio di persone potrebbe bastare.
2. Un partner diverso affronterebbe gli stessi problemi? Se sì, sistemi prima perimetro, decisioni e governance dal Suo lato.

Se la risposta alla prima domanda è no, perché il partner non trova le persone, ha la Sua risposta. La disponibilità di persone di qualità non è qualcosa che si risolve con una modifica al contratto.

Questa è la parte che la maggior parte dei clienti sbaglia. Annunciano la decisione, e il loro potere negoziale sparisce con essa.

Il partner uscente detiene le conoscenze che Le servono per sostituirlo. Finché quelle conoscenze non sono nelle Sue mani, tenga la decisione all'interno di un gruppo ristretto: lo sponsor, il CFO, il programme director e il Suo responsabile legale o acquisti.

Parta dal contratto attuale. Legga la clausola di recesso, il periodo di preavviso, la proprietà dei deliverable e qualsiasi previsione sul trasferimento di conoscenze o sull'assistenza in uscita. Se il Suo statement of work (SOW) non dice nulla sull'uscita, il mio articolo su che cosa deve contenere uno statement of work SAP spiega che cosa scrivere nel prossimo.

Ecco che cosa mettere al sicuro, e dove si trova di solito:

Che cosa mettere al sicuro	Perché conta	Dove dovrebbe trovarsi	Come proteggerlo
Design e decisioni firmati	Il nuovo partner ci costruisce sopra invece di ricominciare	Il Suo repository documentale o SAP Cloud ALM	Copi subito le ultime versioni approvate, con le evidenze di approvazione
Lista WRICEF e specifiche	La baseline del perimetro e il backlog di sviluppo	SAP Cloud ALM o il Suo repository	Esporti la lista con lo stato di ogni oggetto
Codice custom e configurazione	Il lavoro reale fatto finora	I Suoi sistemi di sviluppo e di test	Verifichi che tutto sia nei Suoi sistemi, non sulle macchine del partner
Script e risultati dei test	La prova di ciò che funziona davvero	Il Suo strumento di test o SAP Cloud ALM	Esporti script, risultati e difetti aperti
Lavoro sulla migrazione dati	Mappature, regole di pulizia, programmi di caricamento	Cartelle condivise e i Suoi sistemi	Raccolga dal team dati i documenti di mappatura e i programmi di caricamento
Accessi ai sistemi e al supporto SAP	Il controllo del Suo landscape e del Suo account di supporto SAP	I Suoi sistemi e SAP for Me	Elenchi ogni utente del partner, pronto da rimuovere il giorno stesso
Problemi aperti e rischi	Ciò che il prossimo team deve prendere in carico per primo	Registro RAID e report di stato	Faccia una copia datata del registro RAID

Tenga i contenuti di progetto nei Suoi strumenti

La protezione più pulita è strutturale. Tenga i documenti, i requisiti e le evidenze di test del programma in strumenti di Sua proprietà, dal primo giorno di qualsiasi programma.

SAP Cloud ALM aiuta in questo. I clienti con SAP Enterprise Support, o con RISE with SAP, possono richiedere un proprio tenant senza costi aggiuntivi, uno per numero cliente, secondo le FAQ di SAP su Cloud ALM. Se la documentazione di progetto è nel Suo tenant, resta a Lei quando un partner se ne va.

Pianifichi il cambio degli accessi per il giorno dell'annuncio

I consulenti del partner hanno spesso S-user ID sul Suo account di supporto SAP, oltre a utenze nei Suoi sistemi. Gli S-user ID sono controllati dai Suoi amministratori in SAP for Me.

La guida di SAP alla gestione degli utenti dice che gli amministratori del cliente sono responsabili della cancellazione degli ID degli utenti che se ne sono andati. Dice anche che gli ID con funzioni speciali, come destinatario del software o contatto tecnico, non possono essere cancellati finché SAP non trasferisce quella funzione a qualcun altro. Scopra ora quali utenti del partner hanno quelle funzioni e le sposti prima sulle Sue persone.

Una volta che il materiale è al sicuro e il sostituto è stato scelto, avvisi il partner uscente. Lo faccia per iscritto, in linea con il contratto, e concordi il piano di uscita nella stessa riunione.

Un passaggio di consegne funziona meglio in questo ordine:

Cambiare partner SAP a metà programma

1. 01

   Mettere al sicuro

   Documenti, design, codice, accessi e registro RAID nelle Sue mani prima che qualcuno venga avvisato.

2. 02

   Selezionare

   Referenze su progetti simili e il team reale alle presentazioni orali, con l'effort quantificato.

3. 03

   Sovrapposizione

   I lead uscenti ed entranti lavorano fianco a fianco su un trasferimento di conoscenze strutturato.

4. 04

   Riconvalidare

   Il nuovo partner verifica design, sviluppo e test rispetto a ciò che è rilasciato.

5. 05

   Nuova baseline

   Un unico nuovo piano basato sulle evidenze, approvato prima che inizi la fase successiva.

Selezioni il sostituto come si deve

La tentazione è correre, perché il programma brucia denaro mentre Lei sceglie. Una selezione completa richiede circa 12 settimane secondo la mia esperienza, con almeno tre partner in shortlist. Un sostituto scelto sotto pressione può arrivare prima, ma non salti i passaggi che La proteggono.

Quando scelgo un partner per un cliente, do il peso maggiore alle referenze dei clienti. Nelle chiamate con le referenze chiedo dell'esperienza del partner su progetti come quello dell'acquirente. A metà programma, significa chiedere alle referenze di subentri in lavori avviati da un'altra società.

Due cose mi fanno abbandonare un'offerta: la scarsa qualità delle risorse proposte e un partner che non sa spiegare l'architettura e il piano. Dopo un cambio causato dalla qualità delle risorse, applichi entrambi i test con più rigore, non con meno.

Chieda ai candidati i badge di certificazione delle persone che propongono. SAP rilascia i suoi badge di certificazione su Credly, come spiega la sua pagina di aiuto sui badge digitali. Un badge conferma che un esame è stato superato, quindi verifichi l'esperienza anche tramite le referenze.

Le mie guide su come scrivere una RFP per un'implementazione SAP e sui partner di implementazione SAP per fascia coprono il resto della selezione.

Contrattualizzi il nuovo partner in modo diverso

Il modello commerciale che raccomando è il time & material, con l'effort quantificato. Il contratto indica l'effort stimato per fase e per ruolo, così può confrontare ogni mese l'effort effettivo con quello stimato.

Lo statement of work ha bisogno anche di ipotesi ed esclusioni dettagliate. I clienti le tralasciano spesso, e in un subentro contano ancora di più, perché il nuovo partner vorrà escludere i problemi che ha ereditato.

Nomini anche le persone chiave nel contratto. Le mie note sulla negoziazione dei contratti ERP spiegano la clausola sulle risorse nominate e perché impedisce che le persone senior spariscano dopo la firma.

Sovrapposizione, poi riconvalida

Pianifichi un periodo in cui i lead uscenti ed entranti lavorano insieme. Il team uscente ripercorre ogni area di design, ogni difetto aperto e ogni oggetto sviluppato a metà, con il team entrante che fa domande.

Poi lasci che il nuovo partner riconvalidi ciò che esiste. Si aspetti che trovi delle lacune, e si aspetti che alcune di quelle scoperte siano una posizione negoziale per ottenere più effort. È qui che vale la pena avere un parere indipendente sui deliverable del partner uscente.

Collochi il subentro nella fase di SAP Activate in cui si trova. SAP descrive sei fasi: Discover, Prepare, Explore, Realize, Deploy e Run (SAP Activate).

Un cambio durante Explore costa soprattutto rilavorazione del design. Un cambio durante Realize costa anche rilavorazione di sviluppo e test, perché il codice va capito prima di poterlo completare.

Non esiste un cambio gratuito. Non indicherò una cifra, perché dipende dalla fase, dalla qualità di ciò che è stato consegnato e da quanto collabora il partner uscente.

Questi sono i costi da mettere a budget:

1. Sovrapposizione. Paga due team durante il passaggio di consegne.
2. Riconvalida e rilavorazione. Il nuovo partner verifica design, configurazione e codice, e una parte viene rifatta.
3. Uscita dal contratto. Periodi di preavviso, condizioni di recesso ed eventuali pagamenti per il lavoro in corso, come stabilisce il Suo contratto.
4. Impegno per la selezione. Il tempo del Suo team su RFP, presentazioni orali e chiamate con le referenze.
5. Il tempo delle Sue persone. I key user ripetono workshop e test che pensavano conclusi.
6. Ritardo. Ogni settimana di ritardo tiene in funzione più a lungo i vecchi sistemi e il Suo team interno.

Li confronti con il costo di restare. Un partner che non riesce a fornire il personale per il programma non diventa più economico man mano che il programma diventa più difficile, e Realize, test e cutover sono più difficili di ciò che è venuto prima.

Consiglio ai clienti di coinvolgere un consulente indipendente in tre momenti: la contrattualizzazione, il design e la valutazione dei documenti e dei deliverable del partner. Un cambio di partner li tocca tutti e tre insieme.

Un revisore indipendente può dirLe quanto valgono davvero i deliverable del partner uscente prima che il nuovo partner quoti la rilavorazione. Può anche verificare il contratto del partner entrante e la sua lettura del design. Il mio articolo su partner SAP o consulente indipendente spiega chi fa che cosa.

Questa settimana, scopra dove si trovano davvero i Suoi design firmati, la lista WRICEF, le evidenze di test e il codice custom, e chi controlla l'accesso a ciascuno. Lo faccia che stia pensando di cambiare o no. Se qualcosa si trova solo presso il Suo partner, ne sposti una copia in sistemi di Sua proprietà.

Se sta valutando un cambio di partner e desidera un parere indipendente sui deliverable o sul contratto, può parlarne con me qui.

Si può cambiare partner di implementazione SAP a metà progetto?

Sì. Prima verifichi nel contratto le condizioni di recesso, di preavviso e di proprietà dei deliverable. Metta al sicuro design, codice, evidenze di test e accessi ai sistemi prima di annunciare la decisione, poi gestisca un passaggio di consegne pianificato con un periodo di sovrapposizione.

Quando conviene cambiare partner di implementazione SAP?

Cambi quando il partner non riesce a fornire persone di qualità e non riesce a rimediare, oppure quando i suoi lead non sanno spiegare l'architettura e il piano. Non cambi solo perché una fase è finita in ritardo. Prima faccia una diagnosi, perché i problemi di governo del perimetro o delle Sue decisioni La seguiranno da un nuovo partner.

Che cosa ottenere dal partner SAP prima di recedere dal contratto?

Design firmati e registri delle decisioni, e la lista WRICEF con lo stato di ogni oggetto. Codice custom e configurazione nei Suoi sistemi, script e risultati dei test, mappature della migrazione dati e il registro RAID. Elenchi anche ogni utente del partner nei Suoi sistemi e nel Suo account di supporto SAP, così gli accessi possono essere rimossi il giorno stesso.

Quanto costa cambiare partner SAP a progetto in corso?

Non esiste una cifra standard. Metta a budget la sovrapposizione tra i due team, riconvalida e rilavorazione, le condizioni di uscita dal contratto, il Suo impegno per la selezione e il ritardo. Più la fase è avanzata, più rilavorazione c'è, perché codice e test vanno capiti prima di poterli completare.

Quanto tempo serve per sostituire un partner di implementazione SAP?

Una selezione completa del partner richiede circa 12 settimane secondo la mia esperienza, con almeno tre partner in shortlist. Un sostituto scelto sotto pressione può arrivare prima, ma mantenga le chiamate con le referenze e le presentazioni orali con il team reale.

Di chi sono i documenti e il codice di un'implementazione SAP?

Lo decide il Suo contratto, quindi verifichi la clausola sulla proprietà dei deliverable. In pratica, si protegga tenendo i documenti nel Suo repository o nel Suo tenant SAP Cloud ALM, e codice e configurazione nei Suoi sistemi SAP invece che sui server del partner.