RFP per un'implementazione SAP: cosa chiedere e come valutare

Una RFP per un'implementazione SAP deve chiedere ai partner prove, non promesse: referenze su progetti simili, i CV delle persone che metteranno sul progetto e un'architettura e un piano per il Suo perimetro. Valuti le offerte con pesi fissati prima che arrivino, poi usi le presentazioni orali per verificare che il team di delivery sappia spiegare il piano.

In breve: la RFP mette alla prova le persone e il piano, non le slide sulla metodologia.

Questo articolo copre solo la fase della richiesta di offerta (RFP). L'intero processo di selezione, dalla long list al contratto, è nella mia guida su come scegliere un partner di implementazione SAP.

Nei 21 programmi SAP che ho guidato o recuperato, l'errore più grande che vedo è non pianificare bene all'inizio. Una RFP SAP inviata prima di conoscere il proprio perimetro invita ogni partner a riempire i vuoti con le proprie ipotesi. Poi non può confrontare le offerte, perché ognuna quota un programma diverso.

Quindi l'ordine conta. Definisca il perimetro, i processi inclusi ed esclusi, le società e i paesi, le integrazioni e i dati, poi scriva la RFP attorno a questo.

Il perimetro protegge anche il budget più avanti. I budget saltano nella fase Explore di SAP Activate, dove il metodo SAP prevede workshop di fit-to-standard e registra i gap nel backlog.

È lì che cresce la lista WRICEF (workflow, report, interfacce, conversioni, enhancement e form), e ogni nuovo oggetto è un costo. Una RFP costruita sul Suo perimetro Le dà una baseline con cui misurare quella crescita.

Invii la RFP a una shortlist di almeno tre partner.

Costruisca la long list da SAP Partner Finder, dove SAP mostra le competency che i partner detengono in SAP PartnerEdge, ciascuna su tre livelli: essential, advanced ed expert. Un badge fa guadagnare un posto nella lista. Non fa guadagnare il contratto.

L'intera selezione richiede circa 12 settimane dall'inizio alla fine.

Come si svolge la fase di RFP SAP

1. 01

   Perimetro

   Scriva Lei perimetro, processi, società, integrazioni e dati prima che un partner li veda.

2. 02

   RFP

   Invii un unico pacchetto a una shortlist di almeno tre partner, con i pesi di punteggio già fissati.

3. 03

   Offerte scritte

   Valuti ogni offerta rispetto ai pesi e segnali ogni risposta generica.

4. 04

   Presentazioni orali

   Chieda al team di delivery proposto di spiegare di persona architettura e piano.

5. 05

   Referenze

   Chiami referenze su progetti come il Suo e chieda dell'esperienza del partner su quei progetti.

6. 06

   Contratto

   Porti l'effort, le persone nominate e le ipotesi dell'offerta vincente nello statement of work.

Una RFP SAP ha due metà: ciò che Lei dà ai partner e ciò che chiede loro di restituire.

Cosa dare ai partner

Dia a ogni partner lo stesso pacchetto nello stesso momento. Più il pacchetto è buono, più le risposte sono specifiche:

1. Contesto e obiettivi. Perché implementa SAP, che cosa deve saper fare l'azienda dopo e le date che contano.
2. Perimetro. Processi inclusi ed esclusi, società, paesi, utenti per gruppo e i prodotti SAP che prevede di usare.
3. Integrazioni e dati. I sistemi a cui SAP deve collegarsi, gli oggetti dati da migrare e ciò che sa della loro qualità.
4. Il Suo team. Chi può mettere sul programma, per quanta parte del loro tempo, e quali ruoli si aspetta che copra il partner.
5. Il formato di risposta. Una struttura fissa e un limite di pagine, per confrontare offerte omogenee.
6. I criteri di valutazione e i pesi. Dica ai partner come verranno valutati. Li spinge a rispondere alle domande che contano.
7. Il calendario. Scadenza per le domande, scadenza per le offerte, le date delle presentazioni orali e la data della decisione.

Cosa chiedere ai partner

La maggior parte delle RFP SAP chiede ai partner di descrivere sé stessi, e i partner sono molto bravi a farlo. Chieda invece cose che può verificare:

1. Referenze su progetti simili. Stessi prodotti SAP, scala simile, settore simile, con un contatto che può chiamare.
2. Il team di delivery nominato. CV, il ruolo di ogni persona, la quota del loro tempo sul Suo programma e la loro disponibilità nelle Sue date.
3. Certificazioni verificabili. SAP rilascia le certificazioni come badge digitali che consentono una verifica in tempo reale. Chieda i link ai badge delle persone nominate, non il numero di certificati della società.
4. L'architettura e il piano. Un design di alto livello per il Suo perimetro e un piano per fase di SAP Activate con milestone e dipendenze.
5. Effort per fase e per ruolo. Giornate stimate per ogni ruolo in ogni fase, non solo un prezzo totale.
6. Ipotesi ed esclusioni in dettaglio. Tutto ciò da cui dipende il prezzo e tutto ciò che non copre.
7. Il modello commerciale e il listino tariffe. Tariffe per ruolo e per sede di delivery, viaggi e spese, e come verranno quotate le modifiche.
8. Come controlleranno la crescita del perimetro in Explore. Il loro metodo per gestire i nuovi oggetti WRICEF e chi li approva.

