一汽“业务单元”探讨｜ 对官方出品原文的解析 （一）

关于一汽数字化的“业务单元”究竟创新在哪里？这个争议话题，我找到了“中国一汽官方出品”的著作对“业务单元”的解释。该书可以通过微信读书的付费会员读到，作者是中国一汽数字化转型委员会和上海科技大学毛基业课题组，“业务单元”相关部分为原书第七至九章：

我认为“业务单元”这个概念，不仅是字面上跟企业管理通行术语里的“业务单元”这个词产生混淆，而且它所代表的不标准的企业架构和业务流程管理方法论，可能会给企业的数字化转型技术路线带来隐患，并且不利于促进中国企业软件行业的发展。

以下我对原书跟“业务单元”相关原文进行详细分析。

【官方出品原书文字】

5A架构为企业数智化转型提供了顶层设计，但是如何落地，仍然是企业面临的主要挑战。中国一汽提出了“业务单元”的概念和构建方法，能够在原子级别实现业务的数字孪生，将顶层的业务架构落实到执行层面，并为信息、应用和技术架构提供重要输入内容。

中国一汽体系数字化部总经理表示：“传统企业在应用TOGAF的过程中，业务架构的应用仍停留在‘纸上谈兵’层面，仅利用该方法将业务流程梳理清楚，并形成流程文件，之后便将这些文件束之高阁，没有产生显著的价值。”

【果总点评】

这章论述了“业务单元”这个概念提出来的目的，即解决业务架构的业务流程得以被执行的问题。

那么我们就来分析一下，是不是TOGAF、BPMN等国际通行的企业数字化管理的标准化方法论框架，不能满足一汽在数智化转型中“流程落地”的需求，一定要别出心裁来创新一个“业务单元”？

从中国一汽体系数字化部总经理的这句话来看，他可能是对大型企业IT治理的核心方法——企业架构（EA）以及EA参考框架TOGAF的作用有些误会，简单说，就是对这两点的认识：

TOGAF本身并不解决如何梳理流程、画流程，以及如何让流程运行的问题；

企业架构也不是用来解决流程管理和流程执行问题的。

所以，他说用TOGAF来梳理流程、并且保证流程运行所遇到的挑战，本来就是缘木求鱼，这可能是后面一系列认知错位的本源。

首先，TOGAF是一套企业架构的参考标准，提供开发和治理企业架构的方法论（ADM）与内容框架。

对于具体如何开发面向可执行的流程模型，TOGAF采取开放态度：

不规定具体语法：它更关注架构应该描述什么（如业务功能、流程、数据），而不是严格规定如何画流程。

推荐业界标准：在实际操作中，TOGAF推荐使用UML（统一建模语言）、BPMN（业务流程模型与符号）等被广泛接受的标准来创建架构中的流程模型。BPMN关注业务层面的活动流转、信息结构、参与者角色等，是更适合业务人员（包括流程分析师、管理者）用来进行业务流程建模，并且推给技术人员去实现流程的流程建模语言。

我的感觉是，企业架构和TOGAF不知道是被哪个厂商向一汽过度销售了， 这使得一汽领导对TOGAF产生了不切实际的期望和失望。这个东西不是啥神器，就是一个CIO方法论而已，而且企业架构很大程度上只是一种思想、理念，并不是一套具体的、强制性的、有标准化模板的行动指南。

流程方法论以及建模标准，才是面向行动的。

我在我自己书里写过，在国内做流程模型，过去二十年曾经流行过ANSI、IDEF、EPC等规范，BPMN具有几个优势：国际标准地位、良好的业务与IT沟通能力、强大的执行能力、丰富的元素和符号、与企业信息系统SOA架构的契合等，使得BPMN今天在逐步取代那些旧规范。

从通用性、标准化和厂商支持度来看，BPMN是目前业界公认的流程建模“普通话”，是企业进行跨部门、跨系统业务流程设计和对接时的首选。

所以一汽如果不采用公认的行业标准，而自己去发明一套以“业务单元”这些自创概念为中心的流程建模标准，这就像开展工作不说普通话，一定要说只有自己人听得懂的方言，这不利于在社会上跟外部厂商和合作伙伴进行对接，这对促进中国企业软件行业的发展是非常不利的。

市面上有很多用于绘制BPMN图的设计器（称为Modeler），可以是独立的桌面工具，也可以是BPM平台内置的流程模型设计器。

现在我们团队已经做到用自然语言描述，或者在白板上手绘流程图后拍张照片上传，AI就自动生成BPMN流程模型。

其次，驱动流程模型（亦即总经理说的“流程文件”）能够运行起来的技术组件叫“流程引擎”，通常也称为BPM软件或者BPM平台；今天，流程引擎加上AI大模型能力、各种AI能力和AI智能体交互执行，就是我经常说的业务编排和自动化技术（BOAT）：

流程引擎主要承担以下工作：

解析与驱动：读取BPMN 2.0标准文件，严格按照图中定义的流程逻辑（顺序流、网关、事件）创建并推进流程实例。

任务编排：

