UML建模(2)-流程图

流程图=流程图+图表。

流程:流程是指特定主体为了满足特定需求而进行的一系列具有特定逻辑关系的操作，流程自然存在。但它可以是不规则的，不固定的，充满问题的。所以好像没有过程。

图:图表或图示是将具有一定规则的基本固化流程显形化、书面化，有利于传播沉淀，流程重组参考。

从定义中可以看出，只要有事情和任务，就会有流程，但并不是所有的流程都适合用流程图来表示。适合用流程图来表示的流程在一定程度上是固定的、有规律的，流程中的关键环节不会经常变化。

●参与者:谁在这个过程中？它可以是一个系统，可以是一个打印机，它指的是更多的角色——通常是从事某一类工作的人。例如，有两个客户，小啊和小B，但如果他们的工作性质完全相同，那么就在流程图中写一个客服角色。

●活动:你做了什么，比如点餐，结账。

●顺序:这些事情是什么顺序，哪个任务是其他任务的前提？比如客人不退房，就不会有送他优惠卡的活动。

●输入:每个活动的开始取决于什么样的输入或数据。例如，当厨师开始烹饪时，他需要获得特定的菜单。

●输出:每次活动结束后，会输入什么样的文档或数据，传递给下一方，比如如何让负责送餐的人知道厨师做好菜后，菜已经做好了？

●标准化:用一套标准化的符号来传达你的流程图，让听众更快理解。

常见的流程图包括事务流和页面流。

在工作中，作为UED，你可能会发现PD经常讲业务流程，而作为交互设计师，我们制作更多的是页面流程图。页面流程图和业务流程图是什么关系？谁先来，谁接着来？

先说个故事:假设你的梦想是开一家中高端的全国连锁餐厅，那么你首先要想的不是如何选址，而是为什么要开连锁餐厅，以及你的定位和核心竞争力。是快餐，还是订餐，连锁还是加盟？是位于小区还是繁华商圈？是川菜还是江浙海鲜？是针对中年人还是年轻人？是家庭题材还是动漫题材？竞争对手是谁？需要什么样的投资？可能存在哪些风险？这些都想清楚了，问题也有了答案。所谓战略层面应该是明确的。那么假设你现在分析一下，和主要投资人决定一个方向:一个年轻人的时尚卡通茶餐厅，连锁，但是在杭州开第一家，定位在年轻人聚会扫街的区域，比如景点，著名商圈，电影院旁边等等。下一步是什么？

下一步是找到实现这一目标的方法，对吗？那么需要做些什么呢？选址？拉投资？装修？选择餐饮菜单？雇佣员工？每一步怎么做，什么时候做？任务分解和规划等。，需要去战术层面。

这些事情的实施，总需要讨好人吧？首先，核心团队分工部署各项建设任务。餐厅开业，需要组织稳定的运营团队，如服务、卫生、厨房、采购、人事等。厨房里也有分工，白案，热菜，凉菜等。各部门是否需要建立管理和报告关系？于是你的组织架构就诞生了。

那么各个角色是如何顺利配合完成日常稳定和突发任务的呢？比如顾客上门，谁来引导客人坐下，谁来点菜？点餐的信息如何快速传到厨房，分发到酒房、凉菜房、热菜房？并且保证客人能尽快吃到自己点的菜？你要考虑各种人的合作流程，优化效率，于是业务流程就出现了。

人肉已经运营了一段时间，没有任何点餐系统你也能发现是ok的。客人点餐时，服务员手写下客人的要求。因为有复印纸，服务员可以把复印件送到厨房，同时记下桌号。厨房很小，负责分配任务的工作人员看着菜单，在冷菜处的黑板上写下自己需要处理的事情，跑到热菜区的黑板上写下需要处理的菜，去酒房报名字。但是随着业务的扩大，上述吃人的方法出现了很多问题。首先，人工抄菜效率太低，客户频繁换菜，反应太晚，导致人工抄菜失误，经常会出现错菜的情况。厨房里乱七八糟，我们只好多招几个人跑腿。一旦顾客想加菜，撤就更麻烦了。他们需要找出自己当时点了什么，然后手动标注修改。同时，他们需要修改厨房后端的黑板...

