如您的瀏覽器不支援Javascript 功能,若網頁功能無法正常使用,請開啟瀏覽器javascript 狀態
跳到主要內容區塊

知識管理電子報【第219期】

:::現在位置:首頁 > 電子報 > 知識管理電子報【第219期】

KM論壇


 從精實生產到精實創新(上)


中國生產力中心 盧崇仁 正管理師

  以下的場景一直在各公司上演,研發部黃經理對著總監無奈地表示,「我們幾乎每天都加班到晚上十點鐘,既便如此,開發業務還是趕不上計畫進度,這樣操下去喝再多的蠻牛都沒有用,身體一定受不了,這該如何改善?」,總監用堅定的語氣告訴黃經理「趕快加人,沒有人是做不了事,不減輕研發人員負擔發生離職潮那就更嚴重了」,黃經理無奈的回應「如果加人可以解決,那問題就簡單了,研發團隊的組建不是短時間可以完成的,更何況業務需求的不穩定,這樣做只會增加負擔,對部門經營是沒有好處的」。

  這是常見發生在研發單位的問題,研發專案對公司的經營有戰略上的意義。研發有的是來自顧客的需求,有的是為降低成本而進行,問題是研發團隊的陣容並不可能機動調整。所以,要是來者不拒的話,就會掉入死亡漩渦,結果開發日期就一再被延誤,成本也居高不下。

  這個時候生產部門的陳經理告訴黃經理說「生產部門推精實生產許多年,績效非常好,你們也可以嘗試一下用運精實概念在研發上,說不定可以解決你的問題」。生產部陳經理導入TPS到工廠後,庫存減少,製程流暢,勞動力提升,且大幅縮短全製程時程的效益;第一線作業人員也會主動參與改善活動,改善思維與行動成了工作現場的文化,高層對於TPS降低成本,提升生產力的效益非常滿意。因TPS的目標在減少生產過程中的無益浪費(Muda),為終端消費者創造經濟價值,透過「客戶價值、價值溪流、價值暢流、拉式生產、持續改善」的五大精神來落實。

  研發部黃經理心想TPS的精神用於研發可以發揮功能嗎?研發與生產在本質上有很大的差異。生產是在已知的條件下作業,一切可以經由詳細規劃,透過管理方式逐步落實,重點在財務指標;而研發是處理未知的事,往往無法精確預估研發時程,就算功能做出來也不一定能通過顧客的需求。因此創新產品研發的重工問題非常嚴重,如果牽涉到跨界面整合那問題就更嚴重,公司現在的機構與機電部門常常為了零件配置位子吵得不可開交,常常鬧到總經理要下來協調。

  研發部門雖然有導入Phase-Gate管理概念,但做Phase Review時,工程師必須準備大量工程文件造成工作的延誤。因為Phase Review的重點在稽核研發產品的功能及成本是否符合需求,才能進入下一階段。一般Phase Review屬內部作業,稽核員皆以財務及管理層為主。因顧客在此階段未必參與,通過Phase Review但最後與終端顧客需求相左時,不但要進行設計變更延誤時程,產品開發投入金額也大幅提升。通常在堅守品質的情況下,時間與成本皆大幅超支,是研發單位的常態。

圖一、傳統Stage-Gate的流程圖

圖一、傳統Stage-Gate的流程圖
  
  研發部黃經理為此參加許多新產品開發的研討會,希望能解決研發時間延遲,經費超支及突破技術瓶頸達到顧客需求的問題。在一次新產品開發方法論的開發中,面對興新市場產品的快速變化、靈活性、機動與彈性需求特質,Robert G. Cooper提出新一代產品開發系統(Next-Generation Ideal-to-Launch System),在原來門徑(Phase-Gate)架構中,增加3A系統(The Triple A system)導入以使用者為中心的迭代與螺旋程序,增加適應性與彈性、敏捷開發與加速發展特性,以掌握使用者需求,縮短研發時程,加速產品上市的開發目標。以下針對3A系統作簡單的介紹。

1.適應性及彈性(Adaptive ;ensp;Flexible)

