Så stärker konsulter säljstödet med hjälp av AI-driven modellering

1. Pre-sales-paradoxen i digital transformation

Det moderna it-konsultlandskapet kännetecknas av en brutal paradox. Efterfrågan på digital transformation är rekordhög, drivet av behovet att modernisera legacy-system, migrera till molnet och införa händelsedrivna arkitekturer. Samtidigt har kostnaden för försäljning av dessa högvärdiga uppdrag skjutit i höjden. Digitala transformationsinitiativ har ofta en misslyckandegrad som uppges vara så hög som 70 procent, ofta beroende på kommunikationshinder, felanpassade krav och det “semantiska gapet” mellan affärsintressenter och tekniska genomförandeteam.

För it-konsulter skapar denna miljö en balansgång på slak lina: de måste visa djup domänkompetens och teknisk genomförbarhet innan ett avtal ens är signerat, samtidigt som de ofta bär kostnaderna för pre-sales-arbete som obetald overhead.

Den traditionella pre-sales-verktygslådan – bestående av statiska presentationsbilder, osammanhängande kalkylblad och omfattande kravdokument – är alltmer otillräcklig för komplexiteten i moderna distribuerade system. Dessa artefakter är i praktiken “döda vid ankomst” eftersom de inte fångar affärsprocessernas dynamiska och tillståndsändrande natur.

Konsulter hamnar ofta i en tidskritisk situation där de måste förstå komplexa kunddomäner och föreslå en sammanhängande arkitektur inom dagar. Oförmågan att överbrygga gapet mellan kundens abstrakta affärsbehov och en konkret teknisk lösning leder ofta till förlorade affärer – och ännu värre, felaktigt avgränsade fastprisprojekt som urholkar marginalerna.

I detta sammanhang växer en ny strategisk metod fram: att operationalisera principerna från Event Storming och Domain-Driven Design (DDD) genom AI-driven modellering. Detta gör det möjligt att snabbt omvandla den kaotiska “discovery-fasen” till en strukturerad leveransritning. Denna artikel analyserar hur detta fungerar som en kraftmultiplikator för sales engineering genom att minska ledtider för offerter, visualisera komplexa legacy-system och flytta kunddialogen från riskfyllda antaganden till förtroendebaserat samarbete.

2. Att överbrygga det semantiska gapet

2.1 Visuell semantik

Till skillnad från generella whiteboardverktyg som behandlar varje form som en meningslös vektor, bygger en modelldriven metod på semantisk metadata. En ruta är aldrig bara en form, utan ett dataobjekt med specifika egenskaper och beteenden definierade enligt Domain-Driven Design (DDD).

När en konsult placerar ett “Command”-kort på arbetsytan tolkar systemet det som en användarintention som triggar en tillståndsförändring. Ett definierat “Aggregate” identifieras i sin tur som en konsistensgräns för datatransaktioner.

Denna semantiska djupnivå överbryggar klyftan mellan “affärsprocessen” och “mjukvarudesignen”. Den visuella processkartan och den underliggande domänmodellen förblir synkroniserade, vilket säkerställer att mjukvarans arkitektur alltid är en direkt spegling av det optimerade affärsflödet. För konsulten innebär detta att den “polerade bild” som visas för kunden under en säljpitch i själva verket är stommen i produktionskoden och skapar en sömlös kontinuitet från första handslag till sista commit.

2.2 AI som co-pilot

Integrationen av generativ AI förändrar i grunden ekonomin i pre-sales-arbete. Tidigare krävdes dagar av manuellt arbete för att skapa detaljerade processkartor och domänmodeller. Med dagens AI-förmågor kan dessa modeller istället genereras på minuter utifrån naturliga språk- eller domänbeskrivningar. Detta innebär att AI inte längre enbart är en textgenerator, utan snarare kan betraktas som en “domänarkitekt”.

