如何绘制流程中的交接
如何绘制流程中的交接：找出工作每一次易手的位置，写下接收方是怎么被告知的，并量度那段等待。附一个可直接操作的员工离职示例。
运作方式
先用泳道把流程画出来
只有当流程按负责人切开之后，交接才会显形。把每个步骤放进执行它的那个角色的泳道里——在 QueryChart 里就是“垂直泳道”列——那些跨越就会自己浮出来，不需要任何人专门去找。
标出每一条越过泳道的连线
一条一条走过去，把它们列成清单。一条十五个步骤的流程跨越泳道八次，是很正常的，也值得知道；这个数字本身往往是整个练习里最有说服力的东西，正因为从来没有人见过它。
写下接收方是怎么被告知的
对每一次跨越，把触发机制写进这个步骤的备注里：系统里的一次状态变更、一张指派过来的工单、一封邮件、一个共享队列、一次站会。凡是诚实的答案是“他们自己会看”的地方，您就找到了一个没有负责人的队列，和一段没有人在量的等待。
写下接收方要有什么才能开始
受理条件和触发机制一样重要。没有确认的日期，IT 无法开通或回收；不知道资产归还情况，薪酬无法结清。交接失败，出在信息不完整上的次数不比出在通知太晚上的少，而这两者的解法并不相同。
给等待时间计时，哪怕很粗略
问每一个接收团队：一件事项通常放多久他们才会接手。粗略数字就够了——重点是形状，而这个形状几乎总是：一两次跨越占掉了大部分的实际耗时。把数字写在步骤上。
先修机制，再改流程
大多数交接问题靠改触发机制就能解决——用一条通知取代靠人查看，用一个有指名负责人的共享队列取代一个邮箱——而不是靠搬动工作。只有当这次跨越根本就不该存在时，才去重新设计流程。
常见问题
什么是流程交接？
它是一件工作的责任从一个人、一个团队或一个系统转到另一方的那个点。它有三个值得记录的部分：接收方是怎么被通知的、他们要有什么才能开始，以及在他们动手之前这件事项等了多久。交接之所以影响格外大，是因为没有任何单一团队亲身经历它——发送方认为工作已经完成，接收方还没开始，于是这段间隔不属于任何人，也没有任何人在量它。
我怎么找出一条流程里的交接？
按每个负有问责的角色一条泳道把流程画出来，然后把每一条跨越泳道边界的连接都列出来。那就是完整的清单。任何别的做法——问大家延迟在哪里、翻工单——找到的都是那些已经引起投诉的跨越，而会漏掉那些只是慢的。在 QueryChart 里，泳道归属就是电子表格里的一列，所以这些跨越可以直接从行里点算出来。
交接多少次算太多？
没有一个绝对数字，但比例很说明问题：如果一条十五个步骤的流程跨越泳道十次，那么工作几乎每一步都在易手，责任的切分很可能是错的。去找一条本可以整体承担一段连续区块的泳道，而不是让它把同一件事项接进来又送出去两遍。减少跨越次数，通常胜过把其中任何一次做快。
怎样缩短交接造成的延迟？
先改触发机制，再改流程。大部分延迟来自接收方不知道有活——一个没人负责的共享邮箱、一个没人盯的状态字段——把它换成一条真正的通知，或者一个有指名负责人的指派队列，就能在完全不动谁做什么的前提下把等待消掉。只有当一次跨越根本不该存在时，才去重新设计流程；而当它必须存在时，就给它一位负责人。