大厂的供应链采购系统设计
关注我,紧跟本系列专栏文章,咱们下篇再续!
作者简介:魔都技术专家兼架构,多家大厂后端一线研发经验,各大技术社区头部专家博主,编程严选网创始人。具有丰富的引领团队经验,深厚业务架构和解决方案的积累。
负责:
- 中央/分销预订系统性能优化
- 活动&优惠券等营销中台建设
- 交易平台及数据中台等架构和开发设计
目前主攻降低软件复杂性设计、构建高可用系统方向。
参考:
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 发布!