C公司是一個量測系統整合公司，大部分的營收是來自專案，你要說它沒有產品嗎? 它其實是有產品的，只是因為每個客戶的需求都多多少少有點差異，所以導致這樣一個量測系統整合公司的營運模式很像一般的軟體公司，它們會有獨特專精的產品，比如說ERP、CRM或MES等等，但都不太可能直接賣到客戶端而不需要一些客製化的動作。因此，變得每一張訂單都幾乎會牽涉到一個動作，就是客製化，尤其是越大越專業的客戶，對自己的需求了解越深入，客製化的程度也許就越高。 客製化是一個複雜的動作，從需求確認、規格定義到執行，每個過程都難免會有變數。相信我，世事難預料，再厲害的客戶，也會遇到需要變更需求的狀況，更不用說那些搞不清楚自己需求，想要且戰且走的客戶了。一旦客製化程度變高，傳統的功能性組織就會不敷需求，彈性大、機動性強的專案型組織才有辦法面對各式各樣，因客製化產生的大量變化。舉個最簡單的例子，如果是在傳統的功能性組織裡，某個專案發生了技術問題，這個問題會在技術部門裡反覆討論，再由技術部門主管和業務部門主管開會討論該怎麼辦，再由業務部門主管交代業務處理，或是由技術部門主管交代工程師處理。另外，某個專案的物料也出問題了，物流主管可能也要和技術部門主管和業務部門主管開會討論該怎麼辦，各部門也要再回頭開會交代處理方式。如果今天一個公司裡只有五個案子，那各個部門主管都還可以應付，但如果今天公司裡有五十個案子呢? 會就開不完了。
所以，比較有效率的模式應該是針對每一個專案，成立專案組織，所有突發的、非結構性的問題都是在這個專案組織裡機動解決。功能性組織則是負責解決結構性的問題。比如說，某個案子的物料進貨特別慢，在專案組織內解決，但如果每個案子都慢，則回到物流部門解決。再者，某個案子的電路技術遇到瓶頸，在專案組織內解決，但大部分案子都遇到電路技術的問題，則由技術部門考慮如何提升技術部門的整體電路技術。
另外一個待釐清的問題是，站在公司的角度，這個專案型組織要由誰當Leader? 商業週刊1059期裡的文章 (將風險量化 回歸財務流程管控) 有明瞭且完整的答案。簡單地回答，這個Leader就是業務。在專案生命週期管理上，業務不只負責接訂單，還是專案的負責人。他的績效評估模式，將會包含專案的獲利率、客戶滿意度、客戶重複購買率與專案達成度等。他也需要協調每個環節。這就很自然的讓業務對風險擁有Ownership，會更重視整體的達成度。這件事的前提是，要讓業務有driving force承擔這樣的責任，也就是將績效與個人的driving force連結，例如把每個案子最後的獲利讓業務抽成，或是把績效值與升遷畫上直接的關係，都會是不錯的方式。
組織決定了之後，就剩下流程的問題，在這樣的一個組織內，流程就會像：由業務與客戶洽談需求、評估可行性及風險、評估成本及交期，評估過程中由物流部門及技術部門提供支援，最後報價。訂單下來之後，業務將需求會轉化成規格文件，交付物流部門及技術部門，由物流部門採購原物料，技術部門負責軟體開發及系統整合，所有非結構性的問題就會在這三個人當中協同解決，當然，過程當中這三個人還是可以向其他人提出支援的要求，如果必須的話。開發時如果遇到客戶要求工程變更，則統一由該負責業務出面與客戶接洽。技術部門將系統完成後，便可以將這個系統交由業務確認，是否滿足當初他與客戶達成的協議，如果業務確認完成，技術人員即可對業務進行教育訓練，之後就由業務向客戶進行驗收工作、教育訓練工作及後續簡單的維護。
最後我想提的是，雖然一個系統整合公司絕對沒辦法避免客製化這個動作，除非它堅持不做這樣的生意 (我懷疑這樣的公司是否能存活)。但如果能夠用越簡單的客製化動作來滿足大部分客戶的需求，那這間公司與其他系統整合公司的差距一定會非常的大，至於要怎麼做到這件事，我認為產品模組化會是一個關鍵，我會在下一期的文章做一個陳述，敬請期待。
ps. 在看下一期文章之前，請各位先去 YouTube 上看看茶米在上海的 Battle，像是這裡、這裡和這裡。
YoYo, Baby, Check it out, man.
沒有留言:
張貼留言