IT的流程和實踐就是IT完成工作的方式。而那里就是你體現能力所在的地方。
本系列的前一篇文章談到了“改進”IT流程和實踐的重要意義。現在的問題是，作為首席信息官，你究竟需要將個人注意力集中在其中的哪一個上。
答案就從這個基本原則開始：管理者個人發起的變革倡議不應該同時超過三項。超過這個神奇的數字，你就會失去專注的能力，并進而失去領導的能力。
但是首席信息官應該選擇哪三個呢?
不應關注的內容：IT運營
組織流程改進計劃最明顯的候選方案就是著名的ITIL框架。但那可能是一個錯誤。
采用ITIL框架本身并不是一個錯誤。這是一個完美的框架，它背后是幾十年的成熟經驗。ITIL的重點是IT運營。而IT運營只有在出現問題時才會被注意到。作為首席信息官，當事情進展順利時，你也會希望被注意到。
因此，如果你的IT組織需要更好地進行可用性管理、容量管理、性能管理、基礎架構生命周期管理、系統管理，尤其是變更管理時，請確保你有合適的人員來負責IT運營，并明確表示你將通過唯一重要的IT運營指標(不可見性指數)來衡量他們的成功，也就是說，當IT運營沒有被注意到時，你必須是唯一一個能夠注意到的人。
作為首席信息官，你應該認識到，雖然IT運營非常重要，但它一點也不具有戰略性，而且，如前所述，如果它做得不好，你也就不能具有戰略性。
委派它，并確保你委派給它的經理擁有他們所需的所有工具和支持。
流程優先事項1：服務臺
如果IT的聲譽(這也是IT的全部聲譽)不太好，修復服務臺就應該是你的首要任務。
服務臺是IT的紅發繼子，這是不幸的，因為IT與業務其他部分成功集成的一個關鍵因素往往是業務/IT關系的質量。
IT與其他業務的關系在服務臺總是時好時壞。因此，如果你聽到它被稱為“無助的服務臺”，或者如果你的業務伙伴問你，為什么在他們打電話給服務臺讓他們知道之前，IT不知道系統已經關閉，或者如果你聽到了服務臺工作人員在交換愚蠢的用戶故事，或者如果有人在打電話給服務臺尋求快速簡單的幫助時，服務臺只是給了他們一個號碼--請選擇你的故障，而不是給他們立即需要的10秒鐘的答案，如果服務臺表現出了這些癥狀，就請將你的個人注意力放在修復服務臺上。
讓IT組織的其他部分發光所需要的業務支持也依賴于此。
流程優先事項2：應用支持
規則1：如果你的應用程序支持團隊仍然沉浸在瀑布式的方法當中，你還在等什么?立即讓他們開始轉向敏捷吧，并親自監督敏捷采用戰略及其執行。
規則2：敏捷不僅僅是Scrum。為IT實際做的工作選擇合適的敏捷變體，而不是因為“每個人都在使用它”而選擇Scrum。
規則3：大多數敏捷變體都是為了管理應用程序開發而設計的。大多數人都是“在可以的時候進行購買，只有在必要的時候才進行構建。”如果你也是這樣，就請完全忽略Scrum。相反的，可以讓你的應用程序團隊采用CRP(會議室模擬)或是其近親ATDD(驗收測試驅動開發)。
規則4：大多數敏捷變體專注于將軟件作為產品來進行交付。多數企業都需要IT的合作來實現有目的的業務變革。修改你所采用的任何敏捷變體，然后使之成為現實。
流程優先事項3：IT架構管理
我們將在本系列的下一篇文章中介紹如何評估IT架構本身的質量和卓越性。如果它很糟糕，那當然是IT架構管理實踐失敗的征兆。
你的IT架構管理實踐需要幫助的其他跡象是什么?
“我們不知道我們的架構有多好，”這是一個令人驚訝和沮喪的常見癥狀。就這一點而言，“我們不知道我們擁有什么”其實并不罕見。
還有什么?它沒有：
•發布并公布了一份簡短的--簡短的意思是不超過十幾條--指導其他一切的架構原則列表。除了簡短之外，這些原則還必須用簡單、無術語的語言編寫。
•出版和公布一份標準清單，其內容如下：基于原則;根據記錄良好的實踐保持最新;并定期進行更新--每季度更新一次是有意義的。
•將生命周期管理確立為標準實踐，將其集成到IT規劃和預算當中。
•圍繞體系結構原則和標準制定一個云戰略，圍繞著云是一種體系結構，而不是存儲和處理中心這一認識。
這并不意味著，如果IT架構沒有這些缺陷，那么實踐就可以安全地進行了。
IT體系結構實踐——以及它的業務集成，企業體系結構實踐——一直都面臨著從增加和維護價值到變成官僚主義泥潭的持續風險。
順便說一句，這種危險并不是架構所獨有的。任何被授權審查和評論其他團隊創造性工作的企業和組織都有著同樣的風險。
頂尖的架構需要一種反官僚主義的心態。并且它還需要資金，因為交付一個具有令人滿意特性和功能的應用程序項目比交付一個符合架構標準的具有令人滿意特性和功能的應用程序成本更低。
由于你的一般執行發起人不太可能愿意承擔差額，因此提供或修改應用程序功能的項目將需要架構來彌補這一差異。
IT架構管理職能部門必須找到一個能夠實現健康架構的方法，同時最大程度地減少使用強制執行來作為其主要策略。它還必須能夠說服行政領導，一個好的架構也是一項明智的商業投資。由于這兩個至關重要的問題，你將很難逃避這樣的結論：即使在最好的情況下，作為首席信息官，你也應該親自去監督IT架構團隊。
但是信息安全呢?
在當今這個時代，與IT相關的業務威脅正越來越多地受到有組織犯罪和惡意國家行為者的支持，入侵的潛在損害在很久以前就從“惡化”發展到了“巨大”，信息安全必須成為IT的首要任務之一。但是，與IT運營類似，信息安全的有效性也是通過其自身的不可見性指數來衡量的。
更糟糕的是，要想變的有效，信息安全必須是侵入性的，所以一定程度上的不可接受的可見性會隨著地域而變化。
還有一點：沒有與高質量的IT架構緊密結合的信息安全也是有漏洞的信息安全。
因此，需要將信息安全納入到你的IT架構實踐中，作為首席信息官，你可以關注信息安全，但它不會進一步的分散你的注意力。
解決IT創新問題(又稱“數字化”)
看看創新的商業機會是在哪里發生的，你會發現IT即使不是頭號競爭者，也肯定是前三名之一。
作為首席信息官，你在這里的選擇要么是負責IT創新，要么是接受在執行領導團隊中增加一名首席數字官的想法。
但那將是你的一種不稱職的宣告。此外，這會把IT領導層一分為二，CDO將成為創新者，而你則總是會成為那個否定者。所以“首席信息官”將成為你退休計劃的一個陳述(“職業生涯結束了”)。
我們不會想要那樣做。
相反的，要將IT創新也納入到IT架構實踐當中。這樣做不僅為創新提供了一個組織的家，使其不會分散你的注意力，還將創新的責任放在了與將IT創新集成到IT體系結構其余部分的長期需求的相同位置之上。畢竟，你不會希望IT創新成為未來的自動化孤島。
如何處理“DIY IT”
自己動手的IT，也叫“影子IT”、“流氓IT”和“停止吧!你在給我一個頭痛的IT!”這是太多首席信息官竭盡阻止的事情。
這就類似于國王Canute在命令潮水不要進來。
不管怎么說，DIY IT更多的是機遇而不是問題，因為它在不增加IT支出的情況下大幅增加了公司的IT帶寬--或者至少增加了可見IT的支出。
DIY IT的缺點在很大程度上是可以避免的。大多數情況下，它需要IT在技術咨詢方面提供一點點支持，以確保它符合IT的架構標準，而作為交換，IT架構的職能部門將獲得所需的文檔，以防止DIY IT變的隱蔽。
這使得對DIY IT的支持將成為又一個能夠舒適地融入IT架構功能的IT實踐。
最后
為了使IT能夠勝任，它必須使用精心設計、定義和記錄的流程和實踐來完成其工作。首席信息官應對所有的這些問題負責，但在實踐上，一個人是無法同時指導三個以上的轉型的。
在大多數的IT組織中，最需要首席信息官個人領導的三個流程領域是服務臺、應用程序支持和IT架構管理。把它們打磨得閃閃發光，IT就會成功--而且會獲得明顯的成功。
但這只有在IT運營同樣出色的情況下才能實現，這就是為什么，有一點自相矛盾的，首席信息官們應該確保將這一責任委派給其他人的原因。因為如果你做不到這一點，你也就沒有足夠的精力來打磨這三件大事。
版權聲明：本文為企業網D1Net編譯，轉載需注明出處為：企業網D1Net，如果不注明出處，企業網D1Net將保留追究其法律責任的權利。
京公網安備 11010502049343號