如何建立流程文档体系
如何搭一个两年后依然站得住脚的流程文档体系：一份指名责任人的流程清单、按变动频率设定的复审间隔，以及给每一张滞后的流程图记上一个日期。
流程文档体系让一整套流程文件长期保持真实：一份每条流程只有一位指名责任人的清单、一个真能送达那位责任人的复审日期，以及一个有人去测量的失效速度。
简而言之
- 先有清单，再有文件：一条流程一行，一位责任人，一个到期日。
- 在第一份文件之前先搭元流程：创建、审批、发布、培训、废止。
- 把整个文档库平均起来，一份文件有半个复审周期是过时的。
- 先于流程图进入生产的变更，是一条带日期的文档缺陷。
- 什么都没改的复审，同样欠登记册一条带日期的记录，否则准确会看起来像失管。
体系是元流程，不是模板
任何一家组织都能产出五十份流程文件，而且有好几家已经产出过两遍。文档体系要解决的不是它们写得怎么样，而是两年之后关于它们还有什么是真的。这笔账并不客气：如果除了日历没有别的东西迫使人回头看，那么年度复审后一周发生的变更，会有大半年无人察觉；把整个文档库平均起来，一份文件有半个复审周期都在描述已经挪走的工作。一个写作模板对这个数字毫无影响。
所以第一件产出物不是一份文件，而是一份清单：组织跑的每一条流程各占一行，各有一位指名的人对它的描述负责，写明它被记录到什么颗粒度，以及一个复审间隔。接下来才是元流程——流程文件被创建、审批、发布、培训和废止所走的那条路。没有它，每一份文件都由碰巧还记得它的人来维护，而流程先于流程图变化时该怎么办，从来没有被写下来过。
下面呈现的正是这条元流程本身，而不是它所管辖的某一条流程。“确认该制度的责任人”是第二行，排在任何分析开始之前。“制度是否需要修订？”的“无需修订”出口通向“记录本次审查并设定下次到期日”——一次什么都没改、却仍然把日期往前推的审查，正是一个正在老化的文档库永远没有的那条记录。而“退回修改”把审批决定送回“用修订模式起草修订稿”。
用五个阶段搭出元流程
文档库赖以运转的元流程，而不是库里的某一条流程。读它是为了看清一份制度发布之后，登记册还应当拿到什么。
先有责任人，再做分析
触发是一个到期日或一个事件，紧接着那一行在读任何东西之前先“确认该制度的责任人”。“制度是否需要修订？”随后把“无需修订”当成一个真正的结局：“记录本次审查并设定下次到期日”正是让登记册对文档年龄保持诚实的那一条。
征求意见不是客套
先用修订模式起草，再走相关业务部门，然后是合法合规性审核。“是否需要履行民主程序？”把流程引向职工代表，而“不同意”终于“转入正式协商程序”——一个落在文档库控制之外的结局，被画了出来，而不是被默认。
分级审批让最高层腾出手
“适用哪一级审批权限？”一分为三，走向董事会、经营层和制度委员会，三条路又都汇到“审批结论？”。它的“退回修改”出口指回起草那一行；“否决”把修订撤下，旧版本继续有效。
发布要写回登记册
登记册由两行写成：“发布新版本并公示告知”和“作废并归档旧版本”。新的版本号、发布日期和下一个复审日期都出自它们。一个不写回任何地方的发布步骤，只会留下一本自己变老的登记册。
发布之后还欠的事
一个重大性判定决定要不要培训，阅读签认按受影响人员记录，而“更新例外与豁免登记册”抓的是那些针对已不存在条款批出的豁免。体系终于“修订后的制度正式生效”，而不是终于发布。
运作方式
先写流程清单，再画任何图
把组织跑的每一条流程列出来，一条一行，写上对它的描述负责的那个人名、它应当被记录到什么颗粒度，以及它有多关键。要预料到这份清单比担心的要短，而归属那一列会是争论的焦点。只要那一列还有空格，别的东西都建不起来。
按变动频率定复审间隔
从这条流程过去两年实际改动的频次来取间隔，而不是从制度里的默认值来取：改过三次的定六个月，五年没动过的定两年。把间隔、下一个到期日和记录颗粒度都写进清单，这三件事就不必在每次修订时重新吵一遍。
先把元流程搭成一张图表
在记录任何一条真实流程之前，先把你们自己那条文档路线写成行：什么触发复审、谁确认责任人、要征求谁的意见、谁审批、怎么发布和培训。把这些阶段填进“方框文字”一列，用“连线至”一列按行号把它们连起来。后面每一份文件都从它继承。
把审批层级作为决策放到图上
分流那一行的“形状”填决策，各个层级按“连线至”里的数字写进“连线文字”，这样一次修订走哪条路，在起草之前就已经确定。用“横向泳道”一列放阶段，用“纵向泳道”一列放责任人，让图表显示出制度归口部门和审批机构不是一回事。
把退回回路画成一个向后的行号
审批把工作退回去，是一个指向更靠前那一行的行号，而不是事后有人在图上补画的一支箭头。因为“连线至”一列装的是数据，这条回路在它上方插入一个步骤之后依然成立。一张只有向前流动的图表，描述的是一个从未有过一次不同意见的审批机构。
拿文档库自己的日期去审它
每个季度数四个数：过了复审日期的文件、没有指名责任人的文件、流程先于流程图变化的文件，以及复审后没有改动的记录。最后一个是健康指标。在结束这一次清点之前，先把下一次写进清单，因为没有下一个日期的清点会自然失效，文档库随即恢复衰减。
应避免的错误
把文档当成一个项目来做
项目交付了文档库，随后解散，衰减从它结束的那一周就开始。文档工作要么是一项有责任人、有预算科目的常设职能，要么就是某一个季度的快照，而快照老得很快。
把提醒发给一个部门
写着“由运营部负责”，等于这个到期日谁也没送到。一个部门没有日历，也没有会回信的收件箱，于是提醒被生成、被发给一个职能，然后没有哪个具体的人真正读它。
只复审架子上有的东西
复审周期只能作用于它手上那份清单，所以那些根本没有文件的流程，永远不会被它浮出来。清单要从组织实际做的工作里长出来，而不是从现有文件的那个文件夹里长出来。
变更几周之后才补文档
三月改动、五月才补上文档的流程，错了八周，而文档库里没有任何东西记下这一点。把这个间隔连同日期一起记下来；这些间隔连成的形态，会指出体系在哪里漏水。
搭建自己的文档体系
把制度审查示例打开为你们自己的图表，然后定下你们文档库将要依据的责任人、审批层级和复审间隔。
相关指南
常见问题
什么是流程文档体系？
它是让一整套流程文档保持真实的那套规则和角色，与文件本身是两回事：一份每条流程只有一位指名责任人的清单、每条流程被记录到什么颗粒度、一个到期日真能送达那些责任人的复审间隔、一个被测量出来的文档库落后于实际工作的速度，以及一条创建、审批、发布和废止文件的路线。模板是其中最不重要的。真正的检验是：对一份三年没人碰过的文件，登记册说了些什么。
流程清单里应该有什么？
一条流程一行：流程名称、作为个人而不是团队的责任人、它被记录到的颗粒度、关键程度、现行版本存放在哪里，以及最近一次复审和下一次到期的日期。另外两列很快就能赚回自己的位置——这条流程运行在哪些系统里，它告诉你一次系统迁移会让什么失效；以及它是为满足哪一条条款而存在的，它告诉你审核员会要求看什么。清单先行，因为后面每一个决定都是对它的一次查询。
流程文档体系应该由谁负责？
由一个人负责，而且不是持有文件最多的那个人。体系责任人掌管清单、元流程和复审日期登记册；每份文件的责任人掌管内容。把两者合并，就会出现那个熟悉的故障：每一次修订都排在唯一那位懂这套体系的人后面，而这条队列会被当成人手问题上报，而不是被当成设计问题。只要提醒是自动的、每位责任人都是一个名字，每周半天就能撑起五十条流程的文档库。
流程文档应该存放在哪里？
清单说在哪里就在哪里——这正是存放位置要成为清单里的一列、而不是对整个文档库拍板一次的原因。质量管理体系、wiki 和共享盘都能存放一个现行版本；但它们谁也说不出哪些流程根本没有现行版本。所以真正的检验不是选哪个平台，而是登记册里每一行是否都写明了它把读者送去的地方，以及到了那里拿到的是不是登记册所声称的那一版。清单里没有行的流程，对任何平台选择都是不可见的。
