Modello di business case SAP: approvazione senza ritardi

Un business case SAP viene approvato quando chi decide vede il problema, il costo, il ritorno e il rischio su una sola pagina, nei propri termini. Usi la struttura in sette sezioni qui sotto, includa ogni costo per almeno cinque anni, mantenga prudenti le ipotesi sui benefici e scriva passaggi distinti per il CFO, per l'IT e per il business. La maggior parte dei business case che si bloccano fallisce nella presentazione, non nell'idea.

Ho visto approvazioni trascinarsi per settimane, a volte per mesi, anche con un'idea solida. Ricordo una migrazione a S/4HANA in cui la prima proposta non funzionò. Era piena di diagrammi dell'architettura di sistema e diceva quasi nulla sui vantaggi operativi. La riscrivemmo aprendo con la riduzione dei ritardi nelle spedizioni, il calo dei costi di magazzino e il modo in cui il team avrebbe eseguito il lavoro. Il CFO la approvò in una sola riunione.

Un'ultima cosa prima del modello. Il Suo partner di implementazione non dovrebbe scrivere il Suo business case. Il suo incentivo è avviare il programma. Il Suo è portarlo a termine. È così che i programmi da 40 milioni di dollari diventano, senza che nessuno se ne accorga, programmi da 90 milioni.

L'executive summary decide l'esito

Una sola pagina. I dirigenti potrebbero non leggere altro.

Si parte dal problema, in numeri. La proposta in una o due frasi, senza dettagli tecnici. Poi i benefici principali con le cifre, una tempistica semplice, l'investimento totale e i rischi principali con le relative mitigazioni.

In una delle aziende che ho seguito in passato, il riepilogo si apriva con espressioni come «oggetti tecnici» ed «Embedded HANA». Il CFO lo posò dopo il primo paragrafo. Lo riscrivemmo partendo da «2,5 milioni di dollari di risparmi annui sui costi grazie alla riduzione delle scorte» e da «elaborazione degli ordini più veloce del 40%». Lo stesso CFO lesse l'intera pagina e approvò il progetto quella settimana.

Quando il riepilogo è pronto, lo dia a qualcuno esterno al progetto. Se riesce a rispiegarglielo, funziona.

Scrivere per tre lettori

Una versione unica per tutti non funziona. Ho visto proposte solide morire perché scritte per il pubblico sbagliato.

CFO e consiglio di amministrazioneITUtenti di business

Che cosa cercanoCFO e consiglio di amministrazioneNumeri che possano ripetere senza appuntiITPerimetro di integrazione mappato sui sistemi attualiUtenti di businessUn quadro attività per attività della loro settimana

Che cosa dare loroCFO e consiglio di amministrazioneRisparmi annui e payback, con i rischi dichiarati senza giri di paroleITIl modello di supporto dopo il go-liveUtenti di businessPrima e dopo, con un tempo di formazione onesto

Che cosa li convinceCFO e consiglio di amministrazioneFranchezza invece di ottimismoITLa prova che Lei sa dove sono andati storti progetti similiUtenti di businessOnestà su ogni clic in più

Il CFO e il consiglio di amministrazione vogliono numeri che possano ripetere senza appunti: «2 milioni di dollari di risparmi annui, payback in 18 mesi». Vogliono i rischi dichiarati con chiarezza. Con questo pubblico la franchezza batte l'ottimismo.

L'IT vuole il perimetro di integrazione mappato sui sistemi attuali, il modello di supporto dopo il go-live e la prova che Lei sa dove sono andati storti progetti simili.

Gli utenti di business vogliono un quadro, attività per attività, della propria settimana prima e dopo, e un numero onesto per il tempo di formazione. Un piccolo clic in più, ripetuto migliaia di volte a settimana, diventa un problema vero.

Una volta un CFO ha respinto un business case a metà riunione perché non rispondeva a nessuna delle sue domande. Lo abbiamo ricostruito in tre sezioni, una per ogni pubblico, e ancorato ciascuna a KPI misurabili. Il piano tecnico non è mai cambiato. È cambiato solo il modo di raccontarlo.

Queste sono le sette sezioni che uso, in quest'ordine. Ricordo un'azienda manifatturiera in cui il CFO trovò i dettagli dei costi sepolti a pagina 23, mentre il CIO non riusciva a trovare affatto i rischi tecnici. L'approvazione slittò di sei mesi. Con una versione strutturata ci vollero due settimane, e il contenuto era cambiato appena.

