想要最佳化工作,經常會違反一項基本原則:想要將整體最佳化時,其中的各個部分反而必須採用次佳化(suboptimize)。
文/Bob Lewis‧譯/羅耀宗
資訊長投入的很多事情,都與設計規畫有關,但此時就難以督導其他同樣負責設計的人員。此時有可能發生的是,資訊長沒法確認每個人正在設計的東西可能缺乏全局觀,是否能依照合適的方式拼接起來。
不管設計的是什麼,良好的設計都會遵循一些放諸四海而皆準的規則。最有名的可能是偉大的建築師 Louis Sullivan 的格言:形式追隨機能。而戴明(W. Edwards Deming)提出的規則比較少為人知,但同樣重要(至少就本文目前討論的主題而言):想要將整體最佳化時,其中的各個部分反而必須採用「次佳化」(suboptimize)。
不論設計的是什麼,管它是小器具、軟體、組織,還是流程,次佳化都同樣重要。而這也是了解為什麼有那麼多資訊長做錯了最佳化工作的關鍵。
從佇列到佇列:隱藏的流程瓶頸
如果資訊長打算依靠單一技巧維生,那麼流程最佳化很可能就是那項絕技。這對於 IT 把本身的角色執行妥善至關重要,而 IT 賴以維生的很多工作,也就是協助業務經理人將其流程最佳化。
不論是 IT 內部或外部的流程最佳化人員,都擁有可供使用的大量框架和方法。精實方法論(lean)是其中最受歡迎的,所以本文採用它來進行後續說明。
精實方法論的想法,對流程最佳化領域所做出可能是最重要,但也是最不受認可的貢獻,是在於流程並不是從一個方格進行到下一個方格,再到下一個方格的任務集合。
[ 參與 CIO Taiwan 年度盛事 2023 CIO 大調查,就從填寫問卷開始!(survey.cio.com.tw) ]
相反的,它們是從佇列(queue)到佇列,再到下一個佇列的任務。這種差異看起來可能相當細微,但也是對「整體」最佳化所呈現的成果,與最佳化「整體的各個部份」有所不同的原因之一。這聽起來像是學者在掉書袋,也像是 IT 的無頭公案。但能夠了解這種差異,則是嫺熟流程最佳化的關鍵。
不過在這裡請先聽筆者一言。
不妨想像一下:由資訊長管理的專案,需要搞一臺新的伺服器才能繼續進行。但此時 IT 尚未完全邁入雲端化,只有實體伺服器和資料中心。資訊長依照公司規定的流程,向 IT 需求佇列提出請求。
雖然有點過於簡化,圖1 以連續方格,畫出整個流程。
這是個一目了然的簡單流程。負責每個步驟的團隊,在很久以前就已最佳化了處理相關職責內的流程。對這個假設的例子來說,總工作量和流程週期時間相同,大約是八個小時,或算成專案時程的一天。
但是從方格到方格的流程觀點是錯的,實際的流程看起來比較像 圖2。
流程中的每個步驟,都是依照先進先出(FIFO)佇列加以管理。只有在請求進入佇列之後,並被要求處理時,團隊才會開始處理這項請求。總共需要的工作量,與從方格到方格觀點的估計值相同。但是這個周期時間,還包括了工作時間與請求停留在佇列中的時間;就這個模型化的流程而言,大約會需要五天左右。
但實際的分析比這些步驟還要複雜。一般來說,其中有一步最後會成為瓶頸。在其他的佇列中,工作能夠一一出清;但在某一步驟的佇列中,工作逐漸堆積,由接收來自多個來源請求的所有佇列抵消。但這並無法改變原則,只會改變模擬的複雜性。
[ 加入 CIO Taiwan 官方 LINE 與 Facebook ,與全球CIO同步獲取精華見解 ]
真的是這樣,不只是理論而已。就在幾年前,有一位客戶的佇列大小,比上圖所述要長得多。由於該客戶團隊需要安裝獲得批准的伺服器,苦等不得,以致專案延遲了數個月之久。而典型的伺服器,在取得、配置和安裝方面,其實不會耗費比上面所說更多的心力。
根本原因是什麼?負責採購、網路管理、軟體安裝、品質保證和部署的經理人,都將自己整個部門的工作組織得很好,將員工的利用率和產出最大化。
不過他們其實都只是整體流程裡的一部分,只顧最佳化自家單位,但卻犧牲了每個專案的整體效率。
消除外部性
開發營運人員(DevOps)能夠立即認可並接受的解決方案,是將 IT 基礎架構分析師納入核心專案團隊裡。更重要的是,要納入在每個專案的工作計畫裡設置伺服器,以及根據何時需要他們的工作產品,設定起始日和截止日等基礎架構任務。
做了這種改變之後,伺服器建置就會成為專案時程的一部分,而不是專案經理人無法控制的外部因素。
交換條件是,資訊長必須接受,如果專案要在編列的預算內準時交付結果,就必須允許 IT 組織其他成員在工作管理上放寬某些條件(slack)。員工利用率甚至不會也不應該接近 100%。(專業提示:請花一些時間研究 Eliyahu Goldratt 提出的關鍵鏈(Critical Chain)專案管理方法,可以更深入理解這一點。)
MBO 目標管理崩壞
最佳化∕次佳化的問題,其實不只發生在流程設計上,以下將以主管薪酬計算來舉例。
目標管理(MBO)理論以前很流行,探討如何從組織中的每一位經理人得到最多,好從組織得到最多。它的致命缺陷,就是未能認清如果最佳化部分績效而犧牲整體績效,可能會產生不可避免或意想不到的後果。
它的運作方式,或者更好的說法是不能正常運作的方式,顧名思義,是企業高階主管指派給每位經理人一個或多個目標。經理人對他們應該完成的任務更加了解之後,就開始以偏執熱情放手去實現自己被設定的目標;並不會受到組織中其他任何經理人為實現自己的目標需要做的事情干擾而分心。
現代企業組織受限於這種所謂的「畫地自限思維」,難以協同工作,可說是 MBO 時代的遺毒。
服務中心程式反而無力協助
曾有人說過,或是提及這個主題時,幾乎每位經理人都會表示,這個世界上並沒有完美的企業組織圖;而戴明的最佳化∕次佳化原則,就是導致組織圖不完美的關鍵因素。
以典型的內部服務中心(help desk)與其在 IT 組織設計中的地位為例來說。它為和終端使用者的第一次接觸和服務中心初始的回應,兩者之間的延遲設定了服務級別目標;這也是解決終端使用者問題所需時間的目標。這方面,還有一個目標是極小化每次事件花費的成本。
想要衡量每項呈報上來的服務案件狀況,要計算記錄案件登記花費的時間,以及嘗試解決案件所耗用的時間;或是算出將案件交給不同 IT 團隊解決問題所耗費的時間。
想要讓服務中心能夠達到一開始所設定的回應服務水準,最簡單的方法,就是在開始回應的期間盡可能少做事,同時也要盡可能迅速解決每個案件。盡量讓服務中心的分析師因此能夠脫身,好接聽下一通內部客服電話;不會因嘗試解決人員其實沒有能力處理的問題,而進退不得。更好的方法是,要將問題案件導引到具備更多專業知識的部門;與服務中心分析師嘗試自行解決問題相比起來,解決案件的速度會更快。
遺憾的是,這種方法也肯定讓服務中心分析師永遠學不會將來要怎麼處理類似的問題。而且,雖然這種做法壓低了服務中心成本,但要付出的代價,是薪酬較高的人才會因此分心,無法專注在眼前的優先任務;而從整體價值的角度來看,這些優先任務會更重要。
推動服務中心最佳化,就變成了不受限制的成本和責任轉移的練習場域。服務案件管理的總成本,隨著服務中心本身成本的降低幅度,卻成正比增加。
要最佳化整體,資訊長必須將各個部分次佳化 。這句話聽起來可能並不具體也不務實,但別讓這深奧的暗示造成遲疑不決。如果資訊長想要產生最好的結果,務必確保參與交付那些結果的每個人,都能知道他們應當做什麼。
此外,也要保證沒有人會因為熱心透過協同工作來推動結果實現,而受到莫名的懲罰。
(本文授權非營利轉載,請註明出處:CIO Taiwan)