昨天一篇是針對資源盤點的 Situation，今天將針對 Situation 後的 Task 進行分析：

Task

以下是盤點項目的簡列，一些考量的思路及要項供大家參考（非全部，僅是提供一些思路參考）：

Tier One：

主要是先從可以具象化的事情先盤點起，除了盤點也建立起新的資訊部門跨部門溝通模式。

1. 現存軟硬體資源盤點：
   a. 機房服務支援：

   • 各個硬體面的現狀盤點，如主機年限、檔案伺服器、硬碟年限，傳真機 … 等，及相關的專案合約、保固維護合約相關現況是否齊備。
   • 機房基礎設施的現狀盤點，水電、空調、監控、防災，各系統的使用現狀，及相關的專案合約、保固維護合約相關現況是否齊備。
   • 相關備援維護SOP是否齊備，如機房電源的雙回路設計是否可以照案施行，如需要用到柴油發電，備料現況，最長可以支援多久，相關後續支援的合約是否已簽署，意外處理程序是否備妥。
   • 意外狀況處理程序是否已確實規劃，並已進行風險評估，將可能風險跟管理團隊溝通，經核准歸案，若有意外可照案執行。

   b. 硬體服務支援：

   • 釐清合約提供的硬體支援細節，含各項支援的時現，及違約的罰則是否足以確保外包商會按約履行
   • 每年保固的合約有效性，成本效益分析。
   • 是否有確切的驗證程序足以確保保固有效性（含外包商技術支援能力是否到位）。

   c. 網路服務支援：(服務端視角、個人端點視角)

   • 類似上述基礎的服務端需考量的，主要是盤點現存網路架構，資安管理，成本效益分析。

     1. 路架構是否合理，是否可以足以支援日常運作、資安及意外處理所需。

        • 是否有適當的網段切割，如微網段架構施作。
        • 各網段的流量是否有控管，僅限必要存取的流量在合理狀況下發生。
        • 相關設備是否有定期更新，相關更新程序及意外處理程序是否齊備。
        • 如出現意外狀況，是否有適當備援程序，可以配合即時支援，是否有足夠的資料足以進行意外當下及事後的分析所需。

     2. 如防火牆的管理規則設計是否合理，是否可以足以支援日常運作、資安及意外處理所需。

        • 內外部流量是否都已架上適當的管控程序。
        • 相關設備是否有定期更新，相關更新程序及意外處理程序是否齊備。
        • 如出現意外狀況，是否有適當備援程序，可以配合即時支援，是否有足夠的資料足以進行意外當下及事後的分析所需。

     3. 各網路設備節點的管理程序是否足備。

        • 是否有配合管理規範進行控管（ISMS, or configuration managment procedure）。
        • 其他請參考上述概念施作。

     4. 如內部資源不足以支援，是否有適當外包資源支援，或是下一階段改善計劃（如改以雲架構支援）。

   d. 系統服務支援：

   • 各系統作業系統的現況盤點。
     - 相關設備是否有定期更新，相關更新程序及意外處理程序是否齊備。
     - 是否有配合管理規範進行控管（ISMS, or configuration managment procedure）。
     - 如出現意外狀況，是否有適當備援程序，可以配合即時支援，是否有足夠的資料足以進行意外當下及事後的分析所需。
   • 各系統本機設定是否有完成適當且必要的調整，並定期進行定期查核程序。
   • 各系統存取程序是否有適當規範及定期進行查核程序。
   • 如內部資源不足以支援，是否有適當外包資源支援，或是下一階段改善計劃（如改以雲架構支援）。

   e. 軟體服務支援：

   • 各軟體（應用解決方案）的現況盤點
   • 以企業流程盤點整體軟體架構是否合宜，解決方案跟作業流程的組合效率及效益現況
   • 以企業數據儲存，連結（服務提供方式），數據資料交換方式，進行數據流的盤點

   f. 雲端服務支援：

   • 雲端架構
   • 混合雲解決架構
   • 架構調整計劃

   g. 個人服務端點支援：

   • 終端使用者使用狀況盤點：
     • 個人電腦及資料存取使用現況（使用者角度）：
       • 硬體（桌機或是筆電使用場景）
       • 軟體（作業系統及應用軟體）
     • 如何管制：
       1. 帳號生命週期管理（各級員工、外包、訪客等場景）。
       2. 帳號權限管理。
       3. 相關配套稽核作業管理。
       4. 配套控管措施，如: MS endpoint management solution。
     • 如何監控：
       1. 配套監控措施，如: MS defender solution。
     • 異常狀況處理規範：
       1. 配套異常處理規範：
          • 配套作業流程，怎麼通知，怎麼協助使用者及企業進行風險評估與異常處理程序。
          • 配套解決方案，如: MS sentinel solution。
   • 個人網路及組織資源存取現況（組織角度）：
     • 企業數據資源存取架構：
       1. 地端：如機房。
       2. 雲端：如 MS O365、Azure or Google workspace,、GCP。
     • 如何管制：
       1. 一般帳號、網路、稽核相關管制配套措施。
       2. 制度類的規範，如資料不落地，後台不提供相關功能，查詢一次不可超過幾筆之類的。
     • 如何監控：
       1. 如配套資安或稽核需要的即時紀錄。
     • 異常狀況處理規範：
       1. 如配套的異常監控機制，發現異常的實時處理機制（帳號限制存取等）。

   h. 辦公室服務支援：(門禁、監控、wifi...)

   • 門禁：
   • 監控：
   • 辦公室網路：（有線及無線使用場景，各級員工、外包、訪客等場景）
   • MIS支援模式：
     • 軟硬體問題：
     • 日常使用問題：
     • 資安問題：

