華爾街日報》現代企業依舊需要IT員工，不過是時候裁撤IT部門了

沒有人是一座孤島。IT部門（即資訊技術部）也不例外。

儘管它們通常肩負著使命，要在企業上下引領創新，推動數位化轉型，但IT部門的主管，即首席資訊官（CTO）時常淪為「孤島」的管理者。只需看看任何一家公司組織架構，你大概率會看到IT部就像是一個長方形的盒子，不僅管理層級自成一套，預算也是單獨的。

本文為風傳媒與華爾街日報正式合作授權轉載。欲看更多華爾街日報全文報導，請訂閱特別版華爾街日報VVIP方案，本方案僅風傳媒讀者專屬，以低於原價3折以下之全球最優惠價，即可無限暢讀中英日文全版本之華爾街日報全部內容。

但令人沮喪的事實是，IT部門的存在恰恰會阻礙企業的創新力和敏捷性，還會降低企業對用戶的關注度，也不利於數位化轉型。

之所以如此，是因為IT部門服務的是過去那個時代，它已無法適應如今這個「數位化先行」的世界。我們總愛抱怨IT部門——覺得IT部門的員工和領導活在自己的世界裡，對企業需求反應遲鈍。其實我們不該有這樣的抱怨。問題不在於IT部門的員工或是領導，而是設立IT部門的想法就不對，這導致IT部門注定會失敗。

讓人欣慰的是，眼下有一小批先行者正在拋棄IT部門。它們的作法也為那些蠢蠢欲動的企業提供了樣本。

「電腦部門」

要明白事情為何會發展到這一步，首先要回顧一下IT部門的誕生原因。它最初被稱為「電腦部門」，有著嚴格的後台職能，其任務就是確保組織中的電腦能夠正常運行。

在業務和技術各自為政的年代，這種做法行得通。如今，儘管IT部門或許有了一些炫酷時髦的新名字（「全球數位解決方案」，有人這麼叫嗎？），但如果還是把具有必備相關知識和技能、能夠管理IT的所有員工都集中到一個部門，這種想法就過時了。將IT決策和活動交給一個無論是表象還是實質都與所謂的核心業務相去甚遠的部門，這種做法無異於醞釀災難。

畢竟，技術不再是可有可無的選項，也不再是某種特別的東西；它是保持競爭力的必需品。新冠疫情的出現只會強化一個事實：沒有技術的支撐，大多數組織都無法生存。它與員工的工作深度融合，它是商業模式的核心促成者，是用戶體驗的重要驅動者。

問題起源於我眼中的「合夥參與模式」，當一個獨立的IT部被提升到「業務」合夥人的位置時，自然會形成這樣的模式。雖然乍聽上去十分光鮮——誰不想被視為合夥人呢？——但這種模式將IT看成是孤島上的供應商，受命構建IT解決方案，同時向「陸地」提供服務。然而這不可避免地意味著，衡量IT部的指標通常與業務好壞無關。

試想你是製造業務的負責人。你的職責十分明確：如果銷售團隊交給你一份訂單，你應該結合自己的產能，看看是否有能力完成這份訂單。如果不能，你可以思考一下如何調整才能滿足訂單需求。向客戶承諾的交付日期延遲了？這是物流同事的問題。生產線上出現了劣質產品？這是你需要解決的問題。 （相關報導： 華爾街日報》中國和其他亞太國家啟動RCEP，美國冷眼旁觀 ｜ 更多文章 ）

這種邏輯存在於企業的各個領域。它可能並不完美，但卻很有效。只有IT部門是例外。如果你去問大多數企業的IT部門，問一問企業對他們的衡量標準，答案幾乎都與「投入」有關——他們花了多少錢、有多少系統沒有崩潰，或是有多少項目是按時完成並且沒有超預算的。但幾乎沒有一個答案提到IT部門為企業的「產出」做出了哪些貢獻。

換言之，IT部門在預算範圍內按時完成各項要求——這也是合夥模式真正的設計初衷——與企業成功根本就是兩回事。企業從技術中獲得的價值並不來源於它所擁有的東西。成功並不是打造和管理IT系統。

未來不可測

合夥模式還會假定，企業中的各個部門可以提前好幾個月確定它們到底需要IT部提供何種幫助。制定傳統年度預算過程中的種種要求更是強化了這一假設。若想爭取撥款，必須詳細闡明自身部門的需求，同時還要對項目的持續時間和項目成本作出預估。但這一流程的前提是，所有需求都可以提前確定，而且在項目完工前，一切都不會變化。

在如今這個日新月異的數位化世界中，事情不是這樣運轉的。

試想一個以客戶為中心的營銷部門必須在9月或10月提交一份資金申請，以便其需求被納入IT部明年的日程規劃。但現實情況是，營銷部門——或是任何一個部門——根本不知道自己到時候需要哪些東西，尤其是需要哪些技術手段來輔助他們與客戶互動或是打造數位產品。這是因為客戶本身在6個月、12個月或是18個月之前也不清楚自己需要什麼，他們也不知道一項新的產品功能是否能解決需要完成的任務。

