B端产品经理的流程设计思维

回首入行产品经理也已多年，做的项目也由C到B，由前到后都已涉及，辗转跨行仍觉互联网学海无涯，还是需要保持输出。思前想后还是决定聊一聊在过往服务多家大型集团的工作经历中十分重要，但却普遍不被视为产品经理必备能力的流程设计。此文不做具体的项目总结，也不讨论某一实际功能的设计。只以产品经理的角度，聊一聊对流程的认知、价值、操作指引，个人思考仅供参考，共勉。

目录：

一、流程管理综述

1. 关于流程认识的几个误区
2. 流程的理论渊源与业务价值

二、详细流程设计方法

1. 流程框架 VS 详细流程的定义
2. 流程文件的核心要素：一张图、一张表
3. L5流程设计指引、案例及常见问题
4. L5流程梳理项目的策划与筹备

一、流程管理综述

1. 流程是什么——关于流程认识的误区

我相信看到这篇文章的产品经理们肯定都梳理过业务流程，输出过对应的流程文档，对流程都有自己的定义和理解。但是将自己抽离出来，回顾去看自己输出的流程文件的时候，可以试着用一段文字或者一段话来描述出你认为【流程】是什么？

这好像是一种说不清道不明的共识，只要一提到无需多说自能心领神会。流程嘛，无非是步骤、操作、业务行为的体现，但是仅仅如此吗？

2. 流程是什么——流程的理论渊源

关注流程的时代已经到来，从根本上说，流程是我们组织价值创造的机制。   ——哈默

个人认为在定义流程是什么之前，首先要对流程设计的应用逻辑有一个简单的了解。上图是笔者根据质量管理大师戴明提出的SIPOC组织系统模型进行理解后绘制的示意图，抽象来理解就是企业在基于一定的资源输入之后，通过一系列相关联的标准规范的业务活动，将其转化为对客户有价值的输出的过程。

这样理解有点拗口，我从产品经理的视角来举个例子进行阐述，可以理解上图中的流程为一个中台的概念：

在电商行业中从上游PLM、PDM或者MDM主数据平台拿到商品主数据，输入给运营中台去执行一系列的包装活动(维护商品详情图、首图、各种划线价挂牌价、商品配送费、可售库存等等信息)之后，输出给不同的前端渠道(淘宝、拼多多、京东、苏宁、国美电器、唯品会、蘑菇街等等)触达用户，完成端到端的闭环。

权力要放进流程中，流程才有权力，最高领袖没有权力，最高领袖只能做规则。——任正非

那是否只要有资源投入，我就一定要通过按流程执行业务活动的方式，才能够对客户输出价值呢？

一般来讲，微小型企业因为岗位少，人少，公司的运作情况每一个一线的员工都心知肚明，从后端生产到渠道销售，链路并不长，所以在执行业务动作的时候，并不需要具体的标准流程，因为大家都知道自己要做什么，做了之后会产生多少价值。