2. 現存軟硬體供應鏈資源盤點：

   • 協力廠商資源盤點：
     1. 合約跟履約內容是否落實。
        • 交接項目跟驗收是否有落實、常規作業跟報告是否有符合品質產出。
     2. 軟硬體實際支援能力
        • 如：廠商是否有能力完成合約承諾的服務品質。
     3. 相關服務品質確保相關規定是否有規範、是否能落實。
        • 如：異常處理機制跟時限、相關罰則是否有實際規範力。
   • 硬體簽約支援廠商資源盤點：
     1. 除上述外，如：
        • 保固涵蓋範圍？
        • 廠商的備品即時支援能力，跟原廠的合作關係為哪種形式？是否可以獲得即時有效支援？
   • 軟體簽約支援廠商資源盤點：
     1. 保固涵蓋範圍？
     2. 是否為代理解決方案，跟原廠的合作關係為哪種形式？是否可以獲得即時有效支援？
     3. 是否為自行開發解決方案？產品過去的品質？人力支援品質（ex, PM、Eng)？支援的彈性（如主程式異動只能在非上班時段進行）。

3. 現存人力資源盤點：

   • 資訊單位人力資源盤點：
     • 是否有產品及專案管理能力。
     • 是否有規劃、設計、開發、維運能力。
     • 是否有持續學習成長的能力。
   • 組織各單位協作支援資源盤點：
     • 各部門是否有辦法說明部門執掌、作業流程、日常管理及調整作業模式，相關的現狀調查。
     • 各跨部門專案協同作業模式現狀調查。
   • 外部協力廠商人力資源盤點：
     • 各專案組織與外包商協作模式調查。
     • 各保固合約執行狀況調查。
     • 過去異常事件處理狀況調查。

4. 資安合規相關現狀盤點：

   • 資安相關規範清查。
   • 系統及應用程式現況盤點。
   • 對標 ISMS / PIMS / NIST 標準差異調查。

