南宫NG28建设

數碼化平台這個詞，在不同的會議上指向並不一樣。有人指的是數據中台，有人指的是業務系統群，也有人把官網和公眾號都算了進去。口徑不統一，討論就容易各說各話。把頂層設計、技術架構與落地路徑分開來看，事情會清楚許多：先想清為什麼建、建到什麼程度，再談用什麼搭、怎麼推。三段里任何一段跳過去，後面都要補課。

一、頂層設計先回答三個問題

一個數碼化平台在動工之前，有三個問題繞不過去：它為誰服務，邊界劃在哪裏，由誰負責。為誰服務，說的是給管理層看全局，還是給一線提效率，抑或兩者兼顧；劃分邊界，是明確哪些事由平台承擔、哪些留給專業系統；由誰負責，則是牽頭的是技術部門，還是業務與管理層共同有助于。這三問答不清楚，後面建得越多，返工越貴。頂層設計不是一份漂亮的藍圖，而是把這幾件事在開工前談攏。談攏的意思，是各方都認，而不只是會上點了頭。

1.1為誰服務

服務對象不同，平台的模樣完全不同。面向管理層的，重在看全局與預警；面向一線的，重在隨手可用、少填幾張表。想兩頭都占，就要在設計上分清主次，別讓每一方都覺得它不順手。服務對象一旦含糊，功能就會越加越多，誰的需求都想滿足，到頭來誰都不滿意。

1.2邊界劃在哪

平台不是把所有系統都推倒重建。哪些能力上平台、哪些保留在專業系統里，事先說明白，後續才不至於功能重疊、口徑打架。邊界清楚，各方各守其位，協作反而順暢；邊界模糊，建着建着就會出現兩套並行的賬。

1.3由誰負責

牽頭的人要能跨部門調動資源，也要拿得到管理層的支持。責任落到具體崗位，進度才有抓手，否則容易停在開過幾次會的階段，誰都在場，誰也不真正擔責。

二、技術架構，分層來看

數碼化平台的架構講分層，是為了讓每一層各司其職。數據層負責把散在各處的數據匯集、清洗與統一口徑；能力層通常被稱作中台，把可復用的能力沉澱下來，供上層調用；應用層面向具體業務，按場景搭建；集成與安全貫穿其間，負責對接與守住底線。分層不是說層數越多越好，而是每一層都有明確的職責，改動時能收斂在局部，不至於牽一髮而動全身。分層的意義，也在於讓每一處改動都有跡可循。

2.1數據層

數據的匯集、治理與口徑統一是地基。地基不牢，上層做得再花哨也站不住腳。這一層往往耗時，又不容易被看見，卻偏偏是省不掉的一步。

2.2能力層

把反覆出現的能力抽出來共用，避免每個業務各建一套，日後維護時四處救火。沉澱什麼、沉澱到什麼程度，要按實際復用情況來定。

2.3應用層與集成

應用按場景生長，集成負責與既有系統對接。兩者都要留出調整的餘地，別把結構焊死，給日後留一點變更的空間。

三、落地路徑，別指望一次做完

數碼化平台的建設，很少有一次性完成的。更可行的節奏是先選一兩個價值明確、條件成熟的方向做試點，把數據打通、把流程跑順，再向外擴展。每一期都設定能驗收的目標，用起來之後再看下一步。分期不等於慢，恰恰是分期讓風險可控，也讓使用者的習慣有時間跟上。試點選得准，往後推起來信心也足；一上來就全鋪開，往往頭一道坎就沒跨過去。試點的選擇，寧小勿大，寧實勿虛。

四、幾處常被低估的工作

數據治理是其一，口徑統一往往比建系統更耗時；權限與安全是其二，不是上線後再補的附件；運維與調整是其三，平台交付之後仍需要人持續照看。這幾件事不在功能清單上，卻決定了平台兩三年後是否還立得住。把它們當作建設的一部分，而不是額外的負擔，返工的概率才會小。這些工作做在前面，後面省心；堆到後面，就要用加倍的力氣去補。

五、建成之後看什麼

平台建成之後，判斷它有沒有價值，看的不是功能多少，而是幾件樸素的事：常用的事是不是更快辦成了，數據是不是真的被人用起來了，出問題時能不能在平台上找到依據。如果上線半年，員工仍是繞着它走，那問題多半不在技術，而在一開始的服務對象與邊界就沒想清楚。定期回看這些實際的變化，比看一份建設總結更有意義。用得起來的平台，才算真有價值。

數碼化平台建設，說到底是把頂層設計、技術架構與落地路徑三段接起來看。想清楚為誰服務、邊界在哪、由誰負責，再按分層思路搭好骨架，用分期的方式推進，平台才可能既立得住、又用得上。跳過其中任何一段，後面都要用更高的代價補回來。判斷的標準，終究落在日常是否更順上。