Lean forvaltning. Indhold

Transkript

1 Lean forvaltning Indhold Lean forvaltning... 1 Indledning... 2 Value Stream Map (VSM)... 2 Lead Time og Cycle Time... 3 Effektiv tid... 4 Værdifuld tid... 5 Trenden i effektiv og værdifuld tid... 6 Kanban... 7 Den lærende organisation... 7 Team Empowerment... 8 Lean begreber... 9 Spild (Muda) Opsummering C:\Users\Poul\Documents\AS\Essays\Essay, LeanForvaltning.docx Side 1

2 Indledning Lean bygger oprindelig på Toyota Production System (TPS), men fik navnet Lean i USA, da MIT studerede det nærmere. Det omfatter stadig en del japanske begreber, fx Kaizen. Men Lean har udviklet sig selvstændigt, frigjort fra TPS. Det er godt det samme, da Toyota siden har haft deres andel af problemer med kvaliteten. Value Stream Map (VSM) Arbejdet i en Lean organisation bygger på en proces der løbende vurderes og forbedres. I Lean er processen kendt som en Value Stream, og den beskrives i et Value Stream Map (VSM). Figur 1 viser et VSM for forvaltningsopgaver generelt. Processen består af de aktiviteter der gennemfører en forvaltningsopgave. I en Lean organisation vurderes processen løbende, og aktiviteter der ikke tilfører konkret værdi til produktet, altså forvaltningsopgaven, betragtes som spild, og fjernes. Resultatet er en stram (Lean) værdifuld proces. Det japanske navn for spild er Muda, og de forskellige former er beskrevet senere i dette essay i et separat afsnit. Den nederste linje i figur 1 viser nogle implementeringsprocesser som også er en del af VSM et. De to testaktiviteter placeres forskelligt af mange organisationer. Testcases ses ofte efter kodning, af traditionelle grunde. Acceptkriterier kan placeres tidligt eller sent, ligeledes om man forsøger at gøre forløbet testdrevet. Detaljeringsgraden af acceptkriterier varierer i sig selv meget. Hvis man arbejder med meget detaljerede acceptkriterier, og gør det meget tidligt, måske endda samtidig med opgavebeskrivelsen, er hele forvaltningsforløbet testdrevet. Antallet og betydningen af implementeringsprocesserne varierer i forhold til kategorien af forvaltningsopgave. Næste skridt kan derfor være at definere fire VSM er. Én for hver opgavekategori, dvs. for henholdsvis fejl, tilpasninger, udbygninger og saneringer. I figur 1 er de fire opgavekategorier blot stablet ovenpå hinanden, for at vise at en opgave der vandrer igennem vil være en af de fire. Implementeringsprocesserne i den nederste linje skal med i hver af dem. Det vil sige at Analyse, Arkitektur, Acceptkriterier, Design, Testcases, Kodning rykkes op mellem pilen fra Implement og pilen der peger på Build. Med en vægt og indhold der er passende i forhold til om det er en Fejl, Tilpasning, Udbygning eller Sanering. Navnene på implementeringsprocesserne kan være de samme for alle fire opgavekategorier, men beskrives forskelligt. De to testprocesser beskrives forskelligt for at rette en fejl i forhold til at sanere, osv. De fire kategorier er hver især en Class of Service i Kanban terminologi. Kategorien Fejl er at rette en kendt fejl. Man kan derfor kalde denne kategori af opgaver for Rettelser i stedet for fejl. Både Fejl og Rettelse bruges i praksis som opgavekategori. Figur 1 viser nogle procesejere i de grå ovaler. De skal helst være tæt på den proces de ejer, gerne selv arbejde med den dagligt. C:\Users\Poul\Documents\AS\Essays\Essay, LeanForvaltning.docx Side 2

