今天來聊聊在數轉前還需要做的一件事情「工程定錨」，以下是以組織過往的故事來看看何謂工程定錨，要處理的是什麼面向？

Situation

• 如前面章節所述，當專案目標跟執行架構都定義完也啟動後，我們進行了現行作業流程、配套系統跟環境、相關數據、負責單位、負責人、及相關制度的盤點，在進一步拉近組織管理現況認知，跟實務面組織運作狀況的差距，另一個面向上來說，我們也是同步要找出現行流程架構的限制，避免專案目標不切實際，也防範一些看官（假專家) 的風涼話(如 MOMO 都可以，為什麼我們不可以..等等)。
  另一方面，也要破除一些認知錯誤的問題，會啟用數位轉型這個專案，就代表原先的運作模式應該是有落差，無法達到組織想要達到的目標，那為什麼會這樣？管理會議不是都有開嗎？細想一下，這些主管真的會即時反應組織的問題嗎？他們真的會跟大老闆說他想要的其實做不到嗎？所以需要之前的盤點跟再溝通，讓大家的認知一致，因為因應數位轉型的異動要開始了，筆者團隊過往的經驗，如果沒有釐清這一段，一開始異動，就會有人說這問題以前都沒有呀（真的嗎？發誓喔，天打雷劈那種喔，敢不敢？），這問題都是轉型帶來的呀，所以照筆者團隊經驗，現況認知釐清，目前限制釐清（可以做到的事）是非常重要的一步。

• 另一方面，既然專案要開始了，我們要先做到這些異動不會造成不可承受的影響（裁員不要裁到大動脈，系統更新不要毀了服務），工程維運的起手式，如備份是否有落實，各服務異常時的影響跟可容忍時間，大家要把遊戲規則先說清楚，不然光救火背鍋就可以把整個專案搞垮了，所以工程單位要確保每次的異動，在解決方案跟數據層面上，都有妥善的過版(release)及異常回復程序(rollback)計畫，最不濟，備份也可以上場救援，先求服務不死，再求進一步優化。

  • 舉例說明，當初盤點時，關於客服系統，CEO 在高階主管會議上說，客服系統不影響主要服務流程，就算當一天也無所謂，但是隔兩天，系統就真的出事了（真的不要亂立Flag…），一個鐘頭後，CEO 就爆了，每次處理類似的專案都一樣，總是有人以為他是義和團的，刀槍不入，火裡來、水裡去，沒問題的，然後就上桌被當菜吃掉了。

• 再來是既然我們要前進了，那有沒有是以前沒考慮到，考量不周全的，因應未來挑戰的，可以在這次的改進計劃中同步解決，所以可以在前述章節中，看到一些標準（ISMS、PIMS、BCMS、ITSM、NIST）的相關要求，有些是組織期望要做到合規的，有些是借鑒標準來改善組織內部架構的（再說一次，假專家真的超級多的，不然就不會歪到這種程度了），另外在企業責任上，組織有符合社會期待嗎？是不是同步要改善這些認知，在體質改善的同時，一步步對齊現代的價值標準，因為這樣，我們有哪些事情要同步進行？

  • 舉例說明，因組織特性，當初有問一個問題，當一個人捐款 100 元時，他可以知道他的 100 元去了哪裡了嗎？大家都說可以，但是從資訊架構跟數據結構上來看，這是不可能的，因為目前架構的維度就是在專案的層級收斂，捐款專案跟資助專案的關係也不是簡單多對多的關係，這就很典型，管理認知跟現況的差異，那我們在此專案要做到這一步嗎？照資源盤點找出的限制來說，這跨度太大了，缺少的資源太多了，所以比較現實的是，我們在這一專案應該是要把目前的架構跟數據資料清洗跟整理，配合各責成單位進行下一代架構討論，要回答這個問題要以現狀去整理適切的回答方式，所以這邊就會多出一個未來要解決的標準。

• 這邊列出相關考量的標準供大家參考

  • 該組織的專案場景

    • 以雲端為中心的行動化辦公室（數位賦能）
    • 以數據為核心的數位營運團隊（數據應用）

  • 配合預設成功場景，從使用面、服務面、安全面考量要做的事項，整體思路可參考 ITIL v4 標準發想。

  • 使用面

    • 為減少維運的難度，使用者的終端設備應該要統一幾種規格，並跟供應商簽好適當的支援合約，以改善服務效率。
    • 內部服務存取應該是僅限組織成員，管控設備，在允許的時間存取等，這邊標準可以參照 NIST Zero Trust 標準發想。
    • 統一全組織溝通平台及協作工具，如導入 MS O365 解決方案。
    • 資訊部門因應專案管理跟服務品質改善，可參考 Agile, Scrum, Kanban, DevOps, SRE, DORA 標準發想。

  • 服務面

    • 常規性的基礎服務監控有沒有到位？
      • 基本監控，如服務使用量異常（CPU, MEM, DISK, Network ... etc）。
      • 使用者行為異常，如異常存取，半夜不睡覺在工作？早上在台灣，晚上在美國？防火牆不通的，你現在通了？客服單位成員要存取管理者帳號？這邊一些標準落實可以參考 ISMS, PIMS 標準發想。
    • 數位韌性（起碼服務要不能陣亡，不要創造更多的問題）
      • 備原架構設計（從系統、網路、應用程式、數據，分暫存、長久儲存，跟即時、批次，本機、地端、遠距等備份模式進行考量），這邊一些標準可以參考 BCMS 標準發想。
      • 異常實時監控
        • 如程式配套的 log, 異常即時處理程序, Alert, 可參考可觀測性標準發想。
        • 使用者作業模式，盤點系統服務功能是否合宜，如大家共用帳號，所有資料都可以一鍵下載，這麼友善的系統目前已不多見了，在系統及流程改善前，這些異常行為有沒有被監控。

  • 安全面

    • 通常傳統組織在資安落實上是比較薄弱的，在導入資安維運程序並進行與一般常規程序同步整合時，可參照以下標準發想。
      • NIST Cybersecurity Framework
      • PCI DSS
      • ISMS
      • PIMS
      • CIS control
      • GDPR
      • CCPA
      • DPA
      • Zero Trust

• 其他還要一些比較 operation 對應標準異動

  • 如組織採購程序配合專案該如何在符合規定下，考量效率，進行配套調整。
  • 人員考核標準跟汰換程序相關的規定是否合宜，如何進行配套調整。

• 這邊要說明的是，在確保服務不會在異動中陣亡的目標，其實不是僅僅把現狀保存下來，而是如何正確的保存下來，參考這些標準就是要做到怎麼正確的保存下來。
  舉例來說，過去的系統也有做備份，但僅有一種備份方案，檢查後，復原程序要三天，因為系統的承載力跟空間無法有效配套，這就是個非常不切實際的備份作業。那 ISMS 的資訊資產盤點跟風險評鑑，就可以提供一個可借鑑的方法，去定義我們怎麼看這件事，這就是列出這些標準讓大家思考，異動開始前，我們要怎麼做到可接受風險，才確保我們已經進行適當的遊戲備份了，起碼出問題，我們還可以從備份點開始，不會被打回新手村。

以上是相關 Situation 分析，其實談到大多是維運面向，並且方向相當多元，大家可以想想為什麼...
後面，我們明天繼續囉，
to be continue...