• 沒有找到結果。

4.5 新產品開發輔助系統

4.5.1 工程變更作業系統

任何一個產品在開發階段或者是量產階段,都可能因許多原因產生工程/

設計變更,一套完整的記錄/審核/導入的管理系統可以幫助公司控管/把關,讓 公司的資源做最有效的發揮,同時也可以節省時間及無謂的浪費。一般而言,

產生工程變更的原因可分為下列五種:

1. 設計/工程變更

2. 建立第一版零件用量表 3. 零件品名敘述/承認狀態變更 4. 修訂舊料用完日期

5. 主代用料更換

產品之任何一種工程變更,一定要讓所有相關的組織人員做確認,因此在 工程變更申請文件中會帶到各單位負責人員/負責廠區等基本資料;茲先針對文 件內容做一介紹:

1. 設計/工程變更目的(Purpose of Change)

2. 產品編號(Product No.)

3. 產品階段(Product Phase)

4. 申請廠區(Application Site)

5. 生產廠區(MFG Site)

6. 產品線(Product Line)

7. 製造模式(MFG Service Type)

8. 生/物管責任廠區(PMC Responsible Site)

9. 生產責任廠區(MFG/QA Responsible Site)

10. 產品負責人(PM)

11. 負責業務(Sales)

12. 負責工程師(Project Engineer)

13. 變更理由(Reason of Change):需附上測試報告(Test Report)

設計改善(Design Enhancement)

(1) 軟體(Software)

(2) 硬體(Hardware)

(3) 機構(Mechanical)

14. 製程改善(Process Enhancement)

15. 可靠性考量(Reliability Evaluation):需附上改善評估報告(Process Enhancement Evaluation Report)

16. 代用料(Second Source)

17. 成本考量(Cost Issue)

18. 材料短缺(Material Shortage)

19. 環境考量(Environment Compliance)

20. 標籤內容變更(Label Content Change)

21. 設計不變、工程文件/製造文件更正

(1) 文件錯誤更正(Document Correction)

(2) 補文件內容(Supplement Additional Content)

(3) 補零件料號(Supplement Additional P/N)

22. 變更類別(Details of Change)

23. 零件用量表(BOM)及 BOM Change Form 24. 硬體

(1) 版本對應表(Version History)

(2) 排版圖(Penalization)

(3) 佈局圖(Layout)

(4) 零件放置位置(Component Placement)

(5) 線路圖(Schematic)

(6) 著晶/著線(DM & W/B)

25. 軟體(Host S/W)

異動前料號(P/N before Change)及異動後料號(P/N after Change);軟體 版本(S/W Version)

26. 韌體(F/W)

異動前料號(P/N before Change)及異動後料號(P/N after Change);韌體 版本(F/W Version)

27. 絕緣片及其黏貼方式(Insulator Adhesion)

28. 機殼(Enclosure)

(1) 機構組裝圖(Assembly/Labeling Drawing)

29. 包裝圖/出貨方式(Packing/Labeling Drawing)

(1) 基板標籤(PCBA Labeling)

(2) 機殼標籤(Enclosure Labeling)

(3) 包裝標籤(Packaging Labeling)

30. 使用者文件(User Document or CD)

31. 製造測試規格(MFG. Test Plan)

32. 其他(Others)

33. 最後在針對上述變更判斷是否要改變產品標籤的版本。

透過以上的控管機制,完整的資訊記錄及人員的審核可確保與該產品有關 之所有人員皆被知會且於同意後生效。在完整且同步的資訊平台上共同作業,

對於國際性的公司而言,避免造成知識傳遞的斷層是非常的重要,而這也正是 此系統存在的最大價值。圖 25 為工程變更申請流程圖。

Details of Change Change Content Reason of Change Purpose of Change

Modify MFG. Doc.?

Cut in Timing

Product Disposition Plan

Part Disposition Plan EC Responsible date

Sales

圖 27 工程變更申請流程圖 4.5.2 零件承認作業流程

零件承認系統最重要的目的有二:

1. 新料號的導入及編碼

由於電子零組件的種類及規格繁複,因此一套可將公司內部所使用之材料與 零(組)件做一有系統的分類及編號、查詢及管理的系統是必須的。

2. 品名規範的模組化

由於電子零組件的生產廠家數量眾多,每家的命名規則亦有所不同,因此,

