Sådan sporer du ændringer i en proces

Kort fortalt

• En redigering af en beslutningsrækkes tærskel (anden godkender krævet over 5.000 kr. hævet til over 10.000 kr.) bliver til en post i ændringsloggen, der navngiver, hvem der ændrede den, og hvilken værdi den erstattede.
• Hver redigering er tilskrevet: aktør, felt, tidligere værdi, nuværende værdi og et tidsstempel, ikke bare »diagram opdateret«.
• Sammenlign versioner giver den fyldigere diff, når mere har flyttet sig mellem to revisioner, end én ændringslogpost dækker.
• At gendanne en gammel version fortryder redigeringen direkte, frem for at bede nogen om at huske og genindtaste den forrige regel.
• At spore en ændring er noget andet end at styre den: dette er den registrering, en redigering efterlader, ikke godkendelsesporten for, om den skal ske.

Hvem flyttede tærsklen, og hvornår

En procesejer hæver beløbsgrænsen på en beslutningsrække fra 5.000 kr. til 10.000 kr.: ét felt, én redigering, gemt på sekunder. Tre uger senere bliver en faktura på 7.000 kr. godkendt uden en anden godkender, og spørgsmålet er ikke, om reglen ændrede sig, men hvem der ændrede den, hvornår, og hvad det gamle tal faktisk var. Ingen skrev det ned noget sted uden for selve diagrammet, for diagrammet er, hvor reglen lever.

QueryChart holder den registrering automatisk. Hver redigering af et diagram (en omdøbt beslutning, en flyttet gren, en ændret tærskel) skriver en post, der navngiver den person, der lavede den, det felt, de rørte, dets tidligere værdi og dets nuværende. Åbn ændringsloggen på redigeringen ovenfor, og den siger præcis det: tærskel ændret af en navngiven person, fra 5.000 kr. til 10.000 kr., på et registreret tidspunkt. Ingen vedligeholder en separat changelog i hånden, og ingen skal stole på en hukommelse om, hvad reglen plejede at sige. Mekanismen er gennemgået i fulde detaljer på /features/version-control.

At spore en ændring er ikke det samme som at styre den. Denne side handler om den registrering, QueryChart fører, når en proces er blevet redigeret: et faktum, efter faktum. Ændringsstyring er den beslutningsproces, der styrer, om en redigering overhovedet skal ske, som regel med en anmodning og et reviewtrin; den mekanik er bygget på /da/guides/saadan-laver-du-en-aendringsstyringsproces. Og hvis dokumentet under diskussion er en skreven procedure frem for et beslutningstræ, gælder samme ændringslog, men gennemgangen læses anderledes: se /da/guides/saadan-sporer-du-aendringer-i-en-sop for den version.

Godkendelsestræet, redigeret og sporet

Et beslutningstræ til dokumentgodkendelse med tyve rækker, gennemgået i faser fra modtagelse til frigivelse, med tærsklen for anden godkender i centrum: præcis den regel, arbejdseksemplet ovenfor redigerer.

1. Hvor en redigering starter

   Diagrammet åbner ved »Dokument indsendt til godkendelse«, spørger derefter »Nyt dokument eller revision?« og for en revision »Redaktionel eller indholdsmæssig ændring?«, før det forgrener til »Registrer den redaktionelle rettelse« eller et fuldt »Reguleret dokumenttype?«-tjek, den gren, der afgør, hvor meget granskning en ændring får, før nogen reviewer den.

2. Reviewløkken, der bringer uenighed frem

   Rækkerne seks til ni kører selve reviewet: »Tilføj kvalitets- og regulatoriske reviewere«, »Indsaml kommentarer fra reviewerne«, derefter »Er alle kommentarer afklaret?«, som, hvis ikke, spørger »Kan forfatteren løse det nu?«, før det løkker tilbage eller går ud til omarbejdning. Hvert gennemløb af denne løkke gemmes som sin egen version.

3. Tærsklen, dette eksempel redigerer

   »Godkender gennemgår det endelige udkast« fører til »Godkendes til frigivelse?«, derefter til den række, arbejdseksemplet ovenfor handler om: »Kræves der en ekstra godkender?«, som sender videre til »Indhent den ekstra godkendelse«, når svaret er ja. Hæv den rækkes tærskel, og ændringsloggen registrerer præcis den redigering.

4. Frigivelse, og den registrering, den efterlader

   Banen Frigivelse lukker træet på tre måder: »Udgivet som mindre redaktionel rettelse«, »Udgivet efter fuld godkendelse« eller »Udgivet med oplæring tildelt« efter »Kræves læst-og-forstået?«, plus »Returneret til forfatteren til omarbejdning« og »Afvist og lukket«. Hver regel, der sendte et dokument til én af disse, sidder i en version, Sammenlign versioner kan åbne.

Sådan fungerer det

1. Åbn ændringsloggen efter en redigering

   Hver gemning skriver en ny version, og ændringsloggen lister dem i rækkefølge. Åbn den fra diagrammets historikpanel for at se, hvilken version der ændrede sig, og hvem der gemte den. I behøver ikke vide på forhånd, at en tærskel flyttede sig.

2. Læs posten: aktør, felt, tidligere værdi, nuværende værdi

   Klik ind i en version, og dens post navngiver den person, der redigerede den, det felt, de rørte (en rækkes etiket, en grens betingelse, en banetildeling), og den værdi, det havde før, mod den værdi, det har nu. Det er hele svaret på, hvem der ændrede tærsklen for anden godkender, og hvad den plejede at sige, uden at åbne en eneste mailtråd.

