Sådan visualiserer du en forretningsproces
Sådan visualiserer du en forretningsproces: vælg den visning, der besvarer dit spørgsmål (rækkefølge, ejerskab, tid eller undtagelser) og byg den ud fra én kilde i stedet for at tegne fire diagrammer.
At visualisere en forretningsproces vil sige at vælge den visning, der besvarer det spørgsmål, der bliver stillet: rækkefølge, ejerskab, beslutningslogik eller hvor arbejdet går i stå.
Kort fortalt
- Spørg, hvilket spørgsmål diagrammet skal besvare, før I vælger format.
- Rækkefølge → flowchart. Ejerskab → swimlanes. Fejlveje → beslutninger tegnet helt til ende.
- Tid hører hjemme på overleveringerne, ikke i et diagram for sig.
- Hold én kilde og lav visninger ud fra den; fire diagrammer bliver til fire sandheder.
- Skal et diagram bruge en signaturforklaring til at forklare sin egen signaturforklaring, bærer det for meget.
Vælg visningen ud fra spørgsmålet
»Kan vi få et diagram over det her?« er aldrig rigtigt en anmodning om et diagram. Det er en anmodning om et svar, og det første brugbare træk er at finde ud af hvilket: om rækkefølgen er rigtig, hvem der er ansvarlig, hvor tiden går, eller hvad der sker, når noget fejler. Hvert af de spørgsmål kræver sin egen visualisering, og at producere den forkerte er præcis sådan, organisationer ender med en væg af diagrammer, ingen slår op i.
Spørgsmål om rækkefølge kræver et flowchart. Spørgsmål om ejerskab kræver baner. Spørgsmål om undtagelser kræver, at beslutningerne og deres ulykkelige veje er tegnet helt til ende. Spørgsmål om tid kræver noter på overleveringerne, og slet ikke et nyt diagram. Fejlen er at svare på alle fire på én gang: et diagram, der bærer rækkefølge, ejere, systemer, tider og kontrolreferencer, er teknisk komplet og praktisk ulæseligt.
Den gode nyhed er, at det er visninger af én ting og ikke fire dokumenter. Eksemplet herunder er en kvalitetskontrolproces (fra kontrol over test til frigivelse eller afvisning) og den rummer en tredelt forgrening på kontrolpunktet, en undersøgelse af afvigende resultater og en afgørelse i afvigelsesudvalget med tre udfald. Ét diagram, men I kan læse det for rækkefølge, for ejerskab eller for, hvor en batch kan gå i stå.
Ét diagram, flere læsninger
En kvalitetskontrolproces. Læs den for rækkefølge, derefter for ejerskab, og til sidst for, hvor en batch kan gå i stå.
Rækkefølge: én indgang, tre veje ind
Modtagelse, kontrol under produktion og slutkontrol løber alle sammen i det samme trin om prøvetagning. At tegne tre indgangsveje ind i ét forløb er mere ærligt end tre næsten ens diagrammer, og det gør den fælles del tydelig med det samme.
Ejerskab: hvem må frigive en batch
Kontrollen ligger hos kvalitetskontrollanten, testen hos laboratoriet, frigivelsen hos kvalitetschefen og bogføringen på lageret. Fire baner på fem trin: det er den læsning, der besvarer spørgsmålet »hvem skriver under«.
Fejl: hvor en batch reelt går i stå
Et resultat uden for specifikation åbner en undersøgelse, en laboratoriefejl sender sagen tilbage til fornyet test, og en reel fejl udløser en afvigelsesrapport og karantæne. Det er den læsning, der forklarer, hvorfor forsendelsen er forsinket.
Udfald: tre veje ud af karantænen
Afgørelsen i afvigelsesudvalget deler sig i omarbejdning, dispensation eller kassation, hver med sin egen destination. En visualisering, der kun viser bestået og fejlet, skjuler netop den beslutning, der koster flest penge.
Sådan fungerer det
Skriv spørgsmålet ned først
Én sætning: hvad skal man kunne svare på efter at have set på det her? »Hvor bruger en ordre sin tid?« og »hvem godkender frigivelsen af en batch?« giver to forskellige diagrammer, og at stille spørgsmålet først er dét, der forhindrer jer i at lave dem begge og tilfredsstille ingen af delene.
Vælg den mindste visning, der besvarer det
Spørgsmål om rækkefølge har ikke brug for baner. Spørgsmål om ejerskab har brug for baner, men ikke for tider. Lad være med at tilføje en dimension, bare fordi værktøjet kan: hvert ekstra lag koster den opmærksomhed hos læseren, som svaret havde brug for.
Byg det som rækker, så visningerne bliver billige
I QueryChart er diagrammet en tabel: trin, forbindelser, figurer og to banekolonner. At tilføje eller fjerne ejerskabsdimensionen er en redigering af en kolonne og ikke en ny tegning, og det er dét, der gør en visning nummer to til en fornuftig idé frem for et projekt.
Sæt tiden på overleveringerne
Når spørgsmålet handler om varighed, så notér tallene på krydsningerne mellem banerne frem for på hvert enkelt trin. Ventetid mellem teams fylder mere end selve arbejdstiden i næsten enhver forretningsproces, og at sætte tallene dér, hvor køerne er, gør det synligt med det samme.
Vis undtagelserne, eller sig, at I ikke har gjort det
Tegner I bevidst kun den lykkelige sti, til et undervisningsmateriale, for eksempel, så skriv det på. Et umærket diagram over den lykkelige sti bliver senere brugt, som om det var processen, som regel af en, der er ved at beslutte en bemanding.
Del ét link, ikke fem eksporter
Del diagrammet i stedet for at indsætte et billede i en præsentation. Eksporterede billeder er præcis den mekanisme, der gør fire visninger til fire versioner, hver især frosset den dag, nogen havde brug for den.
Faldgruber du skal undgå
At svare på fire spørgsmål på én gang
Et diagram, der bærer rækkefølge, ejere, systemer, tider og kontrolreferencer, er komplet og ulæseligt. Del det op efter spørgsmål, ud fra én kilde.
Diagrammer som pynt
Et procesbillede i en præsentation, som ingen kunne handle på, er et stockfoto med rektangler. Besvarer det ikke et spørgsmål, behøver det ikke at findes.
Farver med en betydning, ingen har fået at vide
Betyder rød noget, så skriv det på diagrammet. Farvekonventioner bor i forfatterens hoved og dør der.
Eksporter i stedet for links
I samme øjeblik et diagram bliver til en PNG i en præsentation, holder det op med at følge virkeligheden, og det cirkulerer stadig et år senere.
Visualisér din egen proces
Åbn kvalitetskontrol-eksemplet som dit eget diagram, og skær det derefter ned til den visning, der besvarer dit spørgsmål.
Relaterede guides
Ofte stillede spørgsmål
Hvad er den bedste måde at visualisere en forretningsproces på?
Start ved spørgsmålet. Handler svaret om rækkefølge, er et flowchart nok. Handler det om ansvar eller overleveringer, så brug swimlanes. Handler det om fejlveje, så tegn hver beslutnings ulykkelige vej frem til en rigtig afslutning. Handler det om tid, så notér tallene på overleveringerne frem for at tegne noget nyt. Den bedste visualisering er den mindste, der besvarer det stillede spørgsmål, bygget på en kilde, I kan lave andre visninger ud fra senere.
Skal jeg bruge BPMN til at visualisere en proces?
Kun hvis noget længere nede i kæden læser det. BPMN's præcision (typede hændelser, gateways, beskedforløb) er værdifuld, når en workflow-motor eller et integrationsprojekt skal læse modellen. Til et diagram, mennesker skal læse, er den præcision en skat: notationen skal læres, og læsere, der ikke har lært den, gætter. De fleste forretningsprocesser er bedre tjent med baner, almindelige figurer og navngivne beslutninger.
Hvordan laver jeg et procesdiagram, folk rent faktisk bruger?
Hold det på én skærm, besvar ét spørgsmål, og placer det dér, hvor arbejdet foregår, frem for i en dokumentationsmappe. Hold det derefter opdateret: grunden til, at procesdiagrammer ikke bliver brugt, er næsten aldrig, at de er svære at forstå: det er, at folk har lært, at diagrammet er forældet. Et diagram, der bliver rettet, når processen ændrer sig, bliver slået op i; et, der var perfekt i marts, gør ikke.
Hvor mange detaljer skal en procesvisualisering have?
Nok til at besvare spørgsmålet og ikke mere, i én ensartet detaljeringsgrad. Femten til femogtyve trin kan være på én skærm og hænge fast i læserens hoved. Er der reelt mere at sige, så link til en delproces i stedet for at skrue ned for skriftstørrelsen, et diagram, der skal zoomes for at kunne læses, er allerede holdt op med at være en visualisering.
