什么是BPMS？业务流程管理系统解析
BPMS用于建模并执行已定义的流程。本文介绍它的五个组成部分、能力边界，以及流程知识为何比执行更重要。
BPMS（业务流程管理系统）用于对既定流程建模、执行并监控运行情况。它擅长推动流程执行：按既定顺序推进步骤、分派任务并记录结果。但它只能处理和报告交由系统执行的工作，难以呈现全局情况。
本指南将介绍BPMS的作用、您实际购买的五个组成部分，以及它的能力边界。随后，我们会比较执行软件与流程智能。后者有意将执行工作交给众多擅长此道的系统，再将这些系统的数据汇集到人员和AI都能使用的统一平台。
BPMS是什么意思？
BPMS是Business Process Management System（业务流程管理系统）的缩写。有些厂商使用Business Process Management Suite（业务流程管理套件）这一名称。无论采用哪种说法，这类软件都用于定义流程、分派工作并监控流程执行。
BPM，即业务流程管理，是理解、设计、衡量和改进工作方式的一门管理学科。BPMS是可用于支持这项工作的软件之一。您可以在不购买BPMS的情况下实践BPM；购买BPMS也不能保证您能有效管理流程。
这一产品类别随着时间不断演变。它起初是工作流引擎，后来发展为加入建模、表单和监控功能的套件，如今还包括团队可用来组装完整流程应用的低代码平台。正因如此，不同厂商对BPMS的定义各不相同。评估业务流程管理软件时，不要只看产品标签，请关注四个关键问题：它能否对流程建模、执行流程、连接相关系统，以及展示流程实例的运行情况？
BPMS由哪五个部分组成？
不同产品整合这些功能的方式各异，但业务流程管理系统通常包含五个部分：
- **建模工具。**您可以使用建模工具定义流程，通常采用BPMN 2.0。模型可以描述流程；在可执行系统中，还可作为运行流程的基础。了解流程模型设计，请参阅BPMN建模工具。
- **执行引擎。**引擎会创建流程实例、评估条件、分派任务、启动计时器，并升级处理逾期工作。
- **表单、规则和角色。**这些功能决定人员需要提供哪些信息、能看到哪些任务，以及下一步适用哪些规则。
- **集成。**系统会与ERP和CRM等应用程序、数据仓库及API网关交换数据。集成工作可能占据实施过程的很大一部分。
- **监控和存储库。**仪表板会展示运行中流程实例的状态。存储库则有助于管理流程版本和控制变更。
工作流引擎只是其中一个组成部分。BPMS还整合了定义、支持和监控更广泛流程所需的工具与控制机制。
BPMS能做什么，而流程文档做不到？
流程文档描述工作应如何开展。BPMS则能根据已配置的规则分派和跟踪工作。例如，它可以：
- 将等待时间超过设定时限的任务升级处理。
- 当流程实例达到设定条件时，将其提交审批。
- 记录每个流程实例经过的路径。
- 通过配置更新工作流，无需修改多个相关应用程序。
当您需要确保工作按统一规则分派、明确责任归属，并了解系统运行的流程实例时，这些功能很有用。但这并不意味着真实流程的每个环节都会在BPMS中发生。如果您主要需要记录流程或了解当前的运行情况，执行软件未必是合适的第一步。
BPMS、工作流引擎、RPA、流程挖掘和流程智能有何区别？
这五类技术分别解决流程管理中的不同问题。下表列出了各自的作用，以及它们能帮助您回答的问题。
| 技术 | 执行工作 | 观察工作 | 改变流程 | 常见问题 |
|---|---|---|---|---|
| 工作流引擎 | 是 | 部分支持，仅限其运行的工作流 | 是，仅限已定义的工作流 | 如何将这个案例从一个步骤推进到下一个步骤？ |
| BPMS | 是 | 是，仅限其运行的流程实例 | 是 | 如何运行和管理这个流程？ |
| RPA | 是，通过模拟人员操作用户界面 | 否 | 否，只自动化现有流程中的步骤 | 如何自动化重复的手动步骤？ |
| 流程挖掘 | 否 | 是，使用事件日志 | 否，为流程变更提供依据 | 实际发生了什么？与预期流程相比，差异在哪里？ |
| 流程智能 | 否，将执行工作交给执行系统 | 是，覆盖所有留有记录的系统 | 否，为变更提供依据并保持模型更新 | 整个流程如何跨系统运行？模型在哪些地方已与实际情况不符？ |
RPA和BPMS采取不同方式改进流程。RPA会自动化现有流程中的任务；BPMS运行您定义的流程，可能会改变工作分派方式。自动化某项任务前，请先确认重新设计流程能否直接省去这项任务。了解更多，请参阅利用流程挖掘发现自动化机会。
流程挖掘和BPMS回答的问题也不相同。流程挖掘分析事件数据，展示工作在各系统中的实际流转情况；BPMS则执行设计好的工作流，并报告自身处理的流程实例。当您需要确认模型是否符合实际工作时，这一区别很重要。
流程智能是表格中的最后一项，也是连接其他技术的一环。它将执行工作交给最适合的系统，读取各系统留下的记录，并维护一个可供所有系统对照的流程模型。BPMS报告自身的流程实例；流程智能则呈现整个流程，包括没有任何单一平台负责运行的工作。
为什么一个BPMS无法运行所有流程？
在您盘点BPMS无法管理的系统之前，它似乎能解决流程管理问题。真实流程往往横跨ERP、CRM、工单工具、供应商门户、电子表格和多个收件箱。平台只能运行其中建模进平台的部分，其余工作仍在其他地方继续。
购买前值得了解，这种差距会带来三个后果。
**您会不断定制工作流，而不是复用标准。**BPMS是一套工具，因此每个流程都可能变成一个项目：您需要建模自己的变体、命名自己的步骤，并维护自己的工作流版本，而成千上万家组织也在运行类似流程。订单到收款、采购到付款或事件管理等行业标准参考模型，往往要在每个平台中重新构建，而非直接复用；甚至同一系统中的两个部门，也可能各自维护同一流程的不同版本。
**以执行为先的平台容易忽略整体情况。**BPMS的评价依据是它运行了什么，因此资源和预算会流向平台内部的工作流。它无法运行的流程，尤其是跨团队、系统和国家的流程，往往无人负责。加快系统执行速度，并不等于理解组织的整体运作方式。
**BPMS的能力始终有限，也会不断积累例外情况。**每个流程都有例外：紧急订单、VIP客户，或只接受电子邮件的供应商。在BPMS中，每种例外都可能变成一个额外分支、一张额外表单、一项额外集成，以及一条需要维护的额外工作流。原本用于规范工作的系统，逐渐塞满只有内部团队才了解的特殊情况。
这并不意味着BPMS不好用，而是说它不适合作为流程的唯一权威来源。
在IT业务流程管理中，这种差距尤为明显：一项工作可能涉及工单队列、变更日历和多个应用程序，而任何单一业务流程软件都无法同时查看这三者。
您应该先了解哪些流程问题？
Before you choose a BPMS, a workflow engine or a measurement platform, agree on what you need to know about the process itself.
- Which systems record a step in this process, and which steps leave no record anywhere?
- Where does work wait, and where does it change hands between teams?
- Which variations happen often, and what causes them?
- Which steps need human judgment, and which only exist because two systems do not connect?
这些问题关注的是流程本身，而非某款产品。因此，大多数问题都可以通过系统已有的记录以及实际执行工作的人员来解答。
这些问题也能反映BPMS实际负责了多少流程。如果五个系统中有三个位于平台之外，BPMS就只能妥善运行部分工作，却无法完整报告其余情况。什么是流程挖掘将介绍如何利用事件数据还原这些工作路径。
使用率很低的BPMS还值得保留吗？
许多组织购买BPMS是为了使用执行引擎，最终却从未真正用起来。部署时间超出预期，初期工作流由合作伙伴配置，业务团队则继续使用原有系统。最后只剩下一款有许可的建模工具，少数人偶尔打开它绘制流程图，却还要为从未启动的运行时环境支付维护费用。
现在正是把平台捆绑在一起的两项工作分开的时候。工作流引擎原本用于执行工作，模型库则用于保存流程知识。如果平台只发挥了第二项作用，您付费购买的执行平台就成了文档工具。这种记录流程的方式既笨重，又技术复杂，成本也高。
您的BPMS是否在承担购买时未曾考虑的工作？
- The workflow engine has not run a process in production this year.
- The models are kept by one team, and nobody outside it reads them.
- Every change to a diagram travels with the runtime, so documentation waits for a release.
- The processes you most need to understand cross systems the platform does not connect.
- The licence is renewed for the modelling features, not for the execution.
如果大多数情况都符合，说明您正在让执行平台承担它从未为之设计的知识管理工作。解决办法不是增加运行时功能，而是把知识转移到专门的枢纽工具中：在一个地方管理所有流程，连接各系统的数据，让相关人员和AI助手都能查阅，而且无需维护运行时环境。
让BPMS继续执行它真正负责的流程。把流程知识转移到不受发布周期限制、能够持续完善的地方。
流程智能与BPMS有何不同？
A BPMS
- Runs a process you define, and enforces the sequence
- Builds a custom workflow for every process, inside one platform
- Reports on the instances the platform itself handles
- Keeps its models executable, so they serve the runtime
- Sees only the systems it has been integrated with
Process intelligence
- Leaves execution to whichever system does it best
- Connects the data from every system into one process model
- Shows how work really flows, including paths no system was designed to run
- Keeps process knowledge in one place for people and AI to use
- Grounds every model in mined reality instead of a workshop's memory
这是有意为之，并非缺少功能。流程智能不负责执行，因为执行工具有很多，而您恰好拥有的平台很少是最佳选择。RPA、AI智能体、工作流管理系统、ERP自带的工作流，以及直接完成工作的团队，各自在不同场景中更合适。执行工作所用的工具，应只根据执行需求来选择。
但流程知识不能分散在五个系统中。如果每个执行工具都保留一份自己的流程图，就没人能说清流程究竟是什么、客户实际经历了哪种流程变体，或下一步该自动化什么。集中管理流程知识，让执行工作的人员和正在接入流程的AI助手都能使用，比亲自执行工作更重要。
数据优势也由此而来。BPMS只能报告自身实例的数据；流程智能平台则能连接各系统的事件数据，呈现BPMS未能覆盖的工作。它还可以维护一份统一模型，供BPMS、ERP和自动化工具共同对照。
为什么需要流程挖掘，让模型反映实际情况？
BPMS可以报告在其中运行的实例，但这不代表它记录了人们完成流程时走过的所有路径。常见的遗漏有三种：
- **工作在引擎之外进行。**有人通过电子邮件处理异常，之后才更新系统。实例看起来可能符合要求，但实际耗时比模型显示的更长。
- **同一结果也可能通过其他系统实现。**团队可能使用ERP系统、电子表格或供应商门户。如果这些工作没有进入BPMS，其仪表板就无法呈现完整流程。
- **模型逐渐落后于实际情况。**流程发布时可能准确无误，之后团队采用本地变体，实际流程便逐渐偏离模型。如果更新模型需要耗费时间，这些变体就可能长期存在。
结果是，模型管理得井井有条，却已无法反映人们的实际工作方式。流程挖掘可以让模型重新贴近实际：它读取系统已记录的事件数据，还原实际运行路径，包括未被建模的路径。
一致性检查将流程模型与事件数据进行比较，指出执行情况与设计之间的差异；流程挖掘则从您自己的记录中呈现流程变体、延误和返工。为什么流程建模与流程挖掘应相辅相成将说明为什么不应把流程意图与实际结果这两方面割裂开来。
为什么我们决定不开发执行功能？
对于流程平台来说，这是个合理的问题：既然可以建模并查看流程运行情况，为什么不直接执行流程？BPMS的存在，正是因为这个问题的答案显而易见：可以。我们选择了另一条路，这是经过考虑的决定，并非遗漏。
我们选择不开发执行引擎，因为执行工具应当择优选用。RPA、AI智能体、工作流管理系统和ERP自带的工作流，各自在不同场景中更合适；负责执行工作的团队应当掌控运行时环境。我们的职责是提供一个统筹层：记录流程、跨系统监控流程、连接数据，并维护一份全组织都能信赖的模型。这样做是为了让任何人都不必把流程迁移到我们的平台，才能了解流程。
实际使用中，ProcessMind从不要求您交出工作流的控制权。您现有的系统继续执行工作，而有关执行内容的知识则集中管理并保持更新。即使您之后更换执行工具，例如用AI智能体替代RPA机器人，或用新工作流替代旧工作流，模型、历史记录和测量数据仍会保留在原处。我们为何创建ProcessMind进一步说明了背后的考量。
ProcessMind如何与BPMS配合使用？
ProcessMind不是BPMS，也不执行工作。BPMS、ERP或自动化平台仍负责运行流程，这正是我们的设计初衷：为每个流程保留最合适的执行工具，并在一个地方集中管理所有流程的知识。
| BPMS | 工作流引擎 | RPA | 流程挖掘 | 流程智能 | |
|---|---|---|---|---|---|
| 变更 | 流程设计与执行 | 任务分配与审批 | 用户界面操作 | 了解实际流程 | 决策与改进 |
| 所需输入 | 模型、规则、表单和集成 | 工作流定义和业务规则 | 稳定、重复的任务和界面访问 | 包含案例ID和时间戳的事件日志 | 事件数据、模型、KPI和上下文 |
| 负责方 | 流程负责人和运营团队 | IT和工作流团队 | 自动化和RPA团队 | 流程分析师和数据团队 | 运营和转型管理者 |
实际应用中，流程智能可以：
- **构建之前：**挖掘相关系统中的事件数据，了解实际路径、流程变体和异常情况。使用BPMN 2.0对目标流程建模，再通过流程模拟测试变更，然后再配置工作流。
- **构建之后：**继续进行流程挖掘，了解执行情况是否仍符合设计，以及本地变通做法是否已悄然成为所有人遵循的流程。
BPMS负责执行工作。流程智能帮助判断哪些工作值得执行，并检查结果是否符合人们实际遵循的流程。
何时应选择BPMS、RPA或流程智能？
合适的起点取决于您已掌握的信息和要解决的问题。
以下情况可从流程智能入手：
- 人们对当前流程的实际运作方式看法不一。
- 流程涉及多个系统，部分工作可能在主要工作流之外进行。
- 您知道流程速度慢，却不清楚原因。
- 您拥有一套闲置工作流引擎的BPMS，希望将流程知识保存在更有用的地方。
以下情况可考虑BPMS：
- 流程已得到充分理解，且足够稳定，可以进行标准化。
- 工作涉及多个团队，需要更清晰地分配交接任务或明确责任归属。
- 您需要执行规则并管理变更，同时避免逐一修改多个应用程序。
以下情况可考虑RPA：
- 流程稳定且重复性高。
- 任务发生频率足够高，值得自动化。
- 应用程序无法更改，但可以通过其界面自动执行相关步骤。
两条原则有助于把握顺序：购买执行软件前先衡量流程；自动化任务前先确认重新设计流程是否能将其消除。
购买前如何评估BPMS？
先选定一个名称明确、负责人清楚的流程，例如订单到收款、采购到付款、员工入职或事件处理。不要只说“运营”等宽泛领域，却不说明具体指哪个流程。然后按以下四个步骤进行评估。
-
查找事件数据
确认哪些系统记录了该流程，以及记录中是否包含案例标识、活动和时间戳。业务流程管理工具描述的是您计划的流程，而事件日志能证明流程实际如何运行。
-
对比设计与实际执行情况
找出模型未呈现的路径、延误和异常情况。使用您自己的数据测试最合适的BPMS候选方案，比查看功能列表更有参考价值，因为这样能看出它实际负责流程的哪些部分。
-
根据证据决定下一步
合适的方案可能是BPMS、流程重新设计、调整某个步骤，也可能什么都不需要。根据发现选择工具，而不是反过来。
-
构建后继续衡量
平台可以报告它所执行的任务。工作流上线后，来自各系统的事件数据能帮助您判断流程是否仍符合实际工作情况。
如果流程涉及BPMS无法连接的系统，初步测量就会揭示这一点。只有了解这些差异，才值得决定是否购买执行工具。
Where to Go From Here
You have the category clear and a way to separate execution from knowledge. The next move is to see the process your own systems already describe.
