Gå til hovedinnhold

Hvorfor din CPQ trenger narrativdata før du legger til AI

En språkmodell vet hva en lastebil er. Den vet bare ikke noe om dine lastebiler. Det er her de fleste stopper opp når de prøver å legge AI på toppen av en CPQ som bare forstår varenummer, attributter og regler. Svarene ser overbevisende ut, men resonnementet er tynt. Selgeren spør hvorfor systemet anbefalte sovekabin, og får ikke noe svar. Jeg har sett dette i utallige workshops: Med en gang modellen får tydelig kontekst for hvorfor og når hvert valg er relevant, endrer samtalen seg. Systemet slutter å gjette og begynner å gi råd. Forskjellen er ikke AI-magi. Det er data med en fortelling. Delen som mangler i dataene dine Regeltabeller forteller systemet hva som er *gyldig*. De sier ingenting om hvorfor et valg er *smart*, når det gjelder, eller når det er en dårlig idé. Dette gapet flytter vurderingene tilbake til e-posttråder, regneark og stilltiende kunnskap som bare noen få sitter på. Så kaller vi det et adopsjonsproblem. For at AI-en skal kunne resonnere, trenger den ikke flere ...

Tilbudsprosessen din er ødelagt. Ikke start med et nytt verktøy.

Your Quoting Is Broken. Don't Start With a New Tool.

Slutt å diskutere hva som er galt. Definer heller spørsmålet.

Jeg har vært i akkurat det møtet. Alle nikker og er enige om at tilbudsprosessen ikke fungerer, men så sprekker rommet. Salg skylder på CPQ-systemet. IT peker på datakvalitet. Økonomi snakker om rabattdisiplin. Ingeniørene lurer på hvorfor CAD-teamet dras inn i hvert eneste salg. Resultatet er ikke en plan, men en fast, unødvendig kostnad for bedriften.

Det som mangler, er en felles diagnose. Dere trenger ikke et nytt verktøy ennå. Dere må bli enige om hvilket spørsmål dere prøver å svare på.

Bra i hvert enkelt system. Feil når alt settes sammen.

ERP-systemet har sin sannhet. PLM har en annen. CRM en tredje. Hver for seg har de rett, men de kommer i konflikt når en kunde ber om et reelt produkt til en reell pris med en reell leveringstid. CPQ skaper ikke disse konfliktene, systemet avdekker dem. Å kaste seg over en ny plattform eller en stor integrasjonsjobb uten en felles diagnose, fører bare til at feilene skjer fortere.

Datakvalitet er ikke en diskusjon. Det er en målbar operasjonell risiko.

Den raskeste beslutningen er den riktige beslutningen tatt tidlig. Fart har bare verdi når dataene er korrekte. Jeg liker organisasjoner som jobber raskt. Men når alles klokker viser ulik tid, hjelper det ikke å løpe fortere. Da går du deg bare fortere vill.

Tre diagnostiske alternativer som matcher tre spørsmål

Veien til en moderne tilbudsprosess er ikke ett gigantisk prosjekt. Det er en serie svar på tre ulike spørsmål. Definer spørsmålet først. Velg deretter omfanget på arbeidet som passer.

Alternativ 1: En helsesjekk (Liten) – Hvor blør vi mest akkurat nå?

Dette er en fokusert, overordnet vurdering når du trenger klarhet i løpet av uker, ikke kvartaler. Vi finner de gapene som skaper unødvendige kostnader, forsinkelser eller risiko i dag.

Fokus: Finne de 2–3 største flaskehalsene som gir resultater innen 30–60 dager.

Kommersiell analyse: En gjennomgang av dagens prosesser for konfigurasjon, prising og tilbud for å finne flaskehalser. Vi ser på ting som gjennomløpstid, antall revisjoner, godkjenningstid og rabattnivåer. Et tilbud er en prognose, så behandle det deretter.

System- og prosesskartlegging: En overordnet sjekk av systemlandskapet, datakvalitet fra CAD og integrasjonene som berører CPQ. Vi ser etter manuell punching, dobbeltarbeid, dårlige filoverføringer og hvor CAD-til-tilbud bremser salget.

Datagrunnlag for AI: En sjekk av datakvalitet og om organisasjonen er klar for LLM og maskinlæring. Har dere data på vinn og tap? Stabile identifikatorer? En taksonomi som kan trene en modell? Dette handler ikke om hype, men om innsatsfaktorene faktisk finnes.

