Produkten

Vi tänker ofta på produkter som något vi köper. Något som någon annan har gjort. En sak som ska möta våra behov.

Men vad händer om vi själva är de som har hand om produkten? Om det är vi som behöver se till att den alltid fungerar som den ska? Som ser till att den möter de behov den är gjord för att möta?

Vissa av oss arbetar i produktbolag. Där är hela organisationen uppbyggd runt produkten. Hur produkten ska utvecklas, hur den säljs och levereras.

Men många av oss arbetar i helt andra organisationer som är byggda för att leverera något annat än en produkt. Till exempel tjänster. Till exempel myndighetsutövning. Det är inte några produktorganisationer.

Men även vi som arbetar i sådana organisationer behöver börja tänka som om vi hanterade produkter i en produktorganisation. Det har med digitaliseringen att göra: I takt med att det vi levererar blir mer och mer beroende av digitala verktyg, desto mer behöver vi ta hand om dessa digitala verktyg som om de vore våra egna produkter.

Det spelar ingen roll om vi köper in verktygen eller om vi bygger dem själva. Vi måste ändå ta hand om hur verktygen fungerar tillsammans med oss och med varandra.

Den helheten är en "produkt" i sig själv och för att ta hand om den krävs det att vi lär oss ett gott produktägarskap i hela vår organisation.

Då finns det några saker vi behöver förstå:

Funktionell indelning

Våra verksamheter är ofta funktionellt uppdelade. Det betyder att varje del av vår verksamhet är uppdelade i olika funktioner: en grupp människor i organisationen som gör en viss sak:

Det har liksom bara blivit så. Verksamheten kom till för att hjälpa en viss grupp människor med någonting. För en kommersiell verksamhet kan det vara en grupp kunder. För en myndighet kan det vara invånare med vissa behov.

När verksamheten växte behövde man hjälpa ytterligare nya grupper av människor med andra saker. Då formades nya kärnfunktioner med andra människor som kunde det här nya.

De olika funktionerna kunde behöva specialiserat stöd för sina personalärenden. Då formades en stödfunktion för personalhantering. På samma sätt formades ekonomiavdelningen när ekonomistyrningen blev mer komplex, IT-avdelningen kom till när datorer blev vanligare och systemen krångligare och så vidare.

Så ser många större verksamheter ut idag: ett konglomerat av olika kärnfunktioner som med stöd av ett antal olika stödfunktioner försöker hjälpa olika grupper av människor med olika saker.

Enstaka verktyg och hela flöden

Hur påverkas våra organisationsstrukturer av digitaliseringen? Varför behöver vi tänka som digitala produktägare nu, även om vi inte arbetar i rena produktbolag?

När datorerna för femtio år sedan kom in i våra verksamheter så började det som enstaka och enskilda verktyg för att hjälpa till att automatisera en del av en process. Det kunde vara en lönekörning, beräkningar av semesterdagar, eller något liknande.

Med tiden blev verktygen fler och fler, tog hand om fler och fler saker, och till slut började verktygen vara så sammankopplade att de började behöva betraktas som större produkter i sig själva.

Förut var många av våra verksamheter i huvudsak analoga med några digitala inslag. Nu är verksamheterna och värdeflödena i dem i huvudsak digitala, med några analoga inslag. De digitala flödena hanterar dessutom mer riskabla saker: pengar, avtal, till och med processer som handlar om liv och död.

Det ändrar hur vi behöver se på vår verksamhet. Vi behöver se på den som ett system, en maskin som ska fungera på ett säkert och tryggt sätt. Verksamheten har blivit produktifierad.

Brett samarbete

Ett verksamhetsstödjande digitalt verktyg är en sammansmältning av flera olika perspektiv. Precis som själva verksamheten är det. Därför behövs det många olika människor, från olika verksamhetsfunktioner, som arbetar med det.

Verktyget och verksamheten finns för att möta vissa viktiga människors viktiga behov. Så det digitala verktyget behöver tas om hand av människor som har djup kunskap om dessa behov. För många verktyg kan det vara användarna själva, eller åtminstone några av dem, som är med och utvecklar och förvaltar sina egna verktyg.

Ett verksamhetsstödjande system behöver dessutom arbeta enligt verksamhetens regler och logik. Varje verksamhetsområde, varje domän, har sina begrepp och processer. Stora delar av verksamheten regleras dessutom av lagtexter och förordningar. Så förutom användarna behövs det andra sorters verksamhetsexperter som kan svara på flera av de frågeställningar som uppkommer när verktygen ska fungera i verksamheten.

Men det är också ett system. Ett digitalt verktyg. Det betyder att det arbetar under vissa tekniska och datalogiska förutsättningar. För att hantera det på ett bra sätt behöver vi ha med oss teknisk och datalogisk kompetens av olika slag.

Dessa tre perspektiv behöver alltså alltid vara närvarande tillsammans:

Perspektiven behöver finnas där under produkternas hela livscykel, ifrån det att någon får en idé om en förändring, när förändringen är i drift, och fram till att den avvecklas eller ersätts. Ibland är det en och samma person som både har tillräcklig kunskap och kan hålla alla perspektiven i huvudet samtidig. Det är dock väldigt ovanligt.

Oftast är det en grupp människor, från olika delar av organisationen, som behöver samarbeta djupt tillsammans för att resultatet ska bli bra.

Ökande projektrisker

När den analoga verksamheten fungerade som den skulle så behövde man inte tänka så mycket på helheten. Det fanns upparbetade kontaktvägar för de olika ärendetyperna, både för dem utifrån som behövde hjälp och mellan enheter och avdelningar inom organisationen som behövde varandras stöd.

