Er konfigurator är inte problemet. Er arkitektur kan vara det.

Det finns ett välbekant ögonblick inom tillverkande industri.

Säljavdelningen vill skicka offerter snabbare. Konstruktion vill ha färre avbrott. IT vill ha något underhållsbart. Ekonomiavdelningen vill ha ett business case som inte innehåller frasen "det löser vi senare".

Då ställer någon en fullt rimlig fråga:

"Ska vi bara bygga en egen konfigurator?"

Någon annan föreslår att köpa ett CPQ-system. En tredje person nämner en befintlig plattform. Inom kort har mötet förvandlats till en debatt om mjukvara, licenser, API:er och huruvida det nuvarande ERP-systemet på något sätt kan göra allt.

Under tiden förblir det faktiska problemet orört.

Kunderna väntar på offerter. Konstruktörerna kontrollerar konfigurationer som ser misstänkt lika ut som de de kontrollerade förra tisdagen. Och säljavdelningen frågar fortfarande Bob på konstruktionsavdelningen om just den där kombinationen av komponenter kommer att fungera.

Bob kan svaret. Bob kan alltid svaret.

Det är precis det som är problemet.

Bygga eller köpa: fel fråga att börja med

Att bygga sin egen mjukvara låter attraktivt av goda skäl.

Ni styr funktionaliteten. Ni kan skräddarsy upplevelsen för era produkter. Ni tvingas inte organisera er verksamhet kring någon annans idé om hur saker och ting ska fungera.

Och om era produkter är genuint komplexa, spelar dessa saker roll.

Men att bygga mjukvara är inte en engångshändelse. Det skapar ett löpande ansvar för utveckling, underhåll, säkerhet, infrastruktur och allt som händer när verksamheten förändras.

Ert produktsortiment utvecklas. Prissättningen ändras. Nya marknader dyker upp. ERP-system uppgraderas. Utvecklaren som skrev den där smarta kodsnutten för fem år sedan kanske gör något helt annat nu.

Gratulerar. Ni äger nu en mjukvaruprodukt utöver er tillverkningsverksamhet.

Att köpa mjukvara har sina egna fördelar. Etablerad funktionalitet, befintlig infrastruktur och en underhållen produkt kan spara avsevärd ansträngning. Men en plattform som fungerar utmärkt för vanliga katalogprodukter kan få problem när er produkt konstrueras utifrån en komplicerad uppsättning tekniska regler.

Och den dyraste begränsningen är inte nödvändigtvis en saknad funktion.

Det är att upptäcka att hela er process måste förändras för att anpassas till mjukvaran.

Inget av tillvägagångssätten är i sig rätt eller fel. Beslutet beror på era produkter, er konkurrensfördel, er interna kapacitet och den komplexitet ni faktiskt behöver stödja.

Vilket leder oss till en mer användbar fråga:

Vad bör ni äga, och vad bör ni sluta bygga om?

Det tredje alternativet: köp grunden, bygg fördelen

Valet står inte alltid mellan att köpa ett färdigt system och att utveckla allt från grunden.

Det finns en medelväg.

Använd en etablerad plattform för de funktioner den hanterar väl. Bygg den produktspecifika logiken, den visuella upplevelsen, integrationerna och arbetsflödena som gör er verksamhet unik.

Tänk på det som att bygga ett hus.

Ni vill förmodligen inte tillverka ert eget tegel, utveckla en ny elstandard och uppfinna ett VVS-system innan ni kan flytta in. Men ni kanske vill ha en ovanlig planlösning.

Mjukvara fungerar på ungefär samma sätt.

En lämplig plattform kan utgöra grunden. Er egen applikationslogik kan hantera de delar som kräver djup kunskap om era produkter och processer.

För en tillverkare kan det innebära en visuell konfigurator som låter återförsäljare designa en lagerlayout. För en annan kan det vara en applikation som konfigurerar maskiner, validerar komponentkombinationer och producerar korrekt teknisk dokumentation.