Sezione	Che cosa deve contenere
Executive summary	Problema in numeri, proposta, benefici, investimento totale, tempistica, rischi principali
Situazione attuale	Punti critici, il loro costo oggi e il costo dell'inazione
Approccio proposto	Perimetro, moduli, modello di deployment (RISE, GROW o on-premise), integrazioni principali
Analisi finanziaria	Costi e benefici a cinque anni, ROI, payback, VAN per i programmi più grandi
Piano di implementazione	Fasi, milestone, team, dipendenze
Rischi	Rischi specifici con responsabili e mitigazioni
Governance	Sponsor, steering committee, controllo delle modifiche, regole di approvazione delle estensioni

Diagrammi dell'architettura e dettagli di configurazione vanno in un'appendice.

I costi che un direttore finanziario cercherà

I costi incompleti uccidono più business case dei benefici deboli. Includa tutte queste voci:

1. Software: licenza più supporto annuale per l'on-premise, oppure la sottoscrizione per RISE e GROW.
2. Onorari del partner di implementazione.
3. Infrastruttura, se la gestisce Lei; con RISE la gestisce SAP all'interno della sottoscrizione.
4. Tempo del personale interno. È la voce che manca più spesso.
5. Formazione e change management.
6. Migrazione e pulizia dei dati.
7. Supporto ricorrente. Per l'on-premise, SAP Enterprise Support vale da tempo circa il 22% del valore della licenza all'anno. Per RISE e GROW, mostri la sottoscrizione per ogni anno della durata contrattuale.
8. Hypercare dopo il go-live.

La voce 7 è la prima che molti direttori finanziari controllano. Se mancano gli anni dal secondo al quinto, la credibilità cala subito. La mia guida ai costi di implementazione SAP riporta gli intervalli tipici per ogni voce, e la mia guida alla revisione dei contratti per i CFO tratta il lato del partner.

ROI, payback e benefici a cui il CFO crede

Il ROI è il beneficio netto diviso per l'investimento totale. Benefici a cinque anni per 3,5 milioni di dollari a fronte di costi per 2 milioni sono un beneficio netto di 1,5 milioni, cioè il 75%.

Il payback è l'investimento diviso per il beneficio netto di cassa annuo. Un progetto da 1,2 milioni di dollari che rende 400.000 dollari l'anno rientra in tre anni.

Il VAN (valore attuale netto, NPV) attualizza i flussi di cassa futuri al valore di oggi. Se il consiglio lo chiede, porti in sala il Suo team finanziario.

Quantifichi i benefici mostrando i calcoli:

• Scorte: 10 milioni di dollari di scorte, ridotte del 15% con un costo di mantenimento del 20%, fanno risparmiare 300.000 dollari l'anno.
• Tempo di processo: un'attività da 45 minuti eseguita 200 volte al giorno, ridotta a 15 minuti, a 30 dollari l'ora, fa risparmiare circa 750.000 dollari l'anno su 250 giorni lavorativi.

Mostri un ramp-up. I benefici del primo anno dopo il go-live sono di solito inferiori a quelli a regime. I benefici che non riesce a quantificare vadano in un elenco a parte, così da non diluire quelli che può quantificare.

Sia prudente. Ho visto aziende ottenere l'approvazione di progetti SAP difficili essendo brutalmente oneste sui costi e prudenti sui benefici. Un cliente manifatturiero aveva presentato all'inizio un ROI del 30% per il suo progetto S/4HANA. Dopo le contestazioni, rivide il business case portandolo a un più realistico 18%. Il CFO apprezzò la franchezza e lo approvò.

La sottoscrizione sostituisce licenza e supporto. RISE e GROW sono sottoscrizioni, quindi il primo anno costa meno dell'acquisto di una licenza on-premise. Il totale a cinque anni dipende da utenti, perimetro e durata. Mostri gli anni uno, tre e cinque affiancati.

Cambia la contabilità, non solo la cassa. Secondo gli IFRS, un contratto cloud spesso dà accesso a un software invece di un'attività software che si controlla. In questo caso, la decisione dell'agenda del 2021 dell'IFRS Interpretations Committee comporta che i costi di configurazione e personalizzazione siano di solito imputati a conto economico man mano che i servizi vengono ricevuti, anziché capitalizzati. Questo può spostare gran parte del costo del programma dallo stato patrimoniale al conto economico. Concordi con i revisori il trattamento del Suo contratto RISE o GROW prima che l'analisi finanziaria vada al consiglio.

