说到流程的表达方式，所有人都会在脑海里立刻浮现出那种图形的模样，就是流程图。它是一种语言，为我们讲述事情是怎么发生的。
它表述了四个问题，我们可以用四个“W”来表示：When，What，Who和Why。什么情况下会发生的？发生一件什么事？这件事是谁做的？结果怎么样？
我们把这种流程的图形化表述叫做流程图，甚至有的时候我们一说到流程也是专指绘制出来的流程图。
流程的表达方式也经历了一个逐步演化和发展的过程，大致可以分成四个时期。
业务逻辑图
80年代，早期的流程图很简单，我们用来表达一个业务的基本逻辑，目的是很直观地呈现一系列动作之间的逻辑关系，我们可以叫它业务逻辑图。没有我们今天说到的众多流程要素和图例，甚至我们也不用在乎语言的标准，没有关系，只是为了能够表达文字难以表达的逻辑关系，便于我们沟通和讨论。没有专业的流程图工具，可以是一种绘图软件甚至只是纸笔来完成它，当然我们也并没有很多将它们用于管理的期待。
泳道流程图
90年代，我们有了管理的需求，有了专门的流程图工具，开始用泳道流程图，Visio这个工具至今我们依然非常熟悉。研究流程的人都用过Visio，它是用一个页面的方式来表达一段流程。泳道流程图有很典型的特征，那就是分泳道。泳道用来表达完成这段流程活动的具体部门或者是某些角色。一般从上面开始，经过一系列动作组合之后，在下面会有一个结束。其中有动作符号、判断符号，也有引用和附加的文本等要素信息。用这种方式做的流程图，一般都会附加一页流程说明，在流程说明里面我们会比较详细的列出来这段流程相关的更多信息。包括每个动作相关的属性，目的、参与人的职责、衡量的指标、参考的标准、输入和输出等等。为什么要附带这样的说明？因为我们有相关的管理需要，而在这样的流程图工具中没有办法表达多个维度的要素，所以为了把事情说清楚会附加这些具体的说明。
全息流程图
00年代，流程管理开始有了平台化的工具，平台和绘图工具的显著区别就是背后有了数据库，它们可以承载多维度的流程信息，然后根据我们的需要来呈现流程，而不再像从前一样用一个页面附加繁杂的说明来展现大量的信息。从工具到平台是一个跨越，这是基于我们对于流程的认识和管理需要的不断深入应运而生的。
首先，它具有更大的信息承载能力，可以不断补充和修改流程图和要素的信息；再者，它体现了流程的层级机构，可以逐层从宏观到细节地展开流程，而且可以将绘制的流程片段链接起来，流程可以形成完整的整体；还有就是它具有了管理功能，也可以多人平台化地协作、授权和管理这些流程图。虽然信息量大了，但是它的视觉上却更加友好了，我们给它起个名字叫全息流程图。
仿真流程图
10年代，人们不再满足于只是用工具来呈现流程，随着管理更加需要数据化，以及类似于ERP、PLM这样大型的企业管理软件的应用，人们更加希望能够让流程管理平台的输出结果更容易被那些管理和业务的系统软件所应用。于是更强大的管理平台应运而生，就是现在我们普遍说的BPM平台。
在这样的平台上，首先，描绘流程的语言逐渐形成了通用标准，比如BPMN的标准符号语言被普遍采用，这些符号在平台上被赋予数据定义；绘图演变成了建模，实际上我们的工作不只是把流程讲清楚让人们看懂，而是需要遵从严格的标准语言将真实的流程再现出来；然后，具有数据含义的流程图可以进行数据分析，可以模拟真实的环境仿真运行，这对于流程优化具有非常重要的意义；还有更令人振奋的结果是，我们甚至可以用这样的平台来设计流程，然后通过中间件将某些流程植入到IT系统中实现自动运行。
上图中形成的表格就是这段流程仿真运行之后得到的数据。我们给它起个名字叫仿真流程图，虽然它已经不仅仅是一张图。
这是流程表达方式经历的四个阶段，我们现在只是在探讨流程的视觉表达，关于软件我会在另外的专题里面去专门说明。
很多人在畅想着这样一个未来：企业应用软件的开发不再是那些写代码的工作，而主体是管理工作，由管理和业务人员来绘制流程，然后通过BPM平台直接就能转化成可以执行的软件，我们称之为敏捷开发。这样的未来是可以预见的，因为那些有严密逻辑性的苦工正是计算机所擅长的，而人类的智慧应该体现在设计上。
语言的标准
随着流程表达方式的演进，流程的语言也在变化。最早的业务逻辑图，语言的规范不重要，因为可能我们只需要用它们来帮助我们看懂一些活动的关系。在后来泳道流程图的时候开始形成了一些规范，但是这种规范是建立在片段流程图的基础上，只是为了让管理人员和操作人员能够看懂和传递这些规范。但是渐渐地演进，到了全息流程图和仿真流程图的年代，流程的语言规范就显得越来越重要，因为流程的应用范围在逐渐扩大。包括整合各种管理功能，包括流程分析，也包括IT开发的支持。
听起来有点复杂，其实说到根本流程图就是一种语言，就像我们的语言从古代汉语转变成现代汉语一样。这套语言能够帮助我们对话，不仅是业务人员之间，也有管理和业务人员之间，也有业务和IT人员之间，我们需要一套标准的普通话，然后所有的事情我们都能相互听懂了。
流程表达的语言标准，现在普遍采用的是BPMN的标准语言。这是BPMN这个国际组织在04年发布的，一套完整的流程描述模型和符号，能够在业务和管理、业务和业务、业务和IT之间，形成一个对话，得到了IBM、Oracle、SAP等一些软件商和公司的认可。2011年又升级了一个2.0的版本。这套模型和符号中，定义了流程的各种要素，包括活动、事件、网关、数据，以及各种流程活动和要素之间的逻辑关系的表达规范。
BPMN标准符号语言与我们传统使用的流程符号语言相比有很大概念上的差异。比如有事件的概念，用来表达一种状态，触发流程活动的一种状态，或者流程活动发生之后的状态。还有网关，我们可以将其理解为逻辑关系的开关，用来定义多个分支状态时什么条件下走什么样的路径。最简单的网关就是一个判断，YES走一条路径，NO就走另外一条路径。现实中还可以存在并行的网关、多重选择的网关。具体细节我们可以找相关资料来参考。
这是一个包含10个活动的流程图，我们分别用两种语言表达来进行对比。上面是用最简单的业务逻辑图来表达的，下面的是用BPMN的语言来表达的，活动都是一样多，但是很明显BPMN的语言表达的流程图要素就要丰富得多，也能够将流程信息表达得更完整和精准。BPMN的标准差不多有上百个图例，但其实我们真正地去描述业务的时候通常用不到那么多的符号。就像汉字一样的，我们的新华字典有66万个字，但是我们平常能用到的只有3500个字。有3000个字我们就能写99%的文章；有3500个字我们几乎可以写100%的文章了。
用什么样的语言来表达流程取决于你要交流的对象以及用途。当我们与管理人员或者业务人员描述业务活动的时候，用相对简单的常用符号就完全可以应付自如，我们也只能用这样的方式，因为复杂的符号语言对于非流程专业人员来说的确是一场灾难。但如果我们需要将流程最后转化为IT的时候，你就会发现问题不是那么简单了，恐怕你就需要更多的符号才能够把那些相对复杂的逻辑表达清楚和准确，才能让开发人员真正明白其中的关系。
描述流程对业务人员来说叫流程梳理，对专业人员或者技术人员来说叫流程建模。建模就需要能够完整、清楚、准确地描述流程，将前者的工作成果转换成后者需要一定的专业性。所以其实我们可以将流程梳理和流程建模看作是两种工作，前者是业务人员的工作，后者是专业人员的工作。我通常也会建议那些应用BPMN语言的团队，在做流程建模的时候不要一次性地完成，而是分成梳理和建模两个步骤来做，这样就不容易产生与业务人员沟通的障碍。
我想起这样一个段子：看门人是最懂哲学的人，因为每个人到访他都会提同样的问题：你是谁？从哪里来？到哪里去？而这三个问题就是哲学研究的根本问题。流程图要描述的核心内容其实也大体如此。
关注微信