Sådan laver du et SOP-flowchart

Kort fortalt

• Én procedure pr. diagram. To startpunkter betyder to SOP'er.
• Trinene er nummererede og korte nok til at blive læst højt under pres.
• Hver beslutning angiver sine kriterier, eller navngiver den rolle, der afgør den.
• Eskalerings- og genåbningsveje er tegnet, ikke underforstået.
• En SOP er først styret, når den har en godkendt version, en ejer og en revisionsdato.

Det, der adskiller en SOP fra et procesdiagram

Et SOP-flowchart læses i en helt anden situation end et procesdiagram. Et procesdiagram læses på et møde; en SOP læses klokken to om natten af en, der aldrig har håndteret det her før og har brug for at vide, hvad næste skridt er. Den forskel styrer hvert eneste designvalg: korte trin, nummererede så de kan læses op i telefonen, beslutninger med kriterierne skrevet på, og ingen gren overladt til skøn, medmindre en navngiven rolle træffer afgørelsen.

Afgræns den til én procedure. Den hyppigste fejl i SOP-flowcharts er, at de i virkeligheden er tre procedurer, der deler en side, og så bliver de så lange, at folk holder op med at åbne dem. Har jeres diagram to startpunkter, eller et afsnit der kun gælder ét team, så del det op. Krydshenvisninger mellem SOP'er koster ingenting; en SOP på tyve sider, som ingen læser, koster.

Den anden halvdel af en SOP er styring. En procedure uden en registreret godkendelse, et versionsnummer og en revisionsdato er et forslag, og i et reguleret miljø er en SOP uden versionsstyring i sig selv en afvigelse. Eksemplet herunder er en procedure for hændelseshåndtering med en gren for større hændelser, en eskalering ved SLA-brud og en genåbningssløjfe, samt proceduretekst genereret fra de samme rækker.

En SOP som flowchart

En procedure for hændelseshåndtering, bygget op i fire etaper. Den nummererede proceduretekst nedenunder kommer fra de samme rækker som diagrammet.

1. Registrer, før du diagnosticerer

   Opdaget, registreret med konsekvens, kategoriseret og prioriteret. En SOP begynder dér, hvor den, der læser den, rent faktisk står, og ved hændelser er det, før nogen ved, hvad der er galt. Derfor kommer registreringen før diagnosen.

2. Forgreningen ved vurderingen af alvor

   "Større hændelse?" deler proceduren: erklær, åbn krisebro og orienter interessenter, eller fortsæt med indledende diagnose i første linje. Kriterierne for den vurdering hører hjemme på selve beslutningen, fordi den træffes under tidspres af den, der har vagten.

3. Eskaler efter en regel, ikke en fornemmelse

   Undersøgelse i anden linje, et eksplicit SLA-tjek med en gren for eskalering ved brud, og derefter genopretning bekræftet med brugeren. Læg mærke til genåbningsvejen: en løsning, brugeren ikke bekræfter, går tilbage til diagnosen i stedet for at blive lukket i håbet om, at den holder.

4. Luk sagen, og før læringen tilbage

   Løsningsnotat og derefter en beslutning om, hvorvidt årsagen stadig er ukendt: er den det, oprettes en problemsag. En SOP, der slutter ved "servicen er genoprettet", mister netop det output, der forhindrer, at den samme hændelse sker igen.

Sådan fungerer det

1. Afgræns den til én procedure

   Skriv udløseren i én sætning: "en hændelse opdages eller anmeldes". Kræver udløseren et "eller", der dækker en reelt anden situation, er det en SOP nummer to. At holde hvert diagram til én procedure er det, der holder det kort nok til at blive åbnet i en akut situation.

2. Skriv trinene som instruktioner

   Udsagnsord først, én handling ad gangen, henvendt til den, der udfører den: "Registrer hændelse med konsekvens", ikke "Hændelsen registreres". Passive formuleringer skjuler ejeren, og en SOP, hvis trin ingen ejer har, er grunden til, at to personer udfører det samme trin, og en tredje ingen.

3. Skriv kriterierne på beslutningerne

   "Større hændelse?" har brug for en definition ved siden af sig: antal berørte brugere, serviceniveau, økonomisk konsekvens, hvad end I bruger. Brug trinnets kommentarfelt til reglen. Beslutninger uden kriterier træffes forskelligt af hver eneste person, der læser diagrammet, og så betyder ordet "standard" ingenting.

