Versionsstyring kontra ændringsstyring: hvad er forskellen

Kort fortalt

• Versionsstyring sporer identitet og historik: hvilken version dette er, og hvad der gik forud.
• Ændringsstyring er styring: om en foreslået ændring er tilladt, og hvem der skal godkende den.
• Ændringsstyring kører først: klassificering og godkendelse låser adgangen til en ny version, ikke omvendt.
• En mindre redigering og en større redigering kan bære forskellige niveauer af ændringsstyring uden at ændre, hvordan versionsstyring fungerer.
• De fleste reelle processer har brug for begge dele, lagdelt: ændringsstyring beslutter, versionsstyring husker.

To forskellige spørgsmål, ét fælles objekt

»Hvilken version er dette?« og »bør denne ændring ske?« er to forskellige spørgsmål, og det meste procesdokumentation svarer kun på det første. Versionsstyring er en mærknings- og historikmekanisme: den tildeler et id til hver efterfølgende tilstand af et dokument, holder en registrering af, hvad der gik forud, og lader jer se, hvem der ændrede hvad, og hvornår. Den svarer på spørgsmål om forvaring efter faktum. Ændringsstyring sidder opstrøms for det: det er den styringsproces, der afgør, om en foreslået ændring er tilladt, hvem der skal reviewe den, og hvad der skal være opfyldt, før en ny version overhovedet får lov at eksistere.

Workflowet for dokumentændringsstyring herunder gør grænsen synlig som et diagram frem for en sætning. Rækkerne 1 til 8 er udelukkende ændringsstyring: at logge anmodningen, klassificere den som mindre eller større, dirigere større ændringer til en reviewer, der vurderer den fulde konsekvens, og lade alt afhænge af en »Godkendt?«-beslutning. Intet af det rører dokumentets version. Først efter godkendelsesporten kører »Opdater versionsnummer og distributionsliste«, ved række 9: det præcise punkt, hvor versionsstyring starter.

QueryChart holder de to adskilt på samme måde. Hver redigering af et diagram fanges automatisk i en ændringslog med feltvise diffs, en Sammenlign versioner-visning og gendannelse med ét klik: det er versionsstyring, der kører, uanset om nogen beder om det, på /features/version-control. Om en given redigering overhovedet fik lov at ske, og hvem der skrev under på den, er det styringsspørgsmål, et diagram som det herunder besvarer. For den fyldigere, mere it/drift-farvede version af den styringsproces frem for den dokumentspecifikke, se /da/guides/saadan-laver-du-en-aendringsstyringsproces.

Hvor ændringsstyring slutter, og versionsstyring starter

Ét dokuments klassificering, review og godkendelse, og derefter den præcise række, hvor dets versionsnummer faktisk ændrer sig.

1. En anmodning, endnu ikke en versionsændring

   »Ændring af et styret dokument identificeret« starter diagrammet, derefter »Indsend dokumentændringsanmodning« og »Log anmodningen mod dokumentposten«: tre rækker ændringsstyring, og dokumentets version er stadig urørt.

2. Klassificering og godkendelse afgør alt

   »Ændring klassificeret som mindre eller større?« forgrener til en hurtigsporsrettelse eller et fuldt review, hvor ændringsrevieweren »vurderer den fulde konsekvens« og registrerer den mod relaterede dokumenter og formularer, før »Godkendt?«-beslutningen: intet af det har rørt versionsnummeret endnu.

3. Række 9 er, hvor versionsstyring begynder

   Først når ændringen er godkendt, kører »Opdater versionsnummer og distributionsliste«, efterfulgt af publicering på den styrede placering, besked til modtagerne på distributionslisten, og tilbagetrækning af den erstattede kopi: versionsstyringshalvdelen af processen.

4. En afvisning løkker tilbage ind i ændringsstyring

   Et »Afvist«-svar sender anmodningen til »Ret udkastet, og send det til fornyet review«, som vender tilbage til ændringsreviewerens konsekvensvurdering: omarbejde bliver helt inden i ændringsstyring, indtil »Dokument genudstedt under formel ændringsstyring« lukker diagrammet med en ny version på plads.

Sådan fungerer det

1. Adskil de to spørgsmål i jeres egen proces

   Før I tegner noget, skal I beslutte, hvad der hører til ændringsstyring (anmodning, klassificering, review, godkendelse), og hvad der hører til versionsstyring (id, revisionsnummer, historik, gendannelse). At navngive grænsen er det designtrin, de fleste flowcharts springer over.

2. Klassificér, før I vurderer

   Send hver anmodning gennem en mindre/større-beslutning, før vurderingen begynder, på samme måde som række 4 gør. En mindre ordlydsrettelse og en større kravændring bør ikke rejse samme reviewvej, og at afgøre hvad der er hvad på forhånd stopper, at hver ændring får den tungeste behandling.

