Sådan laver du et procesdokumentationssystem

Sådan bygger du et procesdokumentationssystem, der stadig er sandt om to år: en procesfortegnelse med navngivne ejere, reviewintervaller sat efter forandringstakten, og en dateret fejl for hvert kort, der halter.

Et procesdokumentationssystem holder et bibliotek af procesdokumenter sandt over tid: en fortegnelse med én navngiven ejer pr. proces, en reviewdato der når frem til den ejer, og en forfaldstakt, som nogen måler.

Kort fortalt

  • Begynd med en fortegnelse, ikke et dokument: én række pr. proces, én ejer, én forfaldsdato.
  • Byg metaprocessen før det første dokument: oprettelse, godkendelse, publicering, oplæring, udfasning.
  • På tværs af et bibliotek er det gennemsnitlige dokument forældet i halvdelen af sit reviewinterval.
  • En ændring, der nåede driften før sit kort, er en dokumentationsfejl med en dato på.
  • Et review, der ikke ændrede noget, skylder stadig registret en dateret post, ellers ligner nøjagtighed forsømmelse.

Systemet er metaprocessen, ikke skabelonen

Enhver organisation kan frembringe halvtreds procesdokumenter, og flere har gjort det to gange. Hvad et dokumentationssystem afgør, er ikke, hvordan de skrives, men hvad der er sandt om dem om to år. Regnestykket er ubarmhjertigt. Er kalenderen det eneste, der tvinger et genbesøg, går en ændring foretaget ugen efter et årligt review upåagtet hen det meste af et år, og på tværs af et bibliotek tilbringer det gennemsnitlige dokument halvdelen af sit reviewinterval med at beskrive arbejde, der har flyttet sig. En skriveskabelon rører ikke det tal.

Derfor er det første artefakt ikke et dokument. Det er en fortegnelse: hver proces, organisationen kører, én række hver, med én navngiven person ansvarlig for beskrivelsen, det niveau den er dokumenteret på, og et reviewinterval. Så kommer metaprocessen: den vej, procesdokumenter bliver skabt, godkendt, publiceret, oplært i og udfaset ad. Uden den vedligeholdes hvert dokument af den, der tilfældigvis husker det, og reglen for en proces, der ændrede sig før sit kort, står aldrig skrevet.

Det følgende er selve den metaproces frem for en af de processer, den styrer. »Bekræft den ansvarlige politikejer« er anden række, før nogen analyse begynder. Udgangen »Ingen ændring« fra »Kræver politikken ændring?« når frem til »Review registreret, ny dato sat«: et review, der ikke omskrev noget og alligevel flyttede datoen, og det er den slags post, et aldrende bibliotek aldrig har. Og »Omskrivning« sender godkendelsesbeslutningen tilbage til »Skriv revisionen med ændringsmarkering«.

Byg metaprocessen i fem stadier

Den metaproces, et bibliotek kører på, ikke en af processerne i det. Læs det for, hvad registret har krav på, efter at en politik er publiceret.

  1. En ejer før en analyse

    Udløseren er en kalenderdato eller en hændelse, og rækken efter den bekræfter den ansvarlige ejer, før noget bliver læst. »Kræver politikken ændring?« behandler derefter »Ingen ændring« som en rigtig afslutning: »Review registreret, ny dato sat« er det, der holder et register ærligt om et dokuments alder.

  2. Høring er ikke en høflighed

    Skrivearbejde med ændringsmarkering, så de berørte forretningsområder, så juridisk og regulatorisk holdbarhed. »Kræves medarbejderhøring?« leder til repræsentanterne, og »Ikke enige« ender ved »Henvist til formel forhandling«: en afslutning uden for bibliotekets kontrol, tegnet frem for underforstået.

  3. Niveaudeling holder bestyrelsen fri

    »Hvilket godkendelsesniveau gælder?« deler sig tre veje ud i bestyrelsen, direktionen og politikudvalget, og alle tre samles i »Godkendelsesbeslutning?«. Dens udgang »Omskrivning« peger tilbage på skriverækken; »Afvist« henlægger revisionen og lader den tidligere version blive gældende.

  4. Publiceringen skriver tilbage til registret

    Registret skrives fra to rækker: »Publicer den nye version og meld den ud« og »Erstat og arkivér den gamle version«. Den nye revision, publiceringsdatoen og næste reviewdato kommer alle derfra. Et publiceringstrin, der skriver tilbage til ingenting, efterlader et register, der ældes alene.

  5. Forpligtelserne efter publiceringen

    En beslutning om væsentlighed styrer oplæringen, attestering registreres på de berørte medarbejdere, og »Opdater undtagelses- og dispensationsregistret« fanger dispensationer givet mod bestemmelser, der ikke findes længere. Systemet ender ved »Revideret politik i kraft« frem for ved publiceringen.

