从严选供应链采购看业务系统架构

1. 前言

严选在发展过程中，不断面临着商业环境的变化，如流量模式、竞争格局，也会遇到突然的公共卫生事件-疫情。采购系统作为严选供给端的核心系统之一，做好顶层设计并持续进行系统演进，才能适应剧烈的业务变化，服务好最终用户。本文从定义宏观、设计蓝图、落地系统、持续演进四个点展开整个采购系统架构过程，希望跟大家一起找找做业务系统架构设计的感觉。

2. 定义宏观：捕捉底层“稳定逻辑“

从企业级的商业定位、到供给端的供应链业务特点、再到技术侧的系统架构特征，不断聚焦，推演采购系统的底层架构关键点。

2.1 最大的变化和不变：商业定位，确定架构底层逻辑

从变化来说，企业不可避免的要面临商业环境的变化，以及自身发展的诉求。这时候企业商业定位面临着调整，业务范围可能扩张或者收缩，业务模式可能微调或者颠覆。这时候架构的重心发生极大变化，需要提前做出规划和调整，不然系统和业务发展的间隙越来越大。

从不变来说，商业定位决定了公司的长期走向，一般商业定位一旦确立是有比较长期稳定性的，以一个明确的定位来占领用户心智，同时业务都围绕定位展开。比如：定位是平台模式和品牌模式的电商公司，其业务特点和架构特点匹配大致情况如下：

2.2 全链路拉起来看特点：深度协同 &双向驱动

供应链采购作为整个严选电商业务的后端，有以下特点：

• 商业链条极长，商品选品，采购溯源，计划下单，合同签署，备料协同，生产制造，品质管控，物流运输，仓储管理，退供翻新，金融结算等环环相扣。

• 协同角色极多，从商品开发，采购，计划，品控，关务，财务等密切合作。

• 层次错综复杂，从传统的供应链三流：实物流、信息流、资金流，加上现在频频提及的商流，流和流之间纵横交错。

严选供应链业务和技术作为互相咬合的齿轮，前期主要是业务驱动，大量场景需要实现线上化，完成初期的流程闭环和数据积累。发展到一定的阶段，就会出现大量技术驱动的场景，逐渐展现出数智化的特征，比如：服务供需平衡的销量预测、智能补货，服务库存平衡的采购分仓、仓间调拨。整体供应链采购的发展呈现出技术和业务双驱的特征。所以架构设计的过程中，要认清当前系统和业务的发展阶段，平衡好当前诉求和未来发展，做好业务支撑的同时，积极挖掘数智化场景的机会点，为变化留有余地同时拒绝过渡设计。

2.3 找准系统演进关键特征：以准确性、可用性为基

理清业务的特点后，需要圈出采购系统关注的技术特征，以及这些关键特征的演进目标。这里说下其中两点：

• 可用性。作为履约核心链路，多角色日常工作需要频繁操作的在线系统，能全天候完整的为用户提供服务能力是基础也是关键。

• 准确性。因为业务链路长（从计划下单到采购请款结算中间要经过十多个关键流程），业务完结周期长（短的几天，长的达一年以上）等，这些特征对数据的准确造成很大挑战。又由于采购是关键的成本结算链路，所以对数据的准确性有很高的要求。

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

3. 设计蓝图：确定阶段性目标架构

当我们理清关键底层逻辑后，可以开始确定我们的阶段性目标架构蓝图。架构的视角很多，描述的方法也很多，比如经典的 RUP 4+1 视图。这里仅从限界上下图、业务架构图两个视角展开。

3.1 限界上下图：分治之基、扯皮之盾

分治，大系统小做。采购系统包含跨境采购、采购执行、退供/翻新等大量业务，同时要和大量的外部系统如商品中心、供应商、财务等打交道，在这种业务场景极多，和外部联动极多的系统，只有清晰的界定好内外部边界，才能将系统和人员职责拆分到位。系统的服务化粒度可以直接映射参考内部子域的划分。如果系统大小合适，系统负责人和系统之间一对一的配比是比较好的方式。

3.2 业务架构图：业务场景和系统能力平滑匹配

画业务架构图要将业务和系统尽量思考清楚，就图本身要明确横向和纵向要表达什么。

横向：表达业务流程

