只做加法不重构：流程引擎的长期演进是怎么做到的

版本戳比对、增量补偿、幂等执行------三步构成一个可以反复运行而不出错的自动升级程序。配合四张核心表的主键二十多年不变，客户从任意历史版本都能一路升到最新。本文拆解这套机制，并对照国外引擎的设计取向。

1.1　公司简介

济南驰骋信息技术有限公司成立于 2011 年，其前身是 2003 年创立的临沂驰骋信息技术有限公司。公司是一家专注于低代码 BPM（业务流程管理）与工作流引擎研发的软件企业，主营业务为：自主研发、销售「驰骋低代码 BPM」产品，并围绕流程引擎、表单引擎、低代码开发平台，为客户提供软件产品、源码授权、技术咨询与深度定制开发服务。

二十三年，公司只做一件事------把工作流引擎这件事做深、做透、做到源码级可控。从最初的 CCFlow 工作流引擎，到覆盖 Java 与 .NET 双技术栈的 JFlow / CCFlow 双引擎，再到今天流程、表单、门户、报表、大屏、AI 一体的低代码 BPM 平台，驰骋始终沿着同一条技术主线前行：让中国的企业和软件公司，用得起、改得动、控得住的流程平台。

公司研发的驰骋低代码 BPM 产品（JFlow / CCFlow）是国内主流的开源工作流引擎之一，长期为软件公司、企业 IT 部门、科研院所提供工作流引擎与低代码开发平台能力。产品以「面向模式的开发理论」为方法论基础------把纷繁复杂的业务形态归纳为少数可组合、可复用的流程模式与开发范式，让业务人员看得懂、让实施顾问配得出、让开发人员扩得开。

值得说明的是，驰骋的引擎不是闭门设计出来的。它起步于税务系统的真实业务------从 2003 年临沂税务局的第一条审批流程开始，随后相继应用于青海省、海南省、河北省等地税务系统。在不同地区、不同组织形态、不同业务规则的长期实践中，团队反复面对同一类问题：流程怎么建模、审批怎么找人、退回怎么留痕、多地差异如何用同一套引擎承载。正是在这些具体项目的差异与共性之间，团队抽象、总结、归纳出了国内第一代 BPM 引擎的核心模型 ，并将其开源，填补了国内开源 BPM 的空白。先有项目，再有产品；先在多地验证，再做抽象归纳------这条路径，决定了驰骋引擎从诞生之日起就是面向真实业务的，而不是实验室里的产物。

1.2　团队与布局

公司现有员工 17 人，其中研发与服务团队按「总部集中研发 + 区域就近服务」的方式分布：

城市	人数	主要职能
济南（总部）	12	产品研发、核心引擎、平台架构、销售与运营
重庆	2	区域交付与技术服务
北京	2	市场与客户服务、区域交付支持
哈尔滨	1	交付与技术支持
杭州	1	交付与技术支持

团队规模不大，但结构精悍：核心研发人员自公司成立起即深耕工作流与低代码方向，多数成员具备十年以上 BPM 引擎研发与政企项目支撑经验。我们不做大而全的「软件工厂」，只做一支能把引擎写到源码级、把问题解到根因上的小而强的团队。

这种布局的意义在于：无论客户在东北、西南、华北还是华东，都能找到近在身边的驰骋同事；而所有区域的交付经验，又统一回流到济南的研发主线，形成「一线问题驱动产品演进」的正循环。

1.3　发展历程

阶段	时间	里程碑
起步	2003 年	CCFlow 工作流引擎诞生，首个落地项目为临沂税务局业务流程
验证	2003 年起	相继应用于青海省、海南省、河北省等税务系统，在多地真实业务中反复打磨引擎
抽象	持续演进	从多地项目的差异与共性中抽象、总结、归纳，形成国内第一代 BPM 引擎的核心模型
开源	持续演进	引擎开源发布，填补国内开源 BPM 引擎的空白
立业	2003 年	成立临沂驰骋信息技术有限公司
迁济	2011 年	迁至济南，成立济南驰骋信息技术有限公司，进入规模化发展阶段
双栈	持续演进	推出 Java 版 JFlow，与 .NET 版 CCFlow 共用同一套流程模型，实现「双技术栈同源」
平台化	近年	从单一引擎升级为低代码 BPM 平台：流程设计器、表单设计器、门户、报表、可视化大屏、数据窗口
信创	持续完善	完成达梦、人大金仓、优炫、瀚高、南大通用 GBase 等国产数据库的深度适配
智能化	2025 年起	发布 AI 生成能力：自然语言生成流程、表单、字段、从表、测试数据与代码

1.4　公司定位与使命

定位：做中国最懂「中国式审批」的低代码 BPM 平台厂商，做软件公司与 IT 部门背后那个「看不见但离不开」的流程引擎底座。

使命：