傳統的門徑系統(Phase-Gate)建構在研發產品的特徵清楚,或技術一致下的系列研發。因此可以用程序與檢驗的方式,逐步完成概念成形(ideal-to-launch)的開發程序。但面對新興市場產品開發的不確定性,高達一半以上的規格無法在開發階段完成,在建構階段又會接受新的需求資訊,研發系統必須能適應這樣的改變。

同時系統也必須具備交付內容的彈性,因為每個階段的交付要求因需求而不同,此與SOP操作的開發方式不同,重點在產品必須符合顧客的價值。

部分機構導入風險應變模型(Risk-based contingency model),透過組合管理評估專案的風險衝擊值決定接受或放棄(Go/Kill),並採用雛形­-測試-修改(build-test-revise)的迭代方式測試每個假設狀態,以符合新興市場產品開發的彈性需求。
  
2.導入敏捷式開發法(Agile)

新一代產品開發系統也納入敏捷式開發的概念,此方法起源於軟體產業的快速開發技術,將整個專案切成許多可交付項目,並在專案期間透過可交付項目展示(prototype)的方式確定進度,而不像一般專案管理採用里程碑(milestone)移動方式。敏捷開發的重點在顧客價值的實現及團隊當責的表現,透過迭代的方式逐步實現。

新興市場因需求變化快也急,採用傳統的里程碑方式,常因期間缺乏與顧客的互動,發生在走完里程碑後顧客的需求已經改變,之前所投入的資源化為烏有,造成專案無法如時如預算完成。

而敏捷開發的迭代與漸進開發法(Iterative and incremental development)改善了這個缺點,因採用快速增生(short time-boxed increments)可交付成果的方式,以2週為一個週期產出可交付成果,透過成果與使用者進行確認工作,當發生需求變動時可以快速的進行軸轉(pivot),修改專案的後續執行內容。

3.加速產品量產(Accelerated)

要讓前端創新(fuzzy for end)的產品快速上市,必須讓規格清楚,減少不確定性。專案必須要掌握範疇,釐清未知、評估風險並結合IT系統減少工作,縮短期程。導入敏捷式開發法,通常可以配合階段推疊與同步活動(overlapping Stages and Concurrent Activities)的方式,加速專案的開發及成果的交付。實施的方式可以先採用階段內的活動快速跟進與堆疊的方式加速階段成果的產出。

當階段間的需求及介面越來越清楚,風險小且控制時,產出也符合顧客價值,就可以採用階段推疊的方式,讓概念成形(Ideal-to-Lunch)的速度加快。由Robert G. Cooper的研究資料得知,假如傳統的Phase-Gated開發方式要花18.8個月,採用階段堆疊與同步活動開發方式只花13.8個月。僅時間部分就提升26.5%的研發效率,如果再加上減少重工成本、減少溝通損失、提早上市等,敏捷式開發法確實可以提升研發效率。

圖二、新一代前端開發系統(The next-generation idea-to-launch system)

圖二、新一代前端開發系統(The next-generation idea-to-launch system)
  
  公司的研發部門,從早期以OEM業務為主,業主提供BOM表、規格及驗收準則。傳統的Phase-gate研發程序可以按部就班完成設計圖、組裝圖、材料表,並展開生產單位所須的製程計畫。隨者業務由委託代工OEM轉成產品開發OBM後,研發部門的工作也從完成功能需求的工作,轉成探索市場機會,研究使用者需求,開發新產品。如果無法掌握顧客需求,開發出令人驚豔的產品,公司就很難找到新的成長動能。

  但導入新一代前端開發系統並不容易,因為整個操作程序及組織架構與公司現行的體制有非常大的區別。改造必須從認知開始,透過學習掌握新技術的知識及工具形成共同語言。藉由示範計畫建立公司自己的程序與表單,深入掌握新知的核心,之後才能擴大運用,形成公司研發管理的體系。之後將介紹源自TPS的Lean Innovation方法論,將概念創新的機制提升到精實與知識管理,以提升公司研發管理的效率。

【參考資料】
What’s Next?: After Stage-Gate Progressive companies are developing a new generation of idea-to-launch processes  Reference Paper #52 by Robert G. Cooper