Che cosa fanno davvero i consulenti: uno sguardo realistico

I consulenti SAP configurano, costruiscono, testano e stabilizzano SAP per un'azienda. In pratica, la maggior parte del loro valore arriva a programma in corso. Chiariscono un perimetro andato alla deriva, conducono i walkthrough che nessuno ha fatto, gestiscono il triage dei difetti in UAT e stabilizzano le operazioni dopo il go-live. I consulenti funzionali si occupano della configurazione dei moduli, i consulenti tecnici di estensioni e integrazioni, i consulenti di programma e di change della delivery e dell'adozione. Questo articolo è per i dirigenti che devono decidere se chiamare un aiuto esterno e per chi valuta la consulenza come carriera. Se è un dirigente, la tabella dei segnali qui sotto Le dice quando chiamare. Se è un consulente, le sezioni sull'operatività quotidiana mostrano che cosa comporta davvero il lavoro.

La domanda salta fuori ogni volta che si valuta un supporto esterno: che cosa fa esattamente un consulente che non possiamo fare da soli?

La risposta onesta non è particolarmente lusinghiera per il settore della consulenza. Gran parte del valore viene dal sistemare ciò che non avrebbe dovuto rompersi. Dal porre domande che andavano già poste. E dall'aggiungere capacità e chiarezza nel momento in cui al team interno mancano entrambe.

Non è una critica ai team interni. È il modo in cui tendono ad andare i programmi SAP. Il team interno è sotto pressione. Il system integrator ha le proprie priorità. Le decisioni si accumulano e il perimetro deriva. Sei mesi dopo l'avvio di un programma di dodici, qualcuno apre il registro delle issue e trova venti voci contrassegnate «da risolvere» che sono lì dalla terza settimana.

Di solito è allora che arriva la chiamata.

Alcuni consulenti vengono coinvolti durante il blueprint o la pianificazione. Molti ricevono la chiamata a progetto in corso, spesso dopo due o tre mesi di avanzamento lento o di passaggi di consegne saltati. I report del comitato direttivo virano sull'arancione. Il team lavora sodo. L'avanzamento è lento e nessuno sa dire con precisione perché.

1. ExploreWorkshop e gapWorkshop di fit-to-standard, gap documentati
2. RealizeSviluppo e walkthroughConfigurazione ed estensioni. A progetto in corso è quando arrivano di solito le chiamate di recupero
3. DeployTriage UAT e cutoverLacuna di configurazione, di processo o di formazione? Decide il triage
4. HypercareStabilizzazioneLa prima chiusura mensile e la coda delle issue

I punti d'ingresso tipici:

1. Il perimetro è andato alla deriva. Ciò che era stato approvato in Explore non corrisponde più a ciò su cui lavora il team di sviluppo. I requisiti sono stati aggiunti in modo informale nei workshop, il registro delle modifiche non è stato aggiornato e nessuno ha un elenco definitivo del perimetro.
2. Un flusso di lavoro critico si è fermato. La migrazione dei dati è bloccata da settimane allo stesso tasso di errore, senza un piano per migliorarlo. L'UAT apre più difetti di quanti ne chiuda.
3. La data di go-live è fissa e il piano non la regge. La data l'ha fissata il consiglio di amministrazione. Il piano non è stato riallineato all'avanzamento reale. Il programme manager sa che la traiettoria manca la data ma non ha ancora fatto escalation.

In ogni caso, il compito non è aggiungere persone al piano esistente. È guardare che cosa sta succedendo davvero, dare un nome chiaro al problema e produrre una via d'uscita. La mia guida su come rimettere in carreggiata i progetti SAP tratta questa sequenza di recupero.

Chiarimento di perimetro e processi

A volte la configurazione è giusta, ma il processo che la circonda è rotto. Uno schema frequente: il team ha configurato in base a un documento di fit-to-standard di Explore e gli utenti di business non hanno più visto la configurazione dopo l'approvazione. Gli è stato detto che cosa si stava costruendo, non è stato mostrato.

La soluzione non è tecnica. È una lacuna di dialogo. Il compito è guidare gli utenti di business attraverso la configurazione prima dell'UAT e produrre un elenco chiaro di modifiche prima che si aprano i test.

Non è affascinante. È così che si presenta il lavoro.

Fare da ponte tra team tecnici e di business

I programmi SAP producono regolarmente qualcosa di tecnicamente corretto che il business non può usare. Una determinazione dei prezzi che funziona nel 90% dei casi e si inceppa sugli ordini export. Un movimento merci che si registra correttamente ma crea un documento contabile che il team di riconciliazione non riconosce.

Il consulente funzionale chiude questo divario. Non essendo la persona più tecnica della stanza. Ma capendo il comportamento del sistema e l'impatto sul business abbastanza bene da consentire alle persone giuste di prendere la decisione giusta.