3 Uden Continuous Integration opstår der en kø mere foran Build. Figur 1: Value Stream Map Lead Time og Cycle Time Lead Time og Cycle Time viser tider for hvornår opgaver ankommer, venter, sættes i gang, gennemføres og leveres. De er nemme at beregne og vise, og al erfaring viser at metrikker af enhver art skal være tæt på gratis at arbejde med. Ellers bliver det ikke gjort, eller ikke gjort godt nok. Lead Time regnes fra det tidspunkt en forvaltningsopgave fremsættes og oprettes i køen før Planning, og til den releases/deployeres og kan nyttiggøres af kunder og brugere. Lead time kan selvsagt være så lang som helst, fordi den afhænger af prioritering. Nye opgaver prioriteres måske konstant højere, eller der fremsættes flere opgaver end vi har ressourcer til. Den effektive tid der arbejdes med den kan tilsvarende være promiller. Cycle Time regnes fra en forvaltningsopgave flyttes til køen før Implement og til den flyttes til køen før Deploy. Lad os som eksempel antage en Tilpasning af beregningen af et tilskud. Lovgivningen har ændret sig, og det er nødvendigt at ændre på selve forretningslogikken. Den 1. april lander opgaven fra en kunde og Lead Time starter. Produktejeren registrerer den i produktbackloggen, giver den en prioritet, estimerer den, og hvad der ellers skal til for at synliggøre den lille ny. Den 31. maj vælges den på en Sprint Planning som del af et Sprint, og Cycle Time starter. Den er nu synlig på et Taskboard. Teamet starter Sprinten den 1. juni, og tilpasningen behandles på et eller andet tidspunkt i de 28 dage. C:\Users\Poul\Documents\AS\Essays\Essay, LeanForvaltning.docx Side 3

4 Den releases sammen med de andre opgaver i den nye release den 1. juli og dermed slutter Lead Time. Lead Time er i dette eksempel 91 dage. Cycle Time er lidt mere problematisk. Den kan være 28 dage for alle opgaver i en Sprint, hvis vi regner dem som startende og sluttende samtidig. Der er intet i vejen for at alle kan starte og slutte samtidig, hvis vi åbner alle med det samme, og arbejder på alle til den sidste dag i Sprinten. Det er mulighed 2 i tabel 1. I mulighed 3 er det lidt mere varieret med opgaver der er i forskellige grader af overlap, og åbne samtidig. Endelig kan de løses som Single-Piece-Flow, Back-to-Back som i mulighed 1. Vores Tilpasning har en mulig Cycle Time på kun 5 dage, men kan være alt mellem 5 og 28 dage. Mulighed Opgave Start Slut C Start Slut C Start Slut C 1 1. juni 4. juni 4 1. juni 28. juni juni 28. juni juni 9. juni 5 1. juni 28. juni juni 6. juni 6 Tilpasning 10. juni 14. juni 5 1. juni 28. juni juni 4. juni juni 17. juni 3 1. juni 28. juni juni 27. juni juni 25. juni 8 1. juni 28. juni juni 28. juni juni 28. juni 3 1. juni 28. juni juni 28. juni 14 Tabel 1: Opgaverne i Sprinten, eksempler på Cycle Time Hvis vi arbejder uden Sprint, men fx løbende med Kanban kan vi stadig ende op med mange forskellige typer af Cycle Times. Afhængigt af hvor mange opgaver vi vælger at arbejde med samtidig, altså hvor høj en WIP. Måske tvunget af at skulle åbne opgaver nye opgaver for at holde alle i teamet beskæftigede. Lead Time og Cycle Time skal vurderes intelligent (no offense), da vi til stadighed skal huske at forvaltning ikke er masseproduktion af ensartede produkter. Effektiv tid Den effektive tid for en opgave er procentdelen af tid vi beskæftiger os med den. Mellem start dato og slut dato. Hvis effektiviteten er 100 % er vi altså optaget af kun at løse denne ene opgave. Vi kan beregne det for Lead Time, såvel som for Cycle Time. Men effektiviteten er ikke altid interessant i forhold til Lead Time, fordi en opgave naturligt kan have lange perioder hvor der ikke arbejdes med en. Opgaven kan ligge i årevis før den er relevant at gennemføre. Og den kan ligge et stykke tid når den er færdig, før den releases til brug. Anderledes stiller det sig for Cycle Time, især hvis man kører Single-Piece-Flow. Trenden i effektiviteten fortæller hvor godt det lykkes at gennemføre én opgave ad gangen. C:\Users\Poul\Documents\AS\Essays\Essay, LeanForvaltning.docx Side 4

