關于城市數字化轉型，大家了解多少呢？下邊這篇文章是筆者結合個人工作總結以及行業資料分析整理分享出來的。包含了架構、實施（微觀）、商業模式的相關內容，大家一起來看看吧！

本文結合個人工作總結以及行業資料分析，闡述城市數字化的轉型過程中，在架構、模式等方面上的一些思考總結。（全文約6000字，預計閱讀10分鐘。）

一、架構（宏觀）

圖1 架構圖

1. 數字底座

數字底座分為核心基礎、應用基礎以及服務基礎三個基礎。

1）核心基礎

核心基礎，即數據。信息是由數據組成的，信息化的實現離不開數據。

數據的采集手段是“核心基礎”中關鍵的一環，在數據采集的過程中，可能會遇到數據標準不統一、數據來源多樣化、數據質量層次不齊的情況。

為了解決這些問題，筆者認為：

需要專門組建一個數據中心，該數據中心主要實現兩個目標，分別為數據的采集和數據的標準建設。

同時，該數據中心需要具備專業性和權威性，專業性是為了保證數據的安全，權威性是為了保證數據的采集范圍。

例如：

在上海的模式中，“上海市大數據中心”作為隸屬于上海市人民政府辦公廳的事業單位，承擔政務數據、行業數據、社會數據和各方面數據歸集和應用融合工作。同時，也會擬定數據資源歸集、互聯、共享、應用等技術標準和管理辦法，指導本市各區、各部門數據管理工作。

在廣東的模式中，數據的承建單位為各級政數局，雖然政數局同樣隸屬于政府辦公廳的部門管理機構，但是筆者認為，在一些因素的影響下，政數局在數據的歸集工作和數據標準工作的發揮空間不夠，對于任務的復雜性的解決存在阻力。因此，容易導致數據采集的范圍不全，標準不齊，質量不好，時效性低等情況。

筆者認為，是否可以有一種新型的數據服務模式，數據的基礎性和協調性工作可以由政數局/大數據中心等政府代表牽頭，協同國有的信息化企業，借助國有企業的產品專業性和技術專業性，完成數據的采集和數據的標準建設工作。

最終的目的就是，通過合作開放的方式，打造一個“政務數據超級大湖”，并且通過”數據河流”連接各式各樣的“小數據湖”（不限于政務數據），在不同的河湖之間建設不同的“政務水利工程”來保障數據的傳輸性和安全性等。

因此，在數字化轉型的過程中，需要不斷的完善數據采集機制和數據對接標準，在標準化手段的基礎上，直接或者間接采集各行各業的數據，打造好“核心基礎”。

2）應用基礎

數據的應用需要平臺的支撐，因此，提出應用基礎的概念，即數據中臺。

數據中心（核心基礎）搭建完成后，在數據轉換為信息的過程中，需要對數據進行進一步的處理，包括數據的流通、數據的計算以及數據的應用。

此處的數據應用，更多的場景是體現在大屏（駕駛艙、指揮中心），因為大屏的實現蘊含了大量的數據計算和應用。

因此，針對大屏或者其他的需求實現，可以交給數據中臺來負責處理和計算數據，為大屏及其他產品需求提供更好的基礎支撐。

筆者認為，上述的數據中臺，需要考慮平臺的歸屬或者管理問題。因為數據中臺的目的是為了更好更快的為應用提供服務，如果服務不能夠得到及時的響應，那也可能會變成一種“擺設”。

同時，大屏的價值體現和對業務的理解水平緊密相關，也和數據的敏感性密切相關。因此，數據中臺的建設非?？简灁祿慕Ｋ?。

最后，在數據中臺的建設過程中，建議數據產品和數據工程師需要在業務上形成緊密的聯系，避免在數據建模的過程由于業務認知的差異性導致后續大屏指標的偏離。

3）服務基礎

在數據應用的過程中，大部分的技術能力是具備公共服務屬性的，因此，提出服務基礎的概念。服務基礎包含服務中臺和算法中心。

