Sådan forbedrer du en forretningsproces

Kort fortalt

• Fastlæg as-is først: I kan ikke vise forbedring i forhold til en proces, ingen er enige om.
• Indeslutning stopper blødningen; den er ikke løsningen og skal registreres for sig.
• Ændr én ting ad gangen, ellers ved I ikke, hvilken ændring der virkede.
• Verificér effekten efter en fastsat periode: mod det mål, I startede med.
• At fjerne et trin er en forbedring. At tilføje en godkender er det sjældent.

De fleste forbedringer fejler allerede i diagnosen

Procesforbedring har en velkendt fejlmåde, og den handler ikke om dovenskab. Den handler om at stille diagnosen ud fra symptomet: fakturaerne betales for sent, så vi tilføjer en godkender; sagerne bliver genåbnet, så vi tilføjer en tjekliste. Begge dele er plausible reaktioner på en observation, og ingen af dem er forankret i, hvorfor det sker. Et halvt år senere er nøgletallet uændret, og processen har ét trin mere i sig, og netop det er den reelle, akkumulerede pris for at springe diagnosen over.

Alternativet er ikke mere analyse for analysens skyld. Det er en bestemt rækkefølge: beskriv, hvad der sker i dag, så detaljeret at det kan diskuteres, inddæm den akutte skade uden at lade som om inddæmning er en løsning, find en årsag, evidensen bakker op om, ændr én ting, og tjek så, om det virkede, før I erklærer jer færdige. Det sidste trin er det, der oftest bliver droppet, og det er det eneste, der skiller forbedring fra aktivitet.

Eksemplet herunder er en proces for rodårsagsanalyse: den diagnostiske motor under ethvert forbedringsarbejde. Den indeholder de to veje, der gør den ærlig: en gren for utilstrækkelig evidens, som kan lukke sagen med en dokumenteret begrænsning i stedet for at opfinde en årsag, og en verifikationssløjfe, der sender en ubekræftet hypotese tilbage til fornyet analyse.

Diagnosen under forbedringen

En proces for rodårsagsanalyse, fra rejst problem til godkendte korrigerende handlinger. Læg mærke til, hvor teams typisk skyder genvej.

1. Definér problemet, før I opstiller teorier

   Beskriv problemet som observeret, aftal en skriftlig problemformulering, iværksæt indeslutning, og sammensæt derefter undersøgelsesteamet. En problemformulering, der skrives, efter nogen har fået en teori, kommer til at indeholde teorien, og analysen bekræfter den så bare.

2. Evidensen, og grenen for når der ingen er

   En beslutning om tilstrækkelighed med tre veje: fortsæt, udvid indsamlingen, eller luk med en dokumenteret databegrænsning. Netop den tredje vej forhindrer, at en undersøgelse opfinder en årsag, når loggene for længst er rullet.

3. Test hypotesen: vælg den ikke bare

   Opstil årsagshypoteser, test dem mod evidensen, og gå tilbage i sløjfen, når årsagen ikke er verificeret. Adskil derefter rodårsag fra medvirkende faktorer: et selvstændigt trin, fordi teams ellers skriver handlinger mod den faktor, der er nemmest at rette.

4. Handlinger, der er godkendt og ressourcesat

   Resultaterne registreres, handlinger foreslås, en godkendelse kan sende dem retur, og til sidst oprettes en CAPA-sag med navngivne ansvarlige. Forbedring dør netop dér, hvor handlingerne er aftalt, men ingen har finansieret tiden, og derfor er godkendelsen tegnet som en port.

Sådan fungerer det

1. Fastlæg processen, som den er i dag

   Kortlæg as-is sammen med dem, der udfører arbejdet (undtagelser og workarounds inklusive) og registrér et par mål: gennemløbstid, andel omarbejde, mængde i hver gren. Uden en baseline, folk er enige i, kan enhver senere påstand om forbedring anfægtes, og den bliver anfægtet.

2. Formulér problemet uden en årsag i

   »Fakturaer betales for sent« er et problem. »Godkenderne er langsomme« er en teori i problemets tøj, og enhver analyse, der starter dér, slutter dér. Skriv formuleringen ud fra observationen og målet, og lad så evidensen fortælle, hvem eller hvad der er involveret.

3. Indeslut, og registrér det som indeslutning

   Hvor problemet aktivt gør skade, skal I stoppe det, men notér det som en midlertidig foranstaltning med en ansvarlig og en slutdato. Indeslutning, der stille får lov at blive, bliver til et permanent ekstra trin, og den fjerner samtidig presset for at finde den egentlige årsag.

