跨职能流程图模板（内容评审与发布）
以内容评审与发布流程为例的跨职能流程图模板：作者、编辑、法务与合规、网站团队四条泳道，横跨从撰稿纲要到发布后回顾的五个阶段。
什么是跨职能流程图模板（内容评审与发布）流程
跨职能流程图就是一张普通的流程地图，按负责人切成泳道，一条泳道一个负责人，于是每一步都同时说明发生了什么、这件事在谁手上。泳道不是装饰，也不是免费的。它们大致会让图所需的篇幅翻一倍，并且迫使你为那些归属本来就有争议的步骤指定一个负责人。判断要不要用泳道的方法很简单：先把流程画成一条直线，然后问最近十次里究竟是什么出了问题。如果出问题的是步骤本身，就留着这张普通流程图。如果出问题的是交接，那么泳道就是这张图存在的全部意义。
这里选内容评审与发布，是因为它的全部难处就在跨界。一句关于竞品的说法或者一个省钱数字，必须由不写文案的人来放行。一个页面由网站团队制作并上预发布环境，却由不能部署的编辑定稿。一篇从法务退回来的稿子需要作者，而不是提出问题的那位评审人。失败的方式很可靠地总是那三种：没人知道有一篇稿子正等着自己；法务检查被跳过，因为作者自己判断没必要；发布前检查是对着文稿做的，而不是对着预发布页面做的。这三件事，每一件都是一次交接。
下面这张图从一份纲要出发，终点或是一个定好回顾日期的已发布页面，或是一篇被撤下、始终没有发布的内容。它有四条泳道——作者、编辑、法务与合规、网站团队——横跨五个阶段，而跨界之处是画出来的，不是描述出来的。修改这一步落在作者的泳道里，同时稿子仍留在评审阶段。法务把要求的措辞写进登记册，然后把稿子交回作者，而不是交回提出问题的编辑。发布前的判断归编辑，而补救工作退回网站团队。从 Visio 的 Cross Functional Flowchart 模板一路找到这个形状的读者会认出这套结构，只不过这里是用行编辑出来的，不是画出来的。
本流程图涵盖的内容
本模板包含
- 四条泳道——作者、编辑、法务与合规、网站团队——横跨五个阶段：撰稿、评审、审批、发布、发布后。
- “编辑是否通过初稿？”处的编辑循环，它的否分支通向“按编辑意见修改初稿”，再回到校订；修改这一步落在作者的泳道里，而稿子仍停在评审阶段。
- 一个由编辑而不是作者负责的表述触发点，“内容是否含受监管或比较性表述？”，正是它把一篇稿子送进法务泳道，而不是把这个判断留给赶截稿的人。
- “法务是否按原文放行这些表述？”处的三向判断：已放行的继续走向定稿；需修改的把措辞写入“将要求的措辞记入表述登记册”并把稿子退回作者；无法证实的表述则让流程在“内容已撤下，不予发布”结束。
- “页面是否通过发布前检查？”这道预发布关卡设在编辑的泳道里，而补救工作退回网站团队泳道的“制作页面并上预发布环境”，因此不通过的检查不会默认落到作者头上。
- 发布之后的日子：“检查收录、跳转与页面报错”，接着是“回顾日时页面是否达到内容目标？”，它的更新分支重新进入同一个修改步骤，于是改动过的表述要重新放行，而不是夹带上线。
何时使用本模板
- 稿子压了好几天，没人说得清它是在等编辑、等法务，还是在等一个部署窗口。
- 一句关于竞品、价格或性能数字的说法，在内容团队之外没有任何人读过的情况下上了线。
- 网站团队在预发布环节被要求修改文案问题，因为定稿是在文稿上完成的，而不是在做好的页面上。
- 两个人各自以为对方已经批过这篇稿子，结果它带着占位文字或者一个坏链接发出去了。
- 你们第一次把编辑工作流写下来，想要一张图，而不是四份在边界上互相矛盾的团队清单。
运作方式
先判断这些泳道是否值得占这么大篇幅
在改动任何东西之前，先确认你们的问题确实出在交接上。如果问题是初稿写得不好，泳道图帮不上忙，一条直线反而更好读。只有会做决定、或者会在等待期间把工作攥在手里的团队才配一条泳道，绝不要一人一条：以个人命名的泳道，在第一次有人换岗之后就不再描述这条流程了。
把泳道改成你们真实存在的职能
把作者、编辑、法务与合规、网站团队换成你们自己的。如果你们没有内部法务评审人，不要把检查跟着泳道一起删掉：把“逐条核对表述与其依据”移到编辑的泳道，并指明由哪位外部律师或合规负责人签字。只有在确实是同一个人既写又编的时候才合并作者与编辑泳道，而那也正是这张图不再是跨职能图的时候。
把表述触发清单写下来
“内容是否含受监管或比较性表述？”的好坏，全看它背后那份清单。把你们自己的记在这一步上：指名的竞品、价格或省钱数字、性能或安全宣称、客户名称与标识、医疗、金融或法律建议，以及任何受监管的用语。这个判断要留在编辑的泳道里。赶截稿的作者会绕开一道由自己负责的检查，而这正是这次跨界要防的事。
定下法务的时限，并指定一位评审人
模板假定有一个写明的时限（三个工作日是常见做法），并且每篇内容有一位指名的评审人。把你们真实的数字写在这一步上。“法务是否按原文放行这些表述？”的第三条分支要保留：背后没有带日期依据的表述不属于改稿情形，把它并入改稿分支，正是站不住脚的说法被改个措辞而不是被砍掉的原因。
把发布前检查换成你们自己的，并且对着预发布页面做
把你们的检查项列在这个判断步骤上：定稿文案是否已就位、标题与元描述、各级标题与替代文字、链接是否可用、移动端排版、嵌入媒体的同意机制。有两件事比清单本身更要紧：检查对象是预发布页面而不是文稿，以及不通过的项目退回网站团队，所以那条分支要一直指向“制作页面并上预发布环境”。
回顾日期在定稿时就定，不要往后拖
“定稿并确定发布日期”这一步同时也是回顾日期该定下来的地方，通常是 30 天或 90 天之后，判断依据是纲要里写明的目标，而不是只看流量。更新分支要保留，让它回到修改那一步：改动过的表述需要重新放行。如果你们团队确实从不回看已发布的页面，就把最后一个阶段整个删掉，而不是留下一个没人做的步骤。
常见问题
什么时候需要跨职能流程图，而不是普通流程图？
当失败发生在交接处的时候。把流程画成一条直线，然后看最近究竟出过什么问题。如果是步骤被做坏了，泳道只会加宽篇幅，不告诉你任何新东西。如果工作停下来是因为没人知道它到了，或者被做了两遍因为两个团队都以为是自己的，那么归属正是你缺的信息，泳道就是把它显示出来的办法。这里的发布流程满足这个检验：一句需要法务放行的表述，一个由网站团队上预发布环境却由编辑定稿的页面，两者都是跨界，而稿子丢就丢在这两处。
内容评审与发布流程有哪几个阶段？
五个，和这张图的阶段一一对应。撰稿：按一份写明受众、目标、目标网址与计划日期的纲要写作，然后附上资料来源、图片与替代文字。评审：校订准确性与文体规范，然后由编辑作出带修改循环的判断。审批：判断内容是否含受监管或比较性表述，把这些表述逐条对照依据放行，然后定稿并确定发布日期。发布：制作页面并上预发布环境，在页面上跑发布前检查，发布并提交收录。发布后：检查收录、跳转与报错，然后在定好的回顾日对照目标评判这一页。
内容评审与发布流程归谁负责？
编辑负责整条流程，别人都不在这个位置上。作者负责初稿和修改，法务与合规负责一句表述能否按原文站得住，网站团队负责做好的页面和部署。但编辑是唯一在五个阶段里出现四次的角色，这也是为什么表述触发点、文案定稿、发布前判断和发布后回顾都落在那条泳道里。如果你们的流程总是卡住，先看看这位端到端负责人到底存不存在，还是每个团队只是各做自己那一段，然后指望着。
这和 Visio 里的跨职能流程图比起来怎么样？
Visio 桌面版的模板叫 Cross Functional Flowchart，而 Microsoft 自己的文档里这个名字的连字符写法前后不一致，所以不要把它读成两种东西。那里有两件事常让人意外。阶段不是泳道的属性，而是拖到泳道上的独立 Separator 图形；删掉一条泳道会连带删掉里面的每一个图形，Microsoft 记录在案的规避办法是先把那些图形整个移到图外。在网页端，跨职能流程图需要 Visio Plan 1 或 Plan 2，随 Microsoft 365 附带的那个 Visio 层级里没有它。这里泳道是步骤本身的一个取值，所以重新分配一个步骤，就是改那一行。