Tværfunktionelt flowchart (gennemgang og publicering af indhold)

Sådan fungerer det

1. Afgør, om banerne gør deres arbejde

   Før du tilpasser noget, så kontrollér, at jeres fejl ligger i overleveringerne. Er problemet, at udkastene er svage, hjælper et banediagram ikke, og en lige række trin er lettere at læse. Giv kun en bane til et team, der træffer en beslutning eller holder arbejde, mens det venter — aldrig én bane pr. person: baner navngivet efter enkeltpersoner holder op med at beskrive processen, første gang nogen skifter job.

2. Omdøb banerne til de funktioner, I faktisk har

   Erstat Forfatter, Redaktør, Jura og compliance samt Webteam med jeres egne. Har I ingen juridisk reviewer internt, så slet ikke tjekket sammen med banen: flyt "Hold hver påstand op mod dokumentationen" ind i redaktørens bane, og navngiv den eksterne advokat eller compliance-ansvarlige, der godkender det. Læg kun forfatter- og redaktørbanen sammen, hvis én person reelt gør begge ting — og det er dér, diagrammet holder op med at være tværfunktionelt.

3. Skriv listen over udløsere for påstande ned

   "Er der regulerede eller sammenlignende påstande?" er kun så god som listen bag den. Notér jeres egen på trinnet: navngivne konkurrenter, pris- eller besparelsestal, påstande om ydeevne eller sikkerhed, kundenavne og logoer, sundhedsfaglig, økonomisk eller juridisk rådgivning samt enhver reguleret betegnelse. Hold beslutningen i redaktørens bane. Forfattere med en deadline går uden om et tjek, de selv ejer, og det er netop den fejl, denne krydsning findes for at forhindre.

4. Fastsæt Juras svarfrist, og navngiv én reviewer

   Skabelonen forudsætter en aftalt svarfrist — tre arbejdsdage er almindeligt — og én navngiven reviewer pr. tekst. Skriv jeres eget tal på trinnet. Behold den tredje gren ved "Godkender Jura påstandene, som de står?": en påstand uden dateret dokumentation bag sig er ikke en sag om rettelser, og at lægge den ind i rettelsesgrenen er den måde, udokumenterbare påstande bliver omformuleret i stedet for droppet.

5. Gør tjekket før publicering til jeres eget, og kør det på siden på staging

   List jeres tjek på beslutningstrinnet: godkendt tekst på plads, title og metabeskrivelse, overskrifter og alt-tekst, links der virker, mobilvisning og samtykke på indlejrede medier. To ting betyder mere end selve listen. De køres på siden på staging og ikke på dokumentet, og det, der fejler, går retur til webteamet — så lad den gren pege på "Byg siden og læg den på staging til gennemsyn".

6. Fastsæt revurderingsdatoen ved godkendelsen og ikke senere

   "Godkend teksten og fastsæt publiceringsdatoen" er også det sted, revurderingsdatoen hører til — typisk 30 eller 90 dage frem — vurderet mod det formål, briefen navngav, frem for mod trafikken alene. Lad opdateringsgrenen føre tilbage til rettetrinnet: en ændret påstand skal godkendes på ny. Vender jeres team reelt aldrig tilbage til publicerede sider, så slet den sidste fase frem for at efterlade et trin, ingen udfører.

Ofte stillede spørgsmål

Hvornår har man brug for et tværfunktionelt flowchart frem for et almindeligt?

Når fejlene ligger i overleveringerne. Tegn processen som en lige række trin, og se på, hvad der faktisk er gået galt for nylig. Bliver trinnene udført dårligt, tilføjer baner bredde og fortæller dig intet nyt. Går arbejdet i stå, fordi ingen ved, at det er kommet, eller bliver det udført to gange, fordi to teams hver især antog, at det var deres, så er ejerskabet den information, du mangler, og baner er måden at vise det. Publiceringsprocessen her består den prøve: en påstand, der skal godkendes juridisk, og en side, webteamet lægger på staging, men redaktøren godkender, er begge krydsninger — og begge er de steder, tekster bliver væk.

Hvilke faser består gennemgang og publicering af indhold af?

Fem, og de svarer til faserne i dette diagram. Udkast: skriv ud fra en brief, der navngiver målgruppen, formålet, den endelige URL og den ønskede dato, og vedhæft derefter kilder, billeder og alt-tekst. Gennemgang: redigér for faktuel korrekthed og husstil, og lad derefter redaktøren træffe en beslutning med en rettesløjfe bagved. Godkendelse: afgør, om teksten indeholder regulerede eller sammenlignende påstande, hold i så fald hver påstand op mod dokumentationen, og godkend derefter teksten og fastsæt publiceringsdatoen. Publicering: byg siden og læg den på staging, kør tjekket på den, publicér og anmod om indeksering. Efter publicering: tjek indeksering, viderestillinger og fejl, og vurdér derefter siden mod sit formål på en fastsat revurderingsdato.

Hvem ejer gennemgang og publicering af indhold?

Redaktøren ejer forløbet; ingen anden er i stand til det. Forfatteren ejer udkastet og rettelserne, Jura og compliance ejer, om en påstand kan stå som den er, og webteamet ejer den byggede side og deploymentet. Men redaktøren er den eneste rolle, der optræder i fire af de fem faser, og det er derfor, udløseren for påstande, godkendelsen af teksten, beslutningen før publicering og revurderingen efter publicering alle ligger i den bane. Går jeres proces gentagne gange i stå, så se først på, om den ejer af hele forløbet overhovedet findes, eller om hvert team blot passer sin egen del og håber.

Hvordan er det sammenlignet med et tværfunktionelt flowchart i Visio?

Visios desktopskabelon hedder Cross Functional Flowchart, og Microsofts egen brug af bindestreg i navnet varierer på tværs af deres dokumentation, så læs ikke en forskel ind i det. To ting overrasker folk der. Faser er ikke en egenskab ved en bane, men separate Separator-figurer, man lægger oven på banerne, og hvis man sletter en swimlane, slettes hver figur inde i den — Microsofts dokumenterede omvej er at flytte figurerne helt uden for diagrammet først. På nettet kræver tværfunktionelle flowcharts Visio Plan 1 eller Plan 2; de findes ikke i den Visio, der er inkluderet i Microsoft 365. Her er banen en værdi på selve trinnet, så at flytte et trin til en anden ejer er en redigering af den række.