在這篇文章里，我要和大家分享一段跨越500天的主數據項目實踐之旅。這不只是技術實現的故事，更多的是關于團隊協同、決策的考驗與數據治理的探索。從項目初步構想到最終成功上線，我們經歷了很多挑戰，如決策的糾結、認知差異、系統的復雜度以及項目中的種種不確定性。請隨我一起，一同探索這段旅程的起伏和轉折。

1、決策過程艱難

現實世界中的每一個地址，都代表著一個家庭或者商業客戶。對于運營商來說每一個地址也就意味著一個市場機會，梳理清楚了地址數據也就掌握了整個潛在的發展市場。

由于原來采用煙囪式的管理模式，公司地址數據分布在BOM三域多個業務系統，不同業務系統的地址數據格式和標準均不相同，使得前后端協同的效率降低，例如，市場前端需要基于小區地址進行寬帶攻堅，但網絡后端家寬覆蓋地址的信息無法準確匹配到，這樣就影響到了家寬網絡的擴容。

正是在這樣的背景下，公司決定啟動地址主數據系統的建設。首先我們來看下項目的時間線：202203 公司數據治理聯席會議第一次會議，管理層提出地址主數據統一管理的要求202204 公司數據治理聯席會議第二次會議，地址數據現狀和統一管理思路匯報，決策由數據管理部牽頭建設202206 公司數據治理聯席會議第三次會議，地址數據整合方案匯報，匯報全量地址目標庫建設思路202207 公司數據治理聯席會議第四次會議，地址主數據系統建設方案匯報，計劃分三個階段推進地址主數據系統的建設，明確項目組織和主要建設內容202208 公司數據治理聯席會議第五次會議，地址相關業務流程梳理情況匯報，各業務部門匯報地址相關業務流程梳理情況和錄入規范情況202210 第六次會議，部門內地址主數據項目階段匯報，明確運維職責202301 地址主數據系統開發完成202303 第一批地市割接上線202305 第二批地市割接上線202306 第三批地市割接上線202307 全部割接完成由于地址數據涉及前端家寬銷售、后端資源開通等大量生產流程環節，跟公司主要的前后端部門都息息相關，公司層面前前后后開了六次會議進行討論，主要圍繞三個核心問題進行決策：

第一，到底由誰來牽頭管理和建設地址主數據系統？

我們選擇了職責最清晰，但挑戰最大的一種，即由第三方數據管理部來負責，因為數據管理部屬于企業級數據管理部門，相對中立，同時本身就有數據治理職能。挑戰最大是因為其沒有地址相關系統建設和管理經驗，需要從0到1去整合各類地址系統的存量數據，溝通協調的挑戰比較大。

第二，到底采用哪種主數據管理方案？是集中管理還是分布式管理，是新建一套系統還是選擇一個存量系統進行擴展升級？

由于公司前期決策是由一個新的數據管理組織來負責建設和運營主數據系統，最后公司還是傾向選擇新建一套集中化的主數據系統的方案，這其實是組織架構決定系統架構的體現，當然這種架構也帶來了可能的性能瓶頸和單點故障的風險。

第三，到底由誰來對業務流程進行梳理和規范？

考慮到地址信息可能會改變我們的前端業務流程，還可能會影響到第一線的員工如何使用，所以在開始系統設計之前，必須仔細分析這個問題。公司決定讓數據管理部門來負責這項工作。我們不僅需要規劃出詳細的流程，并創建一個統一的模板，還要和其他相關部門一起協作，確保每個流程都能順利進行。這對數據管理部門的專業和團隊協作能力都是一個挑戰。總體來講，決策的過程還是比較長的，因為各部門有自己的站位和難處，自身所在的團隊也有各種局限性，比如很多的技術思維，不熟悉相關業務和系統等等，最后還得由公司領導一錘定音。

2、認知挑戰巨大

我總結為三個挑戰：

第一個是從局部到全局的挑戰。

當老板在第一次數據治理聯席會議上說要我們統一處理公司的地址信息，并希望我們團隊來主導時，我們都有點懵。雖然我做數據的時間不短，知道主數據管理是什么，但對公司的地址信息和相關業務真的不太了解，這讓我有點擔心。

做好企業級的數據治理，需要打破部門壁壘。雖然公司已經建立了企業級的數據治理組織，但大家的想法可能還停留在之前。我一開始也是，還是習慣于為自己的工作劃定清晰的邊界，當任務超出這些邊界時，就會有所猶豫，這也是我的個人局限。

比如梳理業務流程，我覺得這應該是業務部門的事，技術部門來主導似乎不太對頭。但后來意識到這種思維還是太局限了。數據治理其實就是要處理這種不清不楚的事。知道有問題，知道自己做可能有局限，但總得有人勇敢地邁出第一步。

事后我也做了總結，發現對于跨部門的事，只要有公司領導的實際支持，不說做到最好，但總是可以做得比以前好一點，即“追求進步，而非完美”，關鍵還是要有些勇氣和擔當。

第二個是統籌協調的挑戰。