Resultat: En kort risikovurdering, en prioritert liste over tiltak og en handlingsplan for de neste 60 dagene. Ingen plattformvalg. Bare enkle kutt som fjerner sløsing.

Alternativ 2: Et veikart (Medium) – Vi kjenner problemene. Hva er riktig rekkefølge for å løse dem?

Når ledergruppen er enig om smerten, men uenig om rekkefølgen, trenger dere en solid plan. Dette er dypdykket som sikrer at dere slipper å gjøre jobben om igjen.

Fokus: Et dypdykk som designer rekkefølge og avhengigheter, slik at dere kan investere trygt.

Kommersielt dypdykk: Vi analyserer produktlogikk og prisverktøy for å lage et veikart for automatisering: hvor vi kan standardisere, hvor vi kan automatisere regler, hvor vi kan legge til rette for «guided selling», og hvordan vi kan redusere antall saker som eskaleres til ingeniørene.Integrasjons- og plattformkartlegging: En teknisk plan for å samle et fragmentert systemlandskap, inkludert detaljerte krav til CAD-prosesser. Vi definerer hvor masterdata for produkter skal bo, hvem som eier prisingen, og hvordan CPQ henter data uten klipp og lim.Analyse av AI-muligheter: Vi vurderer konkrete bruksområder for LLM og maskinlæring i salgsprosessen. Eksempler kan være å rute godkjenninger basert på vinnersannsynlighet, eller sjekke om data fra CAD stemmer overens med produktreglene. Maskinlæring må gjøre seg fortjent til plassen sin ved å effektivisere arbeidet, ikke ved å spå om alt mulig.Resultat: En plan over flere kvartaler med budsjettestimater, arkitekturskisser og milepæler som både styret og IT-avdelingen har tillit til.

Alternativ 3: En detaljert plan (Stor) – Hvordan gjør vi tilbudsprosessen til et varig konkurransefortrinn?

Når målet er en full transformasjon med implementeringsklare spesifikasjoner, er dette den rette tilnærmingen. Dette er mer enn en analyse; det er en oppskrift dere kan bygge etter.

Fokus: Fullskala optimalisering og implementeringsklare spesifikasjoner. Her designer vi systemet for å skalere på tvers av regioner, kanaler og produktlinjer.

Optimalisering av kommersiell strategi: Vi restrukturerer produktporteføljen og prismodeller for å maksimere treffsikkerhet og effektivitet i tilbudsarbeidet. Rabatter blir målrettede, ikke en vane. En rabatt er en beslutning som bør baseres på signaler, ikke magefølelse.

Samling av det digitale økosystemet: En komplett arkitektur for konsolidering av plattformer, 3D-visualisering og sømløs integrasjon. CAD-til-tilbud blir en formalisert prosess med tydelig eierskap og standarder, slik at ingeniørene ikke lenger er en flaskehals.

Implementering av avansert intelligens: Vi lager en implementeringsstrategi for LLM-assistert salg og prediktive BI/ML-verktøy. Bruk historiske tilbud – både vinn og tap – som treningsdata. Tilbud er som en ferdskriver. Å ignorere den informasjonen er å fly i blinde.

Resultat: Implementeringsklare spesifikasjoner, ny driftsmodell, styringsmodell og en utrullingsplan med tydelige målepunkter. Systemet er kun en suksess hvis det endrer den daglige adferden.

Automatisering fjerner manuelle feil og frigjør tid til beslutninger som faktisk betyr noe.

Jeg husker en produsent som ville ha et nytt CPQ-system fordi godkjenninger tok for lang tid. Dataene viste at 42 % av forsinkelsene skyldtes omarbeid fordi attributter fra CAD ikke stemte med produktmodellen. Tre klokker, alle korrekte, men alle viste ulik tid. Vi standardiserte attributtene, definerte hvem som eide prisingen, og sørget for at tilbud med lav vinnersjanse ikke havnet hos ingeniørene. Godkjenningene gikk raskere, uten at vi byttet verktøy.

Riktig alternativ avhenger av spørsmålet. Hvis huset lekker, finn den raskeste løsningen. Hvis huset er ineffektivt, planlegg renoveringen. Hvis du skal bygge nytt, lag en fullstendig tegning.

  • Velg Alternativ 1 når du trenger en rask, faktabasert oversikt over de største risikoene. Forvent en skarp liste med tiltak dere kan gjennomføre på 60 dager.
  • Velg Alternativ 2 når dere har kommet forbi skyldfordelingen og er klare for å diskutere rekkefølge. Forvent en plan du kan forsvare i styrerommet og levere på, kvartal for kvartal.
  • Velg Alternativ 3 når dere er klare for å bygge om hele prosessen for tilbud, prising og CAD-til-tilbud til et reelt konkurransefortrinn. Forvent detaljer på byggenivå.