4. Find en årsag, evidensen bakker op om

   Indsaml data, mens de stadig findes, rekonstruér hændelsesforløbet, opstil mere end én hypotese, og test dem. At stoppe ved den første plausible forklaring er den absolut mest udbredte fejl, og det er derfor, verifikationsbeslutningen i eksemplet går tilbage i sløjfen i stedet for videre.

5. Ændr én ting

   Vælg den mindste ændring, der adresserer årsagen, definér hvad succes er og hvornår, og indfør den alene. Samlede ændringer gør det umuligt at tilskrive effekten: når nøgletallet flytter sig, ved I ikke, hvilken ændring I skal beholde, og når det ikke gør, ved I ikke, hvilken I skal rulle tilbage.

6. Verificér efter en fastsat periode, og opdatér diagrammet

   Kom tilbage, når der er kørt cyklusser nok til at se et signal, og sammenlign med jeres baseline. Virkede det, så opdatér procesdiagrammet og dets godkendte version, så den nye måde er den dokumenterede måde. Virkede det ikke, så genåbn analysen i stedet for at lægge endnu en ændring oven på den første.

Faldgruber du skal undgå

• At forbedre uden en baseline

  Uden en aftalt as-is er der ingen måde at vise, at ændringen hjalp, og ingen måde at opdage, at den ikke gjorde.

• At tilføje en godkender som løsning

  Det er den mest nærliggende reaktion, og den gør pålideligt processen langsommere uden at røre ved, hvorfor fejlen opstod. De fleste reelle forbedringer fjerner et trin.

• At samle flere ændringer i én

  Fem ændringer på én gang giver ét tvetydigt resultat. Tag dem i rækkefølge, også når det føles langsomt.

• Aldrig at verificere

  En forbedring, ingen har tjekket, er en antagelse med en projektplan hæftet på. Verifikationstrinnet er det, der skiller forbedring fra aktivitet.

Forbedr jeres egen proces

Åbn eksemplet med rodårsagsanalyse som dit eget diagram, eller kortlæg jeres as-is-proces først og arbejd videre derfra.

Forbedr jeres egen proces

Relaterede guides

• Sådan kortlægger du en forretningsproces
• Sådan laver du et procesdiagram
• Sådan laver du et swimlane-diagram

Ofte stillede spørgsmål

Hvordan kommer jeg i gang med at forbedre en forretningsproces?

Kortlæg, hvad der sker i dag, sammen med dem, der gør det (undtagelserne inklusive). Næsten alle forbedringsforløb, der går i stå, gjorde det, fordi de tog udgangspunkt i en formodet proces frem for en dokumenteret, og den formodede version er altid den lykkelige sti. Når as-is findes, og folk er enige i den, plejer problemerne at melde sig selv: trin uden ejer, sløjfer med omarbejde og overleveringer, hvor modtageren ikke får besked, er synlige på papiret.

Hvad er forskellen på et symptom og en rodårsag?

Et symptom er det, I observerer: forsinkede fakturaer, genåbnede sager, manglende leverancer. En rodårsag er det, I kan fjerne, så symptomet ikke kan opstå igen. Forbedringsarbejde fejler, når det behandler symptomet, fordi den ændring, der kommer ud af det (endnu en godkender, endnu en tjekliste), koster penge og rører ikke ved mekanismen. Testen for en rodårsag er, om problemet ville være undgået, hvis den var fjernet, og om evidensen understøtter det frem for blot at tillade det.

Skal jeg bruge Lean eller Six Sigma for at forbedre en proces?

Nej, selvom begge giver et brugbart sprog. De mekanismer, der betyder noget, er tilgængelige uden en metode: dokumentér den nuværende proces, mål noget, find en årsag, evidensen bakker op om, ændr én ting, og verificér. Formelle programmer tilfører stringens og et fælles sprog, hvilket hjælper i stor skala; de tilfører også et overhead, der kan overstige værdien for en enkelt proces. Start med rækkefølgen, og indfør rammeværket, hvis mængden af forbedringsarbejde berettiger det.

Hvordan får jeg en forbedring til at holde?

Opdatér den dokumenterede proces og dens godkendte version, fortæl det til de berørte, og tjek igen et kvartal senere. Ændringer, der kun lever i en projektrapport, forsvinder inden for få måneder, fordi den dokumenterede proces stadig beskriver den gamle måde, og nye kolleger bliver oplært i den. Forbedringen er ikke færdig, når ændringen er lavet; den er færdig, når diagrammet, oplæringen og praksis siger det samme.