外觀
警政科技政策與計畫治理
📌 本頁只讀公開的政策文件、行政要點與標準說明。
🔗 接在實習的哪一段：這頁不對應某一天的日誌。它處理的是「系統在被做出來之前發生了什麼」，接在 07-13 需求分析與風險管理 更前面一段：需求變成規格之前，還隔著審議與預算。
這條線我想弄清楚的是什麼
寫程式的時候，需求通常已經長成一份規格。可是規格在更前面是怎麼長出來的，我以前沒有概念。翻完警政科技的公開資料才發現，中間隔著一整段審議與預算流程：策略先變成計畫、計畫要通過分類審議與先期作業、預算過了才有標案，最後才輪到系統設計。這一頁記的是這條線上我看得懂、也查得到來源的幾個節點。
一、S.M.A.R.T. 五個字母各自對著一件事
佐證：我國自 2022 年（民國 111 年）推動「數位警政智慧策略 S.M.A.R.T.」，見內政部新聞稿 〈智慧警政 S.M.A.R.T. 前行〉。
五個字母分別是 S（Security）強化資訊安全管理、M（Mobility）警政行動服務升級、A（AI）情資再造 AI 辦案、R（Resilience）擴增科技偵查韌性、T（Training）厚植數位警政訓練。
首字母縮寫這種東西，我一開始不太當一回事，覺得是給簡報用的。看下來才改觀：五項裡有三項（S、R、T）跟「做出新功能」沒關係，講的是安全、撐得住、人跟得上。策略層願意把三個名額分給這些，後面計畫寫預算時才有理由編非功能性的項目。對我來說，這是縮寫難得有用的地方。
二、一個計畫具體長什麼樣
佐證：警政安全守護雲計畫經行政院 112 年 4 月 18 日核定，期程 113 至 116 年，總經費 3 億 700 萬元，見警政署 政府資訊公開。
這個計畫底下有兩項工作項目：智慧警勤輔助系統與警政韌性防護雲。年度經費分配是 113 年 7,600 萬、114 年 7,650 萬、115 年 7,700 萬、116 年 7,750 萬。
四年幾乎平均攤開、每年只多 50 萬，這件事我看了滿久。從系統的角度看，建置期的花費通常集中在前段，後面是維運。分配拉成一條平線，代表計畫在寫的時候就得把工作切成四段可以逐年驗收的東西，不能設計成「第一年全部做完、後面三年養著」。預算表的形狀會回頭限制專案怎麼分期，這點跟我原本以為的「先設計、再要錢」剛好反過來。
另外一個名詞要分清楚：智慧 XR 警勤訓練系統是《內政部 114 年度施政計畫》裡「數位警政智慧策略計畫」項下的建置項目，不是獨立的中長程個案計畫。原文寫的是「建置數位情資科技偵查及教育訓練平臺、智慧 XR 警勤訓練系統」。
佐證：見內政部 施政計畫。同一份文件在異地備援上的原文為「推動異地備援方案，擴建可執行警政資訊系統之第 2 機房環境」。
三、三類計畫，三套先期作業
佐證：依《行政院所屬各機關中長程個案計畫編審要點》（112.8.11 修正）第三點、第七點，以及國發會 計畫審議與先期作業 公開說明。
政府計畫分成社會發展、公共建設、科技發展三類，審議機關與適用的先期作業要點都不一樣。我原本以為先期作業是一套共用制度，查了才知道是三套並列：
| 計畫類別 | 審議機關 | 先期作業依據 |
|---|---|---|
| 社會發展計畫 | 國發會會同財政部、主計總處審議，報行政院核定 | 《行政院重要社會發展計畫先期作業實施要點》（104.3.5） |
| 公共建設計畫 | 國發會會同財政部、主計總處審議，報行政院核定 | 《政府公共建設計畫先期作業實施要點》（112.7.18） |
| 科技發展計畫 | 國科會審議，報行政院核定 | 《政府科技發展計畫先期作業實施要點》（112.5.9） |
流程本身也有時間壓力。中長程個案計畫須於先期作業審定 3 個月前提報，之後依類別審議、報行政院核定，再進入先期作業的初審與審議排序、額度分配，經委員會議通過後送行政院年度計畫及預算審核會議，最後納入總預算送立法院。
三個月這個數字，換算成技術端就是：需求規格得在預算定案前很久就寫到能被審的程度。系統做出來的樣子，很大一部分是在還沒有人寫任何一行程式的時候就決定的。這也是我覺得資訊人員讀計畫文件不算「行政雜事」的原因。
四、資料中心的門檻寫在要點裡
佐證：《行政院及所屬各機關資料中心設置作業要點》106.1.9 訂定，現行版本 112.12.25 修正第四、九、十一點，主管機關自 111.8.27 起為數位發展部；第九點規定 106.1.9 起新建置之資料中心，能源使用效率值（PUE）應低於 1.6。見 數位發展部主管法規。
這是行政「要點」，不在全國法規資料庫裡，一開始我照法規的找法完全找不到。
PUE 低於 1.6 是我目前看過最直接的一個例子，說明政策文字怎麼變成硬規格。這個比值是總用電除以 IT 設備用電，要壓低，冷卻與供電的設計就得跟著動，而這些都是建置階段的錢，不是事後調參數能救的。所以它必須在計畫書和招標規格裡就出現，驗收時也才有東西可以量。一個數字往上牽動預算、往下牽動機電設計，比很多寫得很漂亮的原則有力得多。
五、TIA-942 和 Uptime Tier 是兩回事
課程與資料裡這兩個名詞常被混著講，實際上發布機構、涵蓋範圍和用法都不同：
| ANSI/TIA-942 | Uptime Institute Tier | |
|---|---|---|
| 發布者 | TIA | Uptime Institute |
| 現況 | 現行 TIA-942-C（2024 年 5 月） | Tier I–IV，1990 年代中期建立 |
| 涵蓋範圍 | 選址、空間、機櫃、佈線、電力、冷卻、消防、實體安全等設施面 | 只涵蓋電力與機械 |
| 性質 | 規範設施設計要求 | 目標導向，不規定用什麼設計手法達成 |
佐證：兩造已協議切割用語，TIA 將 "Tier" 移出 TIA-942，改用 Rated-1 至 Rated-4，見 Uptime Institute 與 TIA 聯合聲明。
分清楚這件事在採購和驗收上是有實際差別的。TIA-942 寫的是設施要有哪些東西，可以逐項對照著查；Tier 講的是要達到什麼結果，怎麼做由你決定。規格書如果只寫一句「符合 Tier III」，驗收時要拿什麼證明，我還沒想清楚該怎麼寫才不會變成各說各話。
六、進氣溫度的建議值
ASHRAE TC 9.9 現行第五版對伺服器進氣溫度的建議值是 18–27°C，Class A1 至 A4 共用。第五版另外針對高密度的 AI 與 HPC 環境新增 Class H1，建議值 18–22°C。
H1 這個新分類值得記一下。它等於承認高密度運算的散熱條件和一般伺服器不同，而且是往更嚴的方向走。要導入這類設備，冷卻能力等於是先決條件，不會是買完機器之後再處理的事。
這篇的分層結構
這篇的軸線是一筆錢從策略走到機房的路線，每一層都在把上一層的抽象講法換成量得到的東西：
text
第 1 層 策略框架
問什麼：哪些面向有資格被寫進計畫、非功能性的項目算不算數
產出：S、M、A、R、T 五個面向的名額分配
↓ 有了名額，還要決定由誰審
第 2 層 計畫分類與審議
問什麼：這是哪一類計畫、誰審、依哪一套先期作業、什麼時候提報
產出：審議機關與先期作業要點的對應、審定 3 個月前提報的時程
↓ 審過了才輪到錢怎麼分
第 3 層 預算與分年額度
問什麼：總經費多少、分幾年、每年多少、每年要交出什麼
產出：113 至 116 年的年度分配、切成四段可逐年驗收的工作項目
↓ 錢的形狀決定規格書寫得出什麼
第 4 層 量得到的硬門檻
問什麼：哪些要求寫得成數字、驗收時拿什麼量
產出：PUE 低於 1.6、進氣溫度 18–27°C、Class H1 的 18–22°C
↓ 數字寫進去了，引用哪種標準還有分別
第 5 層 標準引用與驗收
問什麼：引的是設施規範還是目標分級、驗收看文件還是看結果
產出：TIA-942 逐項可查的設施項目、Tier 的目標導向定位、Rated-1 至 4 的用語切割第 1 層：先決定什麼有資格進計畫。 S.M.A.R.T. 是 2022 年推動的策略框架，S 是強化資訊安全管理、M 是警政行動服務升級、A 是情資再造 AI 辦案、R 是擴增科技偵查韌性、T 是厚植數位警政訓練。縮寫看起來像簡報用語，但五個名額裡有三個跟做出新功能無關，講的是安全、撐得住、人跟得上。策略層先把名額留給這些，後面寫計畫時才有理由編非功能性的項目。這層畫不進任何流程圖，卻決定哪些需求連被審的資格都沒有。
第 2 層：分類決定誰來審。 政府計畫分社會發展、公共建設、科技發展三類，前兩類由國發會會同財政部、主計總處審議報行政院核定，科技發展計畫由國科會審議。先期作業依據是三套並列的要點。時程上，中長程個案計畫須於先期作業審定 3 個月前提報，之後才是審議排序與額度分配，最後納入總預算送立法院。換算到技術端，需求規格得在預算定案前很久就寫到能被審。
第 3 層：錢的形狀。 警政安全守護雲計畫 112 年 4 月 18 日核定，期程 113 至 116 年，總經費 3 億 700 萬元，底下是智慧警勤輔助系統與警政韌性防護雲兩項工作。年度分配 7,600 萬、7,650 萬、7,700 萬、7,750 萬，四年幾乎平攤，每年只多 50 萬。建置期的花費通常集中在前段，分配拉成一條平線代表計畫在寫的時候就得把工作切成四段可以逐年驗收的東西。預算表的形狀回頭限制專案怎麼分期，跟「先設計再要錢」的直覺剛好反過來。
第 4 層：把政策文字變成數字。 資料中心設置作業要點第九點規定，106.1.9 起新建置的資料中心 PUE 應低於 1.6。這個比值是總用電除以 IT 設備用電，要壓低就得動冷卻與供電設計，那是建置階段的錢，事後調參數救不回來，所以它必須在計畫書與招標規格裡就出現，驗收時才有東西可以量。ASHRAE TC 9.9 第五版的進氣溫度建議值 18–27°C，以及針對高密度 AI 與 HPC 新增的 Class H1 建議 18–22°C，性質相同：一個數字往上牽動預算、往下牽動機電設計。
第 5 層：引哪種標準，驗收就變哪種樣子。 ANSI/TIA-942 由 TIA 發布，現行是 2024 年 5 月的 TIA-942-C，涵蓋選址、空間、機櫃、佈線、電力、冷卻與實體安全，規範的是設施設計要求，可以逐項對照著查。Uptime Institute Tier 只涵蓋電力與機械，目標導向，不規定用什麼手法達成。兩造已協議把 Tier 移出 TIA-942，改用 Rated-1 至 Rated-4。分清楚這兩者在驗收上有實際差別：一邊查得出項目清單，一邊只能爭論結果算不算達成。規格書若只寫一句符合 Tier III，驗收時要拿什麼證明就會變成各說各話。
層與層之間的拉扯在第 3 層與第 4 層之間最明顯。分年平攤的額度要求每年都交得出可驗收的成果，而 PUE 這類門檻屬於一次投入、之後改不動的建置成本，硬切成四段就只能挑容易分期的項目先做。真要排順序，我會把牽動機電與空間的數字押在第一年談定，後面三年留給軟體與訓練。順序反過來，前面幾年進度看起來很漂亮，最貴又最動不了的那筆會卡在最後一年。
整條線換到的是「一套系統為什麼做成這樣」有跡可循，往前翻預算書和計畫書通常比翻架構圖有用。代價是技術可行性排到最後才登場。門檻寫得成數字的項目走得順，目標導向的要求到驗收那天仍然沒有好辦法。
往下可以展開的追問：目標導向的標準要寫到什麼程度，契約才不會在驗收時各說各話？分年平攤的額度形狀，會在哪一刻反過來否決技術上更合理的分期？策略把三個名額留給非功能面向，實際編列時換到的比例有多少？
我的反思
把 S.M.A.R.T. 的五個面向和《行政院所屬各機關中長程個案計畫編審要點》的審議流程放在一起讀，感覺像是同一件事的兩個切面。策略決定哪些東西「有資格被寫進計畫」，審議流程決定它「能不能拿到錢、什麼時候拿到」。技術可行性在這兩關之後才登場。
我原本對政策文件的印象是抽象、看了也不會影響做事。PUE 低於 1.6 這個數字打掉了這個印象。同樣的還有 ASHRAE 的建議溫度範圍：它們最後都會變成機房規格、變成標案裡可以量的條款、變成驗收時有沒有過的判斷。制度和硬體之間的距離，比我想的短。
還沒解決的問題是驗收。設施面的標準逐條可查，目標導向的標準要怎麼寫進契約才不會爭議，我目前沒有答案。真正的考驗大概是災害或攻擊發生時系統撐不撐得住，但總不能等到那時候才驗。這個矛盾我還在想。
核心結論
看公開資料最大的收穫，是知道系統長什麼樣不是從需求訪談開始的。策略框架先圈出範圍，計畫分類決定誰來審，先期作業決定拿多少錢、分幾年拿，然後才是規格和程式碼。我想看懂一套政府系統為什麼做成這樣的時候，往前翻預算書和計畫書通常比翻架構圖有用。