4. Tilføj eskalerings- og genåbningsvejene

   Tegn, hvad der sker, når SLA'en er ved at blive brudt, når løsningen ikke holder, og når den, der plejer at gøre det her, ikke er til stede. Det er netop de veje, man slår op i en SOP for. Hver af dem fører enten tilbage til flowet eller ender i sit eget slutpunkt.

5. Fordel banerne, og gennemgå den med vagtholdet

   Placer hvert trin i banen for den rolle, der udfører det (servicedesk, incident manager, anden linje), og læs den igennem med dem, der skal bruge den. Spørg dem, hvor de ville tøve. Hver tøven er et trin, der mangler enten et kriterium eller en opdeling.

6. Godkend den, versioner den, og sæt en revision

   Send diagrammet gennem godkendelsesforløbet, så den gældende version har en godkender og en dato, og sæt en revisionsudløser på: efter enhver større hændelse og mindst én gang om året. I QueryChart ligger godkendelsen og ændringshistorikken sammen med diagrammet, så "hvilken version gjaldt i marts" har et svar.

Faldgruber du skal undgå

• En SOP, der reelt er tre

  To startpunkter, eller et afsnit der kun gælder ét team, betyder, at diagrammet bør deles op. Længden er det, der forhindrer, at en SOP bliver åbnet i netop det øjeblik, den gælder.

• Skøn uden kriterier

  "Eskaler hvis det er alvorligt" er ikke en standardprocedure. Skriv grænsen ned, eller navngiv den rolle, der afgør det: det er de eneste to måder at gøre vurderingen gentagelig på.

• Ingen fejlveje

  Den lykkelige sti er den, folk allerede kender. En SOP, der udelader SLA-bruddet, genåbningen og den fraværende ejer, er tavs præcis dér, hvor der var brug for den.

• Uden versionsstyring

  Uden en godkendt version og en ændringshistorik kan ingen vise, hvilken procedure der var gældende, da noget gik galt, og i et reguleret miljø er det i sig selv en afvigelse.

Lav dit eget SOP-flowchart

Åbn eksemplet med hændelseshåndtering som dit eget diagram, eller start på en tom side og skriv jeres egen procedure ind i rækkerne.

Lav dit eget SOP-flowchart

Relaterede guides

• Sådan laver du en proces for dokumentstyring
• Sådan versionsstyrer du en SOP
• Sådan laver du en proces for ændringsstyring (change control)

Ofte stillede spørgsmål

Hvad er forskellen på en SOP og et procesdiagram?

En SOP er en styret instruktion i at udføre en bestemt opgave: nummereret, med en ejer, godkendt, versionsstyret og skrevet til den, der udfører arbejdet. Et procesdiagram er et billede af, hvordan arbejdet flyder, ofte på tværs af flere roller, og det kan være beskrivende frem for bindende. Tegner du en SOP som flowchart, får du begge dele (et diagrams læsbarhed med en procedures styringsegenskaber), så længe godkendelsen og versionshistorikken følger med.

Skal en SOP være et flowchart eller en tekst?

Begge dele, fra én kilde. Et flowchart er hurtigere at følge under pres og gør huller i forgreningerne synlige; teksten rummer de detaljer, et diagram ikke kan bære, som præcise feltværdier eller sikkerhedsadvarsler. Fejlen er at holde dem som to adskilte dokumenter, for så skrider de fra hinanden. Generér procedureteksten fra de samme rækker som diagrammet, så en ændring det ene sted er en ændring begge steder.

Hvor langt bør et SOP-flowchart være?

Kort nok til at fylde én skærm i en læsbar størrelse: i praksis femten til femogtyve trin. Er der flere, så find en naturlig overlevering og del det op i to procedurer, der henviser til hinanden. Lange SOP'er er ikke mere grundige; de bliver bare sjældnere åbnet, og en SOP, ingen åbner, giver præcis lige så meget styring som slet ingen SOP.

Hvem godkender en SOP?

Procesejeren, plus den, der er ansvarlig for den risiko, proceduren styrer: ofte kvalitet, compliance eller serviceejeren. Proceduremæssigt er det afgørende, at godkendelsen er registreret på en bestemt version med navn og dato, så der ikke er tvivl om, hvilken tekst der var gældende på et givent tidspunkt tilbage i tiden. Netop den registrering er det, der gør et dokument til et styret dokument.