Fem vanliga risker i en­het­sut­vecklings­pro­jekt

Utveckling av en modern enhet med inbyggd elektronik och ett bra användargränssnitt är en komplicerad uppgift. För att göra detta framgångsrikt krävs en mängd olika färdigheter, bra teamwork, erfarenhet och tur. Det finns många utmaningar som måste hanteras längs vägen. I värsta fall blir projektet rejält försenat, utvecklingskostnaderna skjuter i höjden eller så pausas projektet på obestämd tid. Ledningen måste vara medveten om alla möjliga risker.

"De vanligaste riskerna är relaterade till bristfälligt definierade produktkrav. Om produktkraven är oklara vet ingen riktigt vad som behöver göras", säger Kari Viitala, Sales Account Manager för Etteplans Embedded Business Unit.

Affärsrepresentanter kan till exempel diskutera en utmärkt enhetsidé med interna utvecklare, men utan att lyckas kommunicera idén på rätt sätt. Utvecklingsteamet missar därför viktig information. "För att sådana risker ska undvikas är det viktigt att vara proaktiv redan i definitionsfasen. Man måste göra det lättare för alla att uttrycka sina tankar och kontinuerligt fråga vad syftet med enheten är, vem som ska använda den, var den ska användas och så vidare", berättar Viitala.

Moderna enheter är fullproppade med programvara, vilket har lett till grundläggande förändringar i traditionella modeller för maskinvaruutveckling. Programvaruutvecklare använder sig av lean-agila metoder och ”materialet” de arbetar med är ytterst formbart. Maskinvarutekniken är beroende av de fysiska begränsningarna hos processorer, chips, sensorer, och mått – inget är flexibelt.

"Hårdvaru- och mjukvaruutvecklare lever i mycket olika utvecklingskulturer. Deras sätt att tänka och kommunicera är så pass olika att det till och med kan leda till en kulturell konflikt", säger Juha Nieminen som ansvarar för Services Development, Service Product & Portfolio Management hos Etteplan. Det finns dock ingen anledning till att försöka vrida tillbaka klockan. Det enda man behöver göra är att anpassa de lean-agila metoderna så att de passar maskinvarans värld. "Viktigast av allt är att det måste finnas en väldefinierad struktur för enheten. På så sätt får alla en gemensam grund att stegvis utvecklas från", kommenterar Nieminen.

Teknikens mognadsnivå är en typisk riskfaktor. Ju nyare teknik, desto större är de tekniska riskerna som man kan förvänta sig. "Företag lockas ofta att använda den senaste tekniken i nya produkter. Komponenten kan vara helt felfri tekniskt sett, men fortfarande inte tillgänglig när produktionen ska sättas igång. Dessutom kan mognadsnivån hos utvecklingsmiljön också vara låg. Den här typen av risker måste identifieras och dokumenteras i förväg", säger Kari Viitala.

När utvecklingen påbörjas är tillverkningsprocessen något som måste beaktas. "Man måste se till att säkerställa tillverkningsbarhet i ett tidigt skede i utvecklingsprocessen. Om visionen är ett tillverka ett stort antal enheter kan man minska produktionskostnader genom att optimera till-verkningsbarheten", säger Viitala. Han rekommenderar även att man väljer tillverkningspartner redan innan den första prototypen är klar. "En tillverkningspartner kan validera att enheten är tillverkningsbar redan från början. Partnern kan även kontrollera att lämplig testutrustning finns tillgänglig och hjälpa till med planering av testprocessen. Ett värdefullt plus i kanten är att partnern kan förbeställa komponenter", påpekar Viitala.

Vilka är kostnaderna för enhetsutveckling? Eftersom moderna enheter är så pass beroende av programvara är budgetering mer komplicerat än tidigare. Programvaruutveckling kräver mänskliga resurser och det kan vara svårt att sätta en exakt prislapp på detta. I grund och botten handlar allt om krav. Ibland kräver en enda förändring av kraven att programvaruteamets storlek fördubblas. Man kan endast uppskatta kostnaderna efter att kraven har fastställts.

"I slutändan måste företag förstå att en modern enhet aldrig blir riktigt klar. Den måste dock snabbt komma ut på marknaden för att marknadspotentialen inte ska gå förlorad. En produkt med minsta möjliga funktion är tillräckligt för att validera om enheten har en verklig marknadspotential och för att förbättra marknadsinsikten. Det leder till en kontinuerlig utveckling av produkten", säger Juha Nieminen.