5 Målet er måske desuden at reducere Cycle Time, og det kan gøres ved enten at øge produktiviteten i den tid man arbejder med opgaven, eller at reducere tiden hvor der ikke arbejdes med den. I det første tilfælde arbejder man smartere, bruger ny teknologi, eller andet der kan udføre aktiviteten på kortere tid. I den andet tilfælde fjerner man spildtid, øger flowet, etc. Og trenden i figur 2 fortæller hvor godt det lykkes. Eksemplet: Opgaven kom ind ad døren den 1. april. Dermed startede Lead Time, og vi brugte 30 minutter til registrering og prioritering. Det er det samlede tidsforbrug før start af Cycle Time. Analysen tog 30 minutter i forbindelse med Sprint Planning den 31. maj. Det meste var allerede analyseret via opgavebeskrivelsen, så der manglede kun at udpege de konkrete funktioner i systemet der skulle ændres. Der var ingen ændringer til arkitekturen. Den 10. juni opstillede vi acceptkriterier i form af både positive og negative testscenarier. Forløbet var testdrevet og med konkrete testscenarier med konkrete forventede slutresultater. Det tog 3 timer. Den 11. juni reviewede vi designet, men der var ingen designændringer. Det tog alligevel 30 minutter. Den 12. juni skrives testcases. Vi koder testdrevet, og det tog 3 timer. Den 13. juni ændrede vi koden på 2 timer, med automatiseret test af de nye testcases og med Continuous Integration. Den 14. juni opdateredes den eksisterende regressionstest med de nye testcases, vi bruger Continuous Integration, og det hele tog 3 timer. Opgaven er færdig fra vore hånd og flyttes til kolonnen Done på Taskboardet. Den kunne have været releaset hvis kunden ønskede det så Cycle Time slutter derfor her. Den releases derimod først sammen med de andre opgaver i den nye release den 1. juli og dermed slutter Lead Time. Vi har i alt brugt 12 timer på at gennemføre den. Vi bruger altid 6 timer pr. dag som mål for hvor meget der reelt kan arbejdes, og det er 5 dage á 6 arbejdstimer, lig med 30 timer. det giver en effektiv Cycle Time på 40 %. Den effektive Lead Time er 12,5 timer ud af 91 dage, det er ca. 2,3 %. Det ikke ualmindeligt at se effektive arbejdstider på under 50 %. En opgave med en Cycle Time på 2 dage, har måske en effektiv tid på 50 % fordi de 6 timer bruges enten på spild, fordi en aktivitet ikke opfylder de tre kriterier for at være værdifuld, eller på blot at ligge stille fordi forvalterne bruger deres tid på noget andet. To opgaver der løses samtidigt af de samme ressourcer har altså hver især en effektiv tid på 50 %. Værdifuld tid Den værdifulde tid er summen af de værdifulde aktiviteters procent af den effektive tid. Denne oplysning ønsker jeg for at se om der er brug for at jagte Muda. De værdifulde aktiviteter er defineret i Lean med tre karakteristika. Det er det første af begreberne i afsnittet Lean begreber senere i dette essay. Og det der ikke er værdifuldt er Muda. C:\Users\Poul\Documents\AS\Essays\Essay, LeanForvaltning.docx Side 5