服務中臺主要是指將公共的能力或者技術進行標準化的包裝，根據權限適當的內部開放或者外部開放。例如：人口庫、法人庫、空間地理庫等。

算法中心（中樞）主要是指將算法的能力進行標準化的包裝，根據權限適當的為內部或者外部賦予技術能力。例如：AI識別、知識圖譜等。

4）總結

數據是核心，應用基礎和服務基礎是數據基礎的衍生，這三個基礎同時平臺賦能的同時也需要具備自定義拓展的能力，即“通用”、“實用”和“好用”。

2. 數字化應用

數字化應用分為智慧平臺、指揮中心、專題專項三個應用。筆者認為，智慧平臺的應用會優先于指揮中心，因為決策的基礎是有用戶的使用以及業務數據的沉淀。

建設思路是，在使用或者實踐的過程中，通過使用產生的數據分析或者使用過程中提出的意見反饋來反向推動指揮中心的構建和完善。

該思路筆者稱之為“應用優先，在實踐過程中挖掘決策需求”。上海也有類似的口號，稱為“從能用、好用到愿用、愛用”。

即：先能用，在打磨成好用，最后通過決策改進升級成愛用。

1）智慧平臺方面，從主要角色出發，可以分為以下三個方向：

1. 公職人員（類公職人員）: 此類平臺主要為公職人員（類公職人員）服務，從行政職能出發，通過平臺或者數字化信息化的手段更加高效、智能的完成和發揮職能工作，更加的管理好城市運行工作。此類平臺包含智慧司法、智慧法院、智慧環保、智慧應急、智慧黨建、智慧政務等。
2. 公民、法人及其他組織: 此類平臺主要為公民、法人及其他組織服務，即為民生服務。此類平臺包含智慧醫療、智慧停車、智慧教育、智慧社區等。
3. 其他: 此類平臺主要為其他方向的內容服務，例如產業、行業、物體等定義性的內容。此類平臺包含智慧農業、智慧商務、智慧旅游、智慧園區等。

2）指揮中心和智慧平臺不同，平臺主要為目標（工作目標、民生目標等）服務，指揮中心為領導服務。

通過大屏、數據分析、報表、周月報等形式為領導提供決策支撐，直觀掌握城市運行情況。

此類中心包含運行管理指揮中心、輿情中心、預警中心等。

值得注意的是，現有政務體系的決策支撐產品化內容更多的只是數據的可視化，個人認為并沒有達到一個數據分析的可視化，分析的能動性大部分還是需要用戶自身驅動，但是用戶的時間和信息化水平是否能夠用好呢？這是個需要思考的課題。

3）專題專項主要是為了重大的、緊急的、重要的任務服務，它和上述兩個不同，專題專項更具備任務的緊急性和嚴謹性。

此類專題包含了營商環境專題、疫情防控專題、經濟復蘇專題等。

4）總結筆者認為，專題專項和平臺之間存在場景或者業務的重合性，在建設過程中，如果是不同成員之間，那么緊密的交流和聯系是必要的，切莫各自為戰，應該是統一戰線。

二、實施（微觀）

第一部分主要從宏觀上對于底座和應用的一些思考闡述，第二部分主要從微觀上闡述模式和工作機制上的一些思考。

1. 項目模式

由于城市數字化轉型的工程復雜，周期長，以及涉及關系較多，因此關于項目的模式，筆者僅以自身工作經驗中淺談其中的做法。

在筆者的經驗認知中，有兩種信息化項目的建設模式，分別為傳統的項目模式和新穎的運營模式。

1）項目模式項目模式，即以系統需求和功能建設為導向，根據系統建設的軟硬件需求和功能需求來進行立項。

在項目模式的過程中，筆者總結了以下2個遇到的問題：

①需求問題

因為立項方案的時間一般是早于需求調研的時間，因此很多需求或者功能的設計是基于拍腦袋的方式提出的，并不能完全貼合實際的應用場景。

但是，智慧城市的建設，特別是關于民生的建設，我認為必須是以用戶實際價值為核心的。因此，這種項目模式會導致驗收時的建設不符合預期的情況。

