Vai al contenuto
Marc Gasser
← Torna al blog

Forward deployed engineer: prima mappa il processo

Riassumi questo articolo con
Forward deployed engineer: prima mappa il processo

"Become a $1M/yr FDE." È il titolo di un episodio recente di The Startup Ideas Podcast. FDE sta per forward deployed engineer. Il titolo è buono. I dati raccontano una storia più piccola.

La domanda è reale. Gli annunci di lavoro per forward deployed engineer su Indeed sono cresciuti dell'800% tra gennaio e settembre 2025. La paga è alta, non magica. Un'analisi di settore indica uno stipendio base mediano di circa 174.000 dollari, con una retribuzione totale nei lab di AI tra 350.000 e 550.000 dollari. Il conto dell'episodio per il milione è una quota del valore: consegna 10 milioni di dollari, tieni il 10%.

Lascia perdere lo stipendio, quindi. La parte utile è il metodo che c'è dietro. Spiega perché la maggior parte dei progetti di AI si blocca. E vale per un'azienda di 60 persone quanto per un grande gruppo americano.

L'ospite è Vasuman Moza di Varick Agents, una società che inserisce forward deployed engineer nelle grandi aziende e ne ricostruisce i processi attorno agli agenti AI. Un forward deployed engineer è un ingegnere che lavora dentro l'attività del cliente, non alla scrivania del fornitore.

Il conduttore Greg Isenberg chiede esempi concreti, e Moza porta numeri dai lavori con i clienti. I dettagli sono modificati. Leggi i numeri come una direzione, non come un benchmark.

Cosa imparerai

  • Perché il processo documentato non è mai quello reale
  • I quattro secchi in cui va ogni passo di un processo
  • Perché gli agenti stanno dentro il tuo CRM o ERP, non accanto
  • Cosa porta un primo progetto, in numeri

Un agente vale quanto la mappa del processo che ha sotto

Questa è la tesi. La versione di Moza è più corta: don't apply AI. L'AI non si stende come una mano di vernice. Se nessuno ha scritto come scorre davvero il lavoro, l'agente automatizza un'ipotesi.

Quindi prima viene la mappa e poi l'agente. Il resto dell'articolo è la prova, dall'origine del problema fino ai numeri.

Perché la maggior parte dei pilot di AI si blocca?

La maggior parte dei pilot di AI si blocca perché automatizza il processo documentato, e il processo documentato non è quello reale. Quello reale vive nelle teste delle persone, nelle eccezioni e nei loop che nessuno ha disegnato. Un agente costruito sulla versione ufficiale cade alla prima eccezione.

Lo schema è ben misurato. Il report GenAI Divide del MIT mostra che circa il 95% dei pilot aziendali di AI generativa non produce ritorni. Gli autori indicano il divario tra gli strumenti e i flussi di lavoro reali, non la qualità dei modelli. In un sondaggio Celonis tra 1.620 dirigenti, anche di Germania, Austria e Svizzera, l'89% dice che l'AI deve capire come funzionano i loro processi per dare risultati.

Il primo esempio di Moza lo rende concreto. Una società di software quotata, con 5 miliardi di dollari di fatturato, aveva documentato il suo processo di preventivo in 7 passi ordinati. Il suo team ha fatto girare il process mining sul CRM.

Il processo reale aveva 20 passi e 7 loop. Il 61% delle richieste tornava all'inizio. Il legale ne rimandava indietro il 12%. Nel 30% dei casi un nuovo preventivo doveva ripassare dall'approvazione.

Niente di tutto questo era su carta. In ogni azienda che vede, c'è qualcuno che è lì da 20 anni e se ne occupa e basta. Io lo chiamo contesto frammentato: il prodotto conosce una parte, le vendite un'altra, e ogni agente riparte da zero. È lo stesso motivo per cui un funnel CRM non è il tuo vero processo di vendita.

Spiega anche perché tante aziende del DACH sono ferme al primo passo. In Germania il 57% delle aziende ora usa l'AI, ma 9 su 10 dicono di essere solo all'inizio.

Come un forward deployed engineer mappa un processo

