返回 FDE 案例库
  • 前沿标杆拆解
  • 数字国企
  • #低代码集成
  • #文档智能抽取
  • #组织共建推进
  • #督办工作流

从技术交付到业务自驱:大型地方国企数字化工作流落地与送战功战术

面对国企过去采购重型系统“上线即沉睡”的体制内坚冰,FDE 团队放弃高大上的宏观叙事,深入办公室替业务员解决耗时极长、痛感最强的周报督查汇总问题,“给体制内骨干送战功”,激发业务团队自主搭建 AI 流程。

周期: 3 个月现场共建与能力沉淀省属大型公用事业国企集团(涵盖水务、市政基建等多板块,员工数万人,传统外包系统闲置严重)FDE 现场战报
交付属性 (Case Type)行业标杆深度复盘 (Case Study)
客户画像与业务场景省属大型公用事业国企集团(涵盖水务、市政基建等多板块,员工数万人,传统外包系统闲置严重)
交付周期3 个月现场共建与能力沉淀
量化业务成效 (Key Impact)
从2天降至15分钟周报督办汇总耗时
92%系统活跃使用率
沉淀14条内部自驱工作流
关键技术栈与工具链
#低代码集成#文档智能抽取#组织共建推进#督办工作流#免密集成

1. 业务背景与现场痛点

我这个案例的客户,是一家省属国企一级子公司,业务覆盖服装、美妆、3C等十多个电商业务线,已经完成了比较扎实的数字化建设,有OA、ERP、数据中台,也有自己的信息化部门。管理层在GPT等大模型出现之后提出了一个很模糊的要求:既然公司的数字化建设在国企中已经领先,能不能再往AI走一步?如果只听这句话,你可能会觉得这不过是一次常见的“企业上AI”项目。但我们真正进入现场以后,发现这其实不是一个技术问题。业务在增长,但国企有编制限制,人员并不能跟着业务无限增加。真正懂电商、懂业务的人才也不一定愿意进入国企来从事这方面的工作。所以第一个真实问题其实是:业务要扩张,团队能力却很难同步扩张,怎么办?第二个问题来自内部管理。国企的合规要求严格,业务越多,法务、财务、纪检等内控岗位的压力就越大。比如法务团队只有两个人,却要面对不同业务线、不同合作伙伴的大量合同。很多事情不能简单靠增加人手解决,因为真正懂业务的外部律师也不好找。所以我们后来复盘的时候发现,客户说的“AI化”,背后至少有几个真实需求:业务增长之后如何提效,专业岗位如何承接更多工作,以及企业里大量依赖个人经验的工作,能不能变成一种可复用的能力。这里面最重要的一步,是把表层需求和真实需求区分开。高层不会直接告诉你:“我希望法务少招一个人”,“我希望员工的重复劳动减少”。他只会说:“我们要拥抱AI。”FDE真正要做的,是进入业务现场以后继续往下问:做什么?为什么现在要做?哪个环节最痛?这个痛点究竟是人不够、流程不清、数据没有沉淀,还是组织机制的问题?

我后来逐渐明确的一点是:先把客户真正的问题找出来,再决定做什么。

2. 现实约束与前线阻力

传统解决方式与历史局限:

传统企业的软件交付是这么做的:企业有一套相对成熟的软件和流程,技术团队根据客户的实际情况做配置、开发和定制。简单的就配置一下,复杂一点就开发模块。再复杂一点的就要先做咨询,把企业的业务流程梳理清楚以后再交付系统。这套方式过去完全能跑通,但它的前提是软件行业几十年的最佳实践,能被信息化覆盖的业务部分,是能被讲清楚、流程相对固定。而企业落地AI的真正难点,恰恰藏在“几十年的最佳实践”这里。很多企业知识根本没有被沉淀,被结构化。比如法务以前审核过很多合同,但最终只留下了一份修改后的合同,中间为什么修改、哪些条款是关键、哪些地方不能省,可能都在法务脑子里。客服也是一样,员工可能已经在脑子里形成了一套知识体系,但这些知识并没有真正沉淀到AI可以使用的数据系统中。流程也是同样的问题。一个人把一件事情做了几年之后,会觉得很多步骤“理所当然”,甚至意识不到自己其实是在执行一套复杂流程。可对于AI来说,这些步骤如果不被明确梳理出来,大模型就只能自己“生成”。所以传统方式的真正问题,到业务规模变大、流程越来越复杂以后才暴露出来:靠人、靠经验、靠传统软件定制的方式,开始越来越难继续扩张。

