Sette framework di consulenza per la delivery SAP e AI

Quando un programma SAP o AI si blocca, la causa è di solito strutturale e sette framework semplici la trovano. Si mappa lo stato attuale. Si concorda con un RACI chi decide cosa. Si lega il lavoro alle capacità di business. Si cercano le cause radice con i cinque perché. Si ordinano i requisiti con il MoSCoW. Si ordinano i rischi in base a ciò che può davvero fermare il programma. Si fa un vero post-mortem dopo ogni fase. Questa guida è pensata per project manager, consulenti e sponsor impegnati nella delivery SAP e AI. Parta dalla tabella qui sotto: trovi il suo sintomo e usi per primo il framework corrispondente.

Una società di media di medie dimensioni in Qatar stava introducendo SAP in diverse regioni. Finanza e acquisti andavano in produzione nella prima fase. Voleva anche modelli di previsione basati su AI nel reporting.

Alla sesta settimana cominciavano ad accumularsi ritardi. Gli utenti di business dicevano di aver approvato i requisiti ma di non capire ancora che cosa avrebbero ricevuto. Erano stati proposti casi d'uso AI e nessuno sapeva dire chi fosse il responsabile dei dati o come sarebbe stato usato il risultato. Le persone arrivavano in ritardo alle riunioni, o non arrivavano affatto.

Era la fase intermedia. Troppo presto per parlare di fallimento. Troppo tardi per far finta che si sarebbe risolto da solo.

Abbiamo applicato i framework passo dopo passo. All'inizio non tutto è stato ben accolto. Alcune sessioni sono state silenziose. Altre sono andate fuori strada. Ma la struttura ha reso il lavoro più facile: il team ha smesso di girare in tondo, il backlog è diventato gestibile e i casi d'uso AI hanno avuto dei veri responsabili. Il go-live è arrivato otto settimane dopo il previsto. Non perfetto. Ma è arrivato in porto, e la seconda fase è partita su basi migliori, con meno incognite.

Ho usato versioni di tutti e sette in 23 anni di delivery su programmi SAP, Oracle e AI nel Golfo, in Europa e altrove. Nessuno è esotico. Funzionano tutti se si applicano con disciplina e non come esercizi di documentazione.

Si abbini il sintomo al framework:

Sintomo che osserva	Framework	Che cosa produce	Impegno tipico
Gli utenti hanno approvato i requisiti ma sono ancora confusi	1. Mappatura dello stato attuale	Una mappa condivisa di come si lavora davvero oggi	Da 3 a 5 giorni di workshop
Le decisioni rimbalzano da una riunione all'altra	2. RACI sulle decisioni critiche	Responsabili nominati per le 20-30 decisioni chiave	Un workshop, poi l'applicazione
Gli sponsor si sono disimpegnati dal «progetto IT»	3. Mappatura delle capacità	Avanzamento riportato in termini di capacità di business	Integrata nel fit-to-standard
Lo stesso tipo di difetto continua a ripresentarsi	4. Cinque perché	Una causa radice su cui si può intervenire	Una sessione facilitata per ogni problema
Tutto è contrassegnato come alta priorità	5. MoSCoW	Un perimetro ordinato con una lista Must have realistica	Una sessione congiunta business e IT
Il registro dei rischi sembra a posto ma il team è teso	6. Classificazione dei rischi	Elenchi separati dei rischi che fermano il programma e di quelli che danno solo fastidio	Revisione settimanale di 30 minuti
Gli stessi errori si ripetono fase dopo fase	7. Post-mortem	Da tre a cinque modifiche con responsabili	Mezza giornata dopo ogni fase

L'errore più comune all'inizio di un programma è saltare alla soluzione prima di documentare ciò che esiste. La documentazione dei processi è di solito obsoleta. Le persone descrivono come le cose dovrebbero funzionare, non come funzionano. È nello scarto tra le due cose che vivono i problemi di implementazione.

Una buona mappa dello stato attuale richiede da tre a cinque giorni di workshop con le persone che fanno il lavoro, non con quelle che le gestiscono. Copre i passaggi del processo in ordine, i sistemi usati a ogni passaggio, gli interventi manuali e le soluzioni di ripiego, e i flussi di dati tra i reparti.

Si cerchino i passaggi manuali che nessuno cita perché sono diventati invisibili, le soluzioni di ripiego in uso da così tanto tempo da essere ormai considerate processo standard e i problemi di qualità dei dati che tutti conoscono e nessuno ha risolto.

