一汽数字化的“业务单元”究竟创新在哪里？
企业知识开源计划创始人最近行业里有不少人问我一汽集团提出的“业务单元+AI”企业架构方法是怎么回事，甚至有客户说要学习这个创新的做法。
我稍作了一下桌面研究，从对这个方法的公开描述来看，我感觉“业务单元”并没有啥创新，是混淆了企业架构（TOGAF）、业务流程管理（BPMN）等行业标准框架的基本概念而硬造出来的词，关键是，它的融合方向，对于大型企业实施企业架构管理和业务流程管理可能产生误导，兹事体大，因而特将拙见分享如下，如有不当之处，欢迎各位专家批评指正。
在一汽集团官网上，https://www.faw.com.cn/fawcn/373694/373708/5886660/index.html，“业务单元+AI”被作为是一汽数智化转型的基本方法论。
在多篇媒体通稿里（例如https://tech.ifeng.com/c/8nTYOLrICnF），是这样定义“业务单元”的：
中国一汽数智转型之所以能实现“全域变革”，核心在于创新性提出“业务单元”概念，构建起“架构治理-数据驱动-AI赋能”的完整方法论闭环，从根本上破解“流程与执行两层皮”“业务与IT两层皮”的行业痛点。
“业务单元”作为业务流程解耦的最小单元，聚焦最底层业务动作管理。通过EAMAP企业架构管理工具，中国一汽将复杂业务拆解为原子级单元，再依据数据成熟度动态重组，而非人为串联——这一逻辑彻底打破“部门墙”，改变传统管理中“数据向上衰减”的困境，让业务协作从文档流转升级为结构化业务对象联动，业务单元随运行数据实时优化，协同效率显著提升。在此基础上，按角色聚合业务单元打造的“一汽・七星云工作台”，更实现全业务孪生，为多场景数字化奠定统一底座。
如果只从这段文字看，对企业软件架构熟悉的朋友，应该很容易想到“业务单元”指的就是服务导向架构（SOA）里的“服务”（service）而已。
我另外看到三篇公众号文章，对“一汽业务单元”进行了详细阐释：
其中一篇文章是这样写的：
一汽定义的“业务单元”，是构成所有业务流程的最小不可再分的业务动作，如同物质构成的“原子”，具备“节点、效率、质量”三大核心属性。
武艳军，公众号：金融IT那些事儿中国一汽：以业务单元为核心的5A架构方法论与实践
我理解这个图里的业务单元，就是经常有人说的 “六级流程”，它还创造性地画到了第七级（L7）：
这个业务流程六级/七级分类，跟企业架构方法论没啥关系，而是来自APQC的流程分类分级框架（PCF），我在书里写过：
有很多人错误理解PCF是流程模型。APQC PCF并不是流程模型，而仅仅是一个企业流程的编目体系。在这个树形结构只有处于末梢的文件（不论它在参考框架中被细分到第几级）才是流程模型，中间的层级都是分类节点而已，APQC PCF仅仅提供了一个分类框架参考，并没有提供任何参考流程模型。
APQC PCF说的“L3-流程”，跟真正表述流程的“流程模型”，在概念上非常混淆：
所以，一汽的“业务单元”应该等于APQC的L5-Task，或者说，按照公开资料上一汽业务流程/业务活动的那个7级树状图示意，“业务单元”就是一个流程模型而已。
流程建模的国际通用标准是BPMN，流程模型中最小的不可细分单元叫任务（Task，注意BPMN里说的process/activity/task，和APQC里这三个词的所指代的概念有点不一样，非常让人困扰）。那么，当“一汽业务单元”被声称是业务流程不可细分的最小单元，它应该是指BPMN模型里的任务（task）。
但是几篇文中对于“业务单元”的举例又让我很困惑：
例如，消费者订购一台红旗车的过程，被拆解为“车型选择” “配置确认 ”“库存核查”“订单锁定”“排产调度”等数十个业务单元，每个单元独立运行又通过数据流实时联动，彻底改变了传统“计划驱动”的刚性模式，实现了“用户需求驱动”的柔性响应。
武艳军，公众号：金融IT那些事儿中国一汽：以业务单元为核心的5A架构方法论与实践
从流程建模的颗粒度来说，“车型选择”应该不是“最小不可再分的业务动作”，因为车型选择里还有：选颜色、选内饰、选天窗等更细小的动作，或者还有“选错回退”、“试配存档”等子流程。订购一台车的端到端流程，如果有“数十个业务单元”，那么其颗粒度大致等于BPMN面向业务分析的流程模型，而非系统实现的任务级颗粒度，二者区别后文详述。
如下图所示，BPMN的活动（activity）分为Task和子流程两种类型，其中服务类任务（Service task）就是调用了数字化服务——亦即一汽在宣传材料中说的“微服务”，然而在现实软件架构中，业务服务并不一定都是微服务，不过我就不在这个技术定义上钻牛角尖了，我们谈主要问题。
尽管有这么多相互矛盾的陈述，我猜测一汽“业务单元”想表达的意思，等于BPMN流程模型里的任务（task）。
从实现角度，我认为流程就是流程，如果说流程有分级，顶多就分两层：流程和子流程的嵌套。我将BPMN规范推荐的流程分层建模的原理，画了一张图解释如下：
BPMN的分层建模是为了面向企业内流程管理从规划到实现的不同角色：
业务人员讨论流程只需要看到顶层就可以了，不一定需要知道细节到；系统架构设计以及具体的软件开发，在宏观模型之下，有更详细的流程视图，而对于业务用户和业务架构设计者，并不需要了解这些详细视图。
BPMN模型作为一个国际通用标准，本身能百分之百满足一汽对于业务流程建模的要求，我就不明白为啥非要将BPMN标准的“任务”这个词，另外换个名字叫“业务单元”。
在另一篇文章中，业务单元看起来又是典型的基于DDD的微服务架构设计，如下图：
如果按照这个方法设计出来一个业务单元算一个微服务，后文提到一汽集团有数万个业务单元，技术上说，它不可能有数万个微服务，那么，业务单元和微服务并不能画等号。我看起来也很晕，姑且采用前文那个业务单元等于“六级流程”的定义，展开全文叙述。
实际上，“一汽业务单元“是把业界几种主要的业务建模的框架混在一起了：
说自己是企业架构方法论（TOGAF），但是用了APQC的企业流程分类框架（PCF），表达的意思却又是BPMN流程建模的概念，还蹭了一下领域驱动设计（DDD）的边。
为什么我认为把这些概念混在一起，会误导企业架构和业务流程管理的实施工作呢？
因为这是一些不同的方法论，在企业内的使用对象和使用场景都不一样：
企业架构是企业数字化建设从战略规划到项目管控的端到端方法论和治理框架，是企业IT管理的宪法，它是战略性的、宏观的，企业架构不同于解决方案架构（solution architecture），不涉及到具体某个系统、某个应用、某个项目的流程任务级设计；如前文所述“一汽业务单元”等于流程任务的话，那么不应该属于企业架构的范畴。
流程框架是企业流程的字典和分类法，采用APQC PCF国际分类标准，有助于进行跨企业的流程规范性、流程绩效的对标；
BPMN是全世界统一的“业务流程怎么画、怎么执行”的图形与文件标准，是流程图的国际通行语言，
这三者是企业数字化中解决不同问题的方法，一般来说在企业数字化组织中属于不同的部门：
-企业架构是IT战略管理，属于CIO办，甚至可以和CIO平行，它提供的是企业架构蓝图以及各种管控原则
-流程框架属于流程管理部，是个纯管理性职能，可以属于、也可以不属于IT部门，它提供的流程清单用于衔接业务架构规划和信息系统部署
-BPMN属于企业的BPM系统，它交付的是可直接部署到Camunda、奥锐方等流程编排和自动化平台的.bpmn文件（含Call Activity复用子流程）
“一汽业务单元”这个东西在企业数字化工作中实际是存在的，公开报道文章提到：
业务单元并非传统的部门名称，而是从流程视角拆解出的最小标准化业务能力沉淀。
一汽的5A 架构是通过业务单元的拆解与重组，将抽象的战略目标转化为可量化、可执行的架构组件，
1-2个微服务对应一个业务单元
一汽七星云工作台将38000 余个业务单元按角色聚合为可配置的作业流程
Loong，公众号：数字化转型战略指南中国一汽 5A 架构创新：以业务单元协同解决部门墙问题
按这个描述，如果说“一汽业务单元”对应到流程任务，那么一个复杂企业系统中有几万个流程任务是可以理解的。但是我不知道是不是所有业务单元都对应微服务？微服务的重用比例有多高？如果我们假设不重用的话，一个汽车企业的IT平台上有38000-76000个微服务显然是不可管理的。
“一汽业务单元”搞出了个六级/七级流程，我在《七级流程和华为4A架构 ｜ 层级狂热、框架堆砌与会议室虚假繁荣》阐述过我的观点，无论企业架构管理还是业务流程管理，在业务架构设计层都不是越细越好，在此不赘述了。
总之，在目前已有的一切企业数字化的标准化框架中，无论是偏技术的SOA、云原生，还是偏业务的TOGAF、BPM、APQC PCF，都有标准化名词、概念体系覆盖了“一汽业务单元”想表达的意思！
一汽提出个“业务单元”概念，并在行业里推广，不仅没有任何创新，而且误导其他企业错失社会性的技术标准，给企业徒增实施难度——这就是企业知识开源一直反对，并且试图教育社会的：
用标准名词！
别乱发明新词！
乱造词制造信息污染，抬升认知成本，阻碍中国企业服务行业发展！
最后说明：我以上引用三篇文章都非一汽的官方解释，可能跟一汽数字化部门的设计初衷有偏差，所以特别希望一汽业务单元的设计者能够给社会科普一下，业务单元的创新之处究竟在哪里？原创之处究竟在哪里？这也是造福中国企业数字化行业的幸事。
