从项目审批卡壳到跨部门推诿扯皮看责任链模式如何重构沟通流程让每个环节权责清晰避免踢皮球现象发生

你有没有经历过这样的下午：

一个本该半小时就能敲定的项目立项申请，在OA系统里躺了三天。

销售说：“技术还没评估完风险。” 技术说：“产品需求文档写得不清不楚，我怎么评估？” 产品说：“销售当时口头承诺了功能，我没写进文档。” 销售经理说：“我没让你写那么细，这是常识。” 产品经理说：“常识不能当需求，要背锅的是我？”

……

于是这个项目就那样卡在那里，像一滩烂泥，谁都不愿伸手去扶，谁都觉得自己不是那个“该负责的人”。

最后，老板问起来，大家面面相觑，都说“正在推进”，其实谁都知道，这事儿根本没推进。

这不是你一家公司的困境。这是大多数传统组织架构里的“责任真空”。

很多人把这种问题归结为“人性”——推诿、懒政、部门墙、本位主义……

但我想告诉你一个反直觉的观点：

这不是人的问题，是流程设计的问题。

只要流程里存在“模糊地带”，只要没有人在特定节点对特定结果负责，推诿就是理性选择。

今天，我不想跟你讲大道理，我想跟你聊一个编程里的设计模式——责任链模式（Chain of Responsibility Pattern），以及它如何被巧妙地迁移到组织管理和流程重构中，彻底消灭“踢皮球”。

一、先理解什么是“责任链”

1.1 编程里的故事

在软件设计模式里，责任链模式解决的是一个经典问题：

当一个请求产生时，有多个对象可能处理它，但事先不知道哪个对象会处理，也不希望请求发送者和多个接收者之间产生耦合。

举个代码里的例子：

假设你有一个日志系统，日志分为四个级别：DEBUG、INFO、WARN、ERROR。

你不想写一堆 if-else 判断：

if (level == "ERROR") {
    errorLogger.log(msg);
} else if (level == "WARN") {
    warnLogger.log(msg);
} else if (level == "INFO") {
    infoLogger.log(msg);
} else if (level == "DEBUG") {
    debugLogger.log(msg);
}

因为这样太耦合了。万一哪天新增一个 TRACE 级别，你得改核心代码。

于是，你设计一个责任链：

每个处理器（Handler）手里都拿着“下一个处理器”的引用。请求进来，先看看自己能不能处理，能就处理；不能就传给下一个。

// 抽象处理器
abstract class LoggerHandler {
    protected LoggerHandler nextHandler;

    public void setNext(LoggerHandler next) {
        this.nextHandler = next;
    }

    public void log(String level, String message) {
        if (canHandle(level)) {
            doLog(level, message);
        } else if (nextHandler != null) {
            nextHandler.log(level, message);
        }
    }

    protected abstract boolean canHandle(String level);
    protected abstract void doLog(String level, String message);
}

// 具体处理器
class ErrorLogger extends LoggerHandler {
    @Override
    protected boolean canHandle(String level) {
        return "ERROR".equals(level);
    }

    @Override
    protected void doLog(String level, String message) {
        System.out.println("[ERROR] " + message);
    }
}

class WarnLogger extends LoggerHandler {
    @Override
    protected boolean canHandle(String level) {
        return "WARN".equals(level);
    }

    @Override
    protected void doLog(String level, String message) {
        System.out.println("[WARN] " + message);
    }
}

// 组装链条
LoggerHandler errorLogger = new ErrorLogger();
LoggerHandler warnLogger = new WarnLogger();
LoggerHandler infoLogger = new InfoLogger();

errorLogger.setNext(warnLogger);
warnLogger.setNext(infoLogger);

// 发送请求
errorLogger.log("ERROR", "系统崩溃了"); // 只有ErrorLogger处理
errorLogger.log("WARN", "内存不足");   // 只有WarnLogger处理
errorLogger.log("DEBUG", "变量x=1");   // 只有InfoLogger处理（假设Info能处理所有）

关键点在于：

请求者（调用方）只关心第一个处理器是谁，不知道也不关心后面还有谁。
每个处理器只负责自己该管的，不管就往后传。
链条可以动态组合，新增处理器只需修改组装代码，不影响现有逻辑。

1.2 把它映射到现实

现在，把这套逻辑搬到你的公司里。

原来的流程（命令链/瀑布流）：

销售提交 → 产品经理看 → 技术负责人看 → 财务看 → 老板批

看起来挺清晰对吧？

但问题在于：

每个节点都是“总负责人”，大家都觉得自己是第一责任人，也都觉得后面的人应该把关。
没有明确的“我能处理什么”的判断标准，销售提交了一个缺材料的申请，产品经理可能看一眼就扔回去，也可能自己改，也可能假装没看见——结果就是卡住。
下游可以无限推给上游，上游可以无限等下游，形成死循环。

引入责任链后的流程：

销售提交申请 → [格式审核岗] → [技术可行性岗] → [成本核算岗] → [决策岗]

每个岗位的职责边界被明确定义：

