甲方FDE团队最怕的不是做不出东西，而是证明不了自己有用

最近FDE越来越热了。

很多企业开始意识到，AI项目真正难的不是模型能不能跑起来，也不是系统能不能上线，而是技术能不能真正进入业务现场，把问题解决掉。

于是越来越多甲方也开始考虑一个问题：既然外部FDE这么重要，那我们能不能自己培养一支FDE团队？

方向没有问题。但内部FDE团队一旦真正建立起来，很快就会遇到另一个更现实的问题：这支团队，到底应该怎么考核？

这是一个比招聘FDE更难的问题。因为如果这把尺子没定对，FDE很容易慢慢变成另一支项目经理团队、需求分析团队，甚至高级救火队。

一、很多FDE团队最后还是掉进了传统IT的坑

传统IT团队最熟悉的一套指标，我们都见过：今年上线了多少系统、完成了多少需求、交付了多少功能、关闭了多少Bug、项目是不是按计划上线。这些指标有没有用？当然有。

但如果用这套指标考核FDE，问题就来了。因为FDE本来就不是为了多做几个功能而存在的。

比如业务部门说每天整理销售数据太麻烦，希望做一个自动报表。FDE花两个月做出来了，系统也上线了，需求也验收了。从项目角度看，这是成功的。

但如果上线以后，业务人员每天还是把数据导出到Excel，再手工整理一遍，这个项目到底算不算成功？很难说。

再比如做了一个AI客服助手。模型准确率90%，回答速度很快，业务也觉得挺先进。但原来10个人做的事情，现在还是10个人在做，只是大家多打开了一个页面。这种项目到底创造了多少价值？

这就是甲方FDE最容易遇到的问题：东西做出来了，但业务没发生变化。

做出来了，不等于用起来了

二、甲方FDE真正要交付的，不是系统而是业务变化

所以我越来越觉得，甲方内部FDE团队不能再沿用传统研发团队那套考核方式。不能只问做了什么？而应该问业务发生了什么变化？这是两套完全不同的逻辑。

比如一个财务场景。以前每个月需要3个人花5天时间核对数据。FDE介入以后，把数据获取、异常识别、规则判断和结果输出全部串起来，最后可能只剩1个人花半天做确认。

这个时候系统本身反而没有那么重要。真正重要的是原来15个人天的工作，现在可能只需要0.5个人天。这才是结果。

再比如酒店每天做经营分析。以前店总早上需要等财务、运营分别统计数据，中午才能看到完整情况。如果FDE把数据、分析和异常提醒全部做进系统，店总早上打开手机就知道昨天入住率、人房比、异常成本和重点问题。

价值不是多了一个驾驶舱。而是原来靠人整理、靠人发现、靠人提醒的事情，现在系统接过去了。这才是甲方FDE真正应该创造的东西。

三、衡量FDE，我更愿意看三个结果

如果让我给甲方FDE团队定一把尺子，我会看三个东西：业务价值、接管程度、可复制性。这三个指标比做了多少项目更有意义。

比做了多少项目更重要的三个指标

1. 业务价值，业务到底变好了多少

这是第一层，也是最基本的一层。比如处理效率提升了多少？人工成本下降了多少？错误率下降了多少？转化率提升了多少？退款率下降了多少？库存周转有没有改善？一个动作原来需要两小时，现在是不是十分钟可以完成？

FDE最终一定要落到一个业务数字上。因为内部FDE最大的优势，就是离业务够近。如果连内部团队最后都只能拿上线数量和需求数量证明价值，那和传统IT其实没有太大区别。

2. 接管程度：原来人的什么工作不需要做了

这一点我觉得尤其重要，甚至很多时候，它比系统使用率更重要。我们过去做数字化，很喜欢看使用率：多少人登录了、日活多少、月活多少。

但到了AI时代，我反而觉得有些系统最好的状态，是用户根本不用天天进去。因为系统已经替他把事情做了。

所以甲方FDE项目做完以后，我会特别想问一句：这一次到底拿走了人的哪部分工作？

