RAPID 决策角色怎样落地：让跨部门合作知道谁负责哪一步

跨部门会议反复讨论同一事项，往往不是缺少意见，而是不清楚谁提出建议、谁必须确认、谁提供信息、谁最终决定以及谁执行。清楚分配决策角色，才能让讨论转成行动。

大家都参与，却没有人真正决定

营销想尽快上线，技术希望补充测试，运营担心支持资源，负责人说再协调一下。几周后仍然没有结果，团队开始互相评价效率低。问题可能不是有人不配合，而是建议、必要同意、信息输入和最终批准混在一起。任何一句我再看看都可能变成没有期限的暂停，执行者也不知道该按谁的要求准备。

RAPID 是贝恩提出的决策角色框架，五个字母对应建议、必要同意、执行、信息输入和决定。本文保留其角色区别，中文说明与管理案例由知行社为教练家编制。它用于明确一项具体决定中的责任，不是项目进度模型，字母顺序也不表示实际工作必须按这个顺序发生。

教练在使用前应帮助客户选择一个真实、反复卡住的决定，而不是先给组织所有岗位贴字母。一个人可能在不同决定中承担不同角色，同一职位也不是永远有最终权。框架不能改变法定责任或组织已有授权，需要与现有制度一致，不以工具代替审批程序。

建议角色负责形成可以判断的方案

建议者不只是提出一个想法，而是组织必要信息，说明选项、条件和理由，将建议送到适当决定者。这个角色需要时间与协调支持，不能让一位没有资源的人承担收集所有部门意见的工作，然后在信息不足时指责其方案质量。建议范围和交付时间要说清楚。

建议者可以提出推荐方向，但应保留重要不同意见和未知，不把所有争议隐藏在一个整洁结论里。需要谁提供信息、哪些条件必须得到确认，应在准备阶段安排。教练可以帮助客户检查建议是否同时包含不做什么、执行负担和后续复核，使决定者知道同意的实际内容。

建议者也不能默认自己拥有最后批准权。若意见得到讨论却未采用，决定者应说明理由，避免建议角色因此不再愿意承担准备。角色的价值在于形成可用输入，而不是保证自己的方案被批准。清楚区分建议与决定，有助于减少个人立场对讨论的占据。

必要同意与信息输入必须分开

必要同意角色用于必须满足的条件，其意见不能像普通建议一样随意忽略。例如由组织确认的特定合规或专业要求，可能需要对应责任人正式同意。但不能因为职位高、被邀请参加或与项目有关，就给每个人设置必要同意权。过多同意角色会让决定再次陷入无限等待。

信息输入者贡献事实、经验和可行性意见，决定者应认真考虑，但不等于每位输入者都有否决权。输入角色需要知道材料用途与截止时间，也应有提出重要风险的入口。超过期限之后出现关键事实仍应适当核查，不能以你没有按时反馈为由忽略重大问题。

教练可以请客户把现有参与者分开写：谁掌握需要的信息，谁承担必须确认的要求，谁只是希望了解进度。若无法区分，先与组织负责人核对，不靠教练推定权限。角色应基于这项决定的真实需要，避免以人情方式把所有人放入同意名单，再抱怨流程缓慢。

决定角色承担最终选择

决定者需要有相应权限，听取建议和必要输入，在满足必须条件后作出选择，并为其承担责任。通常应清楚指定最终决定者，不能只写领导团队或大家共同决定却没有具体规则。若组织采用集体批准，应明确其正式机制，而不是用模糊名称替代决策权。

决定者可以要求补充信息，但要说明缺口与时间安排，避免不断把判断退回建议者。决定也应说明适用条件、剩余未知与复核触发点，不能只说同意然后让执行者猜范围。教练帮助客户把选择说完整，不替其做业务决定，也不以自己的意见成为隐藏的最终批准。

若必要同意与建议无法协调，需要预先明确升级路径。最终决定者不能随意越过必须要求；必要同意者也不能把个人偏好包装成硬条件。争议应回到组织授权与专业依据，必要时由适当层级处理。框架的作用是让冲突清楚，而不是保证所有冲突都会自动消失。

执行角色应提前参与可行性输入

执行者负责把已决定事项落实，但若只在最后收到通知，往往发现资源、时间或边界不足。可以提前让其提供实际条件，随后再明确执行责任。这不意味着执行者必须同意所有业务选择，而是让决定者在承诺之前知道需要什么，避免用决策权掩盖执行不可能。

执行安排包括对象、期限、资源、协作接口和异常处理。若过程中出现条件变化，执行者应知道向谁报告以及哪些动作可以暂缓。不能让其一边执行、一边重新争论已经决定事项，也不能要求其在重大未知下无条件照做。清楚的反馈入口使决定与现实保持连接。

