CXO主笔团 | 姜正林：FDE来了，企业IT部门该怎么变？

2026-11-03 14:10:14 来源：抢沙发

2026-11-03 14:10:14 来源：

摘要：泰康口腔集团 CIO 姜正林提出，FDE并非在原有IT部门外新增技术团队，而是推动IT组织从项目交付型转向业务价值型。对比传统IT以项目为中心与FDE以经营结果为中心的差异，给出业务前沿战队、共享技术平台、技术治理三层组织模型，划分各方责任与考核指标，并介绍嵌入式FDE、业务战队 + 共享平台、AI 原生组织三类落地路径，建议企业通过 90 天小范围试点验证，依托原有技术能力围绕业务重组，实现从项目交付到持续改善经营结果的转变。
关键词： FDE IT组织升级业务价值

姜正林
泰康口腔集团有限公司CIO
从多年来的从业经历中积累了丰富的实战和管理经验，先后在陕西同辉网络通信有限公司、北京天桥北大青鸟科技股份有限公司、东方惠科、海虹医药电子商务公司(海虹控股)工作。
历任事业部总经理、技术总监、信息安全高级顾问、公司技术副总裁等职务，并在企业的电子商务、网络信息安全、计算机网络和架构、信息系统整体规划等诸多IT领域成绩显著。
于2007初加盟天狮集团，担任全球信息中心总监、总经理职务，负责天狮集团全球的信息化建设，在企业信息系统建设和规划以及整合方面成绩显著。
现任泰康口腔集团有限公司CIO。

主笔强调

FDE不是在企业原有IT部门之外，再增加一支懂业务的技术团队；而是借助FDE理念，推动整个IT组织从“项目交付型”转向“业务价值型”。

我们一直在讨论AI落地的各种业务和技术问题，回过头看看IT组织架构内部的协同才是核心，先说我的结论是：FDE不是在企业原有IT部门之外，再增加一支懂业务的技术团队；而是借助FDE理念，推动整个IT组织从“项目交付型”转向“业务价值型”。很多企业开始引入AI、FDE或者业务技术团队时，都会遇到一个现实问题：原有IT部门已经有应用开发、系统运维、基础设施、数据、项目管理等完整职能，为什么还需要FDE？如果新增一支FDE团队，它与原有IT团队如何分工？谁负责需求、谁负责开发、谁负责系统稳定，最终又由谁对业务结果负责？如果这些问题没有解决，FDE很容易成为原有IT体系之外的另一支开发团队，形成双重架构、重复建设，甚至相互争夺资源。真正需要改变的，不只是岗位设置，而是IT组织的工作逻辑。

一、两种组织模式的根本区别

传统IT部门并不是没有业务能力，而是其组织结构通常围绕专业职能和项目交付建立；FDE则强调深入业务现场，快速识别问题，并将技术能力转化为业务结果。

传统IT组织：以系统和项目为中心

业务部门提出需求：
需求分析 → 项目立项 → 开发实施
系统上线 → 运维交接 → 项目验收
主要衡量：项目进度、交付质量、系统稳定性、预算。

FDE协同模式：以业务问题和经营结果为中心

面临的业务问题与经营目标
FDE深入现场，联合业务定义问题
调用平台、数据、系统、AI及工程能力
小步试点 → 验证结果 → 持续迭代与推广
主要衡量：业务指标改善、问题解决速度、能力复用和持续经营价值。

两种模式并不是非此即彼，企业仍然需要专业化IT团队保障系统、数据、安全和架构，只是需要在专业能力之外，增加一套深入业务、快速解决问题的组织机制。FDE改变的是技术服务业务的方式，而不是让企业放弃原有的技术治理体系。

二、企业IT组织应该如何升级？

我不建议企业简单地在现有IT部门旁边成立一个独立的FDE部门。更合理的做法，是将原有IT的专业能力与FDE的业务前沿能力组合起来，形成一个新的组织体系。

可以把它理解为三个层次：业务前沿战队、共享技术平台、企业技术治理。这是我建议的目标组织模型，不是要求每家企业都设立三个独立部门。治理可以是横向职能，平台也可以由现有团队承担。这套架构的关键，是让不同团队承担不同责任，而不是各自形成一套完整的技术体系。

1. 业务前沿战队：从接需求转向解决问题

FDE不应该只是一个会写代码、懂大模型和AI的工程师，企业需要围绕重要业务领域组建小型、跨职能战队。例如，在连锁零售或者是一个连锁医美企业，可以设置：

