Sådan dokumenterer du en forretningsproces
Sådan dokumenterer du en proces, så den bliver ved med at være sand: en ejer pr. trin, nedskrevne beslutningsregler, versionsstyring og godkendelse samt en revisionsdato. Med et levende eksempel.
At dokumentere en proces vil sige at fastholde, hvad der sker, hvem der er ansvarlig for hvert trin, og hvad beslutningsreglerne er: i en form, der har én gældende version, en navngiven ejer og en revisionsdato.
Kort fortalt
- Én gældende version, som kan kendes som den gældende. Alt andet er kopier.
- Hvert trin har en ansvarlig rolle; hver beslutning har en regel og en grænseværdi.
- Skriv, hvor dokumentationen lander: hvilket system, hvilket register, hvilken registrering.
- Godkendelse med underskrift og dato er dét, der gør et dokument til et styret dokument.
- Sæt en revisionsdato, og revider efter alt, der går galt.
Vælg værktøj til dokumentation
Hvorfor procesdokumentation holder op med at blive troet på
Næsten alle organisationer har procesdokumentation. Meget lidt af den bliver der stolet på, og årsagen er sjældent skrivearbejdet. Den er, at ingen kan se, hvilken kopi der er den gældende. En procedure lever som et Word-dokument på et fællesdrev, et diagram i en andens præsentation og en wiki-side, der sidst blev opdateret for atten måneder siden, og alle tre har ret i hver sin ting. Arbejdet med at dokumentere en proces handler kun halvt om at skrive den ned; den anden halvdel er at gøre én version genkendelig som den aftalte.
Indholdstesten er enkel: kunne en, der aldrig har lavet det her arbejde, udføre det, og kunne en udefra se, om det blev fulgt? Det betyder, at hvert trin har en ejer, at hver beslutning angiver sin regel og sin grænseværdi i stedet for at sige »efter behov«, og at hvert trin, der producerer en registrering, siger, hvor den lander. »Kontroller bankoplysningerne« er en hensigt. »Ring leverandøren op på nummeret fra den underskrevne kontrakt (aldrig nummeret på fakturaen), og notér hvem der kontrollerede det, og hvornår« er en kontrol.
Eksemplet herunder er onboarding af leverandører. Læs procedureteksten under lærredet sammen med diagrammet: de er genereret ud fra de samme rækker, og det er hele pointen. Når diagrammet og den skrevne procedure er to dokumenter, skrider de fra hinanden, og forskellen er usynlig, indtil en auditor lægger dem side om side.
En dokumenteret proces: diagram og tekst
Onboarding af leverandører fordelt på fem baner. Procedureteksten under lærredet er genereret ud fra de samme rækker: to visninger, én kilde.
Notér udløseren og indgangen
En anmodning om ny leverandør og et dokumenteret tjek af, om en eksisterende leverandør allerede dækker behovet. Det er dokumentationen af indgangen, der forhindrer, at processen bliver sprunget ind i på midten, og det er netop sådan, ikke-godkendte leverandører ender i bogholderiet.
Navngiv kontrollerne og dem, der udfører dem
Kontraktvilkår hos Jura, kredit hos Økonomi, databeskyttelse hos Sikkerhed. Fire gennemgange, fire ejere, én bane til hver: en procedure, der blot siger, at »der udføres due diligence«, uden at nævne hvem der gør hvad, er ikke dokumentation, det er en overskrift.
Skriv beslutningsreglen ned
Risikoklassen afgør, hvor dyb gennemgangen bliver, og porten til due diligence har en eksplicit afvisningsvej. Når reglen og dens grænseværdi står på selve trinnet, kan beslutningen gentages af den, der er på vagt, i stedet for at afhænge af, hvem man spørger.
Dokumentér kontrollen: også sløjfen
Bankoplysninger verificeres via et opkald, og uverificerede oplysninger sendes tilbage til fornyet verifikation: betalingsopsætningen fortsætter ikke på en uverificeret konto. Kontroller, der kun findes som en sætning i en politik, bliver sprunget over; kontroller tegnet som en port med en sløjfe er synligt ufravigelige.
Sådan fungerer det
Beslut, hvad dokumentet skal bruges til
At oplære en ny kollega, at tilfredsstille en auditor og at afgøre uenigheder mellem teams kræver hver sit detaljeringsniveau. Skriv ned, hvilket af dem I er i gang med, for det afgør, hvor meget der skal med. Forsøger I på alle tre på én gang, får I et dokument, der er for langt at oplære efter og for vagt at revidere op imod.
Fang forløbet, før prosaen
Byg processen som et diagram først: trin som rækker, forbindelser via rækkenumre og en ejerbane pr. trin. Diagrammet tvinger hullerne frem i lyset: et trin uden ejer, en gren uden navn og en manglende undtagelse er alle synlige i et diagram og nemme at skjule i et afsnit.
Giv hvert trin en ejer og hver beslutning en regel
Sæt den ansvarlige rolle i trinnets bane og beslutningsreglen i dets kommentar: grænseværdien, kriterierne, hvem der må give en undtagelse. Erstat »efter behov« og »rettidigt« med tal, hvor I kan, og hvor I reelt ikke kan, så skriv, hvem der beslutter.
Skriv, hvor dokumentationen lander
For hvert trin, der producerer en registrering (en godkendelse, en underskrevet kontrakt, en linje i et register), skal I skrive, hvilket system der opbevarer den, og under hvilket navn. Det er forskellen på dokumentation, der overlever en audit-gennemgang, og dokumentation, der udløser en opfølgende anmodning.
Få det godkendt, ikke bare offentliggjort
Send det færdige diagram gennem QueryCharts godkendelsesflow, så den aktuelle version bærer en godkender, en underskrift og en dato. Det er dét, der gør det til et styret dokument frem for en fil: en godkendt version, en uforanderlig ændringshistorik og ingen tvivl om, hvilken kopi folk skal læse.
Sæt en revisionsdato og en udløser
Vælg en kadence (årligt er almindeligt, halvårligt for noget, der ændrer sig ofte), og tilføj en regel om, at processen revideres efter enhver hændelse, ethvert auditfund og enhver systemændring, der rører den. Dokumentation forfalder lydløst, og en dato på siden er det billigste værn mod det.
Faldgruber du skal undgå
To dokumenter, én proces
Et diagram i én fil og en skrevet procedure i en anden skrider fra hinanden, og ingen opdager det, før de bliver sammenlignet under pres. Hold én kilde, og generér visningerne ud fra den.
»Efter behov«
Vage forbehold flytter beslutningen fra dokumentet til den, der tilfældigvis er på vagt. Det er det stik modsatte af at dokumentere en proces. Skriv grænseværdien, eller skriv, hvem der beslutter.
Ingen navngiven ejer
Et dokument, alle kan redigere, og ingen ejer, er et dokument, ingen opdaterer. Ét navn, på siden.
Versionsstyring via filnavn
proces_v3_ENDELIG_opdateret2.docx er ikke versionsstyring; det er en arkæologisk udgravning. Brug et system, der kan fortælle jer, hvilken version der er godkendt, og hvad der blev ændret mellem revisionerne.
Dokumentér din egen proces
Åbn eksemplet med onboarding af leverandører som dit eget diagram, eller start på et tomt og byg forløbet op ud fra dine rækker.
Relaterede guides
Ofte stillede spørgsmål
Hvad er forskellen på et procesdokument og en SOP?
Et procesdokument beskriver, hvordan arbejdet flyder, som regel på tværs af flere roller: rækkefølge, beslutninger, overleveringer. En SOP er en instruktion i at udføre ét job, skrevet til den, der udfører det, og den indeholder ofte detaljer, som et proceskort ikke ville bære: skærmbilleder, præcise feltværdier, sikkerhedsanvisninger. I praksis hører de sammen: proceskortet viser, hvordan SOP'erne hænger sammen, og hver SOP folder ét af dets trin ud.
Hvor detaljeret skal procesdokumentation være til en audit?
Detaljeret nok til, at en auditor kan tage en konkret sag, følge jeres dokument og finde dokumentationen dér, hvor dokumentet siger, den ligger. Det betyder navngivne ejere, nedskrevne beslutningskriterier og en placering for hver registrering. Det, auditorer går efter, er ikke længde, men konsistens: en dokumenteret proces, bevis for at den blev fulgt, og en godkendelsesregistrering, der viser, at den dokumenterede version er den gældende.
Hvem skal skrive procesdokumentationen?
En, der ikke selv udfører arbejdet, ud fra interviews med dem, der gør. Praktikere springer de trin over, der er blevet automatiske for dem, og det er præcis de trin, en ny kollega har brug for. Skriv udkastet som udenforstående, og lad derefter praktikerne rette det. Rettelserne går hurtigt, og det, de tilføjer, er den tavse viden, der aldrig kommer med i et første udkast.
Hvor ofte skal procesdokumentation revideres?
Med fast kadence og på konkrete udløsere. Årligt er den almindelige basislinje, halvårligt for processer i hyppig forandring. Udløserne betyder mest: revider efter en hændelse, et auditfund, en systemmigrering eller en omorganisering, der flytter en baneejer. Det meste forfald sker gennem ændringer, ingen fik revideret dokumentationen efter, ikke gennem tidens gang.