流程建模与流程挖掘：协同提升业务效率

流程建模描述工作应如何开展，流程挖掘则根据事件数据还原实际执行情况。结合两者，您可以对比目标状态与实际执行情况，识别关键差距，并确定改进方向。一致性检查可将这种对比明确呈现。

流程管理的两个方面

流程建模和流程挖掘针对同一流程回答不同问题。建模以人员知识和设计决策为起点，流程挖掘则以记录工作情况的系统所生成的事件日志为起点。

流程建模为团队提供共同认可的流程描述。流程挖掘利用记录的事件展示案例经过的路径，包括文档中可能未体现的变化。两者不能相互取代：模型无法证明工作是否按其执行，挖掘出的数据也无法定义流程应如何运行。

流程建模能带来什么？

流程模型让工作中的决策清晰可见，便于审查。它可以帮助您：

• **建立共同语言。**当人们对交接、决策或步骤有不同看法时，流程图能提供具体的参照。
• **明确目标状态。**流程挖掘可以展示当前流程，但无法决定组织希望采用哪条路径。模型则记录这一意图。
• **制作培训和入职材料。**清晰的流程图有助于人们理解职责和顺序，无需依赖非正式说明。
• **为自动化设计提供依据。**考虑自动化某个步骤前，您需要明确它的作用、使用的信息，以及完成标准。流程建模有助于清楚记录这些决策。

流程建模方法从非正式草图到结构化的BPMN流程图不等。细节程度应根据受众和模型需要支持的决策来确定。当团队需要精确、统一的符号规范时，BPMN 2.0提供了表示顺序流的标准方式。

流程挖掘能带来什么？

流程挖掘利用事件数据还原流程执行情况，通常包括案例标识、活动和时间戳。它可以展示：

• **案例实际经过的路径。**查看记录的顺序，包括跳过步骤、返回前序步骤或需要返工的案例。
• **流程变体。**比较案例实际经过的不同路径，而不是假设所有案例都遵循文档中的流程。
• **瓶颈和等待时间。**衡量活动之间的耗时，了解案例在哪些环节等待。
• **用于比较的证据。**建立预期流程模型后，您可以检查实际执行记录与模型之间的差异。

流程挖掘不会判断偏差是否错误，而是提供调查所需的证据。您可以结合流程知识和模型，解读数据所展示的情况。

流程模型与实际执行的差距，以及由此产生的成本

文档记录的流程可能与人员和系统实际执行的流程不同。如果团队依据过时的模型规划人员配置、流程变更或自动化，可能会把精力放在实际并未按预期发生的工作上。与此同时，变通做法和返工也可能一直未被发现。

常见差异包括：

• **模型中有、实际未执行的步骤。**例如，计划中的审核在实际操作中可能被跳过。未核实执行情况就据此设计，可能导致错误的变更。
• **实际存在、模型中没有的步骤。**某种变通做法可能已成为惯例，却没有记录，也没有明确负责人。
• **模型未体现的返工循环。**流程图可能显示一条直接路径，而事件数据却显示案例会返回到较早的活动。
• **交接缓慢。**模型可以标明责任在哪个环节发生转移，流程挖掘则能衡量案例在该环节等待了多久。

仅靠建模无法判断文档记录的流程是否符合实际执行情况。仅靠流程挖掘也无法判断观察到的行为是否合理。因此，比较两者之间的差异很重要。

两者如何协同工作

改进循环将预期流程与实际执行证据联系起来。以下以发票审批流程为例，分三个步骤说明：

1. **挖掘当前流程。**利用事件数据查看发票经过哪些路径、各活动之间等待多久，以及哪些案例会因需要更正而返回。这样您看到的是当前的实际执行情况，而不只是文档记录的路径。
2. **建模目标状态。**明确希望采用的审批步骤、决策点和交接方式，并将目标状态记录在流程模型中，为团队提供清晰的参照。
3. **进行一致性检查。**将模型与已记录的案例进行比较，查看哪些发票跳过了审批、步骤顺序不同或走了意料之外的路径。判断每项差异是执行问题、模型应允许的例外，还是需要重新审视的目标状态。

然后根据发现修订流程或模型，并在获得新证据后再次比较。这个循环并不意味着所有偏差都应消除，而是为您提供一种有条理的方法，判断哪些差异值得关注。

