Sådan laver du et tværfunktionelt flowchart

Sådan fungerer det

1. Skriv de funktioner ned, der rører arbejdet

   Notér hver funktion, der udfører et trin, inklusive kunder, leverandører og fragtførere. Slå derefter alt sammen, der i virkeligheden er én ansvarlig enhed. Sigt efter fire til seks baner; med flere bliver krydsningerne umulige at følge visuelt.

2. Fastlæg yderpunkterne, før du tegner midten

   Navngiv den hændelse, der starter processen, og den tilstand, der afslutter den, og tjek, at begge ligger inden for de funktioner, du har listet. Tværfunktionelle diagrammer breder sig hurtigere end nogen anden type, fordi hver funktion har sin egen mening om, hvor processen egentlig begynder.

3. Læg trinnene ud som rækker, og tildel banerne

   Skriv hvert trin ind i en række, forbind dem via kolonnen »Linje til«, og sæt derefter kolonnen Lodret bane til den funktion, der udfører trinnet, og Vandret bane til fasen. Layoutet følger af banerne i stedet for af trukne kasser, så det at flytte et trin til en anden funktion er én celleredigering.

4. Notér hver eneste krydsning

   For hver streg, der forlader én bane og går ind i en anden, skal du i trinnets kommentarfelt skrive, hvordan den modtagende funktion får det at vide: en statusændring i et system, en mail, en fælles kø, en daglig rapport. Hvor svaret er »de kigger selv efter«, har du fundet en kø uden ejer.

5. Tæl krydsningerne, og udfordr dem

   Læg antallet af baneskift sammen. En proces på femten trin, der krydser baner ni gange, er ikke et tegneproblem, men et designproblem — og løsningen er som regel at flytte et trin frem for at tegne det om. Tværfunktionelle diagrammer er den eneste type, der gør det tal synligt.

6. Valider med hver funktion for sig

   Gå diagrammet igennem med hver baneejer alene, før du viser det til alle samlet. Folk retter frit i deres egen bane og forsvarer den i en gruppe, så du får både et mere retvisende diagram og et markant kortere møde.

Ofte stillede spørgsmål

Hvad er et tværfunktionelt flowchart?

Et procesdiagram delt op i baner — én pr. funktion eller rolle — så hvert trin ligger hos den, der udfører det, og hver krydsning mellem baner er en synlig overlevering. Det kaldes også et deployment-flowchart eller i daglig tale et swimlane-diagram. Formålet er ikke pænere dokumentation, men en helt bestemt diagnose: at vise hvor arbejdet skifter hænder, for det er dér, det meste driftsforsinkelse og det meste tabte arbejde opstår.

Hvordan adskiller det sig fra et swimlane-diagram?

I praksis er det det samme, og begreberne bruges i flæng. Hvor folk skelner, handler det om vægtning: swimlane beskriver notationen, tværfunktionel beskriver hensigten. Hvis det betyder noget i jeres organisation, så brug det ord, jeres modtagere allerede bruger — at diskutere begrebet er en dårlig erstatning for at tælle overleveringerne.

Skal leverandører og kunder have deres egen bane?

Ja, hver gang processen venter på dem. Et kreditcheck, der går i stå, fordi en kunde ikke har returneret en blanket, er en del af jeres gennemløbstid, uanset om I har tegnet den. At give eksterne parter en bane gør det også synligt, hvor stor en del af den samlede tid der reelt ligger uden for jeres kontrol, og det ændrer, hvor det kan betale sig at bruge kræfterne på forbedring.

Hvor mange baner er for mange?

Over cirka seks overlapper krydsningerne så meget, at det kræver reel koncentration at følge en enkelt vej, og diagrammet holder op med at kunne bruges på det møde, det blev tegnet til. Det siger noget om processen frem for om tegningen: enten er flere baner i virkeligheden én ansvarlig enhed, eller også spænder afgrænsningen over to processer, som bør deles ved en overlevering og henvise til hinanden.