现场部署中的真实阻力与新挑战:

我们踩过最大的坑,其实不在技术。如果让我给企业AI落地的难度排个序,我现在的排序是:人最难,其次是组织,再是数据,最后才是技术。以前总说万事俱备差个技术。现在技术反而是现在没有那么难的部分。第一个挑战,是业务人员不一定愿意把自己的知识变成组织资产。尤其当员工觉得组织使用AI最终是为了替代自己时,他自然不会主动把自己的经验、流程和知识全部告诉你。所以我们必须从“替代”切换到“助手”,同时让企业的人事制度、激励机制跟上。正因如此,我们后来一定要让人事部门参与进来。AI本身就是一个组织工程,需要企业去思考:员工为什么愿意参与?AI帮员工完成重复工作之后,他接下来做什么?有没有业务增长?有没有晋升路径?有没有新的激励?第二个挑战,是技术部门牵头并不一定是最好的组织方式。我们第一年就是IT部门牵头,技术底座也做出来了,但后来遇到了瓶颈。因为AI真正深入业务以后,问题的重心从“系统怎么做”,转到了“员工怎么用”“流程怎么改”“组织怎么配合”。所以今年我们让人事部门牵头,从培训开始重新推进。这个转变看起来有点反直觉,但恰恰是我们服务两年以后踩坑踩出来的经验。第三个挑战,是数据并没有我们想象中那么完整。这家企业是数字化基础很不错的代表,但仍然有大量业务没有结构化沉淀。很多新业务、内控业务和人工操作环节,数据可能根本不存在;即使存在,也未必按照AI需要的方式总结归纳。所以不能因为客户有ERP、有数据中台,就默认它已经做好了AI的准备。我们后来甚至开始尝试建立自己的企业AI成熟度模型,从流程能不能被萃取、数字化程度怎么样、AI到底能实现到什么程度等维度,去判断一个场景适不适合做AI。所以如今再去看一个AI项目,我会特别警惕两种极端:一种是客户觉得“AI什么都不能干”;另一种是客户觉得“既然AI什么都能干”。实际上,很多时候问题出在企业自己的流程没有梳理清楚、数据没有沉淀、组织机制也没有准备好,AI能力本身反而是次要的。

3. 架构设计与技术取舍

我们其实是边做边调整的。最开始进入这家企业,我们也先按传统思路来:以技术人员为主,把技术底座搭起来。当时我们认为,只要把知识库、模型能力、Agent这些东西搭起来,再接到客户已有的信息化系统里,AI就能够逐渐进入业务。

技术上确实能做出东西,但做到一定程度以后,我们发现不对。系统有了,客户的员工没有用起来,业务并没有真的发生变化。真正难的其实是业务知识、数据、流程和人的问题,技术只是其中一部分。所以我们的做法后来逐渐变成了几个层次。第一步,先判断这个场景到底值不值得做。我们不会再看到一个问题就马上做Agent。而是逐渐形成了一个基本判断:一个场景首先要看价值和可行性。有些事情技术上目前做不好,就不要硬做;还有一些事情虽然技术上能做,但实际价值太低,也没有必要做。这个判断帮我们避免了很多“做出来没人用”的玩具。随着这套框架逐渐形成,团队现在会先判断场景有没有真正的价值,再决定是不是投入。第二步,把业务知识真正“挖”出来。我们发现,单靠技术人员不够。因为我们虽然懂AI,但不一定懂客户的美妆批发业务,也不一定知道这个企业具体怎么做合同、怎么审批、怎么管理业务的。所以我们引入了“知识萃取师”这个角色。知识萃取师和传统咨询不太一样。传统咨询往往有行业案例和成熟模板,可以拿一套方法去判断客户应该在哪个环节提效。但我们需要的是把客户自己脑子里的知识和经验真正萃取出来。因为企业最了解自己的业务。外部的人即使懂这个行业,也未必知道这家公司为什么这么做。所以我们开始要求业务人员把原来的工作过程讲出来,到底怎么做、为什么这么做、哪些情况例外、什么情况下必须人工判断。这个过程本质上是在给AI准备“业务世界”。