②服務問題

項目模式在一定程度上基本屬于一次性的建設服務，最多就是附帶幾年的支撐服務，而且考慮到建設方的成本問題，支撐服務的質量一般。

但是，現代化城市的發展是迅速的，如果建設的平臺不能夠跟上城市化發展的進程，如果該建設需求不是非必要性的場景適用，總有一天是會被荒廢的（即無效建設）。

2）運營模式運營模式，即以用戶價值和用戶服務為導向，根據提供服務的數量和要求以及建設系統的內容來進行立項的信息化項目建設模式。

值得一提的是，該模式并不是完全拋棄系統建設內容本身，它還是存在系統建設（軟件功能設計），只是這塊內容并不是方案的核心。

運營模式的好處在于，在方案的規劃過程中，可以不必過于挖掘用戶的更加細節的需求，而是先專注于思考為用戶提供哪些方面的服務，它比項目模式更加的抽象化。

在運營模式的過程中，筆者總結了以下2個遇到的問題：

①指標問題

運營模式的難點在于，如何細分服務的內容，如何明確服務的邊界，如何規劃服務的框架以及如何量化服務。量化的核心在于項目金額的計算。這個可能非?？简瀰⑴c立項的人員水平（因為涉及審計的風險問題）。

②邊界問題

雖然運營模式弱化了系統建設本身，但是正因為弱化了此項內容，在項目的建設過程中，如何把握系統建設的邊界，如何控制成本，如何規劃項目建設的優先級，是一個比較棘手的難題。

2. 項目主體

由于智慧城市的主體包含管理者、應用開發商、系統集成商、服務運營商、第三方機構等，其中的復雜性筆者還不具備專業能力闡述。因此，下面僅以筆者經歷過的項目角度討論。

1）管理者管理者，項目的主要協調和決策者，一般是由政府承擔。

管理者在項目的推動過程中起了很重要的領頭作用。

例如在某省的智慧平臺項目中，雖然是省政府重點關注項目，但是實際的管理者是省政府的組成部門（非辦公廳牽頭），雖然該部門在其中也具備很大的說話權，但是不乏有部門不買賬，或者配合力度不夠的情況。

因此，在項目的實際推進過程中，會存在和各行業機關部門的聯系不夠緊密的情況。僅僅只是牽頭部門通過擬定標準，按照統一標準執行落地項目。因此，會導致用戶的實用性并不是太可觀，也會導致使用率不高。

再比如在某直轄市的智慧平臺項目中，同樣是市政府重點關注項目，和某省的不同之處在于，它實際的管理者就是市政府的內設機構部門，同時也會指定相應的組成部門作為業務主導方和技術主導方。

所有的項目推進和匯報都是以市政府的內設機構部門為主，在項目推進和部門聯系上，雖然也會有一點的阻礙，但是不影響主要流程的順暢進行。

2）應用開發商項目的應用開發商，一般是由企業擔任。

某省的智慧平臺項目模式中，“xx企業”是省級數字政府建設運營中心，它提供頂層設計、平臺建設、業務創新等服務，其余的系統建設、實施運營等服務由合作的企業（生態伙伴）負責。

這種模式的優點在于，“xx企業”能夠保障某省的數字政府項目的頂層統一性、架構專業性以及數據安全性，并且能夠規范項目的交付流程。

缺點在于，首先是業務知識的薄弱性問題，“xx企業”因為重點聚焦于標準和統一，因此在業務的鉆研上，還是存在一定的局限性。

同時，“xx企業”掌握著和用戶溝通的直接橋梁，系統的建設方（生態伙伴）不能及時直接的和用戶調研溝通，會導致建設方的需求設計質量和創新不夠。

其次，交付周期較長。成也流程規范，敗也流程規范，項目并不是一成不變的，項目落地過程中如果不能夠及時的變通流程規范，會導致項目的交付周期延長，甚至增加建設方的成本。

