4. 责任协同的组织地图

质量工单一旦进入跨部门流转，最容易出问题的往往不是“谁不负责”，而是“谁先负责、负责到什么程度、把什么交给谁”。责任协同的组织地图，本质上是把一张工单从发起到关闭所经过的角色、职责边界和接口关系显性化。它不替代组织架构图，而是回答一个更具体的问题：当某个质量事件发生时，哪个角色是主责、哪个角色是配合、哪个角色是决策、哪个角色是知会，以及角色之间用什么信息、在什么时点完成交接。

先明确一个基本约定：本节所说的“主责”指对工单最终闭环结果负责的角色，拥有推进、协调和关闭建议权；“执行”指实际完成分析、处置或验证动作的角色；“决策”指对处置方案、放行、让步或升级拥有批准权的角色；“知会”指需要同步信息但不承担推进责任的角色。同一角色在不同工单类型中可能切换身份，例如来料不良时采购可能是主责，而制程不良时生产或工艺才是主责。因此，组织地图必须与工单类型绑定，不能只画一张静态的部门关系图。

上图以制程不良工单为例，展示了七个角色域之间的主责推进与知会协同关系。需要强调的是，这张地图不是固定不变的，它随工单类型切换主责角色。例如来料不良工单中，采购或SQE成为主责，质量转为判定与关闭确认角色；客诉工单中，客服成为信息入口，质量转为内部推进主责。因此，实际落地时建议为每一类工单单独定义一张责任矩阵，而不是共用一张通用图。

职责边界的核心在于“三定”：定主责、定交付物、定时限。以制程不良工单为例，质量在发起时必须在工单中写清缺陷现象、发生批次、机台编号、发现工位和初步判定；生产在接单后需在约定时限内完成隔离与停线确认，并回填实际处置数量与工时；工艺在收到根因分析请求后，需给出参数窗口对比、可疑因子排序和验证方案；研发在涉及设计变更时，需输出ECN编号与验证结论；采购在来料类工单中负责对接供应商并跟踪8D；供应商需提交整改报告与批次追溯证据；客服则负责同步客户影响范围与客诉升级信息。每个角色的交付物就是下一个角色的输入，接口断点往往就出现在交付物不完整或时限未约定上。

接口定义要落到字段级，否则协同仍然靠口头和邮件。建议在工单系统中为每个交接节点设置必填字段和校验规则。例如质量派单给生产时，必填“缺陷代码、发生批次、机台号、发现时间”；生产回传处置结果时，必填“隔离数量、返工数量、停线时长、处置人”；工艺回传分析结论时，必填“根因分类、验证方法、验证结果、参数变更点”；供应商回传整改时，必填“8D编号、整改措施、生效批次、验证证据”。这些字段不是管理装饰，而是判断工单能否进入下一节点的客观依据。缺少任一必填字段，系统应阻止流转并提示补全。

下面给出一份可直接参考的责任矩阵示例，用于制程不良工单。表中“R”代表主责推进，“E”代表执行，“D”代表决策，“I”代表知会。该矩阵可作为工单系统角色权限配置的输入。

实际运行中，最常见的接口断点有三类。第一类是“判定权模糊”：质量判了不良，生产认为可返工，工艺认为参数正常，三方各执一词导致工单停滞。解决方式是在工单类型定义中明确判定权归属，例如制程不良的最终判定权归质量，但工艺有异议时可发起升级评审，评审时限不超过4小时。第二类是“交付物缺失”：供应商提交的8D只有原因没有验证证据，采购无法判断整改是否有效。解决方式是在供应商接口中强制要求“整改措施+生效批次+验证数据”三项齐全，缺一不可。第三类是“知会遗漏”：客服未及时同步客户投诉升级信息，导致内部处置优先级偏低。解决方式是将客诉等级作为工单优先级字段，由客服在发起或升级时写入，系统自动调整工单时限。

最后需要说明的是，组织地图的价值不在于画得漂亮，而在于让每个角色在接到工单时能立刻回答三个问题：我是不是主责？我要交付什么？我什么时候必须交？当这三个问题在系统中都有明确字段和时限约束时，责任协同才真正从“靠人盯”转为“靠机制跑”。