严选供应商系统边界治理实践

1 边界治理在做什么

简单来说：

团队层面，边界治理是明确版块定位并让团队的职责聚焦版块定位。

从产品技术层面，边界治理是规划领域能力并内聚散落在其他版块的领域能力。

2 为什么要做边界治理

2.1 历史背景

2017-2020年初，因为历史原因，供应商系统及关联版块业务架构如上。从目前的视角看来：

一方面，【供应商版块】承担了许多非供应商领域的职责，包括外仓相关，采购履约相关，售后相关等等。

上述边界状态为供应商团队和相关的其他团队带来了以下痛点：

2.2 降低研发效能

边界问题由于自身携带领域能力分散这个自然属性，进而给研发团队带来了一系列强感知的研发效能痛点，包括：

评估难：逻辑分散带来了完整性的挑战，依赖其他团队评估结果又要面临效率问题。

排期难：跨团队排期需要解决优先级匹配以及研发节奏同步。

改动难：核心难点在于烟囱式建设带来的领域逻辑一致性的问题，特定情况下需要先解决历史逻辑不一致的问题，才能开始后续工作。

测试难：测试往往需要进行跨系统造数，有一定的跨系统熟悉成本。

2.3 缺少整体性规划

严选的货品一部分放置在内仓（严选负责的仓库），一部分在外仓（供应商负责的仓库）。在边界治理前，内仓和外仓的产品化建设分别归属于【仓配版块】和【供应商版块】，这导致仓配域无法进行整体性规划，曾产生的现象包括：

外仓相比于内仓，产品上缺少库存管理功能。

外仓相比于内仓，技术上采用的物流轨迹查询方案比较滞后，其的一些物流轨迹停滞问题。

……

上述现象均产生了一定影响，包括：

外仓每年会因为线下手动管理库存，导致外仓次品数量统计出错。

外仓平均每月会有一些物流轨迹停滞问题。

在边界治理前，【供应商版块】未明确自身定位，导致在与版块相关的核心领域方面的建设比较缺失。

3 如何做边界治理

边界问题的治理依次分三步，表达边界、识别边界问题、解决边界问题。其中表达边界旨在明确边界的理想状态，识别边界问题指引我们现状与理想边界的不匹配点，而解决边界问题即解决消除上述不匹配点。

3.1 表达边界

表达边界核心要解决3个问题：

表达语言：语言的粒度要能足够支撑边界描述的丰富性，同时理解成本低。

统一：边界表达后是要用于沟通的，显然语言要统一。

准出：一方面，所有版块的边界要独立不重合，且整体要完整覆盖超域。另一方面，要解决版块间的职责冲突。因此需要有个准出环节要把控。

在供应商边界治理的实践过程中，通过严选业务架构解决表达语言&统一的问题，通过架构组准出环节来解决准出的问题。

业务架构有5个元素，包括用户、问题域、业务场景、产品、能力等。可以简单理解xx版块，为谁解决什么问题，涉及哪些场景，用哪些功能，这些功能有哪些共性。

下述为供应商版块的准出架构的简要介绍（为了方便理解进行一些缩减）：

供应商版块核心用户：供应商、采购

场景&产品&能力设计如下：

3.2 识别边界问题

边界问题可以简单理解组织、领域、系统的职责处于一种不合理的形态，与理想中的完美设计存在差距。那么我们具体做的就是为不匹配的部分找到与之匹配的版块。

匹配过程可以根据版块面向的问题域做自上而下的问题域契合度匹配，也可以如下述案例直接进行能力匹配。

下图为【供应商版块】【采购版块】的边界问题识别过程，如图所示【供应商版块】中提到的签署、生产排期、入库等领域，存在于【采购版块】的业务准出架构中，那么这几部分便涉及了边界问题。

3.3 解决边界问题

边界问题解决的过程会面临一些落地难点，包括项目管理和技术方案的设计和实施，前者关系到项目能否顺利启动，后者关系到治理前后的稳定性。后续会对难点进行简单的分析以及提供一些实践过的策略。

3.3.1 三大特点

边界问题解决的难点，来源三大特点：

偏产技驱动

跨版块技术重构：能力迁移涉及代码迁移以及相关的内外部依赖改造。

迁入方学习成本高：迁入方要学习业务、产品、技术等等系列细节，包括历史业务产品规则和代码本身，尤其在文档缺失的情况下。

名词约定：职责从A换成B，A为迁出方，B为迁入方

3.3.2 三大难点

价值共识：偏产技驱动的需求，往往在与业务、PMO等角色就价值共识的达成商，会有一定的难点，因为他们无法直观感受到痛点与收益。

研发资源空闲度匹配 ：跨版块的协同，需要保障研发资源在时间上的空限度匹配，尤其在迁入方面临高学习成本时，加剧了对空闲研发资源的要求。

稳定性保障：能力迁移涉及代码迁移以及相关的内外部依赖改造（包括DB、MPS等等基建依赖），改动范围的完整性、改动正确性、生产环境依赖切换的平滑性等方面，均对系统稳定性有巨大影响。而且随着工程量提升到一定程度，难度会指数级提高。例如【供应商版块】【采购版块】的能力迁移，单后端涉及10w+代码，60+张表，150+接口，单纯生产环境切换后的接口验证，就需要耗费大量工作。

