得帆CTO徐翔轩：从支持部门到能力部门，IT团队的角色正在变化

本文作者：得帆信息联合创始人兼CTO徐翔轩

过去两三年，在接触到不少制造、零售、金融、服务业等领域的CIO和IT负责人后。我有一个非常直观的体会：同样是IT团队，有的越来越疲于救火，有的却越做越强，正在成为企业的“能力中心”。

为什么会出现这种差异？我认为背后的关键分水岭是——IT部门到底是在“交付项目”，还是在“建设能力”？

本文尝试分享我在项目实践、平台落地以及与CIO深度交流中形成的相关判断，希望能给正在推进数字化的团队带来一些参考。

过去的IT：典型的“支持部门”

在很多企业中，IT的定位长期是“支持角色”：业务提需求，IT负责排期开发，随后项目上线，继续下一个需求。

这种模式的问题非常典型：

• 项目永远排不完
• 中长尾需求长期积压
• IT永远被动响应
• IT能力难沉淀、团队长期承受高压

与此同时，业务也会衍生大量“影子 IT”：外部工具、表格应用、独立小系统在各部门冒出来，不仅增加维护成本，也破坏了企业整体的数字化架构。

这就是很多CIO面临的现实困境：IT做得越多，越忙，却越缺乏能力积累。

领先企业走出了另一条路：从项目走向平台，从交付走向能力

过去几年，一批领先企业做出了关键的转变：不再把IT当“交付部门”，而是开始建设“数字化能力部门”。

其中的关键推动力，就是把低代码、RPA、BI等工具以平台化方式引入组织，形成可持续的能力建设路径。

这种转变往往分为三个阶段，每一步都非常关键。

总结：IT角色的变化，是小趋势中的大浪潮

1

阶段一：IT团队先试点验证，找到“可复制的方法”

第一阶段重点不是规模，而是验证。

IT团队通常会选择一些痛点清晰、价值可见的小场景，例如：

• 一个审批流程、巡检流程
• 一个设备管理小系统
• 一个自动生成报表的动作

目的不是“搭一个系统”，而是：

• 看看这种方式能否更快落地
• 能否让业务方快速看到价值
• 能否让团队找到更好的构建方式
• 能否沉淀第一批“可复用能力”

在这个过程中，工具之间（低代码、BI、RPA）的能力融合也会初步完成。

很多企业到了这一阶段，就已经明确：IT不只是改需求，而是开始构建能力。

2

阶段二：让更多人参与构建，中长尾需求回到IT主导的体系内

这一阶段往往是能力扩展的关键。成熟的IT团队会做几件事：

• 建立构建规范
• 搭建能力库、表单库、流程组件库
• 定义权限体系和数据模型
• 建立跨部门协同与发布机制

然后让业务团队在“可控范围内”参与构建。这不是把开发甩给业务，而是在IT的框架下共同参与。这样一来：

• 小需求业务能做；
• 中等需求部门协作能做；
• 复杂需求IT专注做；
• 系统之间保持一致性，不会碎片化。

需要注意的是：这一阶段对平台本身的开放性、二次开发能力、扩展能力要求较高。

如果这部分能力不足，往往会卡在第二阶段——业务用得不深，IT又无法治理，项目容易烂尾。

3

阶段三：IT成为企业“数字化供给侧”的核心能力部门

当工具、方法论、能力库逐步稳定后，就进入第三阶段。

这时，IT团队开始具备平台化的能力沉淀：

• 数据结构更统一
• 组件服务不断复用
• 原子能力库逐步丰富
• 各类系统间的集成变得顺滑

此时的IT部门，不再是“被动响应需求”，而是：

• 有一套稳定的数字化供给体系
• 能提供业务构建所需的标准能力
• 能让企业随时构建、随时升级
• 能让创新变得可预测、可控

也就是说，IT成为了企业的能力部门和平台治理部门。业务的新系统，不再需要从零开始；新的流程，不再需要一张白纸；创新的成本，也因平台能力沉淀而大幅下降。

回顾这三步，我们会发现，其实逻辑非常朴素：

• 先把工具用起来，验证平台价值，形成方法论；
• 再让更多人参与构建，覆盖中长尾需求，形成组织协作；
• 最终沉淀能力，让企业拥有可持续的数字化供给能力。

我们看到，IT团队真正变强，并不是因为预算或人手的增加，而是因为在关键时刻选择了“建设能力”这条更长期、更可持续的道路。

如果你也在思考如何让IT团队走向能力化，欢迎留言交流，也欢迎与我们进一步探讨相关实践经验。