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.
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.
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.