Conto cinque passi nel suo metodo. La maggior parte del lavoro avviene prima che qualcuno costruisca un agente.

  1. Intervista le persone. Parti da un reparto. Chiedi perché esiste ogni passo, chi decide davvero, quale passo è teatro e quanto spesso capitano le eccezioni.
  2. Scava nei sistemi di riferimento. Il suo team fa girare agenti di process mining sul CRM o sull'ERP per tre o quattro settimane. Quali record entrano, chi li corregge, dove vanno dopo?
  3. Leggi quello che esiste. Vecchia documentazione, thread di chat, fogli di calcolo. A volte superati, a volte buoni.
  4. Smista ogni passo in uno di quattro secchi. Eliminalo. Trasformalo in codice semplice, quando è una regola se-allora. Dallo a un agente, quando richiede giudizio e hai uno storico da cui imparare. Oppure tienilo come decisione umana, quando un errore costa caro.
  5. Misura prima di costruire. Tempo di ciclo, tasso di eccezioni, costo per pratica. Senza un valore di partenza non potrai dimostrare nulla dopo.

Nessuna fonte basta da sola. Una grande azienda ha dieci anni di storico nel CRM. Una piccola ha soprattutto teste. Le interviste senza i dati danno opinioni, e i dati senza le interviste danno metà del quadro.

Il valore sta nel passo 4. Moza cita Michael Hammer, il cui articolo del 1990 sulla Harvard Business Review diceva alle aziende di ridisegnare i processi invece di automatizzarli.

Il punto che prende da Hammer: accelera ognuno di 20 passi e il processo forse non diventa più veloce, perché il tempo sta tra un passo e l'altro. È il passaggio di consegne tra i team. Nessun agente ripara un passaggio di consegne che non dovrebbe esistere.

La ripartizione è meno carica di agenti di quanto l'hype faccia pensare. Una descrizione del metodo di Varick riporta un redesign tipico: su 8 passi, 4 vengono automatizzati, 3 tengono una persona nel loop e 1 resta manuale.

La sua tabella di marcia è corta. 4 settimane per l'audit e i primi proof of concept. 4 settimane per costruire. Poi un confronto prima-dopo a 3 e 6 mesi di distanza. La mappa finita fa anche un secondo lavoro: è il brief per l'agente, così come un buon ticket è un contenitore di contesto per gli agenti.

Devo sostituire il mio CRM o ERP per gli agenti AI?

No. Gli agenti che funzionano girano dentro i sistemi che hai già. Leggono e scrivono nel tuo CRM o ERP, e chiedono l'approvazione nello strumento di chat che il tuo team usa già. Un pitch di migrazione perde la sala e ritarda il risultato di anni.

Moza su questo è diretto. I clienti gli raccontano di cambi di ERP costati diversi anni e diversi milioni di dollari, in un caso circa 10 milioni. Nessuno vuole un secondo giro. I suoi agenti quindi scavano nel CRM e agiscono nel CRM, e un'approvazione umana è un messaggio in Slack. Il personale non ha bisogno di formazione, perché sullo schermo non cambia nulla.

Così il sistema di riferimento diventa il vero strumento. Contiene lo storico che serve a un agente per valutare una pratica. Quello che vuoi ricavarne è contesto, non solo dati.

Altre due scelte dall'episodio. Primo, distingue gli assistenti in chat dagli agenti in background. Un agente in background fa lo stesso lavoro ogni volta senza che glielo si chieda e ti chiama solo quando serve una decisione. La sua stima: un assistente dà un output dal 10 al 20% più veloce, un agente in background dal 70 all'80%.

Secondo, la maggior parte dei passi non ha bisogno del modello più nuovo. Mette alla prova ogni workflow con più modelli e sceglie per workflow.

Un punto per chi legge dal DACH. Non ha visto alcuna domanda di hardware in sede presso i suoi clienti, banche e aziende farmaceutiche comprese. La sua società fa passare i modelli dalle grandi piattaforme cloud, con condizioni che escludono l'addestramento e la conservazione dei dati.

Devi assumere un forward deployed engineer?

All'inizio probabilmente no. Un forward deployed engineer unisce tre competenze: capire come si svolge il lavoro, rilasciare codice di produzione con audit e sicurezza, e sapere cosa si può affidare a un modello. Puoi farle crescere nel tuo team partendo da un solo processo.

Moza dice che le persone forti in tutte e tre sono rare. La maggior parte ne ha una o due. Sopra ce n'è una quarta: spiegare tutto alla direzione.

  • Il processo. Come funzionano davvero Salesforce, NetSuite o Dynamics, e come dovrebbe essere la funzione?
  • Il codice. Agenti che chiamano quei sistemi, con audit trail, governance e sicurezza. È agentic engineering con disciplina, non una demo.
  • Il livello AI. Quale modello per quale passo, gli eval per testarlo, e un rollback quando un agente sbaglia azione.

