（一）
在现实中，经常听到有企业领导或者咨询顾问说：“我们要把流程做得很细，只有做得越细，才越能在业务中落地，要细化到‘六级流程’，要细化到动作级的流程。”，“你们流程梳理得越细越好，程序员拿着你们的流程图就能直接写代码了！”
实际上程序员是不可能拿着流程图就能写得出代码的，程序员的开发输入一般来说不只是流程文档，还有更多的软件功能需求——包括用户界面、后端逻辑、数据库操作、数据模型等，每个功能有明确的描述（流程图只是描述方法之一种）和预期的输出。那么把业务流程“搞得越细越好”的意义何在呢？
还有一位朋友正在苦恼怎么做流程清单。他们做流程之前还要做场景，先做个“场景清单”，用这个场景清单推导出来有哪些流程。“场景清单”是指围绕业务目标，尽可能描述全和描述清楚各种具象化的业务场景、包括要解决的具体问题和期望诉求，为后续流程和方案的设计提供比目标更加具体的输入；场景清单的内容有：主场景、分支场景、场景描述、服务对象、用户诉求、管理诉求、运营诉求、发生频次、现有IT支撑情况、当前痛点等属性。为了描述场景和流程，他们要画用例图、业务场景图、流程图、领域事件表、实体关系图等等一堆的东西。
我问朋友：“你们的流程方法论究竟是什么？你们怎么定义什么叫流程？为什么要做流程？”，朋友说主要是搜集用户对业务流程的需求，指导未来的数字化建设。我说只是搜集需求的目的，难道不是开个研讨会，用一张牛皮纸上让所有业务部门的所有用户按照功能、数据、表单等维度，用贴条的方式，整理大家想法吗？至于后面的数字化建设，不同的建设策略有不同的做流程的方法，你要是实施套装软件，有必要去画什么用例图、领域事件表、实体关系图一类的东西吗？这些东西都是自研系统干的事儿，要是实施套装软件，你们要把精力放在讨论业务流程的业务问题上。
先说结论：我认为流程分成几级、每级流程画的得多细的讨论一点都不重要，首先得回到对流程的定义上。
（二）
我们对“画流程图”做一个狭义的定义：用直观的流程图来展现的一系列相互串联的活动。绘制串接活动的流程图——亦即图形化“流程模型”的工具和方法主要有五个流派：
1、流图表（Flow chart）：由美国国家标准协会（ANSI）制定，就是我们在 Visio 或者 PPT 里看到的那些流程符号，画出来的流程图直观、简单，不过没有标准化的符号属性定义；通常用于对流程建模的严谨性和体系性要求不高的情形。
2、事件驱动流程链（Event-driven Process Chain，简称 EPC）：由前文提到的Scheer教授提出的ARIS框架里的流程模型规范。EPC认为流程是由一系列事件触发的，并且针对事件的行为又将引发新的事件，流程表现为“事件-功能-事件”串接。EPC 的主要元素是：事件（Event）、功能（Function）、组织单元（Organization Unit）、信息（Data）以及称为“规则（rule）”的逻辑运算符（包括“与”，“或”和“异或”）。ARIS 在欧洲普及度较高，尤其是使用 SAP 的大公司。
3、统一建模语言（Unified Modeling Language，简称UML）：由国际技术标准组织OMG（对象管理小组）维护，这是一套做软件开发的系统分析的建模标准化符号，主要用于描述信息系统开发的需求，包括用例、时序、类、状态/活动、部署、组件、实体-关系等，也常用来画流程。
4、集成定义语言（简称IDEF）：由美国政府和军方在 70 年代开发，是一套包括十几种不同用途的建模规范族，从功能建模到数据、仿真、面向对象的分析/设计以及信息收集等，这是最早的流程图规范，我念大学时教授教的画流程就是 IDEF，不过看起来非常不直观，普通业务人员很难看懂。
5、业务流程模型和标记（简称BPMN）：由业务流程管理标准化协会 BPMI创建的标准，后来加入了国际技术标准组织OMG 成为 OMG标准之一。BPMN目前是业务流程建模的行业事实标准，它提供了丰富的符号集，即可使用少数符号用于面向流程梳理的描述性建模，也可用于工程性目的、较为复杂的流程建模，或者用于流程挖掘后的流程可视化展示，目前最新版本是 BPMN 2.0。
如果是管理咨询项目为分析业务而画流程，或者是业务部门分析某个具体业务的流程，用 ANSI流程图就足够了。如果企业要建立覆盖全公司业务的、体系性的业务流程管理，设立企业级的流程模型规范，那么采用 EPC 或者 BPMN画流程图是必须的。所以，“流程画几级”这个问题，本质是用流程图表达业务流程，要到什么颗粒度细度，或者说如何定义每级细度的标准的企业业务含义是什么？例如：“大象放进冰箱里”如果是一个流程图里的活动，可以往下拆解为三个更细的活动“打开冰箱”、“放进大象”、“关上冰箱”，那么“大象放进冰箱里”算第几级流程的活动？三级还是四级？“打开冰箱”又是第几级？
在现实中，流程分级（leveling）的方法并没有统一标准，在学术书籍或者咨询方法论中，什么叫“流程分级”都众说纷纭，而无论是哪种理论上的方法，在实践中都存在着一些无法自圆其说、难以操作的地方。我观察到主要有两种分级方法，姑且称之为分解法（分层分级）和分类法（分类分级）。
（三）
在中国国内市场上的流程建模工具有两个流派：
其一，十多年前 IDS Scheer 公司的ARIS 启蒙了中国的业务流程管理思想，今天中国市场上的一部分BPMS 产品公司跟 ARIS 有一定的渊源，核心人员或者曾经是ARIS 用户，或者在 IDS Scheer 工作过，虽然由于知识产权原因，他们产品对ARIS方法有所名词改换，但是原理和思路还是从ARIS继承来的，可以称为 ARIS 派。另一个流派则受到 WfMC 、OMG等技术标准化组织以及美系软件公司的影响，大多具有中间件软件或者工作流管理软件的背景，流程标记大多采用BPMN规范，可以称为 BPMN 派。
虽然在流程建模的思路和标记规范上，ARIS 派和 BPMN 派二者有所不同，但是在流程分层分级的流程架构上，思路还是基本接近的，我觉得 ARIS 系比 BPMN 系更强调结构化的分级流程架构，BPMN 系则对流程架构的结构化要求要低些。前些年ARIS 在欧美大公司，尤其是德国大企业（例如西门子），的应用很广泛，由于 BPMN 的视觉效果比 EPC 更直观，结构化严谨性要求低些，近年来在全球范围内的实际应用上，BPMN普及程度超过了EPC， 提出EPC的 ARIS 产品十多年前被德国中间件软件公司 SAG 收购后，也在主动拥抱 BPMN 了。
流程分层分级的套路以 ARIS 为代表，其思想是在顶层设计上，通过价值链等方式进行流程粗颗粒度地归类，而在中低层则可以将具体的流程，按照细节程度从粗到细地分解，这样形成粗颗粒度流程和细颗粒度流程的嵌套关系。
以下图为例，流程之间有三种关系：
1、流程链接关系：流程/流程组有顺序的或逻辑的关联关系，这种关系是水平的，关联性可以不是很强，例如价值链的各个环节就是流程链接关系；
2、流程变体：某一个特定的流程/流程组可能根据一些变量，为了完成同样的工作，衍生出多个的流程形态，例如，同样是客户订单交付， 对不同性质客户和不同产品类型及其供应链形态，分别适用按单配置（CTO）、按单组装（ATO）、按单制造（MTO）等模式——我朋友说的“业务场景”，可能表达的就是流程变体的意思；
3、 流程分解：一个流程中的某个活动被打开，由更细的流程来详述，这个流程就可以分解出一个或多个子流程，这就形成了流程的层级关系，高层次的颗粒度粗，低层次的颗粒度细。
在我印象中，2000 年后，ARIS就提出了在其系统工具平台上的流程分级模型，同时提供完整的流程横向分段拆解和纵向树状分解的流程模型集成的技术解决方案方案。
ARIS流程模式的设计技巧是从创建一个高层次的概念模型（企业价值链）开始，然后逐级分解添加细节，形成若干级数。随着流程模型变细，上下级之间以及同级的各个流程之间会有很多交互连接的复杂关系，或者很长的流程为了便于管理或阅读，也需要把它拆成几段——ARIS流程模型具有的上下分解（Hierarchical Decomposition ，“把大象放进冰箱里”如果是个流程中的活动，可以往下拆解为三个更细的活动“打开冰箱”、“放进大象”、“关上冰箱”）、水平分段（horizontal segmentation ，例如“从商机到订单”的流程可能非常长，可以横向拆成“商机到qualify”、“销售投标”、“价格谈判”、“合同签署”四段，四段之间又前后联系）的功能。
企业总体流程模型的建模的顺序既可以从上往下（从粗往细分解），也可以从下往上（从细到粗汇总）。这样使得 ARIS 的流程模型既可以拆成一小段一小段地看，又可以把相关联的流程横向纵向地全部连起来展示，可以形成一个蔚为壮观的流程图——我曾经见过某企业把他们的 ARIS 流程图用工程绘图仪打印出来，覆盖了会议室的一面墙，长有二三十米，高有两三米，图上的流程图标尺寸也就是蚕豆那么大。
在纵向的从粗到细分解，究竟可以分解成几层，并无一定之规，有些人认为应该是三层，也有些人认为最多可以到7 层。通常，ARIS将企业级流程模型的层次（layer）分为三层，而在每层可以再细分层级（level）：
层次一：概念性（conceptual） – 业务模式视角
层次二：流程性 （process）– 业务如何运营的结构
层次三：规程性 （procedural）– 具体活动任务的细节
这三个层次的每层次，为了在逻辑上或者视觉表达上看起来更结构化些，都可以再分解为几个层级。“概念性层次”可能分出一到两个层级，“流程性层词”可能分出二到四个层级，“规程性层次”一般没法再细分，就是一个层级，这么算下来，那就是三到七个层级了。究竟要划成几级没有明确的规则，但如果把层级划得太细，那么其划分的业务原则和逻辑反而会在众多复杂层级中迷失方向。
基于这样的思维，ARIS 提供了一个五级的流程参考架构，见下图，分别叫：企业地图、流程领域地图、主要流程模型、流程模型和活动模型。要注意，这个五级流程架构模型不要和 ARIS 的业务流程管理的四层架构（流程工程-流程规划和控制-工作流控制-应用系统）混淆起来：
这个五级架构，1-3 级对应于前述层次一的概念层，4 级对应于可以指导具体工作、用可视化流程图表示的层次二的流程层，而第5级是展示具体岗位角色、系统功能以及流程活动细节的层次三的规程层。
ARIS并没有提供每级流程定义的具体业务含义，也没有提供包含具体业务内容的流程框架指南，不过，跟 ARIS 联系紧密的德国企业软件公司SAP 在 ARIS 提出流程分级模型的同时，在其 SAP 的实施指南 ASAP 方法论中，曾经给出过一个对其 ERP 软件涉及到的业务范畴（例如财务、生产、销售、库存管理等）的五级流程参考框架，可以作为 ARIS 分级模型的实施对应。
ARIS 流程模型具体建模方法上，概念层的建模方法称为增值链（Value-Added Chain Diagram）模型，简称VAD，显然这是一个业务模式和业务领域的概念表达，主要用于宏观的业务设计，它并不是用来指导具体业务运营的。ARIS 流程架构的 1-3 级都是用 VAD来表示的，下面是常用的一级和二级 VAD 价值链图的示例：
在层次二的流程层，ARIS 采用了称为“事件驱动流程链（Event-Driven Process Chain，简称 EPC）”的流程描述方法，ARIS 流程架构的 4 级是用 EPC来表示的。EPC 是最主要的一种流程模型，ARIS 提供了几十种流程相关的业务和信息模型，包括流程、组织、产品/服务、数据、系统等，最常用的就是本章提到的 VAD、EPC 和 FAD三种，而如果你要做一个真正称得上“业务流程”、可以指导实际运营管理的企业级流程模型的话，其他模型都可以不用，但是 EPC 是必须用的。我认为在这个流程描述颗粒度上，用 EPC 流程图展示的流程才叫“流程”，或者说是狭义上的“流程”。一个 EPC 图里包括了构成流程最主要的几个元素：
事件（event）：流程的开始触发、过程中状态和结束的产出。
功能（function）：代表流程中的一个动作，或称任务（task）或者活动（activity）
资源：跟动作相关的数据、文档、软件系统的功能、组织单元（organization unit）和岗位角色（position）
规则：流程走向的逻辑判断：
ARIS 对于一个EPC流程有几条建模规则：
- 每个模型必须至少有一个开始事件和一个结束事件，
- 功能和事件总是交替发生，
- 功能和事件只有一个传入和传出连接，
- 流程路径总是使用规则来拆分和组合;
- 触发一个功能的多个事件，使用一个规则（OR，XOR，AND）来组合;
- 规则不能跟在单一事件后，
- 决策由功能做出;
- 做出决策的功能，总是跟随在规则后；
- 规则显示遵循一个决策的若干路径的有效组合;
- 跟随着规则的事件，表明决策的实际结果;
- 规则不能有多个输入和多个输出。
尽管流程间存在横向连接或者纵向分解，分解的目的只是为了便于阅读，纵向分解的每级流程上的功能/事件/规则的定义都是一样的，从这个角度上说，基于上述建模规则建立的流程就是流程，并不存在有不同类型、不同定义规则的流程——就像父亲是人，儿子也是具有同样生理特征的人，不是就变成其他物种了，所以我说只要是EPC 画的流程，无论是几级流程，都是“流程”。
对于 EPC 上的每一个功能（function），或者说是任务（task），如果要进一步描述其细节，可以适用“功能分配图（Function Allocation Diagram ，简称FAD)
需要注意的是，并非所有的流程信息或者每层流程图都必须在ARIS中进行图形化、结构化建模，无论是粗的流程组定义、概念想法、需求定义，还是流程活动的详细描述、作业指导等，可以在文本格式或者其他格式的文档中描述。用户可以将这些文档链接到相关ARIS对象上，所以即使没有直接对其建模，各种信息源可以链接到模型架构中，这样，ARIS就成为一个以结构性流程为框架的、完整的企业信息存储库。
下图展示了这种流程分层分级，以流程为核心的企业信息管理的方式。整个模型结构有三层四层(第二层被分成两层)。
在顶部，我们使用增值链图对概念层进行了一级的建模。可以包括文档和图形来支持这种概念表示。
中间是流程层：这一层次包含两个层级的流程模型。为了阅读体验好，EPC 流程最低建模信息或者模型显示可以只包含事件、规则和功能，这种看起来简单的流程图称为“精简 EPC”（lean EPC）。下图上的二级和三级都是精简 EPC。
底层是规程层。在这个例子中，显示了一个详细的模型(带有功能分配)，它再次从上面的流程模型中分解出来。图上展示了附在这个“四级流程”上的一些对象上的文件，这些对象代表了进一步的，但不是直接建模的五级及以下的流程信息，包括操作规程和工作检查表等：
ARIS是基于工具的，比较完善结构化业务流程模型，今天在国内有一些和 ARIS 类似的流程管理工具。在二十多年前ARIS 建模及流程分级方法出现的同时，如果不使用这种复杂的工具以及严谨的流程模型定义，单纯使用手工来管理流程分级、使用相对宽松的ANSI 流程标记方法来画流程图的做法也是有的，当时 IBM 咨询顾问就是采用下图这种做法，请注意这也是一种“嵌套式”的流程分解思想：
在管理咨询顾问采用的做法中，一级和二级流程是价值链图，只有三级流程是通常所说的“流程图”的表现形式，到四级和五级流程就采用文档描述的方式，四级是作业描述，五级是软件功能描述，所以我常说的“流程就是流程”，就是指一般来说只有一个核心流程层级上的一种流程图形式。
（四）
另一种套路并不特别强调流程的横向分段和纵向分解的关系，只是提供了一个分类分级的层级结构，让用户可以将一个个离散的流程装进这个分类框架里。这个套路的代表就是 美国生产与质量协会的流程分类框架（以下简称：APQC PCF），供应链SCOR 模型也是这个套路。
PCF是一个业务流程的层级列表，在最高层级（level），它包括13个工作的“类别”（Category），分别是战略、研发、销售、角度等，每一类别朝下将工作分解为越来越细的单元或级别，称为流程组（process group）、流程（process）、活动（activity）和任务（task）。APQC 提供了一个行业通用模板，和若干个行业专用模板，每个模板具体的内容具有行业特点，各不相同。
很多人把APQC PCF的每一个层级，叫做“某级流程”，我觉得这个说法比较误导，因为 按照APQC PCF的本意，其上的每个对象是一个分类节点（class），而并非指一个活动或动作，例如“管理财务资源”不是一个活动，而是“流程分类框架的第一个层级的财务类”
APQC的官方文档里也承认，流程框架的分级水平的一致性并不高（The PCF is not consistently leveled.）它的一级分类是 13 类，第 13 类叫“开发和管理业务能力”，其实就是前面 12 类领域，包括战略、研发、销售、生产、财务、人力、IT 等企业职能里装不下的职能，都装到这一类下面了，例如项目、质量、EHS 等，那么凭啥项目职能和其他职能相比，就被归在了“其他类”下的二级流程，比财务、人力低一级呢？有些公司是项目型运营的公司，例如 IT 服务公司，那项目应该算是一个一级分类。
我们先澄清一个概念，就是分层级（level）和分类别（categorization）
·分层级是指对细节的颗粒度，不同层级有不同的表现形式，例如高层级可以用价值链图，中层级用流程图，低层级用文档来表现。
·分类别是指把具有共同特性的流程放在一起，例如价值链上的相同职能体系；“价值端到端”也是一种分类思路，类似于职能定义，但是更加强调跨部门协作，常见的端到端定义有“创意到产品”（研发）、“订单到现金”、“需求到商机”、“采购到支付”、“记录到报表”、“请求到解决”。
从不同维度来对流程进行分类分级，通常采用如下三个维度及排列组合：一是价值链职能（或端到端），二是组织行为层级，三是流程颗粒度。前面两个维度属于分类别，第三个属于分层级，加起来就是流程分类（classification）的框架，所以我把PCF 叫做“流程分级分类”，和前述 ARIS 的“流程分层分级”概念有所不同。
在中国企业的实践中，我还看到一种划分流程层级的逻辑，是按照公司的组织层级来划的，例如，我过去文章说到的那个流程要做到6-7 级的流程咨询招标文件里就是这么定义的：集团级流程叫一级流程，事业部级的流程叫二级流程，部门级流程叫三级流程，小组级的流程叫四级流程，小组里的人与人之间的互动叫五级流程，个人的动作分解叫六级流程，每个动作里的电脑屏幕字段操作叫七级流程。我认为这种做法其实不太符合对流程管理跨部门的初衷，做业务流程的目的就是推动组织扁平化和简化管理，他们的做法带有很强的中国企业对业务流程的误解色彩：“流程就是管理制度”。
APQC分类方法的流程类别和迈克尔·波特的价值链模型基本接近，从组织行为的维度上，分为两大类：运营流程、管理和支持流程；按照价值链维度，运营类之下包括战略、研发、销售、实物产品交付、服务交付、客户服务等，管理和支持类之下包括人力资本、财务、信息技术、资产、风险合规、外部关系、其他业务能力（流程、项目、质量、变革、EHS 等），这两大类，十三小类共同构成了 APQC 流程分类框架（PCF）的第一个层级，称为类别。
然而类别往下细分，每一层级定义的颗粒度原则是什么， 究竟什么是可以描述并指导业务操作的“流程”， APQC 官方文档的描述非常模糊，我自己读来有些困惑，大家可以跟我一同感受下：
“类别”是流程框架最高一级（category is the highest level of the process framework）——说人话，就是“一级流程就是流程框架的第一级”——说了等于没说，还是没明白“类别”的定义是什么。
“流程组”指执行“类别”的一组流程（process group indicates a group of processes that are part of executing a Category） ——说人话，就是“‘流程组’就是一组流程”，“二级流程就是一级流程下面的那级流程”——说了等于没说，还是没明白“流程组”的定义是什么。
“流程” 就是一个单一的流程，它是为了完成一个特定结果的一系列步骤的名字（process is a single process; it is the name for a series of steps required to achieve a particular result）——前半句还是屁话，“流程就是一个流程”，而后半句似乎带来理解含义的希望，“流程就是一组步骤的总和”，那什么又是“步骤”呢？我们接着往下看
“活动”指一个执行一个流程的关键行为步骤（Activity is a key step performed to execute a process）—— 我靠，又绕回去了，“步骤就是执行流程”和““流程就是一组步骤的总和”不就是车轱辘话吗？
业务流程框架的官方定义和官方中文翻译反正是把人搞晕，究竟它每一级这个名词包含了什么内涵和外延？什么叫儿子，就是爸爸生的男孩？什么叫爸爸，就是生出儿子的男人？好，那我问你，果总究竟是儿子还是爸爸？显然，果总既是儿子，又是爸爸。“大象放进冰箱”里如果没有一个具备实际业务意义的参照系，永远不知道它是一个活动，还是流程，或者是任务？
从概念上说，APEC PCF的分类层级树上的每个对象，只要还能往下分解，就是一个分类的节点；只有不能往下分解了，才是一个可以包含了若干功能和事件、可以用流程图的方式来表现的“流程”。我们可以用下图来展示这种组织关系，只有第三层级的1.1.4, 1.1.5，第四层级的 1.1.1.3， 1.1.1.4 以及再也不能往下细分的第五层级的对象，是可以用流程图来可视化展现的“流程”，而其他的每个对象都是一个包含了若干子文件夹以及流程图的文件夹 ：
如果我们在口语中的“X 级流程”指的是可以用可视化方式展示、并且指导工作的流程图的话，我们可以分别把1.1.4, 1.1.5 叫“三级流程”，第四层级的 1.1.1.3， 1.1.1.4 叫“四级流程”，1.1.1.1.1 和 1.1.1.1.2叫五级流程，然而这些流程图之间并没有上下级的分解关系，他们之间反而是存在一定的横向逻辑联系，哪怕是不同级。不过 APQC 并没有提供流程模型（有些企业把 APQC 的分类体系叫“流程模型”，这又是一个名词歧义）的建模规范，没有ARIS EPC或者 BPMN 的流程表示、流程连接和流程分解的具体定义。
PCF 本身只是一个五级的流程清单，这个清单是一个由粗及细的业务流程分类的定义，例如：管理人力资源（一级） - 寻源/招募/录用员工（二级） - 找寻候选人 （三级） - 管理猎头公司 （四级）。PCF 官方定义也很清楚：“PCF并不是整个组织中工作流程的可视化表示。它不是流程图、工作流图或泳道图。PCF可用于创建这些模型，但是PCF本身缺乏传统上包含在这些图中的附加信息。”也就是说，PCF 应该是搭配 BPMN、EPF 这类建模方法一起使用的。
APQC PCF提供标准化参考，它本身也有跨行业版和一些行业版，企业应用时可以进行裁剪，如我在《IBM的业务流程管理和流程/IT 治理机制》所写，IBM 应用 APQC 就有所不同，基于 APQC 构建了自己的流程框架，称为 IBM 的企业流程框架（EPF）。更重要的是，IBM 并不是拿着EPF 对每一个流程都大动干戈地开展流程管理工作，而是在这个框架下，只是选择少数类别的流程进行深入的流程变革及数字化实现。‘
（五）
我们来总结下，流程分级的方法论大部分需求最终都集中在业务行为的软件实现上，用各种方法来分析和设计组织内的工作流和流程，使用诸如“流程”（process）、“子流程”（sub-process）、“活动”（activity）、“任务”（task）、“规程”（procedure）、“事务”（transaction）或“步骤”（step）等术语来描述不同颗粒度的工作执行方式，但是这些名词的性质和彼此之间的区别并没有准确定义，也缺乏公认标准，不同的方法论体系和软件各执一词，给企业用户带来很多困扰。
不同流程体系对于分级颗粒度的叫法都不一样，我们可以试举几例：
我觉得“几级流程”这种说法有些误导，建议从流程的表现形式来对应于企业流程的分级。狭义的“画流程”是指用符合 BPMN 2.0 规范的“流程图”形式来建模、并且实现半自动化或全自动化工作流的工作，特指企业流程分级框架里的中间那个层级：
本页的评论功能已关闭