标准流程图怎么做 绘制流程图遵循的规则

作为产品经理，画流程图是必备技能。如订单处理流程、商品审核流程等。关于如何画流程图的文章很多。我们发现有各种各样的绘图方法和概念。这里就产生了一个问题:什么样的流

作为产品经理，画流程图是必备技能。如订单处理流程、商品审核流程等。

关于如何画流程图的文章很多。我们发现有各种各样的绘图方法和概念。这里就产生了一个问题:什么样的流程图才是正确的？

有没有标准的画法？没有标准字段路径的流程图必然是模糊和混乱的。网上的流程图有相当比例是野路子。比如下面两个流程图都有问题，导致表达混乱。

其实流程图是有标准的，这就是UML（统一建模语言）制定的标准，被其称为活动图。并且这个标准被微软和IBM等大厂采用，用来做业务分析。下面我们通过学习就能够分析出来上面两个流程图的问题在哪里。其实流程图是有标准的，是UML(统一建模语言)制定的标准，叫做活动图。而这一标准被微软、IBM等大公司用来做商业分析。我们可以通过下面的学习来分析上面两个流程图的问题。

知道很多流程图都是有问题的，想画好也不是那么容易的。所以我也将分三篇文章介绍如何绘制UML的流程图，即:

第一条:如何做出正确的流程图？

第二条:如何做一个大家都喜欢的流程图？

第三条:日常工作生活中如何使用流程图？

的第一篇会让你明白流程图的正确姿势和语言。第二篇将教你如何画出大家喜欢的粗细合适的流程图，进一步拓展流程图的高级知识。结束了。请移步阅读。

先学习一下做流程图的规则是什么，就像下棋一样。我们首先要明白下棋的规则是什么，然后学习如何赢得比赛。另一方面，就像会下棋却不知道基本规则。规则很无聊，但你得先学会。

第三条是一个扩展，就是通过学习流程图来更好的表达工作中的沟通，甚至可以用来理解编程语言。扩展这一点也是我之前的观点。学习知识在“建立知识的多渠道连接”中很重要。只有建立起知识之间的联系，技能才能快速成长，才能打通当省长的第二脉！具体文章请移步看《产品经理在工作中遇到困难，应该学什么去解决？》

本文是第一篇，内容包括:流程图的意义，如何绘制流程图，网上常见流程图分析。

一、流程图的意义

产品经理画流程图有两个功能，分别是:

1)用于与非R&D部门沟通:决定了人做什么工作？描述公司的核心业务。比如用户下单后，涉及物流部门发货，系统开发票。

2)用来和开发者交流:对于系统开发者来说，他们更关心的是这个订单系统的流程是什么。因此，需要更详细的描述。以下订单后货源不足，无法发货怎么办？

在下一篇文章中，我们将讨论如何绘制不同用途的流程图。本文的主要目标是画出没有错误的流程图。

产品经理要注意流程图的绘制。

首先，很多产品经理经常会开始做交互页面的原型。但这往往导致需要重新绘制原型图，因为过程不清楚。所以注意先画流程图，再画原型。

其次，R&D经常批评产品经理，因为产品经理没有逻辑，而画流程图是建立你的逻辑的方法，最后用在面试表达和产品点评发言中。

让我们展开并解释如何绘制流程图。

二。流程图怎么画？

流程图是为了完成一项任务而进行的相关活动以及这些活动的执行顺序的描述。UML将流程图称为活动图，但为了讨论方便，后来也称为流程图。

下面以订单流程为例，带领大家一步步画出大厂标准的流程图。整个过程涉及到从下单到收货的过程。下面是订购流程。

其中的逻辑是，用户下单后，物流人员需要送货上门。用户收到货物后，点击确认收货完成整个订单。这里涉及到以下概念:

1。活动的概念

在这里，物流人员送货到家和用户确认收货都体现了一个人做了什么，它们会涵盖“主语+谓语+宾语”。“用户”是主语，“点击”是谓语，“确认收到”是宾语。

而人的所作所为，反映的是一种“行动或操作”。UML称之为活动，但它实际上和动作是一个意思。后来我们都用活动这个概念。

活动的标准画法是一个圆角的矩形框，里面写着具体的活动。活动内容写成“主语+谓语+宾语”，根据说话习惯可以省略宾语或主语。

活动由一条带箭头的线连接在一起，称为“转移”。意味着一个活动可以转移到下一个活动。比如物流人员送货上门后，用户确认订单完成，否则无法进入下一个活动。