替相同規格/類型的零(組)件做分類是有需要的。

公司設置「申請零(組)件料號管理系統」的原因一般可歸納成下列五種。

1. 為了新產品所申請的料號。

2. 為了客戶所指定的料號(客戶供料、專業代工、OEM/ODM 指定用料)。 3. 為了不同版本區隔所申請的新料號。

4. 針對有鉛/無鉛料號做區隔。

5. 其他原因。

一般而言,材料/零件料號的編碼原則需讓公司易於管理,同時也讓使用者容易 尋找,因此可將此結構分為四個部分,如下所述。

XXXXX. XXXXX. XX (X) 類別代碼 基本代碼 版本 特殊碼

1. 類別代碼(Category No.):此欄位為定義材料/零件性質。

2. 基本代碼(Base No.):此欄位由一串數字組成,在同一類材料/零件內依”

流水編號”方式排列。

3. 版本(Version No.):當零件版本需變更而另外申請新料號時,用此欄位管 控,管控方式以流水號依序進版。

4. 特殊碼(X):此欄位可作為特殊備註用,例如材料的產地別。

事實上,要一眼看出此顆零(組)件的類別所代表的意義,從類別代碼中 是無法一目了然的,因此我們尚必須針對零件類別讓申請者輸入一些基本資訊。

1. Name 2. Category 3. SMD/DIP 4. Package

5. LF (Lead-Free)

6. Manufacturer model Name 7. REV.

在完成零(組)件基本資料的建立之後,接下來要確認的就是製造商的狀 態,一般而言,可分為下列四種。

1. OEM 指定 2. ODM 指定

3. PSL(Prefer Supply List)

4. QVL(Qualified Vendor List)

在零(組)件基本資料及製造商狀態確認完之後,系統會針對「零件合格 供應商(AML)」再做一次分類。

1. Consolidate

此類型的零(組)件為一般正常的料號,對於可使用的產品沒有任何限制。

2. Groups by Model

此類型的零(組)件為現有的產品申請群組料號,僅限於某特定產品使用。

舉例而言,當同一顆零(組)件有兩種報價時,而此零(組)件僅限於某一 特定機種使用。

根據上述基本資料,零件料號系統會產生一個該零(組)件的敘述

(Description),讓使用者可以從資料庫中快速的尋找所要的規格。

在零(組)件做完上述分類之後,一些其他的資訊是需要輸入到系統中的,

例如「元件應用製程」我們可以分為下列四類。

1. 包裝/組裝 2. SMT 3. DIP/手焊 4. Hybird

另外,零(組)件料號管理所需建置的資訊尚有零件包裝方式,因為相同 的零(組)件可能會有不同的包裝方式;例如不同品牌的 SMT 產線所能接受 的零(組)件包裝方式就不盡相同,一般而言可分為下列六類。

1. 散裝

2. Taping (DIP) 3. Tray

4. Reel

5. Tube 6. Cassette

最後,為了清楚地描述該零(組)件的規格,因此下列文件必須當成「子 文件」,完整地儲存在每一份零(組)件料號表單中。

1. 廠商(供應商)承認書 2. 廠商(供應商)規格資料書 3. 工程圖面

4. 零(組)件實體照片

5. 零(組)件承認與環境壽命相關測試報告 6. 無毒驗證報告

零(組)件料號管理系統除了需完整建立上述基本資料外,針對部分元件 應用製程的選擇、零件擺放方式、對於濕氣敏感的程度都必須詳加定義,如此 研發人員在選用零(組)件的時候可省去許多評估的時間,零(組)件料號管 理系統的重要性由此可略知一二。

零(組)件料號管理系統如果加以擴充,則可以針對相同規格、不同供應 商的產品做比較,當使用者下條件式搜尋(例如價格或交期),系統可以自動比 較出較有競爭力的零(組)件,以節省公司在開發產品上耗費的人力/物力。

4.5.3 成品料號管理系統

成品料號管理系統存在的價值是將公司多樣化的產品以某一特定的編碼原 則加以管理,以達到容易辨識、區分的目的。

成品料號為了能讓所有人易於使用及辨識,因此必須設置專人管理;而料 號的結構可分為客戶碼、產品分類、流水碼及版本。另外,為了方便系統管理 員及 DCC(文件管制中心,Document Control Center)作業,在申請/變更單中 尚須記錄 Description,以方便識別此料號。