所以你想开发一个智能系统来代替大量的人类工作。你雇佣了一个系统开发团队。经过评估，他们判断该系统可以解决从点餐到上菜的问题。手持终端可以将客户的点餐要求快速传输到打印机，打印系统可以根据客户的点餐类型自动打印订单，这样热菜房可以看到自己的热菜菜单，冷菜房可以看到自己的冷菜菜单，酒房可以看到酒店菜单。做好了就送出去，送菜员可以根据菜名和打印的单据送菜，并根据顾客的订单收据核对。同时这个系统必须配备结算系统，将最终确认的菜单和消费价格传送到结算前台，方便收银员快速操作。

这个系统最终是要展示的，那么手持终端的界面怎么设计呢？服务员能否少点击完成一道菜的点餐？结算中心的界面怎么设计？

通过上面的故事，是不是更好的理解了从战略、战术、业务流程图到页面流程图的关系？总而言之:

●首先，有一个业务需求和业务目标，即我们的愿景是什么？(策略)

然后就诞生了我们需要分解什么任务，如何实施战术。(战术)

●那么，需要架构哪些部门和岗位来协同工作呢？(组织结构)

然后就出现了不同部门合作完成一项任务的业务流程？(业务流程)

●业务流程基本稳定后，往往会考虑效率优化，所以会诞生一个系统来支撑流程，减少人肉环节，促进数据收集(系统愿景)。

●为了设计这个系统，PD需要思考什么功能可以代替人肉工作的某个环节(功能需求，系统流程)。

●无论什么样的功能最终会以界面的形式呈现，设计师都会关注用户在系统中的任务流程和行为路径，让用户更高效、更快乐地完成任务。(页面流量)

当然，除了业务流程之外，还关注系统流程、页面流程、数据流程。

在我们的日常工作中，经常会听到人们谈论泳道图、任务流程图等等概念。神马关系？

在工作中，我们经常可以看到两种业务流程图。从表现形式上来说，有一种是很好区分的，俗称“车道图”，看起来确实像车道，可以有横车道，也可以有竖车道。在某些文档中，泳道图会被称为“以活动为单位的流程图”，所有浮动在泳道中的活动都是活动。

泳道图有几个关键点:两个维度，活动流和流程要素。

另一种是以部门和岗位为单位的流程图。下图中的圆圈代表每个部门或岗位。矩形代表活动。这种流程图讲究的是事情怎么做的逻辑，但是在体现各部门的职责方面比较薄弱。如果你是某个岗位的人，很难像泳道图一样一目了然的看到自己部门的职责和任务。所以现在用的少了。

流程图可以提供一个简单明了的“简略鸟瞰图”，帮助观众快速理解业务是如何运作的。它包含几个关键词:谁、何时、在什么条件下、做了什么、输入了什么、输出了什么、给了谁...

与系统流程不同，业务流程更关注业务本身是如何运作的，讲述业务故事，包含业务规则。系统流程是为了满足业务流程，实现部分或全部流程的信息化和系统化。

所以业务流程是所有环节的前提——软件需求分析，信息系统建设也会先梳理业务流程。

下面显示了业务流程图在三种主要场景中的工作方式:

1，培训

在这种情况下，流程图可以提供业务如何运作的快速视图。通过流程图，新员工可以快速了解企业的最终目标是什么，其中涉及哪些角色，他们的职责和他们的关系。

除了培训新员工，员工还需要参考员工轮岗、调动场景下的业务流程图，了解新的工作内容是如何进行的，在哪里，他们的上下游是谁，需要交付哪些工作内容。

2.流程优化和重组

业务流程再造的存在可以明确反驳:存在即合理。事实上，现有的业务流程并不合理。可能是很多参与者习惯了某种做法，可能是变革没有影响到终端运营，也可能是缺乏对运行中的业务流程问题的洞察和对变革的强力推动——因为要推动业务流程变革，不是某个部门的事，而是需要流程中所有部门的全力配合。

更多时候，业务流程优化是自上而下的，但老板们可能对实际的业务流程并不是那么了解，业务流程图可以很好的代表这种“运营模式”。通过看业务流程图，找关键节点的人去拜访，可以直接切入:为什么要这么做，为什么不做？从而探讨更深层次的问题，而不是问:你现在是做什么的？

通过调查、分析业务流程图和引入更多角色，可以分析出当前业务流程存在的问题:缺失、重复、风险、效率等等。从而制定相应的优化方案。