6 Spild. Herunder planlægning og rapportering. Test er også Muda hvis det er traditionel passiv test. I vores eksempel har vi været så heldige at arbejde testdrevet, så tiden er brugt aktivt og med nytte. Den tæller derfor som værdifuld tid. I traditionelle udviklingsorganisationer kan man se meget lave procenter af værdifuld tid. En kort Cycle Time der kun har værdifulde aktiviteter er både produktiv og effektiv. Og uden lagre, handovers eller spildtid. Trenden i effektiv og værdifuld tid Figur 2 viser de sidste 13 måneders gennemsnit. Men fremskaffelsen af dataene er ikke gratis. Det kræver at man holder styr på tidsforbruget. Man skal for hver opgave registrere tidforbrug, effektiv tid, og værdifuld tid. Man må desuden overveje om det er nyttigt at tage alle opgaver med: - Er der en blanding af små og store opgaver, der gør at procenten er misvisende. Skal der skelnes mellem forskellige størrelser af opgaver i forhold til timer og udstrækning. Og kun medtage opgaver over et vist antal timer. Eller forskellige visninger på forskellige størrelse. Der kan være mange små opgaver der tilsammen er signifikant. - Er der en blanding af vigtige og mindre vigtige opgaver. Skal der skelnes mellem forskellige grader af kritiske opgaver, og kun vælge de kritiske. Eller have visninger af forskellige grader af kritikalitet Værdi Effektiv Netto Rullende måneder Figur 2: Cycle Time C:\Users\Poul\Documents\AS\Essays\Essay, LeanForvaltning.docx Side 6

7 Nettotiden er den værdifulde % tid af den effektive % tid. I en Lean forvaltningsorganisation kan man øge den effektive tid ved at arbejde med én opgave ad gangen. Man kan desuden øge den værdifulde tid ved kun at udføre værdifulde aktiviteter, herunder droppe de forskellige former for Muda der er nævnt i figur 3. Grafen er nyttig, men mange organisationer ønsker ikke at registrere timer på et niveau der er tilstrækkelig detaljeret, og især tilstrækkelig korrekt, til at beregne den effektive tid. Nogle undlader helt, andre bruger skønnede tal. Der er et kæmpespring i indsatsen der skal til for at registrere timer, således at vi kan vise effektiv og værdifuld tid, som vist i figur 2. I forhold til den betydelig mindre indsats der skal til for at registrere datoer på opgaverne, og beregne Lead Time og Cycle Time. Lean Time og Cycle Time er nemme at beregne, og de er pålidelige. Effektiv tid og værdifuld tid kræver en stor indsats, og de er både besværlige at skaffe og besværlige at få nøjagtige. Men de er vejen hvis der skal en rigtig analyse i gang, som en del af Lean. Kanban Hvis vi bruger Kanban, er der ingen Sprint. Hver opgave får en synlig Cycle Time, men der kan stadig være et antal overlappende og overhalende opgaver i gang samtidig. Styret af WIP, og dybest set af at alle skal have noget at lave, og at opgaver kan stå stille på grund af problemer, koordinering eller af andre grunde vente på noget. Den lærende organisation En Lean forvaltningsorganisation dyrker mangfoldigheden af mulighederne i den lærende organisation. Det er med til at øge produktivitet og kvalitet i både styring og gennemførelse af forvaltningsopgaver. Læringen er ofte Peer-to-Peer. Forvaltere er de nærmeste til at lære af hinanden. Den daglige læring kan grundlægges ved at få alle til at Blogge og Chatte. Det kan fx være om erfaringer med det daglige arbejde, om konklusionen fra et Kaizen møde, om resultatet af et spændende forsøg (PDCA), en boganmeldelse, etc. Forvaltere skal støttes i at bidrage med viden, og belønnes når de gør det. Konkrete møder kan være morgen, middag og aften. I form af morgenmøder med et spændende emne, frokosten som Walk-and-Talk i nærmeste park (sandwich), eller påvej-hjem møder med en spændende gæstetaler. Deltagelse i konferencer med efterfølgende opsummering og vidensdeling er en mulighed. Periodiske erfamøder med eksterne gæster, eller deltagelse i eksterne erfamøder i andre forvaltningsorganisationer. C:\Users\Poul\Documents\AS\Essays\Essay, LeanForvaltning.docx Side 7

