淺談解決問題的架構

[et_pb_section fb_built=”1″ _builder_version=”3.22″][et_pb_row _builder_version=”3.25″ background_size=”initial” background_position=”top_left” background_repeat=”repeat”][et_pb_column type=”4_4″ _builder_version=”3.25″ custom_padding=”|||” custom_padding__hover=”|||”][et_pb_text _builder_version=”3.27.4″]

前言

品保圈(簡稱QCC)是一套解決問題的邏輯方法,其實是我在某家日商的時候,邊學邊做了解到如何解決問題的方法,我也覺得這是一個基本的觀念是用到每個領域內,
QCC其實有兩種一個是解決問題(問題改善),一個是達成目標(課題達成)的兩種,這次以解決問題說明為主
個人把QCC可以分成四大架構分別為(一)提出問題 、(二)解決問題的方法、(三)預防再發、(四)經驗累積
關於QCC簡單的入門書籍,非常推薦大家去看渡邊健介這位作者的兩本書,解決問題最簡單方法在故事中學會麥肯錫5大思考工具

[/et_pb_text][/et_pb_column][/et_pb_row][et_pb_row _builder_version=”3.25″ background_size=”initial” background_position=”top_left” background_repeat=”repeat”][et_pb_column type=”4_4″ _builder_version=”3.25″ custom_padding=”|||” custom_padding__hover=”|||”][et_pb_text _builder_version=”3.27.4″]

(一)提出問題

在環安衛上面不缺問題,因為問題一直一大堆,但是缺的不知道問題的本質,所以找出一個真正的問題,就是一個很重要的步驟 這個流程中會有幾個步驟:A:發現問題 B:制定計畫 C:確認現況 D:設定目標 [/et_pb_text][/et_pb_column][/et_pb_row][et_pb_row _builder_version=”3.25″ background_size=”initial” background_position=”top_left” background_repeat=”repeat”][et_pb_column type=”4_4″ _builder_version=”3.25″ custom_padding=”|||” custom_padding__hover=”|||”][et_pb_text _builder_version=”3.27.4″]

A:發現問題

這邊要提出的是何謂問題,通常問題就是理想與現實狀況(以下簡稱現況)的差距,但通常很多人都會將現況當作是問題,例如肚子餓這件事

理想是填飽肚子
現況是肚子餓
問題是現在沒辦法吃

通常大家都會將肚子餓當作是問題,問題應該不是肚子餓,應該是為什麼會造成肚子餓,接下來就是要去思考怎麼解決,怎麼樣可以吃東西,而且不一樣的原因,就會有不一樣的處理方式,例如:沒有錢對應的方式是準備錢,沒有餐廳就是找餐廳,不同的原因就會有不同的對應方式,這問題與辨識風險是有點類似的,大家可以參閱這篇文章(請點選)
發現到問題之後相信不會只有一個而已,而是可能會有很多的問題發生,那接下來要怎麼做呢??在這邊就是利用環安衛人員最擅長的風險矩陣法來進行評比就可以知道哪個是要先實施的

相關圖表如下方所示

