怎样做好流程优化？这篇文章里，作者与我们分享了一个与“样品版本”相关的流程分析，并对这一案例做了详细拆解，一起来看看作者是怎么做的，或许会对同为产品运营的你有所帮助或启发。
结合自己之前总结的B端产品运营方法和最近学习的《决胜B端》的知识框架，分享下近期的流程优化案例。
本次主要分享与“样品版本”相关的一个流程分析。
近半年内接收到的与“样品版本”这个版块强相关的需求有3个，分别是“1成品样变更线上化“、“2品质卡审核线上化”、“3样品优化即时入库”，我先让业务提供了自己预期的流程图、以及背景目的。
对于1&2，业务的需求非常简单就是样品审核的动作线上化，减少线下沟通，方便分析。
而“样品优化即时入库”的业务无法直接提供流程和背景，于是我们和业务一起梳理。无法提供流程的原因，是因为业务直接收到仓库的要求，业务并不进一步知道背景（没错，有时候业务只管执行，没有人或者没有空进一步battle不合理性）。
经沟通后，了解仓库要求目前不可以同时留多个样品在库，否则仓库质检时不知道借哪个样品来检查，所以就导致了业务在样品审核后不可以将正确样品入仓，当订单到仓后又借不到最新样品导致可能退货的矛盾问题。本质原因是由于系统上缺乏确定性的订单和样品的对应关系记录。
1）干系人重识别
重新识别干系人是因为提需求给你的人，未必能覆盖核心角色和所有相关部门。通过重新梳理，我们发现实际干系人大大超过我们以为的范围。
2）业务实践调研
通过重新识别的干系人，我们到业务现场重新调研实际操作流程，并对于重新调研的结果，重新组织新的干系人共识会。上面提及的干系人过泛的问题，经过和业务部门沟通，重新指定新的统筹人来对接，譬如业务部门2有3个子部门原本共6个人需要调研，缩减到由1个主要人员先进行统一对接，再对内进行传达。
3）业务目的确认
在干系人共识会上，我们重新与业务确认了需求要解决的目的。
4）流程重新梳理
同时，在干系人共识会上，也重新跟业务共识所有识别到的需求范围，及其系统流程。我们识别到几个重要点与业务重新确认。
3.1 核心方案
3.1.1 核心流程
实际操作中，是针对2.4进行删繁就简&状态机梳理。本次案例说明为方便陈述已经删繁就简，基本内容同2.4，不再赘述。
3.1.2 功能模块思考
在这里我们遇到了三个模块合并方案问题，因为如果所有流程都按照最小颗粒度去做流程，会存在很多模块耦合，需要考虑按照什么维度去合并。可以梳理的方向有3个，分别为“成品样泛变更、首次审核、品质卡审核”。
于是我们从“未来延展性”出发，再细分三个角度思考哪些模块最终应该合并。
1）当前流程是否相同：经过分析发现，Q1不同、Q2&Q3则当前流程相同。
2）功能定位、主导方分析
Q1成品样泛变更：目的是审核非正常变更样品，业务上会尽量避免（因为丢失、或者不得不替换），主导方是“审核部”；成品样优化的定位，是对好卖但品质问题商品进行迭代，业务上“尽量多，且由最源头厂商发起”，主导方是对销量负责的“业务部2”。
Q2首次审核：定位都是新样品审核，只是审核类型不同，但主导方都是“审核部”。
Q3品质卡审核：首次审核和变更审核定位不同，一个是新样品，一个要替换的样品，主导方都是“审核部”。虽然在业务沟通中审核部一直希望Q3两个版块进行融合，但是基于Q2的结论，还是让步于将Q2的两个样品审核优先融合，否则未来改造问题比较多。经沟通后也同意，因为理论上品质卡变更要减少，并非常规流程。
3）未来功能拓展方向
Q1：基于功能定位考虑，可预想Q1两个模块未来的数据来源、展现形式会呈现比较大的差别。成品样变更会更倾向于“发起限制、流程合规”，而成品样优化会更倾向“鼓励发起、发起后效果比照”。
Q2：不会有太大变化，都只是正常商品发起流程，能走完即可。
Q3：品质卡变更会与“成品样变更”流程更融合，因为都是合规操作。而品质卡新卡审核也会跟成品样首次审核更容易，确保能走完即可。两者走向明显不同。
最终结论：基于以上三点综合分析，决定只将Q2两个功能融合，其它两个则进行区分。
3.1.3 演进蓝图
在本流程中，主要跟业务共识如何分阶段实现功能、每个阶段大概多久、功能模块业务是否认可。
3.2 方案细节
在《决胜B端》一书中，方案细节涉及到以下几个内容“业务数据建模/流程和角色/界面设计/报表设计/数据埋点/权限设计/文档编写与管理/UML和常用图表”。本案例中由于F1&F2的上述细节都比较简单，不展开说明，只针对F3中争议比较大的“ER图”方案进行分享。
经过梳理，发现“F3：各种商品资料对应落到样品版本+更过程商品资料记录”，需要处理的数据关系有如下。
进一步梳理数据关系：
其中难点在于处理“SKU、Yn&yn、Zn”的关系，经过分析进一步发现其中不明确的主要是“当SKU同时要参考Y和y（成品样+品质卡）时，商品资料如何处理”，我们提出多个方案和产品业务讨论，看哪个方案既能解决业务问题，又尽量简化产品模型。
在实践中很难有完美又简单的方案，也没有统一标准答案，有的只有不断的沟通和协调，不能试图找一个永远不变的方案，有可能方案做了半年一年要重构，要做好这样的准备，因为业务一直在变。
最终我们的方案打破了以上的预设框架，把品质样版本废除，直接划入生产资料中。
这个环节要提供的分享方法不多，只分享一下实际操作中上线前的运营计划、验收用例、业务问题反馈跟进表格，属于常规运营。
[上线前待办计划]
[验收用例梳理&实际验收处理方式]
[上线后业务问题登记&处理反馈]
由于公司架构原因，我司有单独的产品经理、产品运营（我这个岗位）、业务运营。在这个流程里，我也不断思考，我和其它岗位的区别是什么，独特的价值是什么？
我总结了一下三个点，不是行业通用区别，只基于我司岗位要求和职责做分析，仅供参考~
业务运营负责梳理自己理想的业务流程，而我们则要根据业务的理想，识别清楚业务真实的目的、要解决什么问题、业务提供的流程是否真的能快速解决业务问题？会否只考虑自己部门的操作而影响了其它配合部门的便捷性，是否会降低整体操作流程的顺畅度（例如需求2会加入目前影响不大的必要流程）。
甚至有的时候，业务都不一定知道自己要解决什么根本问题（例如需求3），不能提出解决方案，只是提供了某个问题点。
识别出问题后，我们要帮助业务规划和设计切实落地的方案流程，达到业务需要的结果。在这个流程中，我们识别出版本关系这个需求，这个是业务不会提供的，因为他们能看到表面问题，不一定能知道内在设置有什么关键卡点。我们对于流程的设置区别于产品经理在于，产品要集中全力设计功能模块和如何快速实现，而我们产品运营角色则要统筹业务方的诉求和矛盾。
有了方案，我们还要帮业务规划节奏、要快速解决主要矛盾、要跟产品开发要资源，要一起快速解决业务问题。在本次案例中，业务最迫切 需求是线上化，于是我们也先帮业务解决线上化的流程，同时梳理复杂的版本资料逻辑，这样多个方案可以并行，尽量提高上线效率。而产品经理则根据我们提供的流程，寻找技术上快速实现的方法，我们的敏捷在于业务模块节奏，产品经理敏捷在于技术实现
以上三个价值点，决定了目前我所身处的产品运营岗位，比起业务运营要更理解业务运营要更能从宏观视角识别问题、要更从系统落地的角度提供解决建议。比起产品经理，则要具备沟通和协调的能力，统筹引导业务流程统一，让业务进展更合理，减少一些非必要和后续要重复开发的、复杂的功能。
本文由 @我叫更更 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。