FDE 与驻场外包的区别是什么？
六个可验收维度：计费基础、结果归属、团队去留、知识归属、客户自治时间、复用资产。差异写在合同条款里，不写在宣传语里。
02 定义
FDE 是在约束里做取舍的工程角色
同一个需求，在预算、合规、既有系统和组织习惯的夹缝里，可能有五种做法。FDE 的职责是判断哪一种能在这个客户身上跑通，并对结果负责。
是
- 先写约束清单，再写方案；约束写不成验收口径的项目，不接
- 把「被排除的路径」写进文档，说明为什么不可行
- 对上线后的可运维性负责，而不只对上线那天负责
- 把判断沉淀成适配器、模板与规则，让下一个项目起点前移
不是
- 不是按人天供给的驻场人力，不是「多一个人多一份工」
- 不是只交界面不交结果的外包，也不是只卖产品不改适配的厂商
- 不是把「智慧××」「行业领先」当标签的叙事型公司
- 不是永远在场的团队——能撤场，才说明交付成立
03 五段式
约束 → 判断 → 交付 → 移交 → 复用
所有页面按这条线组织，所有案例按这条线写。任何一段缺失，项目视为未完成。
01 约束
原始约束
业务、技术、合规、组织习惯、工期、既有系统六类，至少写清三类。
02 判断
被排除的路径
先写清楚哪些常见做法不可行、为什么不可行，再谈切口。
03 交付
最小业务闭环
只跑通一条链路上必需的字段，其余按需申请、留痕。
04 移交
能力交出去
移交包 + 培训 + 一次无我们在场的自治演练。
- 05 / 复用
- 每一次现场判断在 5 个工作日内写成一页记录（做了什么、放弃了什么、为什么），抽象成适配器、模板与判断规则进入资产库。下一个项目从资产库起步，报价中的复用抵扣来自这里，而不是折扣话术。
资产归属：客户专属资产归客户，客户可要求删除；公共资产去标识后复用。
04 差异
六个维度，都能在合同里被验证
看完这张表，可以拿它去比对任何一份报价单与合同。
| 维度 | 驻场外包（常见形态） | 伊索 FDE | 怎么验证 |
|---|---|---|---|
| 计费基础 | 人天 / 人月，投入时间即成本 | 里程碑与交付物，附结果指标口径 | 报价单是否出现「人天单价」 |
| 结果归属 | 交付需求清单与工时记录 | 对一个业务结果与上线后可运维性负责 | 验收单上写的是功能还是一项指标 |
| 团队去留 | 长期常驻，人走知识走 | 按阶段进出，约定撤场节点 | 合同是否写明撤场日期与条件 |
| 知识归属 | 留在乙方，客户拿到的是账号 | 移交包归客户：文档、脚本、SOP、台账 | 移交包清单是否为合同附件 |
| 客户自治时间 | 无定义 | 约定目标自治时间，到期做自治演练 | 是否有「连续若干周独立运行」条款 |
| 复用资产 | 每个项目从零开始 | 适配器、模板、判断规则进入资产库 | 新项目报价中是否出现「复用抵扣」 |
05 度量
退化的起点不是态度，是度量
一支团队只被按人天衡量时，判断会自然消失——因为判断不产生工时。所以我们用四个度量替代人天，其中运维指标已经在长期合同里被检验。
M-01
客户自治时间
从上线到客户能独立处理日常运维的时长，以一次无我们到场的自治演练为验收点。
M-02
判断复用率
新项目中被复用的历史资产占比，资产被第二个项目使用时计一次。按项目类型给区间。
M-03
上线后人工介入率
上线一段时间后仍需我们人工处理的工单比例。对外只展示趋势形态，不披露绝对值。
M-04
部署复用率
环境搭建中来自既有模板的步骤占比。不披露模板内容与拓扑细节。
| 指标 | 承诺 | 说明 |
|---|---|---|
| 故障响应 | 15 分钟 | 7×24 小时待命，依托 ITIL 框架与 ISO 20000 标准的三维运维体系 |
| 2 小时内解决 | 90% | 工单全流程留痕，处理过程可回溯 |
| 到场时间 | 30 分钟 | 海口市区 30 分钟到场，全岛 3 小时内到达 |
| 待命时长 | 7×24 | 监控、工单、巡检一体化运转 |
06 交付周期
五个阶段，每个阶段都有不出局的检查
周期长度按项目规模在 P1 结束时确认；这里给的是结构与验收点，不是承诺的日历。
| 阶段 | 我们的交付物 | 客户需要投入 | 不出局检查 |
|---|---|---|---|
| P0 约束盘点 | 一页约束清单 + 被排除路径初稿 + 判断备忘 | 一名对接人 + 现有文档 | 约束能否写成验收口径 |
| P1 最小闭环 | 可运行的最小业务闭环 + 演示环境 | 业务方参与验收口径确认 | 闭环是否解决一个真实业务动作 |
| P2 上线与验证 | 上线版本 + 指标基线 + 运行手册 | 运维接口人到位 | 指标口径双方书面确认 |
| P3 移交与演练 | 移交包 + 培训 + 一次无我们到场的演练 | 客户独立操作 | 演练由客户独立完成 |
| P4 退出或按次支持 | 《撤场评估》或按次支持协议 | 决策 | 自治条件是否达成 |
07 移交与撤场
四件事写进合同，不靠口头承诺
这一节是我们对自己的约束。条款越具体，客户越不需要靠信任来合作。
条款 01
自治目标日期
在 P1 结束时与客户共同确定并写入合同。到期以一次客户独立操作的演练作为验收，而不是以我们的进度汇报作为验收。
条款 02
移交包清单做附件
文档、脚本、SOP、台账、培训与演练一并列清单，作为合同附件。不接受「交付后再说」。
条款 03
退出验收标准
按可观察的三条判定：日常授权配置、一线支持、新增系统接入，能否由客户方独立完成。
条款 04
退出后的支持方式
按次或按期采购二线支持与版本升级评审，单价明码标价，不设隐藏依赖。
对我们不利、但我们写下来
如果到自治日期客户仍无法独立运行，责任在我们
这意味着我们要为「客户学得会」负责，而不只是为「系统能跑」负责。具体费用与补救方式以合同条款为准。
08 适用边界
什么项目适合 FDE，什么项目不该找我们
说清楚不做什么，比罗列能做什么更有用——尤其是在采购之前。
适合
- 既有系统多、厂商杂，需要在不推倒重来的前提下跑通一条业务闭环
- 合规与权限审计要求高，需要可自证的授权与留痕
- 上线后没有专职原厂运维岗，需要把运维能力交出去
- 希望在明确时间点结束外部依赖，而不是无限续期
不适合
- 按人天供给的长期人力外包：只出人、不定义结果的项目
- 只要求界面交付、不定义业务结果的项目
- 无法提供任何可验证数据或验收口径的项目
- 要求承诺不可审计结果，或需要绕过等保与审计要求的项目
09 常见问题
采购前最常被问到的六个问题
你们怎么计费？
按里程碑与交付物，每个里程碑附验收口径与退出条件。人天计费会把「问题变难」变成我们的收入来源，把「客户学会」变成我们的损失。
客户自治时间怎么定？
P1 结束时与客户共同确定并写入合同，由一次客户独立操作的自治演练验收，不由我们单方面承诺数字。
移交包里有什么？
文档（架构、接口、运维手册）、脚本（巡检与自检）、SOP（故障处置）、台账（资产与点位）、培训与自治演练。以可检索形式交付。
项目做完后，你们会不会赖着不走？
不会，前提是计量方式不是人天。条件达成时我们主动出具《撤场评估》；若到期客户仍无法独立运行，责任在我们。
哪些项目你们不接？
人力外包式驻场、只交界面不交结果、无验收口径、要求不可审计结果、需要绕过等保与审计的项目。
先看一次判断，再决定要不要合作
打给我们说说你的情况，我们回一份一页判断备忘：卡在哪、哪些路径不会走、最小闭环长什么样。