Sul modello commerciale, raccomando il time & material con l'effort quantificato. L'effort stimato per fase e per ruolo entra nel contratto, così può confrontare ogni mese l'effort effettivo con quello stimato. Chiederlo nella RFP è ciò che lo rende possibile dopo.

Sulle tariffe, non ancori i partner a un numero. Chieda il loro listino e lo confronti con le forchette della mia guida alla pianificazione delle risorse nei progetti SAP.

Ipotesi ed esclusioni sono ciò che i clienti tralasciano più spesso in uno statement of work (SOW). Se la RFP le chiede in dettaglio, le ha prima di negoziare. La mia guida allo statement of work SAP mostra come passano nel contratto.

Fissi i pesi prima che arrivino le offerte e non li cambi dopo aver letto le risposte. Cambiare i pesi dopo è il modo in cui si sceglie un favorito e lo si giustifica a posteriori.

Quando aiuto un cliente a scegliere un partner, le referenze dei clienti hanno il peso maggiore. Due cose mi fanno abbandonare un'offerta, qualunque sia il totale: la scarsa qualità delle risorse proposte e un partner che non sa spiegare l'architettura e il piano. Il punteggio deve riflettere entrambe.

La tabella qui sotto è un esempio di ponderazione costruito su queste priorità. Adatti le percentuali al Suo programma, ma tenga le referenze al primo posto e mantenga i due criteri di esclusione.

Criterio	Peso di esempio	Come si presenta un punteggio alto	Segnale per abbandonare
Referenze	30%	Progetti simili, contatti raggiungibili, referenze che confermano il ruolo del partner	Nessuna referenza su un progetto comparabile, o referenze che il partner non La lascia chiamare
Qualità delle risorse	25%	Persone nominate con CV pertinenti, certificazioni verificabili e disponibilità confermata	Ruoli senza nome, CV scarni o persone chiave «salvo disponibilità»
Architettura e piano	25%	Un design per il Suo perimetro e un piano per fasi con milestone, dipendenze e rischi	Un piano generico, o un design che non sanno spiegare nelle presentazioni orali
Commerciale	10%	Effort per fase e per ruolo, tariffe chiare, ipotesi ed esclusioni dettagliate	Un unico prezzo totale senza effort dietro
Approccio	10%	Un metodo chiaro per controllo del perimetro, test, dati e trasferimento di conoscenze	Slide di metodologia senza nulla di specifico per Lei

Valuti ogni criterio su una scala semplice, per esempio da 1 a 5, con una motivazione scritta. Ogni valutatore assegna prima i punteggi da solo, poi il gruppo li confronta.

Tratti i due segnali per abbandonare come soglie di sbarramento, non come punti. Un'offerta con condizioni commerciali forti non può ricomprarsi un team debole. Il commerciale ha un peso basso di proposito: la tariffa giornaliera è una variabile piccola rispetto all'effort e alle rilavorazioni.

L'offerta scritta mostra ciò che sa scrivere il team di gara. Le presentazioni orali mostrano se le persone che faranno il lavoro lo hanno capito.

Chieda le persone che lavoreranno davvero sul Suo programma, per nome. Il solution architect, il programme manager e i lead dei Suoi stream più grandi devono essere nella stanza. Se il partner porta un team diverso, lo annoti nel punteggio.

Poi chieda loro di spiegare l'architettura e il piano per il Suo perimetro, se possibile senza slide. Domande utili:

1. Ci illustri il design per i nostri due processi più complessi. Ascolti se compaiono i nomi dei Suoi processi, delle Sue società e dei Suoi sistemi.
2. Che cosa succede in Explore se la lista WRICEF cresce di un terzo? Ascolti se c'è un metodo, una sede decisionale e una discussione sui costi.
3. Quali ipotesi della vostra offerta portano più rischio? Un partner che conosce il proprio piano le nomina subito.
4. Chi in questo team lo ha già fatto, e dove? Poi verifichi la risposta nelle chiamate con le referenze.
5. Di che cosa avete bisogno dal nostro team, e quando? Un piano reale ha dipendenze dal cliente con date.

Un partner che non sa spiegare la sua architettura e il suo piano nella stanza non li realizzerà sul campo. È il secondo motivo per cui abbandono un'offerta.

Ho cambiato un partner durante un programma perché non riusciva a fornire risorse di qualità. La disponibilità di persone valide è la cosa da verificare con più rigore prima di firmare.

Chiamate con le referenze

