1870 fick arkitekten Gustav Dahl uppdraget att rita en ny byggnad till den kungliga boksamlingen på slottet. Biblioteket, som invigdes 1878, utformades efter internationella förebilder. Det blev en av landets första byggnader med stomme i gjutjärnskonstruktion. Bibliotekets exteriör hade ett drag av nyrenässans.
När jag kliver in i den gamla historiska byggnaden så kan jag inte låta bli att förundras av det gamla och traditionella. Men nu var jag där för att utforska framtiden. Jag visste inte exakt vilket problem vi skulle lösa. Vi skulle utveckla en typ av tjänst som kunde leverera data till kunder på ett nytt och modernt sätt. Och vi hade bara några veckor på oss. Hur ska vi egentligen hinna göra något på sådan kort tid tänker jag?
Jag märker snabbt att vi i teamet hamnar i diskussion kring lösning. Det blir mycket prat om teknik. Vi vet egentligen inte vilket problem vi ska lösa. Så vanligt, eller hur? Jag ber om att vi gör detta på ett annat sätt. Jag pratar med några användare, ber dem förklara vad de behöver och hur de jobbar med den data de behöver. Jag återkommer till teamet. Ber om att vi sätter upp en webbplats, en så kallad ”hello world”. Vi lägger till en knapp där det står ”Ladda ner data”. Vi testar med kunden, de blir väldigt glada. Vi lägger till en logotyp och en kort text hur man arbetar med materialet. Vi är klar. Vi kan stänga projektet någon vecka innan tiden är slut. Allt prat om att vi skulle ha massor av lösningar, filtrera data, olika målgrupper, massor av hjälptexter. Inget behövdes.
Vad vill jag säga med denna berättelse? Vi fastnar ofta i analysfasen. Vi vågar inte definiera vilket problem vi ska lösa. Vi är inte överens om varken problem eller lösning. Vi lyckas inte flytta komplexa, och komplicera problem till att bli enkla.
Skapa ett gratis konto för att fortsätta läsa
Idag lägger du förmodligen 99% på att jobba med lösningar, eller hur?
If I had only one hour to solve a problem, I would spend up to two-thirds of that hour in attempting to define what the problem is — Head of the Industrial Engineering Department of Yale University
Varför är det så svårt för oss att jobba mer med problemet än lösningen? Är det för att det upplevs som abstrakt? Är det för att vi inte vet hur vi ska angripa uppgiften? Är de kanske för att det är tråkigt? Om du ser till citat ovan så handlar arbete med problem om definiera, den andra fasen in design thinking. Där den första är att utforska problemet. Så hur ofta tar du dig tid att faktiskt sätta dig ner och definiera dina problem?
Jag har som de flesta ett stort fokus på att lösa problem. Ofta arbetar jag i uppdrag för att just lösa ett problem. Ibland vet jag inte vad problemet är men tror mig ha en lösning. Ibland så har jag koll på problemet men inte lösningen. Ibland så vet jag varken eller.
Varför är det så viktigt att ha koll på det här med problem och lösning? Jag ser denna kunskap och medvetenhet som något grundläggande som har påverkat mig mycket i mitt arbete. Och jag ser att många företag, ledare och team har nytta av kunskapen. Och genom att ha denna kunskap skulle det leda till helt andra förhållningssätt, beteenden, frågeställningar, arbetssätt och styrning.
Vi börjar enkelt. Här är en bild som jag brukar visa när jag jobbar med mina team.
Ibland så omformulerar jag ordet problem, till utmaning eller möjlighet. Det kan upplevas som mer framåtlutat och positivt. Ibland pratar jag om problemdomän och lösningsdomän, det är något jag kan skriva mer om vid ett senare tillfälle. I denna text kommer jag främst att fokusera på själva problemet och reflektera över vilken typ det är.
Visste du att det finns olika typer av problem? Jag är själv ganska ny kring dessa tankar och det finns massor av arbete och personer som skrivit om detta. Som sagt, jag gillar att lösa problem, men har främst lagt min största energi på själva lösningen och inte på problemet.
Dave Snowden klassificerar olika typer av problem på följande sätt
Jag gillar denna modell då det hjälper mig att veta hur jag ska agera när jag ska lösa ett problem. Beroende på hur du klassificerar problemet bör ”vi gör något” se olika ut.
- Enkla och komplicerade problem bör vi först börja med att observera
- Komplexa och kaotiska problem bör vi först börja med att göra.
Om jag börjar med beskriva lite exempel på de problemen.
Enkla problem
Det finns en tydlig korrelation mellan orsak och verkan. Jag kan använda samma lösning på samma problem om och om igen.
Som exempel, om jag kommer in i köket och det är smutsigt, vad gör jag då? Jag observerar och ställer mig frågan varför är det smutsigt. Och sedan kategoriserar jag problemet. Om det är smutsigt för att barnen lagat mat, tar jag beslut om att jag hjälper att städa upp, då jag är på ett gott humör.
När det är enkla problem så använder vi oss av ”best practise”, en lösning som andra använt sig av för det givna problemet och det är effektivt och ger hög kvalitet. Du letar främst efter den bästa lösningen.
Vi säger att de flesta kan lösa ett enkelt problem. Du behöver ingen speciell kunskap och förmåga för att lösa problemet, ofta genom att du gör som någon annan gjort eller du läser en manual.
Det är dock viktigt att komma ihåg att enkla problem inte behöver vara enkla. I början är alltid ett problem svårt till man har lärt sig.
Komplicerade problem
Det finns en korrelation mellan orsak och verkan men ofta är det flera variabler inblandade, vilket gör det svårare att förstå problemet till en början. Du behöver ofta undersöka mer för att se hur saker hänger ihop.
Som exempel, om du ska bygga ett hus så tar du oftast in hantverkare för att bygga huset. Ofta består arbetet av flera olika moment som kräver specialistkompetens. Du har observerat vad som är problemet, analyserat och beslutat att ta in hantverkare för bygget.
När det är komplicerade problem så är det bästa att använda ”good practise” som är ett mer flexibelt sätt att se på lösningen. Och eftersom det är mer flexibelt så behöver du specialister för att lösa problemet. Med komplicerade problem ändras inte de olika variablerna. De är alltid samma. Det gör att du lättare kan dela upp arbetet i mindre delar och olika personer kan göra sin del. Och sedan kan du sätta ihop alla delar och allt fungerar i sin helhet.
Du letar främst en god lösning, men det kan finnas flera lösningar.
Komplexa problem
När det kommer till komplexa problem så finns det ingen korrelation mellan orsak och verkan. Komplexa problem är oförutsägbara. En lösning som fungerade först, fungerar sedan inte alls.
Som exempel, när vi jobbar med organisationer och vi introducerar ett nytt sätt att arbete. Till en början så fungerar det bra men efter 6 månader så slutar flera medarbetare då deras kompetens inte längre behövs. Vi förstår inte varför detta händer, och är det på grund att något vi gjort? Vi vet inte.
Ofta är det komplexa problem när människor är inblandade. Det kallas ibland för soft systems. Ofta finns det en förskjutning i tid när du inför en lösning på ett problem, ibland ser vi inte vilken påverkan en lösning och förändring har på ett komplext system på lång sikt. Ett annat exempel på det är Aza Raskin, uppfinnare av infinite scrolling som nu inser vad han gjort.
Bästa sättet att lösa komplexa problem är att göra saker för att lära sig. Ofta genom mindre experiment och tester som gör att du tar dig framåt. Här passar processer och förhållningssätt som agilt och design thinking bra. Genom att testa saker så kan du sedan observera vad som händer och ta ett beslut.
Genom att du arbetar med flera olika lösningar kommer med tiden ett mönster att framträda. Det går att prata om en mättnad, t.ex. om du jobbar med att analysera data och göra research så framträder mönster kring problemet och lösningen. Ofta är det bra i denna typ av problem att vara flera olika personer med olika perspektiv och bakgrund för att belysa problemet.
En utmaning med komplexa problem är att det är svårt att analysera sig fram till både att förstå problemet och lösningen eftersom det är rörliga mål och variabler.
Jag har själv fastnat i denna fälla när försöker definiera vad som är systemet. Så fort jag är klar med en dokumentation så har något ändrat sig. Det är rörlig materia vilket kan vara grymt irriterande. Det bästa sättet är alltså att agera innan du har alla svar, detta är något som många ledningsgrupper, chefer och ledare ofta har svårt med.
Ett vanligt kommentar i förändringsarbeten är att vi måste analysera vad som är problemet, ta fram en lösning, förankra denna i organisation innan vi börjar agera på den. Detta är ett stort misstag vilket gör att du aldrig kommer framåt. Kan du känna igen dig i detta?
I ditt arbete får du leta efter mönster och lösningar när de framkommer. Du kan ofta inte tänka dig fram till en lösningen men efteråt så kan du se hur saker hänger ihop. Ofta kan har jag en bild kring vart vi är på väg men efter ett tag märker jag att vi hamnat någon annanstans. Vilket är ok.
Kaotiska problem
I kaotiska problem finns det ingen relation mellan orsak och verkan. Kaotiska problem är oförutsägbara. En lösning som fungerade förut, fungerar inte längre. Här är det ofta något som händer akut och du måste agera direkt.
Som exempel, det kan vara akuta problem som behöver lösas direkt och där du behöver agera snabbt. I denna typ av problem går det inte att testa sig fram och ta beslut i större grupper utan det kräver ofta en mer toppstyrd och direkt styrning. Som exempel kan vara inom brandkår, militär eller sjukvård med tydliga hierarkiska linjer där du agerar för att kunna observera och sedan kunna ta beslut.
Ofta när det är akuta problem vill du så snabbt som möjligt flytta problemet till någon av de andra kategorierna av problem, komplext, komplicerat eller enkelt.
Kategorisera dina problem
Hur gör du för att enklast kategorisera dina problem? En utmaning med att kategorisera problem är att du främst har haft erfarenhet av en typ av problem. Detta gör att du använder samma typ av problemlösning på alla dina problem innan du har kategoriserat dem. Här kommer några frågeställningar som du kan använda tillsammans med dina kollegor innan ni sätter igång att arbeta.
Här är flera frågor som du kan använda dig av för att börja kategorisera dina problem för att sedan fundera över hur du sedan ska angripa problemet.
- Tror du att du vet vad problemet är?
- Kan du kategorisera information och data på ett enkelt sätt?
- Vet du hur du ska få fram mer information och data kring problemet?
- Har du erfarenhet kring du hur kan lösa problemet?
- Kan problemet lösas på flera sätt?
- Behöver du analysera större mängd data?
- Behövs det en specialist för att lösa hela eller delar av problemet?
- Går det att bryta ner och flytta till någon annan domän?
- Är det svårt att veta vad det är för problem?
- Behöver du göra något istället för att analysera?
- Går det att göra mindre tester för att lära sig mer?
- Kan du se mönster i all information och data?
- Upplever du att vi bara måste göra något snabbt och agera direkt?
- Vad är det minsta vi kan göra så vi får någon typ av stabilitet?
- Har du ett tydligt ramverk eller principer för prioritering av problem?
Jag får ofta frågor kring om vi alltid måste kategorisera, utforska och definiera problemet som vi ska lösa? Absolut inte, vi ska bara utforska och definiera de problem som det är störst risk kring och där vi har minst starka bevis. Om du, eller teamet känner att du har bra koll på problemet och hur det kan lösas utan att det finns någon större risk, då är det bara att köra. I nedan bild har jag försökt beskriva hur jag tänker kring hur jag angriper problem beroende på vad det är, självklart är detta en mental modell som också är en förenklad bild av verkligheten.
Det här var väl tråkigt va? Har du själv några bra tips på hur du tänker kring komplexa problem? Har du stött på något som du trodde var ett enkelt problem men när du sedan lyfter på stenen så är där ett ormbo? Förresten, vad är Rubriks kub för typ av problem? Som skrivit förut, hör gärna av dig, jag blir alltid superglad när du hör av dig.
/Jens