Där ni står

Under en utbildning idag, hos en avdelning som jag hjälpt införa olika smidiga tekniker för en tid sedan, ställde jag frågan vad som hade förändrats i och med de nya arbetssätten.

- "Entusiasmen, viljan att lösa problem, glädjen i att hjälpa och förbättra", blev svaret.

Det gjorde mig väldigt glad, men faktiskt inte så förvånad. Det är lyckligtvis en rätt vanlig erfarenhet, som bygger på en välkänd mekanism.

Många som stöter på de smidiga teknikerna första gången brukar häpna över den radikala delegeringen. Det till myteriet gränsande (nåja) självstyret. Under förbättringsmötena tar folk ansvar för saker som i en organisationskarta ligger långt utanför den egna avdelningens ansvarsområde. Hur kommer detta sig?

Svaret är att vi människor vill hjälpa till, vill göra ett bra jobb, vill vara med och skapa något stort och bra. Men när man inte ser hur det skulle kunna gå till blir man handfallen, och då också demotiverad.

 

Genom de smidiga teknikerna lär sig alla att fokusera på värdeflödet. Man bryr sig om det som gör mottagaren glad. Det medför att man automatiskt bryr sig mindre om avdelningsgränser och formella mandat. Alla ser ju hur en överlämning mellan två avdelningar fungerar osmidigt. Att försöka påtala denna osmidighet för chefer långt upp i hierarkin känns osmidigt i sig självt. Dessutom: vad vet chefen långt ifrån golvet om det här?

Istället tar man kontakt med varandra och anordnar ett snabbt (<45 minuter) förbättringsmöte för att reda ut hur samverkan ska lösas. Man dokumenterar ett processteg, testkör under två veckor, och bestämmer sig sedan för om man ska permanenta det nya arbetssättet. Arbetssättet skrivs ner på en liten plansch och sätts upp på väggen. Att ändra arbetssätt blir odramatiskt när man hela tiden testkör i det lilla.

En tredje faktor som ökar frimodigheten och därmed motivationen är synliggörandet (rätt info i rätt tid). Vi VET om den förändring vi testar är till det bättre eller ej, för vi får information om utfallet omedelbart. Osäkerhet om det man gör är till det bättre eller ej skapar handlingsförlamning, och är ett tecken på att egentligen ingen i organisationen kan besluta något på goda grunder. Med rätt info i rätt tid kan istället alla fatta vettiga beslut med låg risk.

Så det är inte underligt om smidiga tekniker ökar viljan att ta större ansvar. Plötsligt finns ju förutsättningarna.

Syfte, steg, samspel

Det här är ett försök att beskriva tanken bakom ramsan Purpose, Process, People; alltså i vilken ordning man bör angripa saker och ting som man känner inte riktigt funkar i arbetssättet.

När vi tänker arbetsdelning har vi en tendens att genast tänka på vem som gör vad. Det är inte så konstigt, för i grund och botten är och förblir vi jägare och samlare från savannen. I den lilla gruppen som ska göra något är det överblickbart. Vem som gör vad är rent naturligt arbetsledningens första fråga.

Men när vi ska göra något i lite större skala, då blir vem som gör vad en tokig fråga. För den blir i våra huvuden till stordriftsfrågan vilka gör vad, och då börjar vi genast tänka i termer av avdelningar. Då sätter vi alla flintknackarna i ena hörnet av grottan, alla som skrapar skinn i det andra hörnet, alla som flår djuren i det tredje; osv.

Genast åker vi på bök. Djurkropparna måste plötsligt släpas mellan de olika avdelningarna, och transporter är ju i grund och botten slöseri. Det må vara hänt i en grotta där fyrtio personer samarbetar om något i grunden enkelt och konkret, men hur är det i en storskalig verksamhet? En där det vi gör inte alltid är så påtagligt?

Vår impuls att översätta den småskaliga arbetsdelningen mellan människor ("People") till en storskalig indelning i avdelningar av folk som gör likartade arbetsuppgifter, den skapar slöseri. Värdet består ju i att olika människor gör olika saker för samma produkt, eller tar hand om olika delar i samma tjänsteflöde. Det blir en massa konstiga och osmidiga överlämningar mellan avdelningarna och svårt att samarbeta när avdelningarna blir stora.

Därför ska man börja från början, med att slå fast själva syftet ("Purpose"). Vari består värdet? Vem blir glad? "Vi blir glada när djurkroppen är uppdelad i rena skinn och snygga köttbitar". Aha! Då ska vi inrikta oss på det! Vilka processteg behövs då för att nå dit? Knacka kniv, flå, skrapa, stycka? Ja! Vi har hittat en process för att uppnå värdet!

Först när vi vet vilket syfte vi ska uppnå, och vilka steg som ska ta oss dit, först då är det dags för oss att fundera över hur samspelet bör se ut. Vi börjar alldeles för ofta med att fundera över våra organisationer, när vi egentligen först borde fundera över vilket värde vi ska åstadkomma och vad som då behöver göras.