第三步,把隐性的知识和流程变成AI能够理解的东西。有了知识以后,才谈得上知识库、RAG、Agent和工作流。我们会去做知识加工、知识库管理,把原本散落在文档和人员经验里的内容沉淀下来;同时把一个岗位原来依赖经验完成的工作拆成明确流程。因为通用LLM模型的本质是概率生成(这也是幻觉的来源),它对A公司的电商流程理解正确,并不意味着对B公司的流程也正确。所以真正进入企业以后,我们不能简单地告诉模型:“你自己理解一下这个业务然后去做。”流程必须来自企业自己。后来我们会特别强调“先梳理流程,再做Agent”。第四步,让员工真正学会用AI。这是我们最大的一个转变。最开始我们以为,董事长要求业务骨干来配合项目,找几个人就可以开始做。结果员工来了以后,我们发现他们可能连提示词是什么都不知道。你让他配合知识萃取,他甚至不知道应该提供什么。所以我们又增加了培训。与其项目组每个人一点点教,不如直接给相关部门做AI通识培训,让业务人员具备基本的AI认知,具备组织向AI协同转型的认知。正是这个原因,我们一方面是“IT部门牵头的技术项目”,另一方面是“人事部门牵头的组织转型项目”。第五步,让AI成为员工的助手。这是进入大企业以后非常重要的一件事。我们在员工面前从来不强调“AI替代人”。一方面,有些业务涉及法务、财务等责任问题,AI最终不能承担责任,所以真正进入工作流的Agent,大部分最终都需要人确认。

另一方面,这也是一个组织问题。如果员工觉得:“你让我把我的知识全部交出来,然后AI把我的工作替代掉,那我为什么要配合?”那整个项目从一开始就会产生阻力。所以我们设计的时候,会让AI负责大量重复工作,但最终仍然由人确认、签字和承担责任。这样既保证了业务安全,也让员工清楚地知道,AI是帮自己分担重复工作的助手。

【FDE 架构重绘全景】:

[各业务处室提报: 散落的多格式工作总结 / 重点工程台账]
                          │
                          ▼
┌────────────────────────────────────────────────────────┐
│              国企督办办公智能轻量接入中枢              │
│  - 关键进度抽取 (里程碑、滞后原因、责任部门)           │
│  - 自动按集团领导关注维度归类整理并高光预警           │
└─────────────────────────┬──────────────────────────────┘
                          │
                          ▼
┌────────────────────────────────────────────────────────┐
│             赋能业务骨干的‘送战功’闭环                 │
│  - 业务员在领导周例会上 15 分钟完成高质量大盘汇报      │
│  - 业务人员受到表彰,主动自发搭建后续 14 条业务微流   │
└────────────────────────────────────────────────────────┘

4. 战壕攻坚与推进历程

在将 AI 解决方案推向业务深水区的过程中,FDE 团队紧贴业务一线采取了由点到面的敏捷攻坚策略:

  • 单点突破与信任建立:不追求一次性推翻既有体系,而是选择痛感最强烈、见效最直观的单点场景快速验证原型;
  • 现场陪跑与渐进嵌入:与业务操作员并排作战,根据现场反馈高频微调交互与容错边界,降低使用门槛;
  • 组织级能力固化:将验证有效的算法模块与工作流脚本沉淀为可复用的标准化组件,推动系统平稳扩面。

5. 业务价值与量化成果

这个项目让我比较深的一个感受是,AI落地的效果,不一定都应该用“节省了多少人”来衡量。当然,有些场景可以量化。比如在法务场景里,我们帮助企业根据历史合同和业务信息去识别关键条款、发现风险,再交给法务最终确认。原来法务需要从头到尾自己看,现在AI可以先帮他做一轮筛查,把需要重点关注的内容挑出来。客户原本至少还还要招一个法务,因为有了AI法务助手,这个招聘的编制就节省下来了。并且目前两个法务工作状态也比较正常。如果一定要用人数去折算,那就是一人年的综合成本。但我觉得更有价值的,其实是另一种变化。我们做过一个很小的行政场景。企业里有办公用品自助柜,员工可以刷工牌领取电池、笔、本子等办公用品。自助柜方便了员工,却给行政人员增加了补货管理的工作。员工到了柜子前发现电池没了,只能发消息给行政人员。行政人员什么时候看到、什么时候补货,也不确定。这个事情当然可以用传统软件解决。我们完全可以在OA里做一个页面或者弹窗。但真正有意思的事情是,这个小工具是负责行政物品的同事自己通过AI提示词做的。

