職場漫談｜常山蛇外傳
職場中，是否常常遇到摘要中所說的現象呢? 身為老闆、BU( Business Unit) Head、PM(Project/Program Manager)常常要為了溝通協調、仲裁而耗費許多的時間與精力。
以下分享幾項觀念，從企業文化的常山之蛇、問題背後的問題、本位主義的全新定義、查證與確認的概念等，期以從個人面對事情的態度與處理事情的觀念，再輔以企業文化的氛圍，提升團隊的效率、改善專案管理的品質，為公司提升獲利。
✅企業文化：常山之蛇
「常山之蛇」出自《孫子·九地》：“故善用兵者，譬如率然。率然者，常山之蛇也。擊其首則尾至，擊其尾則首至，擊其中則首尾俱至。”古代傳說中的這種常山蛇，能首尾互相救應，後因以喻首尾相顧的陣勢。
動物兵法為華碩的管理哲學之一。其中一式「常山蛇」是《孫子兵法》中的一種策略：「擊首則尾應，擊尾則首應，擊其身而首尾相應。」意思是說，常山之蛇，你打牠的頭，尾巴就過來支援；打尾巴，頭就過來支援；打中間，首尾就一起過來保護，強調的是整體的彈性與靈活度。華碩董事長施崇棠在多年前，曾將此一觀念轉換成集團內的管理哲學，是一個提升全員品質的革心計畫。
我則再加以延伸解釋為在組織內部(同一條船，如一項專案、部門，大至一家公司)，當某一作業出現問題或者品質異常、客戶抱怨時，上下游單位一起進來到現場，以DMAIC(Define-Measure-Analyze-Improve-Control, 定義-量測-分析-改善-控制)模式，抱持著人人有責的心態來共同解決問題，而非只是指著對方為何會發生問題，你要如何改善云云…。
別忘了指責別人的同時，先想想是否”真的”與自己一點關係都沒有?套一句經典的廣告詞：「刮別人鬍子之前，先把自己的鬍子刮乾淨」，自己該做的事情是否已經100%完成了嗎? 而且所完成的是對的事嗎?
✅問題背後的問題(QBQ, The Question Behind the question)
多年前，看到一部紀錄片，一群地理學家一起探究黃河的源頭。黃河發源於巴顏喀拉山北麓各姿各雅山下的卡日曲河谷和約古宗列盆地，海拔約在4600米至4800多米之間。
最初的河道只不過是一條寬約1米、深不及1米的潺潺溪流，由西南往東北而流，一路匯聚途中的小溪流，而成大家所看到的廣闊黃河。
一件事情的發生，當下看似突然發生，殊不知問題往往都是一點一滴累積而成(如黃河的源頭般，只是潺潺流水)，然後在某一時間點爆發出來的。而這個爆發點若是在客戶端，其結果可想而知，說不定還會被求償，大家的年終就這樣被一點一滴的稀釋掉了。
公司內所有流程不可能僅限於自己就可以單獨完成，一定是結合你的上下游單位或平行單位，需要他們的協助，然後由你把它完成，或者因為有你，才讓你經手的事情更有價值。
所以，你是否真的把你自己應該完成的工作，完成並確實交付(透過公司系統)給到下游接手的單位與個人，確定對方已經完整接收到你所提供給他的資訊，且足以讓對方完成他的工作了嗎?其實問題的發生其背後可能隱含著一連串的問題。
常常聽到工廠端說因為現在是NPI ES/EV/DV 階段，所以RD 要負責…，別忘了是否一旦到了PV階段，說這些話的人是否會因此而角色互換? 換個角度想想，設計不良、DFX(Design For eXcellent)不佳，影響的”只會”是RD嗎?生產良率不高、出貨不順利、品質不佳，影響的”只會”是工廠端嗎?
NPI(New Product Introduction, 新產品導入)，流程共有幾個階段，依序為ES(Engineering Sample)、EV(Engineering Verification)、DV(Development Verification)、PV(Production Validation)。透過完整的執行各項階段，順利將新產品從設計研發、試產一直到量產為止。
這都是同一專案/BU/公司的事! 往往事情一發生，各單位光只是討論(我不想用爭執一詞)責任歸屬就花上大半天，而且只要誰該承擔與負責尚未定義下來，就不會有後續的作為，但可能光討論歸屬問題所花的時間，就已經足夠將問題定義清楚甚至解決了。
✅「本位主義」的定義
本位主義，原意是指只顧自己不顧別人的一種作風。有時它也指一种放大了的小團體主義或個人主義，例如在處理單位與部門、整體與部分之間的關係時只顧自己，不顧大局，對別部、別地、別人漠不關心。本位主義者被認為缺乏大局觀和全局意識，考慮問題時以自我或小團體為中心，無論利弊得失都站在局部的立場上。
我對於所謂的「本位主義」的定義，是指應站在同一個公司的廣義立場而言，追求組織(公司)最大利益為優先考量，而非是個人或單位內的狹隘想法。
部門與部門之間無形中其實都有一條隱藏的界線，劃分彼此的工作範圍與權責，然而這一條界線是只有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 給結束掉。當然，在你第三次回信前，一定要先與相關人員討論過，最好直接到事發現場去，就像檢察官辦案一樣，他們一定會到現場徹底了解狀況。但現在疫情關係，若無法抵達現場又該如何?可以參考以下文章。
📖延伸閱讀：職場漫談｜解讀豐田三現主義
✅V&V(Verification and Validation, 查證與確認)
在軟體驗證技術上有一名詞「查證與確認(Verification & Validation, V&V)」。V&V 的觀念除了運用在產品開發與測試上之外，也是ISO 的精神之一。
ISO全面品質經營(TQM, Total Quality Management)的理念強調，｢第一次就要把對的事情做對。｣如何知道事情做對了沒？品質管理系統(QMS, Quality Management System)的二個要項：「查證與確認」就扮演了關鍵角色，不但運用在產品開發與測試上，也適用在產品實現的全程。
查證(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(Failure Mode Effective Analysis, 失效模式分析))。
應當將查證與確認落實到工作與過程上，把自己的本分確實做好，並且透過JIT(Just in time)的態度主動向你的上游單位要你需要的資訊，確保你的產出是正確的，而非一味的等著別人給你的消極態度，然後遵循常山蛇的精神，保持組織的彈性隨時補位，讓整個組織運作具有彈性卻又紮實，且不會有任何掉棒子的現象。
📖延伸閱讀
📚推薦書目
📜參考文獻