从纸质流程到数据驱动：FDE用AI推动传统消防维保企业数字化转型

访谈资料整理：依据 Datawhale《FDE案例100》所收录访谈。案例叙述与成果均归属于原访谈，本站未进行独立项目审计。

原案例封面

为什么这个案例值得看？

消防维保企业长期依赖纸质流程和人工经验，数据散落在表格与个人手中，管理者难以掌握真实业务状态，一线员工也耗费大量时间填表报送。项目先重梳现场流程、推动数据沉淀，再用 AI 处理高频重复环节，形成从数字化基础到 AI 应用的渐进路径。

这个案例的价值不只在于采用了某种模型，而在于把数据、规则、系统和人工责任连接成可执行的业务链路。落地过程围绕问题识别、方案选择、交付路径、业务结果和关键难点展开。

一、企业与业务场景

FDE进入这家企业时，他们主营消防维保业务，主要承接物业等客户的消防检查、维护和维修工作。

企业规模不算特别大，但业务稳定，属于典型的传统行业，有大量线下执行环节。

这个行业不缺业务，问题在于业务增长过程中，原有的管理模式越来越难支撑企业发展。

FDE进入现场后，从两个完全不同的视角看到了问题的全貌。

从老板的角度看，最大的痛点是“看不见”。

他知道企业每天在做业务，但无法实时掌握一线情况：哪些项目的维保执行到位了？

哪些客户存在消防风险还没有处置？

甚至一些影响回款的重要维保记录，也可能因为人员变动、资料遗失而无法及时找到。

他只能通过周期性的汇报了解业务状态，而汇报和现场之间，永远隔着一层信息差。

从一线维保人员的角度看，问题又完全不同。

他们的核心工作是检查消防设备、完成维修，但大量时间消耗在业务之外：填写纸质表格、整理Excel数据、打印传递归档、反复和各方沟通确认。

有些时候，一个表格的填写和整理就能占用半天时间。

这些工作对他们来说是纯消耗，不产生任何直接业务价值。

更深层的问题是数据割裂。

检查记录在纸质表格里，维修记录在Excel里，客户信息在某个人的微信聊天记录里，设备档案可能散落在不同文件夹中。

这些数据按照监管要求做了保存，但没有形成统一体系，查找困难，也无法支持管理决策。

从FDE视角看，这个问题的本质超越了技术层面。

消防维保业务中，真正棘手的是业务现场、管理需求和执行流程之间的断层。

企业真正缺失的，是一套能够同时连接管理者、一线员工和业务流程的解决方式。

二、原有流程与核心问题

在FDE进入企业之前，他们基本没有完整的软件基础设施。

去年企业曾尝试和外部团队合作，引入过一个监控平台，希望迈出数字化第一步。

但除此之外，企业内部没有形成完整的数据体系和流程系统，日常运转主要依赖经验驱动。

在业务规模较小的时候，这种方式勉强可以维持。

老板靠多年行业经验判断业务状况，员工靠熟悉流程完成工作。

但当行业利润空间持续下降、企业希望拓展新业务机会时，经验驱动的模式开始暴露出明显短板。

老板意识到需要借助数字化和AI提升效率，但并不清楚从哪里入手。

不过，对于传统企业来说，直接购买一个大型系统的成本往往难以负担。

很多外部方案功能列表看起来很完善，但没有真正理解企业现场的监管流程和实际执行方式。

最坏的情况是，系统上线后变成员工额外增加的一套操作流程，不仅没有减负，反而加重负担。

这家企业也面临同样的困境。

他们看到AI和数字化的价值，但缺乏一个既懂业务现场、又能翻译技术方案的角色来帮助判断：到底从哪里开始？

什么值得做？

什么不需要做？

三、AI 解决方案与交付路径

FDE做FDE的第一步，是进入现场理解业务。

很多时候，老板自己也不清楚真正的问题在哪里。

老板看到的是经营结果，员工面对的是每天具体的流程。

如果只通过管理层访谈拿需求，很容易拿到“看起来正确”但实际上偏离核心问题的需求。

所以FDE直接和维保人员、人事、行政、财务等角色逐一沟通，观察他们真实工作的过程。

维保人员怎么填写检查表？

资料怎么流转？

哪些环节需要反复确认？

哪些步骤让他们最头疼？

正是在这个过程中，FDE发现此前设计的方案存在方向性问题。

一开始项目团队计划建设一个完整的业务平台，但走到现场后发现，企业已经部署了政府监管要求的软件流程，这套流程无法开放接口。

如果再增加一个完整系统，意味着员工需要在两套系统之间重复操作。

这意味着原来的方案必须调整。

调整后的思路很明确：在已有流程基础上做最轻量的改造，重新建设一套完整流程既不现实，也会增加员工负担。

整个推进分为两个阶段。

第一阶段，先帮助企业完成流程数字化，把原本在纸质表单和Excel中流转的数据迁移到线上，让信息能够被记录、沉淀和管理。

这一步的目的是先让企业拥有自己的数据基础，为后续AI介入创造条件。

第二阶段，在数字化流程中寻找AI真正适合介入的环节。

判断标准很明确：找到业务流程中真实存在成本的环节，再判断这个环节是否适合AI介入。

先问“哪里存在真实的业务成本”，再考虑“这里是否需要用AI”。

举个例子，维保人员填写月检表时，经常需要重复输入类似的问题描述。

某些设备长期存在相同异常，每个月都需要复制粘贴几乎一样的内容。

这类场景中，AI可以辅助生成和调用历史记录，减少重复劳动。