• 为国内提供一流的 BPM 开源产品，覆盖工作流引擎、表单引擎两大核心；
• 填补国内开源 BPM 的空白，让「自主可控」不只是一句口号，而是可以下载、可以编译、可以改动的源码；
• 普及开发平台架构与软件工程开发理论知识，把二十三年沉淀的建模方法与工程经验，变成行业可共享的公共知识；
• 帮助软件公司少写重复代码、帮助企业 IT 部门少走弯路、帮助研究院所把研究成果快速变成可运行的系统。

我们相信：流程是组织的骨架，表单是业务的皮肤，引擎是一家软件公司最不该重复造的那颗轮子。驰骋愿意做那颗轮子，并且把它打磨到可靠、开放、可托付。

第二章　主营业务与产品体系

2.1　主营业务

公司业务由三块构成，彼此支撑、层层递进：

业务板块	具体内容	交付形式
产品研发与销售	驰骋低代码 BPM 平台、JFlow / CCFlow 工作流引擎	开源社区版、商业授权、源码授权
技术服务	技术咨询、架构设计、流程建模辅导、性能调优、疑难问题攻关	按项目或按人天
定制开发	基于产品源码的行业化改造、系统集成、旧系统引擎替换	定制开发合同

2.2　核心产品：驰骋低代码 BPM

驰骋低代码 BPM 是一套覆盖「流程 + 表单 + 组织 + 权限 + 门户 + 报表 + 大屏 + AI」的完整平台，包含 Java 版（JFlow） 与 .NET 版（CCFlow） 两条产品线，二者核心能力等价、流程模型同源。

产品线	技术栈	适用场景
JFlow	Java + Vue 3	技术栈为 Java 的组织、需要与 Java 中台集成的场景
CCFlow	.NET 8 / ASP.NET Core + Vue 3	技术栈为 .NET 的组织、政企信创环境

同一个流程模型，两套技术栈，客户不必为选型而重构。 这是国内 BPM 领域中极为少见的能力。

需要特别说明的是：JFlow 与 CCFlow 并非两个不同的产品 ，而是同一套流程引擎在 Java 与 .NET 两种语言下的实现。二者的流程模型、数据表结构、功能清单、二次开发接口完全一致，文档、培训与实施方法论通用。选择哪一版，只取决于贵司既有的技术栈与运维团队构成------功能上没有任何取舍。

2.3　产品能力地图

能力域	能力内容
流程引擎	线形、同表单分合流、异表单分合流、父子流程四大运行模式；发送、退回、移交、撤销、催办、加签、会签、挂起等全套操作
表单引擎	傻瓜表单、章节表单、自由表单、开发者表单、Excel 表单等多类设计器；双轨表单范式（低代码 + 高代码）
组织与权限	一人多部门多岗、连续多级主管、党政与行政双轨组织、字段级权限、行级数据权限
低代码设计器	流程设计器 V2、表单设计器、章节表单设计器、打印模板设计器、门户设计器、数据窗口设计器、可视化大屏设计器（共 7 类）
集成能力	组织集成 API、单点登录（SSO）、钉钉、企业微信、WebAPI、数据源联邦（异构库 / Dubbo / WebService）
信创适配	达梦、人大金仓（R3/R6/R8）、优炫、瀚高、南大通用 GBase，共 6 种国产数据库 + 独立国产驱动
多租户与多语言	单组织、集团、SaaS、PASS 四种运行模式；简体、繁体、英文多语言
AI 能力	自然语言生成流程节点、表单字段、从表、测试数据、前端代码；AI Copilot 对话式操作

2.4　服务对象

客户类型	典型诉求	驰骋的价值
软件公司	需要一个可靠的流程引擎内核，避免重复造轮子	源码交付 + 引擎可嵌入 + 授权成本低
企业 IT 部门	需要自主可控、能随业务变化的流程平台	全源码可控 + 深度二次开发能力
科研院所 / 高校	需要可研究、可改造的引擎源码与理论支撑	源码开放 + 面向模式的开发理论
政企单位	需要符合信创要求、能通过安全审查的流程系统	国产数据库适配 + 私有化部署 + 源码可控
制造业 / 物联网企业	需要把产线、设备、工单流转纳入统一的流程控制	流程引擎可驱动设备与系统，人机物协同、全程留痕

第三章　技术与产品优势

以下能力判断基于驰骋 BPM 引擎的实际源码（Java 版 JFlow 与 .NET 版 CCFlow 功能等价，共用同一套流程模型与数据表结构）。

3.1　优势一：流程引擎的深度与完备度

驰骋引擎的核心竞争力，在于对中国式审批场景的覆盖精度。这不是靠文档宣称，而是靠一行一行代码堆出来的完备度。