In Qatar la mappa dello stato attuale è nata dai workshop con gli utenti, non dalla documentazione. È lì che la confusione sui requisiti approvati ha iniziato a diradarsi.

Fatta bene, una mappa dello stato attuale richiede giorni. Trattata come un esercizio di raccolta documenti, richiede mesi e produce qualcosa di cui nessuno si fida.

I diritti decisionali sono l'elemento strutturale che più spesso manca nei progetti SAP e AI. Tutti hanno un'opinione. Nessuno sa chi prende la decisione finale. Le decisioni passano alla riunione successiva, che rimanda al comitato direttivo, che le rimanda al gruppo di lavoro.

Una matrice RACI (Responsible, Accountable, Consulted, Informed) assegna un responsabile a ogni decisione e a ogni deliverable. Una persona è Accountable e può essere anche Responsible o delegare. I Consulted danno il loro contributo. Gli Informed vengono a sapere l'esito.

La versione pratica: si elenchino le venti o trenta decisioni più critiche della fase in corso e si organizzi un workshop RACI con i decisori presenti. Dove un'assegnazione è contestata, si è imparato qualcosa: o la governance non è chiara o c'è uno scontro politico sull'autorità. In ogni caso, lo si faccia emergere alla seconda settimana, non alla quattordicesima.

Un RACI senza applicazione è decorazione. I nomi devono corrispondere alle persone con autorità reale. Attribuire la responsabilità ultima a un titolo di ruolo invece che a una persona con nome e cognome è un modo per evitare la conversazione su chi si assume il rischio.

I programmi SAP e AI generano molta attività tecnica che il business non vede. Il legame tra ciò che si sta costruendo e il risultato che dovrebbe produrre diventa astratto. Gli sponsor si disimpegnano e la colpa dei ritardi, che in realtà sono decisioni di business, ricade sul «progetto IT».

La mappatura delle capacità collega la funzione del sistema alla capacità di business: ciò che l'organizzazione deve essere in grado di fare. Invece di verificare se il flusso degli ordini di acquisto è configurato, si verifica se l'organizzazione riesce a elaborare le fatture dei fornitori entro tre giorni dal ricevimento. La configurazione è il meccanismo. La capacità è il risultato.

In SAP Activate questo corrisponde ai workshop di fit-to-standard della fase Explore. Ogni processo nel perimetro è una capacità, e ogni scarto tra lo standard SAP e la capacità richiesta è una decisione: accettare lo standard, configurare una variante o estendere. Mantenere la conversazione a livello di capacità tiene vivo l'interesse del business durante la realizzazione e fa emergere capacità che tutti davano per comprese nel perimetro ma che nessuno aveva confermato.

Quando lo stesso tipo di problema continua a presentarsi sprint dopo sprint o fase dopo fase, rattoppare ogni singolo caso non serve. La causa sta a monte.

I cinque perché sono lo strumento più semplice per risalire alla causa radice. Ci si chiede perché il problema è successo, poi perché è successo quello, fino a raggiungere qualcosa che si può cambiare. Cinque giri di solito arrivano alla causa vera. Due giri di solito si fermano al sintomo.

Un esempio di migrazione dei dati. Il caricamento di prova presenta errori di qualità dei dati: è il sintomo. Perché? L'estrazione dalla sorgente aveva mappature dei campi sbagliate. Perché? La specifica di mappatura non era mai stata rivista dal data owner di business. Perché? Il data owner era stato assegnato solo a mappatura conclusa. Perché? Il piano non faceva del coinvolgimento del data owner una dipendenza per la mappatura. Questa è la causa radice, e la soluzione è una decisione di governance, non una correzione dei dati. Il mio articolo su perché la migrazione dei dati SAP fallisce mostra quanto spesso si presenti proprio questa catena.

1. 01Errori nel caricamento di provaIl sintomo
2. 02Mappature dei campi sbagliatePerché il caricamento è fallito?
3. 03Specifica mai rivistaPerché le mappature erano sbagliate?
4. 04Responsabile nominato troppo tardiPerché la specifica non è stata rivista?
5. 05Il piano non prevedeva la dipendenzaPerché il responsabile è arrivato tardi?

La causa radice è una decisione di governance, non una correzione dei dati

L'analisi delle cause radice in una stanza senza colpevoli produce risposte oneste. In una stanza in cui si cercano colpevoli produce atteggiamenti difensivi. Il compito del facilitatore è tenere la conversazione sul processo, non sulle persone. La mia guida al pensiero strutturato e alla risoluzione dei problemi spiega come scomporre un problema confuso prima di cominciare a chiedersi perché.

