产品经理如何从0到1规划新零售供应链核心系统（下篇）

「 以下故事情节及人物均为作者杜撰，若有雷同，纯属巧合：

    小Q：某医药互联网公司后台产品经理，着手规划重构公司的电商及供应链系统；

    飞哥：小Q领导，后台产品部总监；

    云老师：CTO，掌管整个技术体系；

    浩子：产品经理，小Q的小弟，协助小Q推进大后端重构项目。」

        周五，对很多白领来说是一周中最美好的一天，过完这一天就能迎来天堂般的周末，懒觉、逛街、游戏，尽情潇洒。当然对一些工作没完成的人来说就是最黑暗的一天，如果今天干不完，周末将是无尽深渊，当然工作狂除外。

        对于小Q来说，今天是提供后台系统整体规划方案的期限，是美梦还是噩梦，就取决于今天下午向云老师汇报的结果了，所以还是早早的到了办公室，趁早上的时光抓紧赶工。虽然平日里大小业务讨论会上很少见CTO的身影，但通过昨天下午一起讨论业务流程的过程来看，云老师对公司业务的了解程度远比小Q要深入的多，而且专业性极强。所以无论是为了公司，还是为了维护产品部的专业性，亦或是为了自己的颜面和在药健康的未来，这一份整体规划方案都不能有失水准。

01 从业务流程到系统功能，再到系统划分

        昨天将公司里的7大主营业务流程全部梳理完毕，各业务部门负责人也分别邮件确认了，按照小Q惯用的产品套路，接下来就是将业务流程与系统功能结合的过程了，这其实就是产品经理进行需求分析的过程。

        第一步，先把各业务流程中的业务场景进行横向拆解，以角色为单位将场景进行汇总。

        比如，采购部的一名普通采购员，按照采购和首营流程，我们将其日常工作的业务场景汇总呈列一下：供应谈判、供应商及商品资料收集、供应商首营、商品首营、采购询价、采购价格维护、采购计划、日常补货、缺货补货。

        第二步，区分开这些业务场景中哪些是需要系统完成的，哪些是线下完成的。

        第三步，针对需要系统完成的这些业务场景，即为我们设计系统时需要重点关注的（当然需要考虑怎样与线下操作的场景串联起来，不能出现流程断档）。将这些业务场景进行功能拆解，最好到每个需求用例（功能点）维度。

        第四步，将拆解完毕的功能点进行系统划分，尽量把业务相似度高的功能规划到一个系统中。比如都是对商品资料进行操作的功能，都规划到基础数据中。

        按照以上步骤，以上第一步的例子中，采购部的采购员和采购经理的业务流程拆解过程如下：

▲ 采购部各角色系统功能拆解示例

         按照以上方法，终于赶在午饭前将系统整体规划图给画出来了并整理为汇报PPT，没有影响下午的汇报。为了犒劳一下这周辛苦的脑细胞，小Q决定中午给自己加个餐，吃个鲍鱼龙虾双拼套餐去……

        （各个系统的主要功能拆分，放到后续章节中呈现，不在这里详列）

        这一套方法论是小Q刚毕业时作为校招生进入第一家公司，跟着产品的启蒙师傅凯哥学来的，后来就如同打通了需求分析能力的任督二脉，凭借三板斧一路叱咤到现在。想起凯哥，当年长期一起出差做项目，同吃同睡同玩，既是自己的产品启蒙老师，也是一位年长的老大哥，教了自己很多为人处世的道理。一晃许多年没见面了，甚是想念。