能力项	具体实现
运行模式	普通 / 合流 / 分流 / 分合流 / 同表单子线程 / 异表单子线程
会签	队列会签、协作组长会签；组长规则支持仅一个组长 / 最后一个组长主持 / 每人主持；支持加签、减签
多人处理	抢办、协作、队列、共享需申请、协作组长五种模式
退回	不可退回、退上一步、退任意节点、退指定节点、退开始节点、按流程图退回线，共 6 类；另支持「退回并原路返回」
撤销	撤销发送、撤销退回、取回、自由跳转
条件引擎	表达式条件与 SQL 条件双引擎，覆盖 16 类条件数据源
接收人规则	约 70 种投递方式：角色、部门、岗位、用户组、直属领导、连续多级主管、SQL、存储过程、表单字段、明细表行、WebAPI、智能角色等
超时处理	13 种超时策略：自动转下一步、跳指定节点、移交指定人、多级消息通知、删流程、执行 SQL、执行事件
阻塞控制	子线程未完成、约定格式、子流程、SQL、表达式、平级子流程六类阻塞模型
定时调度	Quartz + 后台服务，支持 Cron 表达式定时自动发起流程
事件模型	约 30 个流程 / 节点 / 表单生命周期挂钩点，统一拦截与重写

一句话概括：把 BPMN 里需要网关、多实例、事件子流程才能表达的复杂拓扑，压缩成业务人员看得懂的四种模式；再用一个统一的发送矩阵把全部模式调度起来。引擎的行为边界清晰，因此出错时可定位、扩展时有章法。

3.2　优势二：源码完全可控，双技术栈同源

优势	说明
源码完全可控	全量源码交付，可自主改造、可审计、可长期维护，满足政企「自主可控」的硬性要求
双技术栈同源	Java 版 JFlow 与 .NET 版 CCFlow 功能完全一致、共用同一套流程模型，客户按既有技术栈任选其一，无需为选型重构
开放 API 极丰富	二次开发接口提供数百个静态方法，调用规范统一，另有约 30 个事件钩子与回调签名验签
无侵入扩展	通过事件与重写机制扩展业务逻辑，不必修改引擎源码，升级风险可控
跨平台部署	支持 Windows / Linux / Docker，摆脱单一操作系统绑定
总体拥有成本低	开源社区版免费，商业授权与二次开发成本显著低于头部商业厂商

3.3　优势三：二十余年不重构------引擎设计的可持续性与严谨性

引擎类基础设施最贵的成本，从来不是第一次采购，而是十年之后还能不能升级。一套流程引擎一旦上线，就会承载企业数年积累的流程定义、审批数据与二次开发代码。如果一次版本升级就要客户重写流程、迁移数据、回归测试全部业务，那么此前所有的成本优势都会在那一刻归零。

这不是假设，而是国内 BPM 领域真实发生过的事情。

3.3.1　二十三年，核心表结构主键未变

驰骋工作流引擎的第一版表结构设计于 2003 年，落地在税务系统。二十三年过去，其中承载流程运转最核心的几张表，物理表名与主键定义至今保持不变：

核心表	作用	主键定义（2003 年至今未变）
WF_Flow	流程模板表	No（字符串主键）
WF_Node	流程节点表	NodeID（整数主键）
WF_GenerWorkFlow	流程实例表	WorkID（整数主键）
WF_GenerWorkerList	运行控制表（待办与办理人）	WorkID + FK_Emp + FK_Node（复合主键）

这四张表构成引擎的骨架：模板定义流程长什么样，节点定义每一步做什么，实例表记录每个流程跑到哪里，运行控制表记录每一步该谁办、办没办。骨架不变，意味着二十三年间积累的流程模板与业务数据，始终可以在同一套引擎上继续运行。

在国内 BPM 领域，能做到这一点的产品屈指可数。这不是运气，而是设计之初就确立的克制：只做加法，不做重构。

3.3.2　升级机制：版本戳 + 增量补偿 + 幂等执行

主键稳定只是前提，真正让「不重构」成立的是升级机制本身。驰骋工作流引擎内置一个自动升级程序，其工作方式可以概括为三点：

• 版本戳比对：数据库版本号记录在系统表中，程序启动时先比对数据库当前版本与引擎内置版本，版本一致则直接跳过，不做任何多余动作。
• 增量补偿：版本不一致时，按版本号顺序逐段执行升级逻辑。每一段升级都对应一个明确的历史时间点与解决的问题，改动范围可追溯、可审计------从 2013 年的视图重建，到 2020 年的组织模型与方向条件优化，再到近年持续补齐的字段与索引，全部保留在升级链路中。
• 幂等执行 ：所有升级动作都先判断「是否已经存在 / 是否已经完成」，再决定是否执行，执行后立刻回写版本戳。因此升级程序可以反复执行而无副作用；即使中途中断，重新执行也会从断点继续，不会破坏数据。

此外，引擎还支持以升级脚本文件的方式扩展升级内容。脚本按内容变更自动触发，且只需执行一次，便于在不停机、不改动主程序的前提下补充结构变更。

