如何制作可视化 SOP
如何做一份可视化 SOP：图承载顺序、责任人、决策和交接，文字承载容差、判定标准、警示和记录，而培训挂在唯一一个已批准的版本上。
运作方式
先定下图要为什么负责
动手之前先把分工写下来：图负责顺序、责任人、决策和交接，文字负责容差、判定标准、参数设置、警示和记录。现有程序里的每一句话于是都有了去处，关于该收进什么的争论，也就不再是一场关于品味的争论。
把每个步骤削到只剩一条指令
在整个量程上取五个点比对示值、并先让器具稳定下来——这是一个步骤加两条细节。标签里留下动词和它的宾语；五个点和稳定时间放进这个步骤的备注。一个会被人一边干活一边看的标签，长度保持在十来个字以内。
把步骤填进去，再把问题做成形状
每一行的“方框文字”就是一个方框。任何在提问的行，把它的“形状”列设为决策；“连线至”列填这个步骤通向的行号，“连线文字”按同样的顺序填每条箭头上的措辞。一个关于容差的决策要的是结果状态——“在允差内”“超差”——而不是是和否。
把细节挂到它管辖的那个步骤上
把接受规则放在它所判定的那个决策上，而不是放进一段开场白：判定之前是否要扣除标准器的不确定度、要核查几个点、以及示值正好压线时由谁来定。挂在步骤上的细节，是有人在它真正适用的那一刻会读到的细节。
把每个步骤的责任人放进泳道
执行某个步骤的角色填进它的“垂直泳道”列，阶段填进“水平泳道”列——两者都是这一行上的纯文本，于是归属是数据，而不是一个位置。填好之后，从“开具超差报告”往后的五行连成一条“质量经理”带：程序已经完全离开技术员的手。
只照着图跑一次真实作业
把图交给一位没有做过这个程序的技术员，看着他只凭这张图做完一次真实的校准，中途不回答任何问题。他每问一个问题，都点出一处放错层的细节；他每一次没有按画出来的顺序做，都是一条需要修正的路线。经得起这一趟的版本，才是拿去批准的那个版本。
常见问题
什么让一份 SOP 是可视化的，而不只是配了插图？
看主版本是图还是文字。在可视化 SOP 里，图是受控文件，书面细节挂在各个步骤上；在配了插图的 SOP 里，文字是程序，图只是把它概括一遍。判别方法是看流程变更时会发生什么。如果改的是图，细节随之而来，那么这份 SOP 是可视化的。如果两份文档都得改，那么其中一份已经过期了，而且没有办法分辨是哪一份。
一份可视化 SOP 还应该有多少文字？
工作需要多少就多少，但要按步骤存放，而不是写成一段叙述。某一个步骤可能带着一整段——量程上的取点、稳定时间、不确定度规则——而它后面三个步骤什么都不带。不应该存在的，是一份与图并行的连续散文版本，因为它把顺序复制了一遍，而被复制的顺序正是会走偏的那样东西。挂在步骤上的细节不可能与流程矛盾；一份平行的叙述可以，而且迟早会。
容差和接受准则放在哪里？
放在它们所判定的那个决策上。“调整前示值是否在允差内？”只有在规则跟着它一起走的时候才是可重复的：核查了哪几个点、判定之前是否扣除标准器的不确定度、以及示值正好压在限值上时由谁来定。改为归在某一章规范里，这条判定标准在被需要的那一刻就隔着三次点击，而那个宽松的放行会悄悄变成本地的标准。
审核员会接受可视化 SOP 吗？
审核员对格式无所谓，对控制却很具体。他们会问的是：是否存在唯一一个权威版本、谁在什么时候批准的、与上一版相比改了什么、做这项工作的人是否受过现行版本的培训，以及程序要求的那些记录有没有真的产生。这五个问题，一张图回答起来和散文一样顺，而且它把审核员本来要从一句句话里重建出来的分支直接摆了出来。