2012年创立，2022年系统超过300个，2015年成立效能团队——一家大型互联网公司的真实账本。这本书用三十章拆一件事：当组织从树状长成网状，如何用一条可解释的流程抵抗自身的混乱。

2015年，一家大型互联网公司成立了一个叫“效能”的团队。在此之前，公司已经引入过一些OA系统，但“简单的OA系统根本无法满足组织内复杂的协同需求”。七年之后，2022年，这家公司的各类系统数量超过300个。系统是加法，协同却常常做成了减法。

这不是一家公司的病。任正非描述过企业的熵增：政策、制度、文化在运营过程中，有效功率逐步减少、无效功率逐渐增加，混乱度上升，企业向无效、无序的方向滑去，最终进入熵死状态。要抵消它，只能靠制度、变革，激活组织与人的竞争与活力。问题在于，制度写在纸上，变革落在会上，真正每天运转的是那些没人画出来的流程。

贺波，国内资深的工作流及BPM领域专家，专注于流程领域十余年，曾任东华软件股份公司技术总监，从零研发的BPM平台被用于政府、银行、学校和企业；后来他加入某知名互联网公司，任高级企业信息化技术专家、流程平台部负责人，从无到有搭建“倚天”BPM平台。他把这两段经历写进了《深入Activiti流程引擎》：4篇，30章，从流程六要素一直讲到多引擎架构。

战略是大脑，流程是血管和神经

书里给了一个可以随身携带的模型。企业战略决定做正确的事，组织决定正确地做事，流程帮助企业高效、低成本、低风险地做事。把企业看作人体：战略是大脑，决定做什么；组织是各个器官，各司其职；流程是遍布全身的血管和神经，连接器官，让物质有效循环。

这个比喻之所以有用，是因为它把“卡住了”这件事拆成了两种病。纵向的线路由组织构成，靠职责体系串联最高经营者与普通员工；横向的线路由流程构成，直面客户，打破部门壁垒。一件事推不动，先别急着开会，先判断它堵在纵向的职责上，还是断在横向的衔接上。这两种堵法，药方完全不同。

再往下拆，一个完整的业务流程只有六个要素：输入资源、若干活动、相互作用、输出结果、客户、价值。输入资源包括客户订单、顾客需求、经营计划、物料、设备、资金、信息、行政指令、会议纪要；活动之间要有严格的前后顺序和逻辑关系，一个活动的产出是后一个活动的输入；输出结果可能是有形产品，也可能是无形服务，合格与否最终由客户判断。书里有一句话很硬：“在21世纪，持续的竞争将更多地出自新流程技术，而非新产品技术。”说这话的是麻省理工学院斯隆管理学院的莱斯特·瑟罗。

系统是加法，协同是减法

书里的推荐序一，写作者是一家大型互联网公司的管理者。他没有谈技术栈，只谈了一笔账：

我所在的企业是一家大型互联网公司，为了满足业务需求，从2012年创立开始，大量的业务类系统被搭建，随着时间的推移，业务的复杂度越来越高，各类系统不断被推倒、重构、升级。除了大量支撑业务发展的系统以外，也有大量的支撑运营效率和内部协同效率的系统被搭建。据不完全统计，在2022年，公司的各类系统数量已经超过300个。伴随着业务的发展和业务系统的建设，组织和人员不断膨胀，组织内部的协同呈现网状结构，协同效率显著下降。2015年，公司成立了效能团队，在此之前，公司就引入了一些OA系统，但简单的OA系统根本无法满足组织内复杂的协同需求。从部门成立伊始，我就一直在思考，是否可以打造一套易用的BPM平台来满足公司复杂的网状协同需求，让大家在统一的平台上完成流程节点任务。

注意他的动作顺序。不是再买一套系统，而是先招一名BPM技术专家，组建包含产品、研发和实施的全功能团队；再构建全公司统一、简单易用的BPM平台；然后推动业务类、运营类、内部效率类系统接入。先统一语言，再统一工具。这个顺序反过来，就是三百个系统各自说方言的结局。

引擎里没有魔法，只有命令与责任链

书从第4章开始动手：安装JDK、MySQL、Tomcat，配置Activiti，用一个简单流程跑通第一次启动。第6章掀开引擎盖，讲核心架构、数据库设计和设计模式。Activiti的表分成五类：通用数据表、流程存储表、身份数据表、运行时数据表、历史数据表。它的骨架由三种模式撑起：命令模式、责任链模式、命令链模式。流程部署、流程定义解析、流程启动、节点流转、网关控制、流程结束，每一步都有对应的核心代码，连乐观锁怎么实现都写了。

如果你喜欢从物理世界入手，《图解机械工程入门》是同一类乐趣的另一面：把一台机器拆到齿轮咬合，再装回去，听它转起来。区别只在于，一个拆的是金属，一个拆的是审批流。

第28章开始谈性能与容量：历史数据异步化，可以基于已有数据库表做，也可以基于MongoDB做，还要保证数据一致性；ID生成器有数据库ID生成器（DbIdGenerator）、UUID生成器，也可以自定义；定时器的执行过程被拆开，再优化。第29章、第30章处理多引擎架构，先分析水平分库分表方案的局限性，再做多引擎建模服务、工作流引擎路由，用Pika写路由信息，用Spring Cloud Gateway做服务网关，用Nacos搭引擎集群，用Elasticsearch搭流程查询服务。这种把每一毫秒掰开来算的劲头，让人想起《那个在荒岛营地瘦了10磅的男孩，后来把火箭送上了天》里那种工程式的偏执——不是喊口号，是把一个环节一个环节地削减到不能再削。

加签与减签，本土流程的骨头

书里最像中国办公室的部分在第27章：通过代码创建流程模型；流程实例动态增加临时节点；流程节点自动跳；会签加签的扩展实现；会签减签的扩展实现。你大概见过这种场面——一张会签单走到第七个人，领导说“再加一个法务”，于是流程不能重发起，只能在运行中的实例上插一个节点。这不是教科书里的标准流程，却是真实组织长出来的骨头。

这也解释了书里那句判断：许多企业的流程管理仍停留在技术层面，企业内部仍然以组织职能为基础开展工作，无法有效解决跨部门的业务问题。流程管理如果只是IT部门的事，它就只是又一套系统。当华尔街的算盘声盖过工厂的轰鸣，账面上的效率会掩盖流程里的空转，《当华尔街的算盘声盖过工厂的轰鸣》讲的是同一个方向的隐忧：数字越漂亮，越要回头看东西是怎么被造出来的。

今晚，先填满六个格子

不用等到公司立项。今晚拿一张纸，画六个格子：输入资源、若干活动、相互作用、输出结果、客户、价值。把你手上卡了三天的那件事填进去。填不满的那一格，就是阻塞点。它多半不在你以为是“不配合”的那个人身上，而在两条活动之间的衔接处，或者在一个从没被定义过的客户需求上。

想动手的，装JDK1.8，用H2数据库，照第4章配置