这套机制带来的结果是：客户无论停留在哪个历史版本，都可以一路升级到最新版本，业务流程无需重建，历史数据无需迁移，二次开发的代码绝大部分保持不变。

3.3.3　横向对照：为什么国外引擎做不到

值得深思的是，国际上几个最知名的开源流程引擎------Flowable、jBPM、Activiti------出自同一批人的设计思路，彼此之间却互不兼容。用户从 Activiti 迁到 Flowable，或从 jBPM 某一大版本升级到下一大版本，往往面临流程定义重写、表结构迁移、API 全面调整的困境。

其根因在于设计取向的差异：

对照维度	驰骋工作流引擎（JFlow）	Flowable / jBPM / Activiti
抽象层来源	自底向上，由真实项目归纳出模型	以 BPMN 规范为抽象层，以 ORM 实体为持久层
表结构稳定性	核心表主键二十三年未变	每个大版本调整表结构
跨版本升级	内置升级程序，自动增量补偿	需人工介入，常需数据迁移
客户升级成本	业务与代码基本不变	流程定义重写、接口适配
语言实现	同一模型，Java 与 .NET 两种实现功能等价	单一实现，跨语言需重新选型

结论：可持续性不是一句口号，而是设计阶段就做出的取舍。驰骋选择了「把抽象做在自己手里、把结构稳定放在第一位」，代价是早期的抽象更慢，回报是客户二十三年不必重构。

3.4　优势四：流程的宽泛性------从行政审批到物联网流程控制

提到 BPM，多数人的第一反应是「OA 审批」。这是一个长期存在的认知窄化。审批仅仅是一方面。

流程的本质，是把一件事拆成有顺序、有责任人、有判断条件、有痕迹的步骤。这个本质与行业无关：只要有「谁先做、谁后做、什么条件下走哪条路、做完之后留什么记录」的地方，流程引擎就有用武之地。行政审批、管事、管人、控制风险，只是 BPM 最常见、也最表层的一层应用。

往产业纵深走，流程引擎的价值呈阶梯式放大：

层级	应用范畴	典型场景
第一层	管事 / 管人（最常见）	行政审批、公文流转、人事任免、费用报销、合同会签、风险控制
第二层	业务过程管控	MES 制造执行、QMS 质量管理：工序流转、异常处理、变更审核、质量追溯
第三层	生产制造与自动化控制	产线协同调度、设备状态与人工决策串联、生产异常自动升级、工艺变更受控流转
第四层	物联网流程控制	传感器事件触发流程、流程驱动设备动作，人、机、物在同一引擎下协同

从第一层到第四层，引擎需要的能力是同构的------顺序、分支、并行、会签、超时、退回、条件判断、找人规则、事件钩子、全程留痕。区别只在于「谁触发流程」和「流程要驱动什么」：第一层由人发起、驱动人；第四层可能由传感器发起、驱动设备。因为抽象层次正确，同一套引擎可以横跨行政审批与物联网流程控制------这不是产品拼凑，而是模型抽象得当的必然结果。

在这方面，驰骋引擎已经进入过要求最严苛的场景。 西门子（中国）在其工业自动化与核电站控制相关业务中引入了驰骋的流程引擎能力。核电站控制对可靠性、规范性、可追溯性的要求处于工业领域的最高标准------流程的每一个步骤都必须可定义、可验证、可审计，任何一次异常都必须留下完整痕迹。能够进入这类场景，说明引擎的严谨性已经经受了天花板级别的检验。

一句话概括 ：驰骋工作流引擎是通用的流程控制底座，而非 OA 审批工具。凡是存在「有步骤、有规则、有责任、有痕迹」的地方，就是它的用武之地------无论在办公桌上，还是在生产线上。

3.5　优势五：信创适配与国产化替代能力

在国产化替代这件事上，驰骋的做法是「真适配」，而非「文档适配」：

• 单套代码覆盖 14 种以上数据库，包含 达梦、人大金仓（R3/R6/R8/R6ForMySQL）、优炫、瀚高、南大通用 GBase 8C/8A 共 6 种国产数据库；
• 国产数据库均带独立 Provider 驱动，不依赖第三方中间层；
• SQL 方言自动适配参数前缀与语法差异，应用层无感知；
• 支持本机库、异构库、WebService、Dubbo、WebAPI、本地处理程序等多种异构数据源联邦。

3.6　优势六：七类自研低代码设计器

设计器	能力
流程设计器 V2	自研，支持自动布局、右键菜单、节点快捷设置、流程校验、保存时实时检查
表单设计器	自研，支持拖拽建模、移动端预览、表单校验
章节 / 自由表单设计器	支持章节化组织复杂长表单
打印模板设计器	支持套打、RTF、Word、Excel 模板
报表设计器	基于 ECharts，14 种图表 + 列表部件 + 13 种框架
数据可视化大屏设计器	ECharts + 3D 地球 + three.js，含三维可视化部件
数据窗口设计器	图表、待办、公告、新闻轮播、天气等门户部件

