1 邊界治理在做什么

簡單來說(shuo)：

團隊層面，邊界治理是明確版塊定位并讓團隊的職責聚焦版塊定位。

從產品技術層面，邊界治理是規劃領域能力并內聚散落在其他版塊的領域能力。

2 為什么要做邊界治理

2.1 歷史(shi)背(bei)景

2017-2020年初，因為歷史原因，供應商系統及關聯版塊業務架構如上。從目前的視角看來：

一方面，【供應商版塊】承擔了許(xu)多非供應商領域的職(zhi)責，包括外倉相關(guan)，采購(gou)履約相關(guan)，售(shou)后(hou)相關(guan)等等。

上述邊界狀態為供應商團隊和(he)相關的其他團隊帶來(lai)了以下痛(tong)點(dian)：

2.2 降低研發效能

邊界問題由(you)于自身攜帶領(ling)域(yu)能(neng)力(li)分散這個自然屬性，進而給研發(fa)團隊(dui)帶來了一系列強(qiang)感(gan)知的研發(fa)效能(neng)痛(tong)點，包括：

評估難：邏(luo)輯(ji)分散(san)帶來(lai)了(le)完整性的挑(tiao)戰(zhan)，依賴(lai)其他團隊評(ping)估結(jie)果又要(yao)面臨效率問(wen)題。

排期難(nan)：跨團隊排期需(xu)要解決優先級匹配以及(ji)研發節奏同(tong)步。

改(gai)動難：核(he)心難點在于煙囪式(shi)建設(she)帶來的領域邏輯一(yi)致性的問題，特定情況下需(xu)要先(xian)解決(jue)歷史邏輯不一(yi)致的問題，才能(neng)開始后(hou)續工作(zuo)。

測試(shi)難：測試往往需要(yao)進行跨(kua)(kua)系(xi)統(tong)造數，有一定(ding)的(de)跨(kua)(kua)系(xi)統(tong)熟(shu)悉成本。

2.3 缺少整體性規劃

嚴(yan)選的(de)貨(huo)品一(yi)(yi)部(bu)分(fen)放置在(zai)內(nei)倉（嚴(yan)選負責的(de)倉庫），一(yi)(yi)部(bu)分(fen)在(zai)外倉（供應(ying)商負責的(de)倉庫）。在(zai)邊界治理前，內(nei)倉和外倉的(de)產品化(hua)建設分(fen)別(bie)歸屬于【倉配(pei)版(ban)塊(kuai)(kuai)】和【供應(ying)商版(ban)塊(kuai)(kuai)】，這(zhe)導(dao)致倉配(pei)域無法(fa)進(jin)行整體性規劃，曾(ceng)產生的(de)現(xian)象包括：

外倉相(xiang)比(bi)于內(nei)倉，產品上缺少庫存(cun)管理功能。

外倉相比于內倉，技術上采(cai)用的物流(liu)軌(gui)跡查詢方案比較滯(zhi)后，其的一(yi)些物流(liu)軌(gui)跡停(ting)滯(zhi)問題。

……

上述現象(xiang)均產生(sheng)了(le)一定影響，包括：

外倉(cang)每年(nian)會因為線下手(shou)動管理庫存(cun)，導(dao)致外倉(cang)次品(pin)數量統計出(chu)錯。

外(wai)倉(cang)平(ping)均每月(yue)會有一些物流軌跡(ji)停滯問題。

在邊界治理前，【供應商(shang)版塊】未明(ming)確自身定(ding)位，導致(zhi)在與版塊相關的核心領域方面(mian)的建設比較缺失。

3 如何做(zuo)邊界治理

邊界問題的治理依次分三步，表達邊界、識別邊界問題、解決邊界問題。其中表達邊界旨在明確邊界的理想狀態，識別邊界問題指引我們現狀與理想邊界的不匹配點，而解決邊界問題即解決消除上述不匹配點。

3.1 表達邊(bian)界

表達邊(bian)界核心(xin)要解決(jue)3個(ge)問(wen)題：

