部门协作约定要解决的是跨部门交接时“谁来做、做到什么程度、卡住找谁”的问题。做法是先锁定高频协作接口，把每个接口的输入、责任角色、交付物、时限和异常处理写成可执行条款，再经双方负责人确认、小范围试运行和复盘修订。本文按内容框架、接口梳理、条款编写、角色确认、示例和完成检查六步展开，适用于一般部门之间的日常协作。
要点总览（TL;DR）
- 部门协作约定先定六部分框架：协作事项、角色与职责、信息同步、交接标准、冲突升级、检查与修订，每条按统一字段填写。
- 协作事项从跨部门交接点梳理，按发生频率、影响范围、争议程度排序，首版只覆盖高频高影响接口。
- 条款用“触发条件—责任角色—动作—交付物—时限—完成标志”结构编写，异常与升级路径写到具体角色和响应时限。
- 起草由接口业务负责人承担，双方部门负责人对等确认，涉及资源承诺的条款需上级确认，并设归口维护人管理版本。
- 约定先小范围试运行一个完整业务周期，按检查清单核对可执行性，修订后再确认、归档，作为日常交接依据。
先定协作约定的核心框架：一份约定要写清哪些内容
一份能用的部门协作约定，内容不必多，但六个部分要齐全：协作事项、角色与职责、信息同步、交接标准、冲突升级、检查与修订。缺少任何一块，约定在执行中都会留下模糊地带。比如只写了“需求由业务部门提给研发部门”，没写提交格式和响应时限，交接时双方仍会反复确认。
框架之下，每条约定按统一字段填写，保证不同人写出来的条款口径一致、可对照检查。
| 组成部分 | 回答的问题 | 条款字段 | 颗粒度要求 |
|---|---|---|---|
| 协作事项 | 哪些跨部门工作被纳入约定 | 事项名称、触发条件、发起方、承接方 | 一项工作一条，不合并不同性质的交接 |
| 角色与职责 | 谁发起、谁承接、谁确认 | 责任角色、备份角色、确认人 | 写到岗位或角色，不写“相关部门” |
| 信息同步 | 进展和变更如何告知对方 | 同步内容、渠道、频率、责任人 | 明确到什么信息、多久一次 |
| 交接标准 | 什么算交接完成 | 输入材料、输出交付物、完成标志 | 完成标志可被对方直接核验 |
| 冲突升级 | 分歧和延误怎么处理 | 异常情形、升级路径、响应时限、裁决角色 | 每一级升级有具体角色和时间 |
| 检查与修订 | 约定如何保持有效 | 检查周期、归口人、修订触发条件、版本记录 | 写明谁在什么情况下发起修订 |
颗粒度以可执行、可检查为准。“加强沟通、及时响应”这类表述无法判断是否做到，应替换为“需求提交后两个工作日内给出受理意见，由需求接口人在协作群回复”。时限、频次等数字按组织实际填写，本文示例中的数值仅作演示。
按接口梳理协作事项：从高频摩擦点提取约定条目
协作事项的来源是部门之间的工作交接点，而不是把两个部门的全部职责罗列一遍。梳理时以“一件工作从A部门交到B部门”为线索，逐个列出接口，形成接口清单，再从中筛选值得写入约定的条目。
具体做法分三步：
- 列接口。召集各接口的日常经办人，按业务流程顺序走一遍，记录每一次跨部门交接：谁交给谁、交什么、什么时候交、目前怎么交。
- 排优先级。对每个接口按发生频率、影响范围、争议程度三个维度打分。高频且影响大、经常扯皮的接口优先写入约定；低频偶发、双方已形成默契的接口可以暂缓。
- 记录现状与期望。每个接口写两栏：当前做法是什么，期望做法是什么。两栏之间的差距就是条款要解决的问题，也是后续和对方部门沟通的依据。
| 接口名称 | 发起方→承接方 | 发生频率 | 影响范围 | 争议程度 | 优先级 |
|---|---|---|---|---|---|
| 月度费用报销单据交接 | 各业务部门→财务部门 | 每月 | 影响付款进度 | 中 | 高 |
| 客户合同用印申请 | 销售部门→法务部门 | 每周多次 | 影响签约时效 | 高 | 高 |
| 办公用品领用 | 各部门→行政部门 | 不定期 | 影响较小 | 低 | 低 |
排序结果决定约定第一版的范围。建议首版只覆盖优先级高的接口，条款数量控制在双方都能记住和执行的规模，后续按检查结果增补。
逐条编写约定：输入、动作、输出与完成标志
把接口转化为条款，用固定结构写：触发条件—责任角色—动作—交付物—时限—完成标志。这个结构保证每条约定都能回答“什么时候开始、谁做、做什么、交什么、多久、怎么算完成”。
以合同用印为例，条款可写成：销售接口人在合同定稿后发起用印申请（触发条件），由销售接口人提交合同文本和审批记录（动作与输入），法务审核人在一个工作日内完成审核并反馈意见（责任角色与时限），审核通过的合同进入用印环节，审核意见以书面形式返回销售接口人（交付物），销售接口人确认收到审核意见即为该环节完成（完成标志）。
信息同步约定要写清四件事：同步什么内容、通过什么渠道、多久一次、谁负责。例如项目进度每周五由各接口人在共享文档更新一次，重大变更当天在协作群通知对方接口人。渠道和频率一旦写入约定，双方就按同一节奏对齐，减少临时追问。
交接标准要回答“什么算交接完成”和“缺件怎么办”。前者用可核验的完成标志表述，如“对方接口人确认收到并回复受理”；后者写明缺件时的处理方式，如材料不全时承接方在时限内一次性列出缺件清单退回，发起方补齐后重新计时，避免来回多次往返。
异常与冲突部分要给出升级路径、响应时限和裁决角色。常见写法是：接口人之间无法达成一致时，在两个工作日内提交双方部门负责人协商；仍无法解决的，升级至分管领导裁决。每一级都写明由谁发起、对方多久响应，升级才有实际作用。
角色与确认机制：谁起草、谁确认、谁维护
约定能否长期有效，取决于是否有人对它负责。制定和运行过程中涉及三类角色，分工要提前明确。
| 角色 | 承担人 | 主要职责 | 产出 |
|---|---|---|---|
| 起草人 | 协作接口涉及的业务负责人或接口人 | 梳理接口、起草条款、组织双方讨论 | 条款草案、接口清单 |
| 确认人 | 双方部门负责人 | 对等确认条款，承诺本方资源与时限 | 确认记录 |
| 上级确认人 | 分管领导 | 确认涉及资源投入、跨多部门的条款 | 审批意见 |
| 归口维护人 | 指定一名接口人或协作协调岗 | 版本管理、组织复盘、受理修订申请 | 版本记录、修订记录 |
确认采用对等原则：条款由双方部门负责人共同确认，单方确认的条款在执行中容易失效。涉及人力投入、预算或排期承诺的条款，需要上级确认后再写入，避免约定超出部门可支配的资源范围。
维护角色要明确修订触发条件和版本记录方式。触发条件可以是接口流程变化、连续出现执行偏差、组织调整等；版本记录写明修订日期、修订内容、确认人。新成员加入时，由归口维护人在入职引导中讲解与其岗位相关的条款，并纳入岗位交接材料，保证人员变动后约定仍被知晓。
示例：一次需求交接的协作约定怎么写
以下示例为演示性质，角色名称、时限和升级层级需按组织实际调整。
事项：业务部门向研发部门提交需求并完成受理。
触发条件：业务部门形成新的业务需求，需要研发部门评估或排期。
发起方与承接方：发起方为业务部门需求接口人，承接方为研发部门需求接口人。
输入：需求说明（背景、目标、期望上线时间）、涉及的业务规则、必要的样例数据。
动作：业务接口人在需求评审通过后提交需求说明；研发接口人在收到后两个工作日内完成完整性检查，确认受理或退回补充。
输出：受理回执（含受理结论和初步评估时间），或退回说明（一次性列出缺件清单）。
时限：受理反馈两个工作日内；初步评估结论五个工作日内。
完成标志：业务接口人收到受理回执，需求进入研发评估队列。
异常处理：研发接口人超时未反馈，业务接口人可在第三个工作日升级至研发部门负责人；双方对需求优先级有分歧时，提交双方部门负责人协商，两个工作日内未达成一致的，升级至分管领导裁决。
可调整部分：时限可按团队节奏调整；接口人可设备份角色；升级层级可按组织管理层级增减。需求说明的具体模板由双方共同确定后附在约定之后。
试运行与完成检查：约定是否真的可执行
条款写完不等于约定可用。建议先在小范围试运行，用实际执行检验条款。试运行范围选一到两个高频接口，周期覆盖至少一个完整业务周期（如一个月度结算周期或一个需求批次），由归口维护人记录每次执行中的偏差：谁没按时限完成、哪条完成标志无法判断、哪次升级没有走通。
试运行结束后，按以下清单逐项检查：
- 每条条款是否写明了责任角色，且角色在双方组织中都真实存在；
- 每条条款是否有时限和可核验的完成标志；
- 异常与升级路径是否实际走通过至少一次，响应时限是否合理；
- 是否存在无法执行的条款，例如依赖某个不常设的岗位或无法获取的信息；
- 信息同步的渠道和频率是否被双方实际使用；
- 新成员能否仅凭约定文本理解自己该做什么。
检查发现的问题回流到约定版本：由归口维护人汇总偏差，组织双方接口人讨论修订，修订后的条款再次经双方负责人确认。完成标志是三项同时满足：双方负责人确认、试运行通过、版本归档并可被引用。归档后的约定应放在双方都能访问的位置，作为日常交接和争议处理的依据。
约定进入日常运行后，接口交接、异常升级和修订记录需要有稳定的承载位置。ONES 的文档可用于存放约定版本和修订记录，工作项可承载需求受理、用印申请等具体交接事项并记录状态与时限，使条款中的完成标志和升级路径在执行中有据可查。工具承载的是管理动作，条款本身仍需双方确认后才生效。
常见问题
部门协作约定和部门职责说明书有什么区别，能不能合并？
两者可以互相引用，但承担的功能不同。职责说明书描述一个部门长期负责哪些工作，协作约定描述两个部门之间一次交接怎么完成。合并写容易出现“相关部门配合”这类无法检查的表述。更稳妥的做法是职责说明书保持稳定，协作约定按接口单独成文，并在约定中引用职责说明书的对应条目。
对方部门不愿意把时限写进约定，怎么推进？
先区分对方顾虑的是承诺本身还是承诺的刚性。可以从试运行入手：时限先按当前实际做法填写，标注为试行值，试运行一个周期后再根据偏差调整。同时把时限与升级路径配套写入，超时不是追责，而是触发协商，对方更容易接受。涉及人力投入的条款，提前请上级确认资源，避免条款超出部门可支配范围。
约定运行一段时间后接口流程变了，怎么修订才不混乱？
由归口维护人受理修订申请，先判断是局部调整还是接口重构。局部调整（如时限、渠道变化）走简化流程，双方接口人确认后更新版本；接口重构涉及角色和流程变化，需重新梳理接口并双方负责人确认。每次修订记录日期、内容和确认人，旧版本归档保留，便于追溯争议发生时的约定口径。
跨三个以上部门的协作，约定怎么组织才不至于互相等待？
多部门协作建议拆成两两之间的接口条款，再补一份总的流程说明，标明各环节的先后顺序和总时限。每个接口仍由对应两方确认，避免一份大约定因个别条款谈不拢而整体搁置。总流程说明中明确一个牵头接口人，负责跟踪整体进度和召集升级协商。
约定写好后放在哪里，新成员怎么知道？
放在双方都能访问的统一位置，与岗位交接材料关联。新成员入职引导时由归口维护人讲解与其岗位相关的条款，并指定备份接口人。约定文本本身要能被检索到，修订后及时更新，避免有人按旧版本执行。