新料號及版本申請的流程為:

申請人

單位主管

產品工程師

系統記錄 告知客戶

圖 28 成品料號申請流程 4.5.4 供應商承認作業系統

良好的供應商可以提供高水準的供貨品質,因此如何評核供應商以及正 確、快速地建立供應商管理系統是非常的重要,一般而言,供應商管理系統可 概分為四個階段,分別是供應商審核、進料品管檢驗、供應商後續品質改善措 施、供應商績效評估,請參閱圖 30。

供應商審核

進料品管檢驗

供應商後續品質改善措施

供應商績效評估

圖 29 供應商管理系統流程圖

R&D PUR QA

New Supplier Request

Close Questionnaire Vendor

Review

Vendor Questionnaire

Review

Vendor Survey

Qualified Vendor List

Vendor improved, Re-survey if

necessary

NG

No NG

Yes

Ok

Ok

圖 30 Vendor Qualification Process

新供應商的調查 (Survey) 一般會由採購、研發人員及品管人員共同進行,調 查的內容包括:

1. 供應商營運狀況 2. 供應商工程能力 3. 供應商品管標準

在供應商調查完成之後,如果供料過程中發生不正常的品質問題,則以下兩種 人最為重要。

1. MQA(Material QA):當進料檢驗發生異常時,MQA 必須提報告給 MRB

(Material Review Board),並且以正式書面通知原供應商。

2. Purchaser(採購):必須與供應商協調如何解決(ex. Sorting 或換貨),由於目 前許多公司都採行 JIT 觀念,本身庫存皆相當低,因此,如何確保生產不斷料 或及時導入(第二合格供應商)Second Source 是採購最為艱鉅的任務之一。

4.5.5 問題追蹤系統

新產品無論是在開發過程或量產階段中,只要發現 bug,不論其發生原因 為何,都必須要有一套系統作完整詳細的追蹤,以求每一個 bug 都能在時效內 被解決,在 Production Bug Tracking Form 中所需記錄的資訊有:

1. 產品料號(P/N)

2. 產品類別(Category)

3. 產品階段(Product Phase)

4. 產品描述(Product Description)

5. Date bug Occurred

6. Production stage for the problem:該 bug 於哪一段製程中產生 (1) SMT

(2) DIP

(3) Menu Soldering (4) Assembly (5) Testing (6) Packing (7) Others

7. Bug types (circle one only) (1) Document

(2) Electricity (3) Program

(4) Mechanical Material

(5) Mechanical Design (6) Operation Method (7) CAD

(8) PCB Layout (9) Packing (10) Label (11) Material

(12) Manufacturing Issue 8. Bug Description #1, #2, #3, #4 9. Attachments

10. Suggestion

11. Forward to Owner (1) PE

(2) TE

(3) ME Process (4) ME Mechanical (5) IE

(6) H/W Engineer (R&D)

藉由以上完整的資訊記錄,每一份 Bug Tracking Document 會以副本的形式 由系統自動分送到各相關人員手中,且系統每天發警告信提醒此工作尚未結 案,如此可確保每一個 Bug 自發現開始都能在所期望的時間之內解決,並留下 一筆記錄,以利日後追蹤。

4.5.6 產品相關人員異動申請系統

為了確保每一個產品於任何一個位置/時間都能有適當的人員負責,因此每 一個產品都有其專屬的 PE、TE、ME 或 H/W RD 負責,然而人員會因組織或任 務編組而變動,因此當負責人員發生變動時,為了避免某一產品成為孤兒,因 此任何人員變動都必須填寫「產品相關人員異動申請單」,其中所需填寫的欄位 有:

1. 異動類別 2. 承接人員 3. 異動零件類別 4. 原負責人員

申請單在經過雙方部門主管同意及上系統公告後即可生效。

4.5.7 客戶拜訪記錄

Call report System 基本上是「會議記錄」的延伸,但是他所著重的不光是 坐在會議桌上記錄著會議的結論,而是將他擴大到「任何與客戶的接觸記錄」;

Call report System 基本上是「會議記錄」的延伸,但是他所著重的不光是 坐在會議桌上記錄著會議的結論,而是將他擴大到「任何與客戶的接觸記錄」;