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 ...
CPQ-prosjekter: Bremsen alle kjenner, men få fjerner
Stemningen blir ofte litt trykket når noen sier det høyt: De fleste CPQ-prosjekter sluker 600 timer før selgerne ser noe de kan bruke. Tallet dukket opp igjen i en workshop forrige uke. Alle nikket gjenkjennende. Vi har alle vært der.
Jeg har jobbet med CPQ i 25 år. Det triste er ikke selve tallet. Det er hva 600 timer gjør med fremdriften i et prosjekt. Diskusjoner om prising fyller kalenderen. Utvikling av produktlogikk settes på vent. Adopsjon blir en fjern drøm for fase to. Innen du er live, har markedet endret seg, og de beste selgerne dine har gått tilbake til Excel.
Den virkelige kostnaden i et CPQ-prosjekt er ikke lisenser eller konsulenttimer. Det er forsinkelseskostnaden du har begynt å se på som normal.
Dette er et punkt mange beslutningstakere bør se på en gang til. For spillereglene har endret seg.
Den skjulte tregheten du faktisk kan fjerne
Mange tror CPQ-prosjekter er trege fordi produktkonfigurasjon er vanskelig. Det er stort sett feil. Konfigurasjon er detaljert, ikke nødvendigvis vanskelig. Tregheten ligger vanligvis tre steder, som du nå kan komprimere kraftig:
- Hente ut produktkunnskap fra PDF-er, prislister og tekniske datablader.
- Strukturere kunnskapen i moduler, varianter og avhengigheter som faktisk kan vedlikeholdes.
- Validere at dataene er komplette, konsistente og forståelige nok til at dere kan stole på dem.
Før gjorde et team av eksperter dette for hånd, med regneark og lange workshops som verktøy. Nå kan en AI-assistert prosess gjøre grovjobben på noen dager, mens ekspertene dine kan bruke tiden på å tenke.
Hvorfor dette er annerledes nå
Språkmodeller (LLM) er ingen magisk erstatning for produktlogikk. Men de endrer arbeidsmengden dramatisk. Når du kombinerer dem med tydelige, testbare regler, kan en fungerende CPQ-modell være oppe og gå på en uke. Vi har gjort det. På DTU satte vi opp et lastekran-eksempel fra et strukturert dokument, komplett med moduler, varianter og beskrivelser. Hos en heisprodusent brukte vi samme metode for å bygge en guidet salgsprosess oppå deres eksisterende Tacton-modell på dager, ikke kvartaler.
AI gjør grovjobben med å hente ut og strukturere data. Symbolsk logikk holder systemet ærlig.
Denne endringen er viktig. Business-caset for CPQ handler ikke lenger bare om salgseffektivitet. Det handler om implementasjonshastighet og smidighet. Raskere modellering gir raskere læring. Jo fortere du ser hvor selgerne nøler, hvor prisene er feil og hvor regler krasjer, jo fortere kan du fikse det.
Hvordan en hybrid tilnærming til CPQ kutter tidslinjen
Dette handler ikke om én super-plattform. Det er et valg om hvordan du designer systemet:
- Innsamling fra dokumenter: Gi systemet de dokumentene dere allerede har – prislister, produktkataloger, tekniske PDF-er. AI-en henter ut forslag til moduler, varianter, varenummer og beskrivelser som både mennesker og maskiner kan lese.
- Strukturert grunnlag: Resultatet lander i en ren, flat og modulær struktur. Én modul har varianter som utelukker hverandre, med tydelige ID-er, varenumre og en kort og lang beskrivelse per variant.
- Rekkverk, ikke gjetting: Under AI-laget ligger harde regler og avhengigheter. Hvis en type førerhus krever en bestemt chassishøyde, er den regelen eksplisitt og testbar. AI-en anbefaler; de harde reglene godkjenner eller avviser.
- Søkbar kontekst: En kunnskapsbase inneholder all tilleggsinformasjon. AI-en kan svare på hvorfor en regel er som den er, basert på de samme kildene som ble brukt til å bygge modellen.
- Automatisk validering: Systemet flagger automatisk manglende varenumre, brutte referanser, doble varianter og feilaktige avhengigheter. Tenk på det som en kontinuerlig sjekk av modellen.
- Test-scenarioer: Definer de vanligste tilbudsprosessene som test-scenarioer. Hver endring kjøres mot disse. Hvis noe brekker, ser du det med en gang, ikke tre uker etter en utrulling.
Resultatet? De første 400 timene av den berømte 600-timersblokken forsvinner. Teamet ditt kan bruke tiden på å ta beslutninger, ikke på tasting.
Hva hastighet betyr for business-caset
Når en fungerende modell er oppe og går på under en uke, skjer det tre ting:
- Omfanget slutter å ese ut. Du trenger ikke perfekt prising for å gå live. Du trenger et korrekt fundament og en måte å lære fort på.
- Styringen blir enklere. Produkteierne kan forholde seg til lesbare beskrivelser og regelforklaringer, ikke ugjennomtrengelig kode.
- Adopsjonen kommer i gang. Hvis systemet kan forklare seg selv, bruker selgerne det. Hvis det sparer dem for tid fra dag én, fortsetter de å bruke det.
Det er også en annen fordel: lavere kostnad for eksperimentering. Før krevde det et miniprosjekt å teste en ny produktpakke. Nå kan du prøve det ut på fredag og ta en datadrevet beslutning neste uke.
Fordelen som forsterker seg selv
Noen team vil bruke dette til å skape et stille forsprang. De vil behandle produktlogikk som et produkt. De vil vedlikeholde en levende kunnskapsbase og kjøre tester ved hver endring. Modellene deres vil bli klarere, prisingen enklere å forklare og salgssamtalene raskere.
Andre team vil fortsette som før. De vil vente på den perfekte prismodellen. De vil la logikken bli i hodene på fire nøkkelpersoner. De vil måle fremgang i PowerPoints, ikke i faktisk bruk. Deres CPQ-system vil se ferdig ut på papiret, men forbli valgfritt i praksis.
Fart er ikke et demo-triks. Det er slik du fortjener retten til å forbedre systemet i produksjon.
En praktisk plan for dette kvartalet
Hvis du vil kjenne på forskjellen, ikke bestill en ny utredning. Gjør fem konkrete ting:
- Ta tiden på de tre vanligste tilbudene, fra start til slutt. Inkluder all ventetid. Målet er ikke å fikse CPQ, men å fjerne treghet.
- Finn frem én prisliste og én produkt-PDF dere allerede har. Bruk dem til å bygge en enkel modell på en uke, med moduler, varianter, varenumre og beskrivelser.
- Definer ti absolutte regler. Skriv dem i klarspråk først. Kod dem deretter slik at systemet kan forklare dem tilbake til deg.
- Lag ti test-caser som speiler reelle salg. Sørg for at alle kan se dem. Kjør dem ved hver endring.
- Sett fem selgere foran et enkelt, guidet grensesnitt. Spør dem kun om to ting: Sparte det deg tid, og kunne systemet forklare seg selv?
Hos Siemens Healthineers, og i andre store, internasjonale prosjekter jeg har jobbet med, var det ikke prosjektene med de tykkeste rapportene som lyktes. Det var de hvor produktlogikken forble forståelig, regelsettet var testbart og selgerne merket at det gikk fortere.
Den nye ROI-historien
Dette er den egentlige nyheten bak 600-timers-tallet: En moderne tilnærming til CPQ flytter ROI-diskusjonen fra automatisering til smidighet. Når systemet både kan resonnere og forklare, slutter du å betale forsinkelseskostnaden og begynner å høste av kontinuerlig læring.
Hvis en fungerende modell kan være klar på en uke, hva ville du lært i uke to?
Kommentarer
Legg inn en kommentar