配套的流程中心页面同样完备：发起、待办、在办、已完成、草稿、收藏、挂起、退回、超时、会签、抄送、任务池、催办、流程监控、异常处理，轨迹图基于流程画布实时渲染。

3.7　优势七：AI 生成式低代码

产品的 AI 能力已实现完整链路，而非停留在演示层面：

• 自然语言生成流程节点；
• 生成表单字段与从表结构；
• 生成测试数据；
• 生成前端代码；
• 智能推荐表单类型；
• 前端 AI Copilot：以自然语言对话完成发起流程、查询、打开页面；
• 设计器内嵌 AI 入口，覆盖流程、表单、测试数据、报表；
• 后端已封装通义千问（含图文）、DeepSeek、豆包及 OpenAI 兼容接口。

这是当前最能形成代际差异的方向：把「配置一个流程」从数小时压缩到一次对话。

3.8　横向对标：与国内头部 BPM 厂商的能力对照

图例：● 领先 / 优势　◐ 相当 / 主流水平　○ 相对偏弱或非主打。头部厂商为综合能力判断，驰骋 BPM 列基于源码实测。

#	评估维度	驰骋BPM	炎黄盈动	FlowPortal	泛微	微宏科技	致远互联	用友 BPM	普元 BPS	奥哲 H3
1	流程引擎成熟度	●	●	●	●	●	●	●	●	●
2	顺序/分流/合流/分合流	●	●	●	●	●	●	●	●	●
3	子流程能力	●	●	◐	●	◐	●	●	●	●
4	会签/加签/减签	●	●	●	●	●	●	●	●	●
5	退回/驳回/撤销/取回	●	●	●	●	◐	●	●	●	●
6	条件/表达式引擎	●	●	●	●	◐	●	●	●	●
7	接收人/权限规则	●	●	●	●	◐	●	●	●	●
8	超时/催办/升级	●	●	◐	●	◐	●	●	●	●
9	表单/低代码引擎	●	●	●	●	●	●	●	●	●
10	流程设计器体验	◐	●	●	●	●	●	●	●	●
11	数据可视化/大屏	●	●	○	●	◐	●	●	●	◐
12	报表/BI 深度	◐	●	◐	●	◐	●	●	●	●
13	AI 流程/表单生成	●	●	◐	●	○	●	●	◐	●
14	移动端（H5/微信/钉钉）	●	●	●	●	●	●	●	●	●
15	门户/工作台	●	●	◐	●	◐	●	●	●	●
16	组织架构/多租户	●	●	●	●	◐	●	●	●	●
17	多数据库/信创	●	●	◐	●	●	●	●	●	●
18	跨平台部署	●	◐	◐	●	◐	●	●	●	◐
19	二次开发/API 开放度	●	●	◐	◐	◐	◐	●	●	●
20	技术栈双选（.NET/Java）	●	○	○	○	○	○	◐	◐	○
21	开源与可控性	●	○	○	○	○	○	○	◐	○
22	实施方法论/服务体系	○	●	●	●	●	●	●	●	●
23	行业解决方案沉淀	○	●	●	●	●	●	●	●	●
24	生态与市场验证规模	◐	●	●	●	●	●	●	●	●
25	定价/总体拥有成本	●	○	○	○	○	○	○	●	◐

客观结论 ：驰骋 BPM 是「引擎深度 + 源码可控 + 信创适配 + AI 生成」四张牌都很硬的平台型产品，在产品能力维度上不落下风，部分细节（接收人规则、超时策略、退回方式、国产库谱系、技术栈双选）甚至更细。我们同样清楚地看到自己的短板------行业解决方案沉淀、BI 分析深度、大规模客户验证与实施服务体系，这是「产品之外」的壁垒，也是驰骋近三年重点补齐的方向。

3.9　典型适用场景

场景	推荐度	理由
政企信创国产化替代	★★★★★	6 种国产库原生支持 + 源码可控 + 跨平台
中小企业流程审批 / 协同办公	★★★★★	成本低、开箱即用、功能覆盖充分
需要深度二次开发的流程中台	★★★★★	全源码 + 数百 API + 事件钩子
技术栈为 .NET 的组织	★★★★★	国内 .NET BPM 的头部选择
需要 Java 技术栈	★★★★★	JFlow 原生 Java 实现，与 CCFlow 同源模型、功能等价
MES / QMS / 生产制造过程管控	★★★★★	流程模型同构，可直接承载工序流转、异常升级、质量追溯
自动化控制与设备协同	★★★★☆	事件钩子可对接设备与控制系统，实现受控流转与留痕
物联网流程控制	★★★★☆	传感器事件可触发流程、流程可驱动设备动作，人机物统一编排
长期演进、拒绝重构的系统	★★★★★	核心表主键二十三年未变，升级不重构业务与代码
大型集团复杂流程 + 深度 BI	★★★☆☆	引擎足够，BI / 数据治理需外部补齐
追求开箱即用的行业套件	★★★☆☆	行业解决方案沉淀弱于头部厂商

