2012-05-15: Håkan Edvinsson och Peter Tallungs
LEAN ARCHITECTURE Kvalitet inom it har länge dominerats av systemens tillgänglighet och källkodens felfrihet. Det borde handla mer om att möjliggöra för verksamheten att alltid göra rätt saker. Här är ett upprop: applicera Lean på arkitekturarbete och få bättre verksamhetseffekt.
När du ska resa till ett varmt semesterland med flyg så kan du processen. Du vet att du måste avsätta tillräckligt med resurser för att ta dig till flygplatsens avgångshall, tid för incheckning och säkerhetskontroll, samt till sist ta dig fram till rätt gate innan den stängs. Alla steg måste utföras, ges rätt tid och ordningsföljd, och dessutom måste du kolla att du har helt rätt information med dig. Minsta avvikelse gör att processen havererar. ”Hann du med flyget? – Ja, nästan”.
I hur många fall räcker ”nästan” som resultat? Exemplet med flygavgången används som metafor för hygienrutiner på en operationsavdelning i ett Skånesjukhus. Rutinerna omfattar många fler inblandade än dem som utför själva operationerna och alla bidrar till målet friska patienter utan komplikationer. Här är förstås ”nästan ren” otillåtet.
Om fem procent av serviceärendena och leveranserna till våra kunder eller medborgare blir fel så blir arbetet att korrigera avsevärt högre än fem procent av kostnaderna. Den tid det tar att korrigera fel kostar resurser i onödan och tiden är dessutom ett nytto- eller intäktsbortfall. Innebär korrigeringen transporter och material blir det dessutom onödig miljöbelastning.
I kommersiella verksamheter tappar man kunder genom att göra fel. Ett transportföretag gjorde 95 procent rätt i sina leveranser. I de fem procent felen förekom ett fall när man skulle köra avfall från ett mejeri, tog fel container och körde flera ton prima ost till tippen. Nästan rätt.
När man har vant sig vid att ”nästan rätt” är tillräckligt så uppstår en räddningsverksamhet som tyvärr blir en accepterad del av vardagen. I förlängningen utvecklar det här så kallade brandmanskulturer: de som är bäst på att lösa akut uppstådda problem blir belönade. Ändå vet vi i tanken att göra helt rätt är alltid billigast och mest lönsamt.
Verksamhetsutvecklare av skilda slag arbetar kontinuerligt med dessa frågor. Processutformning, kvalitetsutveckling, ständiga förbättringar och Lean-tavlor är några av verktygen. Och det finns alltid något att göra.
En verksamhetsarkitekt arbetar med att bistå i, och ständigt förbättra, hela organisationens utveckling. Man har lyckats väl om organisationen snabbt, rätt och smärtfritt kan ställa om sig vartefter nya omvärldskrav inträffar. Väldigt få är där.
Arkitekten har en del av ansvaret för att verksamheten ska kunna göra helt rätt. En verksamhetsutformning och en systemlösning som överensstämmer ”nästan” med den övriga verksamhetsarkitekturen borde inte vara tillräckligt. Det är fullt naturligt att motstridigheter i definitioner och verksamhetsregler uppstår i olika delar av verksamheten.
Men, handen på ditt hjärta, i hur många fall hade det inte behövts den där lilla extra ansträngningen som gjort verksamheten som helhet avsevärt mer felfri?
Det där extra jobbet med processutformningen, den lite mer noggranna kravspecifikationen, kontrollen av systemreglernas samstämmighet, den extra lilla indatakontrollen, uppföljningen sex månader efter implementeringen? Någonting gör att vi blir mindre noggranna än när vi ska hinna med ett flyg.
Kvalitet inom it har länge dominerats av systemens tillgänglighet och källkodens felfrihet. Det borde handla mer om att låta verksamheten göra inget annat än rätt saker.
Hur bra är arkitekten själv på ett felfritt arbete? Vi trendspanare har ännu inte sett en Lean-tavla på ett arkitektkontor. I de fall det finns mätning av arkitektens arbete så rör de oftast arkitektarbetets mognadsgrad, resultat och prestationer. Men sällan mätning av effekten av arkitekternas arbete. Och aldrig något om hur man blir bättre än ”nästan rätt”.
Så här kommer uppropet: hur skulle det se ut ifall vi applicerar några av Lean-tankarna på arkitekturarbete?
Om vi ska ha koll och utveckla arbetssättet, ska vi enligt Lean-experten Niklas Modig inte bara göra en processkarta och ha pejl på verktygen. Vi ska också definiera våra principer. Ok, många är med så här långt. Toppen på det hela är att formulera de värderingar som ligger bakom principerna. Dessa är ofta tysta och lite mer svårfångade än de övriga.'
Niklas Modig har åskådliggjort detta i en triangel. Det intressanta är att det hela hänger ihop. Värderingarna ligger till grund för principerna, principerna för arbetssättet och arbetssättet för verktygen.
Vi kan inte nöja oss med att korrigera i verktygen, vi måste ändra i vårt arbetssätt också. Men förbättringsarbetet måste omfatta även principer och värderingar.
Det här var uppropet. I en senare spaning kommer vi att utveckla samröret mellan EA och Lean samt gå vidare i vad vi behöver ha koll på för att få bättre effekt.
Skriv en kommentar så länge och föreslå vilka arkitekturvärderingar och arkitekturprinciper som är oumbärliga för att vi ska komma längre än ”nästan rätt”. Har du ett förslag på vad en Lean-tavla för EA borde innehålla? Skriv det som kommentar också.
Vi arbetar med utveckling av affär, verksamhet och IT. Det handlar om att coacha IT- och verksamhetsutvecklare att arbeta tillsammans och leverera värde dag för dag. Vi tror att vi lever i en tid av uppvaknande. Det som nu händer i relationen mellan IT och verksamhet är större än allt som hänt tidigare. Detta vill vi skriva om.
Peter Tallungs finns på konsultföretaget IRM som startades med modelldriven verksamhets- och systemutveckling som bärande idé år 1982. IRM driver utbildningarna Certifierad verksamhetsarkitekt sedan 1994 samt Certifierad process- och verksamhetsutvecklare.
Håkan Edvinsson finns på företaget Informed Decisions som är konsulter kring förbättrade beslut inom affär, verksamhet och IT. Han är författare till facklitteratur inom Enterprise Architecture.
Du når oss på peter.tallungs@irm.se och hakan.edvinsson@informeddecisions.se.
Peter Tallungs och Håkan Edvinsson
#1 Thomas Drakengren |
söndagen den 27 maj 2012 kl. 10:19 |
Vi har kört lean ett tag i vårt EA-arbete för att stödja FMV med arkitekturstyrning. Det fungerar mycket bra!
#2 Torbjörn |
söndagen den 27 maj 2012 kl. 21:18 |
Intressant!
#3 Håkan Edvinsson |
söndagen den 27 maj 2012 kl. 21:33 |
Tack, Torbjörn. . Thomas, har du lust att dela med dig här om hur ni applicerar Lean på EA@FMV? Något om era arkitekturvärderingar och arkitekturprinciper, eller kanske något framgångsrikt exempel på mätning?
#4 Lars Andreen |
måndagen den 28 maj 2012 kl. 08:19 |
Är inte triangeln felvänd eg -Värderingarna ligger till grund för principerna?
PS: tack för bra artiklar
#5 Thomas Drakengren |
måndagen den 28 maj 2012 kl. 08:26 |
Absolut! Vi har kört med Scrum för vårt EA-arbete i en grupp på 8-10 personer sedan januari 2010, men insåg att de uppgifter vi utförde var extremt svårplanerade i tid, och det var lätt att ta på sig för många parallella uppgifter. Så vi skippade detta att ha sprintar som vi planerar för (det är ju "waste"!), och kan planera när som helst. På så sätt behöver vi inte (får inte!) ta på oss mer än en uppgift som vi kontinuerligt kan arbeta på (inte för "brett" flöde).
De mått vi har, hittills, är "uppskattade timmar i produktion", "återstående timmar i produktion", "produktionshastighet" (senaste månaden, uttryckt i uppskattade timmar).
#6 Janne Gustafsson |
måndagen den 28 maj 2012 kl. 08:33 |
Hej Peter. Som fd Scania-kille, så kan jag inte annat än att hålla med! Så enkelt! Men ändå så svårt! En människas grundläggande värderingar är satta i 5-7års ålder... Rgds.Janne
#7 Sten Söderberg |
måndagen den 28 maj 2012 kl. 09:57 |
Lean - talar vi om det Lean som Toyoda, Liker mfl arbetat med? I så fall är jag rädd för att hela Enterprise Architecture riskerar att ses som ett enda sloseri. Men om man implementerar Lean tänkandet på EA så kan man ju utgå ifrån Womack och Jones fem principer, kundvärde, värdeskapande, dragande system och som Ni redan uppmärksammat strävan mot perfektion och aktivit arbeta med ständiga förbättringar.
Skall bli mycket intressant att följa den här spanningen..
#8 Håkan Edvinsson |
måndagen den 28 maj 2012 kl. 14:08 |
@Lars Andreen. Jag håller med dig om att man kan vända på triangeln för att få värderingar som bas - prova gärna det i en presentation. Det är nog så enkelt att spetsen är uppåt eftersom det är vanligast och ser stabilt ut. Det reflekterar ju också detaljgraden - få värderingar, lite utförligare och fler principer, osv.
#9 Håkan Edvinsson |
måndagen den 28 maj 2012 kl. 14:23 |
@Thomas Drakengren Ska jag uppfatta det som att ni har produkt- och produktivitetsmått för arkitekternas arbete och resultat, eller att ni har mått för verksamhet t ex FMV:s upphandlingsprocess?
#10 Håkan Edvinsson |
måndagen den 28 maj 2012 kl. 14:58 |
@Sten Söderberg:
Det som är väldigt smakligt med Womack och Jones Lean-ansats är att de utgår från value stream, och inte från resurserna. Det innebär ju att man utgår från den bästa processen för att uppnå värde till kunden och jobbar successivt därifrån. Alternativet är att utgå från befintliga resurser för att öka prestanda och minska fel vilket visat sig inte ge samma effekt. Det är ett bra komplement till Niklas bild.
Poängen i spaningen är att inte se EA som en resurs vars metoder och resultat ska manglas enligt lean, utan snarare ta ett kliv ut i verksamheten för att hitta nyttoeffekterna av EA. Jag tänker t ex på en arbetsplats som har problem inom en del av sin inköpsverksamhet: det blir fel med både inköpsordrar och leverantörsfakturor och man undviker att lägga upp nya leverantörer. Här stämmer inte kombinationen processer, organisation och system. Klassiska EA-problem, alltså. Viss vore det intressant att etablera en koppling mellan dssa utmaningar och hur EA-arbetet bedrivs?
Du har rätt - om vi inte kan påvisa nytta med EA, är den då nyttig (eller är vi bara dåliga på att hitta och förklara nyttan)?
#11 Thomas Drakengren |
måndagen den 28 maj 2012 kl. 17:52 |
@Håkan Edvinsson: Ja, det stämmer. Det har varit oerhört svårt att få en kundkontakt som i någon värld kan betraktas som ett "flöde". Det bästa vi har kunnat göra själva har varit att ordna vår egen produktion på effektivast möjliga sätt, och till slut har detta angreppssätt lönat sig i och med att vi har kunnat vi ett bra gehör för det vi producerat. Till slut ser de nu möjligheterna att använda våra RA-mönster, protokollstackar, standardkatalog och förbandsdefinitioner som värdefullt underlag i upphandling och teknisk styrning.
Ser du någon kommentar som du tycker är kränkande eller olaglig? Då kan du anmäla den här >>
Skriv en kommentar...