某市的智慧平臺項目模式中，業務部門（市的組成部門）作為業務的主導方和需求的把控方，技術部門（市的下屬事業單位）作為技術的主導方和賦能的提供方，建設企業（廠商）作為項目的建設方，并且會參與市政府辦公廳、業務部門以及組成部門的項目小組中，一起推動項目的建設和落地。

這種模式比較考驗建設方也就是建設企業的專業性和標準性，即是否有足夠的專業能力承擔起標準的建設和項目的建設。

3. 工作機制

在建設的過程中，項目建設方需要不同角色參與并完成項目的落地，如產品、設計、測試、運維等。

以下是我所理解的工作機制模式：

1）里程碑首先是里程碑，里程碑是項目的核心。

該里程碑一般由項目管理者制定，由管理者界定每個時間點應該完成的工作目標，并且該目標通過發文的形式通知到各合作方，作為項目的推動背景（推手）。

2) 實施計劃里程碑制定完成后，由建設方配合管理者細化每一個里程碑的推廣實施安排，可以按照不同的維度分組或者分類，細粒到每一個涉及的單位以及時間點安排。

計劃制定后，由管理者組織項目推廣大會，并發函給各參與單位，在大會中明確項目的重視程度和對各單位的要求。

3) 倒排計劃在實施計劃的基礎上，由項目建設方協同項目參與方確定更加詳細的倒排計劃。

該倒排計劃制定完成后，固定周期內通過某種形式匯報給管理者及抄送給其他參與者，如果有計劃的延期風險或者存在推進難度，及時組織會議協調解決。

4) 工作小組根據上述擬定的計劃，組建工作小組，明確工作小組的責任人和聯系人，定期組織項目例會溝通計劃的進度和計劃的風險。

5) 版本規劃根據計劃規劃版本，在版本規劃的過程中，可能會出現版本之外的需求或者任務，需要及時的進行動態調整以及匯報。

版本規劃中關于角色職能的思考如下：

①項目經理（PMO）

項目經理分為對外溝通和對內溝通兩個角色。

1. 對外的項目經理負責和客戶溝通，和客戶建立良好的溝通關系，及時收集和匯報項目信息。
2. 對內的項目經理負責項目的跟進，把控項目或者版本的進度，分解項目內容，合理規劃資源，輸出項目匯報材料等。

②產品經理等其他角色

各司其職的同時，需要產品同學拉通整個項目組的目標，即目標的統一性和業務的專業性。不能為了交付而交付，更重要的是應該達到各成員對業務都有一定的理解性。

總結：版本交付是一個因素變化很大的工作，特別是合作方多的情況下，最重要的還是如何把信息拉通以及如何預防風險。

三、商業模式

筆者認為，智慧城市的方向是為民，為城市運行服務。但是，服務的前提是生存，生存的核心是價值。企業如何在賽道中生存，如何提供更大的價值，是商業模式中重要的一環。

筆者建議，在項目落地的過程中，需要摒棄以交付為核心的理念，重視以產品為核心的理念。

因為，每個城市的市場、環境和條件層次不齊，如果需要把產品向外滲透，或者成為標桿，需要在打造智慧城市的項目過程中，盡可能的解耦每一個業務板塊，讓每個業務板塊都具備獨立運作的能力。

其次，需要盡可能的讓平臺具備通用性，或者，讓平臺具備高拓展性，這樣可以盡可能的在其他城市中復制和改造。

值得一提的是，在政企的信息化服務范圍中，筆者認為還是存在純公益服務性的產品化內容，這類內容需要摒棄商業化的思想，從“公益服務”的角度出發，切實的解決人民的問題，從量化問題的解決下手，不斷的投入和產生公益價值。

最后，在營收方面，是否可以從政府中獲取的項目收入的同時，后續可以把標準化的能力或者數據包裝成服務，對B端銷售。

以上內容僅為個人在工作中以及閱讀中的總結和思考，描述若有不當之處，還請批評指正，謝謝！

四、參考文獻

《百度城市數字化轉型白皮書》-劉捷、徐志發

《新型智慧城市設計與建造》-劉伊生