Sådan laver du et procesdiagram

Kort fortalt

• Fastlæg trigger og målstreg først; alt andet er midten.
• Én handling pr. kasse, med udsagnsordet først: 'Registrér faktura i kreditorsystemet', ikke 'Fakturering'.
• Hver beslutning er et spørgsmål, og hver udgang fra den har en tekst.
• Hver gren kobler sig på flowet igen eller ender i sin egen terminator: ingen linjer, der stopper i den blå luft.
• Undtagelsesvejen er den del, der gør diagrammet umagen værd.

Det, der gør et flowchart til et flowchart

De fleste første forsøg på et procesdiagram er slet ikke flowcharts. De er en række rektangler forbundet af pile, som beskriver den udgave af processen, hvor intet går galt. Den tegning er en tjekliste med ekstra trin, og det er derfor, så mange procesdiagrammer bliver lavet én gang, printet og aldrig set på igen: alle kender i forvejen den lykkelige sti. Værdien ligger i det, diagrammet siger om alle de andre stier.

Et procesdiagram, der virker, har en lille og streng grammatik. Én start. Én handling pr. kasse, formuleret med udsagnsordet først, så det er tydeligt, hvem der gør hvad. En beslutning tegnet som et spørgsmål med tekst på hver udgang, så læseren kan se, hvilken vej der gælder for netop dem. Og hver gren kobler sig enten på hovedforløbet igen eller ender i sin egen terminator: for en linje, der stopper i den blå luft, betyder, at ingen ved, hvad der så sker, og det er præcis den situation, diagrammet skulle løse.

Eksemplet herunder er en rigtig fakturagodkendelse, bygget op i fem trin. Hold øje med, hvad der sker ved hvert af dem: diagrammet bliver først brugbart, når undtagelserne dukker op: dubletfakturaen, prisen der ikke stemmer med indkøbsordren, afklaringen der går tilbage til leverandøren og kobler sig på flowet igen længere oppe. De tre grene er hele grunden til, at diagrammet er mere værd end tjeklisten.

Se et procesdiagram blive bygget

Fem trin i et rigtigt fakturagodkendelsesflow. Klik dig igennem: hvert trin tilføjer den næste del af grammatikken.

1. Én trigger, ét første trin

   Ethvert flowchart starter med præcis én Start-figur, og den navngiver en begivenhed frem for en aktivitet: at en faktura ankommer, ikke 'fakturabehandling'. Har dit diagram to starter, tegner du to processer.

2. Stil det første spørgsmål

   Romben er et spørgsmål ('Dubletfaktura?'), og begge udgange har tekst. Læg mærke til, at ja-grenen ikke fortoner sig: den ender i sin egen terminator, fordi det at blokere en dublet er en legitim afslutning på processen og ikke en tegning, der aldrig blev færdig.

3. Del kun de veje, der reelt er forskellige

   En faktura med ordrereference får et trevejsmatch mod indkøbsordren og varemodtagelsen; en faktura uden ordre bliver i stedet konteret på et omkostningssted. To grene, fordi arbejdet reelt er forskelligt, ikke fordi nogen gerne ville have diagrammet til at se grundigt ud.

4. Send undtagelsen tilbage ind i flowet

   En prisafvigelse rejser en afklaring hos leverandøren, og når den er løst, går flowet ind igen ved ordrekontrollen i stedet for at starte forfra. Løkker tilbage ind midt i en proces er helt normale; det unormale er en undtagelsesgren, der stille forsvinder.

5. Slut på en tilstand, ikke en aktivitet

   Godkendelsen dirigeres efter beløb, en medunderskrift kræves over grænsen, og diagrammet slutter ved 'Leverandør betalt og advis sendt': en tilstand, du kan efterprøve. 'Behandl betaling' ville være en aktivitet, og en aktivitet er aldrig en målstreg.

Sådan fungerer det

1. Skriv trigger og målstreg ned først

   Før nogen kasser: hvilken begivenhed starter processen, og hvilken tilstand betyder, at den er færdig? De to sætninger fastlægger afgrænsningen, og de fleste diskussioner om et procesdiagram viser sig at handle om grænserne frem for om trinnene. Skriv målstregen som en tilstand ('leverandøren er betalt'), ikke som en aktivitet.

2. List trinnene som rækker, ikke som en tegning

   Opret et nyt diagram i QueryChart, og skriv trinnene ind i kolonnen 'Box text', ét pr. række. Lad være med at placere noget. Det er hurtigere at diskutere en liste end et diagram, og layoutet bliver genereret for dig: appen står for rutelægningen, så intet af det, du gør i hånden her, overlever alligevel.

3. Forbind rækkerne med numre

   Kolonnen 'Line to' tager rækkenummeret på det næste trin, så række 2, der peger på 3, tegner pilen. Skriv flere numre adskilt af komma, hvor et trin fører videre til mere end ét sted. Det er hele historien om at forbinde et flowchart i QueryChart, og det er derfor, diagrammet kan rettes af en, der aldrig har brugt et tegneværktøj.