3. Brug Sammenlign versioner, når én post ikke er hele historien

   Posten for én redigering er præcis, men snæver. Når flere rækker har flyttet sig mellem den version, I stoler på, og den, der ligger foran jer, skal I i stedet åbne Sammenlign versioner og læse de to side om side, samme mekanisme, udvidet til hvert felt, der er forskelligt.

4. Gendan den forrige version, hvis redigeringen skal fortrydes

   Hvis en hævet tærskel viser sig at være forkert frem for tilsigtet, så gendan den version, der gik forud. At gendanne erstatter det gældende diagram med den revision direkte, frem for at bede nogen om at genindtaste den gamle regel fra hukommelsen.

5. Navngiv reglen, ikke kun grenen, så diffen forbliver læsbar

   Skriv en beslutningsrækkes etiket og dens grenetiketter omkring den faktiske udløser (»Kræves der en ekstra godkender?« besvaret »Kræves« eller »Kræves ikke«) frem for et nøgent ja eller nej. En ændringslogpost, der navngiver et navngivet felt, er langt mere nyttig end én, der siger, at en unavngivet boks flyttede sig.

Faldgruber du skal undgå

• At jagte en ændret regel gennem chat og hukommelse

  Uden en ændringslog bliver en hævet tærskel rekonstrueret fra Slack-beskeder og nogens erindring om det gamle tal, og de to er sjældent enige. Hver feltvise redigering er allerede tilskrevet og dateret: den rekonstruktion, QueryChart er bygget til at gøre unødvendig.

• At forveksle en registreret redigering med en godkendt

  En ændringslogpost beviser, at en tærskel ændrede sig, og hvem der ændrede den. Den beviser ikke, at nogen skrev under på det nye tal. Hvis en regel som denne skal gennem review, før den træder i kraft, hører den port hjemme i selve processen (af den type, der er bygget på /da/templates/aendringsstyring-proces), ikke kun i versionshistorikken alene.

• At antage, at audit trail allerede er slået til

  QueryCharts indbyggede versionshistorik (ændringsloggen, Sammenlign versioner og gendannelse) er gratis og aktiv på hvert diagram uden opsætning. Et hash-kædet audit trail mappet til ISO 27001-, SOC 2- eller HIPAA-kontroller er en separat, betalt funktion, en organisation slår til bevidst; det er ikke noget, hvert diagram bærer som standard, bare fordi redigeringer bliver sporet.

Spor jeres egne procesændringer

Start fra dokumentgodkendelseseksemplet, redigér en beslutningsrækkes tærskel, og se ændringsloggen navngive præcis, hvad der ændrede sig.

Spor jeres egne procesændringer

Relaterede guides

• Sådan laver du et workflow til dokumentgodkendelse
• Sådan laver du en proces for ændringsstyring (change control)
• Sådan laver du en CAPA-proces

Ofte stillede spørgsmål

Hvad registrerer ændringsloggen præcis, når en proces ændrer sig?

For hver redigering en post, der navngiver den person, der lavede den, det felt, de ændrede (en rækkes etiket, en grens betingelse, en banetildeling), og det felts værdi før redigeringen mod dets værdi bagefter. At hæve en tærskel for anden godkender fra 5.000 kr. til 10.000 kr. giver en post, der siger præcis det, tilskrevet og tidsstemplet, uden at nogen fører en separat log. Mekanismen er gennemgået i fulde detaljer på /features/version-control.

Er det at spore procesændringer det samme som ændringsstyring?

Nej. At spore en ændring er den registrering, QueryChart fører automatisk, efter en redigering sker: hvem, hvilket felt, gammel værdi, ny værdi. Ændringsstyring er den beslutningsproces, der styrer, om en redigering overhovedet skal ske, som regel med en anmodning, et reviewtrin og en rollback-vej. Begge dele betyder noget, men de svarer på forskellige spørgsmål; mekanikken bag den anden findes på /da/guides/saadan-laver-du-en-aendringsstyringsproces.

Hvordan adskiller dette sig fra at spore ændringer i en SOP?

Selve ændringsloggen er identisk (samme aktør, felt og før/efter-værdier), fordi et beslutningstræ og en skreven procedure begge er diagrammer under samme versionshistorik. Forskellen er, hvad der typisk bliver redigeret: en proces som denne ændrer grenbetingelser og dirigering, mens en SOP oftere ændrer trintekst og ansvar. Se /da/guides/saadan-sporer-du-aendringer-i-en-sop for den version af samme funktion.

Kan jeg se alt, hvad der ændrede sig mellem to versioner, ikke kun én redigering?

Ja: åbn Sammenlign versioner frem for én ændringslogpost, og den lægger to revisioner side om side med hvert felt, der er forskelligt, markeret. Det er værktøjet til en regel, der har glidet over flere små redigeringer frem for én åbenlys.

Sletter det at gendanne en gammel version den redigering, der ændrede tærsklen?

Nej. At gendanne gør en ældre version gældende igen, men den version, hvor tærsklen ændrede sig, findes stadig i diagrammets historik, dens ændringslogpost bliver ikke slettet, så registreringen af, hvem der hævede den, og hvornår, overlever gendannelsen.