Den underliggande tekniken behöver inte vara unik.

Sättet ni omvandlar er produktkunskap till en konkurrensfördel kan däremot vara det.

Självklart är medelvägen inte automatiskt det billigaste eller enklaste alternativet. Det beror på plattformens anpassningsmöjligheter, licensmodell, integrationskapacitet och hur mycket anpassad utveckling som krävs.

Målet är inte att undvika att bygga mjukvara. Det är att vara medveten om vad ni bygger.

CPQ vs engineering automation: de löser olika problem

Låt oss säga att ni tillverkar konfigurerbara industriprodukter.

En kund vill ha en lösning. Ert säljteam behöver förstå kraven, välja rätt komponenter, beräkna ett pris och skicka en offert.

Det är här CPQ kommer in i bilden.

CPQ står för Configure, Price, Quote. Det hjälper företag att hantera produktval, konfigurationsregler, prissättning och offertflöden.

En bra CPQ-process kan förhindra inkompatibla val, tillämpa affärsregler konsekvent och minska manuellt arbete mellan en kundförfrågan och en offert.

Men det finns en viktig skillnad.

Att veta vad ni får sälja är inte alltid samma sak som att veta hur man konstruerar det.

Tänk er en tillverkare av pallställ.

En säljare behöver konfigurera en lagerlayout. Systemet måste ta hänsyn till dimensioner, tillgängliga komponenter, produktkompatibilitet och prissättning.

Det är redan mer komplicerat än att välja en produkt från en rullgardinsmeny.

Introducera nu de tekniska kraven.

Vilken balkprofil är lämplig för lasten? Uppfyller konfigurationen relevanta strukturella krav? Är de valda komponenterna lämpliga för den avsedda applikationen? Vilka beräkningar eller kontroller krävs innan designen kan godkännas?

Dessa frågor involverar teknisk kunskap, inte bara affärsregler.

Vissa CPQ-system kan hantera sofistikerade tekniska begränsningar och beräkningar. Andra fokuserar främst på produktval, prissättning och offerter. På samma sätt kan engineering automation existera som en separat applikation eller vara integrerad direkt i konfigurationsflödet.

Etiketterna i sig säger inte vad ett system kan göra.

Det som spelar roll är om mjukvaran kan representera och tillämpa de faktiska regler som styr era produkter.

Ett praktiskt sätt att skilja dem åt

Dessa förmågor överlappar varandra. De behöver inte finnas i separata produkter, och det finns ingen universell arkitektur som alla tillverkare bör följa.

Poängen är att de löser olika delar av problemet.

Om ni utvärderar mjukvara enbart baserat på dess förmåga att generera en offert, kan ni missa det tekniska arbete som sker innan offerten kan skickas på ett säkert sätt.

Och om ni fokuserar uteslutande på tekniska beräkningar, kan ni förbise säljupplevelsen som avgör hur enkelt kunder och återförsäljare kan använda resultatet.

Möjligheten ligger i att koppla samman de två.

Den verkliga flaskhalsen är ofta överlämningen

Föreställ er er nuvarande säljprocess.

En kund skickar en förfrågan. Säljavdelningen tolkar kraven. Någon bygger en preliminär konfiguration. Konstruktionsavdelningen kontrollerar den. Säljavdelningen justerar förslaget. Konstruktionsavdelningen kontrollerar den igen. En komponent ändras, priset ändras, och någon uppdaterar offerten.

Ingen av dessa enskilda uppgifter är nödvändigtvis orimlig.

Problemet är den upprepade överlämningen av information och beslut mellan människor och system.

Konstruktörer lägger tid på att kontrollera rutinmässiga konfigurationer. Säljare väntar på svar på frågor som redan har besvarats många gånger. Produktkunskapen lever i kalkylark, dokument och i huvudet på folk.

Ni kan köpa ett nytt CPQ-system och fortfarande ha detta problem.