Velg spørsmål, og kom i gang

Dette handler ikke om små, mellomstore eller store prosjekter. Det handler om å tilpasse dybden på arbeidet til spørsmålet som faktisk gir fremdrift. Definer rammen først. Så ser du hva som passer inni.

Teamene dine vil takke deg for at det blir mindre diskusjon. Kundene dine vil merke at dere er mer konsekvente. Og marginene dine vil slutte å lekke ut gjennom systemer som ikke snakker sammen.

Slutt å diskutere symptomer. Start med å definere spørsmålet. Diagnosen må komme før resepten.

Kommentarer

Populære innlegg fra denne bloggen

Indirekte salg uten kaos: Slik fungerer CPQ-styring

«Partnerne våre trenger mer frihet.» «Jus-avdelingen krever strengere kontroll.» «Økonomi vil ha bedre innsyn.» Du har hørt alle tre i samme uka. Det har jeg også. Fristelsen er å kaste flere rettigheter på problemet og håpe det løser seg. Det er da de stille feilene begynner å hope seg opp. Jeg ser et mønster i partnerprogrammer: Den første partneren får det samme oppsettet som det interne salgsteamet. Den andre får noen justeringer. Når du har fem partnere, har du tre måter å gi rabatt på og fire ulike godkjenningsløp. Alt er halvveis dokumentert. Alle kan teknisk sett lage et tilbud. Ingen kan forklare hvorfor det siste ble godkjent. Frihet uten rammer er bare en raskere måte å ødelegge tillit på. Dette handler ikke om partneradministrasjon. Det er et problem med styring og struktur i CPQ-systemet – det vi kaller governance. Former du eierskap, innsyn og handlinger på en god måte, slutter kanalsalg å være en politisk kamp og blir et kontrollert system. Du bruker samme CPQ-modell, m...

Hva er en salgskonfigurator? (Og hvorfor det ikke bare er et tilbudsverktøy)

I alle bedrifter som selger komplekst utstyr, finnes det en «Sara». Hun kan produktet inn og ut. Hun kan gjøre et rotete kundebehov om til en ren, byggbar løsning mens andre fortsatt åpner regneark. Hun er en helt. Men hun er også en flaskehals. Jeg husker en global utrulling der hvert eneste store tilbud måtte innom én spesialist for godkjenning. Avtaler ble satt på vent. Godkjenninger hopet seg opp. Verktøyene var det ingenting i veien med. Trafikkmønsteret, derimot, var problemet. Når veksten avhenger av hodet til én person, har du ikke en salgsprosess. Du har en flaskehals med et navn. Vi trenger ikke en større kalkulator. Vi trenger en oversetter. Mange tror løsningen er et stort CPQ-prosjekt som koder ned alle tenkelige regler. Det høres trygt ut, men ender vanligvis opp med å bli tregt, dyrt og rigid. Du bruker måneder på å modellere unntak, bare for å oppdage at selgerne allerede har funnet opp nye. Det virkelige problemet er ikke regnestykket bak tilbudet. Det er oversettelse...

Tillit skalerer ikke med mindre du designer din CPQ for det

Den beste tekniske selgeren din har nettopp brukt ti timer på å bygge bunnsolid tillit hos en kunde. Behovene er avklart. Kompromissene er smarte. Alle nikker. Så kommer tilbudet: et 12-siders regneark med produktkoder. All fremdrift stopper opp. Jeg har sett det for mange ganger. Selgeren bygger tillit i møterommet, men så river verktøyene våre den ned etterpå. Tilbudet er teknisk korrekt, men kjøpsopplevelsen skaper nå mistillit. Tillit bygges i samtaler og rives ned i regneark. Dette handler ikke om dårlig opplæring. Det er et problem med systemdesign. Den skjulte kostnaden ved overleveringer De fleste ser på CPQ som et tilbudsverktøy. Det håndhever produktregler, beregner priser og lager et dokument. Det høres fornuftig ut, helt til du ser hva som skjer mellom behovsanalyse og kontrakt. Kunden forlater møtet med en krystallklar forståelse av hva de skal oppnå: «Vi trenger løsning X for å passe inn på Y plass, med Z kapasitet, og vi er mest opptatt av energikostnad og oppetid.» Dok...