Hoppa till innehållet
Marc Gasser
← Tillbaka till bloggen

Forward deployed engineers: kartlägg processen först

Sammanfatta artikeln med
Forward deployed engineers: kartlägg processen först

"Become a $1M/yr FDE." Så heter ett aktuellt avsnitt av The Startup Ideas Podcast. FDE står för forward deployed engineer. Titeln är bra. Datan berättar en mindre historia.

Efterfrågan är verklig. Jobbannonserna för forward deployed engineers på Indeed ökade med 800% mellan januari och september 2025. Lönen är hög, inte magisk. En branschanalys anger en medianlön på cirka 174 000 dollar i grundlön, och den totala ersättningen hos AI-labben ligger mellan 350 000 och 550 000 dollar. Avsnittets egen kalkyl för miljonen är en andel av värdet: leverera 10 miljoner dollar, behåll 10%.

Glöm alltså lönen. Det användbara är metoden bakom. Den förklarar varför de flesta AI-projekt kör fast. Och den gäller ett företag med 60 personer lika mycket som en amerikansk koncern.

Gästen är Vasuman Moza från Varick Agents, ett bolag som placerar forward deployed engineers i stora företag och bygger om deras processer kring AI-agenter. En forward deployed engineer är en ingenjör som arbetar inne i kundens verksamhet, inte vid leverantörens skrivbord.

Programledaren Greg Isenberg kräver konkreta exempel, och Moza kommer med siffror från kunduppdrag. Detaljerna är ändrade. Läs siffrorna som riktning, inte som benchmark.

Vad du lär dig

  • Varför den dokumenterade processen aldrig är den verkliga
  • De fyra hinkarna som varje processteg hör hemma i
  • Varför agenter hör hemma i ditt CRM eller ERP, inte bredvid
  • Vad ett första projekt ger, i siffror

En agent är bara så bra som processkartan under den

Det är tesen. Mozas version är kortare: don't apply AI. Du kan inte stryka på AI som ett lager färg. Om ingen har skrivit ner hur arbetet faktiskt flödar, automatiserar agenten en gissning.

Kartan kommer alltså först och agenten sedan. Resten av artikeln är beviset, från problemets ursprung till siffrorna.

Varför kör de flesta AI-piloter fast?

De flesta AI-piloter kör fast för att de automatiserar den dokumenterade processen, och den dokumenterade processen är inte den verkliga. Den verkliga finns i människors huvuden, i undantag och i loopar som ingen har ritat. En agent som bygger på den officiella versionen faller på första undantaget.

Mönstret är väl uppmätt. MIT:s rapport GenAI Divide visar att cirka 95% av företagens piloter med generativ AI inte ger någon avkastning. Författarna pekar på glappet mellan verktygen och de verkliga arbetsflödena, inte på modellernas kvalitet. I en Celonis-undersökning bland 1 620 företagsledare, även från Tyskland, Österrike och Schweiz, sa 89% att AI måste förstå hur deras processer går till för att ge resultat.

Mozas första exempel gör det konkret. Ett börsnoterat mjukvarubolag med 5 miljarder dollar i omsättning hade sin offertprocess dokumenterad i 7 prydliga steg. Hans team körde process mining på CRM-systemet.

Den verkliga processen hade 20 steg och 7 loopar. 61% av ärendena gick tillbaka till start. Juridik skickade tillbaka 12%. I 30% av fallen fick en ny offert gå genom godkännandet igen.

Inget av det stod på papper. I varje företag han ser finns någon som har varit där i 20 år och bara löser det. Jag kallar det fragmenterad kontext: produkt kan en del, sälj en annan, och varje agent börjar från noll. Av samma skäl är en CRM-tratt inte din verkliga säljprocess.

Det förklarar också varför så många bolag i DACH har fastnat på steg ett. I Tyskland använder 57% av företagen nu AI, men 9 av 10 säger att de bara är i början.

Så kartlägger en forward deployed engineer en process