När en konsult matar in en prompt – exempelvis en beskrivning av ett hotellbokningsflöde – kan AI:n skapa ett visuellt arbetsflöde med swimlanes, events, queries och commands. Denna “strawman”-modell blir ett kraftfullt utgångsläge för kunddialoger, där konsulten kan gå in i rummet med en fungerande hypotes istället för ett blankt papper.

Detta skifte från “interrogation” (att fråga kunden vad de gör) till “validation” (att låta kunden korrigera modellen) accelererar förtroendebyggandet avsevärt och möjliggör ett mer proaktivt och kompetensdrivet arbetssätt.

2.3 Event Storming som samarbetsmetod

Event Storming är ett samarbetsbaserat workshopformat utformat för att utforska komplexa verksamhetsdomäner. Med digitalt stöd bidrar det till att bryta upp de silos som ofta präglar stora organisationer.

I många organisationer har funktioner som ekonomi, logistik och it olika bilder av hur verksamheten faktiskt fungerar. Event Storming samlar dessa intressenter för att gemensamt kartlägga domänhändelser på en gemensam tidslinje.

För en konsult är facilitering av denna typ av samskapande en högt värderad tjänst.  Metoden möjliggör en form av “kaotisk utforskning”, där deltagarna först bidrar fritt, följt av en mer strukturerad organiseringsfas. Processen synliggör dolda flaskhalsar och “hotspots”, samtidigt som den skapar förankring genom att deltagarna ser sina perspektiv reflekteras i modellen.

3. Metodens kärna: Event Storming som säljmotor

3.1 Big Picture Event Storming: “Hooken”

Den initiala fasen i varje konsultuppdrag handlar om att diagnostisera problemet. Big Picture Event Storming är den mest lämpliga metoden för denna upptäcktsfas, då den fokuserar på hela verksamheten och kartlägger händelser på hög nivå över organisatoriska gränser för att bedöma verksamhetens hälsa.

I ett pre-sales-sammanhang är målet med denna session att identifiera “hotspots” – smärtpunkter, konflikter och obesvarade frågor som representerar kundens mest akuta problem. Konsulten kan visualisera dessa hotspots på en tidslinje för att göra det osynliga synligt. En kund kan veta att faktureringen är långsam, men att se ett kluster av röda “problem”-kort mellan händelserna “order skickad” och “faktura skickad” skapar en konkret känsla av brådska. Detta visuella bevis blir en central del av säljargumentet, där konsultens tjänster positioneras som den direkta lösningen på de identifierade friktionspunkterna.

3.2 Processmodellering: “Lösningen”

När problemet är definierat går arbetet vidare till att formulera lösningen. Processmodellering snävar in fokus till en specifik affärsprocess, exempelvis “orderhantering” eller “kundonboarding”. Här kan konsulten kartlägga informationsflöden och introducera begrepp som “roller” (aktörer) och “read models” (information som användare behöver).

Denna detaljnivå är avgörande för riskminimering. En vanlig orsak till misslyckade fastprisprojekt är att dold komplexitet upptäcks först efter att kontraktet är påskrivet. Genom att noggrant modellera processen tillsammans med kunden identifierar konsulten edge cases och alternativa flöden – såsom “betalning misslyckades” eller “slut i lager” – innan de blir kostsamma överraskningar. Den resulterande processkartan fungerar som en visuell scope-definition som skyddar både kund och konsult från oklarheter.

3.3 Mjukvarudesign: “Ritningen”

Den sista nivån, mjukvarudesign, överbryggar gapet till implementation. Här definierar konsulter aggregat, kommandon, entiteter och bounded contexts, vilket i praktiken innebär att systemarkitekturen designas.

För tekniska beslutsfattare, såsom en kunds CTO, fungerar denna fas som ett “kompetensbevis”. Att se en konsult tillämpa Domain-Driven Design-principer för att separera exempelvis shipping context från billing context signalerar arkitekturell mognad och systemförståelse. Det ger kunden trygghet i att lösningen kommer att vara modulär, skalbar och underhållbar. Dessutom möjliggör denna detaljerade design mer exakta uppskattningar av utvecklingsinsats, vilket gör det möjligt för konsulten att lämna konkurrenskraftiga men lönsamma anbud baserade på en beräknad mängd aggregat och kommandon snarare än grova uppskattningar.