表達語言：語言的粒(li)度要(yao)能(neng)足(zu)夠支撐邊界描述的豐富性，同時理解成本低。

統一：邊界表達(da)后(hou)是要(yao)用于(yu)溝通的，顯(xian)然語言要(yao)統一(yi)。

準出：一方面，所有版塊(kuai)(kuai)的邊界要(yao)獨立不重合，且整體(ti)要(yao)完整覆(fu)蓋超域。另一方面，要(yao)解(jie)決版塊(kuai)(kuai)間的職責(ze)沖突。因(yin)此(ci)需要(yao)有個準出環(huan)節要(yao)把控(kong)。

在供應商邊界治理的實踐過程中，通過嚴選業務架構解決表達語言&統一的問題，通過架構組準出環節來解決準出的問題。

業務(wu)架構有(you)5個元素，包括用(yong)戶、問題域、業務(wu)場景、產(chan)品、能(neng)(neng)力(li)等。可(ke)以簡(jian)單理解xx版(ban)塊，為誰解決什(shen)么(me)問題，涉及哪些(xie)場景，用(yong)哪些(xie)功能(neng)(neng)，這些(xie)功能(neng)(neng)有(you)哪些(xie)共性。

下述為(wei)供應商版塊的(de)準出(chu)架構的(de)簡要(yao)介紹（為(wei)了方便理解進行一些(xie)縮減）：

供應商版塊核心用戶：供(gong)應商、采購

場景&產品&能力設計如下(xia)：

3.2 識別邊界問題

邊界問題可以簡單理解組織、領域、系統的職責處于一種不合理的形態，與理想中的完美設計存在差距。那么我們具體做的就是為不匹配的部分找到與之匹配的版塊。

匹配過程可以根據版塊面向的問題域做自上而下的問題域契合度匹配，也可以如下述案例直接進行能力匹配。

下(xia)圖為【供應(ying)商(shang)版(ban)(ban)塊】【采購(gou)(gou)版(ban)(ban)塊】的邊(bian)界問題識別過程，如(ru)圖所示【供應(ying)商(shang)版(ban)(ban)塊】中(zhong)(zhong)提(ti)到的簽署(shu)、生產排期(qi)、入(ru)庫等領域，存在于(yu)【采購(gou)(gou)版(ban)(ban)塊】的業(ye)務準出架(jia)構(gou)中(zhong)(zhong)，那么這幾部分便涉及了邊(bian)界問題。

3.3 解決邊界(jie)問(wen)題

邊界問題解決的過程會面臨一些落地難點，包括項目管理和技術方案的設計和實施，前者關系到項目能否順利啟動，后者關系到治理前后的穩定性。后續會對難點進行簡單的分析以及提供一些實踐過的策略。

3.3.1 三大特點

邊界問題解(jie)決的難(nan)點，來源三大特(te)點：

偏產技(ji)驅動(dong)

跨版塊(kuai)技術重構：能(neng)力遷移(yi)涉及代碼(ma)遷移(yi)以及相關的內外部依賴(lai)改造。

遷入方學習成本高(gao)：遷入方(fang)要學(xue)習業(ye)務、產品、技術等等系(xi)列細節，包括歷史(shi)業(ye)務產品規則和代碼本(ben)身，尤其(qi)在文檔缺失的情況下。

名詞(ci)約定：職責從A換成B，A為遷出方，B為遷入方

3.3.2 三大難(nan)點(dian)

價值共(gong)識：偏產技驅動的需(xu)求，往往在與業務、PMO等(deng)角色就價(jia)值共識的達成商，會(hui)有(you)一(yi)定的難點(dian)，因為他們無法直觀感受到(dao)痛點(dian)與收益。

研發(fa)資源空閑(xian)度匹配?：跨版塊的(de)協(xie)同(tong)，需(xu)要保障(zhang)研(yan)發資(zi)源在時間上(shang)的(de)空(kong)限度匹配，尤(you)其在遷(qian)入方面臨(lin)高學習成本時，加劇(ju)了(le)對空(kong)閑研(yan)發資(zi)源的(de)要求。