Sådan fungerer det

  1. Skriv procesfortegnelsen før noget kort

    List hver proces, organisationen kører, én linje hver, med en navngiven person ansvarlig for beskrivelsen, det niveau den bør dokumenteres på, og hvor kritisk den er. Forvent, at listen bliver kortere end frygtet, og at ejerkolonnen bliver diskussionen. Intet andet kan bygges, mens den kolonne har huller.

  2. Sæt hvert reviewinterval efter forandringstakten

    Tag intervallet fra, hvor ofte processen faktisk flyttede sig de sidste to år, frem for fra en standard i en politik: tre ændringer giver seks måneder, ingen ændring i fem år giver to. Registrér intervallet, næste forfaldsdato og det dokumenterede niveau i fortegnelsen, så ingen af de tre bliver diskuteret igen ved hver revision.

  3. Byg metaprocessen som et diagram først

    Før I dokumenterer nogen rigtig proces, skal jeres egen dokumentationsvej ind i rækker: hvad der udløser et review, hvem der bekræfter ejeren, hvem der høres, hvem der godkender, hvordan der publiceres og oplæres. Skriv stadierne ind i kolonnen Bokstekst, og forbind dem via rækkenummer i kolonnen Linje til. Hvert senere dokument arver fra den.

  4. Sæt godkendelsesniveauet på diagrammet som en beslutning

    Rækken, der styrer vejvalget, får Beslutning i kolonnen Figur, med niveauerne skrevet ind i Linjetekst ud for numrene i Linje til, så en revisions vej er kendt, før skrivearbejdet begynder. Brug kolonnen Vandret bane til fasen og Lodret bane til ejeren, så diagrammet viser, at et politiksekretariat og en godkendelsesinstans er to forskellige ting.

  5. Tegn omskrivningssløjfen som et tal bagud

    En godkendelse, der sender arbejde tilbage, er et rækkenummer, der peger på en tidligere række, ikke en pil, nogen tegner på bagefter. Fordi kolonnen Linje til holder data, overlever den sløjfe, at der indsættes et trin over den. Et diagram, der kun viser bevægelse fremad, beskriver en godkendelsesinstans, der aldrig én gang har været uenig.

  6. Auditér biblioteket op imod dets egne datoer

    Tæl fire tal hvert kvartal: dokumenter over deres reviewdato, dokumenter uden navngiven ejer, dokumenter hvis proces ændrede sig før kortet gjorde, og reviews registreret uden ændring. Det sidste er et sundhedstegn. Book den næste optælling i fortegnelsen, før I lukker denne, for en optælling uden en næste dato falder bort, og biblioteket genoptager sit forfald.

