研發過程式控制制及風險管理最常見的8個問題
研發過程式控制制及風險管理，是確保產品安全性，有效性的重要工具。
然而非常普遍的是，這兩項工作被當作是質量部、審核機構的要求，在很多公司得不到應有的重視，應付了事。
市場上的數據卻證明，研發過程式控制制及風險管理問題是產品召回、質量/安全問題的最主要原因。
深入了解這些設計問題出現的原因，以下這8個問題具有共性。
1. 產品研發流程定義的不好
研發流程要包含主要階段（stages）的定義，各階段的輸出（deliverables），以及從項目啟動要市場投放的關鍵節點（milestones）。
研發過程式控制制及風險管理要嵌入到上述的整個流程中去。
現實中，企業的產品研發流程容易走向兩個極端，一個極端是把所有的細枝末節全部包含其中，最後的結果往往如下圖所示；另一個極端是極其簡單，連主要階段都沒定義，或者根本連流程都沒有。
公司需要「合適」的產品開發流程，要根據公司的規模和需要來定義，直接抄一個大公司的流程往往並不「合適」。
確定產品最基本的風險點，圍繞這個來建立最基本的過程式控制制與風險管理，然後在實際工作中去完善。
2. 不深入了解產品用戶的需求
用戶的需求是定義設計要求的前提。
這裡容易出現的問題有兩個，第一，基於自己的理解來定義用戶需求，想當然地認為自己知道用戶需要什麼、市場需要什麼；第二，對「用戶」理解不全面，比如說，一個醫療設備產品，誰是用戶？是醫生？還是患者？其實都是，甚至還包括護士、設備維護人員等等。
用戶需求要全面、實地去了解，這個環節出了問題，後續的項目、風險控制再好也沒辦法輸出一個好的產品。
3. 設計輸入定義不足夠重視
定義設計輸入是產品開發最重要的一部分，是後續工作的基礎。
通常情況下，大家都急於快速完成設計輸入定義，以便趕快進入樣機（prototypes）階段，很多的研發項目甚至在項目啟動前都已經確定了項目完成日期，項目成員疲於不斷追趕進度。
設計輸入來源於用戶需求，項目完成後，設計輸出要與輸入做驗證，確定是否都得到了實現，倉促定義的設計輸入必然影響最終開發出來的產品。
4. 太晚開始做風險管理
很多公司做產品研發時，都太晚開始做風險管理。
風險管理應該在最初的用戶需求定義，設計輸入定義時就開始，這樣識別出來的風險能夠指導這些定義工作，而且也有利於後續的設計驗證（Design Verification）與確認（Design Validation）工作。
5. 設計評審（Design Review）質量不高
我們需要在開發過程中進行設計評審，這讓我們有機會回顧一下進展，總結一下問題。
設計評審應該是問題導向的，常見的問題有這麼幾個：參加評審的人員不廣泛；評審前未做文件化的準備，流於口頭評審；對跟進事項的追蹤不細緻，遺留很多問題。
另外一個很常見的現象是，把所有的設計評審項目集中到一次評審中，為了評審而評審。把評審頻率提高一點，每次有所專註才能讓評審真正帶來價值。
6. 將設計驗證等同於測試
設計驗證是確認設計輸出是否符合設計輸入。
這裡容易出現的兩個問題是：
事前並沒有確定驗證的可接受標準，輸出達到什麼樣的水平可以認為實現了設計輸入要求？
將測試等同於設計驗證，測試是一個重要的驗證方式，但不是唯一的，檢驗（例如Checklist）、分析等方式也是驗證的方式。
7. 設計確認不有效
設計確認是為了表明研發出來的產品符合用戶的需求。
這裡要注意的兩點是：請用戶參與到設計確認中來；另外，用來做設計確認的產品是按照量產的工藝及物料生產出來的，而不是樣品。
8. 設計變更管理不善
這幾乎是每家公司都有待改善的地方。
在設計階段，設計變更要很好地文件化/系統化記錄下來，確保設計控制做出相應的更新，另外，可以肯定的是，我們一定需要專門的設計變更評審流程。
即使產品已經釋放，後續的還是會有各種的設計變更，完善的變更控制流程對保證產品的持續成功不可或缺。
最後，過程式控制制與風險管理也不僅僅適用於產品研發，而應該是貫穿於全產品生命周期的質量管理，在最初階段就引入這兩個概念，能讓我們儘可能規避上市後的產品質量及合規風險，並為市場成功奠定基礎。
關注「質量優勢」，關注原創質量文章
TAG:質量優勢 |