关于B端产品经理对整个流程体系的思路，你都了解哪些？作者以自身实践经历为例，分享B端产品经理的流程设计思维，希望对你有所帮助。
在上一篇文章中对流程的认识做了介绍，内容不多但也是自己对整个流程体系的认知进行了梳理和沉淀，如感兴趣的朋友可以先行阅览B端产品经理的流程设计思维（上），本篇文章主要针对流程设计的实操过程中，对流程文件的定义，输出标准进行介绍（仅为笔者个人经验非行业标准，可自行取其精华，去其糟粕）
一个企业或者一个商业主体，在生产销售进行市场运营行为的过程中，涉及的流程可能成百上千，甚至破万。有的流程可能涉及公司战略走向或者上百万的经费调用，有的又可能只是一颗螺丝钉的入库流程；有的流程需要走系统走OA，几十级审批；有的可能又只是一条微信，一封邮件几次转发抄送，一个口头传达，心领神会。
那面对如此繁琐杂多各有千秋且的流程，在实际入手解决之前，共通的做法是先分级分类去定义，然后再做具体梳理和设计。对不同层级、定义的流程要代入不同的视角，考虑不同的利益核心。
(年末事情比较多，抽空画的图，比较简陋)
上图做了一个简单划分，从L1到L6一共分为6级（如果企业规模较小，L1和L2可合并，L3和L4也可合并），由于笔者对L1到L4这个层级的流程架构设计参与较少，没有单独主导过，所以暂时没有沉淀出太多可靠的内容可分享，本篇文章就简单描述。核心内容会落在标注红色的L5级别的流程活动设计上:
L1、L2级别的流程架构，通常产出物为一些公司业务政策现状、管理手册、以及全公司适用和执行的规范和标准，主要目的为下：
L3、L4级别的流程架构，要注意的就是一些更细节的东西，因为你在给董事长股东汇报，或者攥写企业年报写L1、L2级别的内容的时候，肯定会选择性的跳过一些细节，例如集团本部的差旅费报销标准及流程或者订单履约规范及流程，就可以放到L3、L4中体现，主要目的为下：
L5级别的流程活动，这个级别的流程颗粒度需要非常细，在L3、L4的框架下，再要讲清楚什么角色要按照什么规范执行什么动作，输出什么结果给流程的下一位角色。以此明确及固化公司末级组织和一线人员的工作内容：
固化具体的流程活动内容、步骤、角色、规则、输入输出等；
L6 流程支撑文件，对L5流程活动形成支撑力的文件：
指导书/表单/模板等：沉淀打法、形成标准，指导IT开发。
2.1 一张图：流程图
能看出来流程图的整体结构是列式分布，左侧一列为业务场景发生的过程中会卷入哪些角色（角色不一定等同于某一个人），右侧一列则是这些角色在整个业务场景中需要做什么活动，也许是审批，也许是知会。
在绘制右侧一列时，要想清楚每一个活动节点的前后关系，流转逻辑，再去布置节点进行连线，不要无限制的拆角色，拆活动，最终一个流程图又臭又长，事无巨细全铺出来，阅读理解成本极高。另外在流程图的绘制会有一些比较通用的规则，如下：
流程图里只能有一个开始，但是可以因为判断条件或其他活动产生多个结束；
2.2 一张表：流程图的说明表
与流程图配套的说明文件，一张流程图对应至少一张说明表，说明表里对每一个活动节点都至少需要说明以下内容：
在流程图及文字说明表输出以后，需要跟业务反复磋商，每一个活动对应的说明都要讨论到，并且要明确告知流程文档是要签字画押的。大多数业务同学很少参与到类似的数字化过程中，产品经理作为IT侧代表在进行研讨会或者业务摸底时，实际上业务都会以一种发散性的思维来回答你的问题，在他与产品经理进行业务描述的过程中，一定会出现信息失真的情况，会有偏差、歧义，东一榔头西一棒槌，这很正常，所以才会有产品经理或者流程师、架构师之类的岗位，不要因为过程中这种阻力对业务产生情绪，我们要做的是，认认真真的听业务说话，仔细思考辨别，哪些他是说的线下动作，哪些是系统流转，哪些是上传下达，哪些是心领神会。
比如业务描述他的动作为：他在业务走到某某节点需要提个单给领导，那我们需要引导提问：你在提单之前的前置动作是什么，你是接到了什么信息或指令；或者咨询业务领导，这一环节为什么要提单给你确认，是业务政策规范性的规定吗？为什么会有这样的规定。他在提这张单的时候，承载形式是什么，oa或者其他系统，或者邮件，或者其实就是口头知会。单据内容有哪些信息？里面的每个信息对应的作用是什么你都逐一确认吗？提完单同意了后续动作要做什么？业务的前置动作加当前活动加后续动作，之间的必然联系与可能流转到大后方的联动规则是什么等等……
这种属于纸上谈兵了，每个公司内部自带的文化性格不同，沟通频率节奏不同，到什么山头就唱什么山歌，各位看官自行辨别，接着说回文件输出
在我们去梳理绘制产出L5流程文件的过程中，大致可以按照思考、落笔、检查这3个阶段和6个步骤来完成，当然根据企业内部的管理情况，也是自行优化减少或增加步骤的；
3.1 第1步：场景识别及场景差异确认
场景识别：业务场景是什么？业务场景描绘的是为了完成业务目标相关的交互过程，包括：时间、地点、人物、在什么情况下、要做什么、怎么解决等要素。
场景差异确认：什么情况下流程图需要区分场景差异？
场景差异示例：
下图中的两个场景都为某一集团公司的订货管理流程，不过因为外部客户向集团公司要货，和集团下属子公司或其他BU向集团公司要货，所要走的业务流程存在显著差异，无法通过简单的说明进行区分，故而拆分为两份流程图说明。
3.2 第2步：痛点分析和业务解决方案设计
梳理团队及内容：由业务专家+流程专家(多数企业没有流程师岗位，由产品岗代替)构成梳理团队：梳理需确保流程的目标明确、流程颗粒度一致、接口流程清晰，流程操作相关人员达成共识。
梳理方法：可通过研讨会，或白板法（准备一块白板，若干便利贴，在讨论过程中将讨论到的点快速记录后贴在白板上）
流程梳理表：对会议讨论的结果进行盖棺定论
确定流程优化目标，利用工具及业内成熟或公司内部总结的方法论，制定相应措施及改进方案(以下为部分方法，不一定具有普适性，当是笔者个人沉淀）。
流程优化方法：
自动化：对高度重复无特殊场景的乏味工作、无效职责、数据采集、数据传递、数据分析…等从产品角度考虑自动化方案。
流程改进方案示例：
以上方法方案，根据各企业内部存在的具体问题，仅可作为参考之一。
3.3 第3步：确定流程的起点和终点
实际上在产品设计过程中，调研盘点业务流程时，我也经常感到棘手的是找到流程最源头的起点，这是一个很模糊很容走偏的过程，例如说我们讲报销流程，报销流程的起点是什么？有的朋友可能认为是提交报销申请，流程则开始。也有人可能认为起点是我为公司付了钱，所以要申请报销。
而笔者认为，报销流程的起点在于企业颁布了某些应该由企业进行支付的但为了灵活性让员工暂时代付的费用类型之后，想对这个应付兑现的过程进行规范管理。这个规范管理的共识形成落地之后，就称之为报销流程，而这个流程的源头，也可以被称之为流程背景或者项目背景。
当然从产品角度来定义，我们肯定以填写报销单提交报销申请这个动作为起点的。
定义流程起点
定义流程终点
3.4 第4步：分步骤绘制流程图——通过5个维度准确描述具体流程
纬度：
流程图示例：
3.5 第5步：编制流程说明——流程说明写作要点
在2.1和2.2大概介绍了一下流程图的核心要素是一张图和一张表，画图大家肯定不陌生，但是编写流程说明表想必就不太清楚了。
每张流程图我们都可以输出一张下面这样说明表帮助阅读者或团队成员理解，达成共识。
A执行角色：执行该活动的角色，可以是个人/团体/组织，不随业务组织结构变化而变化。
B活动名称：编写时尽量采用动词在前，宾语在后结构，如：“编制XX报告”、“创建XX表单”。
C活动说明：
D输入/E输出：
输入、输出物指流程涉及到的信息传递，包括但不限于：工作文档、数据、其他交付件等。
每个活动都需要有输入、输出物，可能是：
F IT信息系统：指明承载该活动的IT系统名称。
3.6 第6步：检查并完善流程——按需输出支撑表单/模板、指导书
这一步是整个L5流程绘制输出的最后一步，需要对之前已经产出的流程方案、文档进行review。效果最好的方式是产品经理、流程师、业务owner一起评审进行查漏补缺，当然，也要对过程中产生的需要额外的指导文件、政策说明进行支撑的地方进行补充，如果这些支撑性的文件较多，可以列出相应的表单，落实责任人及交付日期。
流程表单：
流程表单是流程过程中产生或者使用到的文件、表单等。流程表单在业务流程图中需要明确标识，并作为流程文件的支撑性L6补充文件，按需对填写要求及规则进行说明。例如：
检查流程逻辑、完整性、书写规范等：
在最终的检查中，可以着重按照图中标注的9个点来进行复盘：
以上就是笔者个人梳理的整个L5流程输出过程，仅代表个人观点，供参考。
根据以往做L5流程的经验来看，有明确WBS计划，和没有明确WBS计划的工作效率，大概相差在3-4倍，所以在业务活动启动之前，先制作计划，再按图索骥的找到对应责任人进行分发，是非常关键的开门锤之一。当然，这个世界上不会有做的完美的项目，再充足的准备，再谨慎的计划都会面临各种各样的问题，以下是在流程梳理中，笔者总结的还算是比较常见的问题，仅供各位参考：
以上所有内容相对来说比较严格，因为笔者杂糅了华为内部的标准，ibm流传出来的标准，以及一些质量管理范围内的标准，这些东西分开来看都具有相当高的价值，但是笔者很难验证杂糅在一起后其价值是否起到了正向增长，至少确实在工作实践中，在梳理业务流程时，这样的标准和方法给我带来了很大的助力，并且为企业也留下了非常宝贵的经验和相关标准文档。
因为笔者现在工作环境的原因，这些东西已经用的比较少了，能感受到正在逐渐忘记，所以才开始动笔写一些文章，把这些内容进行沉淀，并非是以行业标准的态度进行分享，欢迎交流。
本文由 @Tom huang 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。