原来人工录入的，现在是不是自动生成？原来人工判断的，现在是不是系统先判断？原来人工盯着看的，现在是不是异常才提醒？原来一个五步流程，现在是不是只剩一步确认？

如果一个FDE项目上线半年以后，员工原来的工作内容基本没变，那这个项目大概率只是增加了一个工具。真正好的FDE项目，应该让人明显感觉到：这件事情以前我要做，现在不用我做了。这句话比100页项目总结都更有说服力。

3. 可复制性，下一次是不是还要从头再来

这是很多内部FDE团队最容易忽略的一点。FDE早期一定是驻场式的，钻进业务现场，一个流程一个流程地拆，一个问题一个问题地解决。这很正常。

但如果做了两三年，还是每来一个业务部门，就重新调研、重新写需求、重新开发一套，那这支团队实际上只是一个更灵活的定制开发团队。

真正成熟的内部FDE团队，应该越来越有一个特点：第一次解决问题，第二次复制能力。

比如第一次做酒店人效分析，可能需要两个月。但第二家酒店是不是只需要两周？第一次做合同风险识别，需要重新整理规则、数据和流程。到了第二个业务公司，是不是直接复用80%的能力？第一次做经营日报，是一个项目。后面再做物业、养老、商管，是不是已经变成一个平台能力？

这时候，FDE才真正开始产生复利。否则团队规模只能越来越大。业务越多，人越多。项目越多，人越多。最后又重新走回传统IT堆人的老路。

四、真正值得警惕的，是FDE变成高级救火队

其实甲方自己做FDE，有一个特别大的诱惑业务哪里有问题，就往哪里冲。领导提出一个需求，马上跟。某个部门系统不好用，过去帮忙改。某个流程跑不动，赶紧协调。

短期看，这种团队特别受欢迎。大家都会觉得：这帮人真能解决问题。但时间长了，问题就出来了。团队每天都很忙，项目很多，需求很多，现场也跑了很多。可是一年以后回头看，公司真正沉淀下来的东西很少。

这其实是FDE团队最危险的状态看起来离业务很近，实际上一直在替业务救火。

所以FDE不能只解决眼前的问题。每做完一个项目，都应该多追问一步：这个问题为什么会发生？能不能变成一个标准能力？能不能让下一次不再依赖某个FDE亲自到现场？能不能把个人经验变成系统能力？

FDE真正厉害的地方，不是永远在现场。而是有一天，很多现场已经不需要他去了。

五、甲方FDE最好的KPI，可能不是项目数量

如果让我给内部FDE团队开季度复盘会，我可能不会先问：这个季度做了多少项目。而会问三个问题。

第一，哪些业务指标因为你们发生了变化？

第二，哪些原来由人完成的工作，现在已经不需要人做了？

第三，哪些能力已经沉淀下来，下一个业务不用重新开发？

这三个问题基本就能判断一支FDE团队到底在创造价值，还是只是在制造忙碌。

甚至我觉得好的FDE团队应该出现一个很反常识的现象：项目数量不一定越来越多，需求数量也不一定越来越多。但业务价值越来越大，重复工作越来越少，能力复用越来越高。这才是正确的增长曲线。

六、FDE的终点，不是离业务越来越近

很多人说FDE最大的特点，是深入业务现场。这当然没错。但我觉得这只是起点。

FDE进入现场，是为了看清真正的问题。看清问题以后，要把问题变成产品。再把产品变成能力。最后让这项能力可以在组织里反复复制。

图片

从现场中来，到能力中去

所以甲方FDE真正完整的一条路径应该是：进入现场，找到真问题；做出结果，接管一部分工作；沉淀能力，再复制到更多业务。

如果只做到第一步，它是咨询。做到第二步，它是交付。做到第三步，它才真正变成企业自己的能力。

这可能也是甲方自己培养FDE最重要的原因。不是为了建立一支更能写代码的团队，也不是为了多做几个AI项目。而是企业内部需要有一群人，既能理解业务，又能使用技术，还能对结果负责。

他们不断进入现场，又不断从现场离开。因为他们每解决一个问题，都应该让这个问题下一次不再需要靠人解决。

这可能才是衡量一支甲方FDE团队最好的标准。