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

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

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

负责:

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

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

参考:

0 前言

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

1 定义宏观

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

1.1 最大的变化和不变

商业定位,确定架构底层逻辑:

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

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

业务特点 架构特点
平台模式(如:天猫) 撮合大量商家和消费者,关注交易量,关注GMV。入驻品牌多,品类广,更关注商品交易属性,基本不关注生产制造 起量快,得确保系统设计易扩展,无论表拆分、机器扩容。营销玩法多变,为快速响应业务,需灵活前台设计和坚实中后台
品牌模式(如:严选) 关注忠诚用户,关注利润率,以品为核,从设计制造环节抓起,到商品交付给用户,乃至售后都兼顾。但品类数量增长慢,资产重 需向多渠道铺货,业务前端要匹配各平台玩法。业务后端从商品企划到设计、生产、制造、运输、仓储的链条极长,流程联动,数据准确性保障都要考虑。为匹配业务前端,往往要做渠道库存、渠道订单这样的抽象设计

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 发布!

热门相关:盛宠之嫡女医妃   玉堂金闺   龙组使命   影帝偏要住我家   玉堂金闺