企业数字化的深水区，其实是流程问题

heidsoft

发布于 2026-07-02 11:59:09

文章被收录于专栏：云计算与大数据云计算与大数据

A blue nebula surrounded by countless stars in deep space.

云与数字化 | AI Native ITSM 系列

企业数字化做到后面，最难的往往不是再买一个系统，而是让流程跨部门、跨系统、跨责任边界稳定流动。

数字化的深水区，本质上是流程治理问题。

很多企业过去几年投入了大量资源做数字化：上 ERP、CRM、OA、HR、财务系统、项目管理系统、研发平台、监控平台、数据中台、低代码平台。每个项目单独看，都有明确价值；每个系统上线时，也都解决了某一个局部问题。

但当系统越来越多，新的问题开始出现：员工办一件事，要在多个系统之间切换；同一份数据，要在不同部门重复录入；流程状态散落在不同系统里，没有人知道卡在哪里；出了问题，各个部门都能说明自己已经完成了本部门动作，但端到端结果没有完成。

这就是企业数字化进入深水区后的典型状态。系统建设已经不是主要矛盾，流程割裂才是主要矛盾。企业不缺工具，缺的是把工具连接起来的流程底座；不缺数据，缺的是让数据沿着流程自动流动的机制；不缺局部效率，缺的是端到端效率。

所以今天谈数字化，不能只谈“有没有系统”，更要谈“流程能不能跑通”。如果流程跑不通，系统越多，管理复杂度越高；如果流程能跑通，系统才会从一个个工具，变成企业能力网络。

数字化上半场：系统建设解决局部问题

企业数字化的上半场，核心任务是把线下业务搬到线上，把纸质表单变成电子表单，把人工台账变成系统记录，把部门管理变成软件管理。这一阶段非常必要，因为没有系统，就没有数据沉淀，也谈不上后续自动化。

ERP 解决财务和供应链管理，CRM 解决客户管理，HR 系统解决人事管理，OA 解决审批协同，ITSM 解决 IT 服务管理，监控系统解决运行状态，数据平台解决报表分析。这些系统共同构成了企业数字化的基础。

但上半场的建设方式通常是部门驱动的：财务买财务系统，人力买人力系统，IT 买运维系统，研发买研发平台，销售买 CRM。每个部门都希望解决自己的问题，也会按照自己的指标和流程来建设系统。

这种方式在早期效率很高，因为目标清晰、边界明确、上线快。但随着企业规模扩大，跨部门协作变多，系统之间的断点就会越来越明显。

上半场的典型结果

每个系统都在提升局部效率，但企业整体流程并没有自然变快。因为真正的业务结果，往往发生在多个系统和多个部门之间。

比如一个新产品上市，可能涉及研发、采购、生产、销售、财务、客服、IT 和法务。任何一个部门的系统都无法单独完成这个过程。流程跨系统流转时，谁来串起来，谁来判断状态，谁来催办，谁来记录责任，谁来沉淀经验，就成了新的管理难题。

数字化下半场：流程割裂成为主要瓶颈

流程问题最典型的表现，是“每个节点都完成了，但整体没有闭环”。这句话在企业里很常见。

以新员工入职为例。HR 完成了员工信息录入，IT 需要开通账号和权限，行政要准备工位和设备，财务要处理薪资和社保，部门负责人要安排导师和任务。如果这些动作靠人工通知、手动转交和重复录入，入职流程就会变成一串松散的待办。

问题不一定出在某个部门不负责，而是整个流程没有统一编排。HR 不知道 IT 是否开通账号，IT 不知道行政是否准备设备，部门负责人不知道员工是否已拿到所有权限。最后新员工第一天到岗，可能账号没开、电脑没到、系统权限不全，大家都很忙，但体验仍然很差。

类似问题在 IT 服务、采购审批、合同评审、故障处理、变更发布、客户交付、供应商协同里都会出现。企业越大，流程越复杂，越不能依赖“人盯人”来保证结果。

流程割裂通常有五个根源：

一是系统割裂。不同系统之间没有稳定连接，数据不能自动流转。

二是责任割裂。每个部门只对自己的节点负责，没有端到端责任视图。

三是状态割裂。流程状态散落在聊天记录、邮件、表格和多个系统里。

四是规则割裂。审批条件、权限规则、例外处理分散在不同制度和人员经验里。

五是知识割裂。处理经验没有沉淀到流程中，下一次仍然依赖熟人和老员工。

这些问题不是靠再上线一个单点系统就能解决的。因为新系统如果不能进入企业流程，也会变成新的孤岛。数字化下半场真正要做的是流程治理：把流程、系统、数据、人员、权限和审计放到同一个框架里。

流程治理不是画流程图，而是建立可运行的管理机制

很多企业也做流程管理，但常见问题是流程停留在文档、制度和流程图里。制度里写得很清楚，实际执行时还是靠人记、靠人催、靠人判断。流程图可以说明“应该怎么走”，但不能保证“实际怎么走”。

真正的流程治理，应该把流程变成可运行的系统机制。它至少包含五个层面。

第一，流程模型要可配置

企业流程不是一成不变的。组织调整、业务变化、监管要求、产品变化都会带来流程变化。如果每次改流程都要开发，流程系统就会很快跟不上业务。更合理的方式是基于标准流程引擎，让企业能够通过配置和编排调整流程。

第二，流程节点要能连接系统

