大厂的供应链采购系统设计

关注我，紧跟本系列专栏文章，咱们下篇再续！

作者简介：魔都技术专家兼架构，多家大厂后端一线研发经验，各大技术社区头部专家博主，编程严选网创始人。具有丰富的引领团队经验，深厚业务架构和解决方案的积累。

负责：

• 中央/分销预订系统性能优化
• 活动&优惠券等营销中台建设
• 交易平台及数据中台等架构和开发设计

目前主攻降低软件复杂性设计、构建高可用系统方向。

参考：

• 编程严选网

0 前言

公司发展面临商业环境变化，如流量模式、竞争格局和公共卫生事件。采购系统作为供给端核心系统之一，做好顶层设计并持续进行系统演进，才能适应剧烈的业务变化，服务好最终用户。本文从定义宏观、设计蓝图、落地系统、持续演进展开整个采购系统架构过程，看业务系统架构设计过程。

1 定义宏观

不断聚焦，推演采购系统的底层架构关键点。

1.1 最大的变化和不变

商业定位，确定架构底层逻辑：

• 变化：企业面临商业环境变化及自身发展诉求。企业商业定位面临调整，业务范围可能扩张或收缩，业务模式可能微调或颠覆。架构重心发生极大变化，需提前规划调整，不然系统和业务发展间隙越大
• 不变：商业定位决定公司长期走向，商业定位一旦确立有长期稳定性，以一个明确定位来占领用户心智，同时业务都围绕定位展开

如定位平台模式和品牌模式的电商公司，业务特点和架构特点匹配如下：

1.2 全链路视角：深度协同 &双向驱动

• 商业链条极长，选品，采购溯源，计划下单，合同签署，备料协同，生产制造，品质管控，物流运输，仓储管理，退供翻新，金融结算等环环相扣
• 协同角色极多，从商品开发，采购，计划，品控，关务，财务等密切合作
• 层次错综复杂，从传统的供应链三流：实物流、信息流、资金流和商流，纵横交错

供应链业务和技术是互咬齿轮：

• 前期业务驱动，大量场景需线上化，完成初期流程闭环和数据积累
• 发展一定阶段，大量技术驱动场景，展现数智化特征，如服务供需平衡的销量预测、智能补货，服务库存平衡的采购分仓、仓间调拨

整体供应链采购发展是技术和业务双驱。架构设计过程，要认清当前系统和业务的发展阶段，平衡好当前诉求和未来发展，做好业务支撑同时，挖掘数智化机会，为变化留有余地同时拒绝过渡设计。

1.3 找准系统演进关键特征

以准确性、可用性为基：

理清业务特点后，需圈出采购系统关注的技术特征及这些关键特征的演进目标：

• 可用性。作为履约核心链路，多角色日常工作需频繁操作在线系统，能全天候完整为用户提供服务能力是基础和关键
• 准确性。业务链路长（从计划下单到采购请款结算中间要经多个关键流程），业务完结周期长（短则几天，长则一年多），数据准确有很大挑战。又因采购是关键的成本结算链路，所以对数据准确性有很高要求

需进一步量化这些架构特征，用以观察和保证系统是向目标方向拉动。如关注服务可用性，可用在线率、故障率俩指标。指标构建落地要结合公司技术，若有SLA/SLO/SLI相关服务质量平台，可直接借力，把指标纳入架构观察大盘，而非重复构建。类似也可借力自动化测试平台，构建一些性能、安全性的架构特征的量化观察指标。

2 设计蓝图

确定阶段性目标架构。理清关键底层逻辑后，可开始确定阶段性目标架构蓝图。如RUP 4+1视图，本文谈如下视角

2.1 限界上下图

分治之基、扯皮之盾：

分治，大系统小做。采购系统包含跨境采购、采购执行、退供/翻新等大量业务，同时要和大量外部系统如商品中心、供应商、财务等交互，这种业务场景多，和外部联动多的系统，只有界定好内外部边界，才能将系统和人员职责拆分到位。

系统的服务化粒度可直接映射参考内部子域划分。如系统大小合适，系统负责人和系统之间一对一配比最好。

2.2 业务架构图