Il Clean Core cambia il costo a lungo termine. Le estensioni costruite su interfacce rilasciate costano di più da progettare, ma sopravvivono agli aggiornamenti. Le modifiche costano meno oggi e sono care a ogni aggiornamento successivo. Un modello a cinque anni dovrebbe mostrare questa differenza, soprattutto sulla Private Edition, dove il core può ancora essere modificato.

L'AI entra nel business case solo con ipotesi a livello di workflow. Joule e altre funzioni di AI possono far risparmiare tempo in attività specifiche. Leghi ogni beneficio dell'AI a un workflow preciso, a un numero di utenti e a un tasso di adozione che sappia difendere. I CFO vedono ogni settimana proposte del tipo «l'AI trasformerà il business» e le scontano pesantemente.

Lasciare fuori il costo dell'inazione. Se il sistema attuale causa 500.000 dollari l'anno di rilavorazioni, questa cifra va nel business case. A volte supera l'investimento in SAP.

Ignorare i disagi operativi. Il tempo di formazione, il fermo del cutover e un primo mese lento dopo il go-live riducono tutti il ritorno.

Rischi vaghi. «Problemi di dati» non è un rischio. «Incongruenze nei dati anagrafici che causano il rifiuto di fatture nei primi 30 giorni» lo è.

Una sola data di go-live, senza dettaglio. I ritardi di solito nascono nei passaggi di consegne: dai requisiti alla configurazione, dai test all'accettazione, dalla formazione alla prontezza. Li mostri.

Ignorare le dimensioni dell'azienda. In un progetto a cui ho lavorato, un piccolo distributore aveva copiato il processo di governance di una grande corporation. Le riunioni settimanali di steering diventarono ore di produttività persa, finché il processo non fu snellito. Sotto i 200 dipendenti bastano 8-10 pagine. Le grandi imprese si aspettano una modellazione finanziaria completa e una sezione di governance dettagliata.

Ho lavorato con un team manifatturiero che ha impiegato sei mesi per ottenere l'approvazione. Ha rivisto il business case quattro volte, perché ogni versione rispondeva a un approvatore diverso e ignorava gli altri. Scrivere fin dall'inizio per tutti e tre i lettori avrebbe fatto risparmiare quasi tutto quel tempo. Una volta ottenuta l'approvazione, il documento successivo è il project charter.

Che cosa deve includere un business case SAP?

Sette sezioni: un executive summary, la situazione attuale e il costo dell'inazione, l'approccio proposto e il modello di deployment, un'analisi finanziaria a cinque anni con ROI e payback, un piano di implementazione, rischi specifici con i responsabili e un modello di governance. I dettagli tecnici vanno in un'appendice.

Perché i business case SAP vengono respinti?

Di solito perché i benefici sono vaghi o i costi incompleti, soprattutto il supporto ricorrente o gli anni successivi della sottoscrizione. Altre cause frequenti: rischi minimizzati, oppure un documento scritto per un solo pubblico quando finanza, IT e funzioni operative vanno tutti convinti.

Come si calcola il ROI di un'implementazione SAP?

Si divide il beneficio netto del periodo, di solito cinque anni, per l'investimento totale. Si includono tutti i costi: software o sottoscrizione, onorari del partner, tempo interno, formazione, migrazione dei dati, supporto ricorrente e hypercare. Si usano benefici prudenti, con un ramp-up dopo il go-live. Un 18% realistico si chiude più in fretta di un 35% ottimistico.

Come cambia il business case con RISE with SAP?

La sottoscrizione sostituisce la licenza e il supporto annuale, quindi serve una vista dei costi per ogni anno della durata contrattuale. SAP gestisce l'infrastruttura, il che elimina la spesa hardware. Secondo gli IFRS, i costi di configurazione di un servizio cloud sono di solito imputati a conto economico e non capitalizzati, quindi conviene concordare presto il trattamento contabile con i revisori.

Quanto deve essere lungo un business case SAP?

Un executive summary di una pagina, poi circa 15-25 pagine per un programma di una media impresa e fino a 40 per una grande azienda. Quanto eccede va in appendice. Se lo sponsor ha bisogno di un'ora per fare il briefing a partire dal documento, è troppo lungo.

Che cos'è il costo dell'inazione in un business case SAP?

Ciò che l'azienda continua a perdere restando sul sistema attuale: soluzioni manuali di ripiego, lavoro di riconciliazione, ritardi nella reportistica, supporto per sistemi obsoleti e decisioni prese su dati inaffidabili. Se è su ECC, includa il costo della manutenzione estesa dopo il 2027.