2。起点和终点的概念

流程图有一个“起点”，用来表示流程从这里开始。起点是一个实心圆。

一个流程图也有一个“终点”，用来表示前一步的“活动”就是这个过程的结束。对于上面的订单流程，结束活动是“用户确认收货”。这个活动完成后，整个过程就完成了。绘制规则是实心圆加空心形圆。

注意:必须有一个起点，终点可以省略，也可以不止一个。画完画的好处是可以让别人知道你考虑了收尾因素。但是有些工序涉及的终点太多，终点很明显，所以画起来比较繁琐。

3。判断和平行的概念

现在我们已经能够画出流程图了。但是我们发现这个过程中还有很多细节需要补充，这就是我们接下来要介绍的判断和并行的概念。让我们以问题为出发点，来看看如何改进流程图。

如果订单有“网上支付或货到付款”不同的处理流程，如何表达？-用判断标记来解决。

这时候物流人员就需要判断订单了。如果是网上支付(先付款后发货)，商品会直接送到用户手中，否则用户必须支付现金或刷POS机才能发货。此时的流程图如下:

这个判断点用菱形符号表示。此时是一进多出，判断条件用退出线上的方括号表示。这是:

如果第一个条件是“如果用户在线支付”(简称:在线支付)，对应的动作是“物流到货物到用户”；

如果第二个条件是“如果用户货到付款”(简称“现金支付”)，对应的动作是“物流代收现金”。

第三个条件是“如果用户选择POS支付”，那么“物流用POS机收款”。

注意，与其他流程图中写在菱形符号中间不同，这里不允许在菱形符号中间写任何字，但意思是一样的。其实“物流确认付款”可以写在菱形位置，简单易懂但略显繁琐。

如果电商再见面，用户付款的话，有时候会反悔，通知商家。商家也有“同意就取消订单”和“拒绝就坚持发货”两种选择。这两种表达方式可以达到同样的效果，但方式不同。

了解了与传统流程图不同的表示方法后，对于UML系统，除了上面提到的用菱形表示的方法外，另一种方法就是不添加菱形判断图标，如下图所示:

两种表达都可以，但是要把判断条件写在转移线上。对于这种情况，判决中加入的菱形图标会更清晰。这时候显然物流人员要在这里做出判断。

如果用户要同时开发票，流程怎么表述？-用平行符号解决。

现在很多商品都是和发票一起发货，或者支持电子发票。但仍有部分企业开具纸质发票，货物与发票开具地不符。此时，需要将货物和发票分别发送给用户。

这意味着两个物流人员在送货，一个在送发票。下面是一个并行处理，如图所示:

绘制方法是画一条粗横线，加上一条进入线和多条退出线。对于本例，两个分支流程是货物交付和发票发送，它们是同时处理的，但不关心谁先处理。

4。融合和合并的概念

完成网上支付或现金支付。-通过合并解决。

这时候只要是网上支付或者现金支付，就完成了支付。也就是条条大路通罗马。只要有一条路可以到达，我们就可以进行下一步。这时，有两种表达方式:

第一种方法可以通过三条传送线直接连接到下面的活动，这就是我们前面看到的。第二种方法是画一个菱形，多进出。注意，这里这个菱形符号并没有判断的意思，只是借用了菱形符号，所以不需要在线旁边添加判断条件。

实际上，第二种绘图方法是UML的标准绘图方法。但毕竟有些看流程图的人不是程序员，画出来会被误解。为了方便交流，可以选择第一种画法。但是，当你看到在线流程图中合并的菱形标志时，你应该意识到你是在合并而不是在判断。

这里再举一个例子，用户可以点击确认收货，系统也可以自动确认收货。也是第一次确认收货才算收货，订单才算最终完成。

只有当发票和商品用户收到订单时，订单才完成。——用收敛来解决。

我们之前说过，货物和发票是分开寄的。对于用户来说，必须同时收到发票和货物，才能点击“确认收货”。两者缺一不可。详情见下图:

表达式是一条粗水平线，加上多个入口和一个出口。条目的分支是交货和发票。这时候同步处理，但是不在乎谁先做，谁后做。但是，当它们相遇时，必须全部完成才能进入下一步。

再比如吃饭上菜的例子。我们去餐厅，菜是分开上的，都上完了才能吃完。但是野路的流程图没有办法表达这种并行收敛的过程。