业务场景和系统能力平滑匹配：

业务架构图要将业务、系统思考清，图要明确横向和纵向的意图。

① 横向：表达业务流程

• 利益相关者：可通过用户利益关注点不同做用户群体划分，可通过角色来抽象划分后的用户
• 横向业务闭环：业务最终必定服务用户，所有利益相关者的关注点应该在每个横向层次上得到承载和体现

② 纵向：表达能力分层

• 纵向关注拆解，从“业务愿景”不断拆解到一个个细小的‘业务能力’载体
• 分层，对拆解过程进行抽象，归纳，提炼 4 层表达结构：场景层、产品功能层、系统能力层、业务模型层

场景分析是关键。业务架构产出靠不靠谱，其中一个因素就是业务域下的作为输入场景是否考虑清晰，是否覆盖全面，即‘场景分析’是否到位。该层是基础，至于分层业务架构产出，如L0，L1，L2层可在该基础做抽象和结构化。

3 落地系统

有层次，有节奏的构建系统：

3.1 一层：横向扩张

以域为核心，打造系统版图：

搭建业务和系统大的框架结构，做业务域级别的覆盖和服务系统级别的落地。供应链采购作为相对成熟的业务，可参考业务侧整体版图来预判系统形态。

然后结合当前系统和业务现状，规划系统发展路径。若新需求不在当前子域，可考虑将新的系统直接构建出来，承接这块业务需求，以满足未来发展。若有板块内的关键子域落入其他板块，可边界治理，划回业务和系统能力，划出不属于采购系统的，以保证规划整体性和系统内聚。

3.2 二层：垂直深挖

精细化场景覆盖：

多角度验证场景完整性，做场景级业务覆盖和系统能力级别的补全。业务域初步搭建成型后，在支撑基本业务流程基础上，不断挖掘用户在成本控制、提效、体验的深度诉求，迭代细分场景以丰富系统。如审批域：

• 可提供专门服务紧急场景的紧急审批能力，除了几个关键节点审批，其他日常审批节点都绕过，极速完成审批
• 也可根据便携化审批诉求，提供移动审批

3.3 三层：自动化 &数智化

当前的终极阶段，需长期思考探索。在精细化做了段时间后，系统有一定成熟度基础，团队也对业务有深入理解，可挖掘自动化&数智化机会。

如探索个性化流程场景：为不同业务方个体搭建个性化采购流程。关键思路，采购是重流程系统，而有些流程节点的设计是在风险控制和效率间博弈，如某些审批节点。而每个业务人员个体靠谱度不同，若能为某些靠谱业务人员跳过某些主要基于风险控制考量的节点，极大提升流程效率。

4 持续演进：动态平衡

目标架构，只是某时间对架构的理想状态的判断，当一些关键因素变化，目标架构需及时调整，而变化是持续的，所以目标架构其实也是连续变化的。当目标架构变化后，会开启新一轮定义、设计和落地，所以系统能力和需求的匹配一直处于一个动态平衡中。如双十一说明市场环境变化导致业务变化，而业务变化后系统侧需要做出调整：

• 市场变化：本年双十一销售高峰除当天，还有‘11.1-11.3’，形成 2 个销售波峰，波峰之间有 7 天缓冲

• 业务变化：对采购侧业务方，这市场变化，多‘一次复盘，一次补货’

  • 一次复盘：‘11.1-11.3’大促后，可快速复盘下当前采购量和目标偏差，调整关键数据如大促系数（大促期间对比平销期采购量倍数）
  • 一次补货：复盘后发现一些采购量偏差、一些爆品缺货风险

• 系统变化：一波大促变两波，对流量、系统容量需重新评估设计。可提供一些数据辅助决策工具帮助业务快速‘11.1-11.3’复盘，和‘11.11’采购量重新预测。最后提供紧急补货工具，缩短采购履约时间，完成偏差采购量补货

5 总结

供应链这种B端系统门槛高，对架构师业务深度、技术深度提出双向要求，埋头做系统可不行。将业务敏感度和架构方法论结合，用发展动态眼光看，才能发现真正技术价值和业务价值。

本文由博客一文多发平台 OpenWrite 发布！