8 Peer-to-peer kan suppleres med Mentorships og Senseis, hvis de mest erfarne forvaltere fungerer som Coaches og Mentors. Det er værd at uddanne forvaltere i procesforbedring, VSM'er, fejlårsagsanalyse, øget produktivitet, kvalitetsforbedringer, Muda Hunting og proaktiv forvaltning. Uddan også forvaltere i Teaming, Pairing, Coaching og kommunikation. Både individer og teams kan og skal udvikle sig. Videreudvikling af mennesker er en væsentlig faktor i videreudvikling af systemer. Enhver kan starte med at forbedre sig selv. Du er den eneste der kan ændre dig. Giv også plads til at teamet kan udvikle sig. Kaizen er en teknik til konstant forbedring. Den kan fx bruges når der er fundet en fejl, eller hvis en leverance ikke kan gennemføres som aftalt. Men Kaizen bruges også til forbedringer af noget der ikke er Broken. Velfungerende processer skal også forbedres. Team Empowerment Forvaltningsteamet skal have kompetence til at træffe beslutninger. Det samme med hvert medlem af teamet. De kendte historier om at arbejderen på gulvet har både ret og pligt til at stoppe produktionen, hvis man opdager en fejl. Et samspil mellem enkeltpersoner der træder i karakter, og teamet der er ansvarlig for produktionen. I forvaltning handler det knap så meget om at stoppe arbejdet, men mere om at gøre opmærksom på fejl og mangler. Det kan være produktrelateret, for eksempel en opgavebeskrivelse der kan tolkes på flere måder. Eller procesrelateret, for eksempel hvis teamet møder sig ihjel. Det er begge to fejl, der skal illumineres og fjernes. Teamet skal kunne stå inde for det der foregår. Det er en forudsætning for at tage ansvar. Myte: Man får det man betaler for. Og produktivitet og kvalitet er en funktion af budgettet. Nej, man kan få mere, med en mindre indsats. Best Practices og løbende forbedring af dem, kan skabe mere, for samme investering. Teamet kan skabe mere i dag end i går. Eller er du født perfekt? Når teams får indflydelse, øges deres lyst til at deltage i en forbedringsproces. Man får måske endda mest for sine penge, når teamet får indflydelse. Det er OK at fejle, det er ikke OK at undlade eksperimenter. Ethvert resultat af et forsøg er værdifuldt. Teamet skal have lov og pligt til eksperimenter. Bidrager medarbejderne med forslag til forbedring? Måler vi antallet af forslag? Ellers må vi begynde på begge dele snarest. C:\Users\Poul\Documents\AS\Essays\Essay, LeanForvaltning.docx Side 8

9 Lean begreber Value Stream Map: En værdistrømsanalyse der viser de værdifulde aktiviteter i en forvaltningsopgave. Tre kriterier for at en aktivitet er værdifuld, skal være opfyldt: a. Kunden vil gerne betale for aktiviteten. b. Den skal kunne udføres uden fejl. c. Den skal bearbejde produktet. Transformere det. Tilføre det værdi. VSM er synlig og viser den givne organisations strøm og aktiviteter. Den nemmere vej er at bruge de 14 trin, og tage hensyn til forskelligheden af de fire typer opgaver, fejl, tilpasninger, udbygninger og præventiv vedligeholdelse. Stadig generelt til en start, og så bygge videre med sin egen organisations interessenter, beslutninger og så videre. Muda: Det der ikke lever op til de tre karakteristika for værdifulde aktiviteter er spild. Mura: Er der ujævnheder i kodens eller artefakternes kvalitet? Uensartede opgavebeskrivelser eller kode? I masseproduktion betyder det kassering. I systemforvaltning at processen skal forbedres. Muri: Pres og stress. Er tempoet bæredygtigt? Er der overarbejde på grund af urealistiske tidsplaner eller ønsketænkning. Vi må kalde en spade for en spade, hvis vi véd at produktet lider. Ikke lade som om det ikke betyder noget, eller kalde noget for et nødvendigt onde, hvis det blot er et ledelsesmæssigt valg. Det er helt OK at træffe ledelsesmæssige beslutninger. Men det skal ikke være med bevidst lukkede øjne for konsekvenserne, og bilde sig ind at det går nok. Pres og stress er kilder til fejl. Flow: Sell one, make one. Den ideelle produktion sker uden afbrydelser, Fra krav til ibrugtagning. En kunde bestiller en ændring, vi leverer den. Det er faktisk naturligt i forvaltning. Uden stop, uden køer, uden lagre under vejs, uden overleveringer. Lean Nirvana. Continuous Flow Production. Single-Piece Flow. Pull-Push: I et Pull forløb er det den enkelte opgaver der trækker noget arkitektur, design, unittest, kodning og CI med sig. Traditionelle projekter kører Push, med faser. Arkitekturen defineres først, som projektet så skal skubbe foran sig indtil GoLive, hvor den til den tid er forældet, fejlfyldt, og dem der så det geniale i den, er rejst. Det samme med de efterfølgende faser. Push giver ophobninger af Work-in-Progress. I Pull arbejdes der ikke med arkitektur eller design, før en opgave har brug for det. Pull giver Just-in- Time. Decide at the latest possible moment. Rette mængder til rette tid. Push svarer til vandfald. Lean bruger Pull når det er muligt, og kun Push når det er nødvendigt. kanban (med lille k): Et visuelt signal der styrer arbejdsgangen i et Pull system. Det er en del af den simple og visuelle styring. WIP: (Work-in-Progress). WIP styres af forvalterne, med det formål at begrænse antallet af åbne opgaver. C:\Users\Poul\Documents\AS\Essays\Essay, LeanForvaltning.docx Side 9