Faldgruber du skal undgå

  • Dokumentation kørt som et projekt

    Projektet leverer biblioteket, opløses, og forfaldet begynder den uge, det lukker. Dokumentation er en stående funktion med en ejer og en budgetlinje, ellers er det et øjebliksbillede af et kvartal, der ældes dårligt.

  • Påmindelsen adresseret til en afdeling

    »Ejes af Drift« betyder, at forfaldsdatoen ikke bliver leveret noget sted. En afdeling har ingen kalender og ingen indbakke, der svarer, så påmindelsen bliver dannet og adresseret til en funktion, og ingen bestemt læser den.

  • Kun det, der står på hylden, bliver revideret

    En reviewcyklus kan handle på den liste, den har, så de processer, der slet ikke har et dokument, er dem, den aldrig får frem. Byg fortegnelsen ud fra det arbejde, organisationen udfører, ikke ud fra den mappe med dokumenter, der findes.

  • Dokumenteret om igen uger efter ændringen

    En proces, der ændrede sig i marts og blev dokumenteret om igen i maj, var forkert i otte uger, og intet i biblioteket registrerer det. Registrér intervallet med datoer; mønstret på tværs af de intervaller viser, hvor systemet lækker.

Byg jeres eget dokumentationssystem

Åbn eksemplet med politikreview som jeres eget diagram, og fastlæg derefter ejeren, godkendelsesniveauet og det reviewinterval, jeres bibliotek skal køre på.

Byg jeres eget dokumentationssystem

Relaterede guides

Ofte stillede spørgsmål

Hvad er et procesdokumentationssystem?

Det er det sæt regler og roller, der holder en samling procesdokumentation sand, til forskel fra dokumenterne selv: en fortegnelse med én navngiven ejer pr. proces, det niveau hver af dem er dokumenteret på, et reviewinterval hvis forfaldsdatoer når frem til de ejere, en målt takt for, hvor hurtigt biblioteket falder bagud, og en vej for at oprette, godkende, publicere og udfase et dokument. Skabelonen betyder mindst. Prøven er, hvad registret siger om et dokument, ingen har rørt i tre år.

Hvad skal en procesfortegnelse indeholde?

Én linje pr. proces: procesnavnet, ejeren som en person frem for et team, det niveau den er dokumenteret på, dens kritikalitet, placeringen af den gældende version, og datoerne for sidste review og næste forfald. To kolonner mere tjener sig hurtigt hjem: de systemer, processen kører i, som fortæller jer, hvad en migrering vil ugyldiggøre, og det punkt, den findes for at opfylde, som fortæller jer, hvad en auditor vil bede om at se. Fortegnelsen kommer først, fordi hver senere beslutning er en forespørgsel i den.

Hvem skal eje et procesdokumentationssystem?

Én person, og ikke den, der ejer flest dokumenter. Systemejeren holder fortegnelsen, metaprocessen og registret over reviewdatoer; hver dokumentejer holder indholdet. At lægge de to sammen giver den velkendte fejl, hvor hver revision står i kø bag den ene person, der forstår systemet, og hvor køen bliver rapporteret som et ressourceproblem frem for et designproblem. En halv dag om ugen bærer et bibliotek på halvtreds processer, forudsat at påmindelserne er automatiske, og at hver ejer er et navn.

Hvor skal procesdokumentation ligge?

Der hvor fortegnelsen siger, og derfor er placering en kolonne i den frem for en beslutning, der tages én gang for hele biblioteket. Et kvalitetsledelsessystem, en wiki og et fællesdrev kan hver især holde en gældende version; ingen af dem kan fortælle jer, hvilke processer der slet ikke har en. Prøven er altså ikke, hvilken platform det er, men om hver række i registret navngiver det sted, dens læsere sendes hen, og om det at komme derhen frembringer den revision, registret hævder. En proces uden en række er usynlig for hvert eneste platformvalg.

Skabelonen bag denne guide

Flowchart for gennemgang og godkendelse af politikker — Flowchart for gennemgang og godkendelse af politikker: udløser fra kalender eller hændelse, bekræftelse af ejer, gap-analyse, høring, juridisk review og medarbejderhøring, godkendelse i niveauer, publicering og attestering.

Browse all SOP- og procesdokumentationsvejledninger

Gennemgang og godkendelse af politikker: Udløser og afgrænsning → Gap-analyse → Udkast og høring → Godkendelse → Publicering og attestering
Sådan laver du et procesdokumentationssystem