5. 連結數位轉型策略所需資源盤點：

   • 以雲端為中心的行動化辦公室：
     1. 組織網路化與行動化所需資源盤點：
     2. 服務雲端化所需資源盤點：
   • 以數據為核心的數位營運團隊：
     1. 數據整理與重新定義所需資源盤點：
     2. 流程再造所需資源盤點：

6. 施作標準對標業界標準所需資源盤點：

   • ISMS/ISO27001
   • PIMS/ISO27701
   • InfoSec related tools and standard （Zero Trust）
   • Agile related tools and standard
   • Operation support tools and standard (MIS, DevOps, SRE)
   • ITSM

7. 對齊數位轉型專案解決方案目標, 相關調整所需資源盤點：

   • 制度規範面。
   • 各部各級專業人力需求面。
   • 預算。
   • 新專案帶來的排擠效應，各個現行及規劃專案優先度調整帶來的影響。

8. 近期組織施行中及計劃中的專案跟數位轉型專案整合可能性及相關所需資源盤點：

   • 舉例參考：
     • 跟國際總公司合作的專案。
     • 辦公室遷址，新大樓辦公室及機房建置案。
     • 因應稽核查核事項需進行的大型調整。
     • 新的緊急應用系統解決方案的調整。
   • 數轉專案是否可以同步將這些需求進行整合規劃。

9. 從風險的角度切入，對以上盤點的結果進行風險評估，列出風險待辦事項，及排序處理所需的資源盤點：

   • 新舊架構應該如何漸次移轉，如何處理移轉中造成的風險。
   • 如何將新的標準架構漸次導入，如何處理流程作業需要配套的調整。

Tier Two：

會需要數轉專案發生，簡單說就是原來的工作慣性無法達到新目標的需求，走舊路不會到新地方，工作方式的調整是一定會發生的，以上 Tier One 主要是盤點事情，Tier Two 要盤點的是從事情中找出對應的作業流程，再來是作業流程往上對應的人跟制度。

1. 組織面上：
   各部執掌的責任範圍現狀，專案中需要配合的責任範圍釐清，及配套調整的異動需求盤點。
2. 業務面上：
   工作流程各個節點、產出、負責人相關定義及假設釐清，專案中作業流程需要調整配合的角色及能力需求釐清，及相關必要調整的異動需求盤點。
3. 資訊面上：
   工程單位軟硬體支援能力，及異動需要的資源調整盤點（如：教育訓練與人員汰換作業）。
   因為專案需求及未來組織支援需要，必要的組織架構調整資源需求盤點。
   配合新的SOP所需的資源盤點。
   舉例：除了工作流程照已知理解的，跟目標需求相關的配套調整，是否有需要加入合規需求或標準導入的考量，是否有足夠相關專業人力進行長期專案支援？
   風險評估，列出風險待辦事項，及排序處理所需的資源盤點。
   相關的專業人力需求配套措施？

Tier Three：

這一階段主要是階段性的盤點複查，根據盤點發現事項，及盤點過程中，專案需求的相關調整作業。

1. 收斂資源盤點作業，結果產出確認及因為發現事項需要進行的專案相關調整。

   • 盤點作業照經驗不會一步到位，第一次的結果也通常是需要再覆核調整的，需要定義一個一到三個月的定版計劃，週週進行有效產出，一方面是回覆數位轉型委員會專案進度，一方面是讓治理面及管理面的資源有辦法協作進行配套調整。
   • 反應因應盤點查核事項中，專案執行可能會面臨的風險，如專業能力不適任的員工或主管，組織結構需要進行的調整（如：教育訓練，組織調整）。

2. 經盤點，通常會發現管理認知跟現狀的落差，所以要同時進行專案各個負責人的責任範圍釐清，大型長期專案最怕的就是一堆風涼話的看官（假專家），要確保對應專案相關負責人有被指派及授權，這樣專案管理才有辦法落地。

3. 進一步進行專案目標收斂，照經驗第一次產出的專案目標應該是有蠻大的再聚焦空間的。