3.3.3 三大策略

针对上述三个难点，分别对应有3个策略：

业务导向

价值共识可以从与业务相关的研发效能收益上去对齐，进而不外乎减少维护成本、减少扩展成本、提高稳定性等几个维度。在边界治理中，上述维度可以因能力分散逻辑割裂直观化为以下几个易于业务理解的收益点：

提高需求分析效率：逻辑割裂会提高分析完整性的成本，进而导致业务产品研发等职能的分析低效性；

加快业务响应：只要涉及外部联动，那么即使是半天的改动量，也会因为优先级不一致而导致交付周期延长xx周，经历过的都知道痛（要不是不懂，好想直接进依赖方的代码库敲代码）；

减少学习成本：能力分散的情况下，概念重复的问题会难以避免，进而引入重复学习的问题（尤其涉及指标时，重复学习的成本更高）。

上述是定性收益分析，如果还需要定量收益分析的话，可以通过频率*单次收益来对未来的一段时间做预测，关于频率和收益的相关建议如下：

频率：可以通过相关领域是否有重点业务项目来进行简单的推算，一方面重点业务项目本身蕴含着迭代和运维收益，另一方面，相关领域在重点业务项目之后会伴随一定的高频迭代。

收益：对相关类型问题耗时提前做好耗时的采集，进而后续支持分析和推算，这是比较容易被忽视的，同时也较难进行弥补的。

前瞻性&精细治理

可以让迁入方先接手增量迭代运维任务，然后再接手历史存在的功能。

可以先交接产品职责，再交接技术职责（包括扩展与维护）。

迁入方可以先在迁出方的代码库里进行代码开发，再择机进行能力迁移（包括代码迁移和DB库迁移）。

在【供应商版块】【采购版块】长达1年半的边界治理中，就是按照上述方式进行。一方面，在2020年中，2021年初，2021年中等3个时间节点，与采购团队对齐了治理节奏并预留了资源。另一方面：

采购团队先负责新增需求，后熟悉存量需求。

采购团队先进行产品交接，再进行技术交接。

采购团队于2020.h2接手运维，2021 全年分两次进行能力迁移。

复杂度降解

上述难点分析阐述了稳定性保障的复杂点来自于保障改动范围的完整性、改动的正确性，生产环境依赖切换的平滑性等方面，那么可以通过以下几个方式来减少相关复杂度：

确保改动完整性

可以基于数据流进行改动逻辑梳理盘点。在技术层面实操时，可以通过DAO层代码从底下上梳理链路。

进行数据迁移时，不要忘了与数仓对齐相关数据源的改动。

后置非必要的改动

减少外部依赖改造：对于迁出方提供给外部的api，暂时由迁出方作为迁入方的反向代理，进而减少外部依赖的改造。后续择机进行外部依赖的改造。

减少不必要的模型升级：很多时候会想借助能力迁移，对迁入的模型进行升级和整合，但这必然增加改造和验证复杂度，如果不是必须项，可以后续择机升级。

天下没有免费的午餐，上述策略的代价是额外的时间和研发资源，实操时可根据容错性进行选择使用。例如在核心资损链路，稳定性是第一准则，那么就可以采用该方式。

前置验证数据清洗逻辑

进行数据迁移时，有时需要通过数据清洗来解决数据异构等等问题。而数据清洗逻辑的测试往往会因测试数据封不够丰富、测试数据量太少、线上脏数据等因素导致测试不全面，该不确定性会增加线上实施的风险。针对此问题，可以提前基于生产环境数据来验证清洗逻辑的正确性。

除此之外，如何应对发布及切换过程中的流量、回滚策略的设计与实施等等也是难点，在此不深入探究。

4 成果

边界治理部分成果如下：

提高领域规划完整性：通过【供应商版块】【仓配版块】的边界治理，不仅解决了背景中提到的问题，【仓配版块】还在后续绘制了外仓建设蓝图。

聚焦团队目标：供应商团队完成版块定位，并且后续专注于版块核心领域的建设。

5 小结

在主导供应商版块持续一年半的边界治理过程中，对边界治理的理解也在逐步加深：

除了能力迁移本身外，边界治理的核心和挑战在于认知版块定位，表达版块边界，对齐版块边界等事情。

边界治理绝对不仅是技术的事，这个过程是需要产品与技术紧密协作，脱离产品的边界治理会在实践时更容易遇到边界划分不合理、边界腐化等问题，最终使得边界治理变成闭门造车或不具有可持续性。

边界治理是个常态化的事情，随着业务、技术、组织与人的认知的不断变化，板块的定义与边界仍然需要不断的演进才能适应业务的发展。

本文旨在对供应商系统边界治理进行了体系化基础性的总结，在细节上不会过于深究，包括业务架构产出和技术重构等等细节。

最后，给大家推荐一个简单好用的供应商管理系统。简道云SRM系统，一步连接，开启千万供应协作。新一代采购数字化解决方案，全方位闭环管理供应商；互联互通，实现采购全流程协同管理；好用易用，无需下载软件，最快1天即可上线应用。