* 当遇到需要人类执行的“用户任务”时，自动生成待办事项，并分配给指定的人或角色，这需要集成组织的目录服务。

* 当遇到需要软件执行的“服务任务”时，自动调用预定义的API、Web Service或Java类，完成系统操作。

* 状态管理：持久化保存每个流程实例的当前状态、变量和历史日志，确保流程可中断、可恢复、可审计。

围绕流程引擎，还有一些相关技术，共同构成流程的运行环境：

集成与连接技术：流程需要与企业内部或外部的系统进行信息交互，通常通过ESB（企业服务总线）、REST/SOAP API、消息队列（MQ/Kafka）或专门的连接器来实现。

管理与监控：提供流程实例监控、错误处理、用户任务管理、流程绩效分析（如平均处理时间）和优化建议。

低代码/无代码平台：将BPMN引擎可视化，允许通过拖拽配置方式快速构建应用，降低了开发门槛。

云原生与微服务：现代流程引擎（如Camunda、Flowable、Orion等）本身就是微服务架构，可以容器化部署，通过API协作，更具弹性和可扩展性。

RPA集成：流程引擎可以编排RPA机器人，让其代替人工，完成被流程调用软件的图形界面的操作。

流程引擎有在市场上有广泛的选择——既有开源软件，例如Camunda, Flowable, Activiti，Orion等，开源软件功能强大、灵活性高，也符合国家信创要求，是企业的首选，此外，国内外也有众多的商业化BPM套件可供选择。

【官方出品原书文字】

业务架构是价值流、业务能力和业务流程的结构化设计，业务流程是业务架构的具体执行路径。业务流程管理中存在诸多缺陷，影响了业务架构的有效落地，主要缺陷包括：流程和执行脱节、流程冗余、多任务/多人协作困难。

具体而言：一是流程和执行脱节。企业形成流程设计书，将其录入IT系统，传统上，到这一步，就默认流程管理工作已完成。这种做法忽视了对员工具体动作和行为范式的细粒度管理，未能覆盖到产品或服务交付的“最后一公里”。流程文件成了摆设，未能指导实际的业务执行，未能有效规范员工的实际操作行为。流程和执行脱节会导致效率低下、业务交付质量难以保障等问题。

例如，中国一汽以往研发设计流程，只确定研发人员提交设计任务书的截止日期，却没有明确应该什么时间开始撰写、文稿应达到什么样的质量标准、最终交付的文稿需要包含哪些具体内容等细节。在这种情况下，研发人员很可能临近最后期限才匆忙开始写任务书，后续也按照自己的理解开展任务。这导致工作质量难以得到保障，且一旦出现其他临时事务，研发人员很难并行处理，可能导致交付延期。此外，只有在督查人员发现作业明显不合规时，研发人员才会重新查阅相关流程文档的要求。

【果总点评】

BPMN作为流程建模语言，完全有能力定义流程中任何任务的开始时间、前置条件、关联文档，而BPM平台也具备监控和催办功能。

原书上面这段话将一汽过去存在的业务流程问题，归咎于“业务流程管理中存在诸多缺陷”，所以导向到要去设计“业务单元”这个东东。

这是明显的逻辑错误，就像批评飞机不能飞，不是飞机有问题，而是因为你在把飞机当汽车开。

我们来具体分析几段关键表述：

原文说：“只确定截止日期，未明确开始时间、质量标准、具体内容”，

这是将流通建模不完整等同于无法建模。BPMN完全可以定义流程中每个任务的：

开始时间：通过定时器启动事件、循环事件或条件事件，可精确触发流程/任务。

质量与内容：通过数据对象关联具体的作业指导书、标准模板、表单字段与校验规则。

原文说：“流程文件成了摆设，未能指导执行”，

实际上，真正的BPM就是将流程文件“系统化”、“可执行化”。现代BPM平台可将流程模型直接发布为可运行的应用程序，任务界面内嵌工作指南、表单和必填字段，强制规范执行，而非让人去查阅分离的文档。

原文说：“临近期限才匆忙开始…导致质量难保”，

BPM平台的流程控制台可设置KPI与预警规则，例如：若任务在启动后第3天仍未完成，则系统自动提醒参与者及其汇报经理，实现主动管理，而非被动的人为催办。

原文说：“只有督查时才发现不合规”，

BPM平台可在每个任务提交节点设置自动化验证规则（如：检查文档版本、关键字段完整性），不合规则无法提交，实现“质量内建”。

总之，原文陈述的事实：一汽过去的IT系统仅仅是记录、存储流程，而没有成为一个可执行、可监控、可优化的任务编排和流程驱动器，这个事实的问题本质并不是BPMN流程建模语言和BPM平台做不到，而是在过去许多系统实施中“没有被要求做到”或“没有被正确地用起来”。

真正的BPM体系，恰恰是为了弥合流程设计与业务执行之间的鸿沟而设计的。要发挥其威力，需要将精细化的管理思想，转化为同样精细化的流程模型与系统规则。

所以一汽业务架构通过流程来落地的第一个挑战，完全可以通过标准化的BPM体系来解决；这个挑战的存在，不是发明“业务单元”的理由。