两种架构方式，两种基因碰撞！-上糖网

两种架构方式，两种基因碰撞！

Apr 8, 2019 8:09:32 AM

来源：上糖网研究院

2394 人参与 0评论

在供应链管理中，没有任何一个模块是可以抛开其它部分而独立存在的！

然而,在架构供应链系统产品的时候，我们的惯性思维却是将供应链拆解为计划、采购、库存、财务、网络、履约等一个个独立的模块。我们花费了大量的时间在这些独立的模块上进行深耕，并且将这些模块进一步拆解为更细小的模块来规划和设计，却往往忽略了厘清这些模块之间的关系是我们做产品系统规划时首先应当关注的重点！

例如计划系统，我们将其拆解为销售计划、生产计划、采购计划、补货计划、调拨计划、仓配计划、S&OP、CPFR……这些系统之间是什么关系？更进一步，它们和营销计划、品类规划、目标管理、财务计划、库存管理、网络优化……是什么关系？甚至，它和供应链金融产品、渠道销售系统、门店POS系统之间又是什么关系？

类似的，库存、财务、物流、定价、生产……无论哪个系统，都存在着类似的特点。

这也是供应链管理的魅力所在！这种端到端的、全链路的特性在带给供应链无穷无尽的复杂性的同时，也带给了我们巨大的想象空间和创造空间！

我们知道，在架构系统产品的时候，通常有两种典型逻辑。一种是顶层架构（top-down），另一种是底层架构（bottom-up）。这是两种不同的思维方式，前者的典型代表是集中式架构方式，而后者的典型代表是分布式架构方式。

在互联网公司里，尤其是以平台为主要模式的互联网公司里，分布式架构是一种与生俱来的基因和思考方式。它的优势是将风险和算力分散到了海量的资源中，解决了高并发的问题。分布式的架构还给我们带来了创新，因为不存在唯一的所谓的“主机”，它使得所有的产品和人，都可以独立地、创造性地进行工作，并将创新的成果分享到平台上。

然而，在架构供应链产品的时候，我们却不得不遵循另一种思维方式，即顶层架构的思维方式。它要求我们首先要具备从上至下的完整性思考能力，无论是从业务战略角度出发也好，还是从产品架构角度出发，我们都需要在脑海中构建出一个整体的、端到端的、完整的供应链大闭环。

为什么底层架构方式不太适用？试想，当我们将视野局限在一个个细小的子模块的构建的时候，我们的发散性思维，以及供应链的端到端的特性仍然会迫使我们将这个子模块的边界不断向外扩张。这种扩张是无法避免的，因为供应链与生俱来就是端到端的，它会牵引我们向外扩张。扩张的结果就是与其它子模块产生交叉，此时此刻重复建设就难以避免了。这种低效率的、不创造价值的重复建设对于供应链架构师来说就是灾难！

当然，任何事物都不是绝对的！供应链需要顶层架构，但顶层架构也存在着一定的弊端，例如：创新性的丢失、资源的集中占用等。

因此，当互联网式的底层架构、分布式架构的基因和供应链的顶层架构、集中式架构的基因相互碰撞的时候，会不会产生出新的方法论来，这是一个十分有趣的话题！

至少在笔者看来，我们可以尝试通过“两步法架构”来融合两种基因。

第一步仍然是顶层集中式架构。这是由供应链的端到端的特性所决定的，只有顶层架构才能解决低效重复建设、边界不清晰的问题。

第二步则是底层创新性架构。当顶层架构确定了大的框架，确定了各个模块之间的关联关系，构建了供应链的完整闭环后，我们要能够允许在这个基础之上的底层创新，要容许这个框架对于不同业务的兼容性，甚至要允许业务和产品在这个顶层框架中独立地进行开发和迭代。

“两步法架构”既保持了供应链顶层架构的完整性，也兼容了供应链底层架构的创新性。在这个过程中，把握好“火候”特别重要：顶层架构的颗粒度越细，留给底层架构的创新空间就越少；顶层架构的颗粒度太粗，又不可避免地产生过多的重复建设。这从某种程度上依赖于企业的文化，也考验供应链架构师的智慧。文化上，鼓励创新的企业会倾向于留给底层创新更多的空间，而传统企业则恰恰相反。

供应链的产品架构是严谨的科学，也是优雅的艺术。不存在完美无缺的顶层架构，更不能放纵底层架构的信马由缰！我们应当学会和适应如何戴着镣铐翩翩起舞！