Versionsstyring af flowcharts: sådan fungerer det reelt

Kort fortalt

• Et filnavn som »v3_FINAL_gennemgået(2)« er et gæt, ikke en versionshistorik.
• PDF- eller PNG-eksport gemmer et billede af flowchartet, ikke dets redigerbare struktur.
• Clouddrevets filversionering sporer filen, ikke boksene og forbindelserne indeni.
• Reel versionsstyring af flowcharts differ boks-, forbindelses- og etiketændringer mellem to vilkårlige gemte tilstande.
• QueryCharts ændringslog og Sammenlign versioner gør det automatisk på hvert diagram, gratis: se /features/version-control.

Et filnavn er ikke en revisionshistorik

Et sted på et fælles drev lige nu ligger Procesdiagram_v3_FINAL_gennemgået(2).vsdx, ved siden af Procesdiagram_v3_FINAL_gennemgået.vsdx og en Procesdiagram_v2.pdf, en interessent stadig har hæftet på en gammel mailtråd. Mellem de tre findes der ingen registrering af, hvilken boks der flyttede sig, hvilken beslutningsgren der blev omdøbt, hvem der lavede den ene eller anden ændring, eller om nogen overhovedet skrev under på den: kun et filnavn, der udfører det job, en versionshistorik skal udføre.

At eksportere et flowchart til et billede eller en PDF til arkivering fanger nok, hvordan det så ud, men smider den ene ting væk, en senere læser har brug for: den redigerbare struktur under. En PNG kan ikke diffes mod en anden PNG for at vise, at en beslutningsboks fik en tredje gren: en person må stirre på to billeder og gætte. Et clouddrevs egen »versionshistorik« løser heller ikke det her: den versionerer filen, ikke diagrammet indeni. Den kan give jer gårsdagens .vsdx eller .pptx tilbage, men den aner ikke, at en bestemt boks skiftede bane, eller at en forbindelses etiket ændrede sig fra »Eskalér« til »Auto-godkend« mellem to øjebliksbilleder.

Et diagramværktøj med reel versionsstyring gør tre ting, et filnavn og et fælles drev ikke kan: det lader jer gennemse hver tidligere revision af selve diagrammet, det viser præcis, hvilken boks, forbindelse eller etiket der ændrede sig mellem to vilkårlige af dem, og det gendanner en gammel tilstand uden at miste det arbejde, der er lavet siden. QueryChart gør det på hvert diagram, live, automatisk, gratis: ændringsloggen registrerer hver redigering med hvem der lavede den, og hvilket felt den rørte, og Sammenlign versioner sætter to vilkårlige gemte versioner side om side. Hele mekanismen findes på /features/version-control.

Det skel betyder noget, fordi et flowchart ikke er det samme objekt som det procesdokument, det måske er indlejret i. Denne side handler om at versionsstyre selve diagrammets struktur (bokse, baner, forbindelser) inden i et værktøj bygget til at spore den struktur. Styrer I i stedet revisioner af et længere procesdokument, der tilfældigvis indeholder et diagram, er den værktøjsagnostiske version af dette problem gennemgået på /da/guides/versionsstyring-af-procesdokumentation.

Sådan optjener dette dokument sit eget versionsnummer, række for række

Nummereringssystemet herunder er præcis den disciplin, en dokumentejer håndhæver i hånden (decimaler til udkast, hele tal til godkendelser), samme skel, QueryCharts ændringslog sporer automatisk for selve diagrammet, uden at nogen skriver et tal.

1. Et udkast starter på et decimaltal, ikke et gæt

   Startrækken er »Nyt dokument udarbejdet«, og lige den næste række er »Tildel indledende udkastversion 0.1«: decimaltallet identificerer præcis, hvor mange reviewcyklusser udkastet har været igennem, før »Send udkast til intern review« og »Reviewer vurderer udkastet« overhovedet sker.