穩定(ding)性保障：能力遷移涉及代碼遷移以及相關的內外部依賴改造（包括DB、MPS等等基建依賴），改動范圍的完整性、改動正確性、生產環境依賴切換的平滑性等方面，均對系統穩定性有巨大影響。而且隨著工程量提升到一定程度，難度會指數級提高。例如【供應商版塊】【采購版塊】的能力遷移，單后端涉及10w+代碼，60+張表，150+接口，單純生產環境切換后的接口驗證，就需要耗費大量工作。

3.3.3 三(san)大策(ce)略

針對上(shang)述三個難點，分別對應有(you)3個策略：

業務(wu)導向

價值共識可以從與業務相關的研發效能收益上去對齊，進而不外乎減少維護成本、減少擴展成本、提高穩定性等幾個維度。在邊界治理中，上述維度可以因能力分散邏輯割裂直觀化為以下幾個易于業務理解的收益點：

提高需求分(fen)析效率：邏輯割裂會(hui)提高(gao)分(fen)(fen)析完整性(xing)的成本，進而導致業務產品(pin)研發等(deng)職能的分(fen)(fen)析低效(xiao)性(xing)；

加快業務(wu)響(xiang)應：只要涉及外部聯動，那么即使是半天的改動量，也會因為優先級不一致而導致交付周期延長xx周，經歷過的都知道痛（要不是不懂，好想直接進依賴方的代碼庫敲代碼）；

減(jian)少(shao)學(xue)習成本(ben)：能力分散的情況下，概念重復的問題會難以避免，進而引入重復學習的(de)問題（尤其涉及指(zhi)標時，重復(fu)學習的(de)成(cheng)本更高）。

上述是定性收益分析，如果還需要定量收益分析的話，可以通過頻率*單次收益來對未來的一段時間做預測，關于頻率和收益的相關建議如下：

頻率：可以通過相關領域是否有重點業務項目來進行簡單的推算，一方面重點業務項目本身蘊含著迭代和運維收益，另一方面，相關領域在重點業務項目之后會伴隨一定的高頻迭代。

收益：對相關類型問題耗時提前做好耗時的采集，進而后續支持分析和推算，這是比較容易被忽視的，同時也較難進行彌補的。

前瞻性&精細治理

可以讓遷入方先接手增量迭代運維任務，然后再接手歷史存在的功能。

可以先交接產品職責，再交接技術職責（包括擴展與維護）。

遷入方可以先在遷出方的代碼庫里進行代碼開發，再擇機進行能力遷移（包括代碼遷移和DB庫遷移）。

在【供應(ying)商(shang)版塊】【采(cai)購(gou)版塊】長達1年(nian)半(ban)的邊界治(zhi)理中，就是按照上述方式進行。一(yi)方面，在2020年(nian)中，2021年(nian)初，2021年(nian)中等3個時間節點，與采(cai)購(gou)團隊(dui)對(dui)齊了治(zhi)理節奏并(bing)預留了資源。另一(yi)方面：

采購(gou)團隊先負責新(xin)增(zeng)需(xu)求，后(hou)熟(shu)悉存量需(xu)求。

采購團(tuan)隊先進行(xing)產品交接(jie)，再進行(xing)技(ji)術交接(jie)。

采購團隊于2020.h2接手運維，2021 全年分(fen)兩次進行能力遷移。

復雜(za)度降解

上述難點分析闡述了穩定性保障的復雜點來自于保障改動范圍的完整性、改動的正確性，生產環境依賴切換的平滑性等方面，那么可以通過以下幾個方式來減少相關復雜度：

確保改(gai)動(dong)完整性

可以基于數據流進行改動邏輯梳理盤點。在技(ji)術層面實(shi)操時，可以(yi)通過DAO層代碼從底下上梳理鏈(lian)路。

