谈数字化时,最常见的说法是“降本增效”。这当然没错,但如果只用这个视角理解数字化,会把它说得太窄。
很多数字化建设短期甚至并不会降本。增加过程记录、补齐追溯链路、统一对象定义、明确责任边界、采集更多状态,都可能让组织一开始做更多事情。但这些投入仍然有价值,因为数字化真正改变的,不只是工作的效率,而是一个组织能够感知、理解和治理多复杂的现实。
从这个角度看,数字化更底层的意义是:提升治理能力。
01|治理的前提,是先看见
一个组织能够治理什么,首先取决于它能够看见什么。
古代国家想征税,需要先知道有多少人口、多少土地、多少产出;城市想治理交通,需要知道道路、车辆、位置、流量和事件;企业想管理交付,也需要知道现在有多少订单、每个订单走到哪里、哪些任务已经延期、哪些物料影响生产、谁对哪个事项负责。
如果这些现实无法被稳定地看见,那么所谓“管理”很大程度上只能依赖经验、人工汇报和临时协调。
管理者每天开会追问“现在什么情况”,本身就说明组织对现实的感知能力还很弱。信息可能存在于员工脑子里、群聊里、Excel 里,也可能散落在多个互不连接的系统中,但只要它们没有形成稳定、持续、可共享的表征,组织就很难在这个基础上进行进一步判断。
所以治理并不是先有一个聪明的决策者,再去调用数据。很多时候,是因为现实终于变得可见,治理才第一次真正成为可能。
一个组织能治理到多细,首先取决于它能看见到多细。
02|数字化首先扩展的是组织的感知范围
没有数字化时,一个组织能够感知多少现实,受到很多天然限制。管理者只能看到自己亲自接触的部分,只能依赖下属逐层汇报,信息在传递过程中不断压缩和失真;很多状态只有现场的人知道,很多规则只存在于某个老员工脑中,很多异常只有出问题以后才会被发现。
纸面记录、Excel、ERP、MES、CRM,本质上都在不断突破这些限制。它们把原本只能依赖人脑记忆、口头沟通和现场观察的现实,逐渐搬进一个可以共享、持续读取和反复检查的数字环境中。
这也是“表征”和“数字化”之间的关系。表征解决的是现实如何被表示,而数字化进一步让这些表征能够规模化、持续化地进入组织运行。
一个订单不再只是销售和客户之间的一次约定,而成为系统中的一个对象;它可以拥有状态、责任人、时间节点和关联任务。一个设备不再只存在于厂房里,而拥有自己的数字身份、运行状态和维修历史。一个采购需求也不再只是某个人发出的一句话,而可以进一步关联库存、项目、供应商、采购任务和交付结果。
随着越来越多现实进入数字世界,组织拥有的就不只是“更多数据”,而是一个不断扩大的可观测空间。
数字化因此首先提升的,不是操作速度,而是组织对自身运行状态的感知能力。
03|Agent 的闭环能力,建立在业务世界的可治理性之上
今天很多 Agent 架构都会讨论类似的闭环:感知环境、获得信息、进行判断、采取行动,再根据结果更新下一轮行为。从 Agent 自身的视角看,这通常会被描述为一组能力:感知、度量、判断、决策、行动和反馈。
但如果把视角从 Agent 本身移到它所处的业务环境,会发现这套闭环还有另一组更基础的前提。
所谓“感知”,首先要求现实是可见的。关键对象、状态和变化必须能够进入 Agent 所能访问的数字环境。如果真实的订单状态从未被记录,设备运行状态三天才人工更新一次,责任分工只存在于临时群聊里,那么模型具备再强的感知能力,也只能感知到一个残缺的世界。
“度量”要求业务现实是可量化的。一个组织不只是知道“项目慢了”,还需要知道慢了多少、相对哪个目标发生偏差、偏差持续了多久。如果目标、时间、数量和状态都没有被清楚定义,Agent 也无法仅凭推理能力补出可靠度量。
“判断”则进一步要求环境具有可归因性。如果系统只能看到“项目延期”,却无法看到任务依赖、资源占用、需求变更、物料缺口和责任链路,那么 Agent 即使能生成一段听起来合理的解释,也很难稳定地区分真正原因和文本上的合理猜测。
再往后,决策和协作需要业务世界是可协调的:责任是否明确,任务能否拆分,资源能否调度,动作边界是否清楚。真正采取行动,又要求系统具备可干预性:在哪里可以执行什么动作,动作会改变哪个对象的什么状态,执行结果又如何重新反馈回来。
所以从两个视角看,其实是同一套闭环的两面:
| Actor / Agent 的能力 | 业务世界需要提供的条件 |
|---|---|
| 感知 | 可见:对象、状态和变化可以被观察 |
| 度量 | 可量化:规模、时间、目标和偏差可以被测量 |
| 判断 | 可归因:关系、依赖、约束和原因可以被追踪 |
| 决策 / 协同 | 可协调:责任、任务、资源和动作可以被组织 |
| 行动 | 可干预:存在明确的动作入口,并能获得结果反馈 |
Agent Loop 描述的是 Actor 如何运行;数字化治理描述的是这个世界是否已经被建设到足以支持这样的 Loop。
这也是为什么模型能力并不能单独决定 Agent 在企业里的能力上限。一个业务世界如果不可见、不可量化、不可归因,那么再强的模型也只能在一个低分辨率环境中工作。
从这个意义上说,数字化成熟度也可以理解为:现实业务从“存在”到“可治理”的程度。
04|数字化的颗粒度,决定治理能力的上限
治理能力不仅取决于“有没有数据”,还取决于现实被建模到了什么颗粒度。
假设一个企业只能在系统里看到“项目正常”或“项目延期”,那么它能够进行的治理也基本停留在项目这一层。管理者知道项目出了问题,但不知道问题具体发生在哪个环节,只能继续开会、问人、催进度。
如果进一步把项目拆开,就会看到合同、订单、技术方案、物料需求、采购任务、生产任务、交付节点等不同对象;每个对象拥有自己的状态、责任人、关系、规则和指标。此时“项目延期”不再只是一个结果标签,而可以进一步被追踪:是哪一批物料未齐套,哪个采购任务没有完成,原因是供应商延期还是需求变更,又影响了哪些生产任务。
组织并没有因为系统上线就突然变聪明。真正发生变化的是:原来只能在“项目”这一层观察现实,现在可以继续向下看到任务、资源和依赖,因此治理也可以从粗粒度的催促,进入更细粒度的定位和干预。
你能治理到哪一层,取决于现实被建模到了哪一层。
城市治理也是如此。
只有行政区级别的统计数据,城市只能在较粗的范围内识别和处理问题。当道路、建筑、地块拥有稳定编号,空间关系被建立,网格与责任主体能够对应,城市才有条件进一步定位具体事件、识别影响范围并安排处置。
摄像头可以扩展城市的感知能力,但仅有摄像头还不够。如果监测到的事件无法关联到具体道路、建筑、规则与责任主体,感知结果就很难转化为精确的治理行动。
这也是为什么对象、任务、职责这些看起来很基础的数字化工作如此重要。对象没有被定义,就无法稳定追踪状态;任务没有被定义,就无法准确识别执行进度;职责没有被定义,就很难回答出现问题以后究竟由谁处理。
数字化成熟度因此并不等于“上了多少系统”,更不等于“有多少功能在线”。更值得关注的是,在一个具体业务域中,关键对象是否被识别,状态是否可信,任务是否可追踪,责任是否清楚,关系和依赖是否能够被理解。
这种治理分辨率还可以进一步拆解为不同业务对象与任务的数字化成熟度。
对象成熟度关注的是:一个对象是否具有稳定身份,能否与其他对象建立明确关系,其状态和变化是否能够被持续追踪。
任务成熟度关注的是:一项工作是否具有明确的触发条件、执行主体、输入输出、状态与完成标准,执行结果能否反馈到相关业务对象。
两者并不一定同步。企业可能已经建立了完整的物料档案,却仍然依靠采购人员在群聊里协调缺料;也可能拥有完善的审批和任务系统,但系统处理的只是定义模糊的申请单。
因此,数字化成熟度不宜只看企业整体处于哪个阶段,还需要下钻到具体业务域,检查不同对象和任务的成熟度,以及它们能否相互衔接。
这些能力共同决定了一个组织能够以多高的分辨率治理自己。
05|为什么“降本增效”把数字化说窄了
传统数字化项目喜欢计算投入之后节省了多少人、少填了多少表、缩短了多少天。这些指标当然重要,因为数字化最终必须产生业务价值。但如果把这些结果直接当成数字化的本质,就容易忽略很多更底层、也更长期的价值。
征税是一个很直观的例子。古代征税依赖户籍、土地登记、人工清丈与层层汇报,能够识别和核验的对象范围、信息更新频率以及统计精度,都受到当时治理基础设施的限制。
随着身份登记、地籍、不动产登记、交易记录和税务信息系统逐步发展,治理主体能够更稳定地识别纳税主体、核验相关事实,并在更细的颗粒度上开展征管。
这些基础设施的价值,显然不能只用节省了多少统计人员来衡量。它们更根本的作用,是扩展了治理主体能够识别、计算和处理的现实范围。
企业数字化也是一样。
统一产品定义,可能短期不会少一个人,甚至需要投入大量时间整理历史资料;补齐质量追溯,可能增加现场记录工作;把过去模糊的责任拆清楚,也可能让原本靠默契和熟人关系运行的流程暂时显得更“麻烦”。这些工作未必立即产生一个漂亮的 ROI 数字,但它们在建立新的治理基础。
以前组织无法稳定知道发生了什么,现在可以知道;以前问题只能等到最终结果暴露,现在可以提前在中间状态发现;以前出了问题只能找人协调,现在可以定位到具体对象、任务和责任;以前业务增长以后只能依赖更多人维持,现在则可能依赖更稳定的结构管理更大的复杂度。
所以数字化更深层的价值,不只是让既有工作做得更快,而是:
让一个组织能够管理过去无法管理的复杂度。
当企业规模变大、变化速度加快、业务链条拉长、参与角色增加以后,这种能力往往比单点效率提升更重要。
降本增效,是治理能力提升之后可能产生的结果之一;更好的风险控制、更稳定的交付、更高的组织复制能力和更强的复杂业务承载能力,也都是它的结果。
06|Agent 没有降低数字化要求,反而提高了要求
Agent 出现以后,一个很自然的想法是:既然大模型可以读文档、理解自然语言、跨系统调用工具,那么过去那些复杂的数据治理、系统建设和业务建模是不是可以绕过去。
从短期局部任务看,确实有一部分工作可以被绕过。Agent 可以从多个来源抓取信息,也可以利用自然语言补足过去必须通过固定界面和流程完成的操作。
但如果目标是让 Agent 长期进入真实业务并持续承担判断和行动,结论反而相反。
过去很多模糊性可以由人来兜底。一个字段定义不清,老员工知道什么意思;流程和现实不一致,执行的人知道什么时候应该变通;两个系统数据冲突,业务人员可以凭经验判断哪个更可信。
一旦越来越多判断和行动开始交给 Agent,这些曾经被隐藏在人的经验里的模糊性,就会直接变成机器行动的不确定性。
对象没有定义清楚,Agent 就无法稳定判断自己操作的是谁;状态不可信,它就无法知道当前现实是什么;责任不明确,它不知道该把任务交给谁;规则互相冲突,它只能在冲突表述之间自行猜测;现实变化没有进入系统,它甚至无法意识到环境已经发生变化。
所以 Agent 并没有让数字化基础变得不重要。
恰恰相反,它把过去被人默默吸收的很多组织熵重新暴露了出来。
这也是为什么我把企业 AI 落地理解成一条存在依赖关系的链条:
业务 → 组织 → 系统 → Agent
这不是要求所有企业必须先完成一场漫长而完整的数字化转型,再开始使用 AI。现实中的建设当然可以并行,也会不断往返迭代。
它表达的是另一件事:Agent 能够稳定工作的前提,最终仍然来自一个足够可见、可量化、可归因、可协调和可干预的业务世界。
数字化真正改变的,也从来不只是企业使用了什么软件。随着越来越多对象、关系、状态、规则和任务进入持续运行的数字表征中,组织获得的是一种更高分辨率的治理能力。
而 AI,只是在这个基础上,进一步扩展能够理解、判断和行动的主体。
所以,在讨论一个企业可以做什么 Agent 之前,也许应该先问一个更基础的问题:
这个组织今天,究竟能看见自己的业务到什么程度?