Vad CPQ-integrering behöver hantera i båda riktningarna
En konfigurator är bara så bra som datan den matas med och ordern den skapar. Båda riktningarna korsar en systemgräns.
- Produkt- och tillvalsdata inåt: vilka komponenter, funktioner och varianter som för närvarande finns tillgängliga, lagrade i affärssystemet eller produktinformationssystemet
- Kostnader och prissättning inåt: aktuella kostnader, avtalspriser och rabattbehörigheter från affärssystemet, så att offerten speglar marginalen, inte listpriset
- Tillgänglighet och ledtid inåt: om kombinationen kan levereras enligt löfte, vilket bara affärssystemet eller planeringssystemet vet
- Konfigurationen utåt: den accepterade offerten omvandlad till en kundorder i affärssystemet, med tillhörande stycklista och arbetsplan
- Orderstatus tillbaka till säljavdelningen: produktions- och leveransstatus som skickas tillbaka till CRM-systemet, så att säljaren kan svara kunden
De flesta CPQ-implementeringar löser det första inåtgående flödet med en periodisk produktexport och stannar där. Det utåtgående flödet, det som omvandlar en accepterad offert till en order, lämnas nästan alltid till en människa.
Varför skrivs en konfigurerad offert in på nytt i affärssystemet?
En konfigurator och ett affärssystem beskriver samma produkt på olika språk. Ett CPQ-system hanterar en konfiguration som valda tillval mot en modell, vilket är hur en säljare ser på saken. Affärssystemet behöver en stycklista och en arbetsplan, vilket är hur en fabrik ser på saken. Att översätta mellan dem innebär att definiera hur varje tillval motsvarar delar och operationer. Det är enklare att låta en människa göra det varje gång än att lösa det en gång för alla.
Konfigurerbara produkter driver behovet av översättning bortom vad som kan förberedas i förväg. En produkt med femton valgrupper har fler giltiga kombinationer än vad ett företag någonsin kan definiera som fasta artikelnummer. ERP-posten måste därför sammanställas för varje order, vilket är precis det arbete som CPQ-systemet var tänkt att ha utfört. Det är en anledning till att ERP-integration inom tillverkningsindustrin sällan stannar vid en enda mappning.
Inget av detta framgår av affärsnyttan för CPQ, eftersom den baserades på offerthastighet. Kostnaderna visar sig senare och hamnar hos en annan avdelning.
Vad bristfällig CPQ-integration kostar efter försäljningen
Förlusterna hamnar i produktionen, på ekonomiavdelningen och hos säljarna, vilket är anledningen till att ingen summerar dem och spårar dem tillbaka till offertarbetet.
- Konfigurationsfel som når produktionen: ett felaktigt valt tillval gör att en enhet byggs enligt fel specifikation, vilket upptäcks vid inspektion eller av kunden
- Offerter prissatta utifrån inaktuella kostnader: en konfiguration prissatt utifrån en kostnadstabell som uppdaterades förra kvartalet, för en produkt vars materialpriser har ändrats
- Leveransdatum utlovade utan hänsyn till kapacitet: en ledtid baserad på en standard snarare än på den aktuella orderboken
- Säljare som inte kan svara på statusfrågor: kunden frågar var deras order befinner sig och säljaren måste gå och efterforska
Det första når kunden, eftersom en enhet byggd enligt en specifikation som ingen sålt resulterar i omarbete eller kreditering. Alla fyra koncentreras till en viss typ av verksamhet.
Konfigurerbara produkter är där CPQ-integration verkligen gör nytta
Företag som säljer standardartiklar ur en katalog behöver sällan CPQ, eftersom en offert bara är en prislisteslagning. En distributör som offererar standardfästelement läser av ett nummer från en lista. En tillverkare som offererar en industriell pump specificerar pumphjulsstorlek, tätningsmaterial, motoreffekt och ytbehandling, och varje kombination innebär en unik uppsättning delar och en specifik monteringssekvens.
Det är därför verktyget är så värdefullt inom configure-to-order-tillverkning, och varför överlämningen till ERP-systemet är svårast där. Den komplexitet som gör manuell offerthantering långsam är samma komplexitet som gör det svårt att omvandla en konfiguration till en order som går att bygga. Att lösa den främre delen utan den bakre flyttar bara flaskhalsen istället för att eliminera den.
Tillverkare som får ut fullt värde av CPQ betraktar konfigurationsmodellen som delad infrastruktur, inte som ett säljverktyg. Reglerna för vad som kan byggas finns på ett ställe, och både offerten och ordern utgår från dem. Att hålla dessa regler uppdaterade kräver samma disciplin som styr tekniska ändringsordrar, eftersom ett alternativ som ändras måste ändras i båda ändar. Det lämnar den praktiska frågan om var kopplingen mellan offert och order faktiskt byggs.
Hur kopplar en integrationsplattform ihop CPQ med affärssystemet?
Kopplingen mellan offert och order byggs på en av tre platser, var och en med sina begränsningar. Det första alternativet är att köra CPQ inuti affärssystemet, vilket tar bort överlämningen helt men oftast ger en sämre säljupplevelse. Det andra är ett specialiserat CPQ-system som kopplas till affärssystemet via en färdig koppling från leverantören. Det fungerar för vanliga systemkombinationer men tar stopp när produktmodellen är ovanlig, vilket för konfigurerbara produkter är fallet för det mesta. Det tredje är att en person läser offerten och knappar in den i affärssystemet, vilket är vad de flesta företag faktiskt gör och vad som begränsar nyttan.
För att föra över en validerad konfiguration till affärssystemet, prissätta den mot aktuell kostnad och kontrollera ett datum mot orderboken, behöver en tillverkare ett lager mellan konfiguratorn och de bakomliggande systemen. Det lagret är en integrationsplattform (iPaaS), och att bygga kopplingarna där innebär att varje koppling konfigureras en gång istället för att byggas om för varje produktfamilj. På Alumio iPaaS tar det fyra former.
- Konfiguration omformad till en orderstruktur: en datatransformator mappar valda alternativ till den stycklista, rutt och artikelnummer som affärssystemet kräver, så att en offert blir en order utan manuell inmatning
- Prissatt mot aktuell kostnad: en realtidsproxy kontrollerar aktuell kostnad, avtalspriser och rabattbehörighet i affärssystemet medan offerten skapas, istället för att använda en tabell som exporterades förra kvartalet
- Tillgänglighet kontrollerad före löftet: samma synkrona kontroll läser orderboken och komponenttillgängligheten, så att det utlovade datumet är ett som fabriken kan hålla
- Status återförd till säljaren: en händelsestyrd datarutt skickar tillbaka produktions- och leveransstatus till CRM-systemet, så att säljaren kan svara direkt från det system de redan använder
Dessa flöden konfigureras snarare än att byggas för hand för varje produktfamilj, med en kodtransformator tillgänglig där konfigurationen inte kan uttrycka en regel. En ny alternativgrupp blir en mappningsändring, inte ett projekt. Det som förändras är inte hur snabbt en offert skapas, utan om offerten och ordern beskriver samma sak.
Vad CPQ-integration ger en tillverkare
CPQ motiveras ofta med offerthastighet och vinstgrad, vilka båda mäter den första halvan av processen. Arbetet efter offerten är uppdelat på tre roller. Säljingenjören ansvarar för konfigurationen och går vidare när kunden skrivit på. Orderadministratören bygger upp den på nytt i affärssystemet och bär risken för ett felaktigt inmatat alternativ. Produktionsplaneraren schemalägger utifrån vad som än kommer in. Ingen av dem ser hela kedjan, vilket gör detta till ett integrationsbeslut snarare än en utbildningsfråga.
Att koppla ihop konfiguratorn med affärssystemet förändrar verktygets värde. En offert som blir en order utan ett manuellt steg behåller den konfiguration som validerades. Vad verksamheten får är färre specifikationsfel i produktionen, offerter prissatta utifrån aktuella kostnader och leveransdatum som fabriken faktiskt kan hålla.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