4. Lav hvert 'hvis' i dine noter om til en beslutning

   Overalt hvor dine noter siger 'hvis', 'medmindre' eller 'afhængigt af', skal du sætte den rækkes 'Shape' til Decision og skrive etiketten om til et spørgsmål. Sæt derefter svarene i kolonnen 'Line text' ('Ja', 'Nej', 'Over 50.000 kr.'), så hver udgang fortæller, hvilket tilfælde den dækker. En gaffel uden tekst er den klart hyppigste grund til, at et flowchart ikke kan følges.

5. Tegn undtagelsesvejen

   Tag hver beslutnings ulykkelige gren, og følg den frem til en rigtig konklusion: løkker den tilbage til et tidligere trin, overdrager den til en anden, eller slutter den? Giv den en terminatorfigur, når den slutter. Det er den del, folk springer over, og det er den del, læserne faktisk har brug for: ingen slår op i et procesdiagram for at finde ud af, hvad der sker, når alt går godt.

6. Gå det igennem med en, der udfører arbejdet

   Læs diagrammet højt for den, der kører processen, og spørg, hvor det er forkert. Regn med at finde ét trin, der i virkeligheden er tre, og én gren, ingen nogensinde har skrevet ned. Ret det i rækkerne, del diagrammet, og læg en godkendelse på det, så den version, folk kigger på, er den aftalte og ikke et skærmbillede i en andens præsentation.

Faldgruber du skal undgå

• Beslutninger formuleret som udsagn

  'Ledergodkendelse' er et trin; 'Godkender lederen?' er en beslutning. Læses en rombe ikke som et spørgsmål, kan de to linjer ud af den ikke få fornuftig tekst, og læseren må gætte, hvilken der gælder.

• Grene, der stopper i den blå luft

  Hver linje skal ende et sted: enten i et nyt trin eller i en terminator. En gren, der bare hører op, er diagrammets måde at indrømme, at ingen ved, hvad der sker i det tilfælde, hvilket er værd at vide, men bør løses frem for tegnes.

• Én kasse, der gør tre ting

  'Gennemgå og godkend og arkivér' er tre kasser med to skjulte fejlpunkter imellem sig. Skal et trins etiket bruge et 'og', er det som regel mere end ét trin, og den overlevering, du ikke kan se, er dér, ventetiden bor.

• At tegne den proces, man gerne ville have

  Kortlæg as-is-processen først, undtagelser og nødløsninger inklusive, også når det er pinligt. Et to-be-diagram, tegnet før nogen er enige om, hvad der sker i dag, er et forslag og bør mærkes som sådan.

Lav dit eget procesdiagram

Start fra eksemplet med fakturagodkendelse ovenfor, eller ryd det og skriv dine egne trin ind i rækkerne.

Lav dit eget procesdiagram

Relaterede guides

• Sådan laver du et swimlane-diagram
• Sådan kortlægger du overleveringer i en proces
• Sådan forbedrer du en forretningsproces

Ofte stillede spørgsmål

Hvilke figurer har jeg brug for i et procesdiagram?

Fire bærer næsten alt: en terminator til starten og til hver sluttilstand, et rektangel til en handling, en rombe til en beslutning og en dokumentfigur til et trin, der frembringer en registrering: en underskrevet blanket, en rapport, en logget hændelse. QueryChart har desuden Reject- og Success-terminatorer, hvilket er praktisk, fordi et diagram typisk har mere end én måde at slutte på, og forskellige farver gør de ulykkelige afslutninger synlige med det samme.

Hvor detaljeret skal et procesdiagram være?

Detaljeret nok til, at en, der ikke selv udfører arbejdet, kan følge det, og ikke mere. En brugbar test: kan et trin overdrages til en anden afdeling uden yderligere forklaring, er det én kasse. Tager det et helt afsnit at forklare, er det formentlig en delproces, der fortjener sit eget diagram med et link fra dette. Femten til femogtyve kasser er det interval, hvor de fleste driftsprocesser stadig kan læses på én skærm.

Hvad er forskellen på et procesdiagram og et proceskort?

Et flowchart viser rækkefølge og logik: hvad der sker, i hvilken orden og med hvilke beslutninger. Et proceskort lægger kontekst rundt om den rækkefølge: hvem der ejer hvert trin, hvilket system det sker i, hvad der går ind, og hvad der kommer ud. I praksis handler forskellen mest om baner: i det øjeblik du deler flowet op efter ejer, har du et proceskort, og det er som regel den udgave, der er værd at have for alt, der krydser en afdelingsgrænse.

Skal beslutninger altid være ja eller nej?

Nej, men de skal være udtømmende og gensidigt udelukkende. En tredeling på ændringstype (standard, normal, akut) er helt fin, så længe hver anmodning lander i præcis én af dem. Det, der ødelægger et diagram, er en beslutning, hvis navngivne udgange ikke dækker alle tilfælde, for den læser, hvis situation mangler, har ingen steder at gå hen og opfinder sin egen vej.