如果這個特例變成常態的話,那我們要如何應對呢?

公司的既有流程,一定是經過討論、驗證過,尤其大多數公司都通過ISO認證,每一個流程一定是很嚴謹的。但是在公司運作過程中,偶而會出現一些緊急事件,基於時間緊迫性,這些緊急事件會作個案處理,但是,如果這個特例變成常態的話,那我們要如何應對呢?

每一家公司都會有一個ECN(工程變更通知,Engineering Change Notice)的制度(ch. 2.3.13),為了因應客戶、市場、品質或技術之需要,產品需要進行零組件、程式、製程之工程變更,ECN流程必須傳簽到相關人員,對工程變更進行討論和驗證,以作為量產階段執行工程變更的依據。

然而當公司發展到一定的規模,細分出來的部門越來越多,文件傳簽的速度就會很久,以系統產品為例,也許就會牽涉到研發硬體、研發軟體、機構、安規、環保、採購、品管、製造、業務…等部門,除了要傳簽到工程師,還要簽到部門主管。有時候這個工程師在國外,那個主管在忙開會,雖然文件傳簽改成電子化,但是工廠設在國外,因為各地區時差的問題,往往沒辦法在短時間內,完成這份文件的簽核作業,偏偏產線對策如箭在弦上,整廠大軍都在等這份ECN。

有個頗具規模的公司,就發明一個緊急ECN流程。發行緊急ECN的目的,是彌補一般ECN流程的不足,以避免一些無意義的傳簽造成曠日廢時,在一般 ECN流程,設計文件傳簽流程,一定要考慮最大化的狀況,各部門都要考慮進來。若碰到緊急狀況,運用緊急ECN流程,就可以避開很多不必要的程序,例如機構元件組裝干涉,只要修改一個小地方即可,會簽到安規、軟體等部門是無意義的,啟動緊急ECN流程,可以加速ECN流程的簽核。
當緊急ECN生效時,第一步就是改BOM,先把想到可能的損失物料擋下來,例如先從電腦操作來阻止錯誤的物料進入生產線,再由後續人工作業來把關。
緊急ECN流程不在文件制度,跳脫一般ECN流程的框架,在執行過程中,雖然方便行事,卻容易發生了一些問題,例如:品管部門抱怨「應該先經過品管審核」;文件發行部門抱怨「緊急ECN發行得太過於頻繁、草率」;採購部門抱怨「所更改的物料沒辦法立即買到」等。
可是問題來了,這個緊急ECN流程從來沒有寫在文件制度裡面,也幸好這些老長官都沒退休,自己也不記得自己規定過什麼;也幸好官大學問大,要不然每個人解釋制度的說法都不同。

 

因此在情非得已的狀況下,才要走制度外的緊急ECN流程,不要為了省事而走在緊急ECN流程,而且在緊急ECN流程所產生的一些規定,如果真的是可執行的話,就必須回饋到ISO文件裡面,唯有沉澱討論成文,才能演繹出邏輯;如果不能放到公司伺服器作制度化的管理,那這種口頭規定,的確就是可有可無的。


公司ISO規定的流程是基本的憲法,任何後續的規定,都不能違背憲法;當出現「特例」,代表規定的流程在實行上有問題,因此一定要檢討制度,修改或是寫入憲法,絕對不能讓「特例」重覆上演。
 

arrow
arrow

    兩本書 發表在 痞客邦 留言(0) 人氣()