Det var egentligen bara förändringar i verksamheten, verksamhetsutvecklingen, som krävde att man tänkte lite större. Något som var ganska dyrt och krångligt och som därför gjordes ganska sällan.

De tidiga digitala verktygen stöttade som sagt varsin del av verksamheten, genom att hantera en del av den. Flera av dem skrevs på plats, av organisationen själv, och utvecklades löpande i takt med förändringsbehoven. Eller så köptes de in för att stötta en mogen process och behövde inte bytas ut speciellt ofta.

Det dyra var ofta själva datamaskinen, hårdvaran. Det var den du köpte in som en anläggningstillgång och sedan skrev av på några år.

Men digitaliseringen tog ny fart. Datorerna blev mindre, hamnade på skrivbordet, och började kopplas samman med varandra och med de stora gamla systemen. Plötsligt började även verksamhetsprocesserna, genom de digitala verktygen, kopplas samman över verksamhetsgränserna, och utveckling av de digitala verktygen blev i princip verksamhetsutveckling.

En dyr, krånglig och riskabel verksamhetsutveckling, som tvingade helt olika delar av verksamheten att möta varandra och sambesluta om saker som varje del hittills hade bestämt själva.

För att försöka minska risken investerade organisationer i projektmodeller som byggde på en hög grad av föranalys och försök till långtgående planering av utvecklingen.

Men verksamhetsutveckling, i synnerhet systemutveckling, är en svårplanerad verksamhet. Det handlar om att pröva olika sätt att tänka och kodifiera verksamhetens regler och begrepp på olika vis, utan att man kan förutse alla konsekvenserna eller hur svårt det kommer att bli.

Ju mer vi försökte planera och få in alla relevanta aspekter i projekten, desto större blev de, och desto mer försenade blev de. Förutom att projekten långt ifrån alltid levererade det som behövde levereras.

En löpande investering

Både tekniken och samhället utvecklades dessutom. Det, tillsammans med att våra sammankopplade system blev större och större, det gjorde att vi behövde börja förändra systemen och verktygen betydligt oftare.

När tekniken och världen förändras behöver vi både hantera det, men också ta till vara de nya möjligheterna. Kanske genomföra en effektivisering, motverka fel, eller utforska nya affärsmöjligheter. Om vi inte kan göra det, bara för att våra digitala verktyg saknar vissa egenskaper, då kan vi se att den uteblivna förändringen blir en kostnad för oss.

Om den viktiga förändringen inte kan äga rum förrän om ett långt tag, så blir den kostnaden, dröjsmålskostnaden, riktigt stor.

I rena digitala produktbolag har man inte riktigt det problemet. Där är förbättringen av den digitala produkten något man försöker arbeta med hela tiden. Det är inget som sker bara då och då.

Produktorganisationer arbetar med att ständigt försöka införa de mest värdefulla förändringarna. Man prioriterar löpande bland mängder med idéer och förslag.

Så om vi vill undvika stora dröjsmålskostnader och istället ha en digital verktygsflora som alltid hjälper oss, så behöver vi lära oss att ständigt fånga nya behov och utveckla våra verktyg så att behoven möts.

Vi behöver sluta utveckla våra verktyg i enskilda projekt, och istället bygga en permanent utvecklingsförmåga. Vi behöver agera som en produktorganisation.

Utforskande utveckling

Men utveckling, antingen det är verksamheter eller verktyg vi utvecklar, är som vi såg förut svårförutsägbart och svårplanerat.

Vi utvecklar verktyg för att vi vill möta viktiga människors viktiga behov. Och vi vill möta dessa människors behov eftersom det i förlängningen leder till något bra för vår egen organisation. Eller som man också kan säga: Vi vill att våra produktmål stöder användarnas användningsmål som så småningom leder till vår organisations resultatmål.

Det är många saker som behöver stämma om det verkligen ska bli så.

Kommer förändringarna i produkten (produktmålen) verkligen att hjälpa användarna på det som är tänkt? Eller ska vi genomföra en annan förändring?

Vet vi exakt vad förändringen innebär? Eller behöver vi fortsätta att utforska detaljerna, även om vi beslutat om huvuddragen? Och vad gör vi om detaljerna visar sig kasta om våra tidiga antaganden?

Möter vi verkligen användarnas användningsmål? Kommer användarna att påverkas på det sätt som vi tänkt? Leder det till att användarnas nya beteende faktiskt får den effekten som gör att vi möter vår organisations egna mål?

Och hur svårt är det? Hur lång tid kommer det att ta?

Enligt de äldre projektmodellerna skulle det finnas svar på de här frågorna redan efter en tidig förstudie, innan projektet började genomföras på allvar. Men vi kan faktiskt inte få svar på frågorna förrän vi börjar utveckla lite och se vad som händer.

Ett annat paradigm växte därför fram. Med en stabil produkt- och verksamhetsutvecklingsfunktion på plats så kunde vi arbeta kontinuerligt med att pröva olika förändringar som verkade vara lovande. Mindre bra förändringar kunde vi stoppa på ett tidigt stadium, innan vi plöjt ner för mycket tid och resurser i dem.

Vi började utveckla löpande. Satte en prototyp eller en tidig version av något i händerna på riktiga användare för att se hur de påverkades. Lärde oss om vad som behövde göras i systemens inre för att stötta det nya beteendet. Såg hur svårt det var och hur lång tid saker skulle komma att ta.

På så sätt blir vi en produktorganisation runt våra digitala förmågor. Hela tiden ser vi till att verktygen blir mer och mer värdefulla.