第四章　客户与案例

4.1　客户分布概览

驰骋的客户覆盖运营商、金融、能源、制造、交通、政务、军工、科研、零售等多个行业，并延伸至工业制造、自动化控制与物联网流程控制等纵深场景，既有大型央企集团与国家机关，也有区域性龙头企业和快速成长的软件公司。

4.1.1　运营商与通信服务商

海南电信、山东联通、亿阳信通（服务多家运营商）、软通动力（服务多家运营商）。

4.1.2　金融与保险

福建省保险、河南省财险、浙商银行、华夏银行、光大银行、厦门证券、周大福珠宝。

4.1.3　能源、矿业与重工

西门子、山东信发集团、临矿集团、华电国际、大庆油田、新疆天业、河北矿山、中节能、中国船舶。

4.1.4　交通、港口与基建

海南航空、天津港、宁波港、国家铁路局、广西交投、云南交投、山西交投、广西交投集团、广州市政总院、珠江委、江苏测绘院。

4.1.5　政务与科研

国家铁路局、国家海事局、国家海关、山东省国土资源厅、中国物理研究院、中国农科院、中科曙光；税务系统：临沂税务局、青海省税务局、海南省税务局、河北省税务局。

4.1.6　制造、军工与零售

中航工业、成飞集团、中汽研、欧派集团、天宇集团、星巴克、大连华信、软通动力。

以上客户清单按行业归类，具体系统名称、上线范围以合同与实施交付为准。

4.2　典型案例

4.2.1　税务系统------驰骋引擎的起点与试验田

驰骋的一切从税务系统开始。2003 年，团队在临沂税务局构建第一条审批流程；此后，同样的需求相继出现在青海省、海南省、河北省等地税务系统。这些项目的共同点是：审批事项多、规则严谨、留痕要求高、组织层级复杂，且各地在统一规范之下又各有差异。

正是在这种「同一类问题、不同地区形态」的反复实践中，团队总结、抽象、归纳出流程建模的通用方法，形成了国内第一代 BPM 引擎 的核心模型------先有项目，再有产品；先在多地验证，再做抽象归纳。引擎随后开源，填补了国内开源 BPM 的空白。可以说，税务系统是驰骋引擎的起点，也是它的试验田。

价值：税务场景对规范性、权限控制与全流程留痕的苛刻要求，奠定了驰骋引擎「严谨、可审计、可追溯」的底层基因，也使它在后续的公文、集团办公、工程管理等场景中同样适用。

4.2.2　国家铁路局------全国铁路局公文系统

国家铁路局负责全国铁路行业监督管理，公文往来覆盖部局与各地监管单位，具有发文量大、流转环节严、留痕与时效要求高的特点。项目以驰骋工作流为引擎底座，承载全国铁路局公文流转，覆盖拟稿、核稿、签发、分发、签收等标准环节，支持跨单位协同与全流程痕迹管理。

价值：国家级垂管公文场景强调「标准流程 + 全国部署」，驰骋工作流在公文类审批上成熟度高，节点权限、退回、会签、抄送等能力齐全，兼顾全国规范统一与各地办理差异。

4.2.3　国家海事局------全国海事公文系统（由中科软实施）

国家海事局承担水上交通安全监管等职责，公文与业务审批覆盖部局及全国海事系统，属于典型的垂管、广域、高可靠政务应用。项目由中科软基于驰骋工作流构建整体公文系统，全国海事局统一使用，覆盖收发文、签批、会办与归档全链路。

价值：海事公文是「全国一张网」工程，对引擎扩展性与集成商二次封装能力要求高。驰骋工作流便于集成商做行业定制，既满足全国统一规范，又能按区域、单位做权限与流程微调。

4.2.4　广西交投------覆盖 200 余家子公司的集团办公平台

广西交通投资集团是省级大型交通基础设施投资运营企业，下属子公司超过 200 家，组织纵深大、业务单元多。项目以驰骋工作流支撑集团级内部办公系统，统一待办、审批与组织权限，在集团制度框架下配置各子公司差异化流程，实现「一套平台、分级运营」。

价值：200+ 子公司场景考验的是多组织管理与流程复用能力。驰骋擅长大型集团组织建模与流程模板推广，既能保证集团管控要求落地，又允许子公司按需调整节点与表单。

4.2.5　临矿集团------行政与党政双轨组织的人力资源系统

临沂矿业集团内部同时存在行政组织体系与党政组织体系，人事任免、公文流转、考勤薪酬等业务常需按不同组织维度找人、分权、会签。传统系统往往只支持单一组织树，难以适配「一套流程、两套组织」的管理现实。项目基于驰骋工作流建设内部行政与人力资源相关流程，支持双轨组织混合建模，同一流程可按节点配置不同组织维度的审批人规则。