Supporto all'UAT

L'user acceptance testing è il momento in cui le decisioni accumulate da un programma reggono o crollano. Ogni scorciatoia presa in Explore, ogni aggiunta informale al perimetro e ogni test case scritto a livello di sintesi emerge qui.

Un buon supporto all'UAT significa fare il triage dei difetti nel modo giusto, distinguendo le lacune di configurazione da quelle di processo e da quelle di formazione. Significa anche gestire il clima quando gli utenti di business incappano in una serie di errori che scuote la loro fiducia nell'intero programma. Senza questo, ogni difetto in una sessione di UAT diventa un motivo per mettere in dubbio il go-live, di solito perché il triage era debole e nessuno aveva definito che cosa significasse «pronto per il go-live».

Stabilizzazione post go-live

Il lavoro meno affascinante della consulenza SAP è l'hypercare. Il go-live c'è stato, sono partite le email di festeggiamento, il team di implementazione ha cominciato a ridursi. Poi arriva la prima chiusura mensile. Le registrazioni non corrispondono al formato di riconciliazione. Gli ordini di produzione si completano ma non vengono liquidati. L'help desk si riempie di utenti che erano stati formati ma non erano preparati ai casi limite.

È qui che si genera gran parte del valore vero ed è qui che la maggior parte dei programmi ha meno risorse. Il team di hypercare lavora la coda delle issue in modo sistematico, separa i problemi sistemici dagli errori isolati e ricostruisce la fiducia nel sistema.

La struttura del lavoro non è cambiata. È cambiata la ripartizione del tempo.

La documentazione si scrive quasi da sola. SAP Joule for Consultants, disponibile in via generale dal 2025, risponde alle domande di configurazione attingendo alla knowledge base di SAP, comprese le SAP Notes, e spiega il codice ABAP. Gli assistenti basati su Joule in SAP Cloud ALM redigono requisiti e test case a partire dal materiale dei workshop. Il consulente funzionale passa meno tempo a scrivere documenti e più tempo a mettere in discussione le conclusioni dei workshop.

Il codice si rivede più che si scrive. Gli assistenti per sviluppatori di SAP redigono codice, tra cui SAP Build Code per le estensioni Java e JavaScript su SAP BTP. I consulenti tecnici ora lo rivedono, lo mettono in sicurezza e lo testano.

I desk di hypercare ricevono meno domande di routine. Joule può rispondere a domande di routine, come il saldo delle ferie o lo stato di una nota spese, all'interno delle applicazioni SAP, e questo toglie un po' di volume al desk di hypercare. Il tempo dei consulenti si sposta sulle lacune di processo, sui problemi di dati anagrafici e sui casi che richiedono una persona.

Il motivo per cui si chiama un consulente non è cambiato. I consulenti che hanno imparato questi strumenti dedicano più tempo a giudizio, comunicazione ed escalation e meno a lavori che l'AI ora redige in modo adeguato. La descrizione che SAP stessa dà di Joule for Consultants è un riassunto fedele di ciò che copre.

I consulenti funzionali sono specializzati in moduli come FI, CO, SD, MM, PP, EWM o SuccessFactors. Configurano il sistema attorno ai processi di business e colmano il divario tra lo standard SAP e i requisiti del cliente. Il loro valore sta nella profondità sul modulo unita alla conoscenza dei processi di business.

I consulenti tecnici (sviluppatori ABAP, specialisti SAP BTP, architetti di integrazione, Basis) costruiscono le estensioni e le integrazioni che la configurazione non può coprire. Nei programmi S/4HANA moderni, i principi del clean core spingono le nuove estensioni su SAP BTP o su API rilasciate, e questo richiede competenze diverse dalla classica modifica ABAP.

I project e programme manager danno struttura alla delivery: governance, rischi, calendario e risoluzione delle issue, con una visibilità sull'intero programma che permette di fare escalation dei problemi prima che diventino crisi.

I consulenti di change management si occupano della parte delle persone: formazione, comunicazione, coinvolgimento e la governance che decide se gli utenti adottano il sistema o lo aggirano.

La maggior parte dei grandi programmi SAP ha bisogno di tutte e quattro. I programmi del mid-market hanno spesso meno persone che coprono più ruoli, ed è lì che si aprono le lacune. I framework di consulenza e le competenze che contano nella consulenza sono gli stessi per tutti e quattro. Se è un consulente e sta tracciando il suo percorso tra questi ruoli, SAPopedia presenta percorsi di carriera e corsi, mentre ERPCV La aiuta a presentare quell'esperienza ai recruiter.