2. Hver omarbejdning tæller tallet op, ikke gætteriet

   Ved »Kræves der ændringer?« sender et Ja-svar til »Optæl den mindre version«, før »Ret udkastet i forhold til kommentarerne« begynder, så en reviewer, der citerer kommentarer på et bestemt decimaltal, navngiver et præcist, adresserbart udkast frem for en vag »seneste«-fil.

3. Godkendelse er den ene begivenhed, der udløser et helt tal

   »Indsend det endelige udkast til godkendelse« og »Godkender gennemgår det endelige udkast« fører til »Godkendt til udstedelse?«: kun grenen Godkendt når frem til »Tildel hovedversion 1.0«, så intet før det punkt, uanset hvor mange decimaludkast det passerede, nogensinde forveksles med version 1.0.

4. Publicering opdaterer registret, før nogen læser det

   »Opdater versionshistorikregistret« kører før »Publicer den godkendte version«, og »Markér den forrige version som erstattet« følger lige efter, så registret, der lister hvert tidligere nummer, ikke kun det gældende, er opdateret, før en eneste læser når frem til »Læser tilgår den aktuelle version«.

5. En senere ændring genåbner registreringen, den overskriver den ikke

   »Ønskes der ændring efter publicering?« sender enten processen tilbage til »Genåbn dokumentet ved den næste version« (hvilket genstarter den nummererede kæde frem for at redigere den gældende fil på stedet) eller slutter ved »Aktuel version forbliver gældende«, med hvert tidligere nummer stadig på registret.

Sådan fungerer det

1. Hold op med at navngive versioner i filen

   Udfas »v3_FINAL_gennemgået(2)«-konventionen helt: et decimaltal eller en farve skrevet ind i et filnavn er en etiket, nogen tilføjede, ikke en registrering af, hvad der ændrede sig. Modellér flowchartet i et værktøj, der fører sin egen revisionshistorik, og lad filnavnet gå tilbage til bare at være et filnavn.

2. Giv hver reviewindsendelse en navngivet version

   I QueryChart gemmer det at indsende et diagram til review automatisk en navngivet version, og intet bliver nogensinde overskrevet. Den ene vane erstatter hele »Gem som«-sporet af duplikerede filer, fordi den tidligere tilstand bevares, uanset om nogen husker at omdøbe noget.

3. Åbn ændringsloggen, før I spørger, hvad der ændrede sig

   Ændringsloggen lister hver redigering af diagrammet, hvem der lavede den, og hvilket felt den rørte, så »hvad ændrede sig siden tirsdag« bliver en rulning gennem en liste, ikke en hukommelsesøvelse eller et sammenkniben af øjnene mod to eksporterede billeder side om side.

4. Diff to versioner i stedet for at stirre på to eksporter

   Brug Sammenlign versioner til at vælge to vilkårlige gemte versioner og se forskellen felt for felt: boks-, forbindelses- og etiketændringer bliver hver især fremhævet som tilføjet, fjernet eller ændret, frem for overladt til en læser at få øje på på tværs af to flade PDF'er.

5. Gendan i stedet for at genopbygge fra hukommelsen

   Hvis en revision viser sig at være forkert, så gendan den tidligere version i stedet for manuelt at tegne den om fra en gammel eksport. Selve gendannelsen bliver en ny post i historikken, så intet om det gældende udkasts oprindelse går tabt.

6. Hold diagrammet som masterversionen, ikke dets eksport

   Behandl den PDF eller PNG, I cirkulerer, som et øjebliksbillede til læsere, aldrig som den registrering, I ville genopbygge fra: det redigerbare diagram med dets versionshistorik er den ene kopi, der kan svare på »hvordan så det her ud i marts«, og det kan eksporten ikke.

Faldgruber du skal undgå

• Tallet »(2)« i filnavnet er tegnet

  Et tal i parentes hæftet på et allerede versioneret filnavn betyder, at to personer redigerede den samme »seneste« kopi samtidig, uden nogen måde at flette dem på. Rettelsen er ikke en bedre navnekonvention, det er at fjerne behovet for én: ét diagram, én historik, ingen kopier, der kan kollidere.