10 Kaizen: Korte møder der fokuserer på forandring. Teamets medlemmer stiller konkrete forslag til forbedring af deres egen proces. Uanset hvilken form for Lean man bruger til systemforvaltning er procesforbedring ved hjælp af Kaizen en obligatorisk del. Det involverer forvalterne i en hyppig og konkret forbedring af præcis den måde de selv arbejder på. Plan-Do-Check-Act: Konkrete eksperimenter, som grundlag for at vedtage, ændre eller afvise en mulig forbedring. PDCA sættes ofte i værk i forlængelse af Kaizen møder. PDCA sørger for at gode ideer afprøves før de indføres generelt. Et eksperiment kan handle om at blive bedre til at styre WIP. Eller styre hasterettelser. Eller fjerne ujævnheder i vores kvalitet. Eller ændre på opgavestørrelsen. Kaikaku: Teknikker til store ændringer, paradigmeskift. Hoshin: Planer der sikrer at strategiske mål får betydning i hverdagen. Systemforvaltning sigter længere end til næste release. DCA: Er der kilder til en fejl der kan fjernes, for at hindre den i at opstå fremover? De 5 Why s: Princip der ofte bruges i DCA. Op til 5 gange Hvorfor det?. Afsenderkontrol: Bygger på aftalte Exit kriterier. Forudsætning for Built-in Quality. Modtagerkontrol: Bygger på aftalte Entry kriterier. Forudsætning for Built-in Quality. Andon: Lysende lampe der viser at der er et problem eller anomali. Fortæller om indtrufne eller nærtstående problemer. Testmiljøet er nede. Serveren er nede. Faresignaler: Lav benzinstand. Slik (Frugt) skålen er tæt-på-tom. Indgår i den visuelle styring. Simpel og visuel styring: Visualisering af opgaverne, på Wall en. Dashboard til team og ledelsen. Rød-Gul-Grøn. Lyd, lys, farver, grafer. Brug sanserne, væk sanserne. Jidoka: Processen stopper ved fejl. Ikke bare for at reparere produktet, men for at finde og fjerne den egentlige årsag. Filosofien er at når medarbejdere har ansvaret for kvaliteten af arbejdet der udføres, har de også kompetence til at stoppe produktionen. Built-in Quality: Kvaliteten skabes i flowet, den reviewes ikke på, testes ind eller klistres på til sidst. Lead Time: Tiden mellem vi kender et ønske og til det er i brug. Det kan være årevis. Cycle Time: Tiden fra vi konkret starter på at gennemføre en forvaltningsopgave, til den er leveret fra vores hånd. Poka-yoke: Sørg for at du ikke kan fylde diesel på benzindrevne biler. Sørg for automatik, i stedet for manuel opmærksomhed. C:\Users\Poul\Documents\AS\Essays\Essay, LeanForvaltning.docx Side 10

