ITIL® 4 guiding principles: 4 .Collaborate and promote visibility

Caspar Miller

Af Caspar Miller, 22. oktober 2024

Dette er fjerde artikel i serien om de syv guiding principles i ITIL, denne gang om at skabe flow.

De første artikler i serien kan du læse her.

1. ”Focus on value” - Hvad betyder det i praksis?

2. Start where you are!

3. Progress iteratively with feedback

 

Den første artikel i denne serie om princippet "Focus on value" nævner værdiperspektivet på Lean, hvor næste skridt efter fokus på kundeværdi netop er at indrette arbejdet i værdistrømme på tværs af organisatoriske skel. Som også indledningsvis nævnt hænger principperne i ITIL tæt sammen med tilsvarende principper i andre metoder, herunder ikke mindst Lean, og "Collaborate and promote visibility" er muligvis det princip, der lægger sig tættest op ad netop Lean.

Samtidig er dette princip muligvis det sværeste at efterleve. Det kan der givetvis være mange forskellige årsager til, men en hyppigt forekommende årsag er i min egen erfaring det måle- og rapporteringssystem, mange organisationer har indført til at styre driften. Binder man arbejdet op på målsætninger for aktiviteter, der ikke hænger sammen end-to-end, risikerer man en række suboptimerede aktiviteter, der hænger sammen som perler på en snor, men efterstræber hver sit sæt af målinger og mål og ikke fokuserer på det outcome, der i sidste ende skaber kundeværdien.

Der kunne skrives (og er allerede skrevet) reoler af bøger om de mange gevinster ved at ensrette og standardisere arbejdet og skabe bedre sammenhængskraft på tværs—at skabe flow (svarende til det tredje trin i værdiperspektivet på Lean)—men ITIL fremhæver specifikt tre teknikker, der er vigtige i denne sammenhæng: at begrænse igangværende arbejde (work in progress), at udnytte eller udvide flaskehalse, og at begrænse spild. Disse tre teknikker er alle helt centrale i netop Lean-filosofien.

 

Teknikker til at skabe flow

At begrænse igangværende arbejde er i sig selv en måde at reducere spild, og meningen er at fokusere på at gøre færre ting ad gangen, men til gengæld gøre dem færdige, inden man går i gang med noget nyt—grundlaget for alle agile metoder (Scrum, DevOps, SAFe etc.), og akkurat som i princippet fra den forrige artikel, "Progress iteratively with feedback". Et eksempel herpå kunne være en servicedesk, hvor man ændrer praksis fra at uddelegere ("despatche") alle sager, så snart de kommer ind, til at lade de enkelte medarbejdere plukke sager efter klassificering, kategori, prioritet etc. Med andre ord går man fra push til pull (som meget passende stemmer overens med Lean-værdiperspektivets fjerde trin).

Flaskehalse, eller constraints, opstår de steder i et flow, hvor kapaciteten eller båndbredden pludselig snævrer ind, og der dermed kan slippe mindre arbejde, materiale el.lign. igennem dette punkt sammenlignet med resten af systemet. Forsøger man at presse mere arbejde gennem systemet, vil det resultere i ophobning af lokale lagre (hvilket også er spild), hvor produkter, komponenter, sager tilsvarende arbejdsenheder (flow units) venter på at komme gennem flaskehalsen. Løsningen på denne udfordring er at udvide indsnævringen, eller at ændre på indretningen af arbejdet på en måde, så kapaciteten øges lokalt. Eksempelvis kunne man oplære flere medarbejdere i at kunne behandle flere forskellige sagstyper, eller man kunne opsplitte et stykke arbejde eller en opgave på måde, så den knappe ressource udfører en mindre del og dermed undgår at skabe en flaskehals. En flaskehals er det svageste led i kæden, og det vil i sagens natur aldrig være muligt at fjerne alle flaskehalse; udvider man en indsnævring, vil det per definition føre til et nyt led, der nu er det svageste. (Den flittige læser vil bemærke, at dette fører til Lean-værdiperspektivets femte og sidste trin, nemlig at stræbe efter perfektion—et mål, der aldrig kan opnås, men ikke desto mindre er værd at efterstræbe i alt, hvad man foretager sig.)