价值：双轨组织并存是国有能源企业的常见形态。驰骋工作流可灵活配置组织、角色与找人策略，降低为「特殊组织」单独开发的成本，保障 HR 与行政流程合规、可追溯。

4.2.6　山东信发集团------低代码 + 工作流驱动的协同办公

山东信发集团是国内大型铝业与综合能源企业集团，组织层级多、分子公司业务协同频繁。项目以驰骋低代码构建内部管理与业务应用表单，以工作流驱动请假、用印、采购、报批等协同审批，业务人员可直接参与表单与流程配置，缩短从需求到上线的周期。

价值：核心诉求是「管得住、改得快」。驰骋低代码适合快速搭建内部管理应用，工作流引擎覆盖复杂审批与组织权限，为后续业务系统扩展预留能力。

4.2.7　云南交投------交通工程管理与内部协同一体化

云南交通投资建设集团业务覆盖公路等交通基础设施投资、建设与运营，工程项目点多线长，进度、变更、验收、计量支付等环节审批链条长；同时集团内部协同办公需求密集。项目采用驰骋低代码快速搭建交通工程管理相关业务应用，并以工作流串联工程审批与内部协同，实现工程业务表单、过程管控与协同办公在同一平台沉淀。

价值：工程业务数字化与机关协同标准化双轮驱动。低代码适合工程管理类多变表单与台账，工作流适合复杂会签与多级审批。

4.2.8　广州市政总院------CRM、项目管理与业财一体化

广州市市政工程设计研究总院是市政设计与工程咨询领域的骨干单位，业务涉及客户关系维护、市政项目全周期管理及业务与财务数据贯通。项目基于驰骋低代码 + 工作流，实施客户关系管理、市政项目管理及业财一体化相关应用，以流程打通商机、立项、执行到财务结算环节。

价值：设计院的核心痛点是「项目驱动、业财协同」，驰骋二者一体，支撑从经营到交付再到财务的闭环。

4.2.9　河北矿山------集团二级管理的全员考核系统

河北矿山类集团企业人员规模大、下属单位多，全员绩效考核涉及指标分解、评分、复核、结果应用等复杂流程，且集团与二级单位权限边界清晰。项目以驰骋低代码搭建全员考核业务应用，以工作流驱动考核发起、评分、审核与结果确认，采用集团模式部署，支持二级管理员与考核人员分层授权。

价值：实现「集团管控 + 单位自治」的考核运营体系，集团定规则，二级单位管本级考核人员与过程。

4.2.10　西门子（中国）------工业自动化与核电站控制的流程引擎

西门子中国区业务系统历经多年运行，原有流程能力逐渐难以满足新的审批复杂度与集成要求。项目需要的不是推倒重来，而是在保护既有业务资产的前提下对流程引擎进行改造升级。驰骋团队提供流程引擎改造服务与整体设计方案，侧重引擎替换路径、流程建模规范与平滑迁移策略。

该项目所处的业务背景是西门子的工业自动化与核电站控制领域。这是工业界对流程能力要求最严苛的场景之一：每一个步骤都必须可定义、可验证、可审计，任何异常都必须留下完整痕迹，可靠性要求远高于常规办公类系统。

价值：跨国企业更看重「可落地的改造方案」而非产品堆砌。驰骋具备清晰的流程设计体系与可嵌入的引擎能力，能够在核电站控制这类高可靠性场景中承担流程编排职责，说明引擎的严谨性已经受住了天花板级别的检验，同样适合作为旧系统工作流现代化的技术底座。

4.2.11　周大福------全球连锁金店开店流程

周大福门店网络遍布多地，新店从选址、装修、验收、合规到开业涉及多部门、多地区协作，流程标准直接关系到品牌形象与开店效率。项目以驰骋工作流引擎支撑连锁金店开店全流程，将开店规范固化为可执行、可监控、可审计的标准流程。

价值：连锁开店的本质是「标准化复制」。驰骋擅长把复杂的跨部门开业 SOP 沉淀为引擎级流程资产，便于在不同城市与门店类型上复用和微调。

4.3　客户价值总结

能力侧重	代表客户
低代码 + 工作流（业务应用快速构建）	山东信发、云南交投、广州市政总院、河北矿山
大型集团多组织办公 / 公文	广西交投、国家铁路局、国家海事局
复杂组织（党政 / 行政混合）	临矿集团
引擎改造与方案设计	西门子（中国）
连锁标准化流程	周大福
第一代 BPM 的诞生地	临沂、青海、海南、河北税务局

第五章　服务与保障

5.1　服务内容

服务项	内容
产品交付	开源社区版下载、商业授权、源码交付与部署指导
技术咨询	流程建模、组织权限方案、信创选型、架构评审
实施支持	远程支持、现场支持、疑难问题攻关
培训赋能	开发人员二开培训、实施顾问建模培训、管理员运维培训
定制开发	基于源码的行业化改造、系统集成、旧引擎替换
版本升级	产品版本迭代、升级方案与脚本、历史数据兼容