而中大型企业(基本指千人以上），岗位设定复杂，各部门各职位的职责已经细分到了几乎是等同信息孤岛的地步，如同一条手机生产的流水线上坐着200个人打螺丝，谁都不知道自己打的这颗螺丝在后续的质检、物流运送、售后、使用体验上会有什么样的使用场景。如果没有标准的流程管理，那就会出现每个员工都只知道这颗螺丝给到手上，我要把它打几圈赶紧交给下一个人，就算后续出了问题，也无法定位，更不要说优化提效。因此我们对流程的定义可以概括为以下两点：

• 流程是过程管理，只有管理好过程，才能得到好的结果；
• 流程是界定和管理组织内部各岗位之间协作规则的方法。为了方便读者理解流程的概念，可以简单粗暴的概括为：（1）跨3个及以上的岗位；（2）重复发生；的工作都需要制定标准流程进行管理；

 

3. 流程是什么——分粥的故事

针对以上的定义，我举个分粥的例子来进行补充阐述流程设计的价值。

预设这样一个场景，五个流落荒岛的人要分一锅粥，每个人都争先抢后生怕自己分不到，最后打翻了锅，大家都没有吃上。我们尝试对这个分粥的场景进行流程的设计，来解决这个问题，有以下方案：

1. 把五个人的名字写在石头上，抓阄抓到谁，谁就来分粥，每个人每天抓一次
2. 成立两人分粥委员会，和三人评委，两个人负责分粥，另外三个人负责评审这两个人分的粥是否合理
3. 五个人轮流分粥，分好粥以后，分的那个人最后选粥

以上3种方案想必大家一样就能看出来哪个是最优解，第1种方案效率极高，但是可能会出现多次抓阄都抓到同一个人分，而分的人又故意给自己多分，给别人少分；第2种方案执行起来谨慎规范，但效率极低，等两个人分好，三个人去评审，粥都凉了还没吃上；第3种方案，分粥人为了保证自己拿到的不是最少的，只好尽量分的平均。

当然，如果是实际业务场景，其实还要考虑更多的情况，比如第3种方案还要考虑分粥人和其他四人中的某个人存在利益关系，让他宁愿自己是最后拿的，也要把给某个人的粥分的最多，以此交换某些隐形资源，这是大型企业中非常常见的现象，不过此文就暂不讨论了。

 

4. 流程是什么——降落伞的故事

我们再来举一个降落伞的例子，也是我在读别的文章时看到的比较有意思的一个故事，正好可以用在本文当中。

可以在上图中看到，第1个场景中，降落伞生产商交付给客户的产品，总是只有99%的合格率，生产商提高员工培训，更换高精尖的生产仪器，提高质检规格，最后交付到客户手上，仍然有1%的不良率；

于是在第2个场景中，我们对整个交付的机制和流程做一点小小的优化，生产商把降落伞交付给客户之后，客户先抽取几个让生产商使用，生产商使用没有问题后，客户再进行验收，投入市场使用。最终生产商为了避免那1%的不良率出现在自己身上，终于将产品的合格率提升到了100%。

当然，这个故事太粗暴简单，实际场景也并不会这样浅显，此处只是作为一个典型的案例来帮助读者理解流程设计的价值。通过以上两个案例可以再深入一点的理解流程的定义：

• 流程是业务过程的体现，流程中融合了管理机制和规则等；
• 企业业务流程建设就是识别最佳实践，并进行固化和推广；

小结

流程设计的思维就是追本溯源，从产生问题的本质原因寻找有效解决问题的必要办法。用华为的定义拓展开来就是：流程是在特定企业环境及资源保障下，为了实现客户价值和企业商业目标而形成的一套规范业务运作规则和机制：即通过一系列可重复、有逻辑顺序的活动，按照相关的政策和业务规则，将一个或多个输入转换成明确的、可度量的、有价值的输出。

而产品经理在进行业务分析，产品规划时，所需要的能力恰恰是与流程设计的思维是高度吻合的，没有哪个公司在业务陷入停滞，内部管理体系繁复冗余，各部门主义林立，各路诸侯心怀鬼胎的时候，会让产品经理来优化系统，来做产品方案。

真到那个时候，像华为的任正非都亲自写邮件邀请IBM的团队参与到华为管理流程体系建设当中，从顶层设计、到业务流程的重组，到LTC（lead to cash）流程架构模型的设计，几乎是IBM大刀阔斧把华为的管理水平带上了国际舞台(这部分内容在华为相关的书籍中都能看出来)，不过也正是因为如此，在华为今年初宣布上线切换全自研ERP之前，业内一致高度怀疑IBM在华为内部留了后门……

扯远了，此文只代表笔者对过往的就职经历中所接触和理解到流程设计的定义做讲解，仅代表个人观点，非业界共识，欢迎良性讨论。具体流程设计操作方法论，流程文档攥写的标准，笔者打算再开一篇新贴进行总结和沉淀。

 

二、详细流程设计方法

1. 流程分层与流程文件类型的对应关系（L5流程的定位）

一个企业或者一个商业主体，在生产销售进行市场运营行为的过程中，涉及的流程可能成百上千，甚至破万。有的流程可能涉及公司战略走向或者上百万的经费调用，有的又可能只是一颗螺丝钉的入库流程；有的流程需要走系统走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. L5流程的核心要素：一张图、一张表

2.1 一张图：流程图

能看出来流程图的整体结构是列式分布，左侧一列为业务场景发生的过程中会卷入哪些角色（角色不一定等同于某一个人），右侧一列则是这些角色在整个业务场景中需要做什么活动，也许是审批，也许是知会。

在绘制右侧一列时，要想清楚每一个活动节点的前后关系，流转逻辑，再去布置节点进行连线，不要无限制的拆角色，拆活动，最终一个流程图又臭又长，事无巨细全铺出来，阅读理解成本极高。另外在流程图的绘制会有一些比较通用的规则，如下：

• 按照阅读理解习惯，流程的开始和结束，在流程图中如无特殊需求，尽量是按照从左上到右下的结构呈现；
• 节点和节点之间连线时，标记箭头方向，明确节点完成后流转到哪里，一般按照左进右出，或者上进下出的原则进行绘制。整张流程图，尽量按照一个规则，不要一会儿左进下出，一会儿上进右出，在业务对接过程中可能造成歧义：

• 流程图里只能有一个开始，但是可以因为判断条件或其他活动产生多个结束；

• 如果连续3个相邻的活动节点，刚好都是审核或者判断，为降低理解成本，可以拆开在中间插入一个无关紧要的动作打断一下，如果团队配合默契高能够快速达成共识，则可以不用；

• 一个流程，多个场景拆开做，不要做成结构图，如订单履约的场景，一个履约的场景可以拆出正反主流程去阐述，不要在一个图里无限衍生；

2.2 一张表：流程图的说明表

与流程图配套的说明文件，一张流程图对应至少一张说明表，说明表里对每一个活动节点都至少需要说明以下内容：

• 活动编号：按照流程执行顺序，以001、002、003…的数字序列编号
• 执行角色：执行本活动的角色名称
• 活动名称：需要角色去执行的活动的名称
• 活动说明：活动实施的具体过程、步骤、方法和结果描述
• 输入：活动实施需要的输入指令、文档、实物等信息
• 输出：活动完成后输出的指令、文档、实物等信息
• it系统：若该活动需要IT系统支撑，列明IT系统名称

在流程图及文字说明表输出以后，需要跟业务反复磋商，每一个活动对应的说明都要讨论到，并且要明确告知流程文档是要签字画押的。大多数业务同学很少参与到类似的数字化过程中，产品经理作为IT侧代表在进行研讨会或者业务摸底时，实际上业务都会以一种发散性的思维来回答你的问题，在他与产品经理进行业务描述的过程中，一定会出现信息失真的情况，会有偏差、歧义，东一榔头西一棒槌，这很正常，所以才会有产品经理或者流程师、架构师之类的岗位，不要因为过程中这种阻力对业务产生情绪，我们要做的是，认认真真的听业务说话，仔细思考辨别，哪些他是说的线下动作，哪些是系统流转，哪些是上传下达，哪些是心领神会。

比如业务描述他的动作为：他在业务走到某某节点需要提个单给领导，那我们需要引导提问：你在提单之前的前置动作是什么，你是接到了什么信息或指令；或者咨询业务领导，这一环节为什么要提单给你确认，是业务政策规范性的规定吗？为什么会有这样的规定。他在提这张单的时候，承载形式是什么，oa或者其他系统，或者邮件，或者其实就是口头知会。单据内容有哪些信息？里面的每个信息对应的作用是什么你都逐一确认吗？提完单同意了后续动作要做什么？业务的前置动作加当前活动加后续动作，之间的必然联系与可能流转到大后方的联动规则是什么等等……

这种属于纸上谈兵了，每个公司内部自带的文化性格不同，沟通频率节奏不同，到什么山头就唱什么山歌，各位看官自行辨别，接着说回文件输出。

 

3. L5流程绘制指引 6步法

在我们去梳理绘制产出L5流程文件的过程中，大致可以按照思考、落笔、检查这3个阶段和6个步骤来完成，当然根据企业内部的管理情况，也是自行优化减少或增加步骤的；

3.1 第1步：场景识别及场景差异确认

场景识别：业务场景是什么？业务场景描绘的是为了完成业务目标相关的交互过程，包括：时间、地点、人物、在什么情况下、要做什么、怎么解决等要素。

场景差异确认：什么情况下流程图需要区分场景差异？

• 当业务流程在不同场景下存在显著差异时，需要区分不同的场景编写流程图；
• “流程名称”后以括号说明场景，如订货管理流程(外部客户要货)/订货管理流程(内部要货)；

场景差异示例：

下图中的两个场景都为某一集团公司的订货管理流程，不过因为外部客户向集团公司要货，和集团下属子公司或其他BU向集团公司要货，所要走的业务流程存在显著差异，无法通过简单的说明进行区分，故而拆分为两份流程图说明。

 3.2 第2步：痛点分析和业务解决方案设计

梳理团队及内容：由业务专家+流程专家(多数企业没有流程师岗位，由产品岗代替)构成梳理团队：梳理需确保流程的目标明确、流程颗粒度一致、接口流程清晰，流程操作相关人员达成共识。

梳理方法：可通过研讨会，或白板法（准备一块白板，若干便利贴，在讨论过程中将讨论到的点快速记录后贴在白板上）

流程梳理表：对会议讨论的结果进行盖棺定论

确定流程优化目标，利用工具及业内成熟或公司内部总结的方法论，制定相应措施及改进方案(以下为部分方法，不一定具有普适性，当是笔者个人沉淀）。

流程优化方法：

• 清除：寻找可清除的等待时间、加工存储、重复、多方协调…等场景，与业务owner、开发leader、项目干系人之间达成共识后清除掉
• 简化：列出流程中会涉及的表格、程序、沟通、技术、子流程…等因子，研讨后进行简化
• 整合：整合影响小价值低的流程、组织、团队、顾客等

自动化：对高度重复无特殊场景的乏味工作、无效职责、数据采集、数据传递、数据分析…等从产品角度考虑自动化方案。

流程改进方案示例：

以上方法方案，根据各企业内部存在的具体问题，仅可作为参考之一。

3.3 第3步：确定流程的起点和终点

实际上在产品设计过程中，调研盘点业务流程时，我也经常感到棘手的是找到流程最源头的起点，这是一个很模糊很容走偏的过程，例如说我们讲报销流程，报销流程的起点是什么？有的朋友可能认为是提交报销申请，流程则开始。也有人可能认为起点是我为公司付了钱，所以要申请报销。

而笔者认为，报销流程的起点在于企业颁布了某些应该由企业进行支付的但为了灵活性让员工暂时代付的费用类型之后，想对这个应付兑现的过程进行规范管理。这个规范管理的共识形成落地之后，就称之为报销流程，而这个流程的源头，也可以被称之为流程背景或者项目背景。

当然从产品角度来定义，我们肯定以填写报销单提交报销申请这个动作为起点的。

定义流程起点

• 《费用报销流程》流程起点是“填写报销单”；
• 《端到端合同交付流程》流程起点是 “接收客户合同”。

定义流程终点

• 《费用报销流程》流程终点是“报销凭证生成存档”；
• 《端到端合同交付流程》流程终点是 “客户验收确认”。

3.4 第4步：分步骤绘制流程图——通过5个维度准确描述具体流程

纬度：

• 活动：流程中的行为列表和行为的结果
• 时间：活动发生的时间/顺序
• 角色：组织/团队/个人按角色进行活动
• 数据/文档：流程步骤中涉及的输入、数据、输出文档
• 工具：每个活动的工具载体，如某个IT系统，某个程序或者某个人纯手动进行

流程图示例：

采用横向泳道图的方式绘制；

• 若存在多个细分场景，且管理流程有较大差异，建议拆分为不同的L5，“流程名称”后以括号说明场景，如供应商认证流程（原材料供应商认证）；
• 不应出现跨多个泳道的活动，若涉及多方参与时，可考虑在泳道上标注出各自的活动，并用联合办公框来说明。

3.5 第5步：编制流程说明——流程说明写作要点

在2.1和2.2大概介绍了一下流程图的核心要素是一张图和一张表，画图大家肯定不陌生，但是编写流程说明表想必就不太清楚了。

每张流程图我们都可以输出一张下面这样说明表帮助阅读者或团队成员理解，达成共识。

A 执行角色：执行该活动的角色，可以是个人/团体/组织，不随业务组织结构变化而变化。

B 活动名称：编写时尽量采用动词在前，宾语在后结构，如：“编制XX报告”、“创建XX表单”。

C 活动说明：

• 按照该活动的步骤展开，可以分1. 2. 3. 小节点区分，活动说明的颗粒度以支撑业务运作为原则，澄清关键业务逻辑规则，如：颗粒度要求、特定的模板要求、周期性要求等；
• 如果一个或多个流程活动有较强的专业作业工序，可以制定该活动的指导书/模板/表单，作为支撑文件。

D 输入/E输出：

输入、输出物指流程涉及到的信息传递，包括但不限于：工作文档、数据、其他交付件等。

每个活动都需要有输入、输出物，可能是：

• 实体文档/模板，需要在流程图中标注，并在流程文档中填写；
• 非实体交付物（如：意见/建议/决策结果等），需要在流程文档中填写

F IT信息系统：指明承载该活动的IT系统名称。

3.6 第6步：检查并完善流程——按需输出支撑表单/模板、指导书

这一步是整个L5流程绘制输出的最后一步，需要对之前已经产出的流程方案、文档进行review。效果最好的方式是产品经理、流程师、业务owner一起评审进行查漏补缺，当然，也要对过程中产生的需要额外的指导文件、政策说明进行支撑的地方进行补充，如果这些支撑性的文件较多，可以列出相应的表单，落实责任人及交付日期。

流程表单：

流程表单是流程过程中产生或者使用到的文件、表单等。流程表单在业务流程图中需要明确标识，并作为流程文件的支撑性L6补充文件，按需对填写要求及规则进行说明。例如：

检查流程逻辑、完整性、书写规范等：

在最终的检查中，可以着重按照图中标注的9个点来进行复盘：

1. 流程目的：为了达成什么效果(降低退货率、提高客服咨询满意度等)，满足客户的什么需求(电子合同签单、减少残次率等)，提供什么样的服务，产生什么样的价值；
2. 流程的起点：从哪个节点开始，这个流程启动，由x部门x人员负责；
3. 上游流程/输入：外部转入到本流程的流程，为本流程提供输入。例如，库存上架流程的上游流程/输入为采购入库(或者退货入库流程，转移入库流程)，员工人事变动流程的上游流程/输入为绩效评估或综合素质评估流程；
4. 流程图：说明整个流程中的参与角色、涉及阶段、活动节点、串联关系的可视化设计；
5. 流程终点：从哪个节点开始，这个流程结束，不再由x部门x人员负责；
6. 下游流程：本流程转出的目标流程，本流程提供输出（为其提供输入），例如订单处理流程的下游流程为发运流程，员工晋升流程的下游流程为薪酬变动流程；
7. 流程图说明文档：对流程图进行文字说明，需讲明在流程图中的每个因子的底层逻辑；
8. 相关要求：整体流程方案的相关要求是否达标
9. 相关模版：支撑该活动执行所需的表单、模板、检查表、指导书、规范/标准（L6文件）

以上就是笔者个人梳理的整个L5流程输出过程，仅代表个人观点，供参考。

 

4、L5梳理项目管理：明确优先级、责任人，制定L5输出WBS计划

根据以往做L5流程的经验来看，有明确WBS计划，和没有明确WBS计划的工作效率，大概相差在3-4倍，所以在业务活动启动之前，先制作计划，再按图索骥的找到对应责任人进行分发，是非常关键的开门锤之一。当然，这个世界上不会有做的完美的项目，再充足的准备，再谨慎的计划都会面临各种各样的问题，以下是在流程梳理中，笔者总结的还算是比较常见的问题，仅供各位参考：

5、总结

以上所有内容相对来说比较严格，因为笔者杂糅了华为内部的标准，ibm流传出来的标准，以及一些质量管理范围内的标准，这些东西分开来看都具有相当高的价值，但是笔者很难验证杂糅在一起后其价值是否起到了正向增长，至少确实在工作实践中，在梳理业务流程时，这样的标准和方法给我带来了很大的助力，并且为企业也留下了非常宝贵的经验和相关标准文档。

作者来源：硬核刘大

好文分享 侵删