Hvis alle aktiviteter, der skaber et resultat (outcome) for en kunde, er værdiskabende, så må alt andet være spild. Det er værdiperspektivet. Den tredje teknik, at reducere eller eliminere spild, er et udtryk for det omvendte synspunkt; hvis man fjerner alle former for spild, må de aktiviteter, der er tilbage, være værdiskabende. Dette synspunkt fremhæves især af Taiichi Ohno, en af de store tænkere bag Lean-filosofien, og der refereres ofte til 7 (eller nogle gange 8) spildtyper[i] efter den tankegang, at hvis vi bare adresserer alle disse spildtyper, så er der ikke mere at komme efter. Desværre er dette reduktionistiske syn på spildtyper for unuanceret, og det vigtige er ikke, om der er 7 eller 8 spildtyper, eller om man har adresseret dem alle, men ganske simpelt hele tiden at forholde sig til, om en given aktivitet fører til en eller anden form for spild, og så undlade at udføre den. Viderefører vi eksemplet fra ovenfor med en servicedesk, der går fra push til pull, kunne en spild-aktivitet være at tildele sager til andre, når sagen lige så godt kan ligge i en bunke og blive plukket af rette vedkommende i rette tid.

 

[i] Spild inddeles ofte i typer såsom transport, lager, bevægelse, ventetid, overprocessering, overproduktion og fejl, nogle gange suppleret med spildt menneskeligt potentiale. Ohno definerer ikke disse spildtyper eksplicit, men nævner dem som eksempler på aktiviteter, der ikke er værdiskabende.

 

Hvad kan vi så gøre ved det?

Indrettelsen af arbejdet i værdistrømme sker naturligvis i flere abstraktionsniveauer. På øverste niveau handler det om hele virksomhedens hovedaktiviteter, og hvordan den indgår i et samspil med sin omverden. Et typisk eksempel er order-to-cash, altså den tid, der går fra virksomheden modtager en ordre, til kunden betaler for varen eller servicen. Det er i al sin enkelhed Ohno's beskrivelse af, hvad Lean er: "All we are doing is looking at the time line, from the moment the customer gives us an order to the point when we collect the cash. And we are reducing the time line by reducing the non-value adding wastes."

På lavere abstraktionsniveau kan der være tale om eksempelvis den måde, hvorpå en servicedesk modtager henvendelser om fejl og bestillinger (incidents og service requests), håndterer dem, og løbende forbedrer fejlretning eller ordreopfyldelse. Det er altså hele værdistrømmen for at løse en fejl; opdage et symptom, finde årsagen, rette fejlen og sikre mod gentagelse. Går vi endnu et niveau dybere og kigger på procedureniveau, bevæger vi os ind i den enkelte proces for eksempelvis afhjælpning af et symptom; altså ikke hele værdistrømmen, men specifikt hvad vi gør for at hjælpe brugeren videre i mellemtiden.

En hyppig årsag til manglende helhedssyn på flowet i arbejdet fra ende til anden er som indledningsvis nævnt målinger, mål og rapportering. Måler vi eksempelvis servicedesk på, hvor hurtigt de kan tage telefonen, eller om de lukker sagerne rettidigt, risikerer vi hurtigt at miste det forkromede overblik. Målinger og mål driver adfærd, og især mål for aktiviteter fører ofte til et uhensigtsmæssigt fokus på at opnå målet i sig selv, frem for at se på resultatskabelsen i sidste ende.

Derfor er det af afgørende betydning, at man nøje overvejer dels hvad man gerne vil måle på, og dels hvad de afledte effekter kan være af, hvad man måler på—og i særdeleshed sætter mål for. Indretter vi vores målesystemer til at skabe samarbejde på tværs af organisatoriske skel og uden hensyntagen til intern konkurrence eller placering af skyld og ansvar, kan vi skabe optimale vilkår for kundeværdi. Hvis vi omvendt suboptimerer med uhensigtsmæssige målinger og mål, risikerer vi at stikke os selv en kæp i hjulet og drukne i interne magtkampe.