格式审核岗：只检查材料是否齐全、格式是否规范。不判断技术可行性，不判断成本。材料不齐，直接打回；材料齐，自动流转到下一个。
技术可行性岗：只评估技术风险。不看成本，不看销售策略。有问题，给出明确结论和风险等级；没问题，自动流转。
成本核算岗：只算账。不参与技术决策，不参与销售谈判。有问题，给出数据；没问题，自动流转。
决策岗：根据前三个环节的输出，做最终拍板。

关键改变：

每个节点只对自己的职责范围内负责，超出范围的不接，也不推。
流转是自动的，不是“看心情”的。
如果某个环节无法处理（比如技术评估不了），有明确的异常处理机制（比如升级给专家池），而不是无限期卡住。

二、为什么传统流程会“踢皮球”？

在谈解决方案之前，我们需要先解剖问题。

2.1 推诿的三个根源

根源一：职责边界模糊

很多公司的岗位职责描述是这样的：

“负责项目前期调研与可行性分析。”

这句话说了等于没说。

调研谁来做？销售？产品？技术？
可行性分析包括哪些维度？技术？市场？财务？
谁对最终结论负责？

当边界模糊时，每个人都会倾向于把自己认为“风险大、麻烦多”的环节推给别人，把“容易出成绩”的环节抢过来。

根源二：缺乏“自动流转”机制

传统流程里，一个任务到某个人手里，他可以用“我在忙”、“我再看看”、“等别人意见”来无限期拖延。

没有截止时间，没有自动提醒，没有升级机制。

这就导致了：

上游不知道下游在干什么。
下游没有压力必须及时处理。
任务像石头一样堆在某个人桌上，然后被遗忘。

根源三：问责对象不明确

当一个项目失败了，老板问：“谁负责的？”

大家开始互相指责：

销售：“产品需求没写清楚。”
产品：“销售承诺了做不到的功能。”
技术：“需求变来变去。”
项目经理：“我说了不算。”

没有人在事前明确说：“到这个环节，我对此负责。”

所以事后追责时，变成了“集体负责=无人负责”。

2.2 一个真实的案例

我之前帮一家中型互联网公司对他们的项目立项流程做诊断。

原始流程：

销售填写《项目立项申请表》，提交给销售总监。
销售总监审批后，转给产品总监。
产品总监转给技术总监。
技术总监转给财务总监。
财务总监转给CEO。

问题爆发点：

销售填表时，经常漏填“预期收入”、“客户背景”等字段。
产品总监收到表后，不是直接打回，而是自己帮销售补齐——但他补的数据不一定准确。
技术总监看到数据不全，懒得问，直接说“技术风险未知，不予评估”。
财务总监说“没有收入数据，无法核算ROI”。
CEO看到一堆矛盾的信息，要么批，要么不批，但没人敢为这个决定负责。

结果：

立项周期平均14天。
立项后项目失败率高达35%。
销售和技术互相抱怨，协作关系破裂。

三、用责任链模式重构流程

3.1 第一步：识别“请求”和“处理节点”

首先，我们要把“项目立项”看作一个请求（Request）。

然后，列出所有可能参与处理的节点（Handlers）。

在我们的例子里，节点有：

格式审核（行政/PMO）
销售评估（销售部）
产品评估（产品部）
技术评估（技术部）
财务评估（财务部）
最终决策（CEO/投决会）

3.2 第二步：定义每个节点的“处理逻辑”

这是最关键的一步。

每个节点必须明确：

我接受什么样的请求？（入参标准）
我处理什么？（核心职责）
我输出什么？（结果标准）
我处理不了怎么办？（异常处理/升级路径）

我们用表格来定义：

节点	入参标准	核心职责	输出结果	异常处理
格式审核	申请表字段完整率≥90%	检查格式、完整性	通过/打回（注明缺项）	打回给销售，24小时内补全
销售评估	格式审核通过	评估客户真实性、收入预估	销售风险评估报告	高风险项目，附加说明
产品评估	销售评估通过	评估市场需求、产品匹配度	产品可行性结论	不匹配，注明原因，终止流程
技术评估	产品评估通过	评估技术可行性、工期	技术风险评级+工时估算	技术不可行，终止流程
财务评估	技术评估通过	核算ROI、成本	财务可行性结论	ROI<阈值，终止流程
最终决策	以上全部通过	综合判断，拍板	立项/不立项	投决会投票决定

3.3 第三步：设计“自动流转”机制

在编程里，责任链的流转是代码控制的，自动且不可逆（除非被打回）。

在流程里，我们也要实现类似的效果。

3.3.1 时效约束

每个节点必须有处理时效：

格式审核：2小时
销售评估：1天
产品评估：2天
技术评估：3天
财务评估：1天
最终决策：2天

超时自动升级：如果某节点超时未处理，系统自动标记为“超时”，并通知上一级管理者和HRBP。

3.3.2 状态机

每个请求有一个状态：

PENDING → UNDER_REVIEW → APPROVED / REJECTED / RETURNED

