4.1.2 供应链系统规划：大而全还是小而美

做系统规划，如同建房子时画设计图，未来交付的是联排别墅还是独家小院，在设计图出来的那一刻基本就定型了，后期要想变更房子的主体结构可谓难上加难。我们在做供应链系统规划时，是选择设计一套大系统囊括所有与供应链相关功能好呢，还是选择将把每个系统功能独立开来好呢？

为了回答这个问题，我们来一次角色扮演，化身为××集团系统规划总顾问，分别为某电商平台规划一套大而全的供应链系统架构，以及一套小而美的系统架构。

（1）大而全的系统设计方案

在大而全的系统设计中，一般是一个大的供应链系统囊括了所有与供应链相关的功能，这个系统，我们可以为它取一个专业的名字，叫作SCM系统，它的系统架构可以分为四层。

第一层是最底层的基础数据层，我们把所有基础数据都放在这一层，为整个供应链业务的开展提供最底层的支撑，因为完整的基础数据是业务良性运转的基础。

第二层是基础数据之上的供应链策略层，所有业务在开展过程中需要用到的策略都在这里实现，通过这些策略驱动业务的多样化发展。例如，采购策略、智能补货策略、送货预约策略、任务调度策略、订单分仓策略等。

第三层是策略之上的供应链的各个功能模块，基于基础数据和策略开展的各项供应链业务，如采购管理、订单履约管理、库存管理、仓储管理、门店管理、配送管理等。

以上三层的结构便能形成一个完整的供应链系统闭环了，我们可以基于此系统开展从采购到存储，再到销售，最终到财务结算的完整业务了。但是自闭环远不足以体现供应链系统的价值，我们设计的供应链系统还能对外开放，将我们的供应链能力对外输出，于是，第四层出现了，这是最顶层设计，我们将供应链的商品、订单、库存等能力与各个销售平台进行对接，用一套供应链系统支撑起企业的销售目标。

我们设计的大而全的供应链系统规划就出来了，如图4-3所示。

（2）小而美的系统设计方案

在小而美的系统设计思路里，我们将供应链业务细分为多个子业务，一般是根据部门职责来划分，如采购部门负责采购，仓储部门负责仓储，配送部门负责配送。然后将相关的功能类聚到一个子系统中，于是供应链便被解耦为一个个独立的子系统，每个子系统负责一个核心业务，有其自己的策略配置，如本书中的基础数据中心、采购管理系统、供应商管理系统、订单履约中心、中央库存系统等。

在小而美的系统架构中，每个系统独立运行，通过接口或服务与其他系统交互，如所有系统都需要基础数据，而其所需要的基础数据均从基础数据中心中获取。中央库存集中所有仓库和门店的库存，为其他各系统提供库存服务，所有仓库和门店的库存变化，均需要在中央库存系统中有所显现。我们为之产出的系统规划，如图4-4所示。

在图 4-4 中，有必要重点说明一下平台交互层和仓配交互层这两个子系统，它们属于内部流转型系统，在业务开展过程中基本感知不到它们的存在，但在复杂的供应链形态下，它们又是如此重要。正是有了它们的存在，才能实现供应链的中台化和服务化。

① 平台交互层。如果我们的供应链系统需要对接多个销售平台，势必会存在多个销售平台之间的数据、规则不同的情况，如何将不同平台中的数据按照供应链体系的标准进行统一转换，以及按照统一的标准传送数据，这便是平台交互层的职责，它将差异化的外围数据和业务在这一层进行标准化，为供应链内部系统提供更为稳定的环境。

例如，我们的供应链系统对接了三个销售平台，三个平台上的同一商品的商品编码分别是A+、A++、A+++。而供应链系统内部的标准编码是A。这时用户在销售平台1下单了，下单的商品编码为A+，但是我们的供应链系统里只有A，没有A+，想要正常发货，就必须将A+转变为A，才能将订单流转到仓储管理系统中。同理，发货完成以后，相关人员需要告知销售平台1，A商品已发货，需同步库存，但销售平台1中只有商品A+，我们需要将A再转换为A+回传。这个转换的工作，便是平台交互层的职责所在，如图4-5所示。

② 仓配交互层。如果我们的下游有很多个不同类型的仓储或配送中心，刚好在不同的仓储和配送中心中又部署的是不同的仓储管理系统，假如没有仓配交互层，那么上游的每个业务系统都需要与下游所有的仓储管理系统和配送管理系统针对所有有关联的业务进行对接，n 个业务系统+仓配系统+n 个业务，对接次数便是 n³，如果企业后续又开了新仓，或者调整了仓配业务，系统对接的工作量会让程序员怀疑人生。所以，仓配交互层存在的目的就是让上游业务侧的对接难度降低，它的职责是按标准出入库方式与各个不同的仓配系统进行业务对接，并将标准化接口提供给上游的各个业务系统进行对接，这样，上游业务系统只要与仓配交互层对接即可完成数据的传送，下游仓配业务的调整也只需要在这一层完成同步，尽量降低对上游业务系统的影响，如图4-6所示。

以上系统顾问的工作完成了，我们来对比一下大而全的系统规划思路（以下简称方案一）和小而美的系统规划思路（以下简称方案二）。