如果您还不清楚流程中哪些部分需要关注，可以先从流程挖掘入手。如果已有共识明确的目标状态需要核查，可以先从建模入手。无论从哪一步开始，都应把首次建模或分析视为起点，并随着认识加深持续更新。

先在一个流程上进行初步分析，看看事件数据能揭示哪些情况。

一致性检查：两者的交汇点

一致性检查会将预期流程模型与已记录的执行情况进行比较，并突出显示跳过活动、顺序不同或模型中某条路径未实际出现的案例。

发现差异意味着需要调查，并不代表流程一定有缺陷。流程可能允许合理的例外，模型可能不完整，事件数据也可能未记录相关活动。请先明确流程和模型的范围，再与了解实际工作的人员一起审查发现。

查看ProcessMind中的一致性检查原理。如需了解各案例遵循的不同路径，请参阅流程变体。

传统做法的利弊

将流程模型和流程挖掘结果分别放在不同工具中，适合已有成熟建模或分析工作流的团队。每种工具都能发挥特定作用，团队也可以根据需要选择合适的建模符号和分析环境。

代价是需要额外投入精力将两者衔接起来。您可能需要导出模型、整理分析结果、统一活动名称，并手动核对版本。如果比较过程过于费力，团队可能只在项目中做一次，之后便不再重复。模型和证据也会再次脱节。

如果您有可靠的方法保持模型与数据一致、明确的责任归属，以及团队会遵循的审查流程，分开使用工具仍然可行。关键在于，流程发生变化时，团队能否重复进行比较。

流程建模实用指南

实用的流程建模指南应从模型需要支持哪些决策入手。开始绘制前，先明确流程边界、模型的使用者，以及他们需要的细节程度。

1. **明确范围。**选择一个起点和终点清晰的流程。订单到收款等范围较广的业务流程，可能需要先拆分成更小的流程，才能有效建模。
2. **选择合适的细节层级。**让流程图聚焦于一个层级。将高层阶段与详细的系统操作混在一起，会让流程难以理解。
3. **使用熟悉的名称。**使用团队日常采用的语言命名活动和角色。清晰的标签便于审查模型，也更容易与事件数据进行比较。
4. **先展示主路径，再补充例外。**先让预期流程清晰易读，再添加较少见的路径。纳入会影响决策或责任归属的例外情况。
5. **明确责任归属并记录模型版本。**指定人员负责审查，并留存变更记录。没有负责人或历史记录，就更难判断模型是否仍然有效。
6. **设定审查周期。**在流程发生变化时，以及约定的审查时间点，重新检查模型。无人维护的流程图最终会失去团队的信任。

符号规范只是工作的一部分。了解BPMN 2.0中的符号和惯例。如需在ProcessMind中记录流程，请参阅BPMN建模概览。如需全面了解流程映射方法，请阅读流程映射相关内容。

将改进循环融入持续改进

随着流程变化不断重复这一循环，才能发挥它的作用。每轮都应明确负责人和需要回答的具体问题。例如，您可以调查长时间等待的原因、检查某项变更是否影响案例路径，或审查模型是否仍反映目标状态。

让审查聚焦于实际问题：

• **针对具体问题进行变更。**一次处理一个明确的问题，不要试图同时重新设计整个流程。
• **核查证据。**使用流程挖掘审查已记录的执行情况，并在适当时通过流程模拟探索可能的情景。
• **更新模型。**如果目标状态发生变化，请修订模型，使其继续发挥参照作用。
• **审查例外。**判断偏差属于可接受的路径、数据问题，还是需要处理的问题。

如需了解结构化的改进周期，请参阅数据驱动流程改进指南。

ProcessMind如何融入流程管理

ProcessMind将流程建模与流程挖掘整合在一个平台中。您可以记录目标状态、分析已记录的执行情况，并直接比较两者，无需在不同工具之间手动交接。您还可以使用流程模拟探索不同情景。

将模型与分析放在一起，有助于重复进行比较。但平台不会替您判断哪些偏差值得关注，也不会替您变更流程。团队仍需负责解读证据，并决定下一步行动。

如需先了解流程挖掘，请阅读流程挖掘是什么。如需了解两者如何在ProcessMind中结合，请参阅BPMN建模和流程挖掘。

从一个流程开始，形成改进闭环

选择一个流程，挖掘其当前执行情况，建立目标状态模型，并与了解实际工作的人员一起审查差异。您可以先在试用版中完成这一轮分析。