Jag räknar till fem steg i hans metod. Det mesta av arbetet sker innan någon bygger en agent.

  1. Intervjua människorna. Börja med en avdelning. Fråga varför varje steg finns, vem som faktiskt beslutar, vilket steg som är teater och hur ofta undantag inträffar.
  2. Gräv i källsystemen. Hans team kör process mining-agenter på CRM eller ERP i tre till fyra veckor. Vilka poster kommer in, vem rättar dem, vart går de sedan?
  3. Läs det som finns. Gammal dokumentation, chattrådar, kalkylark. Ibland föråldrat, ibland bra.
  4. Sortera varje steg i en av fyra hinkar. Stryk det. Gör det till vanlig kod, när det är en enkel om-så-regel. Ge det till en agent, när det kräver omdöme och du har historik att lära av. Eller behåll det som ett mänskligt beslut, när ett misstag är dyrt.
  5. Mät innan du bygger. Ledtid, andel undantag, kostnad per ärende. Utan utgångsvärde kan du inte bevisa något senare.

Ingen enskild källa räcker. Ett stort företag har tio års CRM-historik. Ett litet har mest huvuden. Intervjuer utan data ger åsikter, och data utan intervjuer ger halva bilden.

Värdet ligger i steg 4. Moza hänvisar till Michael Hammer, vars artikel från 1990 i Harvard Business Review uppmanade företag att göra om sina processer i stället för att automatisera dem.

Poängen han tar från Hammer: snabba upp vart och ett av 20 steg, och processen blir kanske inte snabbare, eftersom tiden ligger mellan stegen. Det är överlämningen mellan team. Ingen agent lagar en överlämning som inte borde finnas.

Fördelningen är mindre agenttung än hajpen antyder. En beskrivning av Varicks metod anger en typisk omdesign: av 8 steg automatiseras 4, i 3 finns en människa kvar i flödet och 1 förblir manuellt.

Hans tidsplan är kort. 4 veckor för granskningen och de första proofs of concept. 4 veckor för bygget. Sedan en före-och-efter-jämförelse 3 och 6 månader senare. Den färdiga kartan har ett jobb till: den är briefen till agenten, på samma sätt som en bra ticket är en kontextbehållare för agenter.

Måste jag byta ut mitt CRM eller ERP för AI-agenter?

Nej. Agenterna som fungerar kör i de system du redan har. De läser och skriver i ditt CRM eller ERP, och de ber om godkännande i chattverktyget som ditt team redan använder. En migrationspitch tappar rummet och försenar resultatet med flera år.

Moza är rak på den punkten. Kunder berättar för honom om ERP-byten som tog flera år och flera miljoner dollar, i ett fall omkring 10 miljoner. Ingen vill ha en andra omgång. Hans agenter gräver alltså i CRM-systemet och agerar i CRM-systemet, och ett mänskligt godkännande är ett meddelande i Slack. Personalen behöver ingen utbildning, eftersom inget ändras på skärmen.

Därmed är källsystemet det egentliga verktyget. Det håller historiken som en agent behöver för att bedöma ett ärende. Det du vill ha ut av det är kontext, inte bara data.

Två val till från avsnittet. För det första skiljer han chattassistenter från bakgrundsagenter. En bakgrundsagent gör samma jobb varje gång utan att bli ombedd och hör bara av sig när den behöver ett beslut. Hans uppskattning: en assistent ger 10 till 20% snabbare output, en bakgrundsagent 70 till 80%.

För det andra behöver de flesta steg inte den nyaste modellen. Han testar varje arbetsflöde mot flera modeller och väljer per arbetsflöde.

En punkt för läsare i DACH. Han har inte sett någon efterfrågan på egen hårdvara hos sina kunder, inte heller hos banker och läkemedelsbolag. Hans bolag kör modellerna via de stora molnplattformarna, med villkor som utesluter träning och datalagring.

Behöver du anställa en forward deployed engineer?

Troligen inte i början. En forward deployed engineer förenar tre förmågor: att förstå hur arbetet går till, att leverera produktionskod med spårbarhet och säkerhet, och att veta vad man kan anförtro en modell. Det går att bygga upp i det egna teamet om du börjar med en process.

Moza säger att personer som är starka i alla tre är sällsynta. De flesta har en eller två. Ovanpå kommer en fjärde: att förklara allt för ledningen.

  • Processen. Hur fungerar Salesforce, NetSuite eller Dynamics egentligen, och hur bör funktionen se ut?
  • Koden. Agenter som anropar de systemen, med audit trail, governance och säkerhet. Det är agentic engineering med disciplin, inte en demo.
  • AI-lagret. Vilken modell för vilket steg, evals som testar den, och en rollback när en agent gör fel.