11 Yokoten: Dele viden med andre forvaltere. Pairing, Sharing og Teaming. Heijunka: Production Levelling, fordeling af produktionen af artefakter. Testcases, kode og Scripts i små mængder. Spred produktionen af artefakter over hele Sprinten, for at være i niveau med efterspørgsel. Gemba: Gemba er japansk og betyder Det rigtige sted eller det egentlige sted. Der hvor der arbejdes. Gerningsstedet. Det kan være teamets lokale. Gemba får lov til at snige sig ind i sit originale japanske udseende. Procesforbedring skal tage udgangspunkt i virkeligheden. Alle medarbejdere skal derfor bidrage. For at supplere konsulenters og metodefolks virkelighedsfjerne overvejelser. Genchi Genbutsu: Go See. Hænger sammen med Gemba. Produktejer besøger teamet. Den systemansvarlige besøger produktejeren. Ledelsen skal regelmæssigt besøge forvalterne, og få et førstehånds indtryk af arbejdet. Hvordan vil alle ellers vide hvad de taler om. Metodefolk skal jævnligt besøge forvalterne der jævnligt skal besøge deres kunder. Lean House: Billede af den implementering af Lean, vores organisation arbejder med. Spild (Muda) Muda må jagtes året rundt. Muda Hunting. Muda reducerer produktiviteten og øger Time-to-Market. Muda sætter kundens tilfredshed på spil. Det forhindrer succes. Spild er årsag til ringere kvalitet. Det beslaglægger tid der kunne bruges bedre, og gør det sværere at producere det rigtige, i første forsøg. Uden spild er produktionen enklere, og gør vejen til 0-fejl kortere. Lean arbejder med to typer spild, muda-1 og muda-2. Den første er spild som anses for nødvendig. Administration og rapportering er almindelige eksempler. Muda-2 er decideret spild. For eksempel at vente på noget. Figuren viser eksempler på de syv former for spild. Formernes navne er oversat fra de engelske: Transportation, Waiting, Inventory, Overproduction, Defects, Extra Processing og Motion. Eksemplerne er oversat til IT. Brug dem som inspiration, selvom nogle virker søgte. Og vi har vel alle deltaget på nyttige møder. Og bevægelse er sundt. Og at genskabe en fejl er nødvendigt, selvom det i Lean tankegang er spild. Transport: Overflødig, ikke-værdiskabende, transport af hele eller dele af artefakter, mellem steder hvor der sker egentlig bearbejdning af dem. Automatiserede flytninger, for eksempel i forbindelse med Continuous Integration, er bedre end flytninger der sættes i gang manuelt. Vente: Pauser. Stop. Er der mennesker der venter på noget? Eller faciliteter eller ressourcer der ikke bruges eller udnyttes, fordi noget ikke er klart. Ledighed, ventetid. C:\Users\Poul\Documents\AS\Essays\Essay, LeanForvaltning.docx Side 11

12 Overproduktion: Produkter der ikke er solgt endnu. Produceres der noget der ikke er efterspurgt? Produceres der hurtigere, tidligere eller i større mængder end nødvendigt? Hvornår er det proaktivt, og hvornår er det overflødig spekulation? Fejl: Fejl, mangler, skader. Noget der skal udbedres, repareres, korrigeres. I et produkt, i en proces, eller i en service. Genskabe fejl, rapportere fejl, genteste rettelser. Lager: Mellemresultater der hober sig op. Delvist færdigt arbejde. Bevægelse: Strække sig, bøje sig, række ud, sno sig, dreje, løfte. Mennesker der foretager sig unødvendige bevægelser i den aktuelle arbejdsproces. Ekstra processer: Arbejdsprocesser der ikke er en del af det kunden har bestilt. Kunstige artefakter der kræves af metodeafdelingens modeller, men ikke af kunden. Ud over de syv kan der være spild ved at: - arbejde på mere end ét projekt, eller i mere end ét team. Kaldes også Task Switching. - skulle sætte sig ind i noget for at kunne udføre det. Hvordan er det nu lige at vi gør det her? Er det On-the-Job Training? Måske. Men hold øje med om omfanget er rimeligt. - forklare afvigelser på grund af urealistiske tidsplaner og ønsketænkning. Muda Transport Ventetid Overproduktion Aktiv systemforvaltning Krav, Userstories eller Use Cases der sendes rundt Styringsinformation der sendes rundt Flytning mellem forskellige teams biblioteker Kode der flyttes til Builds Kode der flyttes til Alfatest eller Betatest Transport på grund af handovers Ingen ledig mødedato før Venter på afklaring Venter på nogen Venter på at nogen skal blive færdig Venter på en beslutning Venter på en ændringsbeskrivelse Venter på svar Venter på at noget skal ske Testere, forvaltere og designere der venter på hinanden indbyrdes Forsinkelser, der skaber ventetid, der ikke kan udnyttes, etc. Ledige ressourcer af enhver slags Fremtidssikring af funktionaliteten Fremtidssikring af koden Overbearbejdning, finpudsning Ekstra mulighed for brugere C:\Users\Poul\Documents\AS\Essays\Essay, LeanForvaltning.docx Side 12