首先，从系统实现的难易程度来看，方案一是基于底层数据进行开发，各功能之间共用一套代码功能，读写一套数据库；而方案二是需要为每个子系统都部署一套数据库和一个工程，而系统和系统之间的交互需要通过接口进行。所以方案二比方案一在实现方面要更难，整体耗费的人力、财力和时间成本会更高。由于方案二可以拆解为多个系统，每个系统的难度都会大幅降低，所以可以并行开发，也可以分期迭代，这一点是方案一无法比拟的。图4-7展示了二者在系统部署方式方面的区别。

其次，从性能上看，当数据量较大时，由于方案一只有一套数据库，多个业务只能共用一套数据库，其性能会大幅下降，而方案二是多个系统分布式部署，各个业务相对独立，其性能较良好。

再次，从事故风险来看，如果出现了事故，则方案一基本上全局受挫，一损俱损，而方案二只会影响某一个系统，其他系统还可以独立运行。

最后，从扩展性上来看，方案一将所有功能都融到一起了，耦合性更高，但开发更快。方案二更加灵活，扩展性更好，但系统功能调整往往会涉及多个系统，开发周期会长很多。

总结下来，二者的优劣如表4-2所示。

现在，回到开始的那个问题上，在进行系统规划时，到底是选择大而全的系统，还是选择小而美的系统？相信每个人的答案都不一样，因为这个问题也是没有标准答案的，两个方案各有利弊，存在即合理，并没有谁更好、谁更坏。我们每个人都要结合公司当前的现状、业务形态、资源投入和未来的规划等因素，综合评估以后得出最终结论，这个结论不一定是最好的，但一定是最合适的。在系统规划方面，如果决策失误了，可能会给日后埋下巨大的隐患，不信请看下面这个故事。

一次惨痛的系统规划决策教训

K 公司最近融资到位，老板决定大力发展医药电商新零售业务，自建供应链体系，计划在全国各地开5个大型仓库和100家线下门店，仓库用以承接线上订单，门店用作线下销售和新零售到店服务订单的承接，实现线上、线下完美结合的目标。决策做出以后，公司各部门迅速响应，落实到人，产品部小Q被委以重任，承担了重构供应链体系的重要任务。

为什么要重构呢？因为此前公司只购买了一套ERP系统，各业务部门、仓库、线下门店都在这个系统中进行操作，一旦遇到大促等活动，数据量急剧上升，数据库满负荷，系统就卡得不行，很明显，这样的系统支持当前业务已属不易，更别提支持全国五仓和百家门店了；再加上新零售需要线上线下打通，没有源代码的ERP系统根本不具备扩展能力，所以系统重构势在必行。

如何进行系统重构呢？摆在小Q面前有两个方案：方案一，基于现有的生产研发能力，按照新零售的业务形态梳理出系统方案，再结合ERP系统中和业务相关的采购、订单、仓储能力打造一个完整的供应链SCM系统（大而全的方案）；方案二，按照互联网常用的SOA系统架构，将供应链系统拆分为多个独立的子系统，交由不同的小团队来实现（小而美的方案）。经评估，方案一的开发工作量更小，人力投入更少，更符合公司当前的现状；方案二的扩展性更好，更符合公司的未来规划，但投入会更多。

两个方案各有千秋，小Q也无法定夺，毕竟这一次重构至少会影响公司未来5年的系统架构，于是小Q找了个机会向CTO和各位技术leader汇报，大家听完汇报以后各执己见，无法达成共识，有些人认为要考虑成本和现状，应该采用方案一，而有些人则认为要放眼未来，应该采用方案二。

CTO在一旁默不作声，沉思了两分钟后，说了一段一锤定音的话：“以我们现阶段的情况来看，确实是方案一最适合。但我们是否要按方案一执行？NO。两个原因：①老板的预期是明年6月份业务达到日均10万单，还有不到半年的时间了，试问方案一如何承接？②医药互联网行业风口已来，万亿级的市场一旦打开，订单量就会呈指数级增长，到时候我们哪里还有精力再重构系统呢？所以不如一步到位，按方案二执行，小步快跑。”

CTO拍板了，于是小Q按照方案二将新供应链体系拆解为10多个子系统，其中基础数据中心、仓储管理系统、订单履约中心、中央库存系统、配送管理系统等 5 个系统在两个月以后如期上线，开始接受业务的洗礼，大家都期待着半年后的日均10万单。

如CTO所述，新业务刚开始时一切向好，系统也越来越完善，大家的信心越来越足，技术部从30人迅速扩充到了160人。然而老板终究是错估了市场形势，在烧了不少钱以后，订单一直在日均5000单上下徘徊，公司严重入不敷出。迫于无奈，公司在一年以后做了两个决定：①裁员，技术部被裁得只剩下50人，以最小规模支持业务运转；②寻求业务转型。

这两个决定直接将K公司的系统体系打向低谷，50人维护原本160人维护的系统，基本只能保证日常运营和小需求迭代，任何需要优化多个系统的大需求，都只能放弃，而恰恰公司业务转型，又不得不对现有系统进行大调整。整个公司每每遇到系统需求改动，员工总是哀声连连。

就这样，当初设计的这一套完整的供应链体系，反而成了公司业务开展最大的阻碍，小Q眼看公司一天天衰落，却也爱莫能助，只能黯然离职。