• 利益相关者：可以通过用户的利益关注点不同做用户群体的划分，往往可以通过角色来抽象划分后的用户。

• 横向业务闭环：业务最终一定是服务于用户的，所有利益相关者的关注点应该在每个横向层次上得到承载和体现。 

纵向：表达能力分层

• 纵向关注拆解，从“业务愿景“不断的拆解到一个个细小的‘业务能力’载体。

• 分层，对拆解过程进行抽象，归纳，提炼出 4 层表达结构：场景层、产品功能层、系统能力层、业务模型层。

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

4. 落地系统：有层次，有节奏的构建系统

4.1 一楼，横向扩张：以域为核心，打造系统版图

搭建业务和系统大的框架结构，做业务域级别的覆盖和服务系统级别的落地。供应链采购作为相对成熟的业务，可以参考业界的业务侧整体版图对系统的形态做个预判。然后结合当前系统和业务现状，规划系统发展路径。如果来的新需求不在当前子域内，可以考虑将新的系统直接构建出来，承接这块的业务需求，以满足未来发展。如果有板块内的关键子域落到其他的板块里，可以通过边界治理的方法，将业务和系统能力划回来，同时不属于采购系统的也坚决划出，以保证规划的整体性和系统内聚。

4.2 二楼，垂直深挖：精细化场景覆盖

多角度验证场景完整性，做场景级别的业务覆盖和系统能力级别的补全。当业务域初步搭建成型后，在能支撑用户完成基本的业务流程的基础上，不断挖掘用户在成本控制、提效、体验上的深度诉求，迭代细分场景丰满系统能力。比如审批域，可以提供专门服务于紧急场景的紧急审批能力，除了几个关键节点的审批，其他日常审批节点都绕过，极短时间完成审批；也可以根据用户的便携化审批的诉求，提供移动审批能力。

4.3 三楼，自动化 &数智化

自动化 &数智化是当前的终极阶段，这块需要长期的思考和探索。在精细化做了一段时间后，系统具备了一定的成熟度基础，团队也对业务有了比较深入的理解，可以挖掘自动化 &数智化的机会点。比如探索个性化流程场景：为不同的业务方个体搭建个性化采购流程。其中的关键思路是采购是个流程性很重的系统，而有些流程节点的设计其实是在风险控制和效率之间博弈，比如某些审批节点。而每个业务人员个体的靠谱程度是不同的，如果能为某些靠谱的业务人员跳过某些主要基于风险控制考量的节点，那么可以极大提升流程效率。

5. 持续演进：动态平衡

目标架构只是某个时间对架构的理想状态做出的判断，当一些关键因素发生变化时，目标架构需要及时调整，而变化是持续的，所以从某种程度上来说目标架构是连续变化的。当目标架构变化后，会开启新一轮的定义、设计、落地过程，所以系统能力和需求的匹配一直处于一个动态平衡中。举个今年（2020 年）双十一的例子说明市场环境变化导致业务变化，而业务变化后系统侧需要做出调整。

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

• 业务变化：对采购侧的业务方来说，这样的市场变化，多了‘一次复盘，一次补货’。一次复盘指的是‘11.1-11.3’大促做完后，可以快速复盘下当前采购量和目标之间的偏差，调整一些关键数据比如大促系数（大促期间对比平销期采购量的倍数）。一次补货指的是，复盘后发现的一些采购量偏差、一些爆品的缺货风险可以抓紧再补货一次。

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

6. 最后

供应链这样的 B 端系统是有很深的门槛的，对架构师的业务深度、技术深度提出了双向要求，埋头做系统往往做不好系统。只有将业务敏感度和架构方法论结合，用发展动态的眼光去看，才会发现真正的技术价值、业务价值的闪光。

作者简介

无峰，网易资深服务端研发工程师，供应链侧一线架构师，负责供应链采购的服务体系建设，聚焦于履约基础流程搭建、履约效率、成本控制等方向的解决方案。

头图：Unsplash

作者：严选技术

原文：https://mp.weixin.qq.com/s/_3QpnN4QramF9sTQ1thuLQ

原文：从严选供应链采购看业务系统架构

来源：严选技术产品团队 - 微信公众号 [ID：YanxuanTechProd]

转载：著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。