Alla dessa obegripliga omorganisationer är ett symptom på en oklar värdekedja. När man har anammat tankesättet syfte-steg-samspel ("purpose, process, people") gör man inga omorganisationer förrän värdekedjan är förstådd. Sedan kan det bli justeringar i organisationen i takt med att man förstår mer och mer av vilket värde man kan leverera, men dessa justeringar blir sällan dramatiska, och framförallt blir de inte obegripliga.

Vi har ju ett tydligt syfte.

Exakt samma fast på ny plattform!

Nu ska ni få en liten historia ur verkligheten, men det hjälper inte om ni frågar var någonstans detta har utspelats för dels vill jag skydda mina uppdragsgivare, och dels har jag faktiskt sett precis nedanstående ske på fyra helt olika platser under tolv års tid. Jag gissar att det händer igen och igen och igen...

Det var en gång en verksamhet som behövde ett system. Eftersom organisationen hade beslutat om en viss teknik (en generell applikationsteknik som byggde på en generell relationsdatabas och ett generellt språk för mellanlager och användargränssnitt), så beslöt man sig för att bygga systemet i precis denna teknik.

Organisationen berömde sig av sina noggranna förstudier och sin rigorösa beslutsprocess, och därför tog man god tid på sig för att inhämta kraven från användarna. Alla processer kartlades, och man såg till att ingen detalj glömdes bort. Man gjorde det så noga så att det tog så lång tid, att när informationsarkitekterna tog över för att modellera objektrymd och databas, så hade kravfångarna och verksamhetsmodellerarna ingen budget kvar. De lämnade över kravdokumentet och började jobba på andra projekt. De som var konsulter gick vidare till andra uppdrag i helt andra verksamheter.

Informationsarkitekterna och programmerarna ville jobba agilt och gjorde sitt bästa för att samarbeta runt de överlämnade kravdokumenten, men när de sprang på frågor fanns det inga kravfångare kvar att fråga; och verksamheten tänkte minsann inte lägga en minut till på att förklara sina verksamhetsprocesser och behov en gång till.

Nå, till slut lyckades utvecklarna leverera ett system, inte på budget och inte så att verksamheten blev helt nöjd, men åtminstone så att det kunde anses färdigt enligt de högst luddiga och oklara acceptanskriterierna. Nja, kriterierna var egentligen inte luddiga, språkligt/syntaktiskt sett, men det hade visat sig under resans gång att de innehöll självmotsägelser och det är ju innehållsligt/semantiskt sett samma sak som oklarhet.

Verksamheten och IT-utvecklingen (varför ses aldrig IT som en del av verksamheten när informationsflöden utgör själva verksamhetens blod?) bråkade en stund om vems felet var (rätt svar: ingens, förstås, eftersom det inte existerar någon metod att på förhand ta reda på om krav är självmotsägande med mindre än att du försöker skapa en lösning som uppfyller dem); men verksamheten - som behövde systemet - accepterade och tog det i drift.

Det fungerade. Inte bra, men det fungerade. Åtminstone delvis.

Ganska snart insåg man att det faktiskt var viktigt att systemet både fungerade bra och till alla delar. Systemet skulle ju stödja verksamhetens absolut viktigaste process. Pengar behövde skakas fram för att lyfta systemet ytterligare ett steg.

Men nu tänkte någon till. Var inte grundproblemet egentligen att man valt en generell plattform för att göra systemet? Var det inte så att verksamhetens behov bättre matchades av en mer specifik plattform, ett sk affärssystem, som hade moduler för att stödja den här typen av verksamhet? Naturligtvis skulle det komma att krävas specialanpassningar, men i det stora hela var det en bättre match mellan plattform och verksamhet. På sikt måste ett plattformsbyte vara bättre!

Eftersom denna någon besatt ett rätt så omfattande mandat fattades beslutet utan några förstudier (personer på höga mandat besitter ju magiska egenskaper att se verkligheten sådan den är och behöver inte se några förstudier gjorda av folk med mindre mandat): plattformen skulle bytas ut, innan man gick vidare med att rätta bristerna i det befintliga systemet!

Något ytterligare kravarbete skulle inte behövas, resonerade man, eftersom det befintliga systemet tjänade som facit. Första delprojektet skulle ju bara replikera det befintliga. "Exakt samma, fast på ny plattform!", löd ordern.

Men vem skulle göra arbetet? De befintliga utvecklarna kunde ju funktionskraven bäst, och var därför bäst skickade att göra det! Sedan kunde man kasta in konsulter som kände till plattformen, alltså det nya affärssystemet.

Utvecklarna kliade sig i huvudet. De visste hur databasmodellen såg ut som stöttade de befintliga funktionerna. De visste att affärssystemet i botten var en relationsdatabas. "Exakt samma fast på ny plattform!" löd ordern. Alltså tog man det befintliga schemat och tryckte in i affärssystemets databas, och sedan gav man sig i kast med att anpassa de gränssnittsmoduler som mest liknade den befintliga funktionaliteten.