Ogni discussione sul perimetro di un progetto SAP o AI nasconde una trappola del consenso. Nessuno vuole fare compromessi, quindi tutto diventa ad alta priorità. Quando tutto è ad alta priorità, niente lo è, e il team di sviluppo cerca di fare tutto.

Il MoSCoW (Must have, Should have, Could have, Won't have this time) obbliga a scegliere. Must have è il minimo necessario per il go-live. Should have è importante ma non bloccante. Could have è auspicabile se tempo e budget lo consentono. Won't have è rinviato in modo esplicito.

La disciplina sta nella linea dei Must have. Alla prima passata un esercizio MoSCoW di solito mette nei Must have molto più del dovuto. Le linee guida DSDM dell'Agile Business Consortium, da cui nasce il MoSCoW, fissano un tetto del 60% dello sforzo sui Must have e avvertono che superarlo mette a rischio la delivery. La differenza tra la prima passata e una lista realistica è fatta soprattutto di ipotesi mai verificate.

Si svolga il MoSCoW con business e tecnologia nella stessa stanza. Se si fa separatamente, la lista dei Must have dell'IT e quella del business risultano incompatibili e nessuno le riconcilia finché la configurazione non è iniziata.

La maggior parte dei registri dei rischi è un lungo elenco valutato per probabilità e impatto, rivisto una volta al mese, con stati RAG che si muovono di rado. Registrano il rischio senza spingere ad agire.

Si separino i rischi che possono fermare il programma da quelli che lo rendono solo più difficile. Il primo gruppo richiede responsabili, piani di risposta e visibilità settimanale. Il secondo richiede monitoraggio.

In Qatar il registro dei rischi sulla carta sembrava a posto, ma tutti erano sulle spine. Una matrice rischio-impatto rapida, rivista ogni settimana invece che ogni mese, ha fatto emergere le preoccupazioni vere.

Un registro che sembra a posto mentre il team è teso quasi sempre nasconde qualcosa. La verità non sta nel registro, ma nelle conversazioni che lo circondano. Una revisione settimanale che chiede «che cosa Le ha tolto il sonno ieri notte?» fa emergere più di «qual è lo stato della voce 14?». La mia matrice di valutazione dei rischi SAP offre un modello per il punteggio e l'assegnazione dei responsabili.

I post-mortem dopo una fase o un go-live impediscono che gli stessi errori si ripetano nella fase successiva. Sono anche la prima cosa che si taglia quando il calendario è sotto pressione.

Un post-mortem utile pone quattro domande. Che cosa avevamo pianificato di ottenere e che cosa abbiamo ottenuto? Che cosa è andato bene e va ripetuto? Che cosa è andato male e che cosa l'ha causato? Che cosa faremmo diversamente? Deve concludersi con da tre a cinque azioni specifiche con responsabili, non con un documento che riassume quanto è accaduto.

Il difetto più comune è l'esercizio di giustificazione, in cui i team difendono le decisioni invece di esaminarle. Lo si tenga rivolto al futuro. La domanda non è chi abbia causato i ritardi della sesta settimana. È quale cambiamento strutturale li evita nella fase successiva.

In Qatar il post-mortem si è svolto subito dopo il go-live ed era centrato sull'azione, non sulle colpe. È in buona parte il motivo per cui la seconda fase è partita su basi migliori.

I framework non sono cambiati. È cambiato il modo in cui vengono applicati, in tre modi.

La stesura è diventata più veloce, l'ascolto no. Oggi gli strumenti di AI trasformano in pochi minuti le trascrizioni dei workshop e i documenti di processo in una prima mappa, e SAP Cloud ALM può redigere requisiti a partire dalle trascrizioni dei workshop di fit-to-standard. I workshop richiedono lo stesso tempo di sempre, perché l'ascolto è il punto. Il tempo risparmiato sulla stesura va investito nel mettere in discussione la mappa con le persone.

Le bozze di RACI arrivano già pronte, e la parte difficile resta. Un assistente AI generico produce in un minuto un RACI a partire da un mandato di progetto e da un elenco di work package. La disciplina si sposta sulla negoziazione: ogni cella richiede una vera conversazione su autorità ed escalation. Il tempo risparmiato nel preparare la bozza va investito in quelle conversazioni difficili.

Il MoSCoW diventa più difficile con l'AI in sala. Una classificazione dei requisiti fatta dall'AI è plausibile, curata e spesso sbagliata sulle dinamiche politiche locali. I consulenti che la accettano senza metterla in discussione producono liste di priorità peggiori di quelli che partono da un foglio bianco. La bozza dell'AI va trattata come un punto di partenza, mai come la risposta.

Il giudizio che si aggiunge a questi framework vale oggi di più, non di meno. Se sta sviluppando queste competenze come consulente, i percorsi di carriera di SAPopedia indicano quali contano in ciascuna fase di una carriera SAP.

Che cosa sono i framework di consulenza e perché i progetti SAP li usano?

Sono approcci strutturati per l'analisi, le decisioni e la risoluzione dei problemi. Nei programmi SAP e AI offrono un metodo comune a responsabili di business, architetti, project manager, integratori e sponsor.

Senza un metodo, ogni gruppo ripiega sul proprio modello mentale: i risultati dei processi, l'architettura oppure tempi e risorse. Framework come la mappatura dello stato attuale, il RACI e il MoSCoW rendono il disaccordo esplicito e risolvibile. SAP Activate è a sua volta un framework per fasi, gate e deliverable; questi sette lavorano al suo interno e affrontano i problemi strutturali e umani che la sola metodologia non risolve.

Come funziona la mappatura dello stato attuale in un'implementazione SAP?

Documenta come funzionano davvero i processi prima che inizi la configurazione, invece di come dice la documentazione esistente che dovrebbero funzionare. Si costruisce nei workshop con le persone che gestiscono i processi: fasi, sistemi, passaggi di consegne, interventi manuali e soluzioni di ripiego.

Alimenta i workshop di fit-to-standard nella fase Explore di SAP Activate, in cui lo stato attuale diventa la base di confronto con i processi standard di SAP. Va completata prima dell'inizio di quei workshop, altrimenti la gap analysis poggia su ipotesi.

Che cos'è la prioritizzazione MoSCoW e quando si usa nei programmi SAP?

Il MoSCoW suddivide i requisiti in Must have, Should have, Could have e Won't have this time. I Must have sono il minimo per il go-live; i Won't have sono esclusi in modo esplicito, così non possono rientrare di soppiatto.

È più utile in Explore, quando gli esiti del fit-gap guidano le decisioni sulle estensioni, e in Realize, quando difetti ed evolutive competono per il tempo di sviluppo. Il problema abituale sono troppi Must have alla prima passata. DSDM raccomanda di non superare il 60% dello sforzo sui Must have; un facilitatore che mette in discussione ciascuno di essi, con business e IT nella stessa sessione, permette di arrivarci.

Come si conduce una revisione dei rischi efficace in un progetto SAP?

Come una conversazione, non come un aggiornamento di stato. Si parta da domande aperte come «Qual è la sua preoccupazione più grande questa settimana che non è nel registro?» prima di passare in rassegna il registro.

Per ogni rischio ad alta priorità, ci si chiede che cosa è cambiato, quale azione è stata intrapresa, se la tendenza sta migliorando e se il piano di risposta è ancora adeguato. I rischi che restano allo stesso livello per settimane senza azioni sono spesso sottovalutati. Si riveda ogni settimana nelle fasi attive e si mostrino al comitato direttivo i primi cinque con stato e prossima azione, non l'intero registro.

Che cosa rende utile un post-mortem dopo un go-live SAP?

Modifiche specifiche e attuabili per la fase successiva. Un riassunto di ciò che è accaduto è un verbale, non un post-mortem.

Si copra ciò che ci si era proposti di ottenere, ciò che si è ottenuto, che cosa ha funzionato e che cosa no. Si scenda sotto le spiegazioni di superficie come «avevamo poche risorse»: era sbagliato il piano delle risorse, era sbagliato il perimetro o era interrotto il percorso di escalation? Si concluda con da tre a cinque modifiche, ciascuna con un responsabile e una data.

Come aiutano i framework di consulenza nell'implementazione dell'AI in ambienti SAP?

I progetti AI falliscono per le stesse ragioni strutturali dei progetti SAP, più qualcuna tutta loro: dati senza responsabile, misure di successo non definite e nessun processo concordato per agire sui risultati.

La mappatura dello stato attuale mostra chi possiede i dati di cui un modello ha bisogno e quanto siano buoni. Il RACI risponde a chi convalida il risultato, chi decide di agire di conseguenza e chi ne risponde quando è sbagliato. Il MoSCoW separa i casi d'uso essenziali da quelli solo interessanti. Si parta da due o tre casi d'uso essenziali con responsabili e misure di successo chiari, non da quindici insieme.