前幾天跟一個主管朋友聊到他們的智慧製造單位演進史。第一代掌門人成立了智慧製造中心,組織位階僅次於營運長,與 IT 資訊中心旗鼓相當。我說: 好棒,然後呢? 他說: 沒多久智慧製造中心就被降級合併到 IT 資訊中心裡面! 一間公司組織異動是正常的,但是把智慧製造放到 IT 我就覺得很奇怪。我繼續問: 為什麼要放到 IT 呢? 他說: 因為上面的主管認為會寫 code 的都是 IT。
會寫 code 的都是 IT
在台灣的「免洗筷」軟體工程文化一文中有提到 IT & RD 的差異,我兩種職務都擔任過,想稍微做點補充: MIS 是 IT 對象是 ERP/PLM/BPM 等企業系統,定位沒有問題,CIM 關注工廠 MES/SPC/infra 等系統,定位也 OK,那智慧製造呢? 談的是物聯網、設備自動化、資料自動化、大數據、數據分析、機器學習、可視化… 都是要提升工廠效率提升的主題,做的是一門客製化生意,外面有多公司是把智慧製造當作解決方案來銷售的,所以我認知智慧製造本質就是 RD,靠著軟硬整合的技術能力來解決工廠客戶的痛點,是貨真價實的戰鬥單位。僅是因為會寫 code 就放到一個幕僚單位去,這是不尊重專業的做法。
幾年前我負責事業單位的軟體 RD 團隊的時候,事業群就用相似的理由把事業群的軟體團隊合併到我這邊,我一度感到非常困惑,思考著不同單位資源要怎麼分配? 當時兩個單位的特性還算很接近,所以我做了一個「很聰明」的資源共享決定,讓軟體工程師同時負責事業單位軟體專案跟事業群的軟體需求。結果卻因為內部資源拉扯感到非常困擾,明明已經 overloading 卻因為我不斷挪動資源掩蓋了事實,導致人員技能衝突不說,switch loss 問題也沒辦法浮現,還給老闆造成一切沒問題的假象,不同屬性的單位還是分開管理為好,真的!