在流程设计的时候，“角色”是一个关键的要素，它关乎流程最后是否有对应的人来负责执行；同时，“角色”也是诸多流程设计者遇到的关键障碍之一。很多流程设计者，因为ISO体系的长期熏陶，已经习惯了用岗位、部门的方式来设计，突然来一个“虚”的角色，使用起来难免有些别扭。同时，也有诸多的不解，为什么要这样呢？这个需要了解其背景及问题。

在ISO体系下的程序文件，流程图都习惯用部门、岗位来与活动对应，更有甚者，只有简单的活动说明、描述，没有明确承接的组织或人。如下图所示：

图3.10 某公司不合格品管理流程图

上图是比较常见的推行ISO体系的公司使用的流程图，图中加粗部分是用部门进行定义。这样会产生几方面的问题：

第一，部门是一个很宽泛的词，比如制造部，里面还分了很多下一层级的部门/小组，如：工程、工艺、维修、设备管理等；颗粒度太大，导致每次都要找部门最高负责人拍板，指定负责人，层层指派，难以快速响应处理问题。

第二，国内的企业，一个习惯性的做法是组织架构经常变，而且部门的名称命名相对比较随意，组织架构变化了，部门的名称变了流程就得跟着变化，稍不留神没有及时更新，流程就找不到主了。

另外，有些公共类的流程，比如《请假申请流程》，在公司里，谁都有可能要用到《请假申请流程》，对应部门的话就无法做了。

回归到角色定义上来，角色是指已定义好的标准执行者，负责流程活动的执行及输出。如：IT需求申请人、IT方案审批人、合同注册专员、EMT（经营管理团队）、IPMT（集成组合管理团队）等。

如果某个岗位，在公司内是很容易识别到，具有唯一性，在定义角色的时候可以用岗位名称作为角色，如董事长、总经理等，但忌用部门或其他无法快速识别的岗位名称做角色。如，工艺工程师，有些公司在研发部门有工艺工程师，在制造端还有工艺工程师，在定义角色的时候工艺工程师就不是一个好的选项。

在某些公司，物控工程师、客户经理，在公司内是可以快速识别的岗位类别，可以用做角色定义（如图3.11所示）。当然，这个时候角色依然不能直接等同于岗位/职位，即便是工程师，也有不同的等级划分，具体的分工可能也会有所不同，依然需要通过匹配关系来定义好，避免执行的时候出现偏差。

图3.11 流程角色展现

在实际设计流程的时候，根据实际的业务场景、公司环境来确定哪些岗位可以直接用来定义为流程角色，哪些必须另外去定义，不能一概而论。可以说，小“角色”，大用途；小改变，大改进。