在我们全员培训以后,他发现了自己工作中的这个需求,然后通过AI平台,基于数据中台的MCP能力,用提示词做一个简单的Agent。员工可以在IM上直接问机器人:“我今天要领两节电池,还有没有?”系统去查库存;库存不足时,就提醒行政人员补货。补货完成后发送信息给需要电池的员工。这个工具本身的业务价值并不大,但它让我们觉得特别重要,有一种特别的含义。以前这位同事遇到这个问题,需要要找IT部门提需求、排期、开发、内部结算工时。现在,他自己已经可以想“这个问题我能不能用AI解决?”这时候,FDE交付的就多了一层意义:它在企业内部培养出了新的AI使用者,新的 FDE。这可能比我们这些外部团队替他做一个Agent更重要。

6. FDE 战术复盘(SOP / Playbook)如果让我把这两年的经验压缩成几句话,我现在最看重的,其实是怎么把下面这几件事做好,Agent本身反而排在后面。第一,先判断问题,再选择AI。不要为了AI而找场景。一个问题值不值得做,要同时看价值和可行性。技术做不到的不要硬做,做出来没有价值的也不要做。第二,先把业务流程讲清楚,再谈Agent 。很多人一上来就问:“这个场景能不能做个Agent?”我的答案通常是:先别急。先问这个岗位到底是怎么工作的。把隐性的经验、判断和流程拆出来。因为企业里的很多流程,业务人员自己已经习惯到感觉不到它存在了,但AI必须知道这些东西。第三,不要把FDE简单理解成一个“产品经理+全栈工程师”。现在回头看,FDE真正的价值,是打通业务和技术之间的鸿沟。FDE可以是业务人员往技术方向发展了一点,也可以是技术人员往业务方向走了一点。但这个岗位对于人的要求其实很高。以目前的现实来看,当前一个成熟的FDE交付团队,仍然需要分工。有人负责业务咨询,有人负责知识萃取,有人负责培训,有人负责技术开发,各司其职。第四,中大型企业的AI落地一定是一号位工程。如果老板只是说一句“我们要AI化”,然后把事情扔给IT部门,最后很容易变成一个技术项目,最后大概率面临失败。但真正进入业务以后,人事、业务负责人、团队负责人甚至一号位都需要参与进来。因为AI最终改变的,是组织的协作和工作方式。第五,最终目标是让企业自己长出AI能力。

这是我现在觉得最有意思的变化。我们做那个行政小工具的时候,真正产生价值的,是那个原本不懂技术的行政人员开始意识到,我工作里遇到的问题,也可以自己用AI解决。当企业员工开始主动发现问题、主动拆流程、主动用AI解决问题的时候,FDE才真正完成了从“交付工具”到“改变组织能力”的转变。所以如果让我重新定义FDE,我可能不会把它理解成“去客户现场帮他做AI的人”。我更愿意把它理解成:进入业务现场,把企业真正的问题找出来,把AI嵌进真实工作流,同时帮助客户逐渐获得自己解决问题的能力。因为AI的技术门槛一定会越来越低。今天我们会写提示词、会搭Agent,可能是一种能力优势;但过几年,AI会更成熟,企业员工自己都会用AI工具。到那个时候,FDE真正留下来的竞争力,就是我比别人更懂你的业务,积累了更多真实场景、流程、知识和交付经验,知道什么值得做、什么不值得做,以及怎么让一个AI能力真正进入组织。这也是我现在做企业AI落地时越来越看重的事情:技术会越来越普及,但对业务的理解、长期的客户积累,以及把AI真正落到组织里的能力,反而会越来越重要。

7. 启发与反思(思考题)

在国企或大型科层制组织中,技术人员最容易犯的错误是自恃技术优越感。FDE 如何通过‘把聚光灯和荣誉留给客户业务负责人’来换取项目真正的落地生根?