支付系统功能架构图
 
支付业务的基础系统的复杂性和稳定性是支付业务是否能够及时安全处理的根本,该支付系统功能架构图收集了支付宝的系统架构。完整的支付系统整体架构! 从产品分类、模块功能和业务流程,了解支付产品服务的设计。支付系统要兼并合规性、易用性、安全性为一体,在前期设计时一定要综合考虑。支付系统架构图为通用支付... 
 
 
 
 
 
平台数据架构流程图
 
标准大数据平台架构,标准大数据平台架构,大数据平台架构,数据仓库,数据集市,大数据平台层级结构,数据挖掘,举报,包含该模版的分享。数据架构设计(数据架构组) 概述 总体描述 相对于业务架构和应用架构,数据架构在总体架构中处于基础和核心地位。首先应根据业务架构分析来定义数据架构,然后将数据架构结... 
 
 
 
 
 
系统流程图
 
系统流程图(又称业务流程图)进行可行性分析时,通常用系统流程图来描述所要开发的系统。用于 描述项目的处理流程、范围、功能等。系统流程图是概括的描绘系统物理模型的传统工具。它的基本思想是用图形符号以黑盒子形式描绘系统里面的每个具体部件(程序、文件、数据库、表格、人工过程等），表达数据在系统各个部... 
 
 
 
 
 
Spring Cloud 微服务总体架构图
 
Spring cloud作为当下主流的微服务框架,让我们实现微服务架构简单快捷,Spring cloud中各个组件在微服务架构中扮演的角色如图所示。spring-cloud-aws：用于简化整合 Amazon Web Service 的组件spring-cloud-bus：事件、消息总线，用于... 
 
 
 
 
 
财务管理系统业务流程图
 
这是一个财务管理系统业务流程图,模板主要包含了2大部分:角色和业务执行流程.其中角色就包含了系统管理员,出纳/会计,财务主管,CEO.整个财务管理操作流程清晰明确。ERP中销售流程及财务管理流程,ERP管理系统是非常复杂的的系统,涉及到多个模块。仓库管理业务流程图, ERP业务流程图的画法, ... 
 
 
 
 
 
系统业务流程图
 
商业流程图，又叫做业务流程图,是一种描述系统内部各人员与各单位的业务关系、管理信息以及作业顺序。系统流程图是概括的描绘系统物理模型的传统工具。它的基本思想是用图形符号形式描绘系统里面的每个具体部件，表达数据在系统各个部件之间流动的情况。系统分析员在工作中往往需要绘制各种各样的流程图
 
 
 
 
 
 
 
组织架构流程图
 
组织架构是企业的流程运转、部门设置及职能规划等最基本的结构依据，常见的组织架构形式包括中央集权制、分权制、直线式以及矩阵式等。组织架构关系图有总经理、副总经理、研发部、采购部、财务部、销售部、生产部。完善组织体系架构，员工体系，薪酬体系，绩效体系，岗位体系，建设队伍，创造激励机制!
 
 
 
 
 
 
 
电商物流仓储流程图
 
在电商仓储内部中,其作业流程主要包括订单处理、采购作业、入库上架、在库管理、拣选包装、出库作业、配送作业、退货作业以及财务会计作业等。电子商务的快速发展,其配套设施服务也需跟上,而其中最重要的非仓储、配送等物流服务莫属。电子商务间的竞争,最终转变为后端物流之争。
 
 
 
 
 
 
 
精益质量管理流程图
 
精益质量管理流程图,该流程图以精益质量管理为中心,从五个小点逐步扩散,改善了工作的效率。精益管理有七大任务,分别是:安全、质量、生产、设备、成本、人事和环境!质量管理部进料、生产过程、出货、新产品研发、不合格品控制等工作流程图。建立和实施质量管理体系工作流程: 第一阶段:策划与准备 一、体系策...
 
 

 
 
 
 
 
 
 
 
 
什么是架构图？
 
 
 
如何画好一张架构图，要做好这件事情首先要回答的就是什么是架构图。我们日常工作中经常能看到各种各样的架构图，而且经常会发现大家对架构图的理解各有侧重。深入追究到这个问题，可能一下子还很难有一个具象的定义，如果我们把这个问题进行拆分（如下图）理解起来就会容易一点。
 
 
 
 
架构图 = 架构 + 图
 
 
 
按照这个等式，我们可以把问题转换：
 
 
 
 
架构是什么？
 
 
图是什么？
 
 
 
图是什么？这个比较容易回答，图是一种信息的表达方式，所以架构图，即表达“架构”的图，也就是一种架构的表达方式。也即：
 
 
 
 
架构图 = 架构的表达 = 表达架构的图
 
 
 
按照这种思路我们需要回答：
 
 
 
 
什么是架构？要表达的到底是什么？
 
 
如何画好一张架构图？
 
 
 
接下来的内容基本上就是按照这两个维度来做分析。
 
 
 
什么是架构？要表达的到底是什么？
 
 
 
Linus 03 年在聊到拆分和集成时有一个很好的描述：
 
 
 
 
 
I claim that you want to start communicating between independent modules no sooner than you absolutely HAVE to, and that you should avoid splitting things up until you really need to, because that communication complexity often swamps the complexity of the actual pieces involved in it.（让我们认识到一种现象，把复杂系统拆分成模块，似乎并没有降低整个系统的复杂度。它降低的只是子系统的复杂度。而整个系统的复杂度，反而会由于拆分后的模块之间，不得不进行交互，变得更加复杂。）
 
 
 
 
我理解这里描述的系统拆分就是架构的过程，基本出发点是为了效率，通过架构的合理拆分（无论是空间还是时间上的拆分），最终目的让效率最大化。那到底什么是架构，其实没有完全统一且明确的定义，如下三个定义可以参考。
 
 
 
在百度百科上的定义：
 
 
 
 
 
架构，又名软件架构，是有关软件整体结构与组件的抽象描述，⽤于指导⼤型软件系统各个方面的设计。
 
 
 
 
在 Wikipedia 上的定义：
 
 
 
 
 
Architecture is both the process and the product of planning, designing, and constructing buildings or any other structures.
 
 
 
 
ISO/IEC 42010:20072 中对架构有如下定义：
 
 
 
 
 
The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.　
 
 
 
 
 
 
 
这三个定义也是见仁见智，但是我们基本可以得出：架构体现的是整体结构和组件之间的关系。
 
 
 
架构的本质
 
 
 
这里引用三个观点来探讨架构的本质：
 
 
 
 
架构的本质是为了管理复杂性。
 
 
 
 
架构的本质就是对系统进行有序化重构，不断减少系统的“熵”，使系统不断进化。
 
 
 
 
架构的本质就是对系统进行有序化重构，以符合当前业务的发展，并可以快速扩展。
 
 
 
上述三个观点提到的内容，基本表达了架构的核心目的：管理复杂性，效率最大化。以及架构的两个主要变化来源：一个是以改善软件质量为目的的内在结构性变化；另外一个是以满足客户需求为目的的外在功能性变化。无论是何种变化，在我看来架构都是在不断的判断和取舍，在业务需求和系统实现之间做权衡，从而来应对未来变化的不确定性，如下图可以比较粗浅直观的表达这种理解。
 
 
 
 
 
 
要表达的是什么？
 
 
 
在 EA 架构领域，有两种常见架构方法 RUP 和 TOGAF，这两个框架也是我们常常了解架构分类的两个维度。从个人的角度，我自己觉得 TOGAF 的分类方式更加广泛使用（如下右图）。
 
 
 
 
 
 
结合日常的业务开发，其实我们更多的是关注业务架构和应用架构，所以把上边的表达式进一步的拆解，在回答如何画好一张架构图之前，我们需要关注业务架构和系统架构，讨论清楚如何进行业务架构和系统架构。
 
 
 
 
 
 
架构的过程其实就是建模的过程
 
 
 
我们都知道现实世界到软件世界或者面向对象的世界的过程，是一个不断抽象的过程，这其中的方法就是不断的建立模型。从现实世界到业务模型，从业务模型到概念模型，从概念模型到设计模型，通过不断的抽象去粗取精，形成对现实世界的层层抽象，所以架构的过程其实就是建模的过程。至此，我们有必要了解一下什么是建模。
 
 
 
百度百科定义：
 
 
 
 
 
建模就是建立模型，就是为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。
 
 
 
 
《Thinking in UML》定义：
 
 
 
 
 
建模（Modeling），是指通过对客观事物建立一种抽象的方法用以表征事物并获得对事物本身的理解，同时把这种理解概念化，将这些逻辑概念组织起来，构成一种对所观察的对象的内部结构和工作原理的便于理解的表达。
 
 
 
 
从上述两个定义上基本可以了解到建模就是抽象，对业务或现实世界的抽象，虽然不足以帮我们理解架构本身，但是可以将我们上述关注的业务架构和系统架构进一步向下 Down 一层，架构的过程是建模的过程，我们转换成两个简单的问题：模是什么？如何建？
 
 
 
模是什么？如何建？
 
 
 
这是两个比较容易陷入理论性的问题，我们跳出来从结果看过程。接下来通过已经产出的一些架构图来反向看这些架构图是如何产出的，同时来回答这两个问题。
 
 
 
 
 
 
业务建模
 
 
 
回到当下业务本身，对我而言也是全新的，在最初接触的时候凭仅有的行业背景去理解，结合了大量的文档阅读最终产出了如下图示的《业务核心流程图》和《业务功能模块图》。这两张图基本上就涵盖了所有的业务内容。左边的业务流程图得到了这个行业 20 多年从业经验专家认可，他认为这就是 20 多年所从事的业务内容。
 
 
 
 
图片源于网络，为示意图，侵删
 
 
 
回溯整个过程，特别是左侧的业务核心流程图，今天我们看这张流程图很容易构架起一个基本逻辑来，纵向是不同的业务角色和系统，横向是时间的推进，特别容易理解。但我想说最开始的理解和分析是极其耗时和压力极大的过程。这个过程中我所用的方法就是：
 
 
 
 
“把书读厚”：大量的信息输入，同时探求可能性。
 
 
“把书读薄”：归类汇总，形成大图。
 
 
逻辑对照，确保理解和分析的正确性。
 
 
 
1）把书读厚
 
 
 
下图基本涵盖“把书读厚”的过程，汇聚大量的文档信息，尝试用多维度去形成逻辑。这个维度可能是依据历史经验，也可能是依据文档内容，比如在形成业务大图的过程中，我曾按可能的场景逻辑、可能的系统或领域逻辑分别把多个文档中的内容归类，探求可能性。
 
 
 
这个过程会很枯燥，特别是涉及一些业务的术语内容，理解起来就会很困难。我的方式就是把自己当做一名“探索者”，如同我们玩游戏一样，常常问自己“我的游戏地图全部点亮了吗？”未必要照顾到所有细节，但是需要力求覆盖整体内容。仔细想想，似乎也和日常的读书类似，这期间值得注意的是：
 
 
 
 
重点关注一些业务概念被界定的地方、一些与自己逻辑推理有出入的地方。
 
 
 
 
不断的调整自己阅读过程中记录的维度，矫正自己的分析方向。
 
 
 
 
老老实实用文档中的原话来记录和呈现（这点很重要，特别是阅读英文材料，最好原汁原味的记录，有助于提升自己的专业性）。
 
 
 
 
 
 
2）把书读薄
 
 
 
这个时候的重点是建立“大局观”，尝试梳理自己的逻辑主线，常规逻辑上讲都会划分为横纵，或者矩阵式的框架，当然这需要建立在前期的理解和分析上，这里常常隐含一个最最重要的假设：系统一定是给人用的，一定是解决客户问题的，否则毫无存在的意义。所以核心的套路是：谁？用什么样的服务/功能/能力？解决什么样的问题？从而刻画出：参与者角色、系统能力、交互关系，需要常常问自己的是：边界是什么？输入输出是什么？逐步的通过用例来梳理出业务功能，形成角色—>主流程—>分支流程，进而通过不断的归纳演绎形成最终的业务抽象描述“一张图”。
 
 
 
一个小的细节是不能妄图通过这些过程迅速在大脑里完成大图的绘制，还是需要从小的环节做起，把一部分小的业务闭环做成一个个的小组块，不要让它再占用大脑的空间，然后逐步的整体思考和把握，渐进式的形成大图；与此同时，大图的样式美观先完全忽略，走通逻辑再细致调整。之所以强调这个细节，是因为尝试通过“一张图”去描述一个非常大的业务本身就是件很有挑战的事情，如果不这么做容易让自己变得焦虑和急躁，这是一个慢功夫，需要耐心，需要在关键阻塞的地方慢下来，甚至一遍一遍的反复才能最终完成。
 
 
 
 
 
 
3）逻辑对照
 
 
 
这是一个闭环封装的过程，把前期“读厚”过程中的记录，一些逻辑细节、关键流程都要逐一放到大图里去对照验证，确保业务理解的完整性和准确性，确保业务抽象能够覆盖所有已知的业务用例，甚至能够支持可能的业务场景。这个环节也是必不可少的部分。 
 
 
 
总结一下业务建模（如下图），通过上述三个主要的过程，我们基本可以产出一些业务架构的大图、框图、流程图、用例图等等，是什么样的图并不重要，重要的是这个图面对的是谁？主要用来做什么？我后边也会讲到画图角度的问题。从我们目前的业务场景上看，业务架构图的核心目的是统一共识、减少沟通成本，无论是项目中的哪个角色大家都能讲一样的话，描述一样的事情。这就是建立对话能力和对话语境，特别是有大量外部客户的时候，一方面体现我们自己专业性很重要，另外一方面这种与客户对话的能力更重要，这也是上文中提到为什么要尽可能用原汁原味的文字去呈现一张图的目的。
 
 
 
 
 
 
系统建模
 
 
 
通过业务建模完成了从现实世界到业务模型的构建，在此基础上，如何通过抽象完成业务模型到设计模型的映射，这是系统建模要解决的问题。从研发实现的角度，这个阶段会产出各种各样的模型图，比如实体模型图、时序图、状态图、各个层次的架构图等等，但是无论何种角度，何种层次，系统建模一定是在业务建模的基础上，完成业务需求到系统模型之间的映射；这其中涉及业务功能到系统能力、业务流程到数据流程的映射；系统建模更强调职责、依赖、约束关系，用于指导研发的落地实现。
 
 
 
抛开具体的时序图、状态图不谈，简单看一下如下几个维度的架构图：
 
 
 
 
图片源于网络，为示意图，侵删
 
 
 
上述几张图的视角、层次和面向用户各不相同，基本上都能看到整体，但是细节程度不同，侧重表达的信息也完全不同。那么系统建模时应该如何去做呢，这个过程中我常常用的方法是（不尽然如此）：
 
 
 
 
“剥洋葱式”的由大到小，由粗到细，覆盖所有已知和未来可能业务场景；善于利用各种模型表述：自然语言、关系模型、时序图、状态图、流程图、各种层次架构图等等进行模型表述，充分表达各种业务场景并不断验证。
 
 
 
 
核心实体抽取：抓住核心概念，核心关系完成核心模型建立。
 
 
 
 
终极武器：所有的设计/逻辑模糊的点，将所有已知场景分别套入，自己讲给自己。
 
 
 
1）“剥洋葱”
 
 
 
在业务建模结果的基础上进行“剥洋葱”。这是一个不断拆解的过程，这个过程中的拆解非常重要的方式是就系统分工。如何分工？哪个模块负责什么？模块的输入和输出是什么？内部提供什么样的服务和能力？这几个问题在后文关于抽象的部分回答。一句话总结“剥洋葱”就是：从业务建模的“大局观”去按职责分工拆解成多个子系统、多个子模块、然后在模块能进行细分，层层剥解。
 
 
 
2）核心实体抽取
 
 
 
关于核心实体的抽取，这里的关键问题是：哪些是实体？如何判断核心实体？如何抽取？抽取后的结果是什么样的？很难用一种方法论的形式去描述，我也没有完全形成我自己一成不变的方法论，但是我觉得如下三种方式可以供大家参考。
 
 
 
 
对象的分析方法
 
 
 
 
 
实体（Entity）：客观存在并可相互区别的事物称之为实体。实体可以是具体的人、事、物,也可以是抽象的概念或联系。
 
 
 
 
从这个概念理解，和我们面向对象万物兼对象的理解是基本一致的。所以实体的抽取也可以借鉴对象分析的方法：独立、可抽象、有层次性、在单个层次上又具备原子性。如下图是《Thinking in UML》中关于对象的分析方法。
 
 
 
 
 
 
 
用例分析的方法
 
 
 
通过从业务用例中，去提取其中的关键词，不同的关键词可能表达了实体、关系、属性等等内容，从而完成模型分析与建立。这里引用六铢老师在《问题空间领域模型基本抽象方法》中的的内容，简述如下：
 
 
 
 
 
一句完整的用例描述中，首先找名词，以「主语」和「宾语」为主，这些名词基本可以确定我们的实体；其次找形容词，存在于「定语」和「状语」中，找到形容词基本可以确定对应属性的值；然后通过对用例的补充，细化，对名词进行定义，慢慢的，我们会得到我们的领域模型和对应的属性。最后通过动词&形容词（存在于【谓语】，【状语】，【定语】）来确定他们之间的关联关系。
 
 
 
 
 
问题分析的方法
 
 
 
这是《聊聊架构》中提的方式，具体讲就是通过寻找问题的主体，然后分析主体的生命周期，进而通过区分生命周期里的关键活动来聚焦主体的关键属性和关键关系。推荐大家阅读前 9 章的内容，总计才 40 页的内容，可能会有所体会。这里举一个书中的例子：
 
 
 
 
 
一个笑话：一位女士对老公说：把袋子里的土豆削一半下锅；结果所有土豆都下锅了，而且每个土豆被削了一半。
 
 
 
 
作者指出，这里其实就没有清晰的设别主体，这个主体不单是土豆，而是隐含的人要吃土豆，包括人和土豆两个实体，这两个实体之间的关系就是要解决的业务场景：怎样吃？如何吃？为什么吃？所以主体识别不清楚，可能会导致整体实现的偏离。当然实际过程中不会犯这么愚蠢的错误，但是也侧面说明核心实体的抽取是非常关键的。
 
 
 
3）终极武器：自己讲给自己
 
 
 
实际的业务开发中，往往一种业务设计实现要满足上层N个业务场景，这其中有共性也有个性化诉求，这个过程中我们很容易被多场景之间的异同搞混乱，要么逻辑不清晰、要么过度设计、要么考虑不周。我观察过很多同学包括我自己，在一定的业务复杂度时容易失去设计的焦点。我的做法与业务建模类似，一定要逻辑对照：在所有的设计/逻辑模糊的点，将所有已知场景分别套入，自己讲给自己。请注意这里是“分别套入”，在当前的设计层次下一个场景验证完再去验证下一个场景，找出阻塞的、模糊的点，重新梳理再优化设计。系统建模的结果指导我们软件设计实现，所以一定要反复梳理打通，这个反复的过程其实也是提升架构能力的过程，累积到一定程度就会自然通透。
 
 
 
回到开始的那个问题：
 
 
 
模是什么？通过上面业务建模和系统建模的描述，简单来讲模就是业务的映射，这个映射的结果是业务模型、概念模型或设计模型，但是所有的出发点都是业务需求：客户是谁？核心诉求是什么？
 
 
 
如何建？上面通过业务建模和系统建模两个维度，从个人实践角度大概讲了常规的套路，建模的本质其实一个抽象的过程，但是上述业务和系统建模抽象的过程其实还有两个问题并没有完全说清楚：
 
 
 
 
业务建模中“把书读薄”归类汇总，建立「大局观」，形成大图，这里按什么维度去归类？如何判断归类是正确的？
 
 
 
 
系统建模中“剥洋葱”怎么拆？按什么拆？上述架构图中的层次、领域如何划分层次？边界在哪里？
 
 
 
说回抽象
 
 
 
Haskell 语言的设计者之一 Paul Hudak 曾说过一句略带夸张的话：编程中最重要的三件事是：抽象，抽象，抽象。
 
 
 
 
 
“abstraction, abstraction, abstraction”are the three most important things in programming。
 
 
 
 
如果要问程序员最重要的能力有哪些，我相信抽象一定是其中最重要的之一。那到底什么是抽象？
 
 
 
百度百科定义：
 
 
 
 
 
从具体事物抽出、概括出它们共同的方面、本质属性与关系等，而将个别的、非本质的方面、属性与关系舍弃，这种思维过程，称为抽象。
 
 
 
 
如果更精炼的概括：抽象就是做减法和做除法。通过舍弃非本质和无关紧要的部分，着眼于问题的本质，去粗取精；通过透过现象看本质，发现不同事物之间的共同之处，异中求同，同类归并，也就是做除法。上文中建模过程是共性抽象，通过不断的抽象达到某个状态为止，我理解这个状态没有确定性的答案，核心就是满足业务场景的需要，其实这背后也有一个边界的问题。
 
 
 
抽象的角度
 
 
 
生活中处处都是抽象，但是我们似乎少了为什么是这样或那样抽象的思考。抽象是有角度之分的。
 
 
 
生活中我们常常说“我的观点是…”，其实这里的“观点”就是一个角度问题，从一定的立场或角度出发，对事物或问题所持的看法。以生活中的常见的实物来说（如下图），我们是否能快速的说出其中的相同点和不同点。
 
 
 
 
 
 
如图中已经标注的，我们从功用的角度对它们定义了椅子、桌子、凳子和柜子这样的区分，但显然很有很多很多角度，比如：物料、文字、高矮等等维度，从不同维度看过去，会有完全不同的相同点和不同点表述，所以，本质是什么？本质是：
 
 
 
 
抽象角度其实也是分类的角度，角度不同，会导致完全不同建模方向和结果。
 
 
 
 
抽象的角度就是建模的方向和目的（“屁股决定脑袋”）。
 
 
 
重新回到我们前边的两个问题，业务建模中我们谈到了归类，按什么去归类，答案呼之欲出，按我们的业务流程去归类、按客户的角色去归类，又回到了那个最初始的问题：客户是谁？核心诉求是什么？
 
 
 
同时，上文中我们提到，模是业务的映射，基于对抽象的理解，我们可以进一步展开：模是在确定抽象角度下的业务映射。
 
 
 
 
 
 
抽象的层次
 
 
 
Wikipedia 关于抽象的定义中有一个关于报纸的例子：
 
 
 
 
 
1. 我的 5 月 18 日的《旧金山纪事报》
 
 
2. 5 月 18 日的《旧金山纪事报》
 
 
3. 《旧金山纪事报》
 
 
4. 一份报纸
 
 
5. 一个出版品
 
 
 
 
这五句话中，我们可以感受到抽象的层次，抽象层次越高，细节越少，普适性越强。再比如下图中关于网络模型的抽象，关于操作系统内核的抽象，我们可以明显的看到不同层次的抽象，就是过滤不同的信息，最终留下来的信息才是当前抽象层次所需要的信息。从系统设计实现上来说，抽象层次越高，越接近设计，越远离实现，同时抽象的模型越不受细节的羁绊，稳定性越高，普适性越强，可重用性就越高。
 
 
 
 
 
 
那么这里抽象的划分层次的依据是什么？原则又是什么？我的经验是，划分抽象层次的依据主要包含两个：
 
 
 
 
以抽象角度分层（可能一层是多角度的聚合）
 
 
面对变化分层（用层次隔离变化）
 
 
 
其实这个也不能完全解释如何分层，原则是什么？我觉得这是几个最通用的原则：
 
 
 
 
公用的往下走
 
 
个性的往上走
 
 
下层可以独立于上层存在
 
 
控制下层的变化
 
 
 
考虑抽象层次的好处是不论在哪一个层次上，我们只需要面对有限的复杂度，从而专心考虑这个层次上的抽象是什么，要表达的信息是什么。
 
 
 
抽象的边界
 
 
 
除了角度、层次之外，我们还需要考虑的抽象的边界。如果说层次考虑的是纵向维度的表达，那么边界考虑的是横向维度的表达。如何确定边界，一个总的原则是按照职责进行划分，这里的职责其实也就是分工。一旦职责确定，我们在做建模分析时就不需要把整个业务大局放进来从头到尾去分析一遍，我们只需要考虑当前分工下的上游和下游即可，这样的信息量大大减少，自然的我们面对的领域复杂度也会降低到一定程度。
 
 
 
如果一定要给出边界的定义，我的理解是：边界是在确定抽象角度下，通过寻找核心的业务活动，抽取核心实体，进一步确定实体核心生命周期的结果。可能有一点点绕，关键词是：核心业务活动、核心实体、核心实体生命周期。
 
 
 
以现场娱乐行业为例，如下这张图包含了最高抽象层次下业务的全生命周期，这个抽象层次下的主体是什么，我的理解是票，项目生产的结果是票，分销或电商服务是对票的销售，现场是对票的核验，至此以票为核心实体的生命周期结束。
 
 
 
 
 
 
如果我们往下 Down 一层，从项目生产这一个业务活动去看，整个业务流程是这样：
 
 
 
 
项目管理->场馆座位分销->票房预测->场次管理->配额管理->绘座->票房规划
 
 
 
从生产这个视角去看，核心的实体不是票，而是场次（确定时间、确定地点、确定内容的一场演出或赛事），所有的关键业务活动都是以场次为维度，生产领域里需要考虑的主要就是场次的核心生命周期。
 
 
 
所以，在不同的抽象角度、不同的抽象层次，根据分工的不同会有不同的核心业务活动、不同的核心实体、边界的确定关键在寻找核心的生命周期。寻找生命周期的过程，就是发现内聚的过程；将所有关于生命周期的业务活动累积，就可以提升领域或模块的内聚性。
 
 
 
抽象的评估
 
 
 
前边我们基本说清楚了抽象的角度、层次和边界，从三个维度确定了抽象的结果。那么如何评估抽象结果的好坏呢？答案是“高内聚，低耦合”，当然还有更多的原则，但是单从实践的角度，我觉得这是最最重要的。
 
 
 
 
 
耦合是软件结构中各模块之间相互连接的一种度量
 
 
内聚是一个模块内部各成分之间相关联程度的度量
 
 
 
 
“高内聚，低耦合”从内部、外部两个视角去评估抽象结果的好坏。这其中也有对应的原则和方法论，常规的套路是：
 
 
 
 
每次从一个角度来切分，然后换多个角度来审视
 
 
通过组合、拆分来精化、优化模型与设计（抽象的结果）
 
 
关键的审视点：
 
 
耦合性：减少模块间通信量
 
 
内聚性：功能单一化
 
 
变化的隔离性：减少信息依赖，建隔离层、虚拟层
 
 
 
抽象的方法论（套路）
 
 
 
我想，至此，我们说清楚了前面的那两个问题：
 
 
 
 
业务建模中“把书读薄”归类汇总，建立“大局观”，形成大图，这里按什么维度去归类？如何判断归类是正确的？
 
 
 
 
系统建模中“剥洋葱”怎么拆？按什么拆？上述架构图中的层次、领域如何划分层次？边界在哪里？
 
 
 
总结前面说的所有关于抽象的内容，形成抽象的方法论（套路）：
 
 
 
 
抽象有两种方法，一种是自顶向下，另一种是自底向上
 
 
 
 
业务建模，是从小到大，从局部到整体，自底向上的归纳、演绎的抽象过程
 
 
 
 
系统建模，是从大到小，从整体到局部，自顶向下的拆解、切分的抽象过程
 
 
 
 
但不绝对，自上而下和自下而上，往往在过程中是随意切换的
 
 
 
下面这张图来自于《Thinking in UML》，我觉得这个循环的过程可以表达上面这四个点，供大家参考。
 
 
 
 
 
 
如何画好一张架构图？
 
 
 
回到主题，如果上边的问题说清楚了，接下来的事情就相对简单了。对于架构图是什么这个问题，我们可以把之前的等式进行延展：架构图 = 架构的表达 = 架构在不同抽象角度和不同抽象层次的表达，这是一个自然而然的过程。不是先有图再有业务流程、系统设计和领域模型等，而是相反，用图来表达抽象的思考和内容。
 
 
 
那么架构图有什么用？给谁看？回答这个问题需要讲清楚为什么要画架构图，同时也需要考虑一个问题就是：架构图是不是越多越好，越详细越好？
 
 
 
画架构图是为了什么？
 
 
 
A picture is worth a thousand words （一图胜千言），从 Why 层面讲，我觉得就是如下两点：
 
 
 
 
解决沟通障碍：达成共识、减少歧义。
 
 
 
 
提升协作效率：团队内部和团队之间的协作、沟通、愿景和指导。
 
 
 
但是上述两点其实是非常笼统的信息，如果放在 What 层面，我们必须要考虑架构图面对的“客户”，不同的客户有不同的诉求（其实也就是角度和层次），在不同的抽象层次架构图所表达的信息内容可以完全不一样。以目前团队做的事情为例，架构图的目标客户至少有几类：
 
 
 
 
参与项目的各团队各角色（业务、产品、开发、测试、安全、GOC）
 
 
项目之外的客户（外部客户，外部评审专家）
 
 
各层次 TL（汇报，跨 BU，跨团队协作沟通）
 
 
 
所以画架构图，我们必须首先明确沟通交流的目的和面向的客户，只有明确了这两个点才能更加有针对性的达成上边所说的那两点目标：解决沟通障碍，提升协作效率。
 
 
 
怎么画？
 
 
 
先说分类
 
 
 
架构图分类，本质上是从不同的视角，不同的抽象角度去看，作出清晰、简化的描述，涵盖特点方面忽略无关方面。
 
 
 
从业务应用开发的维度，一般的抽象层次可以分为：
 
 
 
 
业务全域—>子域—>模块—>子模块—>包—>类—>方法
 
 
 
这其中：
 
 
 
 
较低层次的抽象：应用内部包图、类图；某个领域：实体图、时序图、状态图、用例图等等。
 
 
 
 
较高层次的抽象：具有一定的复杂性，比如微服务架构，系统间的交互图，领域/子领域架构图，整个系统架构图等等。
 
 
 
当然，还有很多其他的分类方式，比如：RUP 4+1，GOGAF9 等等分类方式。单从实践的角度，我觉得何种分类不是最重要的，最重要的是想清楚面向谁和解决什么诉求，然后思考架构图到底从哪个角度、哪个层次去抽象。我们目前所做的项目，有很时候要去和国外的业务专家、技术专家去沟通，大家也并没有一个明确的标准定义，表述清楚问题，达成共识这是最最关键的，至于架构图的粒度、类别、内容可以逐步的去完善，去粗取精，迭代优化。
 
 
 
再说构图
 
 
 
构图的部分，我们大家都用 UML 画过类图，涉及泛化、聚合、组合、依赖等等关系，分别用不同的虚实线、箭头样式进行表达。所以画架构图需要考虑架构图的组成元素，要保证符合一贯理解，架构图的组成元素可能涉及：
 
 
 
 
方框、各种形状、虚实线、箭头、颜色（不同颜色代表什么意思）和文字内容
 
 
 
 
虚实线表达什么？组件类型，模块类型，层，服务，需要考虑是否已经实现等？不同状态的标识怎么传递？
 
 
 
 
箭头表达什么?数据流或关联关系？
 
 
 
 
交互类型可以是同步或异步的；关联类型可以是指依赖、继承、实现
 
 
 
构图最最重要的是需要考虑内容术语一致性问题、碎片化问题、信息粒度大小的问题，以及图表的外观问题。
 
 
 
如何评判架构图的好坏
 
 
 
架构图的好坏，我理解主要是两个方向，一个是需要跳出图本身去看，业务领域的抽象设计合理性，是否符合“高内聚，低耦合”的要求，这个需要回到前文的业务建模、系统建模和抽象过程去寻找答案。另外一个方向是图本身，以下几个点供参考：
 
 
 
 
内容术语一致、信息粒度大小一致，图例清晰，颜色类型统一，美观
 
 
 
 
图中的信息与相应的抽象级别相关，且满足利益相关者(合作方)的需求
 
 
 
 
一张好的架构图不需要多余的文字解释！受众有没有准确接收到想传递的信息；如果它所导致的疑问比它能解释的问题还要多，那么它就不是一张好的架构图
 
 
 
 
架构图应该帮助每个人看到大局，了解周围的环境，适当的上下文信息
 
 
 
 
架构图应该避免“只见树木，不见森林”
 
 
 
但是，终归还是那句话，“一张图片胜过千言万语”。不管好坏，不管是否美观，人是视觉动物，用图表达可以极大的提升沟通效率，先画起来吧！
 
 
 
最后也聊聊架构师
 
 
 
这是来自于阿白老师的文章《架构师到底是做什么的？》，越是琢磨，越觉得深以为然。其中提到了好的架构师的画像和不好的画像，如下图，与大家共勉。
 
 
 
 
 
 
从我个人的成长经历看，架构师很重要的一点要学会“权衡”，既要兼顾当下痛点也要符合未来一定时间的发展，既要保留未来的可扩展性也要避免过度设计。选择什么样的时间节点、什么样的业务场景以及什么样的架构迭代策略至关重要，这些决策的关键在于判断和取舍，需要结合深刻的业务思考乃至组织架构去做权衡落地。一点点不算经验的经验：
 
 
 
快速学习
 
 
 
快不是一个速度问题，也是一个判断或者标准问题。面对一个全新业务场景，如何能够识别20%的关键业务路径，关键业务痛点，如何短时间把自己变成业务专家这是一个架构师基本的素质。我的一点经验就是要去「吸金式」的思考，带着问题主动思考，客户是谁？有什么诉求？需要解决什么样的问题？我们能提供什么样的价值？多问为什么？这也需要长时间的刻意训练。
 
 
 
不要屁股决定脑袋
 
 
 
要跨角色、跨层级去看待业务问题，这个点容易陷入说教，说实话我自己做得也未必到位。但是时刻提醒自己的思考是否被局限，在哪一个维度，是 Have-do-be，还是 be-do-Have 等等；同时也不断的在提醒自己永远不要屁股决定脑袋。
 
 
 
提升思考能力和对于技术原理或本质的理解
 
 
 
我觉得这是最底层的能力，业务开发中我觉得最大的两个难点：一是逻辑的复杂性，二是需求的变化性。我们不应该大部分时间花在寻找解决方案上，而应该花更多的时间在选择解决方案上。这就要求我们对业务全局、行业深度、技术视野、技术深度、业务共性、个性特征等等形成自己的认知。权衡取舍，取什么舍什么？该怎么取怎么舍？那个度在哪里？唯有思考，自驱，累积和坚持，勇猛精进，志愿无倦。
 
 
 
最后的最后
 
 
 
希望这篇文章对大家有帮助，附上最初在考虑这个主题时的构思过程及思考路径，供大家参考。
 
 
 
 
 
 
 

 
    
 
        
 
             
 
            
 
             如何绘制业务流程图
             
 
            
 
 
 
 
            
 
 
图1：用即时贴与白板做的简单流程图
 
本文会包含几块内容：
 
1. 什么是流程图？流程图和其他图表（如线框图，概念图，架构图，用例图）有什么不同？
 
2. 为什么需要流程图？
 
3. 流程图的分类？
 
4. 如何绘制流程图？
 
5. 流程图绘制工具
 
视篇幅情况，会在行文时略加划分为系列，敬请关注并多多交流。
 
第一部分：什么是流程图？
 
 1. 定义
 
了解一个事情，我习惯从它的定义开始。至于为什么，可以参见我之前的博客文章http://heidixie.blog.sohu.com/161709085.html
 
我们因为厌恶十年教育，厌恶背各种定理和定义，所以我发现生活中和工作中很多人都很讨厌给一个事情下定义以及去参考定义。所以你会发现很多人在一起争吵得不可开交，仔细去听，原来是鸡同鸭讲，根本不在一个频道上。对于一个事情的描述，没有一个共同的语言，没有所谓的术语。有定义很好办，你们共同引用一个定义，发现定义有问题，OK，去补充这个定义，并扩展到更多的人群。当然，任何事情过犹不及，我们相互提醒吧。
 
那什么是流程图呢？说文解字是一种了解定义的好方法。流程图=流程+图，如下图：
 
 
图2：流程图的定义
 
流程：Flow,是指特定主体为了满足特定需求而进行的有特定逻辑关系的一系列操作过程，流程是自然而然就存在的。但是它可以不规范，可以不固定，可以充满问题。所以就会造成看似没有流程。前不久，团队每个人对接一个业务团队去调研流程，反馈给我的流程有一些缺失。询问时，负责人反馈给我的答复是：这一块业务他们没有流程。其实严格意义上讲，业务已经开展，不可能没有流程，只是说没有固定的流程或者你调研的对象也讲不清楚。
 
图：Chart 或者 Diagram, 是将基本固化有一定规律的流程进行显性化和书面化，从而有利于传播与沉淀、流程重组参考。
 
从定义可以看出，只要有事情和任务，流程就会有，但是并不是所有的流程都适合用流程图的方式去表现，适合用流程图去表现的流程是一定程度固定的有规律可循的，流程中的关键环节不会朝令夕改的。
 
 2. 流程图与其他图表的对比
 
工作中我们还用到或听到很多其他类型的图表，比如交互设计师们经常说的线框图(Wireframes)，信息架构图或站点地图(Site Map)，，开发工程师们经常说的用例图(Use Case)或E-R图。这些不同的图表要表达的内容有何种差异呢？简单做个对比，如图
 
 
图3：流程图VS其他常用图表
 
如果要串到某一个项目来说，可以理解成：
 
用例图（Use Case）：
 
表现了一个角色在系统里要完成的活动是什么，比如用户这个角色与ATM取款机的交互过程中，用户需要完成的活动有存钱，取钱，查询等。而存钱这个活动再可以进一步细分为插卡，输入密码，输入金额，ATM吐钞，用户收款，退卡等活动。用例图可以不考虑用户动作的前后次序，而仅仅提取一些关键的动宾短语，映射出系统应该满足的功能点。常用用例图的人是产品经理和开发工程师。
 
流程图则表示用户每一个活动的前后次序，比如用户必须要先插入银行卡，才能够输入密码，且流程图必须直接表现出各种异常判断，比如当密码错误时，出现什么提示，密码输入错误超过多少次时，出现什么提示和动作。常用流程图的人是产品经理，设计师，或者任何需要讲述业务如何运作的人。
 
信息架构图,站点地图(Site Map)：
 
表现为了做一个这样的系统，功能与内容的展现层次是什么，比如用户一进去后，欢迎页面的导航如何设计，是否直接出现取款，存款，查询，或者还有别的导航？常用信息架构图的是设计师。但是常用组织架构图的是HR。
 
线框图（Wireframe）：
 
将具体每个界面的内容布局和权重表达出来，且标注出一些交互细节的设计，比如当密码错误后，如何提示下一步动作。常用线框图的人是设计师。
 
实体关系图(E-R图):
 
则是数据库架构的工作，表示一个业务系统或场景中的实体时间的关系，比如储户与银行卡的关系是归属1对多，通过开卡事件产生关联。一般来讲，用矩形来表示实体，椭圆标识这个实体的属性，比如储户这个实体的属性有：姓，名，手机号码，住址等。而银行卡的属性有：开户行，开户名称，银行卡号等。
 
以上的这些图表各自都有领域的专家，我这里就不班门弄斧了。
 
那么流程图要体现出他的差异定义，要素是什么？总结出了流程图的6大要素，希望大家能够记住，这6个要素可以在以后的文章里不断回顾，你也可以拿来判断你所看到的流程图是否专业。
 
 
图4：流程图6大要素
 
参与者：谁在这个流程中？可以是系统，可以是个打印机，更多的指什么角色——一般是有某种工种的人。比如客服同时有小A和小B两人，但是若他们的工作性质完全一样，那么在流程图里只需要写一个客服角色就可以了。
 
活动：做了什么事，比如点餐，结帐等活动。
 
次序：这些事情发生的前后顺序如何，哪个任务是其他任务的前置条件？比如客人不结帐，就不会产生送他优惠卡的活动。
 
输入：每项活动开始取决于什么样的输入物或数据，比如做饭的师傅开始做菜时，需要拿到具体的点菜单。
 
输出：每项活动结束后，会输入什么样的文档或数据传递给下一方，比如师傅做好菜后，如何让负责传菜的人知道菜已经做好？
 
标准化：采用一套标准化的符号用以传递你的流程图，从而使受众更快明白。
 
关于流程图的标准化，并不是强制的，事实上，我们见过很多种类的流程图，只要能够传递明白任务和次序其实已经归类于流程图了。如下面的图：
 
 
但是若在一个公司的环境下，你的流程图的受众又非常多的话，采取标准化的符号会带来很多交流上的好处，总之你懂的。
 
第二部分：流程图的分类？
 
常见的流程图有业务流程图（Transaction Flow）, 页面流程图（Page Flow）。
 
在工作中，作为UED，你可能会发现PD经常谈的是业务流程，而作为交互设计师，我们更多产出的是页面流程图。页面流程图和业务流程图到底有什么关系呢？ 先有谁，其次再有谁呢？
 
先讲个故事：假设你的梦想是开个中高档的全国连锁餐馆，那么首先你想到的应该不是如何去选址，而是将为何要开连锁餐馆这件事情，以及你的定位，核心竞争力想清楚。是快餐，还是点餐，是连锁还是加盟？定位于社区还是繁华商圈？是川菜还是江浙海鲜？是面向中老年还是年轻人？是家庭主题还是动漫主题？竞争对手是谁？需要什么样的投资？可能的风险是什么？这些都想清楚了，问题都有答案了，所谓战略层要清晰了吧。然后假设你现在分析来分析去，与主要投资方决定了一个方向：面向年轻人的时尚动漫茶餐厅，连锁，但是先在杭州开始第一家，选址定位于年轻人约会，扫街的地域，比如风景区，著名商圈，电影院旁…………等等等等，那么接下来呢？
 
接下来就是想办法让这些实现吧？那么需要做什么事情呢？选址？拉投资？搞装修？选餐饮菜单？雇佣员工？每一步怎么去做，时间点是什么？等等的任务拆解以及计划，就需要到战术层了。
 
这些事情的执行，总是需要请人的吧？先是核心团队分工去部署各项建设任务，当餐厅开设起来后，就需要组织稳定的运营团队，如服务、卫生、厨房、采购、人事等等，厨房里面还得分工，白案，热菜，冷菜等等吧？每个部门需要设置管理层以及汇报关系吧？所以你的组织结构就诞生了。
 
那具体每种角色是如何顺畅合作完成日常稳定的以及突发的各项任务呢？比如，当顾客上门时，谁去引导客人入座，谁去点菜，怎么将点菜的讯息迅速传递到厨房，并分发到酒水间、冷菜间、热菜间？并保证客人尽快能够吃到所点的菜？你必须要考虑各种人员的协作流程，优化效率，所以业务流程就出现了。
 
人肉运营了一段时间，没有借助任何点餐系统，你发现也还可以。客人点菜时，服务员手抄写下客人的要求，因为有复印纸，所以服务员能够将副本送入厨房，同时写下餐桌号码。厨房规模较小，负责分配任务的员工看下菜单，分别往冷菜处的黑板上写下需要他们处理的，以及跑到热菜区的黑板上写下待处理的菜品，以及去酒水间报下品名即可。可是随着经营的扩大，以上的人肉方式出现了很多问题，首先，手抄效率太低，顾客频繁换菜，响应来不及，手抄出错，导致经常报错菜。厨房很混乱，不得不多招了几个人专门跑堂。而一旦顾客要加菜，撤菜就更麻烦了，需要找出他们当时点的菜，再进行人工的批注和修改，同时要修改厨房后端的各个黑板……
 
所以你们想要开发一套智能系统，取代很多人肉工作，你们请了系统开发团队，他们经过评估，判断从点菜开始，一直到传菜都可以用系统解决。手持终端，能够快速传递顾客点菜需求到打印机，打印系统能够根据顾客点菜的类型进行自动的分单打印，所以热菜间看到自己的热菜菜单，冷菜间看到自己的冷菜菜单，而酒水间看到酒店菜单。当他们准备完毕后，送出，传菜员可以根据菜名与打印出来的单据进行传菜并根据顾客的点菜小票进行核对。这套系统同时必须配备结算系统，将最终确认掉的菜单及消费价格传递到结算前台，收银员能够快速进行操作。
 
这套系统最终是需要展现出来的，那么手持终端的界面如何设计？服务员能够用更少的点击完成一个菜的点餐吗？结算中心的界面如何设计？
 
通过以上的故事，是不是更明白从战略、战术、业务流程图到页面流程图的关系了？总结下：
 
先是有一个业务需求和业务目标，也即我们的愿景是什么？（战略）
 
然后就诞生了我们需要分解出什么样的任务，如何执行战术？（战术）
 
然后就诞生了需要架构什么部门，岗位去分工协作？（组织架构）
 
然后就诞生了不同的部门在协作完成某件任务时的业务流程？（业务流程）
 
业务流程基本稳定后，往往会考虑优化效率，所以会诞生出系统来支持流程，减少人肉环节，促进数据采集（系统愿景）
 
为了设计这个系统，PD需要思考什么功能能够取代某个环节的人肉工作（功能需求，系统流程）
 
不管是怎么样的功能最终都会以界面的方式呈现，设计师们会关注用户在系统里的任务流，行为路径，让用户完成任务更加高效愉悦。（页面流程）
 
当然，除了业务流程，系统流程，页面流程，还有数据流程被人关注。
 
我们平时工作中，还会经常听人谈到泳道图啊，任务流程图啊等等概念，究竟是神马关系呢？
 
 
图5：流程图的分类
 
本文着重于上述流程中的“业务流程图”——并会分享如何绘制泳道图——也即是PD们最多使用，技术们最多参考，UED们最多看到的流程图。
 
本来在第四部分会对泳道图的图示以及绘制方法、原则做更详细的说明，但是看目前的篇幅情况，预计会放到下篇，所以先在这里简单说明下吧。
 
在工作中，我们经常能够看到两种业务流程图，从表现形式来看，一种很好区分，俗称为“泳道图”的它，在样子上也确实像个泳道，可以有横向的泳道，也会有纵向的泳道。泳道图在某些文档里会被称为“以活动为单位的流程图”，浮在泳道中的都是一个个活动。
 
 
另外一种类型是以部门和岗位为单位的流程图，下图中的圆形就代表一个个部门或岗位。矩形代表活动。这种流程图关注事情如何完成的逻辑，但是在体现各个部门的责任上比较弱。如果是某个岗位的人来看，很难像泳道图那样一眼就能看到自己部门的职责和任务。所以现在用得比较少。
 
 
再回过头来说泳道图，泳道图有几个关键点：两大维度，活动流转，流程要素。我们会在以后详解。
 
 
第三部分：为什么需要业务流程图？
 
流程图可以提供一种简单扼要的“缩略俯瞰图”，帮助观众快速了解业务如何运转。它包含了几个关键词：谁，什么时候，在什么条件下，做了什么事情，输入什么，输出什么，输出给谁……
 
与系统流程不同，业务流程更关注于业务本身如何运作，讲的是业务故事，包含的是业务规则。而系统流程则是满足业务流程，实现部分流程或全部流程的信息化和系统化。
 
所以业务流程是所有环节的前置条件——软件需求分析，信息系统建设也会先进行业务流程的梳理。
 
下面表现了业务流程图是如何在三个主要场景中发挥作用的：
 
 
 1. 员工培训
 
 
图6：流程图的应用场景之一：培训
 
在此场景中：流程图能够提供一种快速了解业务如何运作的视图，通过业务流程图，新员工能够快速明白业务的最终目标是什么，中有哪些角色在参与以及他们的职责，以及彼此之间的联接。
 
除了培训新员工，在员工轮岗、调职场景中，员工也需要业务流程图参考，明白新的工作内容如何开展，以及自己所处的位置，自己的上游是谁，下游是谁，自己需要交付的工作内容是什么。
 
 2：流程优化与重组
 
 
图7：流程图的应用场景之二：流程优化
 
业务流程重组（Business Process Reengineering）的存在可以明确反驳：存在即合理。事实上，存在的业务流程并未是合理的，有可能是参与的多个角色习惯了某种做法，有可能是变革尚未影响到末端的操作，也有可能缺乏对于运行中的业务流程问题的洞察以及强有力的变革推动——因为要推动业务流程变革，不是某个部门的事情，而是需要流程中各个部门的通力配合。
 
更多时候，业务流程优化是自上而下的，但是老板们未必对实际运作的业务流程那么心知肚明，业务流程图能够很好去表现这个“运作模型”。通过看业务流程图，找关键节点的人访问，能够直接切入：为什么要这么做，为什么不这么做？从而探索出更深层次的问题，而不是问：你们现在怎么做？
 
通过调研，分析业务流程图，引入更多角色，能够分析出目前业务流程的问题：缺失，重复，风险，效率等等。从而制定相应的优化方案。
 
 3：信息化的基础/p>
 
 
图8：流程图的应用场景之三：信息化基础
 
正如上文所述的餐馆梦想的案例，信息系统的一项任务就是解放员工的手脚，取代一些重复的人力劳动工作。系统上了之后，不是说业务流程不需要而是经过了一些调整，其中某个参与者变成了系统，或手持设备，或打印机而已。
 
那么在做系统的功能设计和系统流程设计时，是不是必须先要了解目前业务是如何运作的呢？从而更好分析分析，更好说明系统在什么环节取代了什么类型的人肉工作？
 
所以我们看到的PRD往往也会先以业务流程图开始说明，而叙述一个系统建设的好处时，也可以用以前的业务流程与系统上了之后的业务流程进行对比。根据分析，将愿景中的新的业务流程图背后需要系统的功能点撰写清楚。
 
第四部分：如何绘制业务流程图？
 
首先绘制业务流程图本身有没有流程？一定是有的。在软件工程学里听说一句话叫：万物皆对象。那么在流程学里，万事皆流程。吃饭难道没流程吗？就吃饭的动作而言，就有流程：拿筷子——夹菜——入口——咀嚼——吞咽。
 
有不少同学在这一部份很快想会问一个问题：Heidi，请介绍画流程图的工具吧？
 
我个人是工具派，从不否认人工欲善其事，必先利其器的道理。好的工具本身就是一名好的老师，除了技能，也能够教会我们一些理论与理念，这些理念也是“器”中很重要的一部分。其次才是具体的工具应用技能。所以我并不建议直接跳转到工具应用。对于初学者而言，笔与纸永远是最好的入门工具，因为你无需和任何一个陌生的软件较劲。
 
那么，绘制业务流程图有没有可遵循的流程呢？我建议可以从下面4步着手。
 
1. 调研
 
如何快速了解业务运作真相？有没有调研的技巧放送？
 
2. 梳理与呈现
 
能否快速将调研得到的文字和问题，快速转化为业务流程图？
 
业务流程图的标准图示是什么？
 
怎么评价一个业务流程图的好与坏？
 
3. 评审与确认——能否真正让业务流程图反映现实中的业务？
 
4. 归档维护——流程不断变更，业务流程图如何快速响应？
 
这些将会在下篇《业务流程图的绘制流程分享(二)》详解。
 
第五部分：绘制工具？
 
如果不搞工具研讨会的话，这部分比较简单.
 
Windows: 线下工具大家常用的就是下面三个：
 
小的流程图用用PPT就够了，完了就导出图片或截图。交互设计师们因为常用axure绘制线框图，所以也不必为了流程图去学习新的工具，完全可以用axure的flow控件完成简单的业务流程图的制作。而PD们则常用微软的visio。
 
业务流程图绘制流程分享(二)
 
 
业务流程图的表达的6个关键问题
 
接上篇《业务流程图绘制流程分享(一)》，本篇将对上篇中间的第四部分——如何绘制业务流程图展开更多讨论。
 
本来写完上篇，我发现没有太多必要单纯讨论这一部分内容，因为对于很多人来讲，缺的不是具体的做法，而是做这件事情的意义以及目标性的明确。一旦对这件事情的意义和目标有深刻认同，那自然会产生较大的动力去研究How这个层次的所需方法和技能。时间管理也如此，很多时间管理技巧牛逼的人未必能够把时间管理做到位，因为内心克服不了强大的拖延症，而克服拖延很多时候是一个心理问题而不是技巧问题……咳咳，这不是在说我自己吗？
 
话又扯远了，扯扯扯回来啊。那么为何还专门狗尾续貂（恩，原文也不见得是貂，成语有限，暂时凑合吧），又来这么一篇How的枯燥乏味的文章呢？因为在上篇文章后，Heidi确实在邮件里收到一些邮件，询问业务流程图的具体操作指南——这东西很好，这东西很有用，但是似乎上篇都是讲的“真实的道理”，但是具体怎么做呢？我应该注意什么呢？……
 
所以，干脆也分享一下吧。但在书写过程中，我发现一个大难题在于收集整理出更生动易懂又典型的案例。不能使用工作中的实际案例，但是短时间又难以找到合适的。所以本人对这部分不太满意。也希望各位读到本文的人，能够提供更多案例分享。
 
 1. 业务流程图的“烹饪三部曲”
 
在绘制业务流程图前，思考如何精美，如何交互，使用什么工具，都不应该是重点。
 
真正重点的是将业务流程图的关键要素给搜集一番。请试图回答清楚以下几个问题，否则不要开始绘制流程图：
 
                
整个流程的起始点是什么？整个流程的终结点是什么？
在整个流程中，涉及到的角色都是谁？
在整个流程中，都需要做什么事情？（可是是一个会议，可以是一个任务）
这些会议和任务是可选还是必选的？
分别产出什么文档？
 
这有点像一个头脑风暴，能够帮助你将所需用到的原材料获取到，有了这些“米”和“水”，那就不愁去如何烹饪了。
 
在项目管理中，上个月，我们也试图给去规范化一个数据产品的设计开发流程。
 
这是一个数据产品的项目，而我们都不是对此很有经验的人。所以我们召集到所有相关的角色，组织了一次头脑风暴及卡片分类法的混合式应用。
 
                
让大家头脑风暴出自己认为在项目里必须的节点，如“需求调研”，“需求分析”，“kick off会议”，“PRD撰写及确认”，“数据评估”，“技术架构”，“DEMO绘制”，“指标算法定义”，等等。
在头脑风暴过程中，主持人将这些节点都写到白板上，等没有新的节点诞生后，大家一起对节点进行合并归类。之后呢？
将这些剩余下来的真正有价值的节点，撰写到即时贴上，开始进行排序。在排序过程中，可以由一个人先主导，他会按照自己的理解，将各个节点放到按角色排布的泳道中，并设计好先后的顺序。在他进行的过程中，其他人不断进行提问：“这项任务开始前，需要什么样的条件？”“这个任务是必须的吗？”然后一起调整先后顺序。直到最终没有人有任何重大的异议。
之后拍照留念。
 
 
然后可整理成电子文档，如project或者excel版本（使用excel做项目管理？）
 
 
但是，业务流程图和上述项目中的流程不太相同的是：
 
项目中的各种活动节点有更宽泛的可配置性，任务A和任务B是否并行，还是串行，如果项目组成员达成共识，是可以调整，并且多做尝试的。所以可以用集思广益的做法去头脑风暴出一个暂定比较合理的流程。而业务流程图的梳理，有两种:
 
                
一种是基于现实发生的业务流程如实反映。这显然不是你一个团队能够YY的结果。更需要走到现实环境中，去调研，去梳理，去确认。
另一种是基于流程优化的方案，当你已经掌握了目前的流程现实如何运作时，基于分析，讨论，能够判断出流程中不合理的地方，给出一个更完善或者有更效率、成本更低的新的流程出来——或许你要求增加一个部门，或者你需要删减一个环节，或者中间的若干步使用新开发的系统去取代。
 
总之，大多数时候，你要想做第二种流程图，必然要先将第一种给梳理出来。所以，第一种如实反映的流程图是躲不过的。既然如此，基于YY或者头脑风暴是不现实的。我们需要走到前线去，掌握现实中业务是如何运作的。而且很多时候，越细节越好。
 
那怎么做呢？基于有限的知识与经验，我可以给如下建议：
 
1. 调研——2.梳理呈现——3.评审确认三部曲，如图所示：
 
 
 2. 调研——问正确的问题，多问问题，多问几个人
 
除了在本部分开始的那几个问题要顾及到，其实调研过程解决的仍然是who，what，why，how，以及where的问题：谁，在什么情况下，做了什么事情，这个事情需要什么前置条件，又输出了什么，这个事情在哪里完成的？搞明白这几个问题，我们的调研就可以圆满完成了。
 
流程图的表现，要回答这几个问题：
 
                
Who——谁？部门，角色，岗位
What——什么事情？
Where——在哪里做的？在我梳理的业务流程图上，where更多表示是文档还是各种系统，用来表示信息化的程度。比如当我们梳理中发现，有一项登记，是用excel而不是业务系统来进行的，那么在这里的where就可以表示为：excel文档。
Document——那产生的这份文档叫什么名字？也写出来，代表有文件的传递，而以后要进行信息化的话，此份人肉文档也是需要被消除而被系统取代的。（相反，如果这项工作是在某个系统里操作的，where就可以写成“人事系统”，文档可以继续存在，即该系统中的表单名称：“员工登记表单”）
Condition——条件。在这种条件下，下一个活动还能够继续，即用逻辑链接线的方式来表示一项活动的输入和输出，指向某个活动的箭头就表示此活动的前置输入条件。
Dicision——决策。有些活动会产生一个条件判断，根据不同的判断结果从而走不同的分支流程。比如输入员工信息的时候，可以根据员工之前是否就职过，选择不同的流程，对于已经就职过的，选用之前的工号而不用生成新的工号。
 
 
举个案例（如果不太恰当，请意会）。假设你受命要调研两家餐饮店的业务流程，目的是给他们提供性价比最高的点餐系统。
 
在调研中：
 
                
你首先可以要求精通业务流程的人给你系统讲解一遍。
调研具体操作的人，来验证他给你讲解的是否全面和偏差。
实地观察和记录（花点时间走遍业务流程）
 
三种方式相互结合使用。第一种方法可以让你首先建立一个系统观，了解大体枝干，但是很难切入到可能会出现问题的细节。第二种方法太依赖于问题的质量以及问问题的场景。有很多结论的不正确其实是因为问错了人或者问问题的方法不对。那么就需要借助第三种，在观察中再进行验证。
 
比如，你现在找到了一个厨师：
 
你主要负责做什么菜系？
 
热菜。
 
那菜单都是谁给你的？
 
我们的服务员。
 
她都怎么提供给你？
 
她负责客人点菜后，然后手写一个单子，给我放到窗口上。
 
单子上都会写什么？
 
桌号，菜名等
 
如何客人点的是冷菜呢？
 
恩，有复印本，直接拿一份给冷菜间。
 
那你怎么开始工作呢？从洗菜到切菜，一直烹饪都是一个人吗？
 
哦，不，我只负责烹饪。当接到菜单后，首先我的助理会进行择菜，刀工进行切菜，这样如果有几个菜就完全可以并行。
 当你们做好后呢？
 
放到窗口，按铃，喊桌号和菜名，传菜员就会传菜。
 ……
 
在这些问题中，就涉及到了“分单”，“切菜”，“择菜”，"烹饪"，“传菜”，“上菜”几个活动，也涉及到了“服务员”，“厨师”，“助理”，“刀工”，“传菜员”几个角色。几个活动的次序也比较清楚了。
 
而另一家餐饮店的业务流程却是不一样的，你同样抓住一个厨师进行询问：
 
要做什么菜，菜单是哪里来的？
 
打印出来的。
 
所有菜都会在这里打印吗？
 哦，只有热菜在这里打印出来，冷菜、酒水就会在冷菜间和酒水间打印出来。
 
打印机是谁在操作的？
 
没人操作，它会自动打印不同的单子给我们。
 
……下面的问题，可能厨师就不了解了，要问点菜员了。
 
请问你是怎么点菜的？
 
拿设备啊，客人点菜就按几下，确认就好了。
 
之后呢？
 
之后就可以将菜单打印出来。
 
不同的菜系会在不同的烹饪间打印吗？
 
是的，我们可以分单打印。是在这中心打印机里完成分单。
 
然后，你可以继续调研烹饪后的传菜和上菜流程。
 
 3. 梳理并呈现
 
你的调研和观察使你拥有了“烹饪”所需的原材料。
 
                
角色：部门、岗位或人
活动：做了什么事情
次序：做这些事情的次序如何
规则：什么情况下到什么事情
 
还记得我们之前提过的流程图要素吗？回顾下：
 
 
接下来的任务是不是很简单，对，就像填空题一样简单。将活动/事件按照一定的规则填到由部门和时间两条维度决定的框框里。
 
这个阶段是paper work，你需要将调研阶段收集到的原材料用更直观明了的方式呈现出来。从而能够更好进行评审和确认。也为以后的流程评审和优化做准备。
 
在刚开始，笔和纸的原始搭配仍然是最好的起步工具。你可以暂时忽略掉美观或者可复用的因素。但是当你对要呈现的流程已经有足够的信心时，就可以借助软件工具了。
 
3.1 复杂流程的分解
 
不可能将所有的活动都放到一张图里呈现。
 
“业务流程是有层次性的，这种层次体现在由上至下、由整体到部分、由宏观到微观、由抽象到具体的逻辑关系。这样一个层次关系符合人们的思维习惯，有利于企业业务模型的建立 企业部门之间的层次关系表。一般来说，我们可以先建立主要业务流程的总体运行过程（其中包括了整个企业的大的战略），然后对其中的每项活动进行细化，落实到各个部门的业务过程，建立相对独立的子业务流程以及为其服务的辅助业务流程。”
 
——引自《百度百科》 业务流程词条
 
对于很多新人来讲，业务最难的在于划分业务流程图的层次上。
 
首先，明确你要梳理的业务流程的范围——用大的粗略的关键节点，讲清楚这个业务流程范围中的故事，就是顶层业务流程图。你的顶层业务流程图是业务全局故事的简单表达，但是请注意这里的业务全局不见得是公司整体的业务全局，而是你界定好的业务范围。比如，下图是餐厅的日常运作流程图，若你界定的业务范围是面向顾客的点餐和结帐流程，那么这就是顶层业务流程图。但是若你界定的是整个餐厅的运作业务流程，那这显然还是一个子集——并没有包含餐厅的采购、供应商管理、一级库存管理等工作。
 
 
其次，先从顶层的业务流程分解开始，由粗至细。顶层业务流程图的梳理原则：
 
                
界定范围内的业务全局故事。
包含该范围内的关键节点。并且，当被质疑说某某环节怎么不存在时，自己要清楚它在下一层分解中应该被包含在那个关键节点中。比如，赠送10周年优惠券，应该会在结帐节点分解中出现。而打印分单，会在点菜节点中分解。而准备儿童座椅应该是接待入座环节。
顶层流程图分解出来的关键节点未必都会细化分解下去，生成二级以及三级的流程图。这要看该节点涉及到的“活动”以及“角色”是否复杂。
 
再看一个案例，对传统生产型企业的进销存主业务流程进行分解。橙色的代表被分解点，已经可以分解为四层。当我们分解到第四层，发现再往下去涉及到的活动和角色都已经很少时，就不必再分解了，而是可以将第四层的关键节点直接作为第三层业务流程的“活动”，而不是子流程图。
 
当然，这是依赖于你梳理业务流程的目标。如果你偏偏是要对“打样”环节进行剖析优化，则还可以继续分解下去。
 
 
这一步的工作会帮你建立出清晰的流程目录结构，如下图所示是摘选于刚完成的一个流程梳理的项目中的目录结构部分。可以看到全图即是顶层关键节点，作为老大，可能只要看这一层就够了。下面则会对顶层做更多细化拆解。
 
“H3.样品认证”在顶层业务流程图中，仅仅是一个“活动”，而在自己细化的这一个层次中，则会包含详细的子活动一级参与者
 
 
3.2 流程图的常用图示
 
 
我常用的就是前两行的“活动”，“判断”，“逻辑关系线”，“起始与终止”，以及第二行的“子流程”，和“文件/表单”。如果你不是符号控，我建议这几个就足够了。
 
其中，“子流程”此图示就是可以帮助你将流程分解得到的子流程能够串联起来，比如，当在"A流程"中涉及到进一步需要分解的"A1.1流程"时，就可以在"A流程"中用子流程符号代表“A1.1”。然后你的读者就会明白要想进一步了解"A1.1"应该参考另外一个流程图。
 
流程图的常用结构：
 
 
给大家看一些案例：
 
基本上包含大多数图示的流程图：
 
 
文档地址：http://www.ais.npic.edu.tw/ais/971%20materials/DfdSfPm_20080724.pdf
 
只用到少数几个图示画的简单流程图（台湾人的文档中称为程序图——不过这里的程序不是指计算机程序，而是process，仅仅是体现任务之间的处理流程，所以使用极简单的符号也不为怪了）：
 
 
以上两个流程图案例，从符号的复杂程度上来讲，一个是完整流程图，一个是基本流程图，但是从表现形式来讲，都属于“泳道图”——Swimlane。这也是我们最常用的一种表现形式了。泳道图能够很好体现部门或者角色在流程中的职责以及上下游的协作关系。且流程图本身的标准容易掌握，达成共识也就更加容易。
 
3.3 泳道图精要
 
 
                
大维度：一般泳道图的横向会作为部门或岗位维，当然也有例外，如上述案例中就是横的泳道。而纵向则做为阶段维——时间是从上到下发展的。如果复杂的泳道图，在任务分解上可以在阶段维里做一些划分，比如“采购”，“生产”，“销售”，"配送”等
活动流转：活动就像一个游泳员一样，游到不同的泳道中去执行任务。
 
在上文中的软件推荐部分，我推荐过smartdraw工具，此工具还附带了泳道图的模板，大家比较更快能够上手：
 
 
 
3.4 Do vs Donnot 业务流程图的注意事项！
 
DO
 
1. 让涉众参与，不要闭门造车
 
业务流程图包含了你图上的各个参与角色代表，与他们适时确认事情的原本流程，禁止自己YY。
 
2. 恰当的层次分解，不要将所有都铺到一张图上
 
如上所示。
 
3. 逐渐深入，先抓枝干
 
切忌胡子眉毛一把抓。
 
4. 流程一定有开始和结束
 
切忌交付出来的流程图，让读者还来问你：流程的开始点是什么？用清晰的代表开始和结束的符号来完成第一步和最后一步。
 
5. 编号，编号，编号
 
这是让沟通效率更高的优化措施。当你有了编号系统，相当于对你的流程图都赋予了唯一识别身份证号。这比中文名称更有效。比如当我们完成了业务流程图后，负责业务流程规则审核和优化的部门能够清楚在邮件里传达：H5.1流程优化，大家就更明确指的是什么。
 
DONNOT
 
                
自己YY应用的环节而不是现实中的环节
所有的环节都试图放到一张图上
一开始就陷入细节，胡子眉毛一起抓
流程很难让人分清楚从哪里开始，到哪里结束
 
 4. 评审及后续行动
 
验证你是否做到了以上的DO，以及规避了Donnot的做法是什么？
 
很好办，及时与各位进行评审。将各个涉众都叫到一起，给他们看你梳理出来的成果。
 
这会发现一些有意思的事情，除了评审你的流程图是否符合现实外，也会评审目前的业务流程是否符合理想。不同的部门和岗位的代表会在这个评审中，确认当前，也会相互提出意见，甚至吵起来，这不失于做流程优化的一个很好的契机。暂且不表了。
 
 
             
 
 

 
 
 
  
 
   1. 什么是流程图？流程图和其他图表（如线框图，概念图，架构图，用例图）有什么不同？
  
 
  
 
   2. 为什么需要流程图？
  
 
  
 
   3. 流程图的分类？
  
 
  
 
   4. 如何绘制流程图？
  
 
  
 
   5. 流程图绘制工具
  
 
  第一部分：什么是流程图？
  
 
 
 
 
 
   
  
 
   1. 定义
  
 
  

   
 
  
 
  
 
   
 
    那什么是流程图呢？说文解字是一种了解定义的好方法。流程图=流程+图，如下图：
   
 
   
 
    
 
   
 
   
 
    
   
 
   
 
    图2：流程图的定义
   
 
   
 
    
 
   
 
   
 
    流程：
    Flow,是指特定主体为了满足特定需求而进行的有特定逻辑关系的一系列操作过程，流程是自然而然就存在的。但是它可以不规范，可以不固定，可以充满问题。所以就会造成看似没有流程。
    前不久，团队每个人对接一个业务团队去调研流程，反馈给我的流程有一些缺失。询问时，负责人反馈给我的答复是：这一块业务他们没有流程。
    其实严格意义上讲，业务已经开展，不可能没有流程，只是说没有固定的流程或者你调研的对象也讲不清楚。
   
 
   
 
    
 
   
 
   
 
    图：Chart 或者 Diagram, 是将基本固化有一定规律的流程进行显性化和书面化，从而有利于传播与沉淀、流程重组参考。
   
 
   
 
    
 
   
 
   
 
    从定义可以看出，只要有事情和任务，流程就会有，但是并不是所有的流程都适合用流程图的方式去表现，适合用流程图去表现的流程是一定程度固定的有规律可循的，流程中的关键环节不会朝令夕改的。
   
 
   
 
    
 
   
 
   
 
    2. 流程图与其他图表的对比
   
 
   
 
    
 
   
 
   
 
    工作中我们还用到或听到很多其他类型的图表，比如交互设计师们经常说的线框图(Wireframes)，信息架构图或站点地图(Site Map)，，开发工程师们经常说的用例图(Use Case)或E-R图。这些不同的图表要表达的内容有何种差异呢？简单做个对比，如图：
   
 
   
 
    
   
 
   
 
    图3：流程图VS其他常用图表
   
 
   
 
    如果要串到某一个项目来说，可以理解成：
   
 
   
 
    
 
   
 
   
 
    用例图（Use Case）：
   
 
   
 
    
 
     表现了一个角色在系统里要完成的活动是什么，比如用户这个角色与ATM取款机的交互过程中，用户需要完成的活动有存钱，取钱，查询等。而存钱这个活动再可以进一步细分为插卡，输入密码，输入金额，ATM吐钞，用户收款，退卡等活动。用例图可以不考虑用户动作的前后次序，而仅仅提取一些关键的动宾短语，映射出系统应该满足的功能点。常用用例图的人是产品经理和开发工程师。
    
 
    
 
     
 
    
 
    
 
     流程图则表示用户每一个活动的前后次序，比如用户必须要先插入银行卡，才能够输入密码，且流程图必须直接表现出各种异常判断，比如当密码错误时，出现什么提示，密码输入错误超过多少次时，出现什么提示和动作。常用流程图的人是产品经理，设计师，或者任何需要讲述业务如何运作的人。
    
 
   
 
   
 
    
 
   
 
   
 
    信息架构图,站点地图(Site Map)：
   
 
   
 
    
 
     表现为了做一个这样的系统，功能与内容的展现层次是什么，比如用户一进去后，欢迎页面的导航如何设计，是否直接出现取款，存款，查询，或者还有别的导航？常用信息架构图的是设计师。但是常用组织架构图的是HR。
    
 
   
 
   
 
    
 
   
 
   
 
    线框图（Wireframe）：
   
 
   
 
    
 
     将具体每个界面的内容布局和权重表达出来，且标注出一些交互细节的设计，比如当密码错误后，如何提示下一步动作。常用线框图的人是设计师。
    
 
   
 
   
 
    
 
   
 
   
 
    实体关系图(E-R图):
   
 
   
 
    
 
     则是数据库架构的工作，表示一个业务系统或场景中的实体时间的关系，比如储户与银行卡的关系是归属1对多，通过开卡事件产生关联。一般来讲，用矩形来表示实体，椭圆标识这个实体的属性，比如储户这个实体的属性有：姓，名，手机号码，住址等。而银行卡的属性有：开户行，开户名称，银行卡号等。
    
 
   
 
   
 
    
 
   
 
   
 
    以上的这些图表各自都有领域的专家，我这里就不班门弄斧了。
   
 
   
 
    
 
   
 
   
 
    那么流程图要体现出他的差异定义，要素是什么？总结出了流程图的6大要素，希望大家能够记住，这6个要素可以在以后的文章里不断回顾，你也可以拿来判断你所看到的流程图是否专业。
   
 
   
 
    
 
   
 
   
 
    
   
 
   
 
    图4：流程图6大要素
   
 
   
 
    
参与者：谁在这个流程中？可以是系统，可以是个打印机，更多的指什么角色——一般是有某种工种的人。比如客服同时有小A和小B两人，但是若他们的工作性质完全一样，那么在流程图里只需要写一个客服角色就可以了。
活动：做了什么事，比如点餐，结帐等活动。
次序：这些事情发生的前后顺序如何，哪个任务是其他任务的前置条件？比如客人不结帐，就不会产生送他优惠卡的活动。
输入：每项活动开始取决于什么样的输入物或数据，比如做饭的师傅开始做菜时，需要拿到具体的点菜单。
输出：每项活动结束后，会输入什么样的文档或数据传递给下一方，比如师傅做好菜后，如何让负责传菜的人知道菜已经做好？
标准化：采用一套标准化的符号用以传递你的流程图，从而使受众更快明白。
 
   
 
   
 
    关于流程图的标准化，并不是强制的，事实上，我们见过很多种类的流程图，只要能够传递明白任务和次序其实已经归类于流程图了。如下面的图：
   
 
   
 
    
 
   
 
   
 
    
   
 
   
 
    
 
   
 
   
 
    
   
 
   

    图片来源于网络，如有侵权，请邮件告知。
   
 
   

    
 
   
 
   
 
    但是若在一个公司的环境下，你的流程图的受众又非常多的话，采取标准化的符号会带来很多交流上的好处，总之你懂的。
   
 
   
 
    
 
   
 
   
 
    第二部分：流程图的分类？
   
 
   
 
    
 
   
 
   
 
    常见的流程图有业务流程图（Transaction Flow）, 页面流程图（Page Flow）。 
   
 
   
 
    在工作中，作为UED，你可能会发现PD经常谈的是业务流程，而作为交互设计师，我们更多产出的是页面流程图。页面流程图和业务流程图到底有什么关系呢？ 先有谁，其次再有谁呢？
   
 
   
 
    
 
   
 
   

     先讲个故事：假设你的梦想是开个中高档的全国连锁餐馆，那么首先你想到的应该不是如何去选址，而是将为何要开连锁餐馆这件事情，以及你的定位，核心竞争力想清楚。是快餐，还是点餐，是连锁还是加盟？定位于社区还是繁华商圈？是川菜还是江浙海鲜？是面向中老年还是年轻人？是家庭主题还是动漫主题？竞争对手是谁？需要什么样的投资？可能的风险是什么？这些都想清楚了，问题都有答案了，所谓战略层要清晰了吧。然后假设你现在分析来分析去，与主要投资方决定了一个方向：面向年轻人的时尚动漫茶餐厅，连锁，但是先在杭州开始第一家，选址定位于年轻人约会，扫街的地域，比如风景区，著名商圈，电影院旁…………等等等等，那么接下来呢？
   
 
   
 
    
 
   
 
   

     接下来就是想办法让这些实现吧？那么需要做什么事情呢？选址？拉投资？搞装修？选餐饮菜单？雇佣员工？每一步怎么去做，时间点是什么？等等的任务拆解以及计划，就需要到战术层了。
   
 
   
 
    
 
   
 
   

     这些事情的执行，总是需要请人的吧？先是核心团队分工去部署各项建设任务，当餐厅开设起来后，就需要组织稳定的运营团队，如服务、卫生、厨房、采购、人事等等，厨房里面还得分工，白案，热菜，冷菜等等吧？每个部门需要设置管理层以及汇报关系吧？所以你的组织结构就诞生了。
   
 
   
 
    
 
   
 
   

     那具体每种角色是如何顺畅合作完成日常稳定的以及突发的各项任务呢？比如，当顾客上门时，谁去引导客人入座，谁去点菜，怎么将点菜的讯息迅速传递到厨房，并分发到酒水间、冷菜间、热菜间？并保证客人尽快能够吃到所点的菜？你必须要考虑各种人员的协作流程，优化效率，所以业务流程就出现了。
   
 
   
 
    
 
   
 
   

     人肉运营了一段时间，没有借助任何点餐系统，你发现也还可以。客人点菜时，服务员手抄写下客人的要求，因为有复印纸，所以服务员能够将副本送入厨房，同时写下餐桌号码。厨房规模较小，负责分配任务的员工看下菜单，分别往冷菜处的黑板上写下需要他们处理的，以及跑到热菜区的黑板上写下待处理的菜品，以及去酒水间报下品名即可。可是随着经营的扩大，以上的人肉方式出现了很多问题，首先，手抄效率太低，顾客频繁换菜，响应来不及，手抄出错，导致经常报错菜。厨房很混乱，不得不多招了几个人专门跑堂。而一旦顾客要加菜，撤菜就更麻烦了，需要找出他们当时点的菜，再进行人工的批注和修改，同时要修改厨房后端的各个黑板……
   
 
   
 
    
 
   
 
   

     所以你们想要开发一套智能系统，取代很多人肉工作，你们请了系统开发团队，他们经过评估，判断从点菜开始，一直到传菜都可以用系统解决。手持终端，能够快速传递顾客点菜需求到打印机，打印系统能够根据顾客点菜的类型进行自动的分单打印，所以热菜间看到自己的热菜菜单，冷菜间看到自己的冷菜菜单，而酒水间看到酒店菜单。当他们准备完毕后，送出，传菜员可以根据菜名与打印出来的单据进行传菜并根据顾客的点菜小票进行核对。这套系统同时必须配备结算系统，将最终确认掉的菜单及消费价格传递到结算前台，收银员能够快速进行操作。
   
 
   
 
    
 
   
 
   

     这套系统最终是需要展现出来的，那么手持终端的界面如何设计？服务员能够用更少的点击完成一个菜的点餐吗？结算中心的界面如何设计？
   
 
   
 
    
 
   
 
   

     通过以上的故事，是不是更明白从战略、战术、业务流程图到页面流程图的关系了？总结下：
   
 
   
 
    
先是有一个业务需求和业务目标，也即我们的愿景是什么？（战略）
然后就诞生了我们需要分解出什么样的任务，如何执行战术？（战术）
然后就诞生了需要架构什么部门，岗位去分工协作？（组织架构）
然后就诞生了不同的部门在协作完成某件任务时的业务流程？（业务流程）
业务流程基本稳定后，往往会考虑优化效率，所以会诞生出系统来支持流程，减少人肉环节，促进数据采集（系统愿景）
为了设计这个系统，PD需要思考什么功能能够取代某个环节的人肉工作（功能需求，系统流程）
不管是怎么样的功能最终都会以界面的方式呈现，设计师们会关注用户在系统里的任务流，行为路径，让用户完成任务更加高效愉悦。（页面流程）(如何绘制页面流程图？)
 
   
 
   
 
    当然，除了业务流程，系统流程，页面流程，还有数据流程被人关注。
   
 
   
 
    我们平时工作中，还会经常听人谈到泳道图啊，任务流程图啊等等概念，究竟是神马关系呢？
   
 
   
 
    
 
   
 
   
 
    
   
 
   
 
    图5：流程图的分类
   
 
   
 
    
 
   
 
   
 
    本文着重于上述流程中的“业务流程图”——并会分享如何绘制泳道图——
    也即是PD们最多使用，技术们最多参考，UED们最多看到的流程图。
   
 
   
 
    
 
   
 
   
 
    本来在第四部分会对泳道图的图示以及绘制方法、原则做更详细的说明，但是看目前的篇幅情况，预计会放到下篇，所以先在这里简单说明下吧。
   
 
   
 
    
 
   
 
   
 
    在工作中，我们经常能够看到两种业务流程图，从表现形式来看，一种很好区分，俗称为“泳道图”的它，在样子上也确实像个泳道，可以有横向的泳道，也会有纵向的泳道。泳道图在某些文档里会被称为“以活动为单位的流程图”，浮在泳道中的都是一个个活动。
   
 
   
 
    
 
   
 
   
 
    
   
 
   
 
    另外一种类型是以部门和岗位为单位的流程图，下图中的圆形就代表一个个部门或岗位。矩形代表活动。这种流程图关注事情如何完成的逻辑，但是在体现各个部门的责任上比较弱。如果是某个岗位的人来看，很难像泳道图那样一眼就能看到自己部门的职责和任务。所以现在用得比较少。
   
 
   
 
    
   
 
   
 
    图片来源于网络，如有侵权，请邮件告知
   
 
   
 
    
 
   
 
   

     再回过头来说泳道图，泳道图有几个关键点：两大维度，活动流转，流程要素。我们会在以后详解。
   
 
   
 
    
 
   
 
   
 
    
   
 
   
 
    
 
   
 
   
 
    第三部分：为什么需要业务流程图？
   
 
   
 
    
 
   
 
   
 
    流程图可以提供一种简单扼要的“缩略俯瞰图”，帮助观众快速了解业务如何运转。它包含了几个关键词：谁，什么时候，在什么条件下，做了什么事情，输入什么，输出什么，输出给谁……
   
 
   
 
    
 
   
 
   
 
    与系统流程不同，业务流程更关注于业务本身如何运作，讲的是业务故事，包含的是业务规则。而系统流程则是满足业务流程，实现部分流程或全部流程的信息化和系统化。
   
 
   
 
    
 
   
 
   
 
    所以业务流程是所有环节的前置条件——软件需求分析，信息系统建设也会先进行业务流程的梳理。
   
 
   
 
    
 
   
 
   
 
    下面表现了业务流程图是如何在三个主要场景中发挥作用的：
   
 
   
 
    
 
   
 
   
 
    1. 员工培训
   
 
   
 
    
 
   
 
   
 
    
   
 
   
 
    
 
   
 
   
 
    图6：流程图的应用场景之一：培训
   
 
   
 
    
 
   
 
   
 
    在此场景中：流程图能够提供一种快速了解业务如何运作的视图，通过业务流程图，新员工能够快速明白业务的最终目标是什么，中有哪些角色在参与以及他们的职责，以及彼此之间的联接。
   
 
   
 
    
 
   
 
   
 
    除了培训新员工，在员工轮岗、调职场景中，员工也需要业务流程图参考，明白新的工作内容如何开展，以及自己所处的位置，自己的上游是谁，下游是谁，自己需要交付的工作内容是什么。
   
 
   
 
    
 
   
 
   
 
    2：流程优化与重组
   
 
   
 
    
   
 
   
 
    
 
     图7：流程图的应用场景之二：流程优化
    
 
    

     
 
    
 
    

     业务流程重组（
     Business Process Reengineering
     ）的存在可以明确反驳：存在即合理。事实上，存在的业务流程并未是合理的，有可能是参与的多个角色习惯了某种做法，有可能是变革尚未影响到末端的操作，也有可能缺乏对于运行中的业务流程问题的洞察以及强有力的变革推动——因为要推动业务流程变革，不是某个部门的事情，而是需要流程中各个部门的通力配合。
    
 
    

     
 
    
 
    

     更多时候，业务流程优化是自上而下的，但是老板们未必对实际运作的业务流程那么心知肚明，业务流程图能够很好去表现这个“运作模型”。通过看业务流程图，找关键节点的人访问，能够直接切入：为什么要这么做，为什么不这么做？从而探索出更深层次的问题，而不是问：你们现在怎么做？
    
 
    

     
 
    
 
    

     通过调研，分析业务流程图，引入更多角色，能够分析出目前业务流程的问题：缺失，重复，风险，效率等等。从而制定相应的优化方案。
    
 
   
 
   
 
    
 
   
 
   
 
    3：信息化的基础
   
 
   
 
    
   
 
   
 
    图8：
    流程图的应用场景之三：
    信息化基础
   
 
   
 
    
 
   
 
   
 
    正如上文所述的餐馆梦想的案例，信息系统的一项任务就是解放员工的手脚，取代一些重复的人力劳动工作。系统上了之后，不是说业务流程不需要而是经过了一些调整，其中某个参与者变成了系统，或手持设备，或打印机而已。
   
 
   
 
    
 
   
 
   
 
    那么在做系统的功能设计和系统流程设计时，是不是必须先要了解目前业务是如何运作的呢？从而更好分析分析，更好说明系统在什么环节取代了什么类型的人肉工作？
   
 
   
 
    
 
   
 
   
 
    所以我们看到的PRD往往也会先以业务流程图开始说明，而叙述一个系统建设的好处时，也可以用以前的业务流程与系统上了之后的业务流程进行对比。根据分析，将愿景中的新的业务流程图背后需要系统的功能点撰写清楚。
   
 
   
 
    
 
   
 
   
 
    第四部分：如何绘制业务流程图？
   
 
   
 
    
 
   
 
   
 
    首先绘制业务流程图本身有没有流程？一定是有的。在软件工程学里听说一句话叫：万物皆对象。那么在流程学里，万事皆流程。吃饭难道没流程吗？就吃饭的动作而言，就有流程：拿筷子——夹菜——入口——咀嚼——吞咽。
   
 
   
 
    
 
   
 
   
 
    有不少同学在这一部份很快想会问一个问题：Heidi，请介绍画流程图的工具吧？
   
 
   
 
    
 
   
 
   
 
    我个人是工具派，从不否认人工欲善其事，必先利其器的道理。好的工具本身就是一名好的老师，除了技能，也能够教会我们一些理论与理念，这些理念也是“器”中很重要的一部分。其次才是具体的工具应用技能。所以我并不建议直接跳转到工具应用。对于初学者而言，笔与纸永远是最好的入门工具，因为你无需和任何一个陌生的软件较劲。
   
 
   
 
    
 
   
 
   

     那么，绘制业务流程图有没有可遵循的流程呢？我建议可以从下面4步着手。
   
 
   
 
    
 
   
 
   
 
    1. 调研
   
 
  
 
  
 
   
 
    
 
     
 
      如何快速了解业务运作真相？有没有调研的技巧放送？
     
 
    
 
   
 
  
 
  
 
   

    2. 梳理与呈现
   
 
  
 
  
 
   
 
    
 
     能否快速将调研得到的文字和问题，快速转化为业务流程图？
    
 
   
 
  
 
  
 
   
 
    
 
     
 
      业务流程图的标准图示是什么？
     
 
     
 
      怎么评价一个业务流程图的好与坏？
     
 
    
 
   
 
  
 
  
 
   
 
    3. 评审与确认——能否真正让业务流程图反映现实中的业务？
   
 
   
 
    4. 归档维护——流程不断变更，业务流程图如何快速响应？
   
 
   
 
    
 
   
 
   
 
    这些将会在下篇
    《业务流程图的绘制流程分享(二)》
    详解。
   
 
   
 
    
 
   
 
   
 
    第五部分：绘制工具？
   
 
   

     如果不搞工具研讨会的话，这部分比较简单.
   
 
   
 
    Windows: 线下工具大家常用的就是下面三个：
   
 
   

     小的流程图用用PPT就够了，完了就导出图片或截图。交互设计师们因为常用axure绘制线框图，所以也不必为了流程图去学习新的工具，完全可以用axure的flow控件完成简单的业务流程图的制作。而PD们则常用微软的visio。
   
 
   
 
    
 
   
 
   
 
    
   
 
   

     此外，特别推荐一个软件：
    SmartDraw。
   
 
   

     我最近的流程图都是用SmartDraw绘制的，你可以下载一个免费版本体验下。这个工具不仅仅是为了流程图而设计的，几乎上包罗万象：线框图，流程图，E-R图，UML ,韦恩图，甚至甘特图，脑图……没有像很多人推荐就是因为他太庞大了，尤其是里面的模版。大家体验下：
   
 
   
 
    
   
 
   
 
    
 
   
 
   
 
    Mac电脑:
   
 
   

     自然要推荐
    omniGraffle. 绘制出来的任何图表不知为何总会觉得很美……
   
 
   

     当然，这个软件是可以去www.macx.cn下载免费版的……
   
 
   
 
    
 
   
 
   
 
    但是不管windows还是mac，除了线下的工具，还有更多线上的选择：
   
 
   

     不过貌似我们对线上工具普遍来说都不太放心，是对服务器，网速，还有对GFW不放心吧。
   
 
   
 
    
 
   
 
   
 
    1. https://cacoo.com/
   
 
   
 
    
   
 
   

     这个是界面做得最好看的一个工具。我用它来绘制过概念图（Concept map）。如下图即是用以上的工具画的。
   
 
   
 
    
   
 
   
 
    
 
   
 
   
 
    2. 
    http://creately.com/
   
 
   
 
    
   
 
   
 
    3. 
    www.lucidchart.com
   
 
   
 
    

     http://
    
 
    
   
 
   

    
 
   
 
  
 
   
  
 
   1. 业务流程图的“烹饪三部曲”
  
 
  
 
   
 
  
 
  
 
   在绘制业务流程图前，思考如何精美，如何交互，使用什么工具，都不应该是重点。
  
 
  
 
   
 
  
 
  
 
   真正重点的是将业务流程图的关键要素给搜集一番。请试图回答清楚以下几个问题，否则不要开始绘制流程图：
  
 
  
 
   
整个流程的起始点是什么？整个流程的终结点是什么？
在整个流程中，涉及到的角色都是谁？
在整个流程中，都需要做什么事情？（可是是一个会议，可以是一个任务）
这些会议和任务是可选还是必选的？
分别产出什么文档？
 
  
 
  
 
   这有点像一个头脑风暴，能够帮助你将所需用到的原材料获取到，有了这些“米”和“水”，那就不愁去如何烹饪了。
  
 
  
 
   
 
  
 
  
 
   在项目管理中，上个月，我们也试图给去规范化一个数据产品的设计开发流程。
  
 
  
 
   
 
  
 
  
 
   这是一个数据产品的项目，而我们都不是对此很有经验的人。所以我们召集到所有相关的角色，组织了一次头脑风暴及卡片分类法的混合式应用。
  
 
  
 
   
 
  
 
  
 
   
让大家头脑风暴出自己认为在项目里必须的节点，如“需求调研”，“需求分析”，“kick off会议”，“PRD撰写及确认”，“数据评估”，“技术架构”，“DEMO绘制”，“指标算法定义”，等等。
在头脑风暴过程中，主持人将这些节点都写到白板上，等没有新的节点诞生后，大家一起对节点进行合并归类。之后呢？
将这些剩余下来的真正有价值的节点，撰写到即时贴上，开始进行排序。在排序过程中，可以由一个人先主导，他会按照自己的理解，将各个节点放到按角色排布的泳道中，并设计好先后的顺序。在他进行的过程中，其他人不断进行提问：“这项任务开始前，需要什么样的条件？”“这个任务是必须的吗？”然后一起调整先后顺序。直到最终没有人有任何重大的异议。
之后拍照留念。
 
  
 
  
 
   
  
 
  

    然后可整理成电子文档，如project或者excel版本（
   使用excel做项目管理？）
  
 
  
 
   
  
 
  
 
   
 
  
 
  
 
   但是，业务流程图和上述项目中的流程不太相同的是：
  
 
  
 
   
 
  
 
  
 
   项目中的各种活动节点有更宽泛的可配置性，任务A和任务B是否并行，还是串行，如果项目组成员达成共识，是可以调整，并且多做尝试的。所以可以用集思广益的做法去头脑风暴出一个暂定比较合理的流程。而
   业务流程图的梳理，有两种:
  
 
  
 
   
一种是基于现实发生的业务流程如实反映。这显然不是你一个团队能够YY的结果。更需要走到现实环境中，去调研，去梳理，去确认。
另一种是基于流程优化的方案，当你已经掌握了目前的流程现实如何运作时，基于分析，讨论，能够判断出流程中不合理的地方，给出一个更完善或者有更效率、成本更低的新的流程出来——或许你要求增加一个部门，或者你需要删减一个环节，或者中间的若干步使用新开发的系统去取代。
 
  
 
  
 
   总之，大多数时候，你要想做第二种流程图，必然要先将第一种给梳理出来。所以，第一种如实反映的流程图是躲不过的。既然如此，基于YY或者头脑风暴是不现实的。我们需要走到前线去，掌握现实中业务是如何运作的。而且很多时候，越细节越好。
  
 
  
 
   
 
  
 
  
 
   那怎么做呢？基于有限的知识与经验，我可以给如下建议：
  
 
  
 
   
 
  
 
  
 
   1. 调研——2.梳理呈现——3.评审确认三部曲，如图所示：
  
 
  
 
   
 
  
 
  
 
   
  
 
  
 
   
 
  
 
  
 
   2. 调研——问正确的问题，多问问题，多问几个人
  
 
  
 
   
 
  
 
  
 
   除了在本部分开始的那几个问题要顾及到，其实调研过程解决的仍然是who，what，why，how，以及where的问题：
   谁，在什么情况下，做了什么事情，这个事情需要什么前置条件，又输出了什么，这个事情在哪里完成的？搞明白这几个问题，我们的调研就可以圆满完成了。
  
 
  
 
   
 
  
 
  
 
   

    流程图的表现，要回答这几个问题：
   
 
   
 
    
Who——谁？部门，角色，岗位
What——什么事情？
Where——在哪里做的？在我梳理的业务流程图上，where更多表示是文档还是各种系统，用来表示信息化的程度。比如当我们梳理中发现，有一项登记，是用excel而不是业务系统来进行的，那么在这里的where就可以表示为：excel文档。
Document——那产生的这份文档叫什么名字？也写出来，代表有文件的传递，而以后要进行信息化的话，此份人肉文档也是需要被消除而被系统取代的。（相反，如果这项工作是在某个系统里操作的，where就可以写成“人事系统”，文档可以继续存在，即该系统中的表单名称：“员工登记表单”）
Condition——条件。在这种条件下，下一个活动还能够继续，即用逻辑链接线的方式来表示一项活动的输入和输出，指向某个活动的箭头就表示此活动的前置输入条件。
Dicision——决策。有些活动会产生一个条件判断，根据不同的判断结果从而走不同的分支流程。比如输入员工信息的时候，可以根据员工之前是否就职过，选择不同的流程，对于已经就职过的，选用之前的工号而不用生成新的工号。
 
   
 
   

    
   
 
  
 
  
 
   
 
  
 
  
 
   举个案例（如果不太恰当，请意会）。假设你受命要调研两家餐饮店的业务流程，目的是给他们提供性价比最高的点餐系统。
  
 
  
 
   
 
  
 
  
 
   在调研中：
  
 
  
 
   1. 你首先可以要求精通业务流程的人给你系统讲解一遍。
  
 
  
 
   2. 调研具体操作的人，来验证他给你讲解的是否全面和偏差。
  
 
  
 
   3. 实地观察和记录（花点时间走遍业务流程）
  
 
  
 
   三种方式相互结合使用。第一种方法可以让你首先建立一个系统观，了解大体枝干，但是很难切入到可能会出现问题的细节。第二种方法太依赖于问题的质量以及问问题的场景。有很多结论的不正确其实是因为问错了人或者问问题的方法不对。那么就需要借助第三种，在观察中再进行验证。
  
 
  
 
   
 
  
 
  
 
   比如，你现在找到了一个厨师：
  
 
  
 
   你主要负责做什么菜系？
  
 
  
 
   热菜。
  
 
  
 
   那菜单都是谁给你的？
  
 
  
 
   我们的服务员。
  
 
  
 
   她都怎么提供给你？
  
 
  
 
   她负责客人点菜后，然后手写一个单子，给我放到窗口上。
  
 
  
 
   单子上都会写什么？
  
 
  
 
   桌号，菜名等
  
 
  
 
   那如何客人点的是冷菜呢？
  
 
  
 
   恩，有复印本，直接拿一份给冷菜间。
  
 
  
 
   那你怎么开始工作呢？从洗菜到切菜，一直烹饪都是一个人吗？
  
 
  
 
   哦，不，我只负责烹饪。当接到菜单后，首先我的助理会进行择菜，刀工进行切菜，这样如果有几个菜就完全可以并行。
  
 
  
 
   当你们做好后呢？
  
 
  
 
   放到窗口，按铃，喊桌号和菜名，传菜员就会传菜。
  
 
  
 
   ……
  
 
  
 
   
 
  
 
  
 
   在这些问题中，就涉及到了“分单”，“切菜”，“择菜”，"烹饪"，“传菜”，“上菜”几个活动，也涉及到了“服务员”，“厨师”，“助理”，“刀工”，“传菜员”几个角色。几个活动的次序也比较清楚了。
  
 
  
 
   
 
  
 
  
 
   而另一家餐饮店的业务流程却是不一样的，你同样抓住一个厨师进行询问：
  
 
  
 
   要做什么菜，菜单是哪里来的？
  
 
  
 
   打印出来的。
  
 
  
 
   所有菜都会在这里打印吗？
  
 
  
 
   哦，只有热菜在这里打印出来，冷菜、酒水就会在冷菜间和酒水间打印出来。
  
 
  
 
   打印机是谁在操作的？
  
 
  
 
   没人操作，它会自动打印不同的单子给我们。
  
 
  
 
   ……下面的问题，可能厨师就不了解了，要问点菜员了。
  
 
  
 
   
 
  
 
  
 
   请问你是怎么点菜的？
  
 
  
 
   拿设备啊，客人点菜就按几下，确认就好了。
  
 
  
 
   之后呢？
  
 
  
 
   之后就可以将菜单打印出来。
  
 
  
 
   不同的菜系会在不同的烹饪间打印吗？
  
 
  
 
   是的，我们可以分单打印。是在这中心打印机里完成分单。
  
 
  
 
   
 
  
 
  
 
   然后，你可以继续调研烹饪后的传菜和上菜流程。
  
 
  
 
   
 
  
 
  
 
   3. 梳理并呈现
  
 
  
 
   你的调研和观察使你拥有了“烹饪”所需的原材料。
  
 
  
 
   
角色：部门、岗位或人
活动：做了什么事情
次序：做这些事情的次序如何
规则：什么情况下到什么事情
 
  
 
  
 
   还记得我们之前提过的流程图要素吗？回顾下：
  
 
  
 
   
  
 
  

    接下来的任务是不是很简单，
   对，就像填空题一样简单。将活动/事件按照一定的规则填到由部门和时间两条维度决定的框框里。
  
 
  
 
   
 
  
 
  
 
   这个阶段是paper work，你需要将调研阶段收集到的原材料用更直观明了的方式呈现出来。从而能够更好进行评审和确认。也为以后的流程评审和优化做准备。
  
 
  
 
   
 
  
 
  
 
   在刚开始，笔和纸的原始搭配仍然是最好的起步工具。你可以暂时忽略掉美观或者可复用的因素。但是当你对要呈现的流程已经有足够的信心时，就可以借助软件工具了。
  
 
  
 
   
 
  
 
  
 
   
 
  
 
  
 
   3.1 复杂流程的分解
  
 
  
 
   
 
  
 
  
 
   不可能将所有的活动都放到一张图里呈现。
  
 
  
 
   
 
  
 
  
 
   “
   业务流程是有层次性的，这种层次体现在由上至下、由整体到部分、由宏观到微观、由抽象到具体的逻辑关系。
   这样一个层次关系符合人们的思维习惯，有利于企业业务模型的建立  企业部门之间的层次关系表。一般来说，我们可以先建立主要业务流程的总体运行过程（其中包括了整个企业的大的战略），然后对其中的每项活动进行细化，落实到各个部门的业务过程，建立相对独立的子业务流程以及为其服务的辅助业务流程。
   ”
  
 
  
 
   
 
  
 
  
 
   ——
   引自《百度百科》 业务流程词条
  
 
  
 
   
 
  
 
  

    对于很多新人来讲，业务最难的在于划分业务流程图的层次上。
  
 
  
 
   
 
  
 
  
 
   首先，明确你要梳理的业务流程的范围——用大的粗略的关键节点，讲清楚这个业务流程范围中的故事，就是顶层业务流程图。你的顶层业务流程图是业务全局故事的简单表达，但是请注意这里的业务全局不见得是公司整体的业务全局，而是你界定好的业务范围。比如，下图是餐厅的日常运作流程图，若你界定的业务范围是面向顾客的点餐和结帐流程，那么这就是顶层业务流程图。但是若你界定的是整个餐厅的运作业务流程，那这显然还是一个子集——并没有包含餐厅的采购、供应商管理、一级库存管理等工作。
  
 
  
 
   
 
  
 
  
 
   
  
 
  
 
   
 
  
 
  

    其次，先从顶层的业务流程分解开始，由粗至细。顶层业务流程图的梳理原则：
  
 
  
 
   

    1. 界定范围内的业务全局故事。
   
 
   

    2. 包含该范围内的关键节点。并且，当被质疑说某某环节怎么不存在时，自己要清楚它在下一层分解中应该被包含在那个关键节点中。比如，赠送10周年优惠券，应该会在结帐节点分解中出现。而打印分单，会在点菜节点中分解。而准备儿童座椅应该是接待入座环节。
   
 
   

    3. 顶层流程图分解出来的关键节点未必都会细化分解下去，生成二级以及三级的流程图。这要看该节点涉及到的“活动”以及“角色”是否复杂。
   
 
   

    
 
   
 
  
 
  

    再看一个案例，对传统生产型企业的进销存主业务流程进行分解。橙色的代表被分解点，已经可以分解为四层。当我们分解到第四层，发现再往下去涉及到的活动和角色都已经很少时，就不必再分解了，而是可以将第四层的关键节点直接作为第三层业务流程的“活动”，而不是子流程图。
  
 
  
 
   
 
  
 
  

    当然，这是依赖于你梳理业务流程的目标。如果你偏偏是要对“打样”环节进行剖析优化，则还可以继续分解下去。
  
 
  
 
   
  
 
  
 
   
 
  
 
  

    这一步的工作会帮你建立出清晰的流程目录结构，如下图所示是摘选于刚完成的一个流程梳理的项目中的目录结构部分。可以看到全图即是顶层关键节点，作为老大，可能只要看这一层就够了。下面则会对顶层做更多细化拆解。
  
 
  
 
   
 
  
 
  

    “H3.样品认证”在顶层业务流程图中，仅仅是一个“活动”，而在自己细化的这一个层次中，则会包含详细的子活动一级参与者。
  
 
  
 
   
 
  
 
  
 
   
  
 
  
 
   
 
  
 
  
 
   3.2 流程图的常用图示
  
 
  
 
   
 
  
 
  
 
   
  
 
  
 
   
 
  
 
  
 
   我常用的就是前两行的“活动”，“判断”，“逻辑关系线”，“起始与终止”，以及第二行的“子流程”，和“文件/表单”。如果你不是符号控，我建议这几个就足够了。
  
 
  
 
   
 
  
 
  
 
   其中，“子流程”此图示就是可以帮助你将流程分解得到的子流程能够串联起来，比如，当在"A流程"中涉及到进一步需要分解的"A1.1流程"时，就可以在
   "A流程"中用子流程符号代表“A1.1”。然后你的读者就会明白要想进一步了解"A1.1"应该参考另外一个流程图。
  
 
  
 
   
 
  
 
  
 
   流程图的常用结构：
  
 
  
 
   
  
 
  
 
   
 
  
 
  
 
   
 
  
 
  
 
   给大家看一些案例：
  
 
  
 
   

    
 
   
 
   

    基本上包含大多数图示的流程图：
   
 
  
 
  
 
   
  
 
  
 
   文档地址：http://www.ais.npic.edu.tw/ais/971%20materials/DfdSfPm_20080724.pdf
  
 
  
 
   
 
  
 
  
 
   只用到少数几个图示画的简单流程图（台湾人的文档中称为程序图——不过这里的程序不是指计算机程序，而是process，仅仅是体现任务之间的处理流程，所以使用极简单的符号也不为怪了）：
  
 
  
 
   
  
 
  
 
   
 
  
 
  
 
   以上两个流程图案例，从符号的复杂程度上来讲，一个是完整流程图，一个是基本流程图，但是从表现形式来讲，都属于“泳道图”——Swimlane。这也是我们最常用的一种表现形式了。泳道图能够很好体现部门或者角色在流程中的职责以及上下游的协作关系。且流程图本身的标准容易掌握，达成共识也就更加容易。
  
 
  
 
   
 
  
 
  
 
   3.3 泳道图精要
  
 
  
 
   
  
 
  
 
   
2大维度：一般泳道图的横向会作为部门或岗位维，当然也有例外，如上述案例中就是横的泳道。而纵向则做为阶段维——时间是从上到下发展的。如果复杂的泳道图，在任务分解上可以在阶段维里做一些划分，比如“采购”，“生产”，“销售”，"配送”等。
活动流转：活动就像一个游泳员一样，游到不同的泳道中去执行任务。
 
  
 
  
 
   在上文中的软件推荐部分，我推荐过smartdraw工具，此工具还附带了泳道图的模板，大家比较更快能够上手：
  
 
  
 
   
  
 
  
 
   
 
  
 
  
 
   
 
  
 
  
 
   
  
 
  
 
   
 
  
 
  
 
   3.4 Do vs Donnot 业务流程图的注意事项！
  
 
  
 
   
 
  
 
  
 
   DO
  
 
  1. 让涉众参与，不要闭门造车 
  
 
   
 
    

     业务流程图包含了你图上的各个参与角色代表，与他们适时确认事情的原本流程，禁止自己YY。
    
 
   
 
   2. 恰当的层次分解，不要将所有都铺到一张图上
  
 
  

    如上所示。
  
 
  
 
   3. 逐渐深入，先抓枝干
  
 
  

    切忌胡子眉毛一把抓。
  
 
  
 
   4. 流程一定有开始和结束
  
 
  

    切忌交付出来的流程图，让读者还来问你：流程的开始点是什么？用清晰的代表开始和结束的符号来完成第一步和最后一步。
  
 
  
 
   

    5. 编号，编号，编号
   
 
  
 
  
 
   

    这是让沟通效率更高的优化措施。当你有了编号系统，相当于对你的流程图都赋予了唯一识别身份证号。这比中文名称更有效。比如当我们完成了业务流程图后，负责业务流程规则审核和优化的部门能够清楚在邮件里传达：H5.1流程优化，大家就更明确指的是什么。
   
 
   

    
 
   
 
  
 
  
 
   
 
    DONNOT
   
 
   
 
    

     1. 自己YY应用的环节而不是现实中的环节
    
 
    

     2. 所有的环节都试图放到一张图上
    
 
    

     3. 一开始就陷入细节，胡子眉毛一起抓
    
 
    

     4. 流程很难让人分清楚从哪里开始，到哪里结束
    
 
   
 
   
 
    
 
   
 
   
 
    4. 评审及后续行动
   
 
   
 
    验证你是否做到了以上的DO，以及规避了Donnot的做法是什么？
   
 
   
 
    很好办，及时与各位进行评审。将各个涉众都叫到一起，给他们看你梳理出来的成果。
   
 
   
 
    这会发现一些有意思的事情，除了评审你的流程图是否符合现实外，也会评审目前的业务流程是否符合理想。不同的部门和岗位的代表会在这个评审中，确认当前，也会相互提出意见，甚至吵起来，这不失于做流程优化的一个很好的契机。暂且不表了。