建立起有效的 IT 流程百科：流程很重要，但其中有某些流程的重要性比一般的更高；本文的內容希望協助讀者成為能夠掌控局面的 IT 領導者。
文／Bob Lewis‧譯／潘得龍
在《Keep the Joint Running: A Manifesto for 21st Century Information Technology》一書中提及的第七項原則指出，在制定策略之前，決策者本身必須要能擁有足夠的基本能力。本文則將重點放在資訊長所扮演的角色內容，也就是身為資訊長所需要聚焦的部份。
這項問題的答案，得從一項基本原則開始：「管理者從來就不該讓自己負責超過三項變革創新的任務。」超過這個神奇數字，就會喪失聚焦的能力，然後隨之亦失去領導能力。但身為資訊長，應該如何選擇那 3 項優先的變革項目呢？
不該將重點放在 IT 基礎運作上
對企業組織而言，針對流程本身效能的提昇工具，最廣為人知的方法，就是 ITIL 架構，不過往這個方向思考是錯誤的。
這並不是說，採用 ITIL 架構就是一種錯誤。ITIL 是一種非常好的架構，已經發展了幾十年的時間，相當的成熟。不過 ITIL 的重點是 IT 的運作，而 IT 的運作只會在有問題的時候，才會被特別留意。但資訊長的角色，應該是假設在一切都正常運作的情況下，要進一步留意未來的發展方向。
[ 2022年度CIO大調查報告下載 ]
所以如果貴 IT 單位所需的是更好的可用性管理、能力管理、效能管理、基礎架構生命週期管理、系統管理，以及特別是變革管理，那麼請資訊長首先要確定的是，能夠找到正確的人，接替管理 IT 的基礎運作，接著清楚地建立起衡量 IT 運作的重要管理指標。而資訊長應該要注意的，則是在這些 IT 運作的更上一個層次，也就是所謂的不可見指標。
身為資訊長，應該要能理解，IT 的日常運作固然非常重要，但這些日常性工作，並不歸屬於策略層面。因此正如前面提到的，除非基本的運作做好，不然就沒有資格談策略問題。將 IT 的運作委託給一個正確的管理者，並且確認所委派的管理者有足夠的工具，並且能夠獲得充分的執行授權。
第一優先流程：服務支援系統（help desk）
如果企業組織對 IT 部門的風評不好，那麼負責守住第一線的服務支援系統，就應該是資訊長第一優先要處理的流程。不幸的是，服務支援系統相關人員可是 IT 部門中不受歡迎的職缺之一；但它卻是 IT 成功整合其它業務，並提供企業業務與 IT 關係品質的關鍵因素。
IT 部門與企業組織中其它業務單位關係的成功與失敗，可說是取決於服務支援系統上。所以常常能聽到像是「毫無作用的服務支援系統人員」，或是企業的其他部門質問為什麼 IT 部門不曉得某某資訊系統功能異常，然後還得打電話給服務支援人員讓他們知道。另外像是聽到服務支援系統的人員互相傾訴使用者的愚蠢經驗為樂；或是當有人尋求服務支援系統的協助時，所需要處理的事情是一些能夠快速而簡單處理就能解決的，但服務支援系統卻給他們另一個聯絡電話，而不願意花 10 秒鐘的時間回覆能夠立即解決的問題。面對這樣的情況，如果發現服務支援系統本身能力不足，就需要資訊長的關注，以及提供所需的協助，或是進行一些調整。
資訊長需要相關的業務支援，才能協助 IT 單位閃閃發亮。.
第二優先流程：應用程式系統開發支援
規則一：如果貴公司的應用程式開發團隊，仍然習慣採用傳統瀑布式開發方法，那麼還在等什麼呢？馬上開始讓開發團隊轉移到敏捷式開發法吧！然後就能很快感受到採用敏捷開發策略的差異。
規則二：敏捷開發並不是只採用 Scrum 軟體而已，想要真正協助進行開發工作的 IT 人員，應當選擇正確的敏捷開發方法，而不是直接選擇採用 Scrum，只因為「這是大家都在用的東西」，其實不一定適合貴企業。
[ 加入 CIO Taiwan 官方 LINE 與 Facebook ，與全球CIO同步獲取精華見解 ]
規則三：各種敏捷開發工具，大多是針對管理應用程式開發所設計；其中大部分的 IT 單位會購買，是因為可以容易買到，而且也只因為他們必須使用而購買。如果這情況已發生在貴公司，還請直接完全忽略 Scrum。請讓貴公司應用程式團隊改採會議室測試（Conference Room Pilot, CRP）或類似的產品，如驗收測試驅動開發（Acceptance test-driven development, ATDD）等。
規則四：大部分的敏捷開發相關產品，重點都是以提供商品的方式提供軟體，但大部分的企業情況，則是需要 IT 團隊的協助，才能達成企業原本設定的變革目標。因此不論採用那種敏捷開發產品，都必須修改成適合個別企業組織的工具，才能發揮效果。
第三優先流程：IT 架構管理
在本系列的後續文章，將介紹如何評估 IT 架構本身的品質，以及如何達成優異表現。如果 IT 的架構不良，當然會讓企業產生與 IT 架構管理執行問題的徵兆。
還有什麼其它 IT 架構管理方式的徵兆是值得注意的呢？一般出現令人驚訝或沮喪的共同情況，就是難以評估目前採用 IT 架構的良莠。針對「不曉得敝公司出現了什麼異於常人之處」的情況，有什麼可以做的嗎？其實 IT 團隊可以進行以下判斷：
- 列舉已經發行以及公開的簡要架構原則清單，能夠提供必要的指引。而所謂的簡要，就是不要囉哩囉唆一大堆。公開的原則如果過於繁瑣，就必須將原則重寫成簡要內容，而且能清楚表達的語句。
- 已經發行以及公開的清單內容標準包含了：基本的重大原則、依現有狀況做為基礎要求且具備完整文件的執行方式，並包含定期更新清單。
- 建立起讓文件生命週期管理成為標準化的習慣，並且讓 IT 計畫與預算能夠連動。
- 設定雲端策略，並融入到企業組織 IT 架構原則及標準當中；了解雲端是一種架構，而不只是儲存與運算的技術而已。
此外要記得，如果 IT 架構沒有漏洞，並不表示實際上系統就能安全無虞。
IT 架構的運作，是配合企業相關的業務執行；而企業的架構運作，一直都是面對風險，以不斷地維持和增長自身的價值，並且避免成為僵化的官僚系統。
順道一提，這樣的危機，並不只存在於架構中。任何企業組織，只要去檢視和批判一個團隊的創造性工作，就會看到類似的風險。
主管要具有反官僚的心態，並且需要投入相當的資源。因為要提供一般滿意特性與功能應用程式的專案成本，會比那些必須配合組織標準架構的應用程式的滿意度特性與功能的成本為低。
但資訊長無法保證，企業大老闆會願意補足短缺的經費。這類提供或是修改應用程式功能的專案，會需要架構經費的補助，才能涵蓋超過的成本。
IT 架構管理功能必須尋找達成健全架構的方式，同時又要盡量避免權威式的管理──這是一種重要的戰術。也就是說，一方面還得說服領導團隊，替企業所投入的資源，建立起健全的架構。針對這兩種重要的觀點，即使在非常健全的企業組織，也很難取得平衡；身為資訊長，個人必須具備高於 IT 架構的全面視野，來帶領團隊。
關於資訊安全呢？就放後面去？
在目前這樣的時代，針對企業與 IT 所面對的相關威脅，隨著組織性的犯罪以及惡意的攻擊者與日俱增，所可能造成的威脅，從以前逐漸「增加」的入侵，到目前已經對資訊安全造成巨大的威脅。因此，資訊安全當然也就成為 IT 管理的的最高優先選項。
但是，與 IT 應用程式類似的是，資訊安全的有效性，必須根據企業本身所發展出的一套不可見指標，才能真正有效衡量。而更壞的情況是，因為要能夠有效，資訊安全的管理會對使用資訊資源的單位，造成某些侵入式妨礙。而不同層級的不可見性指標，就會進入到不同領域中。
此外還有重要的一點，資訊安全並不代表從此就能夠提供高品質 IT 架構；也就是說，這兩者之間是沒有耦合性的。資訊安全的管理，可能會給其他單位帶來不便。所以如何整合資訊安全與 IT 架構，在執行方式上，資訊長應該要具備足夠的高度和觀察能力，才能全盤掌握。
如何面對 IT 的創新和數位化
觀察企業的機會在那裡，發現可以在那個領域投入創新，然後找到對應支援的資訊科技。這樣的角色，如果不是高階主管，也一定是屬於企業組織結構的頂層之中。
資訊長在此處的角色，要就是直接負責 IT 創新；不然就要另外新設「數位長」（Chief Digital Officer, CDO）角色來帶領這部份團隊。但這樣將會對此部份，造成外界某種不適當的印象。此外，也可能將 IT 領導的角色分成兩個部份，其中數位資訊長會成為地下指揮；而資訊長，則會變成喜歡說「不行」的專家。但如此一來，資訊長就會變成為退休計畫的一個代名詞（CIO 變成 Career Is Over 的縮寫）。
別這麼做。
取而代之的是，將 IT 的創新也同樣融入 IT 架構運作中。這樣做不僅可以有助於對組織本身的創新，同時也不會分散你的注意力，也可以將創新的責任放在與長期需求相同的位置，可以整合 IT 創新於 IT 架構的其中一個部份。你不需要，大可不必，讓 IT 創新成為只是某種自動化的代名詞。
資訊長該如何處理「DIY IT」？
DIY IT，通常也被稱為「影子 IT」、「流氓 IT」或「停！你讓我頭痛 IT」，是一種讓許多資訊長跳腳的情境。
面對這種情境，資訊長就活像 11 世紀的英格蘭國王 King Canute，在海邊舉起手想阻擋潮水，但海水仍舊滾滾而來。
不管如何，DIY IT 所帶來的機會比問題多，並且也能大量增加公司的 IT 能量，但不至於增加 IT 費用──或是至少在帳面上看不到這些費用。DIY IT 的缺點是，在大部分的情況下，它需要由 IT 團隊對使用者提供些許技術諮詢支援，以確保能夠盡量符合 IT 架構的標準。在這樣的作法之下，可以建立起相關管理文件，讓 DIY IT 不至於全面演化成地下 IT。
這樣一來，採用 DIY IT 反而有助於輕鬆融入 IT 架構，進而提昇 IT 服務能力。
綜合總結
要讓 IT 團隊能夠扮演好自己的角色，就必須要妥善地設計、定義以及記錄流程和方法所需的文件，在文件的規範之下完成相關的工作。資訊長是要對所有這些內容負責，但一個實際的作法，就是資訊長自己不能親自指導超過 3 個以上變革方案。
在大多數 IT 團隊裡，資訊長最需要的三種流程領域，分別是有效協助服務支援系統以提供優異服務、對應用程式開發的支援，以及良好的 IT 架構管理。讓這幾個系統發光發亮，IT 團隊就能獲得顯著成功，並被所有主管與員工看到相關成就。
而這種美好情境，只有在 IT 的基本運作也處於順風順水狀況的前提下發生，造成以下兩種情境看起來似乎是矛盾現象。資訊長一方面應該確保委派人員的工作品質，確保底層的架構運作良好；另一方面在同時間也要讓自己保有時間和專注力，來綜觀全局。
如果不採用這種作法，那麼資訊長很難產生足夠的能量，來做好這三件最重要的事情。.
(本文授權非營利轉載，請註明出處：CIO Taiwan)