進行數據遷移時，不要忘了與(yu)數倉對齊相關(guan)數(shu)據源的改動。

后置非必要(yao)的改動

減少外部依賴(lai)改(gai)造：對于(yu)遷出方(fang)提供給外部的(de)api，暫時(shi)由遷出方(fang)作為遷入方(fang)的(de)反(fan)向代(dai)理，進(jin)(jin)而減少外部依賴(lai)的(de)改(gai)造。后續擇機(ji)進(jin)(jin)行(xing)外部依賴(lai)的(de)改(gai)造。

減(jian)少不必(bi)要(yao)的(de)模型升級：很多時候會想借助(zhu)能力遷移，對遷入的(de)模型進行升級和整(zheng)合，但這必(bi)然增加(jia)改造和驗證復(fu)雜度，如果(guo)不是必(bi)須項，可以后(hou)續擇機(ji)升級。

天(tian)下沒(mei)有免費(fei)的(de)午餐，上述策略(lve)的(de)代(dai)價是額外的(de)時間和研發資源，實操時可根據容錯性進行(xing)選擇使用。例(li)如在(zai)核心資損(sun)鏈路，穩定性是第一(yi)準則(ze)，那么就可以采用該方式。

前(qian)置驗證(zheng)數(shu)據清洗邏(luo)輯(ji)

進行數據遷移時，有時需要通過數據清洗來解決數據異構等等問題。而數據清洗邏輯的測試往往會因測試數據封不夠豐富、測試數據量太少、線上臟數據等因素導致測試不全面，該不確定性會增加線上實施的風險。針對此問題，可以提前基于生產環境數據來驗證清洗邏輯的正確性。

除此(ci)之外，如何(he)應對發布及切換過程中的流(liu)量、回滾策略的設(she)計與實施等(deng)等(deng)也是難點，在(zai)此(ci)不深(shen)入探(tan)究。

4?成果

邊界治理部分成果如下：

提高領域規(gui)劃完整(zheng)性(xing)：通(tong)過【供應商版(ban)塊(kuai)】【倉配版(ban)塊(kuai)】的邊界治理(li)，不僅解決了背景中提到的問(wen)題，【倉配版(ban)塊(kuai)】還在(zai)后(hou)續繪制(zhi)了外倉建設藍圖。

聚焦團隊(dui)目標：供應商團(tuan)隊完成版塊定位，并且后續專注于版塊核心領域的建設。

5?小結

在主導供應商(shang)版塊持續一年半(ban)的(de)邊(bian)界治理過程中，對邊(bian)界治理的(de)理解也在逐(zhu)步加(jia)深(shen)：

除了能力遷移本身外，邊界治理的核心和挑戰在于認知版塊定位，表達版塊邊界，對齊版塊邊界等事情。

邊界治理絕對不僅是技術的事，這個過程是需要產品與技術緊密協作，脫離產品的邊界治理會在實踐時更容易遇到邊界劃分不合理、邊界腐化等問題，最終使得邊界治理變成閉門造車或不具有可持續性。

邊(bian)界治理是個(ge)常態化的事情，隨著業務、技術、組織與(yu)人的認知的不斷變化，板塊的定義(yi)與(yu)邊界仍然需要不斷的演(yan)進才(cai)能適(shi)應(ying)業務的發展。

本文旨在對供應商系統邊界治理進行了體系化基礎性的總結，在細節上不會過于深究，包括業務架構產出和技術重構等等細節。

最后，給大家(jia)推薦一(yi)個簡單好用(yong)(yong)的供應商管理(li)系統(tong)。簡道(dao)云(yun)SRM系統(tong)，一(yi)步連接，開啟千萬供應協作。新(xin)一(yi)代采購數字(zi)化解決方案，全方位閉環管理(li)供應商；互(hu)聯(lian)互(hu)通，實現采購全流程協同管理(li)；好用(yong)(yong)易(yi)用(yong)(yong)，無需下(xia)載軟件(jian)，最快1天即可上(shang)線應用(yong)(yong)。