En tredimensionell organisation
Traditionellt har en linjeorganisation organiserats efter dess kompetensområde. Har någon egentligen funderat på om detta är det rätta sättet att organisera ett företag eller beror det på historiska orsaker?
När industrin växte fram i slutet av 1800-talet och en bit in på 1900-talet så fanns det förstås ett behov av att lösa ett antal svårigheter som dök upp när företaget växte. Det kunde inte längre vara en person som hade asnvaret för varje arbetare. På något sätt behövde ägaren delegera ansvaret.
I huvudsak fanns det en person, fortfarande, som hade det totala ansvaret och kunde styra företaget efter sina egna intresse. Det blev en tydlig målbild och inte olika intressekonflikter. Chefen styrde med hård hand och de som var mellanchefer på samma sätt. Det var enkelt att organisera sig efter t ex delar av fabriken och var chef fick ansvar för olika dear av fabriken och att det skulle fungera.
Det var nog naturligt att de som gjorde ungefär samma sak jobbade på samma ställe eftersom de då kunde hjälpas åt att förbättra sitt sätt att tillverka sin del av produkten och lärlingar kunde se hur mästarna jobbade.
Successivt har företagen förändrat inriktning och inom mjukvaruutvecklingen har vi ändå behållit 1800-talets sätt att organisera företaget trots helt andra behov av kommunikation mellan olika delar av företaget.
Genom införandet av målstyrning på olika sätt har man valt att styra annorlunda än på under industrialiseringens barndom. Det är t ex balanced score cards osv. Svårigheterna med målstyrning är att hitta ett mål som stämmer överens med den överordnade organisationens mål. Vilket mål skall en avdeling ha för att dra åt samma håll som resten av företaget?
Företagets mål är, oftast, att göra en vinst och att vara långsiktigt konkurrenskraftiga. Detta är en balansgång i utvecklingsorganisationer. Det är ofta lätt att blåsa upp vinsten under några år genom att minska investeringarna i ny mjukvara som ger avkastning på några års sikt. Målen måste på något sätt balansera dessa två på ett bra sätt.
I en utvecklingsorganisation väljer man ofta att jobba i projekt. Linjen får då det långsiktiga ansvaret att se till att produkten har ett liv efter ett projekt medan projektet förstås har som mål att leverera så snabbt som möjligt med minsta möjliga insats. Linjen vill att koden skall göras underhållsbar, förändringsbar osv så att nästa projekt kan göra ett bra jobb utan att man har en teknisk skuld med saker som måste åtgärdas. Konflikten mellan dessa två organisationer är uppenbar redan med detta upplägget.
Tyvärr har man en tendens, i både projekt och linjeorganisation, att strukturera sig efter funktionalitet. SCRUM försöker t ex få krossfunktionella team som kan ta ett helhetsasnvar. Detta är ett steg i rätt riktning för att kunna genomföra målstyrning som har tydliga mål kopplade direkt till företagets mål. På Ericsson i Lund införde vi för några år sedan SCRUM team som var grupperade för att leverera olika Use Case. Varje Use case fick då en tydligare kostnad och intäkt avseende vad produktledningen var beredda att investera i respektive område beroende på vad kunderna efterfrågade och köpte.
Samtidgt var linjen fortfarande organiserade efter kompetensområde. Testarna satt i en testorganisation och utvecklarna i en utvecklingsorganisation. Målen som sattes upp var för t ex testarna att hitta X antal fel. Dessa fel skulle rapporteras i ett ärendehanteringssystem. Om det inte fanns i ärendehanteringssystemet så kom de inte med i statistiken. När då testrna började testa redan under utvecklingsfasen som SCRUM rekommenderar började de också att rapportera fel i ärendehanteringssystemet vilket medförde en ökad administration och en signal om att kvaliteten försämrades. Detta klart emot vad som egentligen var fallet. Vi hade jobbat mycket med att försöka hitta felen tidigare i processen för att detta är billigare enligt de flesta modeller. Nu hittade vi felen tidigare och kvaliteten ut från SCRUM teamen var högre men det verkade tvärtom och vi fick en ökad administration. Målet var helt klart felaktigt och inte i linje med företagets övergripande mål.
Likaså drevs testorganisationen av att följa olika processer för att genomföra heltäckande testning osv. Jag hade gärna sett att linjen fick mål som stämde överens med företagets mål. Ett förslag är då att organisera linjen på ett annat sätt. I alla fall den delen av linjen som är ansvarig för det långsiktiga produkten. De borde, enligt min mening vara organiserade efter Use Cases eftersom det är detta som är viktigt för kunden. Detta ger en morot till att leverera bra Use Case och ger mål som kan brytas ner som ligger i linje med företagets mål.
Sedan finns det en annan del av linjen som måste fokusera på kompetensområden. Den delen måste fokusera på utbildning av personalen.
Genom denna uppdelning i en tredimensionell matris får man fokus på de tre problem som finns i en organisation. Dels de kortsiktiga behoven av att leverera kontinuerligt och dra in pengar för likviditeten i företaget, dels att säkerställa företagets långsiktiga överlevnad och dels att säkerställa kompetensen inom företaget. Jag menar att man på detta sättet minskar konflikterna internt i organisationen och att man får en större möjlighet att få till ett samarbete och tydliga kompromisser.