如何绘制流程中的交接
如何绘制流程中的交接：找出工作每一次易手的位置，写下接收方是怎么被告知的，并量度那段等待。附一个可直接操作的员工离职示例。
绘制交接，就是找出工作每一次易手的位置，写下接收团队是怎么知道自己有活的，并量度它在有人动手之前等了多久。
简而言之
- 大多数流程的周期时间是团队之间的排队时间，而不是团队内部的作业时间。
- 每一次交接都有一套触发机制、一段等待时间和一个受理条件。
- “他们会看共享邮箱”是一个没有负责人的队列，不是一套触发机制。
- 把跨越次数数出来：次数太多说明工作切分错了，而不是画错了。
- 迟到代价高昂的交接，应该画成决策，而不是步骤。
工作并不是停在某个步骤里
把任何一条运营流程端到端量一遍，算出来的账通常都不好看：作业只要几个小时，流程却要几天。这个差额不是步骤内部效率低。它是步骤之间的空隙——一个团队做完了、下一个还没开始、当下没有任何人把这件事项当成自己的，就是那段时间。这些时间段就是交接，而它们几乎从不被记录下来，因为没有任何单一团队亲身经历过它们。
交接不是一支箭头。它是一个事件，有三条值得写下来的属性：触发机制（接收方是怎么发现的）、等待时间（他们隔多久才动手），以及受理条件（他们要有什么才能开始）。一次画成普通直线的流转，暗示这三样都是即时且完整的——而恰恰是这个假设，造就了一条人人都觉得没问题的流程，和一位仍在等待的客户。
下面的示例是员工离职，它几乎从头到尾都是交接：人力资源到主管，主管到 IT，IT 回到人力资源，然后是薪酬和后勤。它还包含整个人力资源领域里迟到代价最高的那一次交接——当天撤销权限——这也正是它被画成一个决策、而不是被留成一个总有人会去做的步骤的原因。
一条几乎全是交接的流程
跨人力资源、主管、IT、薪酬与后勤的员工离职流程。留意工作易手的频率有多高。
第一次跨越就开始计时
辞职或解雇通知到达人力资源，按主动离职与被动离职分成两支，最后一个工作日由主管确认。下游所有期限都挂在这个日期上，所以传递这个日期的那次交接，正是值得计时的那一次。
不能迟到的那次交接
“是否需要立即中断权限？”会通向当天撤销。把它画成决策而不是步骤是有意为之：这样就逼着某个人在第一天回答这个问题，而不是把它留在一份 IT 要到周四才看到的清单里。
会被打回来的交接
工作移交方案、项目转手和操作手册更新都在主管手上，随后是一次可以把整件事退回去的签核决定。一次被退回的交接是第二次跨越，而这一次没有人数进去，离职流程通常也正是在这里超时的。
最后一天同时行动的三个团队
人力资源做离职面谈、薪酬部门结算最后一期工资、后勤回收资产，最后由 IT 撤销剩余权限——并有一条资产未归还时退回薪酬的路径。四条泳道在同一天行动，只有在每一方都知道那个日期时才成立，于是又回到第一阶段。
人走之后的那些交接
最后一期工资发放，档案按保存政策归档。离职流程里最常缺失的就是离职之后的这些步骤，因为到那时已经没有人在催，而本来会发现问题的那个人已经走了。
运作方式
先用泳道把流程画出来
只有当流程按负责人切开之后，交接才会显形。把每个步骤放进执行它的那个角色的泳道里——在 QueryChart 里就是“垂直泳道”列——那些跨越就会自己浮出来，不需要任何人专门去找。
标出每一条越过泳道的连线
一条一条走过去，把它们列成清单。一条十五个步骤的流程跨越泳道八次，是很正常的，也值得知道；这个数字本身往往是整个练习里最有说服力的东西，正因为从来没有人见过它。
写下接收方是怎么被告知的
对每一次跨越，把触发机制写进这个步骤的备注里：系统里的一次状态变更、一张指派过来的工单、一封邮件、一个共享队列、一次站会。凡是诚实的答案是“他们自己会看”的地方，您就找到了一个没有负责人的队列，和一段没有人在量的等待。
写下接收方要有什么才能开始
受理条件和触发机制一样重要。没有确认的日期，IT 无法开通或回收；不知道资产归还情况，薪酬无法结清。交接失败，出在信息不完整上的次数不比出在通知太晚上的少，而这两者的解法并不相同。
给等待时间计时，哪怕很粗略
问每一个接收团队：一件事项通常放多久他们才会接手。粗略数字就够了——重点是形状，而这个形状几乎总是：一两次跨越占掉了大部分的实际耗时。把数字写在步骤上。
先修机制，再改流程
大多数交接问题靠改触发机制就能解决——用一条通知取代靠人查看，用一个有指名负责人的共享队列取代一个邮箱——而不是靠搬动工作。只有当这次跨越根本就不该存在时，才去重新设计流程。
应避免的错误
把交接画成一支普通箭头
一次没有任何注解的跨越，暗示的是即时且完整的移交。那些不见了的天数，就藏在这个假设里。
数步骤而不是数跨越
步骤数告诉您有多少工作量。跨越数告诉您它要花多长时间。两者经常毫无关系。
在一条泳道内部做优化
把某个团队自己的步骤做快很有成就感，而且通常什么也改变不了，因为事项一生中的大部分时间是在泳道之间，而不是在泳道里面。
想当然地认为接收方知道
“他们在系统里看得到”只有在真有人去看时才算触发机制。要问他们什么时候看，以及多久看一次。
绘制你们自己的交接
把员工离职示例打开为您自己的图表，重命名泳道，并在每一次跨越上注明下一个团队是怎么被告知的。
相关指南
常见问题
什么是流程交接？
它是一件工作的责任从一个人、一个团队或一个系统转到另一方的那个点。它有三个值得记录的部分：接收方是怎么被通知的、他们要有什么才能开始，以及在他们动手之前这件事项等了多久。交接之所以影响格外大，是因为没有任何单一团队亲身经历它——发送方认为工作已经完成，接收方还没开始，于是这段间隔不属于任何人，也没有任何人在量它。
我怎么找出一条流程里的交接？
按每个负有问责的角色一条泳道把流程画出来，然后把每一条跨越泳道边界的连接都列出来。那就是完整的清单。任何别的做法——问大家延迟在哪里、翻工单——找到的都是那些已经引起投诉的跨越，而会漏掉那些只是慢的。在 QueryChart 里，泳道归属就是电子表格里的一列，所以这些跨越可以直接从行里点算出来。
交接多少次算太多？
没有一个绝对数字，但比例很说明问题：如果一条十五个步骤的流程跨越泳道十次，那么工作几乎每一步都在易手，责任的切分很可能是错的。去找一条本可以整体承担一段连续区块的泳道，而不是让它把同一件事项接进来又送出去两遍。减少跨越次数，通常胜过把其中任何一次做快。
怎样缩短交接造成的延迟？
先改触发机制，再改流程。大部分延迟来自接收方不知道有活——一个没人负责的共享邮箱、一个没人盯的状态字段——把它换成一条真正的通知，或者一个有指名负责人的指派队列，就能在完全不动谁做什么的前提下把等待消掉。只有当一次跨越根本不该存在时，才去重新设计流程；而当它必须存在时，就给它一位负责人。