當然你也可以說，你希望IT部門到時的行動更迅速，更靈活。但是把IT部置於一座孤島上，這幾乎是不可能。

最後，你需要考慮IT部門員工的思維模式。大部分IT員工不是因為喜歡製造業、保險業或是銀行業才從事這一行的，他們選擇IT是因為他們熱愛科技業。這種情況下，設立單獨的IT部門只會強化這種思維模式，加劇文化鴻溝。技術是技術，業務是業務。但這種看法完全錯了：今天，業務即技術，技術即業務。

先行的公司

所幸，還有更好選擇。有幾家我合作過的企業，它們正在撤掉IT部門，轉而讓IT人員融入每一個業務部門。這些企業的領導團隊從IT部門的設計初衷出發，努力實現IT部門的價值，而不僅僅是讓它專注於管理IT系統那麼簡單。儘管這種轉變剛開始似乎不易察覺，但它卻代表著一種深刻的變化。正如一位首席資訊官曾告訴我：「三到五年內，每一個人都會成為IT人。」

當然，如果你有自己的數據中心、本地伺服器和軟體，你將需要專業人士來替你維護這些硬件和軟體。這也是組建IT部門的最初目的。但隨著雲端計算和其他科技創新發展，實地配置硬體或軟體已不再必需。

此外，如今我們編寫軟體的方式也發生了根本性變化。比如，有了低代碼/無代碼軟體開發平台，員工可以通過拖拽、拼湊應用程式組件來做開發，無需編程技能即可做出移動端或網頁端應用程式。如此一來，傳統IT部的這項職能也失去了必要性。

我想到一家我曾經合作過的僅面向移動端的歐洲數位銀行，該公司首席資訊官說過這樣一句話：沒有IT部門意味著你永遠不需要用到「業務」這個詞。

他說，「業務部門與IT部門的嚴重割裂是我們極力想要避免的，我們不想出現這種情形，也不想任其發展。」 （相關報導： 華爾街日報》中國和其他亞太國家啟動RCEP，美國冷眼旁觀 ｜ 更多文章 ）

這家銀行在搭建組織架構的過程中，按照商業銀行、支付、市場等不同工作任務將員工組織起來，通過這種方式將技術方面的專業人士融入每一個業務領域。企業領導不妨問自己一個簡單的問題：我們如何利用技術能力才能實現我們的特定目標？一旦有了答案，他們就擁有了自由度，可以選擇最適合自己的方式來運用技術。

這種「享受自治」與「承擔責任」的結合讓員工有了強烈的主人翁意識，同時也有了動力。團隊掌握了他們所需要的資源，儘管有時這會導致裁員，但銀行已對此做好準備。人們不再需要IT部來批准自己的需求。

設立邊界

不過值得注意的是，這並不意味著在涉及技術問題時，員工可以隨心所欲。在技術問題上去中心化的同時，也需要一些集中管理。上述數位銀行就設立了「邊界」——每名員工必須使用同樣的安全協議和軟體編程語言，構建數位產品和解決方案時，必須遵循規定的架構規劃。但在這些「邊界」內，他們可以自由發揮，施展任何必要的手段來完成任務。

一家採取類似做法的能源企業的首席運營官曾告訴我：這麼做的目的是要「在一個框架內營造出自由的空間」，為員工準備好畫布和顏料，至於他們要畫什麼以及怎麼畫，就讓他們自己來決定。

上述數位銀行、能源企業以及為數不多的其他企業已經意識到，如果設立單獨的IT部，要想擁有客戶所需的敏捷性、速度和靈活性，幾乎是不可能的。它不利於企業充分發揮所有員工的潛能，還迫使不同工作任務之間產生相互競爭，在員工中間也容易引發內鬥。除此之外，出現這種結果的可能性也變得更大：當大家終於敲定解決方案時，他們當初想要解決的問題已不復存在。

上面提到的這些企業認為，最成功的組織需要的其實是一種分佈式網絡，其儲備著大量技術知識和專業技能。這些企業正將技術人員部署到每個部門——在每個部門，甚至在一個部門的每個團隊裡配備兩種人才：一種是懂業務的人，一種是懂技術的人。此舉融合了內部團隊之間的工作關係，有利於加快決策速度，增加透明度，並共享主人翁意識。同時各部門無需再與IT部交接，因此不會減緩工作進度。

將所有這些付諸實施並非易事。面對一個去中心化的新世界，不同團隊的需求每個月都會變化，這種狀況下，企業必須想明白如何分配和部署IT資源。何況，如果改變現狀，會牽扯到很多既得利益。高管層需要承認，他們自己往往也是問題的一部分，而且涉及數位世界時，很多高管其實並不知道自己在哪些方面有盲區。

一旦他們意識到這點，今後該怎麼做就變得一目瞭然，那便是企業需要IT。但幾乎可以肯定的是，它們不需要一個IT部門。 （相關報導： 華爾街日報》中國和其他亞太國家啟動RCEP，美國冷眼旁觀 ｜ 更多文章 ）

（注：本文作者Joe Peppard是麻省理工學院斯隆管理學院首席研究員。）