教练可以在会谈里请客户复述五类角色的下一步任务。如果每个人都要开会协调，却没有谁形成建议、谁作决定，框架还没有真正落地。角色的清楚程度应通过具体动作体现，而不是通过一张字母分配表显得专业。

虚构案例：新服务上线的责任拆分

以下是虚构教学案例。一家企业咨询服务公司计划上线客户资料整理服务。业务负责人希望快速推出，技术、客户服务与信息管理不断提出意见。会议多次结束于继续沟通，业务同事以为技术在拖延，技术同事认为业务没有说清范围，客户服务则不知道最终要承诺什么。

组织教练请负责人把决定限定为是否在既定范围内对少数客户开放试行。业务项目经理负责整理建议，技术与客户服务提供能力和支持信息，信息管理按组织规则确认资料处理必须条件，具备权限的负责人作最终决定，交付组承担执行。每项角色写明具体人和时间。

讨论时发现，过去一位资深主管虽然没有正式批准职责，却习惯在最后提出偏好，其他人都等他同意。负责人澄清其为信息输入角色，仍认真听取意见，但不再让模糊等待代替决定。必须条件则提前说明，并由相应角色确认，不把它们留到上线前一天才发现。

项目经理提出有限试行方案，保留客户支持负担与尚未确认情况。决定者批准范围内的动作，同时明确不能处理的资料类型、出现异常时的暂停入口和试行复核日期。交付组知道获准做什么，也知道哪些新需求需要再请求决定。组织没有宣称因此提升了多少效率，只记录责任和等待更清楚。

这个情境说明，角色框架处理的不是谁更重要，而是谁对哪一部分负责。资深经验仍有价值，专业底线仍需确认，执行条件也提前进入建议。教练协助澄清过程，正式权力与业务后果依然由组织承担，不通过工具创造新的审批权。

选择少数关键决定先试用

不需要把所有日常任务都画成复杂角色图。可以选择经常跨部门、容易重复争论或后果较大的决定，先核对角色与实际效果。角色多并不代表更严谨，若任务简单且授权清楚，直接安排可能更有效。工具应减少不必要等待，而不是增加一层术语。

试用后观察卡点是否来自角色不清、资料不足还是资源冲突。即使五类角色已写清，技术能力不足或业务目标冲突仍需要处理。不要把所有问题归结为谁没有履行字母职责。框架有助于定位，但不能替代组织设计、专业能力和具体协商。

负责人也要检查自己是否经常在已经决定之后重新插入意见。若员工按获准范围执行，却因为领导后来的偏好被追责，角色表很快失去意义。必要变化可以重新决定，但应说明新依据、影响和责任，不把个人反复改动隐藏为执行者理解不到位。

用一项决定检查角色表是否真的一致

角色分配完成后，可以请每位参与者分别说出自己下一步交付什么、向谁交付、何时需要回应。若建议者等待某人的正式同意，对方却认为自己只供参考，说明字母表还没有形成共同理解。此时先澄清，而不是等期限过后再问谁没有负责。工具落实在实际期待的一致。

有些决定同时涉及多个层级，可以拆成相应事项，例如是否批准预算与选择具体执行方案。两者可能由不同人决定，不必强行找一个人拥有所有选择。每项分别明确角色和相互条件，能够避免一个批准被误解为全部批准。教练帮助客户界定事项，但不推定任何正式权限。

角色变化时及时更新。负责人请假、人员调岗或项目范围扩大，都可能使原分配不再适用。组织应说明临时代理与升级入口，不让执行者追问一个已经不负责的人。记录中的名字与真实责任必须保持一致，才能减少无法回应的等待，而不是保存一份已经过时的角色图。

让参与者知道怎样提出重要新信息

角色清楚不应让团队变得僵硬。未承担输入角色的人如果发现重大风险，也需要适当渠道报告。可以规定一般建议与关键异常的不同处理方式，既避免所有人随时重开讨论，也不堵住必要信息。对于专业底线，按组织已有程序处理，不受私人角色表限制。

会议记录应保留最后决定、必要条件、执行责任和重新讨论的触发点。不要只写原则同意。相关人应能复述这些内容，尤其是后来加入的执行者。若理解不同，及时澄清，不等到出错以后才发现大家对同意的含义并不一致。

知行社希望企业教练使用 RAPID 时保持一个简单目标：让必要的人在必要的位置贡献，让授权的人承担选择，让执行的人获得条件。字母不是权力装饰，清楚责任也不是减少倾听。真正落地的角色安排，会让意见更有用途，让决定更能被执行和复核。

在使用一段时间后，还应检查建议者是否承担了过多无权协调的工作。如果其不断追问材料却得不到回应，问题可能是组织未提供必要支持。负责人应帮助建立响应约定，而不是只要求建议者更主动。责任与资源匹配，角色澄清才能真正帮助团队。