Statement of work SAP: che cosa deve contenere

Uno statement of work (SOW) SAP è il documento contrattuale che dice che cosa consegnerà il partner, con quale effort, con chi e come può cambiare. Deve coprire il perimetro, ipotesi ed esclusioni dettagliate, l'effort per fase e per ruolo, i deliverable con i criteri di accettazione, le risorse nominate e il change control.

La maggior parte dei SOW copre il perimetro in modo sufficiente. Ciò che i clienti tralasciano spesso sono le ipotesi e le esclusioni dettagliate, ed è la sezione che decide quanto pagherà alla fine.

Questo articolo fa parte della mia guida su come scegliere un partner di implementazione SAP. Il SOW è l'ultimo passo di quel processo, dopo la RFP per il partner SAP e le presentazioni orali. Per un esempio concreto di revisione di un SOW prima della firma, legga il mio caso di studio sulla negoziazione dei contratti ERP.

Un buon SOW SAP si legge come un manuale operativo del programma. Chiunque dal Suo lato dovrebbe poterlo aprire e rispondere a tre domande: che cosa riceviamo, da che cosa dipende e che cosa succede quando qualcosa cambia.

Queste sono le sezioni necessarie, e che cosa va storto quando ne manca una:

Sezione	Che cosa deve dire	Che cosa succede se è scarna
Perimetro	Processi, moduli, società (company code), stabilimenti, paesi e utenti nel perimetro	Ogni workshop riapre la questione di che cosa fosse incluso
Ipotesi	Le condizioni da cui dipende il prezzo, ciascuna con una conseguenza se si rivela falsa	Il partner solleva richieste di modifica che Lei non può contestare
Esclusioni	Che cosa il partner non farà, e chi lo fa al suo posto	Il lavoro cade tra Lei e il partner, e nessuno se ne fa carico
Approccio e fasi	Il metodo, il piano per fasi e i quality gate	Nessun punto concordato in cui una fase è conclusa
Effort	Effort stimato per fase e per ruolo	Non può capire se il ritmo di consumo è in linea con il piano
Deliverable e accettazione	Documenti e output nominati, criteri di accettazione, periodo di approvazione	Si pagano fatture per lavoro parziale
Risorse	Persone chiave nominate, ruoli, allocazione e regole di sostituzione	Il team visto alle presentazioni orali non è il team sul campo
Responsabilità del cliente	Che cosa devono fornire le Sue persone, e quando	I ritardi causati dal Suo lato diventano richieste di modifica del partner
Change control	Come una modifica viene sollevata, valutata, quotata e approvata	Le richieste di modifica diventano una seconda linea di ricavo
Governance	Comitato guida, reporting, escalation	I problemi emergono tardi, quando costano cari

Scriva Lei il perimetro prima di chiedere i prezzi, così i partner quotano il Suo perimetro e non il loro.

Questa è la sezione che i clienti tralasciano spesso. Senza di essa, il prezzo poggia su condizioni che nessuno dal Suo lato ha letto o accettato.

Un'ipotesi è una condizione su cui il partner ha costruito il prezzo. Un'esclusione è un lavoro che il partner non ha quotato affatto. Entrambe devono essere abbastanza specifiche perché un terzo possa verificare se sono state rispettate.

Tipi di ipotesi da mettere per iscritto

Ogni ipotesi ha bisogno di una conseguenza. «Se si rivela falsa, la modifica passa dal change control con una valutazione d'impatto» trasforma un'ipotesi da decorazione in strumento di controllo.

Queste sono le categorie che un SOW SAP dovrebbe coprire:

1. Perimetro organizzativo. Il numero di company code, stabilimenti, organizzazioni commerciali, paesi e persone giuridiche coperti dal prezzo.
2. Perimetro dei processi. I processi di business nel perimetro, con il loro nome, e i processi standard SAP che il partner si aspetta che Lei adotti.
3. Volume WRICEF. Il numero di workflow, report, interfacce, conversioni, enhancement e form, per complessità. I budget saltano nella fase Explore man mano che questa lista cresce, quindi il conteggio di partenza va nel contratto.
4. Dati. Gli oggetti dati da migrare, il volume di storico, il numero di caricamenti di prova e chi pulisce i dati.
5. Integrazioni. Ogni interfaccia nominata, con il sistema dall'altra parte e chi modifica quel sistema.
6. Test. Il numero di cicli di test, chi scrive gli script, chi li esegue e chi corregge i difetti.
7. Disponibilità del cliente. Quali Sue persone servono, per quanta parte del loro tempo, e con quale rapidità vanno prese le decisioni.
8. Ambienti e licenze. Chi fornisce sistemi, strumenti e accessi, ed entro quando.
9. Sede e lingua. Dove lavora il team, il mix onshore e offshore, i viaggi e le lingue per documenti e formazione.
10. Formazione e hypercare. Il modello di formazione, il numero di formatori formati, e la durata e i criteri di uscita dell'hypercare.