Ni kan bygga en vacker 3D-konfigurator och fortfarande ha detta problem.

Ni kan introducera AI och fortfarande ha detta problem.

Om de underliggande produktreglerna saknas, datan är opålitlig eller arbetsflödet är dåligt utformat, löser det inte problemet att lägga till ytterligare ett gränssnitt.

Målet bör vara att flytta repetitiva beslut till en kontrollerad, underhållbar process.

Där en konfiguration kan valideras automatiskt, låt mjukvaran göra det. Där en beräkning kan standardiseras och verifieras, gör den återanvändbar. Där ett beslut verkligen kräver en ingenjörs bedömning, håll ingenjören involverad.

Målet är inte att ta bort ingenjörer från processen.

Det handlar om att sluta använda dyr ingenjörsexpertis för arbete som verksamheten redan vet hur man gör.

Så vad bör ni faktiskt bygga?

Innan ni väljer en plattform, startar ett utvecklingsprojekt eller skickar ut en RFI/RFP, ställ fem frågor.

1. Var saktar processen faktiskt ner?

Kartlägg resan från kundförfrågan till offert och leverans. Hitta köerna, de upprepade kontrollerna, den dubbla datainmatningen och de manuella besluten. Börja med flaskhalsen, inte tekniken.

2. Vilka beslut är repetitiva?

Särskilj enkla affärsregler från tekniska beräkningar och beslut som kräver expertbedömning. Identifiera vad som kan automatiseras på ett tillförlitligt sätt och vem som är ansvarig för att validera det.

3. Vad är genuint unikt med er verksamhet?

Er produktkunskap, era konstruktionsmetoder och er kundupplevelse kan vara det som skiljer er från mängden. Autentisering, infrastruktur och standardiserat datautbyte är det troligen inte. Anta inte att varje komponent måste utvecklas internt.

4. Vad händer när verksamheten förändras?

Fråga hur enkelt lösningen kan anpassas till nya produkter, nya regler, ytterligare integrationer och nya marknader. Tänk på löpande ägande, licensiering, underhållsbarhet och beroendet av enskilda utvecklare eller leverantörer.

5. Kan ni börja i liten skala utan att måla in er i ett hörn?

Ni behöver inte nödvändigtvis automatisera varje produktfamilj och varje process från dag ett. En fokuserad första fas kan bevisa konceptet med en riktig produktkategori och riktiga användare, samtidigt som ni etablerar en grund som kan byggas ut senare.

Arkitekturen bör stödja nästa steg utan att kräva att ni löser alla framtida problem i förväg.

Den bästa arkitekturen är den som löser affärsproblemet

Det finns ingen universell vinnare i debatten om att bygga eller köpa.

Ibland är en standardlösning för CPQ precis vad ni behöver. Ibland är en skräddarsydd applikation motiverad. Ibland är det rätta svaret en visuell konfigurator kopplad till tekniska beräkningar, ett ERP-system och en återförsäljarportal.

Och ibland är det första ni behöver åtgärda själva processen.

Tekniken ska följa problemet.

På NorrLab arbetar vi med tillverkare vars produkter kräver mer än ett enkelt val av alternativ. Vi bygger visuella produktkonfiguratorer och sammankopplad mjukvara som förenar produktkunskap, konfigurationsregler, engineering automation och affärssystem.

Målet är inte att sälja er det största möjliga mjukvaruprojektet. Det är att identifiera var bättre digitala verktyg kan ta bort friktion från att sälja, konfigurera och leverera era produkter.

För den mest imponerande konfiguratorn är inte nödvändigtvis den med flest funktioner.

Det är den som hjälper er verksamhet att fatta rätt beslut, snabbare – utan att be Bob kontrollera allt.

Produktkonfiguration. Och mer därtill.

Vill ni ta reda på var konfiguration och automation kan göra skillnad i er verksamhet? Låt oss börja med processen, inte mjukvaran.