某TikTok主管在发现FBT库存积压后，将责任归咎于计划部门，声称计划未拦截运营的调拨指令。然而事实是，运营在未通知计划的情况下，擅自将库存从海外仓调拨至FBT。
对此，计划部门予以反驳：尽管调拨流程存在漏洞，但运营人员应具备基本的职业素养，需对需求预测及库存调拨的合规性负责。制度防不住所有违规操作，不能仅靠计划部门“防贼”。
从解决问题的角度出发，计划部门可承担修补流程漏洞的责任，但这不能掩盖运营操作的随意性。运营需反思自身SOP及责任边界，不应期望计划部门在所有环节越俎代庖。
深度思考
在电商卖家组织中，运营作为业务引擎，其指标与公司经营指标高度重合，因此在决策中占据主导地位。相比之下，供应链等部门常被视为辅助性的“承重墙”，在多方指标平衡时往往处于劣势。这一冲突的本质，是“引擎”岗位与“承重墙”岗位之间责权利界定不清的问题。
确立权责基本原则
计划部门职责：识别风险、量化影响、提供建议、跟踪闭环、及时升级。
运营部门职责：提供需求、促销、上新、清仓及价格等业务输入，并对风险做出处置决策和执行。
管理层职责：公开制定规则、支持升级机制、依据动作问责，杜绝“谁预警谁背锅”的现象。
核心原则：预警不等于代劳，前置介入不等于替代执行。
建立RACI责权矩阵
RACI模型旨在明确事项中的角色分工，避免权责模糊和推诿扯皮：
R (Responsible)：执行人，可有多个，需明确具体操作者。
A (Accountable)：负责人，每项活动只能有一个，对结果负最终责任。
C (Consulted)：咨询对象，事前沟通，而非事后甩锅。
I (Informed)：知情者，仅需知晓结果，不参与决策和执行。
注意：RACI是按事项分配角色，同一部门在不同流程中可能扮演不同角色。
关键原则：
计划部门可以是断货预警的R（执行人），但不能成为运营不提供需求、不响应预警时的A（负责人）。RACI的核心在于将“预警”与“代做”分离：计划负责预警和跟踪，运营负责业务输入与处置决策，管理层负责规则制定与裁决。
基于上述原则，梳理计划与运营的RACI分工如下：
构建双闭环流程
1. 计划预警闭环：风险识别 → 风险分级 → 确定责任人 → 提出建议动作 → 设定时限 → 升级机制。
2. 运营响应闭环：接收工单 → 确认/修正需求 → 选择处置动作 → 执行 → 反馈结果。
实操案例：计划部每周输出红黄绿风险清单。对于红色风险，运营需在24-48小时内确认处置方案（如补货、调拨、促销、控单或清仓）。若超时未响应，系统将自动升级至运营负责人。若不响应，应按默认规则处理并记录，而非由计划部门承担责任。
预警工单化与看板化
摒弃仅通过Excel或群消息沟通的低效方式。应将断货或冗余风险转化为标准化工单，包含以下要素：风险SKU、影响金额、建议动作、责任人、截止时间、当前状态及最终结果。
此举有助于复盘分析：清晰界定计划是否及时预警，以及运营是否及时响应并执行。
指标共担，责任拆解
虽然断货率、库存周转、冗余金额等结果指标可由双方共担，但过程责任必须明确拆解：
计划考核：预测偏差率、预警及时率、补货及时率、建议合理率。
运营考核：需求输入及时准确率、促销信息同步率、风险工单响应率、处置动作完成率。
共同承担：断货率、冗余率、库存健康度。
复盘审计重点：在发生断货前，运营是否提交了促销计划？是否响应了预警？是否执行了加急、调拨或控单措施？若未执行，责任不在计划部门“未代做”。