Hans startövning tar fyra dagar och använder ditt eget liv som testfall. Lista varje app som håller dina saker, och vilken som vinner när två säger olika. Välj 20 saker du gjorde förra veckan.

Skriv ner en av dem steg för steg, med varje undantag. Sortera stegen i de fyra hinkarna. Samma playbook skulle han ge ett företag som vill bygga upp egna FDE:er.

Mitt tillägg: gör det sedan för en verklig process i ett team. En process, en ägare.

Vad ger process-reengineering i siffror?

I leverantörsreskontra-fallet från avsnittet blev 17 processteg till 7. Ledtiden föll från 24 dagar till 6. Kostnaden per faktura sjönk från 31 till 6 dollar. Andelen fakturor som passerar utan undantag steg från 18% till 87%.

Läs den sista siffran igen. Före projektet tog 82% av fakturorna en undantagsväg. Det är inte en agent som saknas. Det är en trasig process.

Moza säger det själv: den här vinsten är process-reengineering, och allt handlar inte om agenter. Kartläggningen tog två till tre veckor med intervjuer och process mining.

Ingen ritar en sådan process. Den växer fram. I ett annat exempel körde fem portföljbolag på samma ERP samma slags process i 12, 9, 15, 18 och 13 steg.

En reservation. Det här är en leverantörs egna siffror, från enskilda kunder, med ändrade detaljer. Pröva dem alltså mot ett publicerat fall.

Moza pekar på Thrive Holdings, som köper redovisningsbyråer och IT-tjänstebolag och sätter in ingenjörer i dem. Gruppen äger mer än 70 bolag. Dess skatteagenter har behandlat över 7 000 deklarationer med 98% träffsäkerhet och kortat förberedelsetiden med mer än 30%. Annat bolag, samma mönster: ingenjörer inne i verksamheten, processen först.

Var det fungerar, var det inte gör det, och fällan

✅ Det som lyser. Flöden med hög volym och många regler, med ett källsystem och flera års historik: fakturor, offertgodkännanden, avstämningar. Det finns en tydlig ägare, ett mätbart utgångsvärde och ett synligt resultat inom några månader.

❌ Det som inte lyser. Små bolag där inget är nedskrivet och inget källsystem finns. Där finns ingen historik att gräva i, så intervjuerna bär allt. Personliga assistentagenter lyser inte heller. Moza ser ännu ingen governance för att låta dem sköta företagsprocesser.

⚠️ Varning. Behåll människor på godkännanden och betalningar. En agent som betalar varje faktura som ser äkta ut är en gåva till bedragare.

Och räkna ner marginalkalkylen i AI-roll-ups. En studie från Stanford och BetterUp visar att 40% av de anställda får AI-output som ser polerad ut men saknar substans. Kostnaden: omkring 186 dollar per person och månad. Gartner väntar sig att över 40% av projekten med agentic AI läggs ner före slutet av 2027. Skälen: stigande kostnader, oklart värde eller svag riskkontroll.

Tillbaka till miljonen. Ingen betalar den för att någon kan agenter. Om någon betalar den, betalar de för att någon kan processen.

De fyra hinkarna beskriver helt enkelt hur jag tycker att team ska arbeta. Jag kallar det Get Multiplayer: Människor sätter mål, beslutar och godkänner. Agenter förbereder och tar hand om det återkommande arbetet. Gemensamma mål och gemensam kontext håller ihop arbetet.

Processkartan är den gemensamma kontexten, nedskriven. AI lagar inte en otydlig process. Den gör den snabbare och högljuddare.

Om du vill ha ett sådant bygge per utgåva, prenumerera på nyhetsbrevet The Science of GTM.

Skriven av

Serieentreprenör, författare

Marc arbetar i skärningspunkten Product × GTM × AI och bygger B2B-mjukvaruföretag med människor + agenter. Vid 16 startade han sitt första mjukvaruföretag och har i tjugo år arbetat där software product management möter go-to-market. Medgrundare av Teklens, det delade Product Brain för mjukvaruteam. Innosuisse-expert och Springer Gabler-författare.