如果一个<流程步骤>没有明确规定负责完成的人,EBPM 方法论就认为这个<流程步骤> 存在 “组织断点”,也就是说端到端流程中的 “组织断点” 是针对一个具体的 <流程步骤> 而言的,而且细化到具体的 “人”。
01
—
”组织断点“ 的各种类型
如上图所示,<活动A>、<活动B> 和 <活动C> 都没有落实到具体的 “人”,所以都存在 “组织断点”。而<活动D>由于只关联了一个<角色>、一个<岗位>,而这个<岗位>中只有一个 “人”,所以<活动D>的实例任务一旦产生就由 “张三” 来完成,这个规则是明确的。总之,因为<活动D>的任何实例任务都能落实到具体的负责执行 “人”,所以<活动D> 没有“组织断点”。
上图中,<活动A> 没有落实到具体的 “人”,所以存在“组织断点”。但<活动B>落实到具体的 “人”了,为什么还是有 “组织断点”呢?因为,<活动B>落实到了不止一个 “人”。因此,还需要进一步明确究竟是 “任何一个实例任务这些人都可以完成,谁完成了都算” 还是 “每一个实例任务只能从这些人中选择一位来完成"。
<活动D>通过<授权规则:上一步完成人所属部门的主管>明确了<角色-岗位-规则-人员>所关联的两个人员的选择规则。每一个实例任务都基于规则从这两个人员中选择唯一的一位来负责完成,这样确保了每一个实例任务都可以落实到具体的“人员”,因此<活动D>不存在“组织断点”。
上图中,<活动D>中的<授权规则>也可以是<共同完成>。这是什么意思呢?就是<活动D>这项任务,同时派发给“张三”和“李四”,他们同时收到此“待办事项”。两人都可以提交完成此“待办事项”,其中任何一个人提交完成了,<活动D>就算完成了。这种情况,自然也不存在“组织断点”。
上图中,<活动D>中的<授权规则>是<由上一步骤完成人选择本步骤的完成人>。这是什么意思呢?就是由<活动C>的完成人,在提交完成时,从“张三”和“李四”中选择一位来完成<活动D>,他选谁,谁就负责完成。这种情况,也不存在“组织断点”,因为<活动D>还是可以基于规则确认具体完成人的,只不过这个规则是<由上一步骤完成人选择本步骤的完成人>而已。
02
—
”组织断点“ 带来的问题
可能又会有人要问了,“组织断点” 在企业现有的流程图中同样是大量存在的,也没看到有什么问题啊?
是的,同 “信息断点” 类似,企业现有的流程图中,能按上述逻辑严谨描述流程步骤完成人的少之又少。那为什么似乎没有造成什么大的问题呢?因为,执行者又会祭起 “脑补”、“打听” 和 “试试” 三大 “法宝”来 消除这些 “断点”。
比如,下一步骤仅描述为由<主管领导>或者<相关部门>这个角色来完成,那么本步骤的完成人就会自己 “脑补” 谁是<主管领导>或者<相关部门>是找哪个部门的哪个人。如果 “脑补” 不出来,可以 “打听”,然后可以 “试试”,试着找张三来完成,张三说不是他该做的,那再找李四,最后总能找一个完成人,实在找不到,就向自己的主管反应和求助。接下来,主管再来一轮 “脑补”、“打听” 或 “试试”。
在企业内部,常常会听到这样的说法:“没有必要也不可能描述得这么细,业务人员一般自己都知道该找谁的。”
如果您认同上述观点和做法,那么 “组织断点” 不消除也罢。但是,不管您认不认同上述观点和做法,当企业致力于流程的数字化转型时,“组织断点” 就必须消除了。不然,在数字化的流程中,您会切实感受到什么叫 “断点”。因为,流程每运行一步,都会停下来请 “人” 来选择或决定下一步骤的完成人,人不选就不能往下运行。此时,就又要来一轮 “脑补”、“打听” 或 “试试”。
当前,很多企业内部的审批流程都会在 OA 系统中运行。流程设计者所绘制的审批相关的流程图中也有大量“组织断点”,但在 OA 系统中之所以能够运行,也是因为 I T人员通过调研人为补上了相关规则。也就是说,同一条流程的内容,一部分在图中体现,一部分在 OA 系统中设置。
03
—
”组织断点“ 的消除
消除“组织断点”的方法就是确保每一个与<流程步骤>关联的<角色>都明确了如何落实到“人”的规则。本公众号前期发表的文章《职能流程图解惑 | 角色人员选择表:制定 “谁来做” 的规则》中介绍了<角色人员授权表模型>的构建方法,这个模型就是专门用来消除“组织断点”的,这里不再赘述。当然,这套模型需要在数字化的平台上运行,才能真正发挥作用,消除 “组织断点”。