编辑导语：一个合格的B端产品或系统，必须是基于业务出发。那么，如何梳理复杂的业务关系呢？本文作者认为可以运用流程图来化解，并对此进行了分析，一起来看一下吧。
B端产品是服务于组织，通过帮助组织提高收入、提高效率、控制风险，从而协助达成组织商业目标的系统。一个合格的B端产品或系统，必须是基于业务出发。如何梳理复杂的业务关系？
流程图=流程+图，流程是一系列的逻辑关系（包含因果关系、时间先后、必要条件、输入输出）做需求前一定要先把这些逻辑关系理清楚，用一句话概括的话“流程就是在特定的情境或场景下满足用户特定需要的总结”。
图就是将大脑中的逻辑关系以图形化的形式呈现出来，具有图形化、可视化的特点，因为是图，可以及时的迭代，当逻辑需要修改的时候就拿出来迭代一下，同时可以更好的给项目成员进行沟通和交流。
每个人想一个逻辑的时候，不一定能把这个逻辑的细枝末节都想到，如果我们贸然的画原型就有可能做许多无用功，这个时候画流程图可以帮助梳理清楚的逻辑。
Tips：
团队讨论或开会时，如果有一张清晰的流程图，不仅便于讲解，也便于技术理解。
同频的沟通，能快速地就某个点进行有效讨论。同时把确认后流程图写入PRD文档中也方便传播，当技术忘记流程的时候，查看一下文档里的流程就知道流程了，不用反复确认。
对于输出的一个逻辑，不一定能考虑的那么周全，如果有一个清晰的流程图也方便做记录以及修改。
同时每个版本迭代的流程图可能会有相应的变化，通过对每个版本流程图的对比分析，可以知道流程优化在什么地方，产品优化了什么地方。
流程图是符号化的图形语言，有一定规范，菱形代表判断，距形代表具体的操作行为、开始和结束用圆角表示。
1）角色：都有那些人参与功能里（系统也作为一个角色）
如：coo/ceo、行政部长、内部组织或部门、业务owner、业务监管人员（前台）、员工、供应商、除供应商外的第三方组织。
2）事项：这些人分别扮演什么角色，要做什么步骤事情
如：
3）需求或信息的流向：要完成任务的流程顺序是如何？
如：安全事故应急处理流程，需要来源是员工突发的事件。
每个功能模块中，从哪里开始，到哪里结束。
Tip1：流程是可以多进，但是必须是一出，这个是最常见的一个错误，从一个流程直接出到多个下级流程的做法是完全错误的，正确的做法是出到一个判定然后再分别到多个下级流程。
Tip2：流程里的文字描述得是谓词短语，而不能是名词短语，如：提交申请，而不是申请的提交。
Tip3：在画完泳道图后,最好给每个流程、判定、子流程加上序号，方便在和团队沟通的时候用序号来快速定位（注意：一定是在整个泳道图定稿后才加上序号，不要对还在优化修改过程中就加序号，否则很容易把序号搞得很乱）。
Tip4：如有必要，可添加必要的说明文字。
梳理陌生的业务前期思路的不清楚，会痛苦挣扎了很久，选择好的工具和一个清晰的思路让梳理业务没那么痛苦～
本文由 @番茄 原创发布于人人都是产品经理，未经许可，禁止转载
题图源自 Unsplash，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。