3、信息技术的基础

就像上面提到的餐厅梦的案例，信息系统的一个任务就是解放员工的手脚，代替一些重复性的人力劳动。系统安装后，并不是不需要业务流程，而是经过一些调整，其中一个参与者变成了系统，或者手持设备，或者打印机。

那么，在设计系统的功能和流程时，是否有必要了解业务目前是如何运作的？从而更好的分析说明系统在哪个环节取代了什么类型的人肉工作？

所以我们看到的PRD往往是从业务流程图开始，在描述一个系统建设的好处时，也可以把之前的业务流程和系统安装后的业务流程进行对比。根据分析，远景中新业务流程图后面需要系统的功能点写得很清楚。

首先，绘制业务流程图本身有没有流程？肯定有。在软件工程中听到一句话，一切都是对象。那么在过程科学中，一切都是过程。吃饭不是有个过程吗？就吃的动作而言，有一个过程:拿筷子——拿菜——入口——咀嚼——吞咽。

那么，画业务流程图有流程可循吗？我建议可以从以下四个步骤入手。

1，调查

如何快速了解企业经营的真相？有什么研究技巧可以播报吗？

2、梳理和呈现

能不能快速把调查得到的文字和问题变成业务流程图？

业务流程图的标准图是什么？

如何评价一个业务流程图的好坏？

3.审核确认——业务流程图是否能真实反映真实业务？

4.档案维护——在流程不断变化的情况下，业务流程图如何快速响应？

在画业务流程图之前，思考如何精致，如何交互，用什么工具应该不是重点。

真正的要点是收集业务流程图的关键要素。请尽量回答清楚以下问题，否则不要开始画流程图:

除了这一部分开头的问题，研究过程还解决了谁、什么、为什么、如何、在哪里的问题:谁做了什么，在什么情况下，这个东西需要什么前提条件，输出了什么，这个东西在哪里完成？如果我们理解了这些问题，我们的研究就能顺利完成。

流程图的性能应该回答这些问题:

1，谁-谁？部门、角色、职位

2.这是什么？

3.在哪-在哪做的？在我梳理的业务流程图上，哪里更多的是一个文件或者各种制度，用来表示信息化程度。比如当我们发现一个注册是用excel而不是业务系统做的，那么这里的where可以表示为:excel文档。

4.文档-这个文档的名称是什么？也写了，代表文件的传递，而如果以后要进行信息传递，这种人肉文件也需要被系统淘汰和替代。(相反，如果这个工作是在某个系统中操作的，在哪里可以写成“人事系统”并且文档可以继续存在，也就是这个系统中表单的名称:“员工登记表”)

5.条件-条件。在这种条件下，下一个活动可以继续，即一个活动的输入和输出用逻辑链接线表示，指向一个活动的箭头表示这个活动的预输入条件。

6.决策。有些活动会产生一个条件判断，根据不同的判断结果采取不同的分支流程。例如，在输入员工信息时，您可以根据该员工以前是否被雇用来选择不同的流程。对于已经就业的，可以选择以前的工号，不生成新的工号。

举个例子(不合适请谅解)。假设你奉命调查两家餐厅的业务流程，以便为他们提供最具性价比的点餐系统。

在调查中:

可以先请精通业务流程的人给你系统讲解一下。

调查具体操作者，验证他给你解释的是否全面，是否有偏差。

现场观察和记录(花时间走一遍业务流程)

这三种方法相互结合使用。第一种方法可以让你先建立一个系统的观点，了解大体的分支，但是很难切入可能会出问题的细节。第二种方法太依赖问题的质量和提问的场景。很多不正确的结论，其实都是因为问错了人，或者问错了问题。那么你需要用第三种方法在观察中验证。

在这些问题中，涉及到分菜、切菜、选菜、烹饪、传菜、上菜等几项活动，以及服务员、厨师、助手、刀工、传菜员等角色。几个活动的顺序也比较明确。

可能厨师不明白下面的问题，只好问点餐人员了。

你的研究和观察给了你烹饪所需的原料。

下一个任务是不是很简单？是的，就像填空一样简单。将活动/事件按照一定的规则填入由部门和时间确定的框架中。

