人人都是产品经理|你看这个流程图，它又长又宽

编辑导语：产品经理在日常工作中，经常会用到流程图，流程图也分很多种类型和作用，但流程图梳理起来并不简单，其中最多见的是业务类流程图；本文详细介绍了流程图的分类以及业务流程图的处理办法。

本文插图
我们产品在梳理较为复杂的业务流程的时候可能涉及到多个组织部门，业务场景、系统交互等等，梳理起来十分困难。
光是如何布局都比较头疼，最后终于把业务的千丝万缕梳理清晰了，才发现业务流程图十分庞大复杂。
在和领导汇报同时交流的时候， ppt和word里面都塞不下；最后用着最小的字体，将整体流程讲解完成发现大家也是很难理解。
这里说明了我们日常流程图存在三个问题：
针对上述的问题，建议产品能够明确对应的流程图的作用与区分。
01
常见的流程图：业务交互流程图系统交互流程图页面交互流程图时序图数据交互图等
其中：
面向业务：业务交互流程图
用于标识业务流转规则，需要有事项的明确开始和结束节点，需要明确的职责划分与对应的输入输出标准。整体保证流程或者事项能够通过业务流转与解决。
面向产品：系统交互流程图
当某个功能涉及多个子系统的时候，需要从业务规则中抽象出需要的功能点，并将这些功能点依据产品定位进行区分，确定系统职责。这个时候可以初步设计可能需要的接口或者大致的交互机制与主键（没有必要定死几个接口和所有字段，这个接口更像是业务属性的接口）。
面向交互：页面交互流程图
用于表述用户操作的细节，这个时候需要将用户场景理解清晰，用户操作需要用到哪些页面，这些页面之间的跳转返回逻辑是什么，有哪些校验条件。这里更加偏重用户体验，可以交给我们的交互同学协助完成。
面向开发：时序图
梳理时序图可以帮助开发梳理逻辑，也可以自己验证设计的逻辑是否闭环，很多异常场景可以在梳理时序图的时候自我反省出来。
面向开发：数据交互图
当项目涉及多个产品的时候，需要单独整理数据词典、接口清单、与数据交互图。
数据交互图在设计的时候有助于全局观审视系统设计。可以避免后端系统系统需要的字段，前端系统没有下传的问题。
这个举一个例子：数据流为：A–B–C 如果C系统需要某个字段是A系统产生的，但是B系统不需要，可能B系统在梳理的时候就会忽略，导致C系统重要字段缺失。如果梳理清晰数据交互图就可以避免类似的问题。
有了以上的对于流程的图划分，我们就可以“看人下菜” ，即提高的沟通的效率，也让对方容易理解。而不是拿一张流程图和所有人讲，结果大家都不清晰。并且上述流程图的输出排序也建议按照上述排序进行输出。
02 如果某个流程图过于复杂怎么办?
这个多见于业务流程图，因为业务流程可粗可细，如果业务纠结于一些细节，光是一个小的场景，就可能会有多个复杂的逻辑，并且需要展示流程全貌，这个时候你的业务流程图就是巨型的，及时你仅仅绘制业务层面的内容，其体量也很大，这个时候如何处理？
建议大家可以从几个层级来细分：部门层级：在了解业务的组织架构于职责之后，通过部门的维护进行业务场景梳理，比如销售部门，财务部门，行政部门。以这个维度进行业务场景的划分，重点在于了解业务主线于全貌，和整体流程的职责划分。岗位层级：在上述基础上将部门所负责的模块拆分到岗位。这个时候可以明确流程处理逻辑，已经可以通过岗位流程图了解到事项处理的条件与要求。并且明确责任到岗位，明确每一个岗位输入和输出的标准产物。操作层级：针对某个岗位的具体操作进行梳理，在明确输入与输出条件的基础上，明确每一步执行的动作。虽然不能达到操作手册的细度，但是要求可以将对应的画面在脑海中勾勒出来的程度。场景层级：如果这块业务十分复杂，可以将其分为几个场景来明确步骤，比如依据地点进行划分，依据处理事项的具体类型进行划分。分页标题
（小技巧：对于一些特殊场景可以单独抽出来，不要影响主线流程的理解；对于分支场景也可以仅仅在主线流程里面一笔带过，单独一个页面进行整理。）
本文由 @离谱发布于人人都是产品经理。未经许可，禁止转载
【人人都是产品经理|你看这个流程图，它又长又宽】题图来自Unsplash ，基于CC0协议