第一章中曾就實務經驗，對於現行 IC 設計管理之缺點做了初步的描述。本章 將從學術研究角度，進一步探討 IC 設計管理之問題及展望，以奠定建構 IC NPD 之基礎，確保此架構之建立，能同時考量實務應用與學術研究兩大主軸。
3.1 IC 設計管理之問題
現行 IC 設計管理屬於循序式的管理流程，除了無法滿足成功 NPD 之條件外，
仍有衍生性的困難課題須要突破，以下將現行 IC 設計管理所面臨之困難課題整理 如表 3.1 所示，分述如下：
表 3. 1 現行 IC 設計管理之困難課題
成功的 NPD 條件 現行 IC 設計管理 面臨之困難課題
即時資訊交換 少 無法成就同步工程理念
累積核心技術 難 專案間獨立管理運作，任務重覆性高
執行動態績效評核 缺 NPD 之成敗在長時間後才得知
最佳化資源分配 差 人力一旦配置，就沒有根據可改變
有效因應市場調整 無 開發週期長，難以同步市場需求
1. 現行 IC 設計管理，除了少數審查會議時各部門才做任務資訊交換，因此，
形成了完成某一任務後，下一任務才被動進行的陋習，而任務之前置溝通 作業，往往又浪費了許多時間。此種銜接方式顯然是同步工程（Concurrent Engineering）最大的障礙。究其原因，乃是整個系統之即時資訊交換不足 所致。
2. 各專案遵循 ISO-9001 設計管制規範，獨立管理運作。實務上，各專案只 將各階段結果，交予文件管制中心記錄備份，專案間無法得知其他專案之 研發成果，專案成果之分享性不佳，嚴重缺乏累積核心技術的能力，突破 未知技術瓶頸須重覆歷經學習過程。
3. NPD 之成敗結果要在很長一段時間後才得知，現行以目標管理的方式，
對於產品開發過程中 NPD 成員努力的程度，以及相對於專案之貢獻度，
難以有客觀的方法執行動態評核，達成績效管理。
4. 實務上，專案於人力配置後，就一直執行任務至專案結束，沒經驗的 NPD 成員往往導致專案進度嚴重落後，對於非常重要且限期完成之專案，管理 者欠缺優序根據，再做適度調整，很難達到最佳化資源分配之目標。通常 管理者憑主觀感受進行人力配置，長久易形成只依賴某些人的迷思。
5. NPD 之開發週期長，現行 NPD 管理方式，對於產品至市場之動態價值無 法掌握；對於市場之需求變化，亦缺乏同步應變機制。管理上難以對開發 時辰及產品規格做有效調整。
現行 IC 設計管理之任務程序規範非常明確，但顯然面對一個成功的 NPD 所必 須具備之條件，尚有許多待克服的困難課題；在未來須變更管理需求，或是管理系統 必須擴充時，新舊專案的管理資訊界面更將無法相容，此管理系統將難以維護；實務 上的經驗通常是“既往不究＂，但妥協的結果往往導致日後更多衍生性的問題。基於 營造一個成功的 NPD 管理之理念，本研究在建構 IC NPD 時，將同時考量未來之擴 充性及可維護性。
3.2 IC 設計管理之展望
新 產 品 開 發 管 理 有 別 於 軍 事 管 理 及 工 廠 管 理 ， 並 非 透 過 標 準 作 業 程 序
（Standard Operation Procedure；SOP）就可準時完成新產品開發任務。研發團隊成 員來自不同領域，分別執行專業分工；管理者須克服不同文化背景障礙、突破未知 的技術瓶頸、以及整合各種知識學問才得以完成開發任務。實務上，管理者若是鼓 勵研發團隊成員，多互動協同及自主自律，或是以管理制度達到相同目的，則管理 之結果將是加乘之效果。因為很多未知的技術瓶頸不須再重覆嘗試錯誤，人與人之 間不同的文化區隔也會隨之降低；各種跨領域待整合的知識學問，其互動融合亦有 助於核心技術的累積。以下將從管理方式、發展架構及資訊系統等三個層面，分別 探討 NPD 管理之展望。
3.2.1 IC 設計之管理方式
在 IC 設計管制流程中有許多反覆式的迴路，站在持續改善以符合產品規格的
觀點當然是沒有問題，但反覆執行的根本原因必須詳加檢討，因為每一次反覆都將 增加成本，而每一次延遲都會降低產品在市場的價值。實務上，由於專案獨立運作，
且人力資源經配置後就難以更改，反覆的原因大部份是在嘗試錯誤（Try & Error），
或是犯了曾經發生的相同錯誤，這種情形在使用新製程，或是配置沒有經驗的 NPD 成員時最容易發生。在半導體廠內最昂貴的是機台設備，所以不容許機台設備有任 何閃失，以至於閒置無法生產；而在 IC 設計公司，研發支出最多的花費在於人力 資源，當然在管理方式上，就該避開以上之盲點。
由 文 獻 探 討 總 結 第 一 點 及 第 四 點 所 提 之 重 點 ， 以 互 動 協 同 （ Interactive -Collaborative）可避免無謂的嘗試錯誤，頻繁的互動交流可降低重複性錯誤的機 率，而協同集思廣益則可減少反覆次數，並在反覆時做出最佳化之決策。這些在管 理架構上都是可以考量的，然而，現行的 NPD 管理方式，卻未見具有改善重複嘗 試錯誤的有效方法；經驗上可觀察出，互動協同頻率愈高的專案團隊，其反覆嘗試 錯誤的情形就愈少。本研究在建構 IC NPD 時，首要考量就是此互動協同之特質。
3.2.2 IC 設計之發展架構
如第一章所提及，將 IC 設計流程以 Project 軟體進行排程，不難看到瀑布式
（Waterfall）的發展架構，進而衍生出關鍵鏈的問題。實務上，若是任務的銜接不 順利，則關鍵鏈之效應將更明顯；值得醒思的是，下層任務一定要等到上層任務完 全完成後才可開始進行嗎？例如：是不是一定要等到所有電路設計完成才可進行 IC 佈局？是不是一定要等到光罩晶圓外包生產後，才可開進行生產測試計畫？
在同步工程的思維下，瀑布式的發展架構是需要被修正的：現在是強調 Design For X 的時代，當發現機台設備有生產測試的瓶頸時，於設計過程就須考量 Design For Testing 的功能；當發覺驗證環境設置有的困難時（例如：訊號太小無法量測驗 證，或電路複雜無法查出失效原因），此時就須考量驗證之 Debug Mode；另外，若 將設計電路區分成若干模組，IC 佈局就可同步進行，及早反應佈局後的問題（例 如：佈局後之形狀限制，或是佈局後面積超出預估，是否調整修正電路）。以上證 明了同步工程的理念，於 IC 設計是可實現的，可以早日發現問題，或是將銜接之 前置作業預先完成，以達到縮短產品至市場時間之目的。本研究在建構 IC NPD 時，將跳脫瀑布式發展架構的盲點，以同步工程的想法改善之。