身為技術管理者，我對技術工作很感興趣，它相對純粹，可以說技術是我的舒適區。雖然必要的上層匯報和同級溝通不可避免，但它們占用的時間比例不高。

然而，當我開始從事主數據工作時，事情變得相反。長時間里，我很少關注技術管理，而是忙于為公司的數據治理聯席會議做準備，并處理各種跨部門的議題，涉及組織、技術和資源等。在這段時間里，我牽頭了六次聯席會議，并為每一次做專題匯報。大量的準備和協調工作讓人焦慮，因為很多東西不是你說了算，什么都要商量著來，而且時間還不確定。

例如，每次會議前，我都要電話溝通關于報告的內容，確認是否有異議。對于存在異議的內容，我們需要詳細記錄以便應對，還必須提前一周與各部門領導確認他們的出席情況，并在會議前通過微信再次確認，因為許多關鍵決策需要領域負責人的意見。有一次，某部門的領導因緊急事務缺席，雖然他指派了其他人員代表，但決策效果顯然不如預期。

實際上，不只是我一個人在努力協調，整個主數據項目組也都在忙于此事。每當我聽到團隊成員在隔壁與其他部門討論主數據方案時，我總會有些擔憂，擔心原定的方案會被否定，這意味著我們需要重新規劃。比如，我們最初理想地認為通過API提供主數據服務就足夠了，但后來發現某些部門的系統需要物理數據表，這又引發了數據一致性問題。這樣的挑戰很多。

第三個是邊做邊學習的挑戰。

盡管我對主數據有基本的了解，但實際操作經驗是缺乏的，大家都面臨同樣的問題。作為主導部門，能否贏得各部門的信任變得尤為關鍵，因此此刻，快速的學習和適應能力顯得至關重要。

主數據與公司的業務、數據和系統緊密相關。在短時間內找到一個完全合適的供應商不太可能，因此我們只能依賴團隊內部的資源。我和我的團隊迅速查閱了所有可用的主數據相關資料，并開始深入的系統調研。我們的目標是清晰地分析地址數據的不一致性，并在系統、數據和業務上找到解決方案。但這一任務十分繁重，因為涉及的地址數據量大且復雜。

經過四個月的努力，我們終于完成了方案的定稿，期間經歷了無數次的修改。最具挑戰性的部分是數據整合方案，我們需要重新設定標準，反復研究建模方法，并清洗數億的存量數據。接著是業務流程改革方案，起初各業務部門提供的流程較為混亂，我們為此專門設計了一個統一的流程模板，并附帶了一個示例，目的不僅是幫助我們自己理解，還希望可以指導其他人。最后就是系統方案，由于涉及的系統眾多，我們需要構建一套橫跨BOM三域、融合OLAP和OLTP的全新系統架構，這對于數據中臺團隊來說都是新的東西，需要重新學習。

3、系統架構復雜

在系統架構方面，我們進行了一些變革和創新。首先，地址主數據系統采用的是最徹底的集中化的主數據系統架構，即“一點采集，統一服務”，好處是能確保地址數據的一致性，壞處是實施難度很高，不僅要求剝離資管、CRM等系統原有的獨立的地址數據管理模塊，新建一套全新的主數據系統，還要對原有所有系統進行適配改造。我們所以果斷的采用這種架構，也許是因為我們在數據管理方面的積累還不錯，也許是太過自信了。后來我發現坑還是很多的，整個方案來來回回近半年時間，難度遠遠超出原來的設想，同時單點故障等架構的隱患也讓項目組非常頭痛。其次，地址主數據系統設計之初就不是單一的系統，而是包括生產服務、地址管理、地址分析三大子系統，這三個系統分屬OLAP+OLTP不同的類型，生產服務子系統為CRM、資管等外圍應用提供地址新增、變更、查詢、分發等生產性服務，地址分析和管理子系統通過稽核分析的手段將新增/變更的地址數據納入生產，從而共同支撐地址數據的閉環管理，我們建設的其實不僅僅是一個IT系統，更是要打造一個地址數據的閉環管理體系，復雜度還是比較高的，最后的系統架構如下所示：

最后，地址數據是非常有價值的數據資產，我們這一次做的不僅僅是內部存量地址的整合，還要盡可能的把各種外部地址數據盡量的采集全面，包括采買的地圖地址數據、一線排摸的地址數據、POI數據、爬取的各種外圍地址數據等等。在這些地址數據的基礎上，我們制定了13+N的標準，自研了清洗算法，最終得到了一份超1億條的標準地址數據。整個數據處理的過程耗時半年。

4、項目控制棘手

項目實施中,我們也面臨了一些項目控制方面的挑戰。地址主數據系統的項目結構較為復雜。雖然有公司領導掛帥,成立了項目領導小組及工作小組,但涉及的相關部門達9個之多,工作小組下掛的專業組就有5個之多，分別是系統架構組，平臺建設組，數據建模組，O域改造組及B域改造組，如下所示：

這樣復雜的項目團隊結構，決定了項目控制的難度。我對此感受最深的有以下三點:

第一個是OLTP和OLAP團隊融合難度高。

