FDE 落地手记 · 01
最近一次围绕经营看板、数据采集和 AI 工作流的交流，让我重新审视了自己参与建设的工具中台。
小程序、商城、ERP、BI、知识库、内容生产工具，每一个都有具体需求，也都能解释为什么要做。但当工具不断增加，使用者仍然要在多个入口之间切换、重新解释指标、找人确认数据时，系统建设就进入了另一个阶段：需要重新组织已经具备的能力。
这篇文章记录我对这一阶段的判断，以及一套可以逐步执行的整合办法。文中的方案是实践复盘与后续改进方法，不代表所有治理环节都已经完成。
一、一个“看起来已经完成”的需求，为什么还会继续消耗人
假设渠道负责人问：“今天的销售增长，究竟有没有带来更好的经营结果？”
销售看板能找到成交金额，投放系统能找到广告消耗，ERP 能找到商品出库，财务掌握产品成本和费用。每个模块单独看都成立，但回答这个问题仍需要人工拼接。
真正缺少的是一条可核验的业务路径：选择渠道和日期，取得相同范围的数据，解释差异，识别异常，找到负责人，记录后续处理。
因此，我会用四个问题重新检查一个工具：
| 检查项 | 要问的问题 | 应当留下的记录 |
|---|---|---|
| 使用目的 | 用户拿到结果后，会作出什么决定？ | 决策与对应动作 |
| 数据依据 | 数字来自哪里，适用于什么范围？ | 来源与指标定义 |
| 交付责任 | 失败、缺数、结果冲突时谁处理？ | 维护人与处理路径 |
| 重复价值 | 下次相同任务，是否还需要从头解释？ | 可复用规则与模板 |
一个模块没有独立使用价值，并不意味着其中的代码和经验没有价值。它可能适合成为另一个流程的内部步骤。
二、先盘点业务任务，再盘点软件菜单
直接从页面数量出发，很容易把整合做成一次导航改版。我更倾向于先列出业务每周反复发生的任务，例如：渠道经营复盘、异常退货排查、库存补货判断、商品详情页策划、制度查询。
然后为每个任务建立一张很短的任务卡：
任务：渠道经营复盘
使用者：渠道负责人、经营管理者
触发：固定复盘周期，或经营指标出现异常
输入：销售、退款、投放、商品成本、费用规则
交付：可追溯的经营结果及异常清单
后续动作：核实数据、调整投放、检查商品或履约问题
完成标准：负责人能解释主要差异，并记录处理结论
这张卡能够暴露真正的缺口：有时缺页面，有时缺成本数据，有时缺统一规则，还有时只是没有人负责处理异常。四种问题需要四种解决办法。
三、把中台组织成三个相互连接的层次
我会把已有能力整理成以下结构：
- 决策入口：公司经营总览、渠道经营视图、异常待处理事项。主要回答“发生了什么、需要关注什么”。
- 业务工作流：取数、分析、复核、产出、反馈。主要完成一项明确任务。
- 共享基础能力：登录、权限、指标、文件、任务执行、模型调用、日志和版本。
例如，工具目录可以继续保留，但经营负责人更常用的入口应当直接通向经营问题；商品策划人员则应能进入具体产品的内容生产流程。
这三个层次不要求使用同一种前端框架，也不要求立刻合并数据库。整合顺序可以是先统一含义和访问方式，再消除重复实现。过早重写全部系统，会把正在发生的业务需求一起拖进迁移工程。
四、用“共享程度”和“出错后果”决定集中管理的范围
业务人员自己做原型，有助于快速发现需求。需要集中管理的，是会影响多个部门判断的规则和基础能力。
| 能力 | 建议管理方式 | 原因 |
|---|---|---|
| 临时文案、个人工作模板 | 允许局部试验 | 影响范围有限，容易调整 |
| 经营指标与渠道映射 | 统一定义并维护版本 | 影响跨部门比较和汇总 |
| 合同、成本、结算规则 | 指定业务负责人确认 | 涉及经营与财务责任 |
| 数据访问与敏感字段 | 服务端统一控制 | 不能依赖客户端自觉遵守 |
| 模型与流程编排 | 在兼容边界内迭代 | 需要同时兼顾试验与稳定 |
这样做可以保留业务探索的速度，也能减少“同一个销售额有三套算法”的问题。
五、功能做减法，要有可执行的判断办法
我会把功能放进四种处理队列：保留、合并、观察、退出。
判断时至少查看近期使用情况、任务重要性、结果接受情况、维护耗时和替代方案。低频不一定低价值：月度结算工具可能一个月才用一次，但业务后果很重要。高频也不一定高价值：一个入口被频繁点击，可能恰恰因为用户一直找不到答案。
具体做法是先选一个完整业务任务，找出它跨越的所有工具，再逐步合并重复步骤。例如，把三处重复上传销售报表的动作改成同一个有来源记录的上传入口，把各自维护的渠道别名改为共享映射。
退出功能也应当有交接：明确替代入口，保留必要历史记录，给使用者迁移时间，确认没有仍在调用的任务，再停止服务。
六、一个人能维护多少工具，取决于故障负担
AI 降低了写出第一个版本的成本，却不会自动消除依赖、账号、接口和数据规则的变化。
可以粗略记录一个维护周期内的投入：
维护负担 = 故障排查时间 + 人工补数时间
+ 规则解释时间 + 升级兼容时间 + 使用支持时间
这个记录有助于判断：某个看似节省时间的功能，是否把时间转移到了维护者身上。只要关键路径仍然依赖某个人不断重启任务、解释数字，系统就还有明显的改进空间。
优先处理高频故障和共享依赖，往往比增加新功能更能释放交付能力。
七、我对 FDE 工作的一个新要求
深入业务现场，会不断发现值得解决的问题；持续交付之后，还需要管理这些解决方案之间的关系。
我希望把每次局部交付留下的规则、映射、异常样本和使用反馈，积累成下一次能够直接复用的能力。衡量这件事的方式也应当更具体：完成相同任务需要跨多少个系统、重复核对多少次、遇到问题后多久能找到责任人，以及维护者离开现场时业务能否继续进行。
当这些问题逐步得到解决，中台才会形成清晰的经营支持能力。工具数量可以减少，系统承担的业务责任则会更加明确。