Det gick trögt. De befintliga utvecklarna kände ju inte till affärssystemets finesser, det gamla systemets databasmodell stöttade inte dessa finesser; så en enorm mängd specialtricks, skript, fulhack osv krävdes. När sedan experterna på affärssystemet skulle komma in och stötta visade det sig att dessa inte alls var så värst mycket till experter. I synnerhet begrep de sig inte på den röra som de befintliga utvecklarna lämnat efter sig. Lämnat efter sig? Ja, det ingick ju inte i någon budget att dessa bägge utvecklargrupper skulle arbeta parallellt.

Nu började någon-med-det-stora-mandatet bli nervös. Version 1 av systemet hade kostat mycket mer än prognosen. Version 2 riskerade att bli ännu dyrare och ta ännu längre tid och vara ännu sämre. Det utlovade leveransdatumet närmade sig och de tilldelade pengapåsarna var tomma. Bäst att agera! Bäst att kommendera fram en leverans!

Och så blev det. Systemet som varken var en skräddarsydd lösning byggd på en generell plattform; eller en smart anpassning av ett standardsystem; och vars funktionalitet (när det över huvudtaget fungerar) var en karikatyr av det som några kravfångare och verksamhetsspecialister drömt fram för länge sedan; det togs i bruk. Och kostade snabbt (i frustration, i fel, i utebliven verksamhetsnytta, i folk som tvingas lägga eoner av tid i handhavandet) betydligt mer än hela den sammantagna utvecklingskostnaden av version 1 och version 2.

Detta är så onödigt, och ändå händer det igen och igen och igen. Några enkla tips på vägen för att inte sätta sig i detta klister:

• Förstudier är galet. Studier är det rätta. Dessa ska bedrivas samtidigt som systemutvecklingen så att man hela tiden vet att man är på rätt spår. Se Scrum för en enkel och handfast metod som löser detta, till en låg kostnad.
• Det finns ingen metod som validerar krav innan de är implementerade. Krav kan vara självmotsägande. Vi kan vissa tricks för att minska risken att vi fångar krav som sen blir tokiga, men säkra kan vi (av matematiska skäl) inte vara. Det går därför inte att minska risken genom att vara rigorös. Det enda sättet att på allvar minska risken i systemutvecklingen är att minska omfattningen. Bryt ner i delmål och delprojekt, så vet ni att ni är på banan.
• Krav kan inte överlämnas i kravdokument. Dokument är viktiga som gemensamma sätt att fästa sin samsyn på papper, men det går inte att skriva ner alla aspekter och vara säker på att dessa tas om hand längre fram. Kravfångare och utvecklare ska campera ihop och jobba tätt. Överlämningar är en känd spillkälla.
• När Gartner Group sammanfattar statistik över lyckade och misslyckade IT-projekt försöker de hitta skälen till att projekt lyckas. Den viktigaste faktorn har varit närvaro av användare. Värdeflödet (tänk lean) är när en användare får ett verktyg som stödjer användarens värdeskapande processer. Man måste ha med dem för att uppnå det!
• Att ha mandat betyder inte att ha förmåga. Och ska du ha reell makt över utfallet behöver du mandat och förmåga på rätt nivå. Folk i höga positioner ska inte göra känslomässiga val av teknik. Inte utan en analys som visar att deras antaganden är rätt. Förbättringar ska vara ett empiriskt experiment. Inte magkänsla hos någon med hög månadslön.
• Om man vill använda färdiggjorda system ska man vara helt på det klara med att dessa verkligen stöttar ens verksamhet (eller så får man göra om sin verksamhet så att den passar systemet), och man måste känna till den verkliga kostnaden av att anpassa. Tänk på att konsulter för ett specifikt system är mycket dyrare och mer sällsynta än konsulter för standardtekniker.
• Att säga: "Exakt samma fast på ny plattform" är inte en kravspec. Plattformar ser väldigt olika ut. Annars hade det inte funnits plats för dem bägge på marknaden: de har olika uppbyggnad och fokus. Säger man "Exakt samma" så menar man ofta "Likadan fasad". Problemet är att de olika plattformarna är radikalt olika hustyper. Att limma på en fasad från en sorts hus utanpå en helt annan sorts hus, brukar inte bli så bra.
• Kostnaden i utvecklingen är inte programmeringen. Kostnaden är att ta fram informationen om exakt hur systemet ska fungera. Fokus ska ligga på att förbättra den informationsframtagningen. Och när vi säger exakt så menar vi exakt. Datorer är exakta.
• Systemkostnaden är till väldigt liten del programmeringen. Livscykelkostnaden är lätt tio gånger högre. Räknar vi med kostnaden av utebliven verksamhetsnytta pga dåliga system blir den mycket högre än så!
• Det går inte att kommendera fram en annan verklighet än den vi lever i. Nej, på riktigt: det går inte.