地址數據的整合是項目成功的關鍵。在這方面，數據中臺團隊還是比較有優勢的，他們不僅擁有豐富的數據處理經驗，還具備AI能力。然而，我們的地址主數據系統不只是用于分析的工具，它更是一個要求高連續性、跨多個領域的企業生產系統，因此系統的穩定性是非常關鍵的。在穩定性方面，業務中臺團隊顯然更有經驗。如何結合兩支團隊的特點，進行有效的協作，是我們在項目管理上要面對的挑戰。

經過考慮，我們決定由CRM業務中臺團隊主導實施，與數據中臺團隊緊密協作。這種合作方式雖然在初期曾出現團隊之間的責任不明確、進度不同步、OLAP與OLTP數據同步問題等挑戰，但從總體上看，這確實是一個有效的協作模式。首先，我們對數據團隊有很好的控制和了解，這降低了許多溝通成本。其次，業務中臺團隊的加入為數據團隊帶來了稀缺的能力，使我們最終能克服系統穩定性的問題。

第二個是在計劃管理方面提出較高要求。

項目最初計劃在6-8個月內完成，但由于與其他部門協同工作的難度，導致進度遠超預期。我們的項目經理過去主要在某一專業領域工作，對于涉及跨領域的大型項目顯然缺乏經驗，我也是如此。在這超過一年的項目周期里，除了初期的方案匯報，我們幾乎沒有在公司層面進行過其他階段性匯報。當時的考慮是，組織匯報會議涉及太多事務性工作，盡量避免為好。但現在看來，這確實是戰略上的疏忽。

同時，也存在一些戰術上的問題。如，項目前期與各部門的共識不足，原先制定的時間計劃未得到其他部門的明確確認；執行階段的控制不夠嚴格，每周的會議常有部門缺席；項目進度和問題缺乏透明度，在遇到問題時往往采用自己解決的方式，而不是及時升級。

當時，我還同時負責對接集團公司財務系統集中化的本地支持工作。在項目期間，無論是論證、啟動、調研、方案設計、動員、檢查、上線或總結等會議，集團公司都是事無巨細，現在回想起來，發現這些手段的確有助于大家形成共識和確保項目的順利進行。當然財務集中化有條線管理的優勢，企業級數據治理橫向協調的難度會更大一點，但道理是一樣的。做事總是要虛實結合，適當的虛是為了更好的實，我在這方面的度把握的還不是很好。

第三個是在底線的基礎上融合各方觀點。

地址主數據項目由我們的數據管理團隊負責。但由于團隊之前缺乏地址數據的建設和運營經驗，我們往往走得更像是一條理想化的路徑。而實際上，不同系統領域對地址數據服務的需求在形式、及時性和準確性上都各有差異。項目的整個過程就像是一個不斷學習和包容的旅程。以下三個點給我留下了深刻的印象：

數據一致性的挑戰：雖然項目組初衷是以API的方式提供地址服務以確保數據一致性，但我們意識到資管系統實際上需要同步一份地址數據副本。這樣，它們才能在本地進行高效、靈活的二次處理以為各自領域提供服務。雖然這可能會引入一些數據一致性的問題，但它確實是一個相對低風險的解決方案。

業務影響的控制：我們曾提議制定地址數據錄入規范，并希望一線人員按照“13+N”的標準進行分段錄入。但這一改變所需的成本實在過高。最終，我們與業務人員達成共識：維持前端的錄入流程，并采用AI技術標準化前臺錄入數據。但某些工程管理崗位的人員仍需遵守該標準。

降低割接風險：為了減少割接對生產環境的影響，我們采納了領域專家的建議，通過映射存量地址ID和新ID來實現地址格式的兼容性，而不對存量系統進行大的改造。盡管這樣會為存量系統的地址表帶來一些冗余，但這無疑是性價比最高的方法。但我們始終能堅守底線，即“集中控制，統一分發”。在這基礎上，愿意探討并采納各種折中的解決方案。

5、總結

項目雖然經歷了諸多曲折，但在企業級數據治理體系的保障下，大家還是做了一件以前很難做到的事情。我們組建了由IT、網絡、市場、政企、規劃、工程等團隊組成的跨部門聯合小組，統一了地址主數據的標準和規范，并對13個地址業務流程進行了重構和優化。最終，在7月，地址主數據系統順利上線。這為公司在家寬資源的精準覆蓋、小微企業的高效拓客以及網格的精準營銷等方面的工作奠定了良好的數據基礎。

這也是我參與過的涉及部門最多、跨領域最廣、改造系統最多、團隊構成最復雜的一個項目，更是我做的第一個主數據項目，對我而言，這是一段難忘的經歷。最近，我們與規劃部門針對地址主數據的后續建設方向進行了深入研討。我們發現，盡管已經邁出了初步的步伐，但地址數據質量的進一步提升和實際應用依然面臨諸多挑戰。此外，公司還有大量的企業數據一致性問題需要解決，如訂購數據與開通數據的不匹配等等。這些數據的不一致性已對公司的客戶體驗和經營管理造成了不小的影響。因此，我們還有很長的路要走。