L'errore di consulenza più costoso è chiamare qualcuno troppo tardi. Una revisione dei rischi pre-cutover quattro-sei settimane prima del go-live può individuare problemi critici quando c'è ancora tempo. Un intervento di recupero dopo un cutover fallito costa molto di più. Inoltre avviene sotto pressione operativa, in un'organizzazione che ha perso fiducia nel sistema.

La tabella mostra i segnali e l'aiuto che ciascuno richiede.

Segnale	Che cosa significa di solito	Aiuto da coinvolgere	Che cosa dovrebbe consegnare in due settimane
Voci del registro delle issue aperte da più di quattro settimane senza data di risoluzione	Un problema di governance, non tecnico	Advisor di programma indipendente	Un elenco di decisioni con responsabili e date
Go-live entro 60 giorni e nessuna prova generale del cutover	Cutover non testato; le sorprese al go-live non si recuperano in tempo reale	Responsabile del cutover o del programma	Un piano di cutover provato e criteri go/no-go
I responsabili di business hanno smesso di partecipare	L'UAT fallirà senza un intervento deliberato	Change lead più un lead funzionale	Walkthrough con gli utenti chiave e un piano per riportarli a bordo
Un flusso di lavoro fermo da settimane allo stesso tasso di errore	Causa radice non individuata	Specialista di quel flusso di lavoro	Un'analisi delle cause radice e un piano di recupero
Il reporting del system integrator è l'unica vista sullo stato del programma	Nessun controllo indipendente	Advisor lato cliente	Una valutazione onesta dello stato del programma per lo sponsor

Che cosa fanno davvero i consulenti SAP in un progetto?

Analizzano i requisiti di business, configurano SAP per supportarli e colmano il divario tra le impostazioni predefinite di SAP e ciò che serve all'azienda. In Explore conducono i workshop di fit-to-standard e documentano i gap. In Realize costruiscono la configurazione e lavorano con gli sviluppatori sulle estensioni. In Deploy supportano l'UAT, gestiscono i difetti e preparano il cutover. In hypercare risolvono i problemi successivi al go-live. La parte che manca nelle job description è il triage dei gap tra una fase e l'altra e il mantenimento della disciplina di delivery sotto pressione.

Quando un'organizzazione ha davvero bisogno di un consulente?

Tre situazioni coprono la maggior parte degli incarichi. Il recupero del programma, quando il perimetro è andato alla deriva, un flusso di lavoro si è fermato o la data di go-live è a rischio. La competenza specialistica, quando al team manca un modulo o una competenza tecnica come la configurazione PP-PI o l'integrazione su SAP BTP. E la governance, quando l'organizzazione vuole una supervisione indipendente su un programma condotto da un system integrator. Aspettare che la situazione peggiori prima di chiamare è lo schema più comune e il più costoso.

Che differenza c'è tra un consulente SAP funzionale e uno tecnico?

I consulenti funzionali configurano SAP a supporto dei processi di business in moduli come FI/CO, SD, MM, PP o EWM e lavorano direttamente con gli utenti di business sui requisiti. I consulenti tecnici costruiscono ciò che la configurazione non può fare: estensioni ABAP e BTP, integrazioni e amministrazione di sistema tramite Basis. I principi del clean core stanno spostando il lavoro tecnico dalle modifiche ABAP dentro il sistema verso le estensioni BTP e le API rilasciate.

Come si capisce se un consulente porta valore?

Tre indicatori. Fa emergere ipotesi mai verificate e decisioni rinviate, invece di confermare le opinioni esistenti. Le decisioni ferme da settimane iniziano a essere prese. E il registro delle issue si accorcia perché si correggono le cause radice, non perché le voci vengono chiuse senza risoluzione. Un registro che resta della stessa lunghezza nonostante l'attività significa che i problemi sono sistemici o che le correzioni non arrivano alla causa.

Qual è la parte più difficile del lavoro di consulenza?

Dare un nome ai problemi che il cliente già conosce ma su cui non ha agito: il perimetro andato alla deriva, i test case mai scritti, lo sponsor che ha smesso di partecipare. Servono abbastanza fiducia da essere ascoltati, abbastanza credibilità da essere creduti e abbastanza franchezza da dire cose scomode. I consulenti che proteggono il rapporto a scapito della diagnosi sono un assenso a caro prezzo.

Perché ingaggiare un consulente indipendente se il cliente ha già un system integrator?

Il system integrator risponde della consegna del perimetro contrattuale. Un consulente indipendente risponde al cliente del risultato. Sono due lavori diversi. L'advisor lato cliente mette in discussione le ipotesi di progettazione e verifica che il disegno risponda alle esigenze di business. Tutela la posizione commerciale del cliente nel change control e dà alla direzione una vista sullo stato del programma che non passa per il reporting dell'integratore. È un conflitto di interessi strutturale, non una critica agli integratori.