Tværfunktionelt flowchart (gennemgang og publicering af indhold)
Skabelon til et tværfunktionelt flowchart bygget på gennemgang og publicering af indhold: fire baner til forfatter, redaktør, jura og compliance samt webteam, fordelt på fem faser fra briefen til en revurdering efter publicering.
Hvad er tværfunktionelt flowchart (gennemgang og publicering af indhold)?
Et tværfunktionelt flowchart er et almindeligt proceskort skåret op i baner, én bane pr. ejer, så hvert trin både siger, hvad der sker, og hvem der har bolden. Banerne er ikke pynt, og de er ikke gratis. De fordobler cirka den plads, diagrammet kræver, og de tvinger dig til at navngive en ejer på netop de trin, hvor ejerskabet reelt er omstridt. Prøven for, om du har brug for dem, er enkel. Tegn først processen som en lige række trin, og spørg så, hvad der faktisk er gået galt de sidste ti gange. Er det trinnene i sig selv, der gik galt, så behold det almindelige flowchart. Er det overleveringerne, der gik galt, er banerne hele pointen med diagrammet.
Gennemgang og publicering af indhold er brugt her, fordi hele vanskeligheden ligger i krydsningerne. En påstand om en konkurrent eller et besparelsestal skal godkendes af en, der ikke skriver tekst. En side bygges og lægges på staging af webteamet, men godkendes af en redaktør, der ikke kan deploye den. En tekst, der kommer tilbage fra Jura, skal til forfatteren igen, ikke til den reviewer, der fandt problemet. Fejlene er pålideligt de samme tre: ingen ved, at en tekst venter på dem, det juridiske tjek springes over, fordi forfatteren vurderede det unødvendigt, og tjekket før publicering køres på dokumentet i stedet for på den byggede side. Hver enkelt af dem er en overlevering.
Diagrammet herunder går fra en brief til enten en publiceret side med en revurderingsdato eller en tekst, der bliver henlagt og aldrig publiceret. Det har fire baner (forfatter, redaktør, jura og compliance samt webteam) fordelt på fem faser, og krydsningerne er tegnet frem for beskrevet. Rettetrinnet ligger i forfatterens bane inde i gennemgangsfasen. Jura skriver den påkrævede formulering ind i et register og sender teksten tilbage til forfatteren og ikke til den redaktør, der rejste sagen. Beslutningen før publicering hører til redaktøren, mens udbedringen går retur til webteamet. Læsere, der nåede frem til denne form via Visios Cross Functional Flowchart-skabelon, vil kunne genkende strukturen, her redigeret som rækker frem for tegnet.
Hvad dette flowchart dækker
I denne skabelon
- Fire baner (Forfatter, Redaktør, Jura og compliance samt Webteam) fordelt på fem faser: Udkast, Gennemgang, Godkendelse, Publicering og Efter publicering.
- Den redaktionelle sløjfe ved "Godkender redaktøren udkastet?", hvis Nej-gren fører til "Ret udkastet efter redaktørens bemærkninger" og tilbage ind i redigeringen, med rettetrinnet placeret i forfatterens bane, mens teksten forbliver i gennemgangsfasen.
- En udløser for påstande, der ejes af redaktøren og ikke af forfatteren, ved "Er der regulerede eller sammenlignende påstande?": det er den, der sender en tekst over i den juridiske bane i stedet for at overlade vurderingen til den, der har en deadline.
- En tredelt juridisk beslutning ved "Godkender Jura påstandene, som de står?": godkendt fortsætter til godkendelse af teksten, påkrævede rettelser skrives ind i "Notér den påkrævede formulering i påstandsregistret" og sender teksten retur til forfatteren, og en påstand, der ikke kan dokumenteres, afslutter processen ved "Indholdet henlagt og ikke publiceret".
- Et kontrolpunkt på staging ved "Består siden tjekket før publicering?", som ligger i redaktørens bane, mens udbedringen går tilbage til "Byg siden og læg den på staging til gennemsyn" i webteamets bane, så et fejlet tjek aldrig som standard lander hos forfatteren.
- Livet efter publicering: "Tjek indeksering, viderestillinger og sidefejl", derefter "Opfylder siden sit formål på revurderingsdatoen?", hvis opdateringsgren går ind i det samme rettetrin igen, så ændrede påstande bliver godkendt på ny frem for at blive smuglet ind.
Hvornår du skal bruge skabelonen
- Tekster ligger stille i dagevis, og ingen kan sige, om de venter på redaktøren, på Jura eller på et deployment-vindue.
- En påstand om en konkurrent, en pris eller et ydelsestal nåede en live side, uden at nogen uden for indholdsteamet havde læst den.
- Webteamet bliver bedt om at rette tekstproblemer på staging, fordi godkendelsen skete på et dokument i stedet for på den byggede side.
- To personer troede hver især, at den anden havde godkendt teksten, og den gik ud med en pladsholder eller et dødt link.
- Du skriver det redaktionelle workflow ned for første gang og vil have ét billede frem for fire teamtjeklister, der er uenige i kanterne.
Sådan fungerer det
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.
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.
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.
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.
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".
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.