[/et_pb_text][/et_pb_column][/et_pb_row][et_pb_row _builder_version=”3.25″ background_size=”initial” background_position=”top_left” background_repeat=”repeat” column_structure=”1_2,1_2″][et_pb_column type=”1_2″ _builder_version=”3.25″ custom_padding=”|||” custom_padding__hover=”|||”][et_pb_image src=”https://www.hbesh.net/wp-content/uploads/2018/02/螢幕快照-2018-02-27-上午4.55.19.png” align_tablet=”center” align_last_edited=”on|desktop” _builder_version=”3.23″][/et_pb_image][/et_pb_column][et_pb_column type=”1_2″ _builder_version=”3.25″ custom_padding=”|||” custom_padding__hover=”|||”][et_pb_image src=”https://www.hbesh.net/wp-content/uploads/2018/02/螢幕快照-2018-02-27-上午5.41.54.png” align_tablet=”center” align_last_edited=”on|desktop” _builder_version=”3.23″][/et_pb_image][/et_pb_column][/et_pb_row][et_pb_row _builder_version=”3.25″ background_size=”initial” background_position=”top_left” background_repeat=”repeat”][et_pb_column type=”4_4″ _builder_version=”3.25″ custom_padding=”|||” custom_padding__hover=”|||”][et_pb_text _builder_version=”3.27.4″]

B:制定計畫

當問題已經確立之後就是要擬定實施計畫,這邊最常見的計畫就是使用甘特圖,然而處理方式的步驟會先擬定一個大的架構,就是每個流程要做的事情
在這邊需要跟大家提醒一下事情,大框架是要以步驟流程去思考,不需要寫到很細,所以大計劃通常都會是整個架構上要執行的流程,通常會如下圖

[/et_pb_text][et_pb_image src=”https://www.hbesh.net/wp-content/uploads/2018/02/螢幕快照-2018-02-27-上午4.37.31.png” align_tablet=”center” align_last_edited=”on|desktop” _builder_version=”3.23″][/et_pb_image][et_pb_text _builder_version=”3.27.4″]

C:確認現況

就如同步驟A:問題為何,我們針對問題都只是假設的,但真正的問題為何,我們需要再確認到底是不是真正的問題,還有問題到底在哪裡,進行更進一步的確認,針對我們的想像問題去確認,我們要了解事實現況並確認是否真正的問題
確認真實的數據與理想間的真正差距是否存在,或者是在哪個地方存在明顯差距並用數據表現出來,而且最好使用三現主義(現場、現物、現實)去確認,通常我們可以透過直方圖比較一個相同的物質兩個不同時間點上的差異,並篩選出差異性最大的數值進行改善

[/et_pb_text][et_pb_image src=”https://www.hbesh.net/wp-content/uploads/2018/02/as.001.jpeg” align_tablet=”center” align_last_edited=”on|desktop” _builder_version=”3.23″][/et_pb_image][/et_pb_column][/et_pb_row][et_pb_row _builder_version=”3.25″ background_size=”initial” background_position=”top_left” background_repeat=”repeat”][et_pb_column type=”4_4″ _builder_version=”3.25″ custom_padding=”|||” custom_padding__hover=”|||”][et_pb_text _builder_version=”3.27.4″]

(二)解決問題的方法

在這邊是大家比較熟悉的原因分析,但是在這邊也會再跟各位說明幾個容易忽略的步驟 這個流程中會有幾個步驟:A:要因分析 B:對策實施 C:效果確認 [/et_pb_text][et_pb_text _builder_version=”3.27.4″]

A:要因分析

這個步驟會有分為兩個階段,(1)真因探討、(2)根因確認

(1)真因探討(確認問題的本質)

通常大家看到問題之後,都會急忙的直接進行直覺式的改善,但是希望各位要針對上述的問題,在思考發生的原因到底為何,不同的原因會有不同的方法處理,舉例而言,在日常生活中,我們會很自然的區分為症狀跟原因,例如咳嗽是一個症狀,但是引起咳嗽的原因是疾病,依照疾病的不同,使用各種不同的藥物治療,假設他是過敏則用過敏藥物,肺炎則是肺炎的藥物,感冒則是用感冒的藥物,所以是要對病因下藥,而不是針對症狀下藥物,所以直覺性的改善很容易落入對症狀下藥,而非對病因下藥,而在這邊大家最常做的方式一定是要因分析圖(魚骨圖),在這邊提供給各位幾個步驟,讓各位能得到更好的結果

a:先試著思考可能發生的原因並記錄下來
b:再將類似的原因進行分類
c:以剛剛b原因當成大分類,a原因當作小骨製作魚骨圖
d:魚骨圖透過反覆的五次自問自答得到最終的可能原因
e:選出最根本的原因

(2)根因確認

在這邊要跟大家提醒的是找到根因之後不要馬上就進行對策的建立,要先去確認這個根因是不是跟你想的一樣,再進行一次查證,此時我們還是會需要利用三現主義進行確認與查證,並利用數據進行兩者間的差異,在這邊建議要去注意數據盡可能不要使用平均化的數據,避免沒有看到在平均數據下的重大差異,可以針對人員別、時間別、系統別、製程別等等的方式多方面探討與分析

[/et_pb_text][et_pb_text _builder_version=”3.27.4″]

B:對策選出與實施

在前面的步驟內你可能會得到很多原因並且得到很多相對應的對策,但是在這邊我們可能很難進行實施每個對策,所以我們需要再使用一次矩陣圖進行分析得到可以實施的對策,針對實施的對策製作出可行性的計畫表,計畫表內通常會有(實施對策內容,真正的實施作法,執行者,截止日期)

[/et_pb_text][et_pb_text _builder_version=”3.27.4″]

C:效果確認

當實施完畢之後都要進行效果的確認,而效果要確認什麼?是要將先前找到問題這個步驟中所調查的數據,再進行一次的比對與分析並確認成效,在這邊建議大家可以將過程無形的效果,以及實際的產出的金額效果計算出來會更好

但在這邊要再拋給各位一個問題,這樣的時間點會不會太晚了,等到要做完了之後再確認,那如果無效的時候,那不就都失效了嗎??所以在這邊提供給各位一個簡單的作法,就是將查核點設計在對策實施的做法之中,這樣可以讓執行人員自我查核與提早提出問題,減少第三方的查核人力,達成一個有效的自我管理(查核點相關的文章請點選此

[/et_pb_text][/et_pb_column][/et_pb_row][et_pb_row _builder_version=”3.25″ background_size=”initial” background_position=”top_left” background_repeat=”repeat” custom_padding=”||0px|||”][et_pb_column type=”4_4″ _builder_version=”3.25″ custom_padding=”|||” custom_padding__hover=”|||”][et_pb_text _builder_version=”3.27.4″]

(三)預防再發

當我們集中力氣完成了問題的改善,當然我們希望這個效果可以完全的持續下去,所以最常見的就是標準化執行,但是在這邊要給所有的讀者一個觀念,短時間大量的時間去改善得到的效果一定會很好,但是長時間高張力的實施,只會把人逼瘋或者是放棄並不會有一個很好的效果,所以在這邊要跟各位讀者提醒,再要轉為例行性的作業時,一定要思考例行性的可執行性,將再先前做的最有成效跟最能反應狀況的查核點簡化並納入原有流程中這個步驟中常見的幾個方式分別下述幾件事情

A:製作標準化文件 B:公告並使所以人員知道 C:教育訓練與人員理解測試 D:確認之後的執行體系

[/et_pb_text][et_pb_text _builder_version=”3.27.4″]

(四)經驗累積

在改善的過程中一定會有好的地方跟不好的地方,通常我們都會過度的去檢討不好的事情,其實我們不應該去檢討而是思考下一次怎麼做會更好,但是我們更應該要記錄下來好的體驗,這些都是持續我們繼續下去,完成下一次改善的動力,以及讓下一次做更好的思考來源

[/et_pb_text][et_pb_text _builder_version=”3.27.4″]

結語

最後職業安全是一個適用到各行各業的應用學科,但是人員不可能會所有的行業別,所以如何發現問題以及處理問題就格外的重要了

希望透過這篇文章能給在職場上的職安人對於解決問題能有新的見解跟想法,對於文章中的內容如果有任不清楚或是想法,歡迎在下方留言給我們。

如果需要私下進行相關諮詢,歡迎透過下方的『加入好友』與我們連絡

其他任何商業邀約或是服務需求請Email:info@hbesh.net 我們會有專人跟您聯繫

[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section]
購物車
error: Content is protected !!
返回頂端