Le chiamate con le referenze sono importanti e spesso vengono fatte come una formalità. Le faccia sul serio. Quello che chiedo alle referenze è la loro esperienza con il partner su progetti simili al Suo.

Prima della chiamata, confronti la referenza con il Suo programma: stessi prodotti, scala simile, settore simile. Se la corrispondenza è debole, chieda al partner un'altra referenza.

Durante la chiamata, chieda chi del partner ha guidato il lavoro, che cosa ha fatto bene e dove ha avuto difficoltà. Poi chieda se quelle persone sono nella Sua offerta.

Come riconoscere le risposte generiche

Le risposte generiche sono il segnale d'allarme in qualsiasi RFP SAP. Una risposta che si potrebbe inviare a qualsiasi azienda è stata scritta per qualsiasi azienda.

Il test più rapido è sostituire in una risposta il nome della Sua azienda con quello di un concorrente. Se la risposta resta corretta, non è stata scritta per Lei. La mia guida su come scegliere un partner per la migrazione a S/4HANA approfondisce quel test per le migrazioni.

In una risposta a una RFP, le risposte generiche compaiono di solito in questi punti:

1. La sezione sul perimetro Le ripete la Sua RFP. Non aggiunge alcuna opinione su ciò che è difficile nel Suo programma.
2. Il piano usa durate tonde per ogni fase. Nulla dipende dalle Sue società, dai Suoi dati o dalle Sue integrazioni.
3. Alle domande sui Suoi processi rispondono parlando di acceleratori. Lo strumento ha un nome, il suo uso per Lei no.
4. I rischi valgono per tutto il settore. Compaiono «qualità dei dati» e «resistenza al cambiamento», e nulla di specifico sui Suoi sistemi.
5. La sezione sul team elenca ruoli, non persone. Di solito è lo stesso problema delle risorse deboli, detto con altre parole.

Dia un punteggio basso a una risposta generica anche quando è ben scritta.

Valutare i documenti del partner è anche il momento in cui aiuta un parere indipendente. Un advisor che non partecipa alla gara può mettere alla prova il design e le stime di effort, e più avanti i deliverable. I compromessi sono trattati nel mio confronto tra partner SAP e consulente indipendente.

Prima di qualsiasi altra cosa, metta per iscritto il Suo perimetro. Una pagina per area di processo, con ciò che è incluso, ciò che è escluso, le società e i sistemi coinvolti. Senza di esso, ogni numero delle offerte poggia sulle ipotesi del partner.

Per i nomi dei partner per fascia, veda la mia guida ai partner di implementazione SAP negli USA per fascia.

Se desidera un parere indipendente su una RFP, sul punteggio o sulle offerte ricevute, aiuto le organizzazioni proprio in questo. Può contattarmi qui.

Che cosa deve contenere una RFP per un'implementazione SAP?

Dia ai partner il contesto e gli obiettivi, il perimetro, le integrazioni e i dati, il team che può mettere a disposizione, un formato di risposta fisso, i criteri di valutazione e il calendario. Chieda loro referenze su progetti simili e il team di delivery nominato con i CV. Chieda un'architettura e un piano per fase di SAP Activate, l'effort per fase e per ruolo e ipotesi ed esclusioni dettagliate.

Come si valutano le offerte dei partner di implementazione SAP?

Fissi criteri ponderati prima che arrivino le offerte: referenze, qualità delle risorse, architettura e piano, commerciale e approccio. Ogni valutatore assegna i punteggi da solo su una scala semplice con una motivazione scritta, poi il gruppo li confronta. Consideri risorse deboli e un piano che il partner non sa spiegare motivi per scartare un'offerta, qualunque sia il punteggio totale.

A quanti partner inviare una RFP SAP?

Almeno tre. Costruisca la long list da SAP Partner Finder e dai livelli di competency SAP, poi metta in shortlist i partner con referenze pertinenti.

Quanto dura la selezione di un partner SAP?

Circa 12 settimane dall'inizio alla fine, dalla long list al contratto. La RFP in sé è solo una parte. Le presentazioni orali, le chiamate con le referenze e la trasformazione dell'offerta vincente in uno statement of work occupano la maggior parte del tempo.

Una RFP SAP deve chiedere il prezzo fisso o il time & material?

Raccomando il time & material con l'effort quantificato. Chieda a ogni partner l'effort stimato per fase e per ruolo e lo scriva nel contratto, così può confrontarlo con l'effort effettivo. Un unico prezzo totale senza effort dietro non si può né confrontare né monitorare.

Quali sono i segnali d'allarme in un'offerta di un partner SAP?

Risposte generiche che potrebbero valere per qualsiasi azienda, una sezione sul team con ruoli ma senza persone nominate, un piano con le stesse durate viste altrove e un'architettura che il partner non sa spiegare nelle presentazioni orali. Un partner che non La lascia chiamare le sue referenze è un altro segnale d'allarme.