La baseline WRICEF è quella che conta di più per il budget. Il materiale formativo di SAP descrive la fase Explore come un'analisi fit-to-standard, in cui i requisiti delta approvati vengono aggiunti al product backlog per la fase Realize (SAP Learning). Ogni delta approvato può diventare nuovo effort WRICEF, quindi serve il conteggio di partenza per misurarne la crescita.

Tipi di esclusioni da mettere per iscritto

Le esclusioni devono indicare chi fa il lavoro al posto del partner. «Escluso» senza un responsabile è un vuoto che aspetta di essere scoperto durante il cutover.

Queste sono le categorie abituali:

1. Pulizia e arricchimento dei dati nei sistemi legacy, spesso un compito del cliente.
2. Modifiche ai sistemi di terze parti e legacy dall'altra parte di un'interfaccia.
3. Licenze software e abbonamenti, che stanno nel Suo contratto con SAP, non nel SOW.
4. Infrastruttura e hosting, a meno che non sia esplicitamente il partner a gestirli.
5. Erogazione della formazione agli utenti finali, quando il partner forma solo i Suoi formatori.
6. Change management organizzativo oltre a quanto elencato.
7. Design di sicurezza, ruoli e autorizzazioni, se ne è responsabile un'altra parte.
8. Test di performance, penetration test e test di regressione al di fuori dei cicli nominati.
9. Paesi, società o localizzazioni non compresi nel perimetro organizzativo.
10. Supporto applicativo dopo l'hypercare, che è un contratto separato.

Legga le due liste una accanto all'altra con il Suo programme director. Tutto ciò che non compare in nessuna delle due è il punto da cui arriverà una richiesta di modifica.

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

Il prezzo fisso sembra più sicuro a un consiglio di amministrazione. In pratica il prezzo è fisso solo finché reggono tutte le ipotesi, e un programma SAP mette alla prova la maggior parte di esse entro la fine di Explore. Le mie note sul costo di un'implementazione SAP spiegano quando una fase a prezzo fisso può ancora avere senso.

Ecco come si confrontano i due modelli nel SOW:

Aspetto	Prezzo fisso	Time & material con effort quantificato
Che cosa fissa il contratto	Il prezzo, finché reggono le ipotesi	Le tariffe e l'effort stimato per fase e per ruolo
Dove sta il rischio	Il partner lo include nel prezzo come contingency	Su di Lei, ma visibile ogni mese
Quando il perimetro si muove	Ogni modifica diventa una negoziazione	L'effort si muove, e Lei lo vede rispetto alla stima
Che cosa può monitorare	Milestone e richieste di modifica	Effort effettivo rispetto al piano, per fase e per ruolo
Che cosa La protegge	Ipotesi ed esclusioni rigorose	Ipotesi ed esclusioni rigorose e reporting dell'effort

L'effort quantificato trasforma il time & material da assegno in bianco in un budget sotto controllo. Chieda la stima come tabella delle fasi per ruoli, in giornate uomo, e renda il reporting mensile su quella tabella un obbligo contrattuale.

Non lasci che le tariffe si nascondano nell'effort. Verifichi il mix di ruoli rispetto alle tariffe di mercato con la mia guida alla pianificazione delle risorse nei progetti SAP.

Un piano con molte giornate senior all'inizio e giornate junior più avanti è comune. Il contrario richiede una spiegazione.

Un deliverable è un output con un nome e una definizione di completamento. «Supporto al design» non è un deliverable. Un documento di solution design firmato per il processo record to report, verificato rispetto a criteri concordati, lo è.

Leghi l'accettazione ai quality gate

SAP Activate si articola in sei fasi: Discover, Prepare, Explore, Realize, Deploy e Run. SAP descrive quality gate formali dopo ogni fase, che verificano che i deliverable della fase siano completi prima che il progetto vada avanti (SAP Learning).

Usi quei gate nel SOW. Elenchi i deliverable previsti a ogni gate, i criteri di accettazione e il numero di giorni che ha per la verifica. Leghi il pagamento ai deliverable accettati, non al calendario.

Qualcuno dal Suo lato deve saper giudicare quei documenti. È uno dei tre momenti in cui raccomando di coinvolgere un consulente indipendente: durante la contrattualizzazione, per il design e per valutare i deliverable del partner. Il mio articolo su partner SAP o consulente indipendente spiega come lavorano insieme i due ruoli.

Nomini le persone, e le verifichi

La scarsa qualità delle risorse proposte è una delle due cose che mi fanno abbandonare un'offerta. L'altra è un partner che non sa spiegare l'architettura e il piano.

Il SOW deve nominare il solution architect, il programme manager e ogni lead funzionale e tecnico. Inserisca la loro allocazione, il Suo diritto di sottoporre a colloquio i sostituti e la Sua approvazione per ogni sostituzione. Il caso di studio sulla negoziazione dei contratti ERP mostra la clausola sulle risorse nominate nella pratica.

