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.
Hvad er flowchart for gennemgang og godkendelse af politikker?
De fleste politikrammer fejler stille frem for højlydt. Politikkerne findes, nogen har godkendt dem, og registret bærer endda reviewdatoer, men en tredjedel er overskredet, flere er ejet af folk, der forsvandt i en omorganisering, og den version, der ligger på intranettet, er ikke den, der ligger i onboardingmaterialet. Årsagen er sjældent, at ingen bekymrer sig om politikker. Den er, at et review behandles som en redigeringsopgave frem for som en styringscyklus med en udløser, en ejer, en beslutning og en registrering. To symptomer er diagnostiske. Det første er et review, der ikke førte til nogen ændring og ikke efterlod noget spor, så en politik, der er læst og fundet korrekt, ser urørt ud i seks år. Det andet er en revision, der blev godkendt og publiceret, men aldrig landede: ingen udmelding, nogen kan huske, ingen attestering, og dispensationer, der stadig løber mod bestemmelser, som ikke findes længere. Ingen af delene er et skriveproblem. Begge er svigt i cyklussen omkring dokumentet: ingen blev udpeget til at køre den, intet registrerede, hvad den besluttede, og der fandtes ikke et trin, der lukkede sløjfen over for de mennesker, politikken binder.
Dette diagram er styringscyklussen for én politik, tegnet i fem faser og seks baner. Det er ikke det generelle livsforløb for styrede dokumenter: versionsnummerering, udstedelse, distribution, tilbagetrækning af forældede kopier og det periodiske review af enhver form for styret dokument hører hjemme i flowchartet for dokumentstyring på /da/templates/dokumentstyring-proces, og denne side forudsætter, at det maskineri allerede findes, og kalder blot ind i det. Det er heller ikke rutetesten for ét enkelt udkast: hvilke reviewere der er obligatoriske, hvad der tæller som en redaktionel rettelse, og hvornår der skal en godkender nummer to på, behandles langt grundigere i beslutningstræet for dokumentgodkendelse på /da/templates/dokumentgodkendelse-workflow. Og det er ikke en SOP-revision. En politik er et styringsinstrument: den fastlægger, hvad organisationen kræver, ejes på bestyrelses- eller direktionsniveau og kommer igen på kalenderen, uanset om noget har ændret sig. En SOP er en arbejdsinstruktion, der ændres, når arbejdet ændres, og derfor er den styrede SOP-skabelon på /da/templates/styret-sop-skabelon bygget op om aktiviteten frem for om reviewdatoen. Fund, der udløser et politikreview, kommer ofte fra intern audit på /da/templates/intern-audit-proces: den side dækker, hvordan et fund rejses, denne dækker, hvad politikejeren derefter gør ved det.
Tre ting, som de fleste skrevne politikprocedurer lader være underforstået, er tegnet som grene her. 'Kræver politikken ændring?' har en Ingen ændring-vej, der ikke bare stopper: den ender ved 'Review registreret, ny dato sat', for et review, der ikke førte til nogen rettelse, er stadig et review, og det er præcis det, en certificeringsauditor stikprøver. 'Hvilket godkendelsesniveau gælder?' besvares, før revisionen indsendes, frem for efter at den har ligget en måned på den forkerte dagsorden, og den fører til tre forskellige fora frem for til én nominel godkender. Og 'Kræves medarbejderhøring?' er en rigtig forgrening med en rigtig udgang. Hvor et samarbejdsudvalg eller en overenskomst giver ret til information og drøftelse, går udkastet til medarbejderrepræsentanterne, og 'Er repræsentanterne enige?' bliver ført til protokols; grenen Ikke enige sender ikke udkastet tilbage til endnu en redigering, men flytter ændringen over i en forhandling med sin egen tidsplan, og derfor forlader 'Henvist til formel forhandling' processen frem for at løkke tilbage. Publiceringsfasen er bevidst længere, end de fleste procedurer gør den (meld ud, erstat den gamle version, tag stilling til, om ændringen er væsentlig nok til at kræve oplæring, indhent attestering, opdater dispensationsregistret), for det er der, fejlene reelt ligger.
Hvad dette flowchart dækker
I denne skabelon
- Seks swimlanes (Politiksekretariat, Politikejer, Berørte forretningsområder, Jura og compliance, Medarbejderrepræsentanter og Godkendelsesinstans) fordelt på fem faser: Udløser og afgrænsning, Gap-analyse, Udkast og høring, Godkendelse samt Publicering og attestering
- En udløser, der enten er den reviewdato, politikken selv bærer, eller en hændelse, der overhaler den, efterfulgt af 'Bekræft den ansvarlige politikejer', trinnet, der fanger de politikker, en omorganisering har efterladt forældreløse, før nogen begynder at skrive
- 'Kræver politikken ændring?' besvaret ud fra en eksplicit gap-analyse, med en Ingen ændring-gren, der stadig ender ved 'Review registreret, ny dato sat', så en politik, der ikke skal rettes, aldrig kommer til at se ureviewet ud
- Høringen fordelt over tre baner: 'Hør de berørte forretningsområder', 'Vurder juridisk og regulatorisk holdbarhed' og beslutningen 'Kræves medarbejderhøring?', der leder videre til repræsentanterne, hvor 'Er repræsentanterne enige?' enten sender udkastet tilbage til 'Opdater udkastet efter høringen' eller forlader processen ved 'Henvist til formel forhandling' frem for at løkke tilbage
- 'Hvilket godkendelsesniveau gælder?' forgrener til Niveau 1 (bestyrelse), Niveau 2 (direktion) og Niveau 3 (udvalg), som mødes i trevejsbeslutningen 'Godkendelsesbeslutning?': Godkendt, Omskrivning tilbage til udkastet, eller Afvist, der ender ved 'Revisionen trukket tilbage og henlagt'
- En publiceringsfase med de trin, procedurer normalt bare forudsætter: 'Publicer den nye version og meld den ud', 'Erstat og arkivér den gamle version', beslutningen 'Væsentlig ændring, der kræver oplæring?', 'Registrer attestering fra berørte medarbejdere', 'Opdater undtagelses- og dispensationsregistret' og slutpunktet 'Revideret politik i kraft'
Hvornår du skal bruge skabelonen
- I skal skrive eller bygge en politikramme om og har brug for ét billede af, hvem der udløser et review, hvem der ejer indholdet, hvem der skal høres, og hvem der skriver under
- Jeres politikregister nævner stadig ejere, der forsvandt i sidste omorganisering, og bærer reviewdatoer, der udløb for to år siden, og I vil have ejertjekket og det registrerede ingen ændring-udfald bygget ind i cyklussen frem for jaget på mail
- Et auditfund, en regelændring eller en omorganisering har netop tvunget et review frem uden for kalenderen, og I vil køre det ad samme vej som et planlagt
- Revisioner ender igen og igen hos bestyrelsen, selv om et politikudvalg burde have afgjort dem, og niveauet skal ligge fast før indsendelsen frem for at blive diskuteret på mødet
- I publicerer reviderede politikker og kan bagefter ikke vise, hvem der har læst dem, eller I finder dispensationer, der stadig løber mod bestemmelser, som blev slettet for to versioner siden
Sådan fungerer det
Omdøb banerne, så de passer til jeres styring
Erstat Politiksekretariat, Politikejer, Berørte forretningsområder, Jura og compliance, Medarbejderrepræsentanter og Godkendelsesinstans med de roller og fora, I reelt har. Hold politiksekretariatet adskilt fra politikejeren, også selv om sekretariatet er én person: den ene kører cyklussen og holder registret, den anden ejer indholdet og forsvarer ændringen. Har I hverken samarbejdsudvalg eller overenskomstdækning, så slet banen Medarbejderrepræsentanter og den beslutning, der fører til den, frem for at lade et forum stå i diagrammet, som aldrig gør noget.
Skriv listen over udløsere ind i politikrammen
Kalenderudløseren er den nemme; det er hændelsesudløserne, folk skændes om bagefter. Navngiv dem i selve politikrammen: en lov- eller regelændring, et påbud eller en tilsynsreaktion, en alvorlig hændelse, et fund fra intern eller ekstern audit, en væsentlig ændring i forretningsmodellen, en omorganisering og et opkøb. Skriv, hvem der må trække et review frem, og hvordan de gør det: et review uden for kalenderen, der afhænger af, at nogen tilfældigt får øje på en nyhed, er ikke en kontrol. Registrer derefter på hvert eneste review, hvilken udløser der udløste det.
Fastlæg godkendelsesniveauerne, før I får brug for dem
Sæt niveau og navngiven godkendelsesinstans på hver politik i registret nu, mens intet er undervejs, at afgøre niveauet med en revision allerede skrevet gør et styringsspørgsmål til en mødekalenderdiskussion. For Niveau 1 skal I læse bestyrelsens forretningsorden frem for at gætte ud fra emnet. Skriv derefter de to ting ned, politikrammer plejer at udelade: hvem der må flytte en revision mellem niveauer, og hvordan en delegeret godkendelse ser ud, når instansen ikke mødes før ikrafttrædelsesdatoen. Det sidste hul er der, hvor ugodkendte politikker stille og roligt træder i kraft.
Definer, hvad en væsentlig ændring er
'Væsentlig ændring, der kræver oplæring?' er tom, indtil I skriver testen. Væsentlig betyder, at ændringen ændrer, hvad nogen skal gøre: en ny pligt, en lavere grænse, et nyt forbud, en anden indberetningsvej. Det betyder ikke en omdøbt afdeling eller en rettet krydshenvisning. At ramme forkert koster begge veje: oplæring i bagateller lærer folk at klikke sig igennem, og en stille væsentlig ændring efterlader medarbejderne i fuld overbevisning om, at de gør det rigtige. Lad politikejeren foreslå svaret og godkendelsesinstansen bekræfte det som en del af godkendelsen.
Beslut, hvordan attestering og dispensationer følges
Afgræns den berørte population ud fra et kildesystem frem for en mailliste, sæt en frist, rykkerne går gennem nærmeste leder, og læg gennemførelsestallene sammen med den version, de hører til: en attesteringsprocent uden versionsnummer beviser ingenting. Behandl derefter undtagelsesregistret som en del af udgivelsen frem for som en oprydning bagefter. Giv det en navngiven ejer, kræv at hver dispensation bærer en udløbsdato, en godkender og den kompenserende kontrol, den hviler på, og peg de overlevende over på den nye nummerering, før revisionen træder i kraft.
Gå diagrammet igennem, og udgiv en version
Tag det færdige diagram med til dem, der står i banerne (politikejeren, den der holder registret, en juridisk reviewer og sekretæren for godkendelsesinstansen), og kør én rigtig politik igennem det fra ende til anden, inklusive et review, der ikke ændrer noget. Ret diagrammet til det, de faktisk gør, ikke til det, politikrammen siger. Udgiv derefter den revision med en godkendelse registreret på sig, og behold de tidligere, så processen for at gennemgå politikker selv er underlagt den versionsstyring, den kræver af alt andet.
Ofte stillede spørgsmål
Hvilke trin består gennemgang og godkendelse af politikker af?
Udløs reviewet, enten fra den dato politikken bærer, eller fra en hændelse, der overhaler den. Bekræft, hvem den ansvarlige ejer er, for omorganiseringer efterlader politikker forældreløse. Analysér den gældende tekst op mod det, der udløste reviewet, og afgør, om der skal ændres noget. Skal der ikke det, så registrer reviewet og sæt en ny dato. Skal der det, så skriv revisionen op mod den godkendte version med ændringsmarkering, hør de forretningsområder, bestemmelsen styrer, indhent juridisk review og compliancereview, og forelæg ændringen for medarbejderrepræsentanterne, hvor de har ret til information og drøftelse. Opdater udkastet, indsend det til det godkendelsesniveau, politikken ligger på, og registrer beslutningen. Publicer derefter en nummereret version med en ikrafttrædelsesdato, meld ud hvad der er ændret, træk den erstattede version tilbage og arkivér den, gennemfør oplæring hvor ændringen er væsentlig, indhent attestering fra de berørte medarbejdere, og opdater undtagelsesregistret mod den nye nummerering.
Hvor ofte bør politikker gennemgås?
Årligt for politikker med lovgivnings- eller myndighedskrav i sig og for alt, bestyrelsen ejer; hvert andet år for de fleste øvrige; og straks, når en hændelse overhaler kalenderen. Den faste kadence er ikke det vigtige: hændelsesudløserne er. En politik, der blev reviewet planmæssigt måneden før en lovændring, er forældet ugen efter, og det review, der betyder noget, er det uplanlagte. Sæt intervallet pr. politik frem for på tværs af hele rammen, skriv det på selve politikken, og hold det i et register, der viser næste dato for hver post, ikke kun den seneste. To praktiske ting. Spred datoerne, så godkendelsesinstansen ikke får fyrre politikker i ét kvartal. Og beslut, hvad en overskredet reviewdato betyder, før I står med en: en politik bortfalder ikke, når datoen passeres, den er fortsat gældende, så en overskredet post skal være synlig i registret og eskaleres til ejerens nærmeste leder frem for stille at få en ny dato af den, der vedligeholder listen.
Hvem bør godkende en politik?
Den instans, der bærer det ansvar, politikken udtrykker, og derfor holder én nominel godkender sjældent hele vejen rundt i en politikramme. Dette diagram fører til tre. Politikker, der fastlægger risikovillighed, udmønter en lovbestemt pligt eller binder organisationen udadtil, går til bestyrelsen. Politikker med tværgående konsekvenser (hvordan udlæg refunderes, hvordan persondata behandles, hvordan leverandører engageres) går til direktionen, hvor de berørte funktioner er repræsenteret. Resten går til et politikudvalg med bemyndigelse fra bestyrelsen. Sæt niveauet på hver politik i registret på forhånd, så vejen ligger fast før skrivningen frem for at blive diskuteret ved indsendelsen. Og hold ejer og godkender adskilt, uanset hvor lille organisationen er: en politik, som én person skriver, ejer og godkender, har ikke haft en andenbehandling, og det er det første, der bliver testet, den dag en politik viser sig at modsige en lovbestemt pligt eller en gældende kontrakt.
Hvordan adskiller siden sig fra et flowchart for dokumentstyring?
De ligger på hvert sit niveau. Flowchartet for dokumentstyring på /da/templates/dokumentstyring-proces er det livsforløb, ethvert styret dokument følger (ændringsanmodning, udkast, review, godkendelse, versionsnummerering, udstedelse, distribution, tilbagetrækning af forældede kopier og periodisk review) med en dokumentansvarlig, der kører det. Denne side er styringscyklussen for én politik, og den forudsætter, at det dokumentstyringsmaskineri ligger under den. Det, den lægger oven på, er det politikspecifikke: et ejertjek, der fanger forældreløse politikker efter en omorganisering, gap-analyse op mod udløseren, høring i samarbejdsudvalget eller efter overenskomsten, godkendelse på niveau hos bestyrelse, direktion eller udvalg, attestering fra den berørte population, og det undtagelsesregister, der skal valideres på ny, når bestemmelserne flytter sig. Vil I have rutebeslutningerne inde i én enkelt godkendelse, så brug /da/templates/dokumentgodkendelse-workflow. Og bemærk forskellen til en SOP: en politik er et styringsinstrument, der gennemgås på en kalender, uanset om noget har ændret sig, mens en SOP på /da/templates/styret-sop-skabelon er en arbejdsinstruktion, der revideres, når arbejdet ændres, og hvis det, I egentlig er ude efter, er ISO 9001 punkt 7.5's vinkel på versionsstyring specifikt frem for denne styringscyklus, se /da/guides/dokumentversionsstyring-iso-9001.
Hvad sker der, hvis et politikreview viser, at der ikke skal ændres noget?
Det skal stadig registreres, og det er den halvdel af processen, de fleste politikrammer springer over. I dette diagram forlader Ingen ændring-grenen fra 'Kræver politikken ændring?' ikke processen i stilhed; den ender ved 'Review registreret, ny dato sat'. Registreringen bør navngive, hvem der gennemgik politikken, hvad de holdt den op mod (den gældende regulering, hændelseshistorikken, auditfundene siden sidste review), datoen, de gjorde det, og næste frist. Eventuelt kan I genudstede samme version med en ny reviewdato frem for at tælle versionsnummeret op, så dokumenthistorikken ikke fyldes med revisioner, der intet ændrede. Det betyder noget, fordi certificerings- og myndighedsauditorer stikprøver for dokumentation af, at der er gennemført et review, ikke for at der er sket en ændring. En politik, hvis indhold reelt stadig er korrekt efter tre år, er et godt resultat; en politik, der ser ureviewet ud i tre år, fordi ingen registrerede reviewene, er et fund, og de to ting kan ikke skelnes fra registret.
Hvor denne proces passer ind
I de fleste virksomheder følger denne proces efter Skabelon til flowchart for intern audit.
Den er ét trin i Dokumentstyring.
Trin 1: Flowchart for dokumentstyring
Trin 4: Workflow for dokumentændringsstyring
En workflow for dokumentændringsstyring, der dækker klassifikation som mindre/større, reviewerens konsekvensvurdering, godkendelse, versionsstempling, opdatering af distributionslisten og formel erstatning af den forrige version.
Trin 5: Flowchart for gennemgang og godkendelse af politikker Du er her
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.