通常会出现平行和收敛对。此时并行执行两组活动，但两组活动都必须完成，才能进入下一个环节。上图是一个完整的流程图。

5。流程图概要

流程图表示方法最终总结在下表中:

三。采用问题学习的概念

看完了流程图的绘制方法和逻辑，我们再来看看网上的一些流程图，逐一理清有哪些常见的问题？让我们避免同样的错误。

情况1:流程图中不应该有不活动的内容

上面的流程图是指产品经理的工作包括需求收集、需求讨论、需求评审等。，并为此绘制了流程图。想想吧。这个流程图有什么问题？

根据流程图的概念，流程图要求每一帧都是一个活动，典型的活动是

“主语+谓语+宾语”

。

在此，“有效需求、现有功能和需求池”不是一个活动，但它们都在谈论不同类型和功能概念的需求。真正体现活动的是产品经理“收集需求，讨论需求，评审需求”。

而这里大家会说，我该怎么做才能体现“有效需求和需求池”这两个概念？

那么可以这样描述:我们可以将需求分为新需求+旧需求，其中新需求产品经理需要将其过滤为有效需求和无效需求。进入需求评审环节的是新需求和旧需求的有效需求，放入需求池。在这个环节中，我们决定在这个时期开发哪个需求。

如果你了解UML的面向对象的思维方法，上面的描述是可以有效描述的。以后会有关于这个的专题。另外，知识是相通的。如果按照金字塔原理进行逻辑思考，也可以得到上面的描述。

通过这个案例，我们发现把需求处理方案和需求评审过程的描述混在一起会让受众感到困惑，但是如果把它们分开描述会清晰很多。

情况二:流程图不同于状态图

这是买家下单付款的过程。这里还是按照“主谓宾”来划分，我们发现待付款不是一个活动，而是一种状态。横线上的“买家下单”是一个活动(即用户点击订单)。

所以这仍然不是流程图，用UML中的状态图来表示更合适。这个时候如果看状态图，这里也有一个问题。以后我们会有一个关于状态图的专题。

案例三:流程图的逻辑需要仔细考虑

这个流程图就是从用户下单到供应商供货的过程。我们假设这是JD.COM或天猫的订单流程。这里“生成送货单，用户选择支付方式，收款”环节存在逻辑问题。有哪些逻辑问题？

至此，让我们回忆一下我们是如何在购物APP上下单的。这个过程是:

1)当用户从购物车中点击“前往结算”时，将打开“提交订单页面”。

2)在“提交订单页面”，允许用户选择在线支付或货到付款，并编辑送货地址。此时，点击“提交订单”按钮。

3)然后系统生成订单，显示到用户的“支付页面”。

4)支付页面允许用户选择银行卡或支付宝后，点击“银行卡支付”按钮。

5)此时系统显示“输入网银(或支付宝)密码”页面。

6)用户在“密码输入页面”上“输入账户密码”后，订单支付完成。

回想整个过程后，我们会发现以下问题:

【/s2/】问题一:“用户选择支付方式，然后收款，中途可以取消订单”的概括是不正确的。

事实上，“在提交订单页面，用户先点击提交订单；之后弹出密码输入页面，用户输入密码完成支付”。当点击提交订单后没有输入支付密码时，用户可以在个人订单列表中选择“取消订单”。所以可以总结为:用户提交订单，然后用户支付订单，提交订单后可以取消订单。

问题二:送货单的生成与其他活动并不并列。

系统的实际工作流程是“用户点击提交订单后”，系统会生成订单，并抛出页面让用户支付。生成的订单可以在订单列表中看到，用户可以对要支付的订单进行支付或取消订单。那么送货单的生成和付款方式的选择是否同时进行。

其实通过这个案例发现，流程培训首先需要对每个环节进行仔细的思考。其次，这涉及到如何把流程的每一步抽象出来，如何画出大家都喜欢和理解的流程图。这也是第二篇文章的重点。

四。摘要

通过这篇文章，我们知道了标准流程图的绘制方法。

首先需要了解活动、判断、并行、并行收敛、合并等基本概念。其次，通过三个例子，说明如何正确表达流程图，而不是学习假流程图。

其次，发现流程图只是逻辑思维和表达的一种方式，还有很多其他方式需要进一步解锁。

比如最后三个流程图，指出了问题，但是没有画出来。可以留言说说自己的想法，怎么画流程图。