5.2　服务方式

• 社区支持：开源社区提问、文档中心、示例代码库，长期免费；
• 商业支持：专属技术支持通道，按响应级别提供服务；
• 伙伴支持：为集成商与软件公司提供产品培训、项目护航与联合交付。

5.3　交付保障

• 源码交付：客户可获得完整源码，不受厂商锁定；
• 平滑升级：产品升级不要求重构，流程与表单支持版本并存，在途实例与新版定义互不影响；
• 无侵入扩展：业务定制通过事件与重写机制完成，升级风险可控；
• 可测试性：引擎提供流程实例测试容器，支持跳转、强制结束、移交、轨迹查看，便于上线前验证复杂流程逻辑。

第六章　发展理念与企业文化

6.1　我们为什么坚持开源

2003 年，团队在临沂税务局做第一条审批流程时，国内几乎没有可用的开源工作流引擎。企业要做流程系统，要么买昂贵的国外商业软件，要么自己从零写一套「能跑但改不动」的审批流。当同样的需求又出现在青海、海南、河北的税务系统里时，我们意识到：这不是某一个客户的问题，而是整个行业的问题。 于是我们选择了第三条路------把引擎开源出去，让整个行业少走弯路。

开源不是营销手段，而是一种产业判断：流程引擎是基础设施，基础设施越开放，生态越健康。 二十三年过去，JFlow / CCFlow 被大量软件公司嵌入自己的产品，被企业 IT 部门用来承载核心审批，被科研院所当作研究样本。这些使用者的反馈、补丁与需求，又反过来推动引擎演进。这是一笔远超商业收益的资产。

回过头看，国内第一代 BPM 引擎不是实验室里的产物，而是从一批真实的税务项目里长出来的。它带着政务系统对规范性、留痕、权限的苛刻要求出生，也因此比通用引擎更懂中国组织的实际运作方式。

6.2　我们理解的「担当」

对客户：源码交付意味着我们放弃了「锁定客户」这条最舒服的商业模式，也意味着我们必须把产品做得足够好，才配得上客户的自愿付费。

对行业：我们把「四大流程模式」「5×5 发送算法」「双轨表单范式」这些方法总结成公开文档，把二十三年的建模经验写成可学习的知识。普及开发平台架构与软件工程理论，不是口号，是我们认为一家技术公司应该还给人行业的债。

对国产化：信创不是把数据库换个牌子。我们为一个又一个国产数据库写 Provider 驱动、做方言适配、做压测验证。这件事枯燥、耗时、短期看不到收益，但它是「自主可控」真正落地的那一段最硬的路。

对员工：一支 17 人的团队能持续做二十三年引擎，靠的不是规模，是每个人都相信这件事值得做。

6.3　我们的技术观

• 引擎要可读：能被别人读懂的代码，才是能被别人信任的代码；
• 抽象要克制：把复杂留给引擎，把简单留给使用者，但不为了「优雅」而制造新的复杂；
• 边界要清晰：明确引擎不负责什么（业务逻辑、行业规则），才能把负责的部分做到极致；
• 演进要连续：升级不让客户重构，是我们对长期主义最具体的承诺。核心表主键二十三年不变、升级程序自动增量补偿，不是技术上的保守，而是对客户既有投入的尊重。

6.4　未来方向

方向	具体举措
AI 深化	从「生成」走向「生成 + 优化」：AI 检测流程冗余节点、识别审批瓶颈、预警权限冲突，并沉淀行业提示词资产
体验打磨	流程设计器交互与流程模拟预演能力，向头部厂商的体验水准看齐
数据分析	强化自助分析与第三方 BI 标准化集成，发挥可视化大屏的既有领先优势
信创加宽	补充更多国产数据库适配，完善 Linux / Docker 部署文档与自动化脚本，正式启用分布式缓存
生态建设	沉淀行业解决方案包、建立标准实施方法论、建设伙伴认证与培训体系、输出更多标杆案例
智能化组织	探索流程引擎与 AI 智能体的深度融合：设计期节点绑定智能体、运行时注入流程上下文、一个节点多个智能体协同

6.5　结语

二十三年，一家只有十几人的公司，做了一件看起来不该由小公司做的事：在流程引擎这个基础设施领域，和国内头部厂商同台，和国外老牌引擎对照，并且把源码全部交到客户手里。

我们很清楚自己的位置------产品能力不弱，生态沉淀尚浅；技术底子够硬，服务体系仍在补齐。 我们也清楚自己的选择------不去追风口，不去讲超出能力的话，只把引擎做到更深处，把国产生态做到更宽处，把客户交付做到更实处。

愿做中国软件产业中那颗可靠、开放、可托付的轮子。

------ 济南驰骋信息技术有限公司