IT 部門如何利用 DevOps 帶領企業數位轉型《鳳凰專案》

上次更新:8 4 月, 2024
戴上公司「利害關係人」的眼鏡,擁有經營者的視野

大家普遍對公司 IT 部門的印象不外乎是負責修電腦、裝 Windows、設定電子信箱、或者電腦中毒時負責處理的單位。如果是稍微熟悉 IT 部門的人,也許就知道其實「許多業務專案跟 IT 息息相關」。 但實際上,IT 可以不只是你想的那樣。IT 如果得以發揮長才,足以擔任翻轉公司存亡命運的重責大任。

這次我想要介紹一本書,叫做《鳳凰專案:看 IT 部門如何讓公司從谷底翻身的傳奇故事》。身為 IT 產業的一份子,得到不少啟發。這本書起源於比爾,IT 經理,在一家逐漸失去市場優勢的零件公司裡面所面對的挑戰。面對突如其來的升職挑戰,向 CEO 直接彙報。並得到命令必須在九十天內完成改造計畫,否則整個部門將會被外包。比爾是如何從原本駕輕就熟的維運部門在最短時間內理解開發、稽核部門,甚至和財務、業務、行銷及產品部門展開溝通,最終得以改善 IT 組織,進而改變了公司及自己的命運?

person working on blue and white paper on board
Photo by Alvaro Reyes on Unsplash

IT 不只是你想的那樣

在書中,稽查部門的約翰經歷了重大的挫折,意識到自己堅守的安全檢查等信念其實在組織當中是不必要的。因為財務和物料管理等部門的經理們不斷演示各種心懷不滿的內部員工或者外部的駭客無論怎麼樣嘗試詐欺,最終都能在財務報表中被抓出來,進而得到懲罰。

垂頭喪氣的約翰在經過一段時間的沉澱,終於起身行動,在和比爾一起對財務、業務、行銷部門訪談後對於自己的工作有了全新的理解。

IT 和財務的工作其實都和公司目標息息相關

在訪談過後,比爾和約翰了解CFO 並不只關注財務和數字指標,同時也在乎公司目標,譬如了解客戶的需求和期望銷售預測準確率以及選擇正確的市場。假使這些核心目標無法達到,則即使擁有全世界最棒的應收帳款團隊,也無法改變公司被市場淘汰的命運。也就是說自己的工作和財務甚至到公司走向其實都互相關聯

快速回應市場和內部回報率是衡量專案成敗的重要指標

許多投資專案對於 CFO 的角度而言,其實是從內部回報率(IRR)來衡量的。意思是如果這個 IT 專案沒有辦法在期間內上線到市場上試水溫、取得成功,是有違經營者期待的。因此儘管在傳統開發方法下所需半年甚至數年的開發時間對於開發和部屬團隊來說很合理,在企業經營的角度卻是不得不面對的考驗。

及時、正確的訂單資料就足以對公司營收產生影響

產品經理和比爾描述美好的一天:「只要點擊一下按鈕就可以得到正確且及時訂單資訊,接著運用這些資料做出生產排程,最終就能夠讓正確的產品出現在正確的貨架上並且投放廣告給需要的消費者」。接著營收將一路衝高、提升市場佔有率,再次打敗競爭對手。

red and green plant on brown wooden wall
Photo by Visual Stories || Micheile on Unsplash

快速上市、快速淘汰

如果產品部門規劃的產品從研發、量產到上市不能在六個月內完成,就有很高的機率被競爭對手偷走想法、複製出類似的東西,並取得市場份額。因此過往開發部門的開發方法必須修正,才能夠適應現在的市場需求。

系統服務中斷所付出的代價比想像中巨大且複雜

和訂單相關的電話系統、訂單系統、MRP 系統(Material Requirement Planning,原物料需求計畫系統)如果出了差錯,不僅因為客戶無法訂購產品而造成業績損失、客戶滿意度下降並可能轉往競爭對手,銷售和財務部門更需面對業務人員因公司系統失誤而無法達成業績的損失,甚至要研擬一套補償方案來提振士氣,更不用提因此失去員工後衍生的招募和訓練成本

稽核的目的也應與公司目標一致

稽核的工作應該要跟公司的核心競爭力息息相關」,反之,則會耗費寶貴的人力資源在各種文書工作以及會議。舉例來說,如果一套系統的導入「既不會影響公司資訊安全、也不影響資料完整性,則其實不用大費周章做資訊安全檢查」。以員工餐廳的POS 系統(Point of Sales,收銀系統)為例,約翰在理解到該系統並不存放機密敏感資料後,便果斷的決定將它外包,以節省內部資源消耗。

black scientific calculator beside black headphones
Photo by Charles Deluvio on Unsplash

我的觀察

在平常跟客戶的 IT 部門互動過程當中,我觀察到有幾種類型:

資安優先

無論評估什麼解決方案,請先填寫一份超過百題的資安問卷再開會做評估。

成本優先

如果業務單位希望做一個PoC(Proof of Concept,概念驗證),比起效益,一定先搞清楚要付出多少成本。

不增加維運為原則

能夠少導入一套系統就少導入,儘管業務單位覺得有效益。

新創思維

也有的客戶,非常有決心,希望能夠快速轉型。就會期望開發人員在測試過最小可行性產品(Minimum Viable Product,MVP)後,在最短的時間內正式上線。

person holding yellow round analog clock
Photo by Morgan Housel on Unsplash

身為 IT 產業的一份子,我理解造成這些決策標準背後有很多原因。有時是公司的企業風格,也是能在市場上屹立不搖的關鍵。例如製造業或者代工業通常以毛利率優先,因此特別重視成本控管。有時則是領導者的績效衡量標準

譬如書中的主角比爾,最一開始是標準「工程師思維」,在意的是專案能不能完成功能驗證、如期交付。但如果戴上公司其他「利害關係人」的眼鏡,譬如財務部或者市場部,那麼思維模式就會完全不一樣。也因此,比爾後來決定將龐大鳳凰專案中,最優先、緊急的幾項小專案切出,成為獨角獸專案

運用開發維運的方式,以最短的時間上線。不僅讓整個專案得以順利運行,更重要的是,讓行銷部門得以施展拳腳,進一步讓公司開始急起直追競爭對手,最終和公司的發展目標一致,同時也保住了自己和全部門的飯碗。

平日總是埋首於各種維運工作或者被交付期限追著跑的 IT 讀者們,偶爾不妨抬起頭來,多跟不同部門的人交流意見,幫助自己換位思考,相信會有很多收穫。

你可能也會感興趣

告訴我你的想法:

Subscribe
Notify of
guest

這個網站採用 Akismet 服務減少垃圾留言。進一步了解 Akismet 如何處理網站訪客的留言資料

0 Comments
Inline Feedbacks
View all comments