4. Operationalisering av AI: från prompt till prototyp

AI gör det möjligt för konsulter att komprimera dagar eller veckors arbete till timmar – inte enbart genom ökad produktion, utan också genom att möjliggöra utforskning av flera olika lösningsscenarier.

4.1 Prompt engineering-flödet

AI kan användas genom naturliga språkbeskrivningar för att generera strukturerade arbetsflöden och metadata. Till exempel kan en konsult som förbereder en pitch för en hotellkedja använda prompten:
“Skapa ett hotellbokningsflöde inklusive gästregistrering, tillägg av rum av manager, bokning, incheckning, GPS-koordinatspårning och betalningshantering”.

AI:n bearbetar detta och genererar visuella modeller för användarflöden och domänmodeller, inklusive events, swimlanes (roller), aggregates, commands, queries och datamodeller.

Den genererade modellen är sällan perfekt – men den ger en 50–70 procent färdig grund. Denna “jumpstart”-effekt gör att konsulter kan hantera fler RFP:er, eftersom både startkostnad och initial kognitiv belastning minskar avsevärt.

4.2 Förfining av datamodellen

Varje steg i arbetsflödet kan berikas med definitioner av in- och utdata. AI kan föreslå relevanta datafält medan konsulten justerar och förfinar modellen. På så sätt designas användargränssnittets wireframe och databasschemat parallellt.

Om kunden exempelvis anger att “passnummer” krävs vid incheckning läggs detta till i modellen. Denna ändring uppdaterar både den visuella modellen som kunden ser och den underliggande domänmodellen som senare kan generera kod.

Denna synkronisering säkerställer att den “skärm” kunden godkänner motsvarar den faktiska datastruktur som utvecklare eller AI-verktyg behöver. På så sätt samordnas UI-design, datamodeller och domänlogik samtidigt, och ändringar i en del av modellen speglas konsekvent i helheten.

4.3 Mot automatiserad kodgenerering

Eftersom modellen innehåller strukturerad domänmetadata kan den användas som grund för att generera tekniska artefakter, såsom API-specifikationer eller standardkod som följer den önskade arkitekturen.

För en sales engineer-konsult innebär detta möjligheten att leverera en fungerande prototyp redan i samband med offerten. I ett säljmöte kan konsulten exempelvis säga: “Vi har modellerat er process, och här är den genererade API-specifikationen samt en initial kodbas för era mikrotjänster.”

Denna nivå av konkretion är mycket övertygande. Den visar att konsulten inte bara säljer presentationer, utan är redo att leverera. Den genererade koden använder det “ubiquitous language” som definierats i workshopen, vilket innebär att begrepp och variabelnamn speglar affärsspråket. Det minskar den kognitiva friktionen för framtida utvecklare och förbättrar överlämning och långsiktig förståelse.

5. Konverteringsarkitektur: att visualisera värde

Det yttersta målet för all sales engineering är konvertering – att omvandla en prospekt till en kund. AI-assisterad modellering stödjer denna process genom att göra värde synligt och komplexitet hanterbar.

5.1 User Story Map som förhandlingsverktyg

En av de mest konfliktfyllda delarna i alla fastprisprojekt är scope-förhandlingar. Kunder vill ofta inkludera allt, medan budgeten sätter tydliga begränsningar. User Story Mapping erbjuder ett visuellt ramverk för att hantera denna balans.

Verktyget gör det möjligt för konsulter att växla från processdiagram till en User Story Map, där krav organiseras efter processsteg och releaser (värdesläpp). Under ett möte kan konsulten, när kunden insisterar på en komplex funktion, visuellt placera den i “Release 1”. Om “Release 1” blir överfull kan en lägre prioriterad funktion flyttas till “Release 2”.