02  系统整体规划方案汇报会  

        下午1点50，小Q和浩子（浩子，飞哥新安排过来的小弟，协助小Q一起梳理供应链系统，很潮的90后，热爱健身的纹身男）先行来到了提前预订好的会议室，调试了一遍投影设备，清点了一下椅子和白板笔，保证2点汇报方案的时候不出现意外情况。呆会云老师和技术部的各负责人，以及相关核心员工都会到场，多浪费大家一分钟时间，就是在拖整个技术部的后腿，罪莫大焉～

        2点的时候，云老师、飞哥和几位技术总监，以及各个部门的架构师全部就位，小Q默数了一下，共15人，整个供应链研发体系的主力军全在了，搞定这帮人，项目也就成功了80%。

       小Q打开上午完工的《药健康后台系统规划方案》ppt首页给大家投屏。这是由公司标准模板制作的红白相间的流线型封面页，右上角是公司logo，很具科技感。

        飞哥先开场：“大家下午好，这个会的主题是将咱们产品部梳理的公司主营业务流程和系统规划方案给大家汇报一下，欢迎大家一起拍砖，在坐的都是咱们技术部最权威的专家，掌握着药健康的技术命脉，希望在这个项目后续开展过程中能得到大家最大力度的支持，我们力争一起把大后端系统打造成一个行业标杆！”，飞哥讲完后对小Q点了下头，示意可以开始了。

      没想到老大在捧人方面这么厉害，平日里真没看出来，果然是个老生姜……

      “各位领导同事们好，我先给大家汇报一下咱们公司的供应链主营业务情况。”，小Q翻到章节第一大部分：“公司供应链主营业务流程梳理”，对在座的所有人详细的汇报了这几天和各方确认过的流程情况......

（流程汇报不在此重新展开，对新零售供应链主营流程感兴趣的童鞋可参考前序章节：

    产品经理如何从0到1规划新零售供应链核心系统-中篇）

03  一个简易电商新零售的产品架构

        “针对以上流程，我们给出两套解决方案：A方案-简易方案  和    B方案-典型方案”。介绍完流程后，小Q对现场同事的问题一一做了解答，然后切入到章节第二大部分：‘’系统整体规划方案‘’。

        “A方案是比较简单的方式，说直白点就是将我们的ERP和OMS中供应链相关功能进行一次翻新，打造一个全新的大ERP系统供总部所有部门的同事使用。考虑到仓储和配送系统需要独立在各个仓库和配送中心分别部署，所以这两个后端物流系统独立设计开发。”

▲A方案：一个简易电商新零售的产品架构（参考）

        “用户在电商平台下的订单，通过接口流到ERP，ERP中的订单管理和库存管理模块对订单集中处理，进行履约分发，将订单下发至仓库或者门店进行出库作业。库房或门店发货以后，订单配送信息再通过配送单的形式流转至配送系统，在配送系统中承接包裹的物流配送工作。所有在途的信息均通过ERP系统中的订单模块返回电商平台，供用户查阅。”

04 一个典型的电商新零售的产品架构

       “说完A方案，再来说B方案，这是一个典型的电商系统设计模型，按照业务来划分，将各个业务独立成为子系统，各个子系统之间互不干扰，通过服务进行交互，这样可以不受语言和平台的限制，每个系统可以独立开发上线。这也是主流互联网公司的标准打法。”

▲B方案：一个典型电商新零售的产品架构（参考）

05 简易方案好，还是典型方案好？

       “两种方案各有利弊，我们进行了对比分析，请看。”，小Q按了一下鼠标，PPT播放到了优劣势对比页，继续说道。

       “总结一下，我们认为如果业务量比较小，并且公司业务相对稳定、不会经常有大变化，比较适合A方案-简易架构；如果业务发展比较快，且经常会有新的业务尝试项目的话，那就比较适合B方案-典型架构。”

