前言:

組織日漸龐大，但如緣起章節所述，運作效率及服務品質卻每況愈下。於是新任董事長，一改之前該組織習慣依賴資深者經驗運作的方式，帶領新任的董事成員們對組織進行現代企業常規性的企業現狀盤點跟風險評估作業。為改善組織韌性，將組織從傳統的經驗口耳相傳、紙本作業的運作模式，轉換為利用現代數位化工具建立起的現代企業數位骨幹。為達到現代化人機協作模式的目標，從工具、環境到文化一步步調整組織的健康狀況，建立起現代化組織運作模式。
以下是該組織數位轉型需求的初衷，也以此期望符合社會期待。

初期目標，著眼現代化企業常規的營運優化要項：
    - 簡化組織結構
    - 提升決策效率

Situation

這裡我們針對該組織數位轉型前，從硬體到軟體到文化狀況的進一步背景說明：

1. 使用者終端環境:

雖然有幾乎人人有電腦，但電腦極度老舊，電腦跑個 MS Teams 會 crash 應該是不可以接受的吧？可是換個角度，如果該企業原生文化就如緣起所述的悠閒生活，且該組織各階主管視為理所當然，這好像也就不奇怪了。
(這不是笑話，當電腦升級改善工作環境時，筆者團隊面對極大的挑戰，極高比例的資深者反應及投訴，筆電造成數位恐懼、改善網路連線品質是意圖以不正常方法迫使他們多做工作，造成工作壓力。可是好笑的是，投訴時，用筆電跟網路就沒有恐懼了，投訴完，發現我剛剛竟然會用筆電聯網投訴了，好恐怖，是這樣嗎？)
*** 資深管理階層跟資深員工，因原先的工作慣性，面對改變的非理性抗拒程度，是建議每隻負責數位轉型的團隊要放進考慮的。 ***

2. 組織網路狀況:

該組織雖然有網路，但連結總公司及遍佈全省的支部的網路架構設計老舊，頻寬只是證明你有網路的存在，每年的維護成本跟效益不成比例。重複前言，這些設備，都只是用來證明員工有要做事，但都是環境有問題，所以無法有效率的產出。資訊單位淪為背鍋的單位。

3. 溝通：

組織原本運作溝通以老闆指示為主，輔以電話及會議溝通，電郵及即時通訊軟體之類的解決方案受限於前述人員對電腦操作的不熟悉，及網路資源匱乏的狀況下，淪為點綴工具，所以得知，該組織沒有架設常規性的組織溝通模式及管道（ex. Teams），也缺乏對工作進度進行管理的工具（ex. Jira）。

4. 管理層：

組織核心單位，過去整體高階團隊的經驗僅能執行常規性作業，缺乏現代化管理經驗，對新事物的學習也持＊極端保守＊的態度。若非新的董事會意圖大破大立，其實既有的高階團隊的管理者都是極度抗拒數位轉型專案的，雖說是人性，但是也很讓人理解數位轉型是步步艱難啊...

5. 資訊部門:

雖然有資訊部門，但是大多數原生資訊部門成員都已面臨屆退狀態（身體健康及心態上都無法面對有壓力的工作環境，如新的數位轉型專案），且原生團隊雖有著業界平均最資深軟體開發團隊的美譽，但其實不具備現代化軟體工程基礎知識，導致系統支援需要的軟實力嚴重缺乏（連Git都沒聽過，六個月的訓練後還是無法進行 regular code commit，有沒有看過防火牆是 default allow？更不用說防火牆被改到原廠都無法找出為什麼設定吃不進去，搞了幾個月，最後只好一台換一台），無內部服務開發能力，也無系統設計能力，就算進行外包，也無法提供進行有效評估、簽約、外包、協作、驗收及後續維運的工程專業，以致系統服務品質低劣。另一方面，原生資訊團隊因受限於知識匱乏，所以企業資訊相對應的年度專案跟預算規劃，也無法配合需求進行配套作業，年度程序都是形同虛設，高階管理團隊也是無法當責，只是行禮如儀，過個場而已，導致專案要進行時無對應資源可用

6. 機房:

雖然有機房，也有門禁，但同時也有無管制後門可供各部門隨時進出，詳細原因得知門禁只是應付稽核所設立。機房形同虛設的狀況下，溫濕度、電力、監控、災害防護的品質可預期的不穩，所幸系統還尚未出明顯大問題（重啟還是可行的），核心數據資料出錯的頻率還在人工可以補救的程度（年度財報資料東拼西湊還是湊得出來），但每次服務出問題，要修復的時間無法預期，是否可修復無法掌控，是否可以針對出問題的部分進行修正，進行改善更是未知數。
然而也跟第 5 點外包管理相關，平日雖服務有外包商保固，但服務的品質堪慮，因原生資訊團隊不知道如何與外包商合作，所以對應的合約也沒有辦法保護組織的利益，沒有人當責確認真正目標有被確實達成。除了問題解決是個問題外，更不用說因為這樣進一步衍生的成本跟費用。