Denna typ av visuell avvägning gör tid- och budgetbegränsningar konkreta för kunden. Det förändrar dialogen från “du säger nej till mig” till “vi prioriterar värde tillsammans”.

5.2 Samarbetsbaserad röstning och prioritering

Att skapa samsyn mellan kundens interna intressenter är ofta en av de svåraste delarna i en affärsprocess. Samarbetsbaserad röstning och kommentering gör det möjligt att samla och strukturera denna input genom att deltagare röstar på och kommenterar specifika krav eller hotspots.

I en workshop är detta särskilt effektivt. Om marknadschefen anser att “social login” är kritiskt medan operationschefen prioriterar “lagerintegration”, kan konsulten genomföra en gemensam röstningssession.

Resultatet blir en transparent, gemensam prioriteringslista. Konsulten kan därefter rama in förslaget kring de mest prioriterade behoven, vilket säkerställer att erbjudandet speglar gruppens samlade uppfattning om värde. Metoden minskar påverkan från intern politik och riktar projektet mot det som upplevs som högst affärsvärde.

6. Integrationsekosystem: bron till leverans

En central oro för kunder är risken för “vendor lock-in” samt hur enkelt det är att överlämna domänmodellen från design till faktisk leverans. Detta bör hanteras genom robust integration med etablerade planerings- och leveransplattformar, såsom GitHub, Jira Cloud och Azure DevOps, samt MCP-integration med AI-baserade kodagenter.

Verktyg bör även kunna generera JSON- och OpenAPI-specifikationer (Swagger) direkt från domänmodellen. Detta är särskilt värdefullt i API-first-projekt. Konsulten kan definiera queries, commands och dataattribut i det visuella gränssnittet, och verktyget genererar det kontrakt som frontend- och backendteam använder för att kommunicera.

Detta minskar den “integration hell” som ofta uppstår i mitten av konsultprojekt, eftersom gränssnittet är strikt definierat och validerat innan en enda rad kod skrivs.

7. Modellering kontra ritning

Varför skiljer sig AI-driven modellering från andra verktyg? En avgörande distinktion ligger mellan “ritning” och “modellering”. Generella verktyg möjliggör visualisering men saknar semantisk struktur. Resultatet blir ofta statiska artefakter som måste översättas manuellt till leveransverktyg.

En elektronisk whiteboard är i praktiken en digital hög av post-it-lappar utan inneboende förståelse för vad informationen betyder. När en workshop är avslutad måste någon manuellt överföra innehållet till Jira eller andra system, vilket är både tidskrävande och felbenäget.

I kontrast säkerställer strukturerad modellering konsistens och producerar levande dokumentation som utvecklas tillsammans med systemet. Detta sparar konsulten många timmar administrativt arbete och bevarar informationskvaliteten från idé till implementation.

8. Framtidsutsikter

I takt med att AI fortsätter att utvecklas kommer “standardarbetet” kring kodning och dokumentation i allt högre grad att automatiseras. Konsultens värde kommer därmed att förflyttas från att “kunna koda” till att “veta vad som ska byggas”.

Fördjupad kompetens inom Event Storming, Domain-Driven Design och AI-assisterad modellering placerar konsulter i detta högre värdeskikt. Det gör dem till arkitekter av affärsvärde snarare än enbart skapare av mjukvara.

9. Slutsats

Digital transformation kräver mer än teknisk kompetens – det kräver samordning, tydlighet och gemensam förståelse. AI-drivna, modelldrivna arbetssätt baserade på Event Storming och Domain-Driven Design adresserar konsultbranschens kärnutmaningar: bristande alignment, scope creep och höga pre-sales-kostnader.

Genom att göra komplexitet synlig och samarbetet strukturerat kan konsulter gå från spekulativa förslag till evidensbaserade lösningar, samtidigt som de sparar tid, bygger förtroende, minskar risk och ökar sannolikheten för framgångsrika projekt.