UNDER_REVIEW 时，显示当前在哪个节点，由谁处理，已停留多久。
RETURNED 时，显示打回原因，回到上一个节点重新处理。
APPROVED / REJECTED 时，流程结束，通知相关方。

3.3.3 打回规则

打回只能打回给直接上游，不能跨级打回。

例如：

技术评估不通过，打回给产品评估，由产品重新评估。
产品评估重新评估后，再流转到技术评估。
如果技术评估连续两次打回同一问题，自动升级到技术总监介入。

禁止：

技术直接打回给销售。
财务打回给格式审核。

这样可以避免“踢皮球”式的跨级推诿。

3.4 第四步：实现“异常处理”

在编程里，如果某个处理器无法处理，它会调用 nextHandler。

在流程里，如果某个节点无法判断，必须有明确的升级路径，而不是无限期搁置。

例如：

技术评估遇到“新技术领域，团队无经验”，无法给出风险评级。
原流程：技术总监说“这我得问问外面专家”，然后就没有然后了。
责任链流程：标记为“需专家介入”，自动转给“专家池”，专家池在3天内给出意见，再流转到下一节点。

关键：每个异常都有归宿，不会消失。

四、责任链模式在沟通中的核心价值

4.1 权责对等

责任链的每个节点，只对自己的职责范围内负责。

技术不背销售的锅（销售数据造假，技术不负责）。
销售不背技术的锅（技术评估错误，销售不负责）。
产品不背财务的锅（财务核算错误，产品不负责）。

这样，当项目失败时，我们可以精准追责：

是销售承诺了做不到的功能？→ 销售责任。
是技术低估了工期？→ 技术责任。
是财务算错了ROI？→ 财务责任。

精准追责，才能让每个人敬畏自己的职责。

4.2 透明可追溯

责任链模式下，每个请求的处理历史都是可追溯的：

谁在什么时候处理的？
处理了多久？
有没有打回？打回原因是什么？
当前在哪个节点？

这消除了“我明明已经发了”、“我不知道你收到了”这类扯皮话术。

4.3 降低沟通成本

在老流程里，跨部门沟通往往需要开会、发邮件、拉群，耗时耗力。

在责任链流程里，沟通被结构化了：

只需要填写标准化的表单。
只需要给出明确的结论和依据。
不需要反复确认“你看到了吗”、“你觉得呢”。

沟通变成了“接口调用”，而不是“人情往来”。

五、如何落地？三步走

第一步：画出你的“责任链图”

拿出一张纸，画出你公司里最常扯皮的三个流程（比如：项目立项、采购申请、合同审批）。

然后，列出每个流程的所有参与节点。

第二步：定义每个节点的“SLA”

和每个节点的实际负责人沟通，明确：

他们能处理什么？
他们处理不了怎么办？
他们必须在多久内处理？

把口头共识变成书面文档。

第三步：用工具固化

不要指望靠人的自觉来维持责任链。

用OA系统、钉钉、飞书、Jira、Trello等工具，把责任链自动化：

设置自动流转规则。
设置超时提醒。
设置打回规则。
设置处理日志。

工具是责任链的骨架，人是血肉。

六、常见误区

误区一：责任链等于“甩锅链”

有人担心，划清职责边界后，大家会更有借口推诿。

恰恰相反。

责任链划清边界后，每个人都知道自己必须扛什么，躲也躲不掉。

老流程里，模糊地带让人有机会钻空子；责任链里，每个节点都是“铁板一块”，无处可藏。

误区二：责任链太死板，不懂变通

责任链不是不能变通，而是变通必须有记录。

比如，技术评估认为某个项目风险极高，但销售说客户非常重要，要求特批。

在责任链里，这可以通过“升级决策”机制解决：

技术输出风险评级。
销售发起“特批申请”，附加说明。
流程升级到“投决会”，由更高层级决策。
决策结果记录在案，作为后续参考。

变通不是破坏流程，而是走升级通道。

误区三：责任链适用于所有场景

责任链适合标准化程度较高、节点清晰的流程。

对于高度不确定、需要大量即兴协作的场景（比如创意策划），责任链可能过于僵硬。

这时候，可以采用“混合模式”：

主干流程用责任链。
并行协作用看板或敏捷方式。

七、一个完整的责任链流程示例

以“项目立项”为例，完整流程如下：

”` [销售] 提交立项申请

↓

[格式审核] 检查材料完整性

├── 完整 → 流转至 [销售评估]
└── 不完整 → 打回 [销售]，注明缺项，24小时内补全
↓

[销售评估] 评估客户真实性、收入预估

├── 通过 → 流转至 [产品评估]
├── 不通过 → 终止，通知 [销售]
└── 高风险 → 附加说明，流转至 [产品评估]
↓

[产品评估] 评估市场需求、产品匹配度

├── 通过 → 流转至 [技术评估]
├── 不通过 → 终止，通知 [销售]
└── 需调整 → 打回 [销售] 重新评估客户需求
↓

[技术评估] 评估技术可行性、工期

├── 通过