# 任务: 把一项工作整理成人与AI协作的依据 从要交付的结果出发，接清任务、角色、交接条件与检查办法。 ## 准备什么 选择一项重复发生的真实工作，准备目标与结果要求、已获授权的输入资料、现行做法、参与角色和已知异常；标明来源、版本与缺项。 ## 形成什么 形成结果支撑关系、闭环任务、角色责任与交接条件的初稿，并列出拟由AI协助的动作、验收办法及异常接管安排。 ## 怎样检查 逐项核对输入、输出、负责人和完成标准；先在资料齐全、缺项、冲突与超范围情形中试行，记录人工复核、返工和未解决问题，再回到业务结果检验。 ## 适用条件 这是组织工作依据与试行安排的阅读路径，不保证一套做法适用于所有岗位。岗位可承担多项闭环任务，业务可跨部门；任务完成与经营业绩分别检查。 先确认输入、适用条件、来源与版本；缺少的资料列为待补，不能编造。 列出需要由人确认的目标、预算、权益、授权和最终决定。 ## 原文与版本 - 模型: 四向SOP：业绩、业务、职能与动作怎样连接 | R1 | https://yutengfei.com/zh/journal/four-way-sop/ Markdown: https://yutengfei.com/zh/journal/resources/four-way-sop.md 先看清具体工作支持哪一项业务与业绩结果。 - 方法: 四向SOP怎么用：从业绩理清业务、人才和每天的工作 | R1 | https://yutengfei.com/zh/journal/four-way-sop-practical-guide/ Markdown: https://yutengfei.com/zh/journal/resources/four-way-sop-practical-guide.md 从一条业务往下拆解闭环任务和具体动作。 - 方法: 从岗责分析到角色工作手册：让共建者知道怎样贡献 | R1 | https://yutengfei.com/zh/journal/co-builder-role-handbook/ Markdown: https://yutengfei.com/zh/journal/resources/co-builder-role-handbook.md 明确角色责任，把多项任务组织成工作手册。 - 模型: 流程走到下一步之前，要交付什么？ | R1 | https://yutengfei.com/zh/journal/process-handover-and-entry-conditions/ Markdown: https://yutengfei.com/zh/journal/resources/process-handover-and-entry-conditions.md 核对前后环节的交付物、进入条件与验收责任。 - 方法: 从 SOP 到 Skill：哪些工作可以由 AI 协助，怎样验收 | R1 | https://yutengfei.com/zh/journal/sop-to-ai-skill/ Markdown: https://yutengfei.com/zh/journal/resources/sop-to-ai-skill.md 选择适合AI协助的部分，写清输入、验收和异常接管。 - 方法: SOP跑完了，为什么没有业绩？ | R1 | https://yutengfei.com/zh/journal/sop-business-outcome-diagnosis/ Markdown: https://yutengfei.com/zh/journal/resources/sop-business-outcome-diagnosis.md 回看真实结果，区分动作、协作与经营假设的问题。 ## 关联 Skill 本路径未配套可安装Skill。阅读或下载资料包不等于安装Skill，也不表示AI已连接工具或获准执行；如需进一步整理为Skill，应另行确认格式、工具、授权并试行验收。 ## 完成后记录结果、偏差与需要修订的知识或步骤。 版本: V1.0 · 2026-11-05 https://yutengfei.com/zh/journal/pathways/sop-human-ai/ --- 按需要选择资源和章节，避免把全部资料无差别塞入任务。 资料导出沿用原有许可与第三方素材说明，下载不扩大改编、商业使用或训练授权。 --- # 四向SOP：业绩、业务、职能与动作怎样连接 - 作者: Andrew David W.Y. - 来源: https://yutengfei.com/zh/journal/four-way-sop/ - 版本: R1 - 发布: 2026-11-04 - 修订: 2026-11-04 - 内容状态: 已公开全文 - 内容类型: 模型 (models) - 研究专题: 利益相关者资本治理 (stakeholder-governance) - 生态视角: 运管生态 (operations) · 资源生态 (resource) ## 如何使用这项资源 **用途**: 从客户与经济结果出发，把关键业务、闭环任务和具体动作连起来。四向SOP提供一条可以向下展开、向上核对的支撑关系，让人知道一项工作为什么要做，也让组织看清流程完成以后还需要验证什么。 **使用条件**: 使用前请核对对象、目标和约束是否适合当前任务；正文未明确的条件需要另行确认。 **模型 · 要素、关系与假设** **依据与验证边界**: 示例用于说明四向 SOP 的展开方法。判断是否有效时，请同时检查交付能否被下一环节使用，以及客户和经济结果是否有变化。 本文未单独登记外部验证结果。公开发布不等于效果已经验证，请结合正文依据、假设与限制判断。 这是可阅读、可引用的知识资源，不是已安装的 Skill。交给 AI 使用时，请保留来源与限制，并核对产出。 ## 正文 一份报价发出去了，客户迟迟没有确认。销售说报价已经完成，采购说供应条件已经给出，报价人员也按表格核算过。每个人都有完成记录，业务却没有往前走。 这时，我觉得先别急着问谁没做完。要先看：客户要解决什么问题？这份报价是否满足需求，能否按承诺履行？已经完成的这些工作，到底支撑了哪个结果？ 四向SOP想理清的，就是具体工作与经营结果之间的关系。它把SOP分为业绩、业务、职能、动作四个层次。设计时可以从结果向下展开，运行后可以从动作向上核对。这样，一项工作为什么要做、做到什么程度、怎样和别人接上，就能沿着这条关系继续往下问。 ## 一、四个层次，分别回答四个问题 SOP通常译为标准作业程序。这里讨论的四向模型，是对不同范围、不同颗粒度的工作程序进行分类的一种方法。它不要求每项工作都另写四份文件，也不把四层当作四级组织。 | 层次 | 核心问题 | 主要看什么 | 简化示例 | | --- | --- | --- | --- | | 业绩SOP | 客户价值怎样转成企业的经济结果？ | 与客户强关联的关键环节及结果 | 从确认需求到履约、回款的订单链 | | 业务SOP | 为推进某个关键环节，需要组织哪些过程？ | 多项任务协作形成的业务结果 | 形成一份可履行的报价 | | 职能SOP | 岗位或角色要完成哪一项闭环任务？ | 有输入、处理、输出和完成标准的任务 | 核算一份报价 | | 动作SOP | 这项任务具体怎样做？ | 准备、操作、检查、异常与交接要求 | 核对数量与计价单位 | **业绩SOP从客户与经济结果出发。** 对订单业务，可以梳理确认需求、确认方案与报价、明确合同条件、完成履约验收、结算回款等关键环节。不同业务的顺序、分支和并行关系不同，不能把一条示意链当成所有企业的固定路径。 业绩也不能只看成交数量。客户是否接受交付、企业是否收回款项、业务是否覆盖必要成本，都可能影响对结果的判断。企业应先说清本条业绩链的范围、观察期间和结果口径，再选择相应记录。 **业务SOP组织一个业务结果。** 为让客户确认报价，可能需要整理需求、核实供应条件、核算报价、完成授权复核。业务SOP要把这些工作接起来，形成下一环节可以使用的结果。它可以由一个部门负责，也可以跨部门、跨组织协作。 **职能SOP对应一项闭环任务。** 这里的“职能”指岗位或角色承担的一项工作任务，例如核算报价、开具发票、核实供期。它不是“财务部”“采购部”这样的职能部门，也不是一个岗位的全部职责。判断任务是否闭环，要看它在什么条件下开始，处理什么，交出什么，以及怎样确认完成。 **动作SOP把任务变成可以执行的说明。** 比如核算报价时，先读取已确认的需求版本，再核对数量与计价单位，按授权的计价规则计算，记录依据和未决事项，最后提交测算单。容易出错、需要交接或存在明确风险的地方，应写清操作标准和异常处理；不必把每个熟练动作都扩成冗长教程。 可左右滑动查看图示，也可打开大图。 [![四向SOP的层层支撑关系：向下明确必要工作，向上核对结果依据。](https://yutengfei.com/journal/four-way-sop/materials/zh/01-four-layer-support.svg)](https://yutengfei.com/journal/four-way-sop/materials/zh/01-four-layer-support.svg) 图1：四层表示工作范围与支撑关系。箭头表示需要说明和检验的关系，不表示完成下层就必然获得上层结果。 [打开大图 ↗](https://yutengfei.com/journal/four-way-sop/materials/zh/01-four-layer-support.svg)[下载可编辑 SVG ↓](https://yutengfei.com/journal/four-way-sop/materials/zh/01-four-layer-support.svg) ## 二、向下展开，要找到真正需要的过程 梳理可以从一条真实业务开始。先看客户在哪里作出选择，企业在哪里形成承诺，交付和款项怎样落实。再选择其中一个关键环节，追问它需要什么结果、由哪些任务共同产生。 以“确认方案与报价”为例。客户能收到一份报价，还不足以说明这个环节已经成立。报价应回应已确认的需求，所依据的供应、交付和商业条件应当可核对，超出授权的条件应有人作出决定。内部要组织哪些工作，就要看怎样把这些条件支撑起来。 继续往下看，“形成可履行报价”这个业务过程，可以包括整理需求、核实供应、核算报价、授权复核等任务。每项任务有各自的输出，也有协作接口。整理需求不能以“沟通过了”作为完成依据，应交出可供核对的需求说明；核实供应不能只说“应该有货”，应说明确认的条件和有效范围。 再选“核算报价”这一项职能任务。它的输入可以是已确认的需求、有效的供应条件和当前适用的计价规则；输出可以是核算正确、标明版本与计算依据的报价测算单，供后续复核使用。阻塞计算的缺项应先退回确认，非阻塞的后续复核项可以随单列示；涉及对客户承诺的未决条件，必须在作出承诺前解决。到了这一层，才需要进一步说明具体操作动作。 每向下展开一次，都要回答：**新增的工作怎样帮助形成上层所需的结果？** 如果说不清，可能是任务没有必要，也可能是上层目标不清，或者两者之间遗漏了一个过程。不能只靠文件编号把它们连起来。 可左右滑动查看图示，也可打开大图。 [![一份报价怎样连接四层SOP：订单链中的关键节点，展开为业务过程、闭环任务和操作要求。](https://yutengfei.com/journal/four-way-sop/materials/zh/02-quotation-expansion.svg)](https://yutengfei.com/journal/four-way-sop/materials/zh/02-quotation-expansion.svg) 图2：虚构订单业务示例，只展开“确认方案与报价”的部分支撑关系；实线箭头表示示意流转，虚线表示局部展开。实际业务可有并行、分支和返工。 [打开大图 ↗](https://yutengfei.com/journal/four-way-sop/materials/zh/02-quotation-expansion.svg)[下载可编辑 SVG ↓](https://yutengfei.com/journal/four-way-sop/materials/zh/02-quotation-expansion.svg) ## 三、向上核对，不能把完成动作当成完成业绩 向下拆得清楚，还要能向上核对。 核对计价单位完成，只能说明一个操作要求得到满足。核算报价完成，说明一份符合任务要求的测算单已经形成。经过需求、供应与授权等环节共同复核，才可能形成可向客户提供的报价。客户是否接受，后续能否履约、回款，还需要继续观察。 因此，四层之间不能写成简单的结果等式。多个合格动作可以为闭环任务提供条件，多项任务可以共同支撑业务结果，多个业务过程可以推进业绩链。但市场变化、客户选择、产品适配、资源约束和经营判断，仍会影响最终结果。 如果客户没有接受报价，要先查看客户反馈和这条业绩链的相关记录。问题可能出在响应时间、需求理解或报价差错，也可能出在产品不适合、交期不满足、价格缺乏竞争力，甚至客户的采购计划已经改变。定位以后，再决定需要调整业务协作、某项任务、操作要求，还是重新判断产品与市场。需要处理哪一层，就展开哪一层，不必每次完整走过四层。 四向SOP可以帮助我们沿着这些关系继续问，也能回头查依据。它不能单凭一张分层图证明原因，更不能把业绩不达预期直接归为某个人执行不力。 ## 四、它与组织有关，但不被组织图框住 实际工作中，四层通常不会与公司、部门、岗位、个人一一对应。一个人可能承担多项职能任务，一项业务可能需要多个角色协作；同一项“核实供期”任务，也可能服务新报价和订单变更等不同业务。 所以，梳理SOP时应同时保留两种关系：一是任务支撑什么结果，二是谁拥有相应的责任、权限和资源。前者说明工作逻辑，后者说明工作由谁组织和完成。两种关系相互联系，不能互相代替。 共享任务还要处理版本和适用范围。比如供应条件更新了，哪些报价仍然有效、哪些需要重新确认？如果把同一任务复制到多份文件里，却没有维护来源，很容易出现流程都照做了、依据却不一致的情况。 从资源、运管、客户、资本四种参与关系（四生态）来观察企业，参与者可以主动提出贡献，也可以响应需求。精干运管负责决策、规则，以及价值生产、销售渠道和客户关系的协调。价值贡献角色通过相应任务进入业务协作，工作手册为角色提供使用这些流程的指引。消费客户和单纯投资人分别走相应流程，不因这两种身份要求配置共建工作手册。 这里先说明工作如何连接。贡献怎样评价、权益怎样约定，仍需按实际业务另行制定规则，不能由任务完成记录自动推导出来。 ## 五、先用一条链检验，再决定扩展到哪里 使用这套模型，不必从全公司的文件整理开始。可以选一条真实、重复发生、能够观察结果的业务链，先做三件事。 第一，说清这条链要形成什么客户结果与经济结果，哪些条件不能省略。第二，选择一个关键节点，展开必要的业务过程和闭环任务，把输入、输出、责任与验收依据接起来。第三，跟随真实业务运行，记录缺项、等待、返工和客户反馈，再决定哪些操作需要进一步标准化。 工作已经熟练、稳定，交接也简单，留一份简洁指引可能就够了。对于新业务、需求频繁变化或高度依赖判断的工作，应先把目标、决策条件和反馈方式说清，再逐步积累程序。为了凑齐四层而增加填写和审批，反而可能妨碍业务。 培训、设备维护等支持性工作，也未必直接对应一次成交。它们可以支撑多条业绩链，或影响更长期间的能力与风险。说明这种支撑关系，需要相应记录与判断，不能给每个动作强行分配一笔收入。 过程方法本身已有成熟研究。ISO关于ISO 9001:2015过程方法的技术说明，同样强调过程之间的输入、输出、接口、责任和检查，并建议按组织情境与风险确定所需文档。\[1\] 本文四向模型的作用，是用四个观察层次，把客户与经济结果一直追问到具体任务和动作；其适用性仍需在实际业务中检验。 判断一次试行是否有用，可以看参与者能否说清自己的交付支撑哪里，下一环节能否使用该结果，出现问题后能否找到相应记录。交接缺项、返工和等待是否减少，也值得观察，但应同时记录业务规模、需求复杂度等变化。即使结果改善，也不能只凭一次试行认定是模型带来的。 四向SOP的价值，最终体现在工作与结果能否相互解释：向下展开时，知道需要组织什么；向上核对时，知道已经交出了什么、还有什么没有成立。把这条关系放回业务里反复检验，流程才有机会成为持续使用的方法。 ## 来源与延伸阅读 模型依据作者提供的早期研究资料《SOP梳理设计方法论》，重点为第2、4、5节；版本记录列有2023年3月9日培训调整及2023年5月11日杨婧参与的基础理论与模型搭建。本篇重新说明四层关系，图示为本篇原创重构，未沿用历史图中的考核及分配机制。文中报价业务为虚构示例。 \[1\] ISO/TC 176/SC 2, _The Process Approach in ISO 9001:2015_, N1289，第1、4—5页。[官方技术说明](https://www.iso.org/iso/iso9001_2015_process_approach.pdf)。此处引用过程方法，不将四向分类归为ISO要求，也不表示本文模型经过认证。 延伸阅读：[繁、简、易、图：商业逻辑设计的思考方法](https://yutengfei.com/zh/journal/fan-jian-yi-tu/)；[企业规划十步法：把方向、资源和执行接起来](https://yutengfei.com/zh/journal/enterprise-planning-ten-steps/)。 ## 关联阅读 - [四向SOP怎么用：从业绩理清业务、人才和每天的工作](https://yutengfei.com/zh/journal/four-way-sop-practical-guide/) - [SOP跑完了，为什么没有业绩？](https://yutengfei.com/zh/journal/sop-business-outcome-diagnosis/) [CC BY-NC-ND 4.0](https://creativecommons.org/licenses/by-nc-nd/4.0/) 原创文字内容适用，另有声明除外；第三方素材不适用。下载和机器读取不扩展现有许可，也不另行授权衍生作品、商业使用或模型训练。 [查看 AI 使用说明](https://yutengfei.com/zh/journal/ai/) --- # 四向SOP怎么用：从业绩理清业务、人才和每天的工作 - 作者: Andrew David W.Y. - 来源: https://yutengfei.com/zh/journal/four-way-sop-practical-guide/ - 版本: R1 - 发布: 2026-11-04 - 修订: 2026-11-04 - 内容状态: 已公开全文 - 内容类型: 方法 (methods) - 研究专题: 利益相关者资本治理 (stakeholder-governance) - 生态视角: 运管生态 (operations) · 资源生态 (resource) · 客户生态 (customer) ## 如何使用这项资源 **用途**: 从一条业绩主线开始，把业务、资源伙伴、岗位职责和日常动作逐步理清。用一家假设的品牌设计公司，说明四向SOP怎样帮助初创企业验证收益路径、寻找和培养人才，并为人与AI协作留下可用的工作方法。 **使用条件**: 使用前请核对对象、目标和约束是否适合当前任务；正文未明确的条件需要另行确认。 **方法 · 步骤、输入与完成条件** **依据与验证边界**: 示例用于说明四向 SOP 的展开方法。判断是否有效时，请同时检查交付能否被下一环节使用，以及客户和经济结果是否有变化。 本文未单独登记外部验证结果。公开发布不等于效果已经验证，请结合正文依据、假设与限制判断。 这是可阅读、可引用的知识资源，不是已安装的 Skill。交给 AI 使用时，请保留来源与限制，并核对产出。 ## 正文 企业靠什么形成业绩？需要开展哪些业务？要找什么人？这些人每天应该做什么？ 这几个问题，其实可以放在一起考虑。 我早期研究四向SOP，就是想把它们接起来。先找到企业创造业绩的核心过程，再顺着这个过程，把业务、职能和具体动作一层层理清楚。这样做，企业已经在经营，可以用它检查现有业务；企业刚刚起步，也可以用它分析几种收益的可能，决定先做什么。 我把这套关系分为四个方向：**业绩SOP、业务SOP、职能SOP、动作SOP。** SOP通常译为标准作业程序。这里，我用四个方向，把从经营结果到具体工作的关系接起来。 从业绩往下看，是在回答“为了得到这个结果，需要组织什么工作”；从动作往上看，是在回答“这项工作，最终支持什么结果”。 如果想先看四者的完整结构，可以读[四向SOP模型介绍](https://yutengfei.com/zh/journal/four-way-sop/)。这一篇，我想把它怎样用于一家企业讲得更具体一些。 图示按阅读宽度显示，也可打开大图。 [![四向SOP实践路径：从业绩、业务、职能到动作，逐步明确收益路径、资源伙伴、岗责人才和日常安排，并通过实践反馈向上核对。](https://yutengfei.com/journal/four-way-sop-practical-guide/materials/zh/01-practice-map.svg)](https://yutengfei.com/journal/four-way-sop-practical-guide/materials/zh/01-practice-map.svg) 图1：从一条业绩主线逐层展开必要工作，再用实践反馈向上核对。四层表示工作范围，并非四级组织；沉淀的方法可支持人与AI协作，仍需授权、配置和结果检验。 [打开大图 ↗](https://yutengfei.com/journal/four-way-sop-practical-guide/materials/zh/01-practice-map.svg)[下载可编辑 SVG ↓](https://yutengfei.com/journal/four-way-sop-practical-guide/materials/zh/01-practice-map.svg) ## 一、先找到企业创造业绩的核心过程 梳理SOP时，我会先问：这家企业的客户是谁，向客户提供什么，客户为什么愿意付钱，企业怎样完成交付并形成收益？ 把这几个问题说清楚，业绩SOP的主线就有了。 早期研究里，我用过“拓客、报价、签合同、回款”这个简化例子。这几个节点之所以被放进业绩SOP，是因为它们都和客户有很强的关联，关系到一笔业务能不能成立。实际使用时，还要按业务把需求确认、交付、验收等必要条件补进去。 **业绩SOP中的过程，应当由业绩成功的关键要素组成。** 下面用一家假设的品牌设计公司贯穿说明。它的一条项目业务，可以先写成： 找到有需求的客户 → 确认需求与服务范围 → 提交方案和报价 → 确认合作与付款安排 → 完成设计交付和验收 → 按约结算。 这里画的是经营主线。每个节点都要有一个说得清楚的结果：“找到客户”要进一步看是不是合适的客户，“确认需求”要留下双方能够理解的范围，“完成设计”要看交付是否满足约定。 一条主线画出来，管理者就容易找到该关注的地方。客户很多却没有合作，看看需求、方案和报价；项目签了却交不出来，看看生产与交付；交付了却没有回款，再看验收和结算条件。 同时，企业要明确自己观察的业绩是什么。签约、收入、毛利和到账各有口径，不能混在一起。一家企业也可能有多条业绩SOP，分别对应不同的产品、服务或客户类型。 ## 二、初创企业可以先把几种收益可能画出来 还没有稳定业务的企业，也可以使用这套方法。 刚开始时，创业者往往有几种想法。还是这家品牌设计公司，可能准备做项目设计，也可能提供持续的内容服务，还可能开展设计培训。这几种业务需要的客户、资源和工作安排并不相同。 可以先各画一条简化的业绩SOP： - 项目设计：找到项目客户，明确范围与报价，完成合作约定，设计交付，验收结算。 - 持续服务：找到有持续需求的客户，明确每期服务内容与收费安排，约定合作，按期交付、验收结算和反馈，再判断是否继续合作。 - 设计培训：明确学员与学习需求，设计课程，招生报名与收费，完成教学，再核对学习效果和后续需求。 画完以后，就可以比较：哪条路径离现有资源最近？哪一环还没有能力完成？客户是否真的愿意付费？前期要投入什么？哪些条件需要先验证？ 这样，讨论就能从“我们还可以做很多事”，进入“先把哪条业务做出来”。 对于还没发生过的业务，我会把业绩SOP当成待验证的设想。先选择一条有条件尝试的路径，接触真实客户，做一次小范围交付，再根据反馈调整。画图能够帮助把问题提前暴露出来，实际业务负责检验这些判断。 ## 三、业绩SOP清楚以后，业务和资源就容易找到 业绩SOP告诉我们，哪些关键结果需要成立。接着要看，为了得到这些结果，需要开展哪些业务。 比如，“完成设计交付”看起来只是业绩SOP里的一个节点，背后却可能包含需求研究、创意设计、内容整理、制作检查、客户沟通等过程。这些过程共同形成客户能够使用的成果，就是业务SOP要组织的内容。 **业务SOP关注怎样创造价值，以及怎样把价值交到下一环节。** 需求研究要交出可用的设计依据，设计工作要交出符合要求的方案，制作检查要保证文件能被实际使用。每一步完成以后，下一步应当有东西可接。 当业务过程清楚了，所需资源也就具体了。 要做客户研究，需要访谈和分析能力；要做设计，需要设计能力、素材和工具；涉及拍摄、印刷或其他制作，还需要相应设备、工艺和供应能力。哪些资源已经有，哪些必须补，哪些适合找合作伙伴，就可以沿着业务逐项判断。 这时找合作伙伴，也有了明确的问题：对方可以提供哪一段能力？交什么结果？按什么标准配合？怎样与我们已有的工作衔接？ 一个业务过程，可以由内部团队完成，也可以由外部伙伴参与。先把需要的价值和协作关系说明白，再决定由什么组织来承接，更容易找到真正需要的资源。 ## 四、业务清楚以后，再把职能和岗责分析清楚 有了业务SOP，就可以继续把其中的任务归纳出来，形成职能SOP。 比如设计业务中，需要有人确认需求，有人完成设计，有人检查制作文件，有人组织交付。这些具体任务，分别需要什么输入、承担什么责任、交出什么结果，都可以继续明确。 我这里说的“职能”，指的是岗位或角色要完成的一项工作。一个岗位可以承担多项职能，一项业务也可能需要几个岗位共同完成。 把这些任务放在一起，就能分析岗位职责：这个角色为什么存在，平时负责哪些工作，与谁配合，需要具备什么能力。 这对找人才、判断人才、培养人才，都很有用。 找人才时，可以从真实任务提出要求。例如，要找的是能把客户需求整理成设计依据的人，还是能完成某类设计的人，或者是能组织多人交付的人？要求不同，找人的方向也不同。 判断人才时，可以围绕相应任务看作品、问过程、做练习，了解他怎样理解问题、使用资源和完成交付。岗位名称相同，实际能够承担的工作可能相差很大。 培养人才时，也能找到具体缺口。是需求没有问清楚，工具还不熟练，还是交付检查不够？把缺口落到任务和动作上，就能安排相应练习，并用后续工作检验进步。 人员配置也可以随业务调整。初创阶段，一个人可以兼几种角色；业务增加以后，再依据工作量、专业要求和协作需要拆分。四向SOP帮助我们说明需要什么工作，再判断需要怎样的人和组织。 ## 五、职能往下展开，每天的动作就清楚了 职能SOP明确了要完成什么，动作SOP进一步说明怎样完成。 例如“整理客户需求”，可以展开为：准备访谈问题，记录客户提供的信息，核对尚未明确的内容，整理需求说明，完成确认，交给设计环节。 在容易遗漏或出错的地方，还要写清楚标准：哪些信息必须具备，使用哪一版资料，怎样判断可以交接，出现缺项时找谁补齐。 然后，把这些工作放回日常安排里，可以从四种属性来看： - **日常任务**：持续开展的常规工作，例如查看客户咨询、维护项目记录。 - **周期任务**：按约定间隔进行的工作，例如每周整理项目进展、每月复盘服务情况。 - **触发任务**：SOP流转到约定节点、相应条件成立后出现的工作，例如需求确认以后进入设计，方案通过以后准备交付。 - **被动任务**：接收到别人提出或指派的事项，例如客户提出变更、协作方请求支持。 “被动”说的是任务怎样进入，不是在评价一个人做事是否主动。几种属性也可以重叠：客户提出变更，既可能是被动接收，也可能触发变更处理流程。 这几项说清楚，一个角色就知道：平时做什么，到了时间做什么，什么情况出现以后做什么，收到别人提出的事项又该怎样处理。 再把适用的SOP、工具、交付标准和协作关系整理到工作手册中，新人有学习的入口，熟练的人有共同依据，交接工作也更容易开展。 ## 六、沉淀下来的SOP，也是AI理解企业工作的资源 这套整理对人有价值，对AI也有价值。 如果只给AI一句“帮我做一个方案”，它缺少很多业务背景。客户是谁，方案要推进哪个节点，需要什么资料，谁要使用结果，哪些条件不能擅自决定，都可能没有说清楚。 四向SOP可以把这些背景接起来：业绩SOP说明工作的目的，业务SOP说明协作过程，职能SOP说明具体任务，动作SOP说明操作方法和标准。 以需求整理为例，我们可以给AI提供已经授权使用的资料、适用的需求模板和检查要求，让它协助整理信息、标出缺项，形成供负责人核对的初稿。哪些内容需要向客户确认，哪些决定涉及对外承诺，也应在流程中留出明确位置。 经过实践的SOP，还可以进一步整理成AI可调用的知识、任务说明和Skill。除了成功做法，实际出现过的例外、失败原因和调整记录，同样值得保留。 我看重的还有更长远的一点：随着AI能力继续发展，企业今天沉淀下来的这些工作方法，会成为AI理解和参与实际业务的重要资源。它们包含企业做事的目的、关系、条件和经验，而不只是一串操作步骤。 把文件交给AI，并不等于AI已经学会，也不等于流程可以自动运行。具体能承担哪部分工作，还要看工具能力、使用权限和结果检验。但这些基础整理得越清楚，后续人与AI协作，就越有依据。 ## 先从一条能看见结果的业务开始 真正使用时，可以拿一张纸，先写下一条业绩SOP。 选其中一个关键节点，展开需要的业务过程；再从业务中找出任务和责任，最后把需要重复开展的动作、标准和任务出现条件写清楚。 跑一次真实业务，再回头看：关键结果有没有成立？资源是否够用？谁的工作接不上？哪些动作需要改？哪些原先设想的工作，其实没有必要？ 业绩没有达到预期时，也要保留回到上层重看问题的空间。客户需求、产品、价格、资源和外部环境都可能发生变化，流程记录可以帮助定位，具体原因还要继续核实。 早期《SOP梳理设计方法论》里，就已经把试行、反馈和迭代放进了形成过程。今天再看，我仍然认为，这一步很重要。把流程写出来以后，还要让它在工作中不断变得有用。 **企业靠什么形成业绩，业务怎样创造价值，需要什么资源和人才，每个人每天怎样开展工作，这些问题可以沿着同一套关系逐步说清楚。** 这就是我希望四向SOP能够帮助企业做到的事情。先从一条业务开始，把它做明白，再把有效的方法留下来。 ## 研究依据与延伸阅读 本文依据早期研究资料《SOP梳理设计方法论》中关于四向模型、岗位职责、工作分类及试行迭代的内容，结合当前对初创企业、资源协作、人才培养和AI应用的思考重新整理。文中的品牌设计公司为说明方法而设的假设案例，不代表已经验证的经营成果。早期资料中的“工作SOP”等称谓，在本文统一为“动作SOP”；任务属性采用“日常、周期、触发、被动”的当前表述。 - [四向SOP模型介绍](https://yutengfei.com/zh/journal/four-way-sop/) - [从岗责分析到角色工作手册](https://yutengfei.com/zh/journal/co-builder-role-handbook/) - [角色任务怎样进入工作流程](https://yutengfei.com/zh/journal/role-task-entry/) - [从SOP到Skill](https://yutengfei.com/zh/journal/sop-to-ai-skill/) ## 关联阅读 - [四向SOP：业绩、业务、职能与动作怎样连接](https://yutengfei.com/zh/journal/four-way-sop/) - [SOP跑完了，为什么没有业绩？](https://yutengfei.com/zh/journal/sop-business-outcome-diagnosis/) [CC BY-NC-ND 4.0](https://creativecommons.org/licenses/by-nc-nd/4.0/) 原创文字内容适用，另有声明除外；第三方素材不适用。下载和机器读取不扩展现有许可，也不另行授权衍生作品、商业使用或模型训练。 [查看 AI 使用说明](https://yutengfei.com/zh/journal/ai/) --- # 从岗责分析到角色工作手册：让共建者知道怎样贡献 - 作者: Andrew David W.Y. - 来源: https://yutengfei.com/zh/journal/co-builder-role-handbook/ - 版本: R1 - 发布: 2026-11-04 - 修订: 2026-11-04 - 内容状态: 已公开全文 - 内容类型: 方法 (methods) - 研究专题: 利益相关者资本治理 (stakeholder-governance) - 生态视角: 运管生态 (operations) · 资源生态 (resource) ## 如何使用这项资源 **用途**: 从一项业务需要的结果出发，把职责分析转为价值贡献角色的工作手册，明确任务、条件、权限、交付与协作。用需求整理协作者的假设示例，说明手册怎样进入一次真实任务，并在试用中修订。 **使用条件**: 使用前请核对对象、目标和约束是否适合当前任务；正文未明确的条件需要另行确认。 **方法 · 步骤、输入与完成条件** **依据与验证边界**: 用真实任务试用手册，核对职责、任务入口和交付条件，再按试用反馈修订。 本文未单独登记外部验证结果。公开发布不等于效果已经验证，请结合正文依据、假设与限制判断。 这是可阅读、可引用的知识资源，不是已安装的 Skill。交给 AI 使用时，请保留来源与限制，并核对产出。 ## 正文 有人愿意参与一项业务，接下来怎么开始？ 如果我们只说“你负责整理需求”“你来协助内容”，对方很快就会遇到具体问题：向谁了解情况，哪些资料可以用，做到什么程度可以交出去，遇到意见不一致又找谁决定。 同样的问题，企业内部也会遇到。岗位职责写了，流程也画了，换个人接手，仍然需要原来的人反复解释。 我觉得，工作手册要把“承担职责”以后怎么开展工作说清楚。参与者要知道自己能贡献什么，需要什么条件，怎样与别人接上。 ## 一、先看这项工作要支撑什么结果 写手册之前，先选一项真实业务，弄清目前需要形成什么结果。 例如，企业准备制作一份业务介绍。眼前需要的可能是一份经过确认的需求说明，让撰稿和设计能够据此开始工作。它服务什么客户、用在什么场景、需要帮助客户理解什么，也要说清楚。 如果直接从“谁现在有空”开始分工，容易把临时安排写成长期职责。如果只从现有岗位名称往下填，也可能漏掉业务真正需要、却暂时无人承担的工作。 早期《SOP梳理设计方法论》已经把业务流程、岗位工作、具体动作、标准和交接联系起来，并要求经过试行再优化。今天继续发展这条思路，可以先把需要的结果找出来，再核对现有工作怎样支撑它。已经有效的分工可以保留，职责重复、交接空缺和条件不足的地方，则需要重新讨论。\[1\] 这里要分清两层结果。需求说明得到确认，是一项工作交付；它是否帮助材料更清楚、帮助客户作出判断，还需要在后续业务中观察。手册写得完整、任务按时完成，都不能直接推出经营结果已经改善。 ## 二、把角色、人员和本次任务分别说清楚 岗位分析提供了理解工作的起点。面向跨团队、跨组织的协作，还需要把其中可以相对独立承担的贡献，说明为角色。 这里所说的价值贡献角色，是对一类贡献及其责任的约定。例如“需求整理协作者”，可以负责收集和核对需求，形成供后续使用的需求确认单。内部员工、外部专业伙伴，都可能在适当条件下承担这个角色。 | 层次 | 需要回答的问题 | 需求整理示例 | | --- | --- | --- | | 角色 | 持续承担哪一类贡献，边界在哪里？ | 收集、核对并整理业务介绍制作需求 | | 人员 | 谁具备相应能力、时间和参与条件？ | 本次由某位内部同事或外部协作者承担 | | 任务 | 这一次具体交付什么，由谁承接和验收？ | 在约定期限内提交某项目的需求确认单 | 一个人可以承担多个角色，同一角色也可以由多人承担。但每次任务仍要明确承接人、协作人和验收人，不能只写“由需求整理角色负责”。多人共同承担时，还要说明各自范围，避免大家都以为别人已经处理。 资源、运管、客户、资本，是观察参与关系的四个生态。角色的工作安排不能机械地按四个生态各配一套。各类参与者都可以主动提出贡献，也可以响应具体需求；精干运管团队负责相应的决策、规则，以及价值生产、销售渠道和客户关系的协调。具体事项由谁决定，仍须按实际授权明确。 工作手册对应实际承担的价值贡献角色。消费客户按购买、使用、反馈和售后等流程参与；单纯投资人按相应投资与信息沟通流程参与，不因这两种身份要求配共建工作手册。如果他们另外承担产品共创、专业研究或其他明确的贡献角色，再使用那个角色对应的手册。\[2\] 可左右滑动查看图示，也可打开大图。 [![图一：先确定业务需要的结果，再界定贡献角色，形成手册，并落实到一次任务。](https://yutengfei.com/journal/co-builder-role-handbook/materials/zh/01-result-role-handbook.svg)](https://yutengfei.com/journal/co-builder-role-handbook/materials/zh/01-result-role-handbook.svg) 图一：箭头表示本文建议的梳理顺序。人员可以承担多个角色，每次任务另行明确承接安排。示例不代表成效已经验证。 [打开大图 ↗](https://yutengfei.com/journal/co-builder-role-handbook/materials/zh/01-result-role-handbook.svg)[下载可编辑 SVG ↓](https://yutengfei.com/journal/co-builder-role-handbook/materials/zh/01-result-role-handbook.svg) ## 三、一本手册，要让人能够回答八个问题 职责说明可以先写清“承担什么”，工作手册还要让使用者知道怎样开始、怎样处理、怎样完成。 下面八个问题，可以作为第一版手册的检查表。篇幅按工作复杂程度安排，不必为了填满目录而制造内容。 | 要回答的问题 | 手册里应有的内容 | | --- | --- | | 为什么需要这个角色？ | 服务对象、支撑的业务结果、角色范围 | | 哪些工作由我承担？ | 主要职责、任务入口、与其他角色的分工 | | 具备什么条件才能开始？ | 必要资料、能力、时间、工具与访问权限 | | 通常怎样开展工作？ | 关键步骤，以及关联的适用 SOP、模板和示例 | | 什么可以自己决定？ | 可以确认和处理的事项，需请谁决定的事项 | | 要交出什么，怎样算合格？ | 交付物、质量要求、验收方式、接收角色 | | 遇到缺口或变化怎么办？ | 记录方式、联系对象、补齐、调整或暂停的入口 | | 谁维护这本手册？ | 维护人、版本、适用范围、生效时间与变更方式 | 职责尽量写到别人能看出具体做了什么。“负责需求管理”还太宽，可以继续写为“核对制作目的、使用场景与内容范围，形成需求确认单，并标明来源和待确认事项”。 标准也要与工作有关。需要核实事实的工作，就说明什么必须有来源、哪些缺口影响继续推进；不要只用“认真负责”“及时高效”代替要求。探索性工作则保留方法选择空间，写清要回答的问题、证据要求和讨论节点，不必把每一步都固定下来。 SOP（标准作业流程）与角色手册可以相互引用。手册从角色出发，告诉我在什么情况下使用哪套流程；SOP 从一项工作出发，说明涉及哪些角色、步骤和标准。共用流程只维护一份有效版本，手册引用它，减少多处抄写后各自变化的问题。 ## 四、从实际工作里找内容，再请别人试着用 第一版可以从一次已经做过、或者正准备开展的任务入手。 请实际承担者讲清楚：事情从哪里来，第一步看什么资料，哪些判断依赖经验，通常找谁核实，最后把什么交给谁。再请上游和下游分别核对。承担者认为自己已经完成的工作，下游是否真的接得住，往往要在这里才能看清。 整理时，把内容分成三种状态：已经核实的做法、准备试行的安排、仍待决定的问题。历史上一直这么做，不代表它就是合理标准；新提出的好办法，也需要经过使用。 然后选择一位具备基本能力、但不熟悉这项工作的协作者，拿手册试做一项范围可控的任务。第一次可以有人辅导，同时记录他在哪里停下来、需要额外解释什么、哪项输入根本拿不到。 遇到这些问题，先查手册和开展工作的条件。是说明不清楚，还是任务超出能力？是流程有遗漏，还是授权、资料和时间没有到位？查清楚了，再决定补培训、改分工、调整条件或修订手册。 如果工作仍高度不确定，可以先用简短的角色说明和任务单推进，边做边记录。强行提前写成一套固定步骤，反而容易让使用者照着失效的前提继续做。 ## 五、用“需求整理协作者”试填一版 下面是企业业务介绍制作中的假设示例，只说明方法怎样使用，不对应某个项目的既有成效。 **角色目的**：把制作需求整理到撰稿和设计可以判断怎样开展工作的程度，减少对使用场景、内容范围和业务事实的反复猜测。 **开始条件**：项目负责人已经明确制作目的、沟通对象和大致范围；提供可以使用的现有资料，并明确业务事实的确认人。本次任务另行约定交付期限、可投入时间和验收人。 **主要工作**：先核对材料给谁看、在什么场景使用、希望对方理解或采取什么行动；再整理业务内容和表达要求；对关键说法核对来源；把分歧和缺口列出来，提交有权限的人确认。 **交付物**：一份需求确认单，至少包括使用场景、对象、内容范围、关键业务事实及来源、交付规格、已确认事项、待确认事项和对应负责人。具体期限、确认状态和适用版本随本次任务记录。 **权限与协作**：协作者可以提出问题、整理资料和建议表达方式。业务范围、产品承诺、价格或公开时间等事项，由有相应权限的人确认。整理者不能因为写入文档，就把尚未决定的事项变成企业承诺。 **验收与接收**：验收人核对事实和范围，撰稿、设计角色检查是否具备开展工作的条件。如果某项缺口只影响一部分内容，可以明确已确认的工作先做哪部分；影响整体方向的缺口，则先补齐或重新决定。不能用“已交文件”代替对可用程度的判断。 **异常处理**：发现资料相互矛盾、使用场景改变，或者新增需求超出范围时，留下问题及其影响，请相应负责人决定补充、调整、暂停或取消。新的范围和期限需要重新确认。协作者也可以主动提出改进建议，但实际行动须具备相应授权和条件。 **完成与移交**：保存最终确认单及必要依据，向下游说明未决事项、限制和版本；更换承接人时，移交未完任务、文件位置和访问安排。 这样，参与者拿到的就不只是一句“帮忙整理需求”。他能判断自己是否具备承接条件，也知道开始以后怎样把事情往前推进。 ## 六、手册进入任务后，还要保留调整的入口 任务开始时，双方确认范围、条件、期限和验收安排。执行中按适用版本开展工作，遇到缺口及时提出；结束时核对交付和下游接收情况，再把手册本身的问题反馈给维护人。 验收未通过的事项，说明需要补充或返工什么，完成后再验收。发生分歧时，由预先约定的负责人或复核角色处理。暂停事项保持待处理，需继续时重新确认条件；取消事项做好收尾后结束。小团队允许一人兼任多种角色，但重要承诺和存在利益冲突的事项，仍应按实际规则安排复核。 手册修订也要有依据。一次特殊处理可以先作为例外记录；同类问题反复出现，或者业务条件已经改变，再决定是否修改通用做法。新版要说明改了什么、适用什么范围、何时生效。未完任务怎样衔接也要交代清楚，历史版本保留备查。 可左右滑动查看图示，也可打开大图。 [![图二：角色手册进入任务承接、执行、验收和反馈；异常由有权限者决定，必要时评估修订。](https://yutengfei.com/journal/co-builder-role-handbook/materials/zh/02-handbook-in-use.svg)](https://yutengfei.com/journal/co-builder-role-handbook/materials/zh/02-handbook-in-use.svg) 图二：这是建议的运行机制。异常处理后的工作须重新确认条件；修订须确认生效。交付是否合格、下游是否可用、业务结果是否变化，分别观察。 [打开大图 ↗](https://yutengfei.com/journal/co-builder-role-handbook/materials/zh/02-handbook-in-use.svg)[下载可编辑 SVG ↓](https://yutengfei.com/journal/co-builder-role-handbook/materials/zh/02-handbook-in-use.svg) 手册有没有用，可以先看几个具体问题：新参与者是不是更清楚从哪里开始？关键问题有没有更早发现？解释和返工有没有减少？下游是不是更容易接收？试行前后尽量记录相近任务的范围、复杂程度和人员经验。任务变简单了、人员更熟练了，也可能影响结果，不能把所有改善都归因于手册。 手册可以规定交付和贡献记录应保留哪些依据。报酬、费用、权益及其条件，则按实际业务中的合同和制度另行确认，不从“完成手册任务”自动推导出来。\[2\] AI 可以协助查找适用内容、整理已有资料、起草确认单，也可以根据手册提示遗漏。事实由谁核对、哪些事项可以决定、结果交给谁，仍要明确。进一步将可复用步骤整理成 Skill 时，还需要明确适用范围、输入输出和人工判断的边界。 先选一个目前反复需要解释的角色，拿一项真实任务，把目的、条件、工作、权限和交付写清楚。让下一位合适的参与者用起来，再根据他遇到的问题修改，手册就有了实际使用的起点。 ### 依据与延伸阅读 \[1\] 早期研究资料《SOP梳理设计方法论》，重点参考第 3—4 页的岗责与工作手册关系、第 6—9 页的文档内容、岗位调研、试行与迭代。文末保留 2023 年的版本与协作记录；本文的生态共建角色、角色与任务区分及试行建议，是在这些资料基础上的本次发展。两张历史岗责与流程研究图仅用于辨认原有关系，不沿用其中的考核和权益安排。 \[2\] [《四生态治理模型：贡献、权益与协作闭环》](https://yutengfei.com/zh/journal/four-ecology-governance-model/)讨论参与关系、贡献与权益、事项权限。本篇进一步研究角色手册怎样组织工作，不预设统一分配办法。 可结合[《企业规划十步法：把方向、资源和执行接起来》](https://yutengfei.com/zh/journal/enterprise-planning-ten-steps/)理解业务目标与协作条件，结合[《一次交易之后，企业还能留下什么？》](https://yutengfei.com/zh/journal/after-transaction-business-accumulation/)继续观察经验怎样进入后续工作。 本文是一套待实践检验的方法设计，未提供其在不同企业中的效果验证。图示和假设示例用于说明机制。 ## 关联阅读 - [流程走到下一步之前，要交付什么？](https://yutengfei.com/zh/journal/process-handover-and-entry-conditions/) - [日常、周期、触发、被动：角色任务怎样进入工作流程](https://yutengfei.com/zh/journal/role-task-entry/) - [选一条业绩链，怎样启动企业生态改造](https://yutengfei.com/zh/journal/performance-chain-ecology-transformation/) - [SOP跑完了，为什么没有业绩？](https://yutengfei.com/zh/journal/sop-business-outcome-diagnosis/) [CC BY-NC-ND 4.0](https://creativecommons.org/licenses/by-nc-nd/4.0/) 原创文字内容适用，另有声明除外；第三方素材不适用。下载和机器读取不扩展现有许可，也不另行授权衍生作品、商业使用或模型训练。 [查看 AI 使用说明](https://yutengfei.com/zh/journal/ai/) --- # 流程走到下一步之前，要交付什么？ - 作者: Andrew David W.Y. - 来源: https://yutengfei.com/zh/journal/process-handover-and-entry-conditions/ - 版本: R1 - 发布: 2026-11-04 - 修订: 2026-11-04 - 内容状态: 已公开全文 - 内容类型: 模型 (models) - 研究专题: 利益相关者资本治理 (stakeholder-governance) - 生态视角: 运管生态 (operations) · 资源生态 (resource) ## 如何使用这项资源 **用途**: 把上一过程的交付、接收结论与下一过程的启动条件分开，说明交接异常怎样处理，以及共同目标如何约束局部完成。 **使用条件**: 使用前请核对对象、目标和约束是否适合当前任务；正文未明确的条件需要另行确认。 **模型 · 要素、关系与假设** **依据与验证边界**: 文中案例用于演示分析和操作。应用时请用实际业务记录替换示例条件，再核对判断和结果。 本文未单独登记外部验证结果。公开发布不等于效果已经验证，请结合正文依据、假设与限制判断。 这是可阅读、可引用的知识资源，不是已安装的 Skill。交给 AI 使用时，请保留来源与限制，并核对产出。 ## 正文 销售把客户需求交给报价人员，任务状态也改成了“完成”。报价人员打开资料，却发现数量、交期和使用条件都没有确认，又得重新找人。前面确实做过工作，后面仍然无法开始。 类似的情况，发生在方案交给设计、设计交给制作、研发交给测试，也发生在企业与供应商、渠道和客户之间。 我更关心的是：上一环节做出的结果，能不能成为下一环节真正可用的起点？ 把这件事说清楚，流程图上的箭头才有实际含义。 ## 一、先分清两个判断：交付合格，下一步也能开始么？ 一段流程可以由几个相互关联的过程组成。每个过程有自己的目的，也为整条业务链提供某种结果。这个结果可能是一件产品、一份方案、一组数据，也可能是经过确认的需求或一项决定。 ISO 关于过程方法的说明，将过程理解为利用输入形成预期结果的一组相关活动，并强调过程之间的输入、输出和相互依赖。本文沿用这个基本认识，进一步提出一个用于日常交接的工作模型。[过程方法说明](https://www.iso.org/iso/iso9001_2015_process_approach.pdf) 模型从一个共同目标出发：**上一过程形成结果 → 对照下一过程需要验证 → 明确接收结论 → 核对启动条件 → 进入下一过程。** 这里要分开看两件事。 第一个是，交来的结果是否符合约定。需求有没有确认，图纸是不是现行版本，数据有没有来源，交付物是否在约定范围内。它回答“这份交付能不能用”。 第二个是，下一过程是否具备启动条件。负责的人是否能够承接，必要的材料和资源是否到位，相关决定是否已经确认。它回答“现在能不能开始”。 一份合格的图纸，可能因为材料尚未到货而暂时不能进入制作。这时应记为“交付已接收、制作待启动”，继续处理材料问题。不能把所有等待都退回设计人员，也不能因为图纸已经接收，就把制作写成已经开始。 可左右滑动查看图示，也可打开大图。 [![图一：交付成为下一过程起点的条件。交付核对与启动确认分别进行，接收不自动意味着已启动。](https://yutengfei.com/journal/process-handover-and-entry-conditions/materials/zh/01-handover-to-next-process.svg)](https://yutengfei.com/journal/process-handover-and-entry-conditions/materials/zh/01-handover-to-next-process.svg) 图一：共同目标与约束贯穿各环节。箭头表示交接和判断顺序，不表示客户或经济结果已经实现。 [打开大图 ↗](https://yutengfei.com/journal/process-handover-and-entry-conditions/materials/zh/01-handover-to-next-process.svg)[下载可编辑 SVG ↓](https://yutengfei.com/journal/process-handover-and-entry-conditions/materials/zh/01-handover-to-next-process.svg) ## 二、交的是什么，要按下一步的用途来写 “需求整理完成”“方案已经提交”，都太容易产生不同理解。 下一步要做报价，至少需要知道报什么、报多少、什么时候交付，以及哪些条件已经确认、哪些仍是估计。下一步只做初步方案，则可能允许部分信息暂缺，但要把假设标出来，说明哪些判断还不能作。 同一份资料，用在不同环节，适用标准可能不同。因此，交接要求应在工作开始前由相关角色确认；业务中确实发生变化，再按约定调整。接收方不能临到交接，才不断增加原来没有约定的要求。 我建议先把下面六件事说清楚。它们可以写在已有任务单、文件说明或系统字段里，不必另造一套厚表格。 | 要说清的事 | 交接时能够回答什么 | | --- | --- | | 用途与边界 | 供哪个过程使用，支持什么判断，覆盖哪些范围 | | 结果与版本 | 交付对象在哪里，当前是哪一版，形成于什么时间 | | 核对依据 | 关键事实依据什么确认，来源和必要的核对记录在哪里 | | 接收标准 | 达到什么要求才可接收，采用哪一版标准 | | 承接与期限 | 谁提交、谁核对、谁负责后续，什么时候答复 | | 缺口与处置 | 哪些尚未确认，会影响什么，由谁在何时补齐或决定 | 结果与依据也要区分。一次沟通记录，可以证明双方讨论过某个条件，却未必证明条件已经得到确认。一份看起来完整的 AI 生成方案，也未必能够证明其中的价格、规格或交期真实有效。 接收者拿到交付后，要能看明白：哪些内容可以据此行动，哪些还需要核实，用到什么范围需要重新确认。 ## 三、谁来核对，不能只剩一句“请验收” 提交方先按约定自查，接收方核对与自己工作有关的输入。专业判断、对外承诺和超出原授权的事项，再交给有相应权限的人确认。 小团队可以由同一个人兼任几个角色，重点仍是把判断的依据和责任写清楚。关键事项存在明显利益冲突时，需要另行安排适当复核。普通、低成本且容易纠正的交接，可以采用简明确认或抽查；风险较高、改错成本较大的环节，再增加检查。不能每一步都层层签字，把协作成本推得比原来的问题还高。 接收结论应具体。例如：“需求表 V2 已按报价输入标准核对，规格和数量可用于测算；正式交期尚待供应确认，不得据此向客户承诺。”这比“收到”“没问题”更容易继续工作。 “收到”只说明资料送达；“接收”说明指定范围的交付通过核对；“启动”说明下一步的实际条件也已具备。任务系统可以采用不同状态，但应让参与者看得出这几个区别。 还要约好答复时间。逾期没有回复，应进入提醒和协调，不能默认通过；接收方拒绝时，也应指出未满足的标准和具体缺口。双方都有责任减少无依据的等待和反复。 ## 四、接不上，先看是哪一种问题 交接出了问题，最容易采用的办法是“退回重做”。但有些问题不在交来的成果本身，再做一遍也解决不了。 可以先分成三类。 **成果存在缺口。** 比如缺少已约定的规格、关键数据无法核对、文件版本不一致。指出具体缺口和影响，由相应责任人补充或修正，再按有效标准重新验证。已经合格且未受影响的部分，不必一并推倒。 **标准或权限存在分歧。** 比如双方对“已确认”理解不同，或者需要承诺一个原来没有授权的交期。先找回原约定，必要时由有权角色决定适用标准、范围与责任。不能让接收人员凭个人意见新增条件，也不能让提交人员为了赶进度代替别人承诺。 **业务条件发生变化。** 比如客户改了需求、供应能力变化，或者下一步资源暂时不足。先判断影响范围，由相应角色决定补资源、调整范围或时间、暂停，还是终止相关工作。成果本身合格，也可能暂时不再适用。 可左右滑动查看图示，也可打开大图。 [![图二：交接异常的三类处理路径。问题处理后，拟继续的事项都回到重新验证；暂停事项须确认恢复条件。](https://yutengfei.com/journal/process-handover-and-entry-conditions/materials/zh/02-exception-and-revalidation.svg)](https://yutengfei.com/journal/process-handover-and-entry-conditions/materials/zh/02-exception-and-revalidation.svg) 图二：异常分类用于找到合适的处理入口。纠正成果、解释标准和调整业务条件各有责任，不应全部归为执行不力。 [打开大图 ↗](https://yutengfei.com/journal/process-handover-and-entry-conditions/materials/zh/02-exception-and-revalidation.svg)[下载可编辑 SVG ↓](https://yutengfei.com/journal/process-handover-and-entry-conditions/materials/zh/02-exception-and-revalidation.svg) 确有必要时，可以在明确范围内有条件接收。例如先做内部测算，同时补确认信息。此时要有相应权限，写明允许做什么、禁止据此做什么、补齐期限，以及条件未满足时怎样停止或回退；这些安排确认后，还要重新核对受限工作的输入和启动条件。 有条件接收，也不能跳过必须满足的要求。凡是没有权决定、无法控制后果，或者必须先完成的必要核对，仍应暂停相关动作。暂停也要有人跟进，说明待什么条件恢复、何时复核。已经承担的履约、费用和善后责任继续按约定处理，不会因为状态改成“暂停”就消失。 ## 五、用一次报价交接，看看模型怎样落地 下面是专门编写的虚构情境，用来说明模型，不对应某家企业的实际记录。 客户提出一批定制设备需求。需求协调人将材料交给报价负责人，双方事先约定：正式报价需有已确认的规格、数量、交付地点和期望交期，并注明未解决事项。 第一次提交时，规格和数量已经确认，交付地点仍有两个备选。报价负责人指出缺口，说明运输费用无法据此确定。需求协调人随后确认地点，提交 V2，保留前一版与修改说明。 核对 V2 后，报价所需输入已经满足约定，但供应方尚未确认产能。这里需要继续区分：内部成本测算可以开始；向客户发出包含确定交期的正式报价，条件尚未具备。 有权负责人决定，允许先在限定范围内做内部测算。任务记录注明产能确认的责任人、截止时间，以及不得向客户承诺交期的限制。相关输入和资源重新核对后，内部测算启动。 如果供应方随后反馈无法满足期望交期，就由相关角色与客户确认调整。若客户改变规格，应识别受影响的测算和材料，按新版本重新核对，不能沿用“V2 已接收”的结论继续对外报价。 这个例子里，模型帮助区分了资料缺口、承接条件和对外决定，也保留了一部分可以先做的工作。它并不能保证客户最终成交，更不能单凭一次交接顺利就证明整套流程提高了业绩。 ## 六、共同目标，要能约束每一个局部的“完成” 销售希望快一点，报价希望资料完整，供应方希望条件稳定。这些需要都有实际原因。共同目标的作用，是让相关角色围绕同一笔业务讨论取舍：客户要解决什么问题，时间、成本、质量和履约条件怎样平衡，哪些承诺不能作。 它并不要求每个人利益相同，也不能成为向某一方无限加任务的理由。新增工作、等待和返工有成本，需要说明由谁承担，超出原约定时由谁决定。 在资源、运管、客户、资本四生态中，都可能发生这类交接；不同角色可以主动贡献，也可以响应需求。具体事项仍按业务关系和授权办理。精干运管负责相关决策、规则和协调，把价值生产、销售渠道及客户关系接起来，而不是替所有专业角色作判断。 这套模型处理的是交付与承接。交付记录可以为后续评价提供事实，但不自动等于全部贡献，也不自动带来报酬、股权、分红或决定权；有关制度权益需要依据实际业务和相应约定另行处理。 使用时，可以先选一处反复出问题的交接，记录资料缺口、等待原因、返工、核对成本，以及对客户履行的影响。试行后再看：哪些检查有用，哪些标准过重，异常有没有更快找到负责人。缺少对照和足够记录时，先保留观察结果，不急着归因。 如果一笔业务最后没有达到预期，还是要先沿着客户需求、产品与价格、履约、渠道和回款等业绩链找问题，再决定调整哪些业务、职能或动作层面的 SOP。交接只是其中一段，不能用它解释所有经营结果。 流程走到下一步之前，交付要让接收者知道：现在可以据此做什么，还有什么不能做，出了变化找谁处理。把这些条件接起来，才知道流程究竟前进到了哪里。 * * * ### 来源与关联阅读 - 模型依据：早期团队资料《SOP梳理设计方法论》，重点参考第 6—9 页关于前置任务、下一步流转、交接、特殊情况、试行与迭代的内容；两张早期“岗责、工作手册、SOP 与绩效考核”关系图提供“验证前置结果”的研究线索。本文的交接与异常机制为重新构建的工作模型，效果尚待具体业务检验。 - 概念参考：[ISO：The process approach in ISO 9001:2015](https://www.iso.org/iso/iso9001_2015_process_approach.pdf)。用于说明过程的输入、输出和相互依赖；本文并非标准条文解释或认证指南。 - [企业规划十步法：把方向、资源和执行接起来](https://yutengfei.com/zh/journal/enterprise-planning-ten-steps/)：从目标与资源安排，继续理解相互依存的协作承诺。 - [四生态治理模型：贡献、权益与协作闭环](https://yutengfei.com/zh/journal/four-ecology-governance-model/)：从相邻过程的交接，进一步理解多方关系和事项权限。 - [贡献记录与复核表：让评价有依据，也允许提出异议](https://yutengfei.com/zh/journal/contribution-record-review/)：交付之后，怎样记录和复核各自参与的事实。 ## 关联阅读 - [从岗责分析到角色工作手册：让共建者知道怎样贡献](https://yutengfei.com/zh/journal/co-builder-role-handbook/) - [日常、周期、触发、被动：角色任务怎样进入工作流程](https://yutengfei.com/zh/journal/role-task-entry/) [CC BY-NC-ND 4.0](https://creativecommons.org/licenses/by-nc-nd/4.0/) 原创文字内容适用，另有声明除外；第三方素材不适用。下载和机器读取不扩展现有许可，也不另行授权衍生作品、商业使用或模型训练。 [查看 AI 使用说明](https://yutengfei.com/zh/journal/ai/) --- # 从 SOP 到 Skill：哪些工作可以由 AI 协助，怎样验收 - 作者: Andrew David W.Y. - 来源: https://yutengfei.com/zh/journal/sop-to-ai-skill/ - 版本: R1 - 发布: 2026-11-04 - 修订: 2026-11-04 - 内容状态: 已公开全文 - 内容类型: 方法 (methods) - 研究专题: 利益相关者资本治理 (stakeholder-governance) - 生态视角: 运管生态 (operations) · 资源生态 (resource) ## 如何使用这项资源 **用途**: 从一段具体工作出发，判断 AI 的适用条件，约定输入、输出、验收与接管方式，让 Skill 接入企业协作，同时保留业务判断和责任。 **使用条件**: 使用前请核对对象、目标和约束是否适合当前任务；正文未明确的条件需要另行确认。 **方法 · 步骤、输入与完成条件** **依据与验证边界**: 正文提供试行方法。实际接入前应约定输入权限、输出验收、停止条件和人工接管责任。 本文未单独登记外部验证结果。公开发布不等于效果已经验证，请结合正文依据、假设与限制判断。 这是可阅读、可引用的知识资源，不是已安装的 Skill。交给 AI 使用时，请保留来源与限制，并核对产出。 ## 正文 企业已经有 SOP（标准作业流程），能不能把文件交给 AI，让它照着做？ 可以先从其中一部分工作开始。先说清楚：交给 AI 的究竟是哪一段工作，需要什么资料，交出什么结果，谁判断这个结果能否进入下一环节。 例如，整理客户需求、比对产品资料、列出缺失信息，可以由 AI 协助。确认需求是否真正得到满足、接受什么交易条件、向客户作出什么承诺，则需要相应责任角色作出判断。两类工作可能出现在同一份 SOP 中，却有不同的执行条件和责任要求。 从 SOP 到 Skill，可以把已经明确、适合 AI 协助的工作写成可复用的行动指南，再接入原有协作。Skill 能不能用，要看它交出的结果经过怎样的核对，以及出了问题能否及时停下、交回给人。 ## 先区分业务流程与 AI 行动指南 SOP 说明一项工作在什么条件下开展，经过哪些过程，各角色需要做什么，达到什么标准，怎样交接。它所约束的是业务中的工作关系。 本文所说的 Skill，指供 AI 调用的任务指南及配套资源。以 Agent Skills 开放格式为例，一个 Skill 至少包含 `SKILL.md`，也可以带有脚本、参考资料和模板。它用于向 AI 提供特定任务所需的方法和上下文。[¹](https://agentskills.io/home) 二者不能等同。一份业务 SOP 可能要由多个角色、多个工具以及若干 Skill 共同完成；一个资料核对 Skill，也可能被不同业务流程调用。SOP 还包含现场工作、协商、决策、责任和交接，其中只有一部分适合进入 AI 的执行范围。 因此，不能只把 SOP 改成指令语气，就认为完成了转化。还需要核实 AI 能否取得必要资料、使用相应工具、识别例外，并留下可检查的成果。Skill 文件里的步骤，也不能自行扩大执行者的授权范围。 四向 SOP 将工作分为业绩、业务、职能和动作四个层次。使用时，应先从与客户及经济结果相关的业绩链寻找问题，再按需要组织业务协作、职能任务和具体动作的改进。AI 协助可以落在不同层次的具体工作上，不必把整条业绩链封装成一个 Skill。如果真正的问题是需求定位、产品条件或渠道选择，单纯加快文档处理，也未必能改善经营结果。 ## 从一个可检查的工作段开始 可以先选择一个边界清楚、容易回看结果的任务，例如“依据指定资料，整理客户需求及待确认事项”。选择时，先回答五个问题。 | 要核对什么 | 适合开始的条件 | 条件不足时怎样处理 | | --- | --- | --- | | 工作目的 | 能说明成果供谁使用、支持哪个下一步 | 先澄清业务问题和使用者 | | 输入资料 | 来源、版本、必要字段与可使用范围明确 | 列出缺项，补充资料或调整范围 | | 输出结果 | 有可交接的清单、表格、草稿或其他成果 | 先约定成果形式和完成条件 | | 验收依据 | 能根据原始资料或业务标准判断是否可用 | 先由业务人员明确标准和反例 | | 异常与责任 | 说明何时停止、谁接管、谁确认使用 | 先确定处理方式和责任角色 | 这里还要判断，是否真的需要 AI。固定字段转换、确定规则计算等工作，如果用表格公式或脚本即可可靠完成，可以直接使用这些工具。需要理解自然语言、归纳非结构化资料、形成初稿或提出待核实判断的部分，才进一步评估 AI 是否有帮助。 遇到标准还在争论、资料无法取得、错误后果难以挽回的工作，可以把 AI 的任务缩小到整理事实和提出问题。先让人掌握判断所需的信息，再决定是否扩大协助范围。 可左右滑动查看图示，也可打开大图。 [![图1：从业务问题筛选 AI 协助工作段，再形成 Skill，并经过试行后接入 SOP](https://yutengfei.com/journal/sop-to-ai-skill/materials/zh/01-sop-to-skill-boundary.svg)](https://yutengfei.com/journal/sop-to-ai-skill/materials/zh/01-sop-to-skill-boundary.svg) 图1｜先选工作，再组织 Skill。是否采用以及采用到什么程度，取决于输入、验收和接管条件。 [打开大图 ↗](https://yutengfei.com/journal/sop-to-ai-skill/materials/zh/01-sop-to-skill-boundary.svg)[下载可编辑 SVG ↓](https://yutengfei.com/journal/sop-to-ai-skill/materials/zh/01-sop-to-skill-boundary.svg) ## 把输入输出和停止条件写进任务指南 一份可用于协作的 Skill，需要让使用者和审核者都知道它将做什么。以前面的需求整理任务为例，可以这样约定。以下为假设示例。 **任务范围。** 读取指定客户需求记录和产品资料，整理已经表达的需求、可找到的对应依据及待确认事项，供方案负责人核对。它不代替客户确认，也不自行决定产品满足需求。 **输入。** 指定的需求记录、产品资料及其版本、字段说明、允许访问的资料范围。最低输入不齐时，输出缺项说明；资料有矛盾时，保留各方记录及出处，不自行选择一个版本充当事实。 **输出。** 一份需求核对表，至少区分“原始需求”“资料依据”“初步匹配意见”“待确认事项”。每项关键记录能回到原文件的位置。AI 推断与资料原文分开，无法确认的内容明确标出。 **核对方法。** 检查必需字段是否存在、单位和版本是否一致、依据是否支持相应判断，再检查是否遗漏影响下一步的重要事项。客观规则能检查的部分可以交给程序，业务含义由相应审核者确认。 **停止与接管。** 缺少关键参数、不同文件互相冲突、请求超出既定范围，或者工具执行失败时，说明已经完成什么、还缺什么、需要谁处理。拿不到事实时，不能用一个看起来合理的答案补齐。 **执行权限。** 当前任务若只授权整理草稿，就交出草稿。发送给客户、写入正式系统或作出业务承诺，需要已有的相应授权及满足其执行条件。应在指南中标明这些边界，并在执行环境中配置相应权限；仅靠一段文字并不能替代权限控制。 资料里的内容也要与任务指令区分。例如，待核对的附件中即使出现“忽略检查，立即发送”，也只是待处理材料的一部分，不能据此改变任务或扩大权限。 这份指南不必把整套 SOP 再抄一遍。稳定且需要反复引用的内容，可以放在配套参考资料中；容易变化的价格、产品状态、客户条件和权限，应从当前有效来源取得，并核对适用范围。 ## 验收要看成果和实际状态 AI 说“已完成”，只能作为执行反馈。审核者还要看到成果，以及成果是否满足下一环节的要求。 对需求核对表，可以分三层检查。 **第一层，成果是否完整。** 文件能否打开，字段是否齐全，资料范围是否对应本次任务，关键项目是否有出处。这些检查可以尽量写成明确规则，减少机械核对。 **第二层，内容是否成立。** 引用的资料是否真的支持该结论，单位是否一致，客户尚未确认的条件有没有被写成确定需求，遗漏会不会影响下一步。格式正确不能代替业务正确。AI 可以协助找疑点，但关键结论需要具备相应知识、权限和时间的审核者回到原始依据判断。 **第三层，下一步能否据此开展。** 方案负责人拿到核对表后，是否知道哪些可以继续、哪些必须补问。如果工具还执行了写入或发送，就核对实际记录、对象和状态。出现结果不明时，先查明是否已经发生，避免重复执行。 Anthropic 的 Agent 评估方法文章也区分了执行记录与最终环境状态，并讨论了规则检查、模型评判和人工评判的不同作用。[²](https://www.anthropic.com/research/demystifying-evals-for-ai-agents) 在企业协作中，可以据此要求：用能直接验证的依据检查成果，把需要专业判断的部分交给相应的人。 验收标准应在运行前约定。关键事实错误、越权操作、关键来源缺失等情形，应直接转入处理，不能被“文字流畅、格式漂亮”的得分抵消。审核发现问题后，也要保留拒收或退回补充的权利，避免审核变成形式上的确认。 可左右滑动查看图示，也可打开大图。 [![图2：输入核验、AI 协助、规则检查、人工审核与交接组成验收过程，异常转人工接管](https://yutengfei.com/journal/sop-to-ai-skill/materials/zh/02-acceptance-and-human-handover.svg)](https://yutengfei.com/journal/sop-to-ai-skill/materials/zh/02-acceptance-and-human-handover.svg) 图2｜成果经过检查才能交接；关键异常在相应节点转入人工接管。图示是一种待试行的组织方法。 [打开大图 ↗](https://yutengfei.com/journal/sop-to-ai-skill/materials/zh/02-acceptance-and-human-handover.svg)[下载可编辑 SVG ↓](https://yutengfei.com/journal/sop-to-ai-skill/materials/zh/02-acceptance-and-human-handover.svg) ## 先试行，再决定怎样使用 第一次成功，只能说明在当时的资料和环境下完成了这一次任务。要判断能否复用，需要主动准备会遇到的不同情形。 仍以需求整理为例，试行至少应覆盖：资料齐全、缺少关键条件、同一参数存在不同版本、单位不一致、资料无法读取、出现超范围要求。还要检查，AI 应当停下时能否停下，应当继续时是否又过早交回给人。 先由业务人员确定每种情形下可以接受的结果，再运行并复核。对容易波动的关键情形重复观察，并保留部分未用于调整指南的材料作复核。样本的数量和范围随业务风险确定，小范围试行不能证明所有企业、所有任务都能使用。 评价时，要把成果质量、人工审核时间、返工和异常一起记下来。只计算 AI 生成初稿的时间，可能漏掉后续核对成本。可以与原有工作方式比较：在相近资料条件下，是否更快得到可用成果，是否更容易发现遗漏，接手的人是否少了重复确认。 根据结果，可以继续保留人工逐项审核，只采用其中某一部分，调整指南后再试，也可以停止使用。只有低后果、规则清楚且验证充分的工作，才考虑在既定授权内减少人工逐项检查，同时保留抽查和异常接管。 每次试行保留 Skill 版本、输入资料版本、交付成果、审核结论与未决事项。业务规则、资料来源、模型或工具改变后，据此确定需要重新核对的范围。 单次任务验收通过，说明本次成果满足约定要求；一项 Skill 能否复用，还要看其在已测试情形中的表现及后续使用记录。是否进一步改善客户体验、成交或其他经济结果，还需要回到业绩链持续观察，不能把一次任务完成直接写成经营成效。 ## AI 参与之后，责任仍需落实到角色 在资源、运管、客户、资本四个生态中，各类角色都可能主动贡献，也可能响应需求。谁制作、调用或维护 Skill，应按实际工作安排；精干运管负责相应决策、规则和协调，组织价值生产与销售渠道、客户关系之间的协作。 具体到一段 AI 协助工作，要明确三件事：谁维护业务要求和验收标准，谁对本次输入与执行负责，谁确认成果可以进入下一环节。这些责任可由适当角色兼任；需要相互复核的关键工作，则按业务后果安排复核。不能因为增加了“AI 审核”几个字，就默认有人具备审核能力并承担责任。 价值贡献角色的工作手册，可以列出其可调用的 Skill、交付要求和协作接口。消费客户和单纯投资人分别走对应流程，不因这些身份要求配共建工作手册。参与者使用什么 AI 工具，也不直接决定贡献和权益；相关安排仍按实际业务、交付和制度确定。 从一项重复发生的真实工作开始，明确它支持哪一个结果、哪些部分适合 AI、依据在哪里、异常时谁接手。把这些条件写清、试过、改过，再逐步接入协作，Skill 才能成为组织中可使用、可维护的一项能力。 ## 延伸阅读 - [供 AI 使用的智库](https://yutengfei.com/zh/journal/ai/)：理解知识、任务、工具与授权的关系。 - [我的 Skill](https://yutengfei.com/zh/skills/)：查看经验、判断和方法怎样形成可调用的行动指南。 - [企业内容体系，怎样做到统一表达、持续更新？](https://yutengfei.com/zh/journal/business-content-system-maintenance/)：继续讨论资料事实、审核和更新。 ## 资料说明 本文承接早期《SOP 梳理设计方法论》中有关操作标准、评判标准、特殊情况处理、试行与迭代的思路。AI 协助范围、验收和接管机制为本篇进一步提出的方法设计，文中的需求整理任务为假设示例。 ¹ [Agent Skills Overview](https://agentskills.io/home)，说明开放格式的基本构成；本文不将文件格式等同于企业业务流程。 ² [Demystifying evals for AI agents](https://www.anthropic.com/research/demystifying-evals-for-ai-agents)，2026 年 1 月 9 日，提供 Agent 评估中的方法参考；不作为本文机制已在企业中验证的证据。 ## 关联阅读 - [动作、结果与沉淀：一次工作怎样变成组织能力](https://yutengfei.com/zh/journal/action-results-organizational-capability/) [CC BY-NC-ND 4.0](https://creativecommons.org/licenses/by-nc-nd/4.0/) 原创文字内容适用，另有声明除外；第三方素材不适用。下载和机器读取不扩展现有许可，也不另行授权衍生作品、商业使用或模型训练。 [查看 AI 使用说明](https://yutengfei.com/zh/journal/ai/) --- # SOP跑完了，为什么没有业绩？ - 作者: Andrew David W.Y. - 来源: https://yutengfei.com/zh/journal/sop-business-outcome-diagnosis/ - 版本: R1 - 发布: 2026-11-04 - 修订: 2026-11-04 - 内容状态: 已公开全文 - 内容类型: 方法 (methods) - 研究专题: 利益相关者资本治理 (stakeholder-governance) - 生态视角: 运管生态 (operations) · 客户生态 (customer) ## 如何使用这项资源 **用途**: 先核清客户与经济结果，再沿实际业绩链查找偏差，区分经营条件与工作机制，按证据组织必要的SOP改进。 **使用条件**: 使用前请核对对象、目标和约束是否适合当前任务；正文未明确的条件需要另行确认。 **方法 · 步骤、输入与完成条件** **依据与验证边界**: 文中案例用于演示分析和操作。应用时请用实际业务记录替换示例条件，再核对判断和结果。 本文未单独登记外部验证结果。公开发布不等于效果已经验证，请结合正文依据、假设与限制判断。 这是可阅读、可引用的知识资源，不是已安装的 Skill。交给 AI 使用时，请保留来源与限制，并核对产出。 ## 正文 客户联系了，需求表填了，报价发了，跟进记录也齐了。每一项任务都显示完成，月底却发现：订单没有增加，客户没有留下来，钱也没有按预期回来。 这时候，管理者容易想到两件事：再把流程写细一点，或者要求大家执行得更严格一点。 这两种做法有时有用，但先要弄清楚：现在的问题，究竟出在工作没有做好，还是做好的这项工作，本来就不足以带来预期结果？客户是否需要这个产品，是否接受这个价格，渠道找到的是不是合适的人，这些都需要放进来判断。 我认为，业绩没有达到预期时，可以先沿着业绩链查问题，再决定需要启动哪些业务、职能和动作层面的SOP。先把问题找到，流程改进才知道要解决什么。 ## 先分清三个“完成” 这里的SOP（标准作业流程），是把一项工作的步骤、要求和例外处理写清楚，供团队执行和检查的工作指南。文中把与客户和经济结果相连的关键业务路径称为业绩链。 在早期的《SOP梳理设计方法论》中，业绩SOP指向与客户强关联、以经济目的为结果的核心业务逻辑，业务、职能和动作SOP为它提供支撑。我觉得这个起点要保留：看一项工作做得怎么样，要知道它最后支持什么结果。 其中，业务SOP处理跨角色的业务协作，职能SOP处理一项有明确结果的闭环任务，动作SOP说明具体操作。 实际使用时，还要把下面三个层面分开。 | 层面 | 要核对什么 | 能说明什么 | | --- | --- | --- | | 活动完成 | 有没有按要求联系、整理、发送、操作 | 工作发生过，相关步骤可以追溯 | | 过程结果成立 | 需求是否经核对，方案关键条件是否得到必要确认，交付是否达到约定 | 这一环节是否为后续工作提供了合格条件 | | 客户与经济结果实现 | 客户是否购买、使用、验收，收入、回款和经营收益是否达到目标 | 这条业务链是否实现了本期要观察的结果 | 发出报价，只能说明报价被发出。客户有没有收到、有没有理解、是否接受，还要继续核对。即便签了合同，也要分别看交付、收入、成本和回款。 工作完成以后，检查不能停在完成记录上。每个关键环节都要继续问一句：**这个动作想改变什么状态，现在有证据表明它改变了吗？** 标准作业仍然有价值。它可以稳定已有做法，为培训、比较和持续改进提供基线。Lean Enterprise Institute对标准作业的说明也把它放在持续改善的过程中，而不是把写出标准视为终点。[参考：标准作业](https://www.lean.org/lexicon-terms/standardized-work/) ## 把“没有业绩”说成一个可以调查的问题 “业绩不好”太宽，团队很难据此找到同一件事。 先选一条具体业务，明确服务哪类客户、销售什么产品或服务，再写清本期要检查的结果、实际差距和观察期限。例如，“本期新增订单少于计划”与“上一批到期应收款未到账”，调查对象和处理方法就不同。 这里有三个口径，要先说清楚。 第一，签约、收入、回款和利润分别看。它们之间有联系，但不是同一件事。一次促销可能增加订单，也可能带来更多折扣、退款和履约成本。 第二，把可比较的对象放在一起。比较同类产品、相近客户和相同成熟阶段的业务，记录渠道、范围和条件的变化。本月拿到的线索，未必都能在本月形成订单；不能把本月全部线索与本月全部订单直接相除，就当成这批客户的转化情况。 第三，约定什么时候再看。交付与回款还没到约定期限，不能提前判为失败；已经过了观察节点，也不能一直用“销售周期长”搁置问题。对尚未结束的事项，保留当前状态、下一次核对日期和负责人。 本步要留下的是一句清楚的问题：**哪一批业务，哪一个结果，在什么时间内，比原来的目标或基线差了多少？** 如果目标本身缺少依据，也要列为待核对事项。 ## 沿实际业绩链，找出结果从哪里开始偏离 以一项项目型销售为例，可以先把业绩链画成：接触合适客户、核清需求、形成可接受的方案与条件、达成交易、履行交付、完成约定结算。不同业务的顺序和节点会不同，复购、续约、退货、返工与退出也要按实际情况保留。 接着，把每个关键节点原本需要形成的结果，与实际证据放在一起。 可左右滑动查看图示，也可打开大图。 [![图一：先明确未实现的结果，再沿实际业绩链核对客户状态、证据与偏差。箭头表示检查路径，不表示每一步必然成交。](https://yutengfei.com/journal/sop-business-outcome-diagnosis/materials/zh/01-performance-chain.svg)](https://yutengfei.com/journal/sop-business-outcome-diagnosis/materials/zh/01-performance-chain.svg) [打开大图 ↗](https://yutengfei.com/journal/sop-business-outcome-diagnosis/materials/zh/01-performance-chain.svg)[下载可编辑 SVG ↓](https://yutengfei.com/journal/sop-business-outcome-diagnosis/materials/zh/01-performance-chain.svg) 图一：先明确未实现的结果，再沿实际业绩链核对客户状态、证据与偏差。这是项目型销售的检查示例；实际业务可以回访、重谈、返工或退出。[打开可编辑SVG](https://yutengfei.com/journal/sop-business-outcome-diagnosis/materials/zh/01-performance-chain.svg) 检查时，既看数量，也看质量、等待时间和未继续推进的原因。需求表有多少份，不如继续问：有多少份核清了客户要解决的问题、采购条件和决策过程？交付任务完成了多少，也要看客户是否按约验收、是否仍有待处理事项。 如果某一段开始出现明显偏差，可以先围绕它调查。但**发现偏差的位置，还不能直接当成原因**。报价以后流失，可能与价格有关，也可能是需求理解错了、交付条件不合适，或者接触的人没有购买权限。回款延迟，也可能与前面的交付争议有关。 因此，顺着链条看哪里受阻，还要回头核对这一环节收到的输入。上一步留下的问题，可能在后一步才显现出来。 ## 同时检查经营条件与工作机制 找到受阻环节以后，我建议把可能原因放在两组问题里共同核对。 一组检查这门业务目前是否成立。 | 经营条件 | 需要继续查什么 | | --- | --- | | 需求 | 问题是否真实、是否急迫，谁使用、谁决定、谁付钱，购买条件是否具备 | | 产品 | 方案能否解决问题，质量、使用方式、交付与服务是否适合当前客户 | | 价格与交易条件 | 客户是否理解总成本，预算、账期和合同条件能否接受，企业能否承担履约成本 | | 渠道 | 是否接触到合适对象，渠道承诺与实际供给是否一致，线索来源是否发生变化 | | 外部条件 | 客户预算、竞争选择、供给条件或其他约束是否发生变化，原来的判断是否还适用 | 另一组检查工作是否具备完成条件，以及现有做法能否得到需要的结果：前置资料是否合格，协作顺序是否合理，决策和交接是否清楚，资源与能力是否足够，标准是否适用，实际操作有没有偏离。 两组问题可能同时存在。例如，客户要求的交付时间变短，而内部确认供应能力的过程仍然很慢。这里既有外部条件变化，也有业务协作需要调整，不能只选一个理由解释全部问题。 调查可以使用订单、交付、验收、报价版本、沟通记录与财务记录，也可以请客户和参与者补充说明。不同来源相互核对，尽量找到发生了什么，而不是只收集支持原判断的材料。客户说“有兴趣”，与愿意按具体条件购买，支持的判断也不同。 证据还不足时，先把解释写成待验证假设。例如：“客户没有继续推进，可能是交期与采购时间不匹配。”接下来的工作是核对真实采购节点和可用交期。Strategyzer提出先识别关键假设，再设计测试、把证据返回假设的做法，可以为这一步提供参考。[参考：从关键假设开始测试](https://www.strategyzer.com/library/how-to-test-your-idea-start-with-the-most-critical-hypotheses) ## 查清什么问题，再组织什么改进 查完以后，要能说清下一步改什么。需要改哪一层，就组织哪一层的工作，不必把所有SOP都改一遍。 可左右滑动查看图示，也可打开大图。 [![图二：核清偏差后，同时检查经营条件与工作机制，按证据选择经营调整或业务、职能、动作SOP改进，再验证客户与经济结果。证据不足或条件不成立时可以补证、调整或暂停。](https://yutengfei.com/journal/sop-business-outcome-diagnosis/materials/zh/02-diagnosis-intervention.svg)](https://yutengfei.com/journal/sop-business-outcome-diagnosis/materials/zh/02-diagnosis-intervention.svg) [打开大图 ↗](https://yutengfei.com/journal/sop-business-outcome-diagnosis/materials/zh/02-diagnosis-intervention.svg)[下载可编辑 SVG ↓](https://yutengfei.com/journal/sop-business-outcome-diagnosis/materials/zh/02-diagnosis-intervention.svg) 图二：按证据选择必要干预。两组调查可以并行，几类行动也可能组合使用；每项改变要写明预期影响和复核条件。未到最终观察期限，不判定最终业绩失败；已出现的节点异常仍可及时查证。[打开可编辑SVG](https://yutengfei.com/journal/sop-business-outcome-diagnosis/materials/zh/02-diagnosis-intervention.svg) 如果需求或产品判断出了问题，就重新核对服务对象、产品范围和价值主张。如果价格、交易条件或渠道不合适，就由有权限的人决定是否调整。原来的经营前提已不成立时，还要考虑缩小、暂停或停止这项业务，并安排已有承诺的处理。 如果问题在跨角色的业务协作，可以启动业务SOP改进。例如，报价承诺需要供应、技术与交付共同确认，就明确确认顺序、时限、例外处理和决定权限。 如果问题出在一项闭环任务，就继续看它的设计、完成方式和结果标准。缺条件就补条件，方法不合适就改方法，需要改程序时再修改职能SOP。例如，需求核实一直没有核清使用与采购条件，需要明确这项任务的输入、输出、责任与完成标准。 如果结果目标和任务设计已经清楚，问题出在具体操作，就修正动作SOP。例如，使用了错误的报价版本、漏核一个必要字段，或者交接时没有附上已确认材料。此时培训、工具辅助和操作检查才有明确着力点。 还有一种情况，是大家已经按要求执行，但流程仍然无法产生合格结果。这时需要修改方法或标准，不能继续用原标准证明执行没有问题，就结束讨论。 这些层次按工作关系区分，不机械对应某个部门。一项问题可以涉及多个角色，也可以由同一个人承担几项工作。 ## 用一次小范围验证，检查改进有没有作用 举一个假设情境：一家提供设备配套服务的企业，联系人数、需求登记和报价发送都完成了，订单仍低于计划。这个情境用于说明方法，不是已验证的企业案例。 核对同一批客户后，团队发现部分报价超出了客户的采购窗口，另有部分方案不符合安装现场的条件。这个发现还不足以说明所有问题都来自报价速度，需要分别核实。 可以先选下一批条件相近的需求，调整需求核实与报价协作：在方案形成前确认现场条件和采购节点；对需要技术与供应协同确认的事项，约定反馈时间与例外处理。观察既包括资料合格率、确认耗时，也包括客户是否继续推进、实际成交、履约成本和后续回款。 如果需求核实更准确，报价也更及时，客户仍然不接受，就继续检查产品、价格及其他解释。如果成交增加，但返工和成本上升，也不能马上认定改进有效。多个条件同时改变时，要留下变更记录，避免把结果全部归功于其中一项。 第一次可以用一张简表，把改进做实。 | 记录内容 | 要写清的事情 | | --- | --- | | 结果偏差 | 对象、期间、指标口径、目标或基线、实际差距 | | 断点证据 | 哪个节点受阻，资料在哪里，输入是否合格，还有什么解释 | | 本次判断 | 当前证据支持什么，哪些仍待核实 | | 必要行动 | 改经营条件，还是业务、职能、动作SOP；谁决定、谁执行，投入多少 | | 复核约定 | 改进前约定何时检查过程与经营结果、与什么基线比较，什么情况下保留、调整或停止 | 等待观察也是一种明确状态，需要写明等什么、等到什么时候。暂停以后要安排客户、交付、款项和协作方的后续处理；恢复时重新检查条件。每轮都把结果和反例留下来，才有机会看清：这套方法在什么情况下能用，什么情况下还不行。 ## 让流程回到企业共同创造的结果 把方法放到企业生态中，资源、运管、客户、资本各方都可以主动提出问题、提供专业贡献，或响应具体需求。精干的运管团队负责相应决策、规则和协调，把价值生产、销售渠道及客户关系接起来。相关参与者共同提供事实，有权限的角色作出取舍，并明确后续承接。 检查业绩链，是为了看清工作怎样支持客户与经营结果。它不意味着把全部经营风险压给某个执行者，也不能仅凭完成记录就确认全部贡献及权益。具体报酬、责任和权益，仍按实际业务、合同与制度分别确定。 我更愿意从一条真实业务开始：这次没有实现什么结果，证据显示问题在哪里，下一步需要改变什么，何时回来检查。 SOP能把已经理解的工作组织得更清楚，也要允许团队发现原来的理解不够。保持这个入口，流程才有机会随着业务一起改进。这套诊断方法的效果，仍需要在具体业务中通过持续记录、结果变化和反例检验。 ### 方法来源与延伸阅读 本文承接早期《SOP梳理设计方法论》第2—4页的四向SOP关系、第6—9页的场景、前置任务、标准、试行与迭代思路。结果口径、同批业务观察、双向查证和必要干预的诊断路径为本次展开；两张图均按本文论证重新设计。 延伸参考：[Lean Enterprise Institute：标准作业](https://www.lean.org/lexicon-terms/standardized-work/)；[Michael Ballé：在办公室环境实施标准作业时，先明确要改善的问题](https://www.lean.org/the-lean-post/articles/how-do-i-implement-standard-work-in-an-office-environment/)；[Strategyzer：从关键假设开始测试](https://www.strategyzer.com/library/how-to-test-your-idea-start-with-the-most-critical-hypotheses)。这些资料提供相邻方法参考，不构成本篇诊断框架效果已验证的证据。 按需延伸阅读：[企业规划十步法：把方向、资源和执行接起来](https://yutengfei.com/zh/journal/enterprise-planning-ten-steps/)；[四生态治理模型：贡献、权益与协作闭环](https://yutengfei.com/zh/journal/four-ecology-governance-model/)。 ## 关联阅读 - [四向SOP：业绩、业务、职能与动作怎样连接](https://yutengfei.com/zh/journal/four-way-sop/) - [四向SOP怎么用：从业绩理清业务、人才和每天的工作](https://yutengfei.com/zh/journal/four-way-sop-practical-guide/) - [选一条业绩链，怎样启动企业生态改造](https://yutengfei.com/zh/journal/performance-chain-ecology-transformation/) - [从岗责分析到角色工作手册：让共建者知道怎样贡献](https://yutengfei.com/zh/journal/co-builder-role-handbook/) [CC BY-NC-ND 4.0](https://creativecommons.org/licenses/by-nc-nd/4.0/) 原创文字内容适用，另有声明除外；第三方素材不适用。下载和机器读取不扩展现有许可，也不另行授权衍生作品、商业使用或模型训练。 [查看 AI 使用说明](https://yutengfei.com/zh/journal/ai/)