13 Spændende teknisk mulighed Ikke købt af nogen endnu Diskussion I teamet: Det her ville være lækkert (sejt/cool) (Alle eksemplerne skal afvejes med det positive i at være proaktiv) Fejl Lager Bevægelse Ekstra Processer Fejl, reparationer, gentest Regressionstest efter rettelse Korrektioner Sanering Defect Management, Incident Management, Problem Management Afvisning, noget der ikke er helt godt nok, omarbejde Kode der hober sig op, uden at være testet Besluttede og bevilgede ændringer der blot venter på ledige hænder Testscenarier der endnu ikke er brugt til noget Testdata der endnu ikke er brugt til noget V-model, der producerer store mængder planlagt test Enhver test der ikke er en del af et testdrevet forløb Delvist færdigt arbejde Færdigt arbejde der ikke er releaset Møder uden for teamets fælles lokale Hen for at møde nogen Forvaltere der skal flytte sig fysisk for at teste Ting der ikke er ved hånden Mennesker der ikke er i nærheden Gå hen til en PC (værktøj), i stedet for at kigge op på væggen (Wall) Arbejde på flere projekter samtidig (jeg skal lige over til de andre!) Instrumentering af kode for at teste Metadata der skal registreres for en Userstory Rapportering Utilstrækkelig, eller umoden, teknologi Værktøjer, hvor noget simplere kunne bruges Mockups Dokumentation der ikke bruges Kvalitetskontrol som godkendelse Separat kvalitetskontrol Afsluttende testforløb Reviews ved faseskift og overleveringer Genskabe en fejl Reviews af hensyn til standard og metode Figur 2: Potentielt spild i systemforvaltning C:\Users\Poul\Documents\AS\Essays\Essay, LeanForvaltning.docx Side 13

14 Opsummering Ved at kombinere de følgende principper fra Lean: Flow + Pull + procesejere der er tæt på processen + Empowered Teams således som de også bruges i fx produktionsvirksomheder, administration, hospitaler og serviceleverandører, med de følgende Agile Best Practices fra IT: en testdrevet tankegang + Continuous Integration + Whole Teams + Extreme Programming generelt opnår vi en Lean forvaltning hvor: Kode altid er testet (på grund af det testdrevne) Testcases altid er brugt (eventuelt bortset fra én enkelt vi lige har lavet) Alt altid er integreret og integrationstestet (takket være CI) Arkitekturen altid er brugt (sat i sving; i modsætning til at ligge på lager) Designet altid er brugt (sat i sving; i modsætning til at ligge på lager) Der ikke er lagre i det hele taget En opgave løses i ét ubrudt Flow Ingen handovers Ingen flaskehalse Built-in Quality Teamet altid holder et Sustainable Pace Alt i alt er det den situation vi tilstræber med LeanForvaltning. Principperne og metoderne er selvfølgelig ikke formålet i sig selv. De er et middel til at nå det egentlige formål, som er tilfredse kunder, højere produktivitet og større profilt. Men midlerne skal nu engang til. C:\Users\Poul\Documents\AS\Essays\Essay, LeanForvaltning.docx Side 14