对于资源整合，从长远看对于公司肯定是利大于弊；但从当前看，这样规划无边界的整合，也着实会让公司大伤元气一把。

公司医药电商发展了好些年，随着业务线的增加和订单量的增长，发现我们的后台（之前很多的功能都是在ERP系统来实现的）现在已经不足以支撑业务的发展需要；因此在今年的三月份我们开始了一次系统大整合。

公司之前是B2C+O2O，但是由于之前是不同的公司负责，各自做了一套系统；今年突然说要将业务线进行整合，所有的产品都有了大干一场的劲头，也曾经一如既往的想要将后台系统整合的同时，支撑公司所有的业务线；然而2个月的实践给了我们所有人一个警醒；也让大家意识到这样大整合的弊端。

现在将这些坑总结出来，也算是对自己这段期间做产品的几点心得吧：

1.  忌调研不充分

在规划的过程中，由于大家分组进行，虽然对公司业务线已经有一定的了解，但是相关产品人员并未坐在一起充分沟通，将现有的系统架构做一次全面深入的分析，靠着经验和拍脑袋各自一组规划所负责的系统，未能将系统数据流程做明确的二次分析与处理。

当时我们是按系统划分，两三个人一组负责一个系统；大家开始只是针对自己负责的系统做功能模块的划分和功能流程梳理；而并为真正的将业务流程先做整体的串联，都会牵涉到哪些部门，哪些部门能够合并减少不必要的重复性工作；导致商品系统规划完成后评审时很多业务线未考虑到；增加了研发人员的怀疑感，推进过程中也并无前期所想的理想。

2. 忌无厘头的开始进行

由于要考虑所有的业务线场景，导致很多的异常情况都需要考虑衡量，导致每个系统的功能点，流程都很庞大；如：

（1）商品系统因为要支撑所有的业务线，但是每个业务线的商品放在同一系统，导致开始画原型时有遗漏，评审后开发过程中，研发未完全按产品原型开发，最终导致开发完成后研发产品返工，项目工期延长；

商品系统规划时未画出一条主线，业务线流程未考虑全，虽然将自身的功能点整理了出来，但是因为未考虑代运营商品，无法进行订单区分；以至于后期订单系统项目实施过程中无法拆分订单

套餐的取舍；由于在三方商家平台开店，公司内部的套餐其实是以商品的形式在平台上售卖；后期再进行套餐拆分，由于是一个新同事负责，不了解业务，导致当时将套餐功能直接被放到营销系统，拆分时多个接口的调用；系统性能上很是费劲。

（2）物流系统，库存系统的滞后，促销系统和商品系统存在着同样的业务场景和ERP，老商品系统数据同步问题，导致整个中台项目依附性很强的系统（如：订单系统）最终研发要考虑很多系统数据问题，测试也只能是测试功能点，流程出现脱节；

由于O2O业务线与B2C业务线的不同，在库存与物流系统的整合过程中，未将两条业务线相似的地方进行合并，两边的库存概念的不统一，导致规划项目延期；

（3）订单系统虽然考虑分两期做，一期本身只是计划将ERP中的一些不牵涉到大逻辑的功能整合归属到订单系统，二期完成拆分订单，异常订单等的处理；但是由于一些基础系统的未按时实施（如：物流系统，促销系统，商品系统），这个项目相对也是滞后的；

（4）ERP线上线下系统整合，由于本身不是用一套系统，订单处理上也是有一定的不同。本身是计划当中台的一套系统完全能够支撑业务后再做整合；但是由于很多原因，未有一个清晰明了的规划，ERP系统和上游的供应商系统还有对接，产品人员对ERP系统存在黑匣子；又要在很短的时间出具方案，主力产品的离职，最终导致这个项目也最终被搁置。

3.  忌半途而废

在很短的时间段内想要将这样大而全的整合一股脑全部整合完成，可能领导们意识到这些大整合的弊端，告知要优先级放低，先处理业务所积压的一系列需求，压力，迷茫等等因素最终还是导致不少主力产品，研发相继离职，这个项目也就这样被一拖再拖。

4.  忌拆东墙补西墙

由于要看到成效，可能是意识后台的成效不容易被看到，又开始着力前台，改版，优化；最终一个月重新更新一版；但最终还是换汤未换药，并未解决现有业务后台的功能缺失和优化。虽然服务时效上也有了一定的提升，但从长远来看，想要更好支撑业务，后台系统的整合和优化必不可少，也和C端产品一样至关重要。

最后

对于资源整合，从长远看对于公司肯定是利大于弊；但从当前看，这样规划无边界的整合，也着实会让公司大伤元气一把。而产品也一样，虽然项目进行的过程中踩过无数的坑，也着实让我们这一批参加项目的人更加的了解公司业务，流程，系统及其功能，自身产品思考能力也有了提高；所以说不管成功与否，都应该感谢这段时间，有过肯定，有过希望，也有过踩过坑的失望。

作者：简之箐，微信公众号：简之箐，5年互联网产品经理，曾担任医药产品经理和电商产品经理，经历主导过电商平台的系统整合规划。

本文由 @简之箐 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Pixabay，基于 CC0 协议