在技术方案设计上，项目团队采用的是分工协作模式：系统负责流程记录和数据沉淀，AI负责处理复杂信息、辅助生成和降低重复工作，人负责最终判断和业务决策。

大模型擅长从非结构化信息中提取和生成内容，但业务流程的完整性和数据准确性必须由专业系统保障，最终的消防专业判断必须由人来做。

四、项目结果与业务价值

目前项目仍处于持续推进阶段，尚未形成大规模的业务指标变化，但已经可以看到几个层面的实际价值。

首先，企业管理方式发生了变化。

过去企业运转高度依赖老板个人的行业直觉，现在通过数字化流程，企业开始逐步拥有自己的数据资产。

管理者可以更清楚地了解业务状态，知道哪些项目在执行、哪些环节存在风险，降低了信息不对称带来的管理盲区。

其次，员工工作方式发生了变化。

数字化的目标很明确：减少员工在重复填表、整理资料上的低价值消耗。

维保人员如果能把省下的时间投入真正的检查和维修工作，交付质量和客户满意度都会随之提升。

第三，企业能力在长期沉淀。

传统企业最大的短板是经验掌握在个人手里，人员变动就可能导致能力流失。

通过数据沉淀和流程标准化，企业可以逐步把依赖个人经验的能力转化为组织能力。

此外，FDE还帮助企业避免了一次无效投入。

此前企业曾考虑花费约10万元采购一套外部业务系统，但经过现场调研发现，对方方案没有充分考虑行业监管流程和实际执行方式，真正上线后无法使用。

经过重新梳理，这笔采购被及时叫停。

五、关键落地难点

第一个挑战：需求真实性。

在最初沟通阶段，一线员工提出了一些需求，但走进现场深入观察后发现，很多需求偏离了核心问题。

原因是员工在正式访谈环境中，很难完全表达真实的工作状态。

特别是外勤维保人员，平时很少回公司，如果坐在会议室里面对老板和管理人员，容易产生压力，只会被动回答被问到的问题。

项目采用的做法是调整调研方式。

不依赖会议室访谈，走进他们的日常工作场景。

看他们怎么填表、怎么交接资料、哪个步骤反复出错、哪些信息需要反复问别人。

通过现场流程反推真实痛点，从实际工作中把真正影响效率的问题找出来。

第二个挑战：基层接受问题。

员工最初对数字化心存顾虑。

他们担心这意味着更严格的管控，担心自己的工作过程被完全记录，也担心需要学习一套全新的系统。

如果只考虑老板需要的数据透明和风险管理，忽略员工的感受，系统做出来也不会有人愿意用。

所以在设计流程时，项目团队同时兼顾两方诉求。

对老板，解决数据透明和风险管理；对员工，解决工作效率和流程负担。

让一线人员感受到数字化是在帮他们减负，把时间还给真正的专业工作。

只有同时满足双方需求，系统才可能真正落地使用。

第三个挑战：避免过度建设。

在推进过程中，始终面临一个选择：做完整方案还是做最小可用功能？

完整方案看起来更专业、覆盖更广，但对传统企业来说，每增加一个功能就意味着员工需要额外学习和适应。

最终项目团队选择了更务实的路径：拥抱飞书等企业已有的基础工具能力，通过小模块、小功能逐步推进迭代。

简单方案往往更容易落地，也更容易根据反馈快速调整。

六、FDE 交付方法与企业启示

第一，从业务问题出发，把AI放在解决真实问题的位置上。

很多企业看到AI后会先问：“企业哪里可以用AI？”但正确的问题应该是：“企业的业务流程里，哪里存在真实的成本和效率问题？”AI只是解决问题的手段之一。

如果一个问题通过简单流程优化就能解决，就不一定需要AI。

只有当数字化之后发现某些环节仍然存在大量低效劳动，再考虑用AI降低成本。

第二，FDE必须具备业务理解能力，必须进入现场。

FDE区别于传统技术岗位的关键，在于不能只接受需求文档。

很多时候，真正的问题不会被准确描述出来。

老板不知道具体需求细节，员工在正式场合未必敢表达真实想法。

只有深入一线，观察真实工作流程，才能把业务语言和技术语言连接起来。

在这个项目中，正是现场观察让FDE发现原方案的方向性错误，及时调整了方向。

第三，AI项目成功取决于落地细节。

一个Demo很容易做出来，但从Demo到真正融入日常使用，中间有大量需要验证和调整的环节。

需要找真实用户测试，根据反馈快速调整，控制系统复杂度，保证成本可接受。

FDE的核心价值在于连接业务、技术和用户，让AI真正进入企业流程并产生价值。

开发工具只是起点，推动工作方式的实际改变才是目标。

未来真正有生命力的AI应用，必然深入企业真实业务流程，超越停留在演示阶段的浅层应用。

这也是FDE存在的意义：让AI从实验室走向真实世界。

七、可复用的交付资产

同类项目若要复制这条路径，可以优先沉淀以下交付物：

• 场景访谈记录与 As-Is／To-Be 流程图
• 业务对象、关键字段、角色责任和异常分支清单
• 知识地图、文档清洗规则、切片规范和高频问题测试集
• Agent 工作流定义、工具调用清单、提示词版本和任务评测集
• 系统集成图、字段映射、权限配置、失败重试与回写日志
• 覆盖普通、复杂和异常任务的验收样本与业务指标口径
• 人工审核、失败回退、上线巡检和持续迭代清单

来源与作者

Datawhale《FDE案例100》，受访者：尚启峰（重庆新泽鸥科技有限公司CTO）；PDF 第 131-137 页，书内页码 130-136。本文为访谈资料的第三人称整理，不是本站新采访。