需求及供給 出現時，品質就展現在客戶對供給的滿意度上。客戶滿意度高，就會說對方的供給品質很高；客戶覺得品質很差就表示對方不滿意己方提供的東西。
同樣是被評為品質不良時，產品複雜度、是否有形就大大影響了供應者能否順利且快速改善品質來達到客戶普遍的期望。
一台 Dyson DC74 的吸塵器被客訴品質不良時，可能的原因會有吸力不夠強、有雜音、耗電過快等，這都算是很具體的敍述，供應商也能很快查找出問題點。
但如果客戶不滿意的是「服務品質」，那改善上就比較有難度了。
在業界工作也常遇到被客戶抱怨的情況，尤其是剛合作的新客戶，彼此之間不熟悉，總得磨合磨合。可是如果磨合中不小心出了太大的問題，很可能就沒有下次合作機會。
因此如何及早建立可以儘量貼近客戶期望的工作模式並完成產品，就是十分重要的品質管理工作。
半科學 是大多數學科學的人對統計的印象。
其實這麼評斷統計學也不能算錯。在學統計的過程中總會發現這門學問怎麼這裡估計一點、那裡近似一下，混合了某些原本相悖的理論、然後又在某些地方將就一下，同時搞出一堆限制。因此，在我們的世代對統計這門學科的評價抱著正反不一的看法。
在台灣幫大數據這個辭彙興起一波浪潮的大概算柯文哲吧!?他在競選的前中後都用過這個辭，在他沒當選前，我想其它黨派的人大約都是把大數據當噱頭辭看待。
然而，去細想我們生活或工作中大多數處理事情的方法，會發現統計學其實是很貼近生活的。
各種類料類別和檢定 中，有一個在一般統計學上比較少用到的方式叫「勝算比」。
勝算比雖然是一種統計手法，但它比較常被用在生物統計學上，尤其是醫學相關。它的結果來自比例的比，就結果直接去解釋沒有意義。就邏輯上勝算比可以當做一個定量或是一個有效的力量。
在類別交叉分析上，通常會利用卡方檢定或費雪精確檢定，而在醫學界則常會計算出所謂的 RR (reletive risk) 和 OR (odds ratio)。
再談卡方檢定 這個工具在使用上有兩個限制：
1. 卡方檢定中的樣本數不得小於 5 個，或是資料結合後每一格的樣本數不能小於 5。
一般而言，樣本數<5 時必須將樣本合併。或是說格子中的資料不到 5 個時，應該把資料和別格合併。
但事實上，合併資料會使對應的資訊損失。
對於我們從事這種產業的特性來說，很多時候是不可能取得大樣本的資料的。
試驗設計 (Design of experiment) 在遇到不容易澄清的問題時是一個很好用的工具。ODM 業界在產品研發階段比較常見到的解決方式是 trial & error，把可能原因列出後以 troubleshooting 的方式一個一個排除，尋得最可能的根因。
為了節省時間，大多數的研發人員會選擇 trial & error 的方式先進行，因為 80% 的問題都是比較簡單的單一問題，只要射中點就可以顯著甚至完全改善問題。所以 DOE 的應用比例相對少很多，尤其是問題相對複雜時，DOE 還必須搭配 ANOVA 分析才能知道貢獻度最大根因在哪裡。
由於使用的機會少，造成研發人員在進行 DOE 時常常忘了要去記錄失效數據，以致於實驗完成必須總結時沒有數據可以分析。
最可怕的產線失誤 大概就是出問題沒及時喊停吧。
沒檢查到問題、或發生問題但沒有足夠的警覺性喊停，然後還繼續生產，最後產出一堆可能有問題的東西。有些產品是可以拿回去重新測試、重工再出貨的。但是有些產品是沒得救的，只能全部拿去丟掉。
曾經聽一個管理學大師說過，管理要做的主要是三件事：日常管理工作、處理日常工作沒做好到流程後面出現的問題、突發狀況。
然而大多數的組織都花許多時間在管理日常工作沒做好而產生的問題，因此組織的效率嚴重降低。
在跟一個專門在做組織改善的顧問聊到這點時，他說告訴我一個可怕的數據：台灣企業的管理階層平均花在處理這種問題的比例佔了45%，而某些企業的況狀則高達了60%以上。因此企業沒有時間再去思考如何發展自身或團隊能力。
為了風險度高的問題 有時候會為了避免再發生而買保險，除了主要解決方案外又再增加了兩三個方案以免主要方案失效。
但有時候增加解決方案必須評估它帶來的邊際效應，反而使得花下去的成本相對帶來的成效低落。
曾經遇過某個專案，為了解決其中一個特殊難解的問題加入了主要的解決方案後，又應LD的要求再加入了後續的兩個保險備案。導入這兩個備案花了不少時間和成本去進行修改，但事實上效益卻不太大。
能夠有效評估解決方案之間的關聯性和效益，其實在某程度上算是一個很重要的問題，尤其是在成本/ 時程管理上。
類別資料分析 最基本也是最前提的知識就是卡方檢定。
卡方檢定是卡方分配 (Chi-square distribution) 的一種應用。卡方分配是一種概率的分布模式，它是「連續型」機率分配當中Gamma函數的一種特殊型態；順帶一提，指數分配也是從Gamma分配而來的。
因應商業模式快速化 的今天，實在很難看到一個專案可以好好從品質、資源、預算、風險等計劃開始做起。往往是在計劃階段就已經在做執行面的工作 (專案管理流程)。
例如，明明還在報價階段；蒐集並評估各項風險和要求；就已經在執行設計面的工作。這種變態的專案流程已經被視為常規，明明品質目標和風險還沒進行過相當的評估，卻已經把整個設計完成了八成。
等到正式進入執行階段，才在反覆驗證中發現品質目標無法達標、召修損失可能遠比預期高等因素，回頭修正設計。狀況好的只是造成更多的資源浪費，壞的狀況則是浪費資源還無法達成目標，造成雙重的損失。
設計驗證也常成為這種怪異商業生態下的犧牲品，沒好好進行過風險評估就喊出來的驗證計劃，對品保團隊來說只是不停撞牆而已。測了都過，但上市後的客訴量就是超過預期。
不同部門間交互驗證 尤其是量產單位和設計驗證單位之間的驗證，算是我一向認為處理起來棘手的問題。
主要是因為這種交互驗證都是發生客訴才會進行。
再來不論測試條件是否一致，往往交互驗證的樣品間就存在著時間差距(不同時期的材料，試產和量產往往都有些差距)。
常常只要交互驗證出現差異，量產單位都會第一時間導向設計單位的失誤。
差異出現後需要投入不少時間和人力去澄清。
那有沒有機會在投入人力之前就先檢驗測試結果的可信度呢?
答案是有的。在某些狀況下，確實是有機會在投入資源去澄清問題前，就可以鎖定一定程度的範圍，減少初期的工作量。
使用者經驗 是這幾年常被市場行銷和產品開發者掛在嘴上的口號之一。
為了使產品更貼近消費者，考慮UX (user experience) 確實是十分必要的條件，尤其是這幾年UX在台灣越來越廣為人知也常被拿來應用。最常見的就是組織高層拿來提倡產品必須有UX的概念，或者是將產品分給一些人使用來蒐集問題。
然而，整個產品從marketing、定義產品標準到開始研發的流程中，參與人員的使用者經驗概念大多良莠不齊，甚至是完全不在乎UX是怎麼一回事。
只用極少數的樣本 來驗證產品設計的可靠度在許多產業都是慣例，尤其是產品類別已經相對成熟的產業。
成熟的產品利潤相對低，投入研發階段的經費也較少。在研發的過程中，可靠度驗證是相當燒錢的程序。時間長、樣本數多而且測試完幾乎都不能回收再利用。因此只用極少數的樣本來進行可靠度測試成了最常見的做法。
然而，極少數樣品驗證得到的結果代表性有多高，能夠幫助品保下什麼程度的判斷，就是要討論的方向。
Statistical Process Control (SPC) 從發展到應用至今已經有70年歷史，在1960年左右開始被工業界大量應用。製程能力指標；Cpk；在資訊電子業界早已經廣為人知的東西。
這個指標被用了幾十年，業界人員都如此熟悉，現今Cpk可說是被拿來當做製程是否能符合要求的100%指標。
當製造端遇到製程品質問題待澄清時，常看到用Cpk達標與否來證明製程良劣。
不免俗先來解釋一下Cpk
在成本考量 為重的今天，製造業這一區塊中供應商管理幾乎快成了一種形式化的程序。如果產品簡單，供應商的數量少，又或者是供應商是有口碑有保證的品牌，在管理上相對會簡單不少。但對於一些產品複雜的組織；尤其是系統廠；一個產品所涵蓋的供應商數量和種類繁雜，不易管理。
隨著近幾年經濟市場的轉型，各公司都採取節約成本的經營策略，其中便包含了逐年、逐步壓低供應商成本的策略。在供應商自己也有成本策略的情況下，通常造成的結果便是同供應商(或材料)越來越難管理，最後不得不更換一個成本低、較易達到成本策略目標的廠商，而事實上供應商管理卻沒有變好，只有變壞(十分符合熱力學第二定律)。
統計分析 在可靠度裡的重要度在我個人的想法裡應該是越來越重要的。
隨著經濟市場的變化，公司營運成本的降低是非常重要的一環，很多時候可靠度必須要實際驗證來蒐集資料，但是經由統計分析和預估的協助常常可以讓實際測試的樣品數、時間或人力下降，但能得到相當可靠度的結果。例如兩個實驗室在做同樣的測試後產生了矛盾的結果，在排除各種能想到的影響因素後，就得要靠統計方法來分析2組樣品間的異同性後決定是否要再增加測試樣品、或者是增加必要的數量即可。統計的分析應用往往可以幫助我們加速決策的方向並省去決策過程的一些成本。
