Sådan laver du et godkendelsesworkflow
Sådan designer du et godkendelsesworkflow: afklar, hvad hver port reelt beslutter, sæt grænserne efter jeres beføjelsesoversigt, giv afvisninger en vej videre, og registrér hvem der godkendte hvad.
Et godkendelsesworkflow er en række porte, hver med én ansvarlig godkender, et formuleret spørgsmål, en vej for et afslag og en registrering af, hvem der godkendte hvad hvornår.
Kort fortalt
- Har en port aldrig sagt nej, er den en notifikation. Tegn den som en.
- Én ansvarlig godkender pr. port, med den information, der skal til for at beslutte.
- Grænserne kommer fra beføjelsesoversigten og hører hjemme på selve beslutningen.
- Et afslag skal føre et sted hen: tilretning, eskalering eller en eksplicit lukket tilstand.
- Registrér godkender, tidsstempel og version: en godkendelse, der ikke kan dokumenteres, fandt ikke sted.
Enhver port skal kunne sige nej
Testen på et godkendelsesworkflow er ikke, hvor mange underskrifter det samler. Den er, om nogen af dem realistisk kunne nægtes. En port, der aldrig har afvist noget, er en notifikation med ekstra ventetid, og den er værre end ingen port, for den producerer en godkendelsesregistrering, der antyder en vurdering, som ikke fandt sted. Og det er præcis den dokumentation, en auditor tager stikprøver i, og en domstol læser.
Godt godkendelsesdesign handler derfor mest om at trække fra. To meningsfulde porte slår fem ceremonielle, fordi godkendere, der er én ud af fem, skriver under uden at kigge. Hver tilbageværende port har brug for tre ting: én ansvarlig godkender, et formuleret spørgsmål, de svarer på, og nok information foran sig til at kunne svare. Hvor de mangler, flytter en ekstra port bare risikoen hen et sted, hvor den er mindre synlig.
Eksemplet herunder er en proces for godkendelse af leverandører, og det er et godkendelsesworkflow med usædvanligt ærlig struktur: en screeningsport, der kan sløjfe tilbage efter manglende dokumentation, en beslutning om risikoklasse, der styrer vurderingens dybde, en auditport med en sløjfe for korrigerende handlinger, og til sidst en trevejsbeslutning (godkendt, betinget eller afvist) frem for den sædvanlige binære.
Et godkendelsesworkflow med rigtige porte
Godkendelse af leverandører fra forslag til optagelse på listen. Fire porte, der hver kan sige nej, og som hver har en vej ud.
Screen, før I bruger tid på vurderingen
En business case og en beslutning om, hvorvidt kvalificeringen skal gennemføres, kan stoppe forløbet allerede på første trin. Den billigste port kommer først: at vurdere en leverandør, ingen har besluttet at forfølge, er det mest udbredte spild i godkendelsesworkflows.
Rykkere er en del af workflowet
Porten for leverandørspørgeskemaet sender sagen tilbage efter manglende dokumentation i stedet for at afvise den. De fleste virkelige godkendelsesforløb bruger mere kalendertid på at rykke for ufuldstændige besvarelser end på at beslutte, og at tegne den sløjfe er det, der gør det målbart.
Vurderingens dybde følger risikoen
En beslutning om risikoklasse sender højrisikoleverandører videre til en audit med sin egen sløjfe for korrigerende handlinger, mens lavere klasser går direkte videre. Ensartet vurderingsdybde er den mest udbredte designfejl: den bruger for mange kræfter på det trivielle og for få på det farlige.
Tre udfald, ikke to
Godkendelsesinstansen kan godkende, godkende betinget eller afvise, og en betinget godkendelse får sine betingelser registreret, før leverandøren optages på listen. Binære porte tvinger godkendere til at vælge mellem at blokere legitimt arbejde og lade noget ufuldstændigt passere.
Sådan fungerer det
Skriv ned, hvad hver port beslutter
Én sætning pr. godkendelse: hvilket spørgsmål svarer denne person på, og på hvilket grundlag? Porte, der ikke kan formuleres sådan, er som regel der for synlighedens skyld, og synlighed er bedre tjent med en notifikation, der ikke holder arbejdet tilbage.
Hent grænserne fra jeres beføjelsesoversigt
Beløbsintervaller, risikoklasser og væsentlighedsgrænser hører til i beføjelsesoversigten, ikke hos den, der designer workflowet. Skriv beløbet og valutaen på selve beslutningen, så routingen kan efterprøves, og sæt dem højt nok til, at den ekstra port sjældent udløses.
Giv hver port præcis én ansvarlig godkender
Andre kan høres; én person står på mål for beslutningen. Udvalg kan godkende, men så er udvalget godkenderen, og både beslutningsdygtighed og formand skal navngives. To sideordnede godkendere på samme niveau er den form, der får ingen af dem til at læse grundigt.
Giv hvert afslag en vej videre
Tegn, hvor en afvist sag går hen: retur til tilretning med begrundelsen registreret, op til eskalering, eller til en eksplicit lukket tilstand. Workflows, der lader afvisningen være utegnet, producerer sager, der hverken er levende eller lukkede, og som ingen rykker for.
Lad vurderingens dybde følge risikoen
Læg en routingbeslutning ind før de dyre vurderinger, sådan som eksemplet gør med sin risikoklasse. At lægge fuld due diligence på alt betyder enten, at processen er for langsom, eller at grundigheden ikke er reel, og som regel begge dele.
Registrér dokumentationen for godkendelsen
Hver godkendelse har brug for en godkender, et tidsstempel og den version, den gjaldt. I QueryChart har selve diagrammet et godkendelsesforløb og en uforanderlig historik, så »hvem godkendte den version, der gjaldt i marts« har et svar, uden at nogen skal lede i en indbakke.
Faldgruber du skal undgå
Porte, der ikke kan sige nej
En godkendelse, der aldrig er blevet nægtet, er en notifikation, og at registrere den som en godkendelse overdriver kontrollen over for enhver, der læser dokumentationen senere.
Godkendere uden information
En port er kun så god som det, godkenderen får at se. Bliver begrundelsen først registreret efter godkendelsen, er godkendelsen ren dekoration.
Grænser sat for lavt
En grænse, der udløses på de fleste transaktioner, træner godkendere i at klikke videre og lokker folk til at splitte anmodninger op for at holde sig under den.
Ingen vej for et afslag
En utegnet afvisning giver den mest udbredte workflow-fejl: sagen, der hverken er godkendt eller lukket, og som ingen ejer.
Lav jeres eget godkendelsesworkflow
Åbn eksemplet med leverandørgodkendelse som dit eget diagram, og erstat portene med de beslutninger, jeres organisation reelt træffer.
Relaterede guides
Ofte stillede spørgsmål
Hvor mange godkendelsesniveauer bør et workflow have?
Så få som muligt: kun dem, der reelt træffer beslutninger. Typisk ét, med et niveau mere over en grænse hentet fra jeres beføjelsesoversigt. Hver ekstra port lægger kø til og udvander ansvaret: godkendere, der er én ud af fem, vurderer mindre grundigt, ikke mere, så et workflow med fem porte kan være en svagere kontrol end et med to, og koste betydeligt mere. Har en port aldrig afvist noget, er det netop dokumentationen for, at den bør være en notifikation.
Hvad er forskellen på en godkendelse og en gennemgang?
En godkendelse er en beslutning, der kan standse arbejdet, og som bærer ansvaret for udfaldet; en gennemgang er en granskning, der producerer kommentarer. At blande de to sammen er en udbredt designfejl: de, der gennemgår, får en vetoret, de ikke var tiltænkt, eller godkendere behandles som anmeldere, så deres underskrift ikke betyder noget. Tegn gennemgange som trin og godkendelser som beslutninger, så bliver forskellen strukturel frem for en konvention.
Skal godkendelser være parallelle eller sekventielle?
Sekventielle, når en senere godkender bygger på en tidligeres beslutning, og parallelle, når de vurderer hver sin uafhængige ting. De fleste workflows tegnes sekventielt af ren vane og lægger dage til uden analytisk grund: jura, der vurderer kontraktvilkår, og økonomi, der vurderer kreditrisiko, har ikke brug for hinandens udfald. Parallelle porte er sværere at repræsentere i visse sagssystemer, og det er en værktøjsbegrænsning, der er værd at kalde ved navn frem for at bage ind i procesdesignet.
Hvordan dokumenterer jeg godkendelser til en audit?
Registrér godkenderen, tidsstemplet og præcis den version, der blev godkendt: det sidste er det, der som regel mangler. En godkendelse, der ikke kan knyttes til en bestemt revision, beviser kun, at nogen godkendte noget på et tidspunkt. QueryChart registrerer godkendelser mod en diagramrevision med en uforanderlig historik, så det spørgsmål, en auditor faktisk stiller (hvilken version var gældende, og hvem skrev under), kan besvares direkte.