流程不能只是人工审批。很多节点本质上是系统动作，比如创建账号、同步客户信息、触发部署流水线、登记资产、发送通知、查询库存、更新工单状态。流程节点必须能通过连接器调用企业系统，才能减少重复录入和人工搬运。

第三，流程状态要统一可见

管理者真正关心的不是某个系统里有多少表单，而是关键流程现在走到哪里、卡在哪个节点、谁在处理、超时多久、是否影响业务。没有统一状态视图，就很难做过程管理。

第四，流程执行要有审计

企业流程涉及权限、成本、风险和责任。谁发起、谁审批、谁执行、调用了哪个系统、修改了什么数据、是否符合规则，都必须可追溯。流程治理不是为了让系统显得复杂，而是为了让关键操作有据可查。

第五，流程经验要能沉淀

流程执行过程中会产生大量经验：哪些变更容易失败，哪些审批经常超时，哪些故障处理方案有效，哪些服务请求可以自动化。这些经验如果不沉淀，下次还会重新摸索。流程治理应该和知识库、数据分析、AI 能力结合起来，让流程越跑越聪明。

为什么 ITSM 可以成为企业流程治理的一个重要入口？

很多人对 ITSM 的理解还停留在“工单系统”。如果只是记录问题、派单、关闭工单，ITSM 的价值确实有限。但从管理思想上看，ITSM 天然适合做企业流程治理的入口，因为它长期处理的就是服务请求、事件、问题、变更、发布、配置、SLA 和知识沉淀。

这些能力背后，其实是企业流程治理的通用能力。

工单管理解决任务如何接收、分派、跟踪和闭环。

事件管理解决突发问题如何响应、升级和恢复。

问题管理解决重复问题如何根因分析和长期治理。

变更管理解决风险操作如何评估、审批、执行和回滚。

CMDB解决资产、服务、系统和关系如何被看见。

SLA 和知识库解决服务质量如何度量，经验如何沉淀。

这些能力并不只适用于 IT 部门。人事入职、行政申请、采购流程、客户交付、供应商协同、数据权限申请，本质上也都需要任务流转、审批、状态跟踪、责任记录、系统集成和知识沉淀。

当然，这并不意味着 ITSM 可以简单替代所有业务系统。更合理的定位是：ITSM 作为服务管理和流程治理底座，连接已有业务系统，把跨系统流程统一编排起来。业务系统继续负责专业业务，流程底座负责让业务动作跨系统协同。

AI 进入流程后，价值才会真正放大

AI 在企业里的价值，不应该只停留在问答。更大的价值，是进入流程之后，帮助企业减少重复判断、重复检索、重复填写、重复转派和重复催办。

比如一个故障事件进入 ITSM，AI 可以先做分诊，判断影响范围和优先级；再根据 CMDB、监控指标、历史工单和知识库提取上下文；然后推荐处理方案，生成沟通摘要，提醒可能的变更风险；如果是低风险标准动作，可以在审批规则允许的情况下触发自动化；处理完成后，再辅助生成复盘和知识条目。

这类场景里，AI 不是流程外面的聊天框，而是流程里的参与者。它不是替代所有人，而是把大量信息整理、初步判断和标准动作交给系统，让人把精力放在关键决策、风险判断和例外处理上。

AI Native 流程的核心不是“全自动”

更现实的目标是：高频、低风险、规则明确的动作逐步自动化；高风险、强合规、影响面大的动作保留人工审批和人工决策；所有动作都可审计、可回放、可优化。

这也是为什么企业流程平台不能只做表单和审批。未来的流程平台必须同时具备流程编排、连接器、权限、审计、知识库和 AI 能力。否则 AI 没有上下文，流程没有执行力，系统之间仍然是孤岛。

我的开源 ITSM 项目，想先把流程底座打牢

我正在做的开源 AI Native ITSM 项目，正是从这个判断出发：国内企业数字化接下来要解决的，不只是再做一个工单系统，而是建设一个可私有化、可扩展、可二次开发的流程治理底座。

项目目前已经围绕 ITIL v3 核心流程、工单、事件、问题、变更、发布、服务请求、服务目录、SLA、知识库、BPMN 工作流、多租户、权限和 AI 基础能力做了建设。AI 能力方面，已经实现智能分诊、工单摘要、RAG 知识库问答等基础 Skill；连接器市场、插件市场、Skill 市场、飞书/企业微信/钉钉等企业集成能力会持续推进。

CMDB 也是这个体系里的关键模块。它不是简单资产表，而是流程判断的上下文来源：一个变更影响哪些服务，一个故障关联哪些系统，一个权限申请涉及哪些资源，一个告警应该通知谁，都离不开配置项和关系数据。当前 CMDB 能力仍在持续完善中，后续会继续围绕关系建模、影响分析和自动发现做迭代。

这个项目的核心目标不是把概念讲大，而是把几个基础问题做扎实：

流程能不能自定义，能不能按企业制度运行？

系统能不能连接，能不能让数据沿着流程流动？

AI 能不能在权限、审计和流程约束下参与服务管理？

企业能不能基于开源项目二次开发，而不是被封闭平台完全锁定？

项目还在早期阶段，GitHub 上已有 30+ Star，离成熟商业平台还有距离。但开源的意义在于，它可以让更多企业和开发者一起讨论架构、补齐场景、贡献连接器、完善流程模板，把国内企业真正需要的 ITSM 和流程治理能力做出来。