这个阶段是纸面工作，你需要把调研阶段收集到的原始资料用更直观、更清晰的方式呈现出来。以便更好地评估和确认。它还为将来的流程审查和优化做准备。

不可能在一张图中呈现所有的活动。

“业务流程是分层次的，这个层次体现在从上到下、从整体到部分、从宏观到微观、从抽象到具体的逻辑关系中。这样的层级关系符合人们的思维习惯，有利于建立企业业务模型和企业部门之间的层级关系表。一般来说，我们可以先建立主要业务流程(包括整个企业的大战略)的整体运作流程，然后细化每项活动并落实到各部门的业务流程中，建立相对独立的子业务流程和为其服务的辅助业务流程。”

——引自百度百科业务流程词条

对于很多新人来说，做生意最难的就是划分业务流程图的层次。

首先明确你要梳理的业务流程的范围——用大粗关键节点在这个业务流程范围内讲故事，这就是顶层的业务流程图。你的顶层业务流程图是整体业务故事的简单表达，但请注意，这里的整体业务不一定是公司的整体业务，而是你所定义的业务范围。比如下图是餐厅的日常运营流程图。如果你的业务范围是面向客户的点餐和结账流程，那么这就是顶层业务流程图。但如果定义整个餐厅的业务流程，显然是一个子集——不包括餐厅采购、供应商管理、一级库存管理等等。

其次，从顶层业务流程分解入手，由粗到细。顶层业务流程图的梳理原则:

1.定义范围内的整体业务故事。

2.包括该范围内的关键节点。而且，当被质疑为什么某个环节不存在的时候，你要知道，在下一次分解中，它应该包含在那个关键节点里。比如赠送10周年优惠券要出现在结账节点分解中。打印订单将在订货节点分解。儿童座椅的准备工作应该是接待和就座。

3.从顶层流程图分解的关键节点可能不会全部被提炼和分解以生成第二层和第三层流程图。要看节点涉及的“活动”和“角色”是否复杂。

再看一个案例来分解传统生产企业的进销存主要业务流程。橙色代表分解点，可以分解成四层。当我们分解到第四层，发现下一步涉及的活动和角色很少，就不需要再分解了，而是可以直接把第四层的关键节点作为第三层业务流程的“活动”，而不是子流程图。

当然，这取决于你梳理业务流程的目标。如果只是想分析优化“打样”环节，可以继续分解。

这一步的工作将帮助你建立一个清晰的流程目录结构，如下图所示，是从一个新完成的流程梳理项目中提取的目录结构部分。可以看出，整个地图是顶层的关键节点。作为老板，看这一层可能就够了。下面将对顶层做更详细的拆解。

“H3。“示例身份验证”只是顶级业务流程图中的一项活动，但在这一级别的细化中，它将包括详细的子活动1级参与者。

我一般用前两行活动，判断，逻辑关系行，开始和结束，第二行子流程和文件/表格。如果你不是符号控，我建议这些就够了。

其中“子流程”图标可以帮助你将流程分解得到的子流程串联起来。例如，当“A流程”涉及到需要进一步分解的“A1.1”流程时，可以用子流程符号来表示“A流程”中的“A1.1”。那么你的读者就会明白，要进一步理解“A1.1”，你应该参考另一个流程图。

流程图的常见结构:

让我给你看一些案例:

基本上包含大部分图表的流程图:

只使用了几个简单的带插图的流程图(在台湾省人的文档中称之为程序图——但这里的程序不是计算机程序，而是一个过程，只反映任务之间的处理流程，所以使用极其简单的符号也就不足为奇了):

以上两个流程图案例，从符号的复杂程度来看，一个是完整流程图，一个是基本流程图，但从表现形式来看，都属于“泳道”。这也是我们最常用的表达形式。泳道图可以很好地反映流程中各部门或角色的职责以及上下游的合作关系。而且流程图本身的标准也容易掌握，更容易达到* * *的理解。

验证自己是否做到了以上do，避免Donnot的做法是什么？

非常好办，及时跟你复习。把所有利益相关者召集到一起，向他们展示你整理出来的结果。

这样会发现一些有趣的东西，除了判断你的流程图是否符合现实，还会判断目前的业务流程是否符合理想。不同部门、不同岗位的代表会在这次评审中确认现状，也会互相发表意见，甚至争吵，这是流程优化的好机会。暂时不看。