▲典型架构与简易架构对比

        “下面想听听各位专家大神的建议。”，这个关键性的问题，小Q个人拿不定主意，需要征询大家的意见。

         “大家伙儿的意见呢？”，云老师转过头面向各位专家。

         “我认为A方案比较合适，因为现阶段咱们业务量还不大，并且研发也没有这么多人，如果用B方案的话，咱们的投入成本会增加好多。”，阿黄提议到。

        “我认为应该B方案，咱们既然是互联网公司，就应该有互联网公司的技术体系，并且公司业务在逐步变大，说不定还没上线就要重新规划B方案了”，电商研发负责人老芒建议。

      “我也认为A方案......”

       “我认为......”

          一时之间，大家话匣子打开了，各执己见，整个会议室从开始的严肃拘束变成了现在的热火朝天。小Q应付着各位的发言，同时瞟了一眼大boss，只见云老师身子往后略倾，双臂抱怀一言不发，默默的听着大家的讨论。

       “时间差不多了，大家先收一收。”大约10分钟过后，云老师站起来招呼大家安静一下，然后让小Q翻回到方案对比那一页ppt，面向大家说道：“大家的意见都很有道理，以我们现阶段的情况来看，确实是A方案最适合咱们。但我们是否要按A方案执行？我的建议是 no。

        兄弟们，咱们虽然是做技术的，但也需要多关注一下公司业务情况。我给大家分享两个数据：

        一，根据近半年的销量数据来看，我们的GMV每个月比上个月平均环比上升15%，这是一种多快的增长速度？只需要5个月，我们的业务量就会翻番；

        二，现在的医药互联网市场一片蓝海，国家政策又一片利好，万亿级的大盘子一旦打开，只要10%的流量流向互联网，那就是千亿，哪怕只分我们千分之一，咱们的系统承接的住吗？

        所以啊，同志们，你们是选择每次都被业务追着跑呢，还是选择在终点等业务？答案很明显，我们技术应该敢为人先，先行一步，为公司铺好路。我拍了，就按B方案执行，资源问题我来解决。大飞、老芒，这事你俩全力跟进，尽快推进落地！”

        CTO果然有魄力，而且看问题的高度也明显不一样。 小Q想着往后一定要多提升自我认知，不能让格局阻碍了自己的视野。

      “小Q，PPT后面还有吗？”，CTO问道。

      “没有了。最大的争议点就是AB方案问题，确定以后我们就继续可以往下推进了”。小Q回答。

      “好，方案做的不错，看得出来是花了心思的，大家给产品部一个掌声！”，云老师带头鼓掌，会议室一片哗然。

         接着，云老师安排了新任务：“后面，你们就按照B方案把整个系统流程设计一下，系统功能再细化一下，下周三我们再开个会，我也参加。”

      “收到！” ，即便老师不安排，这件事也是小Q计划去实施的，这是整体方案往下推进的重要环节。

06  总结：从0到1规划大后端系统的步骤

       会议结束后，小Q和浩子溜到楼下空地抽了支烟。

    “Q哥，很有大将风范啊，这么多领导在场你都hold住了，我是越来越佩服你了，请受小弟一拜！”，浩子比划了一个作揖的姿势。因为双手往上举的缘故，胳膊上原本被T恤袖口遮住的麋鹿纹身很清晰的露出来了。

    “得得得，这还不是得益于咱们英明神武的飞哥教导有方啊？”，小Q谦虚的将功劳转给了飞哥。

    “你给我分享一下这个方案从始至终的历程呗！我很好奇你是怎么一步步的做出来这么个大家都认可的方案的。”，浩子抬起手吸了一口烟。

    “给你总结一下啊，当我们接到一个项目以后，一般要经过这么5步，把业务需求转换为系统方案。”，小Q左手叉腰，右手食指和中指夹着烟头在空中自上而下的划动着，一派指点江山的范儿，抖掉的烟灰随风散落在脚边的花坛里，化为花草的春泥。

    “  第一步，业务部门及职责梳理。当你不知道从哪里下手的时候，就先把你的业务部门和部门职责先梳理一遍，这样就会比较清楚每个部门大体的工作情况了。

         第二步：业务流程梳理。这是最考验产品经理能力的一环，沟通能力、协调能力、分析能力缺一不可。一个完整的业务流程经常要跨好多部门好多岗位，而且有系统操作，也有非系统操作，咱们一定要精确的找到每个业务的关键节点，把关键节点串起来形成完整的流程闭环。很多流程涉及多个部门利益冲突，所以产品经理明辨是非的能力很重要。

         第三步：业务流程确认。流程梳理完以后，一定要跟各方确认，千万不能闭门造车。

         第四步：系统功能点拆分。拿着各方确认的流程，按照流程节点将系统功能点具象化出来，然后再按照业务边界进行系统的划分。

         第五步：整体方案出具。按照提炼的系统功能点，找到各个系统之间的联系，再从系统的角度反向验证业务流程，不断完善，直到所有的业务场景都能覆盖到，那这个方案就是你想要的方案了。”

       “似懂非懂，等我跟你一起细化的时候，再逐渐领悟吧，请再受小弟一拜......”，浩子继续调侃。

         短短的一周，从焦头烂额到现在的谈笑风生，从对供应链的一知半解到现在的多方认可，从老A的倾囊相授到现在对浩子的总结传承，小Q自己都感觉到自己的飞速成长。进步的感觉，真好！

        在黑暗中摸索前行的过程是痛快的，因为你永远不知道下一脚踩下去的是康庄大道还是泥泞沼泽；黑暗中前行又是快乐的，这样你能更清晰的看到前方的启明星，那里，就是你的方向。

        所有经过的路，都是必经之路。