• En eksporteret PDF overlever det diagram, den kom fra

  En PDF hængt op på en væg eller vedhæftet en gammel mail bliver ved med at cirkulere længe efter, at det diagram, den blev eksporteret fra, er kommet videre, og intet ved selve PDF'en signalerer det. Behandl hver eksport som forældet i det øjeblik, den skabes, og link tilbage til det levende diagram frem for at gendele filen.

• At forveksle filversionering med diagramversionering

  OneDrive, Google Drive og Dropbox kan give jer gårsdagens fil tilbage, men ingen af dem kan fortælle jer, at en beslutningsboks fik en gren, eller at en forbindelses etiket ændrede sig: de versionerer beholderen, ikke dens indhold. Et diagramværktøjs egen historik er det eneste sted, den diff findes.

• At gendanne lydløst i stedet for på registret

  At indsætte indholdet fra en gammel eksport tilbage i den gældende fil sletter selve det faktum, at en gendannelse fandt sted. En gendannelse, der skaber sin egen nye, daterede post, som QueryCharts gør, holder årsagen til rollbacket synlig for den næste læser i stedet for at se ud, som om diagrammet altid havde været sådan.

Byg jeres eget versionsstyrede flowchart

Åbn eksemplet på versionsnummerering som jeres eget diagram, og indsend det til review én gang for at se en navngivet version, ændringsloggen og Sammenlign versioner dukke automatisk op for det.

Byg jeres eget versionsstyrede flowchart

Relaterede guides

• Sådan sporer du ændringer i en proces
• Sådan sporer du ændringer i en SOP
• Revisionsstyring kontra versionsstyring: hvad er den reelle forskel?

Ofte stillede spørgsmål

Er versionsstyring af flowcharts forskellig fra dokumentversionsstyring?

Ikke i princippet: begge betyder at holde fast i hver tidligere tilstand af noget, så I kan se, hvad der ændrede sig, og gå tilbage til det, men et flowcharts »ændrede sig« er strukturelt: hvilken boks der flyttede sig, hvilken forbindelse der blev tilføjet, hvilken etiket der blev omformuleret. En dokumentversionsstyringsproces bygget op omkring brødtekst og sidetal vil ikke diffe en beslutningsgren. Se /da/guides/versionsstyring-af-procesdokumentation for den version af dette problem, der er afgrænset til et helt procesdokument frem for ét enkelt diagram.

Tæller det som versionsstyring at eksportere et flowchart til PDF?

Nej: det er et øjebliksbillede, ikke en historik. En PDF fanger ét øjeblik, men kan ikke sammenlignes automatisk med en anden PDF for at vise, hvad der ændrede sig, kan ikke redigeres tilbage i, og bærer ingen registrering af, hvem der lavede den forrige ændring, eller hvorfor. Den er nyttig til at dele en fast kopi med en læser; den er ikke en erstatning for diagrammets egen versionshistorik.

Hvad er forskellen på ændringsloggen og Sammenlign versioner i QueryChart?

Ændringsloggen er tidslinjen: hver redigering, hvem der lavede den, og cirka hvornår, læst fra top til bund. Sammenlign versioner svarer på et snævrere spørgsmål: vælg to vilkårlige gemte versioner, og se forskellen mellem dem felt for felt, boks for boks og forbindelse for forbindelse, i stedet for at rulle gennem hele loggen for selv at rekonstruere det.

Kan jeg gendanne en gammel version af et flowchart uden at miste det gældende arbejde?

Ja: at gendanne en tidligere version i QueryChart skaber en ny version frem for at slette dem, der kom efter den, så det arbejde, der er lavet siden, bliver stående i historikken, selvom det ikke længere er den aktive tilstand. Intet ved en gendannelse er destruktivt.