簡單來說，建構管理就是產品研發過程的變動管理，也就是系統架構、版本管控加上變更管理(關於變更管理部份請讀者參閱前一篇文章)，確實執行建構管理不但對有助於研發專案的快速進展，加速上市時間，更對公司整體營運有正面的加分效果－尤其是重視智慧資本的２１世紀。筆者認為建構管理對公司的影響是至為深遠的，不但是研發單位的命脈之一，更是公司從A邁入A+ 的重大里程碑，怎麼說呢？請各位看官聽小弟我娓娓道來
先說明一下建構管理跟系統架構之間的關連性吧，各位有沒有吃過歐式自助餐呢？各位有沒有發現，只要稍具規模的歐式自助餐聽都會將取餐區域畫分成：生食區、熟食區、糕點區、飲料區…等，這樣分區的結果不但方便顧客取餐(客戶滿意度)，更讓廚房能精準掌握各餐區的上菜時機與菜色內容(經營成本)，達到顧客與餐廳雙贏(Win-Win)的局面。聰慧的讀者應該已經發現，取餐區的配置其實就是系統規劃，有了系統規劃後，餐廳的經營管理也能提升效率，收到事半功倍的效果喔！在這裡，筆者要提醒各位讀者，取餐區的動線規劃也是系統規劃的重要環節之一，這點請各位下次到歐式自助餐用餐的時候自己留意一下囉。
從產品研發的案例來看，取餐區的劃分就等同於產品分成硬體機構、韌體跟軟體的區隔，其中硬體機構還會再分解成不同的單元，而韌體跟軟體也還會再分解成不同的子系統或是模組，這就是系統規劃的一部份，也是建構管理的重大參考資料，唯有如此我們才能有效的管理研發過程當中的變化。左圖是系統規劃的簡單範例，是不是一目了然且便於管理呢！給研發主管&經營者的建議：系統規劃的優劣與否將是影響產品研發進程的領先指標，然而系統規劃人員(系統架構師)的養成卻是實務經驗跟時間累積而程的，建議各位可以放些資源在系統規劃人員的養成。
各位讀者應該都寫過履歷表吧！相信大多數讀者在騎驢找馬的時候都會重新檢視自己的履歷並加以更新，通常我們都會複製一份舊的履歷，然後才著手進行更新動作，因此我們會有新舊履歷兩份檔案，有些比較精明的讀者還會在履歷上加上日期甚至註解做為區隔，這樣做的讀者讓我忍不住要讚賞一翻(您真內行)，您知道這樣做，正是在實踐建構管理的精隨之一『版本管控』嗎？有沒有發現因為自己留存著不同版本的履歷，也多了些機會省思現在跟過往的輝煌戰績呢！
回到產品研發的案例去看，新舊版本的履歷就等同於不階段發行的產品，作業系統從 98 升級到 2000 又升級到 2003 是一個明顯的案例，然而改版代表的實質意義又是什麼呢？究竟是系統本身的整體規劃更動(大改版)，還是只有單一子系統的更動(小改版)？要回答這個問題真的很簡單，從個人履歷的例子中讀者就可以猜到十之八九了，只要在每次更動前後加上時間戳記與註解，就可以很快瞭解新舊版本之間的差異，建構管理作業規範也有類似的要求－「凡走過(異動)必留下痕跡(註解)」，能做到這點的人大多都是對自我期許頗高的人，相信各位讀者也是。
注重公司經營的研發單位主管都希望了解建構管理到底對公司會有哪些正面或負面影響？相對地又要投資多少資源？…尤其是有關投資報酬率(ROI)的問題；關於這點我必須清楚答覆各位，就像「信我者得永生」一樣，要發揮建構管理的優勢，首重執行力，能落實制度者，必然能夠得到滿意的報酬，有形的報酬將會反應在產品上市速度(獲利率)、專利與智慧財產權…等，無形的報酬將會反應在團隊的研發能力、知識傳承與產業提昇…等，相對投資則是九牛一毛，請各位主管自行盤算是否有投資的價值。
建構管理的投資 = 伺服器主機 + CM軟體工具 + 教育訓練
建構管理的報酬 = 產品上市速度 + 專利與智慧財產權 + 研發能力提昇
建構管理的 ROI = (執行力 X 建構管理的報酬) / 建構管理的投資
讀到這裡，相信各位對於系統架構(例：餐廳分區)跟版本管控(例：新舊履歷)都具備初步的概念了...待續
沒有留言:
張貼留言