優(yōu)化工作經(jīng)常違反一個基本原則：要優(yōu)化整體，必須對部分進(jìn)行次優(yōu)化。

　　作為首席信息官，所做的很多事情都是設(shè)計東西，而那時不會監(jiān)督其他設(shè)計東西的人?；蛘?，當(dāng)不確定每個人設(shè)計的東西是否按照應(yīng)有的方式組合在一起時。

　　無論設(shè)計的是什么，無論是小工具、軟件、組織還是流程，這都很重要。這是理解為什么這么多首席信息官優(yōu)化錯誤的關(guān)鍵。

　　從隊列到隊列：隱藏的進(jìn)程瓶頸

　　如果首席信息官可以靠一個技巧謀生，那么流程優(yōu)化很可能就是這樣。它對于IT很好地發(fā)揮自己的作用至關(guān)重要，而且IT所做的很多工作也是為了幫助業(yè)務(wù)經(jīng)理優(yōu)化他們的流程。

　　IT內(nèi)部和外部的流程優(yōu)化人員擁有豐富的框架和方法可供使用。精益是最受歡迎的，所以讓我們用它來說明這一點。

　　精益思想對流程優(yōu)化世界做出的最重要但最不被認(rèn)可的貢獻(xiàn)可能是流程不是從一個盒子流到下一個盒子再到下一個盒子的任務(wù)的集合。

　　相反，它們是從隊列到隊列再到隊列的任務(wù)。差異可能看起來很微妙，但這是優(yōu)化整體提供與優(yōu)化整體部分不同的結(jié)果的原因之一。這聽起來像是學(xué)術(shù)呼哈或IT公案，但了解這種差異是掌握流程優(yōu)化的關(guān)鍵。

　　想象一下，正在管理一個需要新服務(wù)器才能繼續(xù)進(jìn)行的項目，假設(shè)目前IT還沒有完全云化并且仍然擁有服務(wù)器和數(shù)據(jù)中心。按照程序向IT請求隊列提交請求。

　　這是一個簡單的流程。負(fù)責(zé)每個步驟的團(tuán)隊很久以前就優(yōu)化了處理其職責(zé)的程序?？偣ぷ髁亢土鞒讨芷跁r間是相同的——對于這個假設(shè)的例子，大約是8小時，或者項目計劃中的一天。

　　流程中的每個步驟都作為先進(jìn)先出(FIFO)隊列進(jìn)行管理。只有當(dāng)請求流經(jīng)隊列并彈出以進(jìn)行處理時，團(tuán)隊才會處理請求?？偣ぷ髁颗c盒對盒視圖中估計的相同。但是周期時間包括工作時間和排隊時間——對于這個模型化的流程，大約五天。

　　實際的分析比這更復(fù)雜。通常，一步最終會成為瓶頸。工作在其隊列中堆積起來，而其他隊列干涸，由接收來自多個來源的請求的所有隊列抵消。但這不會改變原理，只會改變模擬的復(fù)雜性。

　　這是真實的，而不僅僅是理論。就在幾年前，一個客戶的隊列大小比上面描述的要長得多，因為他們的團(tuán)隊等待安裝他們所依賴的經(jīng)批準(zhǔn)的服務(wù)器，因此經(jīng)歷了數(shù)月的項目延遲，即使典型的服務(wù)器不需要更多比上面描述的更努力獲取、配置和安裝。

　　根本原因？負(fù)責(zé)采購、網(wǎng)絡(luò)管理、軟件安裝、質(zhì)量保證和部署的經(jīng)理都組織了部門的工作，以最大限度地提高員工利用率和吞吐量。

　　消除外部性

　　DevOps擁護(hù)者將立即認(rèn)可并接受的解決方案是將IT基礎(chǔ)架構(gòu)分析師納入核心項目團(tuán)隊，更重要的是，將基礎(chǔ)架構(gòu)任務(wù)包括在每個項目的工作計劃中設(shè)置服務(wù)器、分配開始日期和截止日期日期取決于何時需要他們的工作產(chǎn)品。

