Sådan visualiserer du en forretningsproces

Sådan fungerer det

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

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.