Den Digitala Agendan – Reverese Engeneering (Del 11)

Jag läste Miccos underbara post ”Det är inte lösningen som är problemet, det är problemet” i går och den handlar om att man ofta marknadsför utan att egentligen veta varför eller vad man egentligen vill uppnå. Det som slog mig är att det handlar mycket om det, när det gäller all problemlösning.

Problemlösning

I en av kommentarerna på Miccos post skriver Mikael Jorkvist ett exempel som belyser det väldigt tydligt. Hans exempel var att om en glödlampa går sönder i ett mörkt rum, då definierar många problemet att glödlampan är trasig, när det egentliga problemet är att man inte ser något!

Vanedjur

Människor är vanedjur och inte speciellt benägna att byta sätt att arbeta, i så fall skall man kunna förklara vad de tjänar på det. När jag arbetade som mattelärare fick jag ofta frågan av eleverna vad de har för nytta av att kunna matte. Kunde man inte förklara varför, var de inte speciellt intresserade av att lära sig det. Den frågan slutar man sig aldrig att ställa även i arbetslivet!

Det är en delförklaring till varför det är så svårt att införa ett nytt system som förändrar folks sätt att arbeta. Jag har inte under mina 14 år sett ett bra intranät hos något företag eller någon organisation. Om man inte har med hela organisationen med så faller ofta systemet eller fungerar knappt på halvfart. Sedan att interna system ofta kommer i bästa fall på andra plats efter mera ekonomiskt driva lösningar

Självklarheter

I en förstudie när man intervjuar användarna så får man oftast veta vad de vill ha som är bättre och även undantagen. Det som ofta missas är självklarheterna, eftersom användarna inte ens tänker på dem. För illustrera IT fenomenet med en liknelse, tar jag ett bil exempel

En kund har problem med att höger blinkers inte fungerar. Kunden lämnar in den till verkstaden och de fixar att den blinkar till höger.

När kunden sedan skall första gången svänga till höger så fungerar blinkersen, men kunden krockar för att när verkstaden fixa bilen så slutade bromsarna att fungera.

De kunde inte koppla ihop att när man använder blinkersen måste man även kunna stanna för att göra svängen… Detta händer ofta inom IT lösningar att man inte får reda på självklarheterna eller i ett sent skede.

Upphandlingar

När någon offentligsektor skall köpa in en ny lösningen, så skriver de ihop en offert förfrågan, där ingår en kravspecifikation vad de vill köpa.  Tyvärr baserar sig ofta kravspecifikationen på vad de har haft tidigare för system och med några saker som de saknar i den existerande lösningen. Det är mycket sällan som man funderar på vad som egentligen är problemet som skall lösas. Det som händer när det köpt in den nya lösningen är att man i bästa fall får en lite bättre lösning än tidigare.

Däremot om man kan identiefiera vad som är problemet, kommer man kunna se att man måste ändra i sina interna processer för att verkligen göra några större vinster i att byta ut det existerande systemet. Det är dock förmodligen bland det svåraste som finns att kunna titta på sina egna processer och inse vad som man gör fel eller kunde göra mycket bättre. Orsaken till det är att man är lite ”hemmablind” och att man inte vet vilka olika tekniska möjligheter som finns tillgängliga. Detta är nog mera förekommande i IT relaterade tjänster än rent praktiska, som t.ex när det är upphandlingen av ploggningstjänster, så säger det sig själv att om ett företag i Kiruna erbjuder sina tjänster till Åland, så fast de har det billigaste anbudet så kan man ganska enkelt inse att det har avståndet som talar emot dem. När det handlar om IT tjänster blir det betydligt mera abstrakt.

Det som krånglar till det i offentliga upphandlingar är de ”måste” välja de billigaste alternativet och att de inte kan gå över budget taket, fast en dyrare lösningen skulle bli en investering och tjäna in kostnaden efter max ett fåtal år.

Reverese Engeneering

För att kunna hitta vad som är problemet, så måste man först identifiera vad som är problemet. För att lyckas med det måste man bryta ner alla processer och se hur man arbetar idag med ”fräscha” ögon. Jag brukar inte heller se hur andra motsvarande lösningar fungerar, förrän jag själv har funderat hur flödet borde fungera. När man vet vad som är huvudproblemet, då kan man börja fundera hur och vad som skall göras. Då kommer också svaren till de andra problemen som har dykt upp under resans gång.

Reverse Engeneering används främst för att plocka i sär en mekanisk pryl för att förstå den, men är ett ypperligt sätt att skaffa sig förståelse av hur processer och kommunikationen fungerar. Man kallar det även för Backward Engeneering. Om man skall lösa ett ”knep och Knåp” är det alltid bra att titta på slutresultatet och fundera på vilket är det nästsista draget, för det finns bara ett sådant. Sedan går man bakvägen tills man har kommit till startpunkten. Börjar man däremot i start punkten finns det oändligt många varianter att gå fel och det är också baktanken med Knep och Knåp.

Posted in: Digitala Agendan, Erfarenheter, Funderingar