　　通過這種更改，服務(wù)器構(gòu)建成為項目計劃的一部分，而不是項目經(jīng)理無法控制的外部因素。

　　作為交換，首席信息官必須接受，如果項目要在預(yù)算范圍內(nèi)按時交付結(jié)果，IT組織的其他成員將不得不在工作管理上有所松懈。員工利用率目標(biāo)不會也不應(yīng)該接近100%。（專業(yè)提示：花一些時間研究EliyahuGoldratt的關(guān)鍵鏈項目管理方法，以便更深入地了解這一點。）

　　MBO的崩潰

　　優(yōu)化/次優(yōu)化問題不僅僅適用于流程設(shè)計。以管理層薪酬為例。

　　過去，目標(biāo)管理(MBO)是一種流行的理論，即如何通過充分利用組織中的每一位經(jīng)理來充分利用組織。它的致命缺陷還在于未能認(rèn)識到以犧牲整體為代價來優(yōu)化部分的不可避免但意想不到的后果。

　　企業(yè)的高管為每位經(jīng)理分配了一個或多個目標(biāo)。經(jīng)理們，由于他們應(yīng)該完成的任務(wù)更加清晰，他們開始以偏執(zhí)的熱情去完成它，不受組織中任何其他經(jīng)理為實現(xiàn)自己的目標(biāo)所需要的干擾而分心。

　　現(xiàn)代組織因無法協(xié)作而遭受其居民所謂的“孤島思維”之苦，這是MBO時代的遺跡。

　　無奈地幫助服務(wù)臺

　　正如有人曾經(jīng)說過的那樣，或者實際上就像每個經(jīng)理在談到這個話題時所說的那樣，沒有完美的組織結(jié)構(gòu)圖。戴明的優(yōu)化/次優(yōu)化原則是導(dǎo)致組織結(jié)構(gòu)圖缺陷的關(guān)鍵因素。

　　以經(jīng)典的幫助臺及其在IT組織設(shè)計中的位置為例。它為第一次最終用戶聯(lián)系和幫助臺的初始響應(yīng)之間的延遲設(shè)置了服務(wù)級別目標(biāo)；也是解決最終用戶問題所需時間的目標(biāo)。在某個地方，還有一個目標(biāo)是最小化每次事件的成本。

　　考慮到處理每個報告的事件包括記錄它所花費(fèi)的時間，以及嘗試解決它所花費(fèi)的時間或通過將其交給不同的IT團(tuán)隊來擺脫它所花費(fèi)的時間。

　　幫助臺達(dá)到其初始響應(yīng)服務(wù)水平的最簡單方法是在初始響應(yīng)期間盡可能少做，盡可能快地處理每個事件。這使幫助臺分析師可以自由地接聽下一個電話，并且不會陷入試圖解決他們沒有能力處理的問題的困境。更好的是，通過將問題導(dǎo)向具有更多專業(yè)知識的部門，與幫助臺分析師試圖自行解決問題相比，事件將得到更快的解決。

　　可悲的是，這種方法還確保幫助臺分析師在未來永遠(yuǎn)不會學(xué)習(xí)如何處理類似的問題。雖然它還降低了服務(wù)臺的成本，但這樣做的代價是分散了高價人才對當(dāng)前優(yōu)先事項的注意力，從整體價值的角度來看，這些優(yōu)先事項可能更重要。

　　優(yōu)化服務(wù)臺最終成為一種不受約束的成本和責(zé)任轉(zhuǎn)移的練習(xí)。事件管理的總成本與服務(wù)臺自身成本的降低成正比。

　　要優(yōu)化整體，必須對部分進(jìn)行次優(yōu)化。這個指導(dǎo)聽起來可能并不具體和務(wù)實，但不要讓它深奧的暗示讓人望而卻步。如果想要最好的結(jié)果，請確保參與交付這些結(jié)果的每個人都知道他們應(yīng)該是什么。