Verifichi le certificazioni invece di prendere un CV per buono. SAP rilascia i badge di certificazione tramite Credly, che consente una verifica in tempo reale (SAP Learning). Secondo il processo stay certified di SAP, una certificazione decade se il titolare salta la valutazione obbligatoria (SAP Learning).

Questa clausola conta più di quanto sembri. Ho cambiato un partner durante un programma, e il motivo era che il partner non riusciva a fornire risorse di qualità. La mia guida su come cambiare un partner SAP a progetto in corso spiega che cosa mettere al sicuro prima di arrivarci.

Il change control è il punto in cui un SOW scarno diventa costoso. Se le ipotesi sono vaghe, quasi tutto può essere presentato come una modifica.

Una sezione di change control funzionante ha bisogno di questi elementi:

1. Un evento scatenante. Una modifica esiste solo quando un'ipotesi salta, un'esclusione entra nel perimetro o Lei chiede qualcosa di nuovo.
2. Una valutazione d'impatto. Perimetro, effort per ruolo, tempi e costi, per iscritto, prima che inizi il lavoro.
3. Un listino tariffe. Le modifiche sono quotate alle tariffe contrattuali, senza maggiorazioni per urgenza salvo accordo.
4. Un livello di approvazione. Chi dal Suo lato può approvare modifiche fino a quale valore, con il CFO al di sopra di una soglia stabilita.
5. Un registro. Ogni modifica, approvata o respinta, riportata al comitato guida con il totale progressivo.
6. Un collegamento alla baseline. I nuovi oggetti WRICEF si misurano rispetto al conteggio indicato nelle ipotesi.

Il partner solleverà modifiche legittime. I programmi SAP scoprono cose che nessuno sapeva alla firma del contratto. L'obiettivo è che ogni modifica sia visibile, quotata e approvata prima che qualcuno spenda il denaro.

Nei 21 programmi SAP che ho guidato o recuperato, l'errore più grande che vedo è non pianificare bene all'inizio. Il SOW è il punto in cui quella pianificazione diventa vincolante, e il tempo dedicato a esso costa poco rispetto alle richieste di modifica contestate.

Il prossimo passo concreto: prenda il SOW che ha davanti ed elenchi ogni ipotesi ed esclusione su una sola pagina. Accanto a ciascuna, scriva che cosa succede se si rivela sbagliata e chi paga. Se non riesce a compilare quella colonna, il SOW non è pronto per la firma.

Se desidera una lettura indipendente di uno statement of work SAP prima della firma, aiuto i clienti proprio in questo durante la contrattualizzazione. Può contattarmi qui.

Che cosa deve includere uno statement of work SAP?

Perimetro, ipotesi dettagliate, esclusioni, approccio e fasi, effort stimato per fase e per ruolo, deliverable con criteri di accettazione, risorse nominate, responsabilità del cliente, change control e governance. La parte lasciata più spesso scarna sono le ipotesi e le esclusioni, ed è la parte che decide il costo finale.

Qual è la differenza tra ipotesi ed esclusioni in un SOW SAP?

Un'ipotesi è una condizione su cui il partner ha costruito il prezzo, come il numero di company code o di oggetti WRICEF. Un'esclusione è un lavoro che il partner non ha quotato affatto, come la pulizia dei dati legacy. Ogni ipotesi deve dire che cosa succede se si rivela falsa, e ogni esclusione deve indicare chi fa il lavoro al posto del partner.

Per un'implementazione SAP è meglio il prezzo fisso o il time & material?

Raccomando il time & material con l'effort quantificato: l'effort stimato per fase e per ruolo scritto nel contratto e monitorato ogni mese. Un prezzo fisso regge solo finché reggono tutte le ipotesi, e un programma SAP mette alla prova la maggior parte delle ipotesi durante la fase Explore.

Come si definiscono i criteri di accettazione per i deliverable SAP?

Nomini ogni deliverable, descriva come si presenta quando è completo e fissi un periodo di verifica per il Suo team. Li leghi ai quality gate di SAP Activate alla fine di ogni fase, e sblocchi il pagamento solo quando il deliverable è accettato.

Il SOW SAP deve nominare i consulenti?

Sì, per i ruoli chiave: solution architect, programme manager e i lead funzionali e tecnici. Aggiunga la loro allocazione, il Suo diritto di sottoporre a colloquio i sostituti e la Sua approvazione per ogni sostituzione. Verifichi le certificazioni tramite i badge SAP su Credly invece di affidarsi al CV.

Chi deve scrivere lo statement of work SAP?

Lo redige il partner, ma il perimetro e le ipotesi devono venire da Lei. Scriva il Suo perimetro prima di andare sul mercato, e faccia verificare ipotesi, esclusioni e deliverable da qualcuno indipendente dal partner prima della firma.