Il suo esercizio di partenza dura quattro giorni e usa la tua vita come caso di prova. Elenca ogni app che contiene le tue cose, e quale vince quando due non concordano. Scegli 20 cose che hai fatto la settimana scorsa.

Scrivine una passo per passo, con ogni eccezione. Smista i passi nei quattro secchi. Darebbe lo stesso playbook a un'azienda che vuole far crescere i propri FDE.

La mia aggiunta: poi fallo per un processo reale in un team. Un processo, un owner.

Cosa porta il reengineering dei processi, in numeri?

Nel caso di contabilità fornitori dell'episodio, 17 passi di processo sono diventati 7. Il tempo di ciclo è sceso da 24 giorni a 6. Il costo per fattura è calato da 31 a 6 dollari. La quota di fatture che passano senza eccezioni è salita dal 18% all'87%.

Rileggi l'ultimo numero. Prima del progetto, l'82% delle fatture prendeva una via d'eccezione. Non è un agente che manca. È un processo rotto.

Lo dice Moza stesso: questo guadagno è reengineering dei processi, e non dipende tutto dagli agenti. La mappatura ha richiesto due o tre settimane di interviste e process mining.

Nessuno progetta un processo così. Cresce da solo. In un altro esempio, cinque società in portafoglio sullo stesso ERP facevano girare lo stesso tipo di processo in 12, 9, 15, 18 e 13 passi.

Una riserva. Questi sono i numeri di un fornitore, presi da singoli clienti, con dettagli modificati. Confrontali quindi con un caso pubblicato.

Moza indica Thrive Holdings, che compra studi contabili e società di servizi IT e ci mette dentro gli ingegneri. Il gruppo possiede più di 70 società. I suoi agenti fiscali hanno elaborato oltre 7.000 dichiarazioni con il 98% di accuratezza e ridotto il tempo di preparazione di oltre il 30%. Altra società, stesso schema: ingegneri dentro l'attività, prima il processo.

Dove funziona, dove no, e la trappola

✅ Cosa brilla. I flussi ad alto volume e con molte regole, con un sistema di riferimento e anni di storico: fatture, approvazioni dei preventivi, riconciliazioni. C'è un owner chiaro, un valore di partenza misurabile e un risultato visibile in pochi mesi.

❌ Cosa non brilla. Le piccole aziende dove nulla è scritto e non esiste un sistema di riferimento. Non c'è uno storico in cui scavare, quindi le interviste reggono tutto. Nemmeno gli agenti assistenti personali brillano. Moza non vede ancora una governance per affidare loro i processi aziendali.

⚠️ Attenzione. Tieni le persone su approvazioni e pagamenti. Un agente che paga ogni fattura dall'aspetto legittimo è un regalo per i truffatori.

E applica uno sconto ai conti sui margini dei roll-up AI. Uno studio di Stanford e BetterUp mostra che il 40% dei dipendenti riceve output di AI che sembra curato ma manca di sostanza. Il costo: circa 186 dollari per persona al mese. Gartner si aspetta che oltre il 40% dei progetti di agentic AI venga cancellato entro la fine del 2027. I motivi: costi in aumento, valore poco chiaro o controlli di rischio deboli.

Torniamo al milione. Nessuno lo paga perché qualcuno conosce gli agenti. Se qualcuno lo paga, lo paga perché qualcuno conosce il processo.

I quattro secchi descrivono semplicemente come, secondo me, dovrebbero lavorare i team. Lo chiamo Get Multiplayer: Le persone fissano gli obiettivi, decidono e approvano. Gli agenti preparano e si occupano del lavoro ripetitivo. Obiettivi condivisi e contesto condiviso tengono insieme il lavoro.

La mappa del processo è quel contesto condiviso, messo per iscritto. L'AI non ripara un processo poco chiaro. Lo rende più veloce e più rumoroso.

Se vuoi una costruzione come questa a ogni numero, iscriviti alla newsletter The Science of GTM.

Scritto da

Serial entrepreneur, autore

Marc lavora all'incrocio tra Product × GTM × AI e costruisce aziende software B2B con persone + agenti. A 16 anni ha fondato la sua prima azienda software e da vent'anni lavora dove il software product management incontra il go-to-market. Cofondatore di Teklens, il Product Brain condiviso per i team software. Esperto Innosuisse e autore Springer Gabler.