這是RD要解決的問題、千錯萬錯都是RD的錯…；我們製程不能改善嗎? 別人可以為何我們製程能力不可以?..., 以上這些對話是不是常常發生在我們目前工作周遭上?
「常山蛇」是《孫子兵法》中的一種策略：「擊首則尾應，擊尾則首應，擊其身而首尾相應。」意思是說，常山之蛇，你打牠的頭，尾巴就過來支援；打尾巴，頭就過來支援；打中間，首尾就一起過來保護，強調的是整體的彈性與靈活度。華碩董事長施崇棠將此一觀念轉換成集團內的管理哲學，是一個提升全員品質的革心計畫。
我則再加以延伸解釋為在組織內部(同一條船，例如同一個部門或同一家公司甚至是同一個集團)，當某一作業出現問題時，上下游單位一起進來到現場共同進行DMAIC(定義-量測-分析-改善-控制)，抱持著人人有責的心態來共同解決問題，而非只是指著對方為何會發生問題，你要如何改善云云…。別忘了指著別人的同時先想想是否”真的”與自己一點關係都沒有???「刮別人鬍子之前，先把自己的鬍子刮乾淨」，自己該做的事情是否已經100%完成了嗎? 而且所完成的是對的事嗎?
問題背後的問題(QBQ)
多年前，看到一部紀錄片，一群地理學家一起探究黃河的源頭，黃河發源於巴顏喀拉山北麓各姿各雅山下的卡日曲河谷和約古宗列盆地，海拔約在4600米至4800多米之間，最初的河道只不過是一條寬約1米、深不及1米的潺潺溪流，由西南往東北而流，一路匯聚途中的小溪流，而成大家所看到的廣闊黃河。一件事情的發生，當下看似突然發生，殊不知問題往往都是一點一滴累積而成，然後在某一時間點爆發出來的。而這個爆發點若是在客戶端，其結果可想而知，大家的年終就這樣被一點一滴的稀釋掉了。公司內所有流程都不會僅限於自己就可以單獨完成，一定是結合你的上下游單位或平行單位，需要他們的協助，然後由你把它完成。所以你是否真的把你自己應該完成的工作給完成並確實交接(透過公司系統)給其他單位以及個人，確定對方已經完整收到你所提供給他的資訊且足以讓對方完成他的工作了嗎?其實問題的發生其背後可能隱含著一連串的問題。
常常聽說RD反應或者工廠端說因為現在是NPI EV/DV 階段，所以RD 要負責…，別忘了是否一旦到了PV/MP階段，說這些話的人是否會因此而角色互換? 換個角度想想，設計不良、DFX(Design For eXcellent)不佳影響的”只會”是RD嗎?生產良率不高、出貨不順利、品質不佳影響的”只會”是工廠端嗎? 這都是同一PU/PG/公司的事! 往往事情一發生，各單位光只是討論(我不想用爭執一詞)責任歸屬就花上大半天，而且似乎責任歸屬尚未定義下來就不會有後續的作為，可能光討論責任歸屬所花的時間，就已經可以將問題定義清楚並且解決了。
本位主義的定義
所謂的「本位主義」是應站在同一個公司的立場而言，追求組織(公司)最大利益為優先考量，而非是個人或單位內的狹隘想法。部門與部門之間無形中都有一條界線，劃分彼此的工作範圍與權責，然而這一條界線是只有0.5mm的寬度還是50m這麼寬? 完全看雙方的定義，最重要的是處理的態度而定，我相信這條無形的界線越是窄的團隊，灰色地帶會愈小，該團隊展現出的績效會越好。
在MLB 美國職棒大聯盟場上，一旦發生打架事件，則休息室內以及牛棚內的球員一定都會蜂擁而上助一臂之力，即使只是上場去”嗆聲”也好，就是不會只讓場上打架的球員在場上單打獨鬥。因為他們共同的想法是若不上去幫忙與助陣，下一次可能是我與對方起衝突，那就不會有隊友來幫忙了，這已經是打職業棒球球員的共同想法以及不成文的規定了，這裡並非要傳達打架要互相幫忙，而是同一個團隊內誰出了事，對於團隊中的每一人都有關係，無法置身事外或甚至於幸災樂禍。不要存著｢千錯萬錯只要不是我出的差錯就好｣的態度。
當打擊者打出一支一壘方向的球時，一壘手前往攔截，此時投手必須立即下投手丘，去一壘補位以便於將打擊者刺殺出局，若投手補位不及、投手或一壘手漏接，都無法將打擊者出局，結果就是投手投的不安穩(看看前洋基隊投手穆西納的動作，只要壘上有人，在他投球前一定會先彎腰觀察壘上跑者的動作)，因為投手必須時時注意壘上跑者的動作，而且只要壘上有跑者就讓對方有繼續往前推進攻佔壘包甚至得分的機會。一個組織內若沒有任何人願意補位，自己顧自己的，則不但自己的事情不能夠做好，且影響到整個團隊的運作，最終只是讓敵人攻城掠地而已。所以說做好補位的動作是全隊贏球的保證之一，公司內各單位不也是如此嗎! 不能做好補位的團隊一定容易失分(失去客戶)。
To be trouble closer, not to be trouble maker (or distributor or forwarder)
一旦有問題發生，往往看到有以下幾種處理現象：
1. 開始對外喊救命，問有誰可以幫助我?
2. 問題一而再再而三的被廣播出去，尤其是發現問題或是問題的發生與當下部門或與個人有關時，深怕沒人知道，所以時常使用Email群發，廣為宣傳，或可能做為自保的手法之一。
3. 問題只是再被轉發出去給更多人，或者又把球丟回給對方，沒有任何積極且正向的回應。
4. 未到現場去實際了解，僅憑所得資訊或者個人判斷就下結論。
5. 把Email 當成論壇或者聊天室。
而好的處理方式應為:
1. 問題到了我這裡不要在讓事情一直發散下去，就讓它在我這裡被收斂下來。
2. 面對有灰色地帶的事情，應主動承擔下來擔任協調者，而相關的單位應抱持著往上游與往下游各多做一點的態度，來將此灰色地帶變成透明地帶。
3. 「坐著寫Email，不如起身到事發現場實際將問題DMAIC」，然後將實際作為與所得結果告訴大家。
4. 一封Email 不要回超過三次，若你已經回了二次，則第三次應該是將此Email的issue 給結束掉。當然在你第三次回信前，一定要先與相關人員討論過(最好直接到事發現場去，難道你看過檢察官辦案是不需要到現場去就能夠將案子結掉的嗎?不過要是真的遇到急迫的事情而無法馬上抵達現場的話，請參考我的另一篇文章:阿波羅13號的危機處理) 並將解決方案提出來!
V&V(驗證與確認)
在軟體驗證技術上有一名詞驗證/查證與確認(Verification & Validation, V&V)，V&V 除了運用在產品開發與測試上之外，也用於ISO 的精神中。ISO全面品質經營(TQM)的理念強調，｢第一次就要把對的事情做對。｣如何知道事情做對了沒？品質管理系統(QMS)的二個要項─驗證/查證與確認就扮演了關鍵角色，不但運用在產品開發與測試上，也適用在產品實現的全程。
驗證/查證(Verification): 是一項品質過程，在於評估工作產品、服務與系統是否符合開發初期所指定之規範、規則或條件。換言之，驗證/查證在於確保｢你做對了(You built it right.)｣，已經落實文件化開發過程，符合指定要求。
確認(Validation): 則是建立文件化證據的過程，展現所提供的產品(或即將提供的產品)、服務與系統，符合其預期使用需求。換言之，確認在於確保｢你做了正確的事(You built the right thing.)｣，滿足使用者的需要。
總言之，驗證/查證與確認就是在於｢確保你做了正確的事情，並且將正確的事情做對了｣。
V&V 的觀念亦可以運用於工作過程上。過程中的每一個環節都必須套用V&V的觀念，因為你的上游單位必須交給你的是他所完成且正確的產出，而你收到後必須先驗證所拿到的是正確的，然後再經過你的程序之後，確保產出是正確的並完整的交給下一棒。
再舉一個例子，ISO 16949 中要求實施PQCP(Process and Quality Control Plan, 外部所熟悉的統稱為QC工程表)，RD 必須提供產品的規格與重點檢驗標準給工廠PQC，PQC依據這些規格再展到第一線作業員所使用的SOP/SIP，如此才能讓第一線人員按照規格(前提是上游必須提供正確的規格)將對的事情把它做對。
結論
問題的發生一定是一點一滴累積下來然後在某一時點爆發出來，但畢竟等到問題發生之後大家才來解決，只能進行矯正與改善而無法做到事前的預防(我想ISO提供了許多預防的方法, 例如: FMEA)。應當將驗證/查證與確認落實到工作與過程上，把自己的本分確實做好，並且透過JIT(Just in time)的態度主動向你的上游單位要你需要的資訊，確保你的產出是正確的，而非一味的等著別人給你的消極態度，然後遵循常山蛇的精神，保持組織的彈性隨時補位，讓整個組織運作具有彈性卻又紮實且不會有任何掉棒子的現象。
延伸閱讀: http://richardview99.pixnet.net/blog/category/list/1426655
留言列表