客户增长战队：负责线索转化、客户运营、复购和转介绍。
门店经营战队：负责经营分析、排班、资源利用和运营效率。
供应链战队：负责采购、库存、供应商协同与成本优化。
财务经营战队：负责经营核算、异常识别、预算分析和业财协同。

每支战队不一定要配齐所有岗位，其中FDE、业务负责人和业务专家构成核心，根据具体问题从数据、AI、开发和安全团队获得支持。

例如，老板提出“提高门店业绩”，传统模式可能会启动一个BI报表或客户管理系统需求；FDE战队则会基于业务运营流程进一步分析，问题究竟出在客户线索质量、预约到诊率、医生接诊能力，还是治疗方案转化率。
随后，FDE战队选择最值得解决的环节，利用现有系统应用、数据和AI能力快速验证，最后用业务指标判断效果。FDE负责把业务问题转化为可运行的解决方案，但业务部门仍然负责业务规则、经营决策和最终执行。

2. 共享技术平台：不再重复造轮子

原有IT部门最有价值的资产，不是某个开发岗位，而是长期积累的系统能力、数据能力、架构经验和企业治理能力。这些能力不能因为FDE出现就被拆散。

平台团队主要承担：
应用与集成： ERP、CRM、SRM、HIS、OA等系统接口及公共服务。
数据与AI： 数据标准、指标口径、知识库、模型接入、Agent运行框架和评测能力。
工程与运维： 开发工具链、自动化测试、发布、监控、故障处理和容量管理。
公共技术组件： 身份认证、权限、审计、日志、工作流及可复用业务组件。

平台团队不再只是等待项目提出需求，而要主动建设能够被各个业务战队调用的标准化能力。例如，FDE战队开发门店经营Agent时，不需要重新开发用户认证、权限管理、数据库连接和模型调用框架，而是直接使用平台提供的能力。
这种“前沿战队快速创新、平台团队持续沉淀”的模式，与Team Topologies所强调的业务流团队和平台团队协作思路相契合。

3. 技术治理：从审批部门变成护栏

FDE强调快速迭代，但企业不能因此放弃技术标准。尤其是医疗、金融、连锁经营等企业，客户数据、核心交易、财务权限和生产系统都不能由各个战队自行决定如何处理。因此，CIO需要保留统一的技术治理机制：

架构标准与技术选型由统一机制管理。
数据权限、隐私保护和安全审计必须有明确责任人。
生产环境变更、系统发布和回滚遵循相应的风险控制要求。
AI应用需要评估准确性、异常处理、人工复核及运行成本。
各战队形成的通用能力应纳入平台复用，避免重复建设。

这里需要区分：治理不等于所有事情都要审批。 低风险、标准化的工作可以授权战队自主完成；涉及核心系统、敏感数据和重大经营风险的事项，才进入相应的控制流程。

三、原有IT部门的岗位和职能，具体如何调整？

最容易出现误区的地方，就是认为增加FDE之后，原有的系统开发、项目经理、架构师、数据工程师和运维人员都需要重新定义甚至裁撤。
实际上，组织升级更多是职责重组，而不是简单替换岗位。

这里面最需要转变的，往往是项目经理和业务分析岗位。过去，项目经理主要确保项目按计划完成；未来企业需要有人负责多个业务战队之间的优先级、资源冲突、系统依赖和整体价值。业务分析也不能停留在把业务需求整理成需求文档，而要能够与FDE共同分析流程、规则、数据和决策节点。
至于开发和运维人员，并不是所有人都要转成FDE。深入业务、理解场景、具备端到端解决问题能力的人，可以逐步进入前沿FDE战队；擅长架构、数据、安全、复杂工程和稳定性保障的人，则可以在平台与专业技术团队发挥更大价值。

四、企业应该怎么设计IT组织架构

企业不一定一步到位。根据规模、数字化基础和业务变化速度，可以分阶段，选择不同的升级路径。
模式一：嵌入式FDE：适合刚开始转型的企业在原有IT架构中选出少量工程师，与业务部门组成联合小组。开发、数据、运维仍由原有团队支持。优点：投入较小、组织冲击低、容易试点。风险： FDE可能被日常需求和原有审批流程牵制，难以形成真正的端到端责任。