7. 系統版本更新:

該組織有著微軟博物館的美譽，筆者也有點年紀，初入了解系統群的時候，彷彿人生跑馬燈。大部分的系統都是處在原生狀態，系統十幾年以上沒有更新是常態，上面的軟體因各式各樣的原因，廠商不保證系統更新不會出事，照原生的企業文化，只要有理由就可以再討論，這一討論就是一年一年過去了，廠商更新報價一年比一年高，久而久之，沒有人要負責，就不更新了，大部分的系統都是用到廠商建議買新的，就買新的，然後舊的還是放在那邊，原來的外包商維護人員退休後，就沒有人敢去動它了。

8. 軟體開發：

因各個系統是在不同時期，由「各單位」自行找外部廠商開發，並非資訊單位決定，所以系統整合度為零。由各部門人員配合各個系統後台所需，如緣起章節所述，人工作業調整維持資料以維持各系統運作所需。核心系統要進行的調整時，往往都是非產品或系統當責單位負責人提出需求，而是單點員工要求原生資訊單位成員進行單點功能修正，也因此在沒有考慮整體作業流程跟數據流的正確性下，導致系統及數據越來越亂。如此破碎化的資訊系統環境，進一步加深員工的負擔，導致錯誤率越來越高，再導致加人加資源，組織營運成本進一步增加，新加入的同仁也因為沒有被教導正確的系統認知，同步增加了協作的複雜度，既有環境並不具備協作的基礎，導致增加的人員並沒有帶來預期的解決效益，最後回到對資訊部門抱怨的惡性循環。

9. 軟硬體外包商:

外包商的品質問題，當時台灣本土外包商人員異動頻繁，同因上述無有效系統驗收、文件及互動協作模式(ex. Ticket tracking)，導致系統問題無法有效解決(挖東墻補西牆)，極度仰賴人工處理(廠商人工介入要收費，又導致額外的成本發生)，配合的國際外包商也同因人員異動頻繁，導致系統維運支援合約形同虛設。
從無法進行系統功能開發、到緊急事件處理無法在合約討論的時效內完成、到事件處理錯誤導致更大的問題發生、到年度維運無法提供報表說明所需的系統更新及調整程序是否已經完成。
縱所前述，該組織的軟硬體供應鏈內外部同步失效，這邊舉個實際的例子，照合約雲端的系統備份應該是每年要驗證一次，筆者團隊入職後，要求原生團隊跟台廠外包商照合約進行系統備援切換作業，驗證後交接，遭到原生團隊跟外包商以各種藉口拖延，結果證明連備份都沒有備份完全。更遑論進行系統服務切換，給外包商兩個月的時間進行修正，外包商直接棄權，該合約從頭到尾都是無法正確執行的狀態，但合約屢行的金額是照實給付，原生資訊單位負責人也不覺得有任何問題（不是有隨身老爺爺加持就沒事，故事裡那都是假的），這邊也藉此說明為何董事會要求起此專案，因為該組織運作上，資訊部門執掌的部分已經失效了。

10. 資訊部門的上下游部門狀況:

以筆者團隊入職時的狀況，沒有任何一個部門可以提供完整正確的作業流程，各個部門的定義跟理解都有顯著差異，在溝通上也不太確定大家都是在說中文還是外星語，自說自話是常態（我不管你懂不懂啦，反正我自己是懂了，自豪，這麼複雜的東西我都說得出來，給自己鼓掌），基本上就是要重頭盤點起。

以上的說明，不是要分享當初筆者團隊多可憐，是在這樣的狀況下，還是可以改善的，但是要怎麼改善，專案要怎麼設定目標，階段性進程的價值產出要著眼在哪裡，才是要討論的，不要老是談高尚大虛無飄渺的未來，既然問題這麼大，從人腦到機腦都當掉了，就不可能期望重開機就一瞬間就把這20年延宕的時光消除，既然決定要重開機，第一部討論怎麼重開機可以開的起來才是對的第一個問題吧，系統可以 reboot，才有改善的機會，不然動一下就葛屁了，那基本上就不能動了，要怎麼找到重啟，步上改善的軌道，是治理面第一階段要凝聚的共識。