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