模式二：业务战队 + 共享平台：建议作为目标模式，适合已有一定数字化基础的中大型企业FDE长期围绕业务领域工作，原有专业团队转向平台、工程和治理职能，形成稳定协作机制。优点：业务响应速度、专业化能力和技术复用相对平衡。风险：如果资源分配、优先级和团队责任不清晰，容易出现业务战队与平台团队互相等待。

模式三：业务产品化与AI原生组织：适合组织成熟、AI应用规模化的企业业务战队持续经营自己的数字化产品和AI能力，平台提供标准化底座，AI Agent承担部分常规执行、分析、测试和运维工作。优点：从单次项目交付转向持续演进，复用和自动化潜力更大。风险：对数据基础、平台成熟度、业务治理和技术人才要求较高，不适合直接照搬。

这三种模式不是简单的成熟度等级，企业也可以按业务复杂度多种使用。FDE的核心价值在于解决传统交付模式难以快速解决的问题，而不是要求所有IT工作都改为FDE模式。

五、重新定义团队之间的责任

组织架构调整之后，如果考核方式没有改变，最后仍然会回到传统模式。所以建议至少明确四条责任边界。

第一，业务部门对业务结果负责。业务部门必须一起与FDE战队参与问题定义、流程调整、规则制定和应用推广，不能把经营目标交给IT后就等待结果。

第二，FDE对解决方案的落地负责。FDE要从业务问题出发，负责技术方案、原型验证、系统集成、效果评估和生产落地，并与业务共同对结果负责，而不是只提交代码或原型。

第三，平台团队对公共技术能力负责。平台团队负责系统稳定性、公共组件、标准接口、数据服务和工程能力，不应该成为所有创新需求的统一排队入口。

第四，CIO对整体技术体系和价值组合负责。CIO需要决定哪些问题值得投入、哪些能力应该复用、哪些工作需要标准化，以及如何平衡创新速度、技术风险和经营回报。
对应的考核也应该调整：

团队	建议关注的指标
业务战队	业务指标改善、用户采用率、问题解决周期
平台团队	服务可靠性、复用率、交付效率、单位运行成本
技术治理	安全风险、合规情况、架构一致性、重大事件
CIO及管理层	业务价值组合、科技投入产出、整体交付效率

这些指标需要根据企业实际确定，不能机械地把业务增长全部归因于FDE，也不能只用代码产量、上线数量衡量技术团队。

六、CIO可以从哪里开始？

不必先改组织架构图，也不必大规模招聘FDE。建议先做一个90天的组织试点。

第1—30天：选问题、组团队选择一个经营目标明确、业务负责人愿意投入、数据和系统条件基本具备的场景。组建由业务负责人、FDE及必要技术人员构成的小组，明确基线指标、目标和权限边界。

第31—60天：小步落地、真实验证不做脱离生产环境的演示。优先调用已有系统、数据和公共组件，针对真实业务流程交付可用的解决方案，持续验证质量、效率和用户反馈。

第61—90天：复盘机制、决定推广评估业务收益、用户采用、运行成本和技术风险。把有效的工作流、接口、知识和工具沉淀为公共能力，再决定是否扩展战队、调整岗位和推广到其他业务领域。

试点结束后，真正值得评估的，不只是某个AI应用是否成功，而是企业有没有建立起一种新的工作机制：业务问题能否更快进入技术解决流程，跨团队协作是否减少了等待，成功方案能否复用，以及业务部门是否真正承担了流程变革责任。

所以说，FDE带给企业的最大变化，不是多了一种工程师岗位，而是让IT组织有机会重新设计自身的生产方式。过去，IT部门以专业分工组织人员，以项目组织工作，以系统交付衡量成果。

未来，更合理的形态是：前沿战队面向业务结果，平台团队提供可复用能力，专业团队守住工程与治理底线，CIO统筹整体价值。

这也意味着，CIO的工作重心需要从管理项目组合，逐步转向管理业务价值组合；从协调不同技术部门，转向设计一套能够持续解决业务问题的组织机制。

但必须强调，FDE不是万能解药，没有清晰的业务责任、扎实的数字化建设基础，可信的数据、可调用的系统能力和必要的授权，FDE只会成为另一种形式的需求开发人员。真正的组织升级，不是把原来的IT部门拆掉，而是让原有技术能力围绕业务重新组合，让技术交付从“完成一个项目”走向“持续改善一项经营结果”。

第四十二届CIO班招生
国际CIO认证培训
首席数据官（CDO）认证培训

责编：zhanghy

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。