Sådan laver du et procesdiagram
Sådan laver du et procesdiagram: fastlæg trigger og sluttilstand, skriv én handling pr. kasse, lav hvert 'hvis' om til en navngiven beslutning, og luk hver gren. Med et gennemarbejdet eksempel.
Sådan fungerer det
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.
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.
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.
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.
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.
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.
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.