3. Placér versionsstyringstrinnet dér, hvor godkendelsen faktisk slutter

   Optæl kun versionsnummeret, sæt ikrafttrædelsesdatoen og opdater distributionslisten efter godkendelsesporten, aldrig før. Opdaterer jeres diagram versionen før beslutningen, har I beskrevet en proces, der versionerer afviste udkast.

4. Giv ændringsstyring sin egen reviewer, ikke dokumentejeren

   En ændringsreviewer, der vurderer den fulde konsekvens og registrerer den mod relaterede dokumenter og formularer, adskilt fra hvem der anmodede om ændringen, er det, der gør »godkendt« til noget, der betyder noget. I eksemplet sidder det trin mellem klassificeringen og godkendelsesbeslutningen, ikke foldet ind i nogen af dem.

5. Lad versionsstyring køre sig selv, når ændringsstyring har besluttet

   Publicering, besked til modtagerne på distributionslisten og tilbagetrækning af den erstattede kopi er mekanisk, når en ændring er godkendt: det er versionsstyringshalen på diagrammet, og det er den halvdel, QueryCharts ændringslog og Sammenlign versioner-visning allerede klarer for jer på /features/version-control.

Faldgruber du skal undgå

• At behandle »vi har versionshistorik« som ændringsstyring

  Et værktøj, der tidsstempler hver redigering, er ikke en styringsproces: det har ingen klassificering, ingen reviewer og ingen godkendelsesport. Versionshistorik svarer på, hvad der ændrede sig; den siger intet om, hvorvidt ændringen burde være sket.

• At versionere en ændring, før den er godkendt

  Hvis versionsnummeret flytter sig før »Godkendt?«-beslutningen, viser et afvist udkast sig stadig som en ny revision. Hold optællingen ved række 9, efter godkendelse, på samme måde som eksemplet gør.

• Én kategori for hver ændring

  At sende en tastefejlsrettelse gennem samme review som en kravændring enten bremser trivielle redigeringer eller lukker substantielle igennem på hurtigsporet. Opdelingen i mindre/større ved række 4 findes, så begge får den rette mængde granskning; se /da/guides/saadan-laver-du-en-aendringsstyringsproces for, hvordan I designer kategorierne selv.

Sammenlign versioner i jeres eget diagram

Hver redigering af dette eksempel spores allerede automatisk: åbn det, og tjek ændringsloggen og Sammenlign versioner-visningen selv.

Sammenlign versioner i jeres eget diagram

Relaterede guides

• Sådan sporer du ændringer i en proces
• Sådan laver du et workflow til dokumentgodkendelse
• Sådan laver du en proces for ændringsstyring (change control)

Ofte stillede spørgsmål

Er versionsstyring det samme som ændringsstyring?

Nej. Versionsstyring er mekanismen, der identificerer og husker et dokuments efterfølgende tilstande: et revisionsnummer, en historik over hvem der ændrede hvad, og evnen til at sammenligne eller gendanne en tidligere. Ændringsstyring er den styringsproces, der afgør, om en foreslået ændring får lov at ske, hvem der reviewer den, og hvad der skal være opfyldt, før den godkendes. Et dokument kan have stringent versionsstyring og slet ingen ændringsstyring: hver redigering gemt, uden at nogen besluttede, om den burde være lavet.

Hvilken bør jeg bygge først?

Versionsstyring, fordi den som regel allerede kører under jer: QueryChart fører en ændringslog med feltvise diffs og en Sammenlign versioner-visning for hvert diagram automatisk, på /features/version-control. Ændringsstyring er den del, I skal designe bevidst (kategorier, en reviewer, en godkendelsesport), hvilket er grunden til, at det er den proces, der er værd at tegne som et flowchart, som det på denne side.

Hvordan adskiller dette sig fra revisionsstyring?

I praksis er »revisionsstyring« og »versionsstyring« samme mekanisme under forskellige navne, begge optaget af at identificere og spore et dokuments efterfølgende tilstande. Ændringsstyring er den anden: den styrer, om en ændring overhovedet er tilladt, typisk endende i en ny version, når den er godkendt. Se /da/guides/revisionsstyring-kontra-versionsstyring, hvis det specifikt er navngivningsspørgsmålet mellem revisionsstyring og versionsstyring, I forsøger at afgøre.

Hvor passer dokumentstyring ind i forhold til disse to?

Dokumentstyring er den bredeste af de tre: det fulde livsforløb for et styret dokument, fra anmodning gennem udkast, review, godkendelse, publicering og eventuel tilbagetrækning eller udfasning. Ændringsstyring og versionsstyring er begge brikker i den: ændringsstyring styrer en enkelt foreslået redigering, versionsstyring sporer de id'er og den historik, redigeringen producerer. For hele livsforløbet frem for blot ændrings-/versionsgrænsen, se /da/templates/dokumentaendringsstyring-workflow eller den bredere /da/guides/saadan-laver-du-en-dokumentstyringsproces.