流程建模：哪种方法适用于何处——以及每种图表的边界在哪里

一个流程模型很快画好，但几乎同样快就变得无用。并不是因为它错了——方框大多是对的。而是因为它没有回答制作它时要解决的问题。人们画图是为了知道从哪里着手，但交付的通常是一个看起来每一步都同等重要的结构。

本文因此站在两条腿上。第一是技艺：哪种方法适合做什么，需要哪些符号，如何确定划分以及按什么顺序进行。第二是界限：四个在任何记法中都不会出现、没有它们就无法判断哪个步骤阻塞流程的数据。

什么是流程建模？

流程建模是用标准化符号对单个业务流程进行图形化表示。它回答四个问题：是什么触发了流程？哪些任务按什么顺序发生？哪里发生分支、谁来决策？流程以什么结束？

日常中这些术语常被混用，但含义不同：

流程地图是城市地图，流程模型是某条道路的行走路线。把两者强行合并会得到一张含有两百个方框的地图，演示结束后没人再打开。如何制作上一级的地图，见流程地图制作指南。

模型的用途：

• 入职：新员工能看流程而不是被口述
• 审计与认证：ISO 9001 本身要求这种结构
• 系统切换：在软件映射之前需要先把要映射的东西画出来
• 移交点：流程责任发生转移的节点
• 异常：那些每个人都以不同方式处理、文档中找不到的情况

模型不适用的场景：

• 优先级判断。所有方框看起来一样大。
• 工作量估算。一个步骤可能是十分钟也可能是四天。
• 能力（产能）规划。流程运行频率不在图中体现。

As-is 和 To-be：先画出存在的情况

流程建模有两种模型。As-is 模型展示现状：流程今天实际上是如何运作的，包括绕行、返工以及名义上不存在但实际使用的 Excel 文件。To-be 模型展示变更后的目标状态。

顺序不可协商：先 As-is，再 To-be。从目标开始会对一个并不熟悉的流程进行优化。

不过多数指南忽略了介于二者之间的第三步：测量。直接从 As-is 得到的 To-be 只是一个愿望清单。它会优化研讨会上讨论声量最大的步骤——而那通常不是阻塞流程的步骤。声音大的通常是令人不快的步骤，昂贵的却是安静的、导致积压的地方。

实用规则：To-be 模型应针对恰好一个步骤构建，且必须是测量所指出的那个步骤。其他部分暂时保持不变。

流程建模：方法一览

流程图

最简单的形式：开始、任务、决策的菱形、结束。任何人无需培训即可理解，这正是其价值所在。但当涉及多角色时，问题出现——职责仅作为方框内的文本出现，而导致时间损失的移交点则消失。

泳道图

相同流程，但每个角色有一条泳道。收益不是美观，而是明确：**每一条离开泳道的箭头都是一次移交。**移交是流程中容易积压的地方，因为可能没有人继续负责，也没人开始处理。对于跨部门流程，泳道是正确的标准选择。

BPMN 2.0

Object Management Group 制定的国际标准，约 150 个符号，机器可读。强项是明确性：BPMN 模型可以导出、校验并由流程引擎执行。弱点是学习曲线——业务人员很少自愿去读它。

当模型需要被执行、外部审查或长期维护时使用 BPMN。不要为了面子去用。一个由相关部门复核的整洁泳道图，往往比无人打开的正确 BPMN 更有价值。

EPK 与 eEPK

事件驱动流程链在事件（“收到请求”）和功能（“记录请求”）间严格交替，并通过 AND、OR、XOR 连接。在德语区因 ARIS 而普及。扩展 EPK 在每个功能旁补充组织单元与信息对象——也就是谁执行该步骤以及用什么执行。

强制交替既是优点也是缺点：它迫使写出触发条件，但也会让模型更长。适合组织内部已有 EPK 资产的情况。对于全新模型很少有必要。

SIPOC

五列：Suppliers、Inputs、Process、Outputs、Customers。它不是流程图，而是建模前的边界划定。一个小时内能填好，解决大多数建模失败的问题：流程从哪里开始到哪里结束？流程部分通常很粗略——五到七个方块。

价值流分析

来自精益管理。绘制物料与信息流，并在每一步填写数值：处理时间、等待时间、在制品、缺陷率。因此它是经典方法中唯一自带定量信息的方法。适用于生产；在办公室流程中“在制品”是收件箱等待队列，使得工作量增加但并非不可能。

价值链与详细模型

同一尺度的两端。价值链展示五到九个不展开内部的块——面向管理层与外部。详细模型则展示每一步含子流程、异常与系统——用于交付给 IT。两者都合理。但在同一图中同时出现两种细节等级时就无用：比如给半个销售部门三个方框，随后给审批流程画十四个方框。

选用哪种方法？三道问题

1. 是否涉及多个角色或部门？ 是 → 泳道。 否 → 流程图。
2. 之后是否需要执行、导出或外部审查模型？ 是 → BPMN 2.0。
3. 是否关乎物料、库存或等待时间？ 是 → 价值流分析。

如果边界尚不清晰，先做 SIPOC。其他选择多属偏好——而偏好在记法问题上是糟糕的向导，因为模型由不会分享此偏好的人来阅读。

流程建模符号

常用符号来自流程图传统，在所有工具中大同小异：

• 椭圆（终结符）： 流程的开始与结束
• 矩形： 一个任务或活动
• 菱形： 决策，带标注的出口
• 箭头： 流向
• 双侧线矩形： 子流程，在别处建模
• 平行四边形： 数据输入或输出
• 下缘波浪的矩形： 文档
• D 形： 延迟，即等待时间
• 上边倾斜的矩形： 手工输入——在实践中这是媒介断裂最可靠的迹象

在 BPMN 中，最重要的五个是：起始事件（细圆）、任务（圆角矩形）、互斥网关（带 X 的菱形）、顺序流（实线箭头）、结束事件（粗圆）。这些足以表示大多数流程。

两条规则比任何符号表更重要：每个菱形的出口都要标注——“是/否”或条件。以及：**每条路径都要终止。**一个通向空白的分支在图上是美观缺陷，在现实中是永远无法完成的流程。

建模流程：六个步骤

步骤 1：设定边界

在开始绘制之前，用两句话写清楚：流程以什么开始（触发）和以什么结束（结果）？如果缺失，模型会在制作过程中不断膨胀——每次讨论都会在前后添东西。这是为什么本应两天完成的建模会拖到三周的常见原因。

步骤 2：向执行者收集步骤

不要只问负责人。负责人知道目标流程，而您要找的正是与现状的差异。五个问题可靠揭示那些程序文件中没有写明的细节：

• 是什么触发这个工作，您如何识别？
• 开始工作您需要什么，这些来自哪里？
• 您最常等待什么？
• 如果缺少某物或系统失灵您怎么办？
• 您在这里与程序不同的做法是什么——为什么？

步骤 3：确定颗粒度

决定划分的规则：**一个步骤是一段由同一角色在同一系统中一次性完成的工作。**角色变了、系统变了或工作被中断，则开始新步骤。

对普通业务流程而言通常得到八到十五个步骤。若得到五十个，您正在建按键击的模型；若只有四个，您正在建部门级别的模型。

步骤 4：绘制

按前三个问题选定的方法绘制，然后做第一次不含异常的流程：从左到右的正常路径。随后再加分支——但不是全部。一个流程通常约三分之一是例外；只建模两到三个最常见的例外，剩余以文字形式标注。

步骤 5：让人复核

将完成的图交回步骤 2 中的同一批人，问一个问题：“哪里不对？”不是“这样可以吗？”——那样人人都会答“可以”。实践中复核会改正两到四处问题，至少有一处不是小问题。

步骤 6：附上数值

多数指南缺少这一步，没有它模型只是装饰。每个步骤至少填写四个数值，必要时估算：

• 时长区间： 乐观、典型、悲观——不要平均值
• 之前的等待时间： 在有人开始前该步骤在队列中等多久
• 频率： 每月执行次数及异常所占比例
• 角色与系统，以及是否发生媒介断裂

为什么用区间而不是平均值：在包含门、循环或多名处理者的流程中使用平均值会系统性地产生过于乐观的估算。详见您的 Excel 计算正确却仍然错。

示例：一个报价流程的建模

下列模型来自我们的示例分析 AN-2026-01。这是构建的示例，并非客户现场采集——结构源自典型中型企业流程，数值来自 500 次运行的模拟。就要点而言足够：图与测量之间的差异是方法的属性，不是商业机密。

作为泳道图，六个步骤，四个角色：

                 ┌────────────┐                              ┌──────────────┐
Innendienst   ●──│ 01 Anfrage │                              │ 05 Angebot   │──▶ ● 
                 │  erfassen  │                              │   schreiben  │
                 └─────┬──────┘                              └──────▲───────┘
                       │                                            │
                 ┌─────▼──────┐                                     │
Konstruktion     │ 02 Techn.  │                                     │
                 │  Klärung   │                                     │
                 └─────┬──────┘                                     │
                       │                                            │
                 ┌─────▼──────┐   ┌───────────┐   nein     ┌────────┴────┐
Kalkulation      │ 03 Kalku-  │──▶│ 04 Frei-  │───────────▶│ Rückfrage   │
                 │   lation   │   │   gabe?   │            │ (Ausnahme)  │
                 └────────────┘   └─────┬─────┘            └─────────────┘
                                        │ ja
                                        ▼
Vertrieb                          06 Versand & Nachfassen ──▶ ●

图是正确的。它回答了谁在什么顺序做什么，并显示了三个媒介断裂（电子邮件、Excel、Word）。但它没有回答：在这六个步骤中哪个会阻塞流程？

图上看六个步骤大小相同，但计算结果并非如此：

{
  "caption": "Auslastung je Rolle im Ist-Zustand. Musteranalyse AN-2026-01, konstruiert, 500 simulierte Durchläufe",
  "unit": "%",
  "data": [
    { "label": "Konstruktion", "value": 118, "tone": "critical" },
    { "label": "Kalkulation", "value": 86 },
    { "label": "Vertriebsinnendienst", "value": 74 },
    { "label": "Vertriebsleitung", "value": 41 }
  ]
}

某个角色的负载超过 100％——它收到的工作超过其可处理量，因此在其步骤之前会形成等待队列。模型把这个角色显示为四条泳道之一，与仅 41％ 负载的销售主管平起平坐。

相应地，通过时间不是单一数值而是一个区间：

[
  { "label": "Durchlaufzeit P10", "value": "1,8", "unit": "Tage", "note": "der schnelle Fall" },
  { "label": "Durchlaufzeit P50", "value": "4,6", "unit": "Tage", "note": "der typische Fall" },
  { "label": "Durchlaufzeit P90", "value": "11,2", "unit": "Tage", "tone": "critical", "note": "was zusagbar wäre" },
  { "label": "Läufe über Kapazität", "value": "34", "unit": "%", "tone": "critical" }
]

典型情况与可承诺情况之间相差两倍。在任何记法的图中都看不到这种差异。完整的示例分析及前后对比见停留在工程环节的报价流程。

四个在任何记法中都没有的数值

没有任何模型能直接指出瓶颈，有个务实的原因：记法描述的是结构，不是负载。要进行计算，需要四个在 BPMN、EPK 或泳道图里不会出现的量：

1. 到达率——流程被触发的频率以及其不均匀性。每周四十个请求不同于每周四十个且其中三十个集中在周一的情况。
2. 时长的分布（波动）——不是“两小时”，而是“1 到 4 小时，通常为 2 小时”。没有波动就没有队列，计算会过于乐观。
3. 产能——有多少人能处理该步骤以及他们可支配的工作时间。图中的泳道可能代表一个人，也可能代表八个人。
4. 日历——工作时间、休假、仅在周二发生的审批等。按计算看似三小时的流程，因过夜仍可能需要一天。

最好在建模过程中直接在步骤 6 收集这四项数据。它们是从图转向计算的桥梁——也是决定模型会成为可行措施还是墙上装饰的关键点。

常见错误

1. 过于细化。 为一个流程画两百个方框。补救：采用步骤 3 的规则——角色、系统、一次性完成。

2. 画的是目标而非现状。 特征是模型中没有返工。真实流程总有返工。

3. 只与管理层沟通。 通常只得到官方流程，而实际差异才是这项工作的收获。

4. 出于面子选择记法。 用 BPMN 因为看起来专业，但因此无人复核——没有人复核的模型只是一个主张。

5. 忽略异常。 画出正常情况，但 30％ 的流程以不同方式运行。应将两到三种常见异常放入图中，其余写在旁边。

6. 没有数值。 模型完成后，问“我们先做哪件事？”变成意见之争。

7. 无所有者、无触发事件。 没有指定负责人和固定的更新触发（系统切换、重组、年度复核）的模型，在十二个月后会过时而无人察觉。

用什么工具建模？

初稿用纸、白板和便利贴最合适。便签可以移动，且一个布置整齐的图能鼓励人们提出异议。为正式稿常用的图表工具已经足够——对单个流程来说，工具是最不重要的问题。若模型需多年维护或被执行，则进入带有仓库、版本控制与审批的 BPM 套件；这是一个采购决策，有自身成本，若维护流程数量不到两位数通常不值得。

会议中直接键入而非绘制的情况

有一个例外值得提及，因为它关系到最常见的中断原因：在研讨会中没人愿意画方框。现场画的人跟不上讨论，记笔记的人事后要转录——或根本不做。我们的桌面应用 FlowVisual 为此提供了一行录入：每行一个步骤，按 Enter 换行，链条自动连好。

Anfrage kommt rein
Angebot rechnen @Vertrieb 20-40min
Freigabe @Chef 5min ?über 10k
Nacharbeit @Vertrieb !fehlende Angaben

四个标记，更多语法没有：@ 表示角色，时间区间表示时长，? 表示条件，! 表示痛点。所有这些都是可选的——一个空白行也是有效行，未被说明的内容保持空白，而不是在模型中被设为虚构的零。若不愿从零开始，可打开六个模板之一（报价、发票审批、投诉、入职、服务台、订单处理）或导入现有程序文件；每个建议步骤带有逐字引用及文件，需要逐一接受。

关键不在于如何绘制，而在于之后能做什么：当角色、时长与频率已写在行里，最终图就已经包含了下一节提到的四个数值——可以进行计算而不仅仅是观赏。如何一次性完成，见指南，章节“如果还没有流程”。

比工具更重要的是：模型必须放在与人们日常工作相同的位置。存放在相关部门无法访问的工具中的图不会被维护——它只会被打印出来并在墙上陈旧。

结论

流程建模是有明确规则的手艺：先定边界，与执行者对话，为目的选合适记法，每个步骤对应一条角色与系统的执行，控制好异常，复核。遵循这些规则，您在一到两天内能得到一个可靠的模型。

模型不能提供的，即便用更好记法也得不到的，是您该先做哪件事。这需要把数值写到方框上并做计算——到达率、时长分布、产能、日历。图是前提，但不是答案。

下一步：

1. 用两句话写出触发与结果
2. 与执行者做两到三次访谈，问上文的五个问题
3. 以泳道绘制，八到十五个步骤
4. 让人复核，问“哪里不对？”
5. 每个步骤补上时长区间、等待时间、频率、是否有媒介断裂
6. 之后再决定在哪儿采取措施

延伸阅读：

• 流程地图制作 —— 单个模型之上的层级
• Lay bare: den Ist-Zustand beziffern —— FLOWREFY 方法的第二步，也就是把数值记到方框上
• 流程分析 —— 如何让模型变成有凭据的结论

用于进一步计算： 使用免费的 Prozesskosten-Rechner，您可以在几分钟内估算出建模流程每月成本——包括节省潜力和逐步明细。