10 replies to this topic

[sukanya3507]

ตามห้วข้อกระทู้เลยค่ะ มาแชร์ข้อมูลกันนะคะ

[Food Safety]

หา Root Cause ให้ได้  แล้วกำหนด Corrective action ให้ชัดเจน

 

แค่นั้นจริงๆ

[dipsopha]

เรื่องนี้ดิ๊ฟเคยทำเป็นคลิปไว้นะคะ

เผื่อใครถนัดฟัง

https://youtu.be/oAiqyzm4rVk

[NaiO]

เกาให้ถูกที่คันครับ

[Aranya Chaiyachin]

อ้างอิงจาก ของอาจารย์ นุกูลนะคะ ซึ่งท่านเขียนได้ชัดเจนและเข้าใจง่ายที่สุด หากใครเป็น Fan page>> Factory Management by Nukool

ตามรายละเอียดข้างล่างเลยค่ะ ส่วนใครอยากได้อะไรเพิ่มเติม ก็ติดตาม Facebook ของอาจารย์ได้เลยค่ะ

 

สำหรับหนุ่มสาวชาวโรงงาน เราคงคุ้นเคยกับคำว่า CAR เป็นอย่างดี (CAR: Corrective Action Request) บางโรงงานอาจใช้ 8D (8 Discipline) ทั้ง 2 ตัวนี้ คือเครื่องมือในระบบการแก้ไขและการป้องกัน

แต่ในระบบนี้ ก็มีปัญหาต่าง ๆ มากมายให้เราได้เห็นกัน วันนี้จะขอแชร์มุมมองในเรื่องของการตอบ CAR ว่ามีปัญหาอะไรบ้าง ที่เราเจอกันอยู่บ่อย ๆ

ในมุมมองที่ว่า 
ตอบ CAR แบบนี้ พี่คิดได้ไงอ่ะ

1. ปัญหาเกิดซ้ำ แต่พี่ก็ตอบแบบเดิม

คือพี่ไม่คิดเหรอว่า เมื่อก่อนปัญหานี้มันเคยเกิดขึ้นแล้ว พี่แก้แบบนี้ไปแล้ว แต่มันเกิดซ้ำ มันแปลว่า วิธีการนั้น ๆ มันไม่ Work พี่ก็ยังจะตอบมาแบบเดิมอีก มันคืออัลไล หรือว่าไอ้ที่ตอบมาก่อนหน้านี้ พี่ไม่ได้ลงมือแก้จริง ๆ

 

2. เอะอะพี่ก็จะแก้ด้วยการอบรมลูกเดียว

อบกันจนพนักงานพี่ตัวดำหมดแล้ว คือพี่น่าจะวิเคราะห์หน่อยนะ บางปัญหามันเป็นปัญหาเชิงระบบ ไม่มีระบบรองรับ ไม่มีขั้นตอนการทำงานที่ชัดเจน ไม่มีระบบการดูแลเครื่องมืออุปกรณ์ เทคโนโลยีไม่ถึง ความแม่นยำหรือความสามารถของเครื่องจักรมันต่ำต้อย พี่ก็ควรไปแก้ในมุมมองนั้น ๆ บ้าง อย่าเอาแต่อบรมพนักงาน

 

3. เอาปัญหามาเขียนเป็นสาเหตุ

ปัญหา คือ ลูกค้าเคลมคืนสินค้า สาเหตุพี่ตอบมาว่า ลูกค้าเคลมคืนสินค้า มันคืออะไร รู้แล้วว่าลูกค้าเคลม ทำไมเขาเคลมล่ะ เขาเคลมเพราะอะไร พี่ต้องตอบแนวนั้น ไม่ใช่เอาปัญหามาเขียนเป็นสาเหตุอีกรอบ...พูดแล้วมันขึ้น !!!

 

4. การแก้ไขกับการป้องกัน พี่ก็ดันตอบเหมือนกันเด๊ะ

นี่ก็อีกอาการ ทรมานใจเหลือเกิน แนวทางในการแก้ไขกับการป้องกัน พี่ก็ตอบมาเหมือนกันเลย

พี่คิดง่าย ๆ นะ 
การแก้ไขคือทำยังไงให้ "ปัญหานี้" มันหายไป "ผลกระทบ" มันหมดไป ควบคุมได้ หรือ จัดการได้

ส่วนการป้องกัน คือ ทำยังไงไม่ให้ "สาเหตุของปัญหา" มันเกิดขึ้นได้อีก ปัญหามันจะได้ไม่เกิดขึ้นซ้ำ พี่จะ "ป้องกันเชิงระบบ" ยังไงในอนาคต

 

5. ปัญหาเกิดชาตินี้ แต่พี่ขอแก้ไขให้แล้วเสร็จภายในชาติหน้า

ปัญหาเล็ก ปัญหาใหญ่ แก้ยาก แก้ง่าย พี่ไม่ได้ตระหนักเลย กำหนดเสร็จในแต่ละเรื่อง แทบจะไปขอยืมประตูข้ามกาลเวลาของโดเรม่อนมาติดตามกันเลยทีเดียว มันจะนานไปไหน ถ้าพี่มีแผนระยะยาวมาก พี่ก็ซอยเป็นแผนระยะสั้นมาตอบก่อน ไม่ใช่บอกว่า ขอแก้ไขให้เสร็จภายใน 3 ปี 5 ปี ถึงตอนนั้น บริษัทฯ คงปิดกิจการไปก่อนแล้วมั้งพี่ ... 

-----
Credit อาจารย์นุกูล ทะนวนรัมย์
  FM Master

[sukanya3507]

ขอบคุณทุกคนมากๆ นะคะ สำหรับความรู้และข้อมูลค่าาา

[iso_man]

หลักการง่ายอย่าไปคิดเยอะ ได้แก่

1. เอาปัญหาที่เกิดขึ้นมาทบทวนก่อนว่าชัดเจนหรือไม่ ครบถ้วนหรือไม่ จากนั้นไปดูของจริง สภาพจริง สถานที่จริง เพื่อยืนยันสิ่งที่กำลังจะค้นหาสาเหตุ

2. นำสิ่งทีทบทวนมาค้นหาสาเหตุใช้หลัก 4M หรือ 5M โดยเอา M Man ไว้ถามหลังสุด

3. เช่น  ทวนสอบถามหามาตรฐาน หรือ มาตรการมีหรือไม่ หรือมีการให้ความรู้คนเกี่ยวข้องไหม หรือ มีการกำหนดความจำเป็นในการสร้างให้เกิดความสามารถไหม หรือ มีการตรวจเช็ค การทำงานตามมาตฐานที่กำหนดไหม หรือมีอะไรไปช่วยในการตรวจสอบไหม

4. ได้ต้นตอแล้วจึงมากำหนดแนวทางการแก้ไขเป็นรูปธรรม

5. จากนั้นตรวจติดตามปัญหาดังกล่าวลดลงหรือไม่ หรือหายไปไหม

[krissarakorn]

 

อ้างอิงจาก ของอาจารย์ นุกูลนะคะ ซึ่งท่านเขียนได้ชัดเจนและเข้าใจง่ายที่สุด หากใครเป็น Fan page>> Factory Management by Nukool

ตามรายละเอียดข้างล่างเลยค่ะ ส่วนใครอยากได้อะไรเพิ่มเติม ก็ติดตาม Facebook ของอาจารย์ได้เลยค่ะ

 

สำหรับหนุ่มสาวชาวโรงงาน เราคงคุ้นเคยกับคำว่า CAR เป็นอย่างดี (CAR: Corrective Action Request) บางโรงงานอาจใช้ 8D (8 Discipline) ทั้ง 2 ตัวนี้ คือเครื่องมือในระบบการแก้ไขและการป้องกัน

แต่ในระบบนี้ ก็มีปัญหาต่าง ๆ มากมายให้เราได้เห็นกัน วันนี้จะขอแชร์มุมมองในเรื่องของการตอบ CAR ว่ามีปัญหาอะไรบ้าง ที่เราเจอกันอยู่บ่อย ๆ

ในมุมมองที่ว่า 
ตอบ CAR แบบนี้ พี่คิดได้ไงอ่ะ

1. ปัญหาเกิดซ้ำ แต่พี่ก็ตอบแบบเดิม

คือพี่ไม่คิดเหรอว่า เมื่อก่อนปัญหานี้มันเคยเกิดขึ้นแล้ว พี่แก้แบบนี้ไปแล้ว แต่มันเกิดซ้ำ มันแปลว่า วิธีการนั้น ๆ มันไม่ Work พี่ก็ยังจะตอบมาแบบเดิมอีก มันคืออัลไล หรือว่าไอ้ที่ตอบมาก่อนหน้านี้ พี่ไม่ได้ลงมือแก้จริง ๆ

 

2. เอะอะพี่ก็จะแก้ด้วยการอบรมลูกเดียว

อบกันจนพนักงานพี่ตัวดำหมดแล้ว คือพี่น่าจะวิเคราะห์หน่อยนะ บางปัญหามันเป็นปัญหาเชิงระบบ ไม่มีระบบรองรับ ไม่มีขั้นตอนการทำงานที่ชัดเจน ไม่มีระบบการดูแลเครื่องมืออุปกรณ์ เทคโนโลยีไม่ถึง ความแม่นยำหรือความสามารถของเครื่องจักรมันต่ำต้อย พี่ก็ควรไปแก้ในมุมมองนั้น ๆ บ้าง อย่าเอาแต่อบรมพนักงาน

 

3. เอาปัญหามาเขียนเป็นสาเหตุ

ปัญหา คือ ลูกค้าเคลมคืนสินค้า สาเหตุพี่ตอบมาว่า ลูกค้าเคลมคืนสินค้า มันคืออะไร รู้แล้วว่าลูกค้าเคลม ทำไมเขาเคลมล่ะ เขาเคลมเพราะอะไร พี่ต้องตอบแนวนั้น ไม่ใช่เอาปัญหามาเขียนเป็นสาเหตุอีกรอบ...พูดแล้วมันขึ้น !!!

 

4. การแก้ไขกับการป้องกัน พี่ก็ดันตอบเหมือนกันเด๊ะ

นี่ก็อีกอาการ ทรมานใจเหลือเกิน แนวทางในการแก้ไขกับการป้องกัน พี่ก็ตอบมาเหมือนกันเลย

พี่คิดง่าย ๆ นะ 
การแก้ไขคือทำยังไงให้ "ปัญหานี้" มันหายไป "ผลกระทบ" มันหมดไป ควบคุมได้ หรือ จัดการได้

ส่วนการป้องกัน คือ ทำยังไงไม่ให้ "สาเหตุของปัญหา" มันเกิดขึ้นได้อีก ปัญหามันจะได้ไม่เกิดขึ้นซ้ำ พี่จะ "ป้องกันเชิงระบบ" ยังไงในอนาคต

 

5. ปัญหาเกิดชาตินี้ แต่พี่ขอแก้ไขให้แล้วเสร็จภายในชาติหน้า

ปัญหาเล็ก ปัญหาใหญ่ แก้ยาก แก้ง่าย พี่ไม่ได้ตระหนักเลย กำหนดเสร็จในแต่ละเรื่อง แทบจะไปขอยืมประตูข้ามกาลเวลาของโดเรม่อนมาติดตามกันเลยทีเดียว มันจะนานไปไหน ถ้าพี่มีแผนระยะยาวมาก พี่ก็ซอยเป็นแผนระยะสั้นมาตอบก่อน ไม่ใช่บอกว่า ขอแก้ไขให้เสร็จภายใน 3 ปี 5 ปี ถึงตอนนั้น บริษัทฯ คงปิดกิจการไปก่อนแล้วมั้งพี่ ... 

-----
Credit อาจารย์นุกูล ทะนวนรัมย์
  FM Master

 

 

ชอบตรงนี้มากๆ ตรงใจจริงๆ บัวเหล่าที่ห้า ยากเยียวยา จริงๆ 

[chorchorp]

เมื่อก่อนเป็น QA มา  6 ปี ก็คิดแบบด้านบนที่ท่านๆ ว่ากันมา

มาตอนนี้ มาเป็นฝ่ายผลิต เข้าปีที่ 4  ในระดับที่ต้องเซ็นอนุมัติการดำเนินการ ผมยกตัวอย่างแค่ 2 ฝ่ายนะครับ

 

บางอย่างฝ่ายผลิตดำเนินการตามหลักการที่ควรจะทำไม่ได้ ไม่ใช่ไม่อยากทำ แต่ทำแล้วมันขาดทุน ประสิทธิภาพต่ำ สินค้่าเสียเพิ่มขึ้น เทคโนโลยีไม่ถึงหรือต้องใช้งบประมาณสูง สิ่งเหล่านี้ ฝ่ายที่ออก CAR ไม่ได้มารับผิดชอบกับฝ่ายที่ดำเนินการแก้ไขด้วย 

 

              "หน้าที่คุณๆก็แก้ไปซิ ฉั้นแค่ต้องการคำตอบที่มันแก้ปัญหานี้ได้ ถ้ามีปัญหาอื่นๆเกิดขึ้น ก็เป็นเรื่องของคุณ"   นี่คือสิ่งที่ได้รับจากฝ่ายที่ออก CAR

บางที่ผู้ที่ดำเนินการแก้ไขทราบสาเหตุของปัญหาดีและผมคิดว่าเค้าทราบวิธีแก้ไขที่ดีที่สุดด้วยซ้ำ แต่ทำไม่ได้ เขียนใน CAR ก็ไม่ได้ ก็เลยต้องตอบแบบแถๆ ไป

 

ที่ผมจะบอกคือทุกอย่างมันมีเหตุและผลที่ต่างกัน เราต้องฟังทุกเหตุและทุกผลแล้วค่อยมาชั่งน้ำหนัก หาทางออกที่ดีที่สุด ไม่ใช่ถูกต้องที่สุด

 

ถือว่าผมมาเล่าให้ฟังแล้วกัน 

 

 

 

[krissarakorn]

เมื่อก่อนเป็น QA มา  6 ปี ก็คิดแบบด้านบนที่ท่านๆ ว่ากันมา

มาตอนนี้ มาเป็นฝ่ายผลิต เข้าปีที่ 4  ในระดับที่ต้องเซ็นอนุมัติการดำเนินการ ผมยกตัวอย่างแค่ 2 ฝ่ายนะครับ

 

บางอย่างฝ่ายผลิตดำเนินการตามหลักการที่ควรจะทำไม่ได้ ไม่ใช่ไม่อยากทำ แต่ทำแล้วมันขาดทุน ประสิทธิภาพต่ำ สินค้่าเสียเพิ่มขึ้น เทคโนโลยีไม่ถึงหรือต้องใช้งบประมาณสูง สิ่งเหล่านี้ ฝ่ายที่ออก CAR ไม่ได้มารับผิดชอบกับฝ่ายที่ดำเนินการแก้ไขด้วย 

 

              "หน้าที่คุณๆก็แก้ไปซิ ฉั้นแค่ต้องการคำตอบที่มันแก้ปัญหานี้ได้ ถ้ามีปัญหาอื่นๆเกิดขึ้น ก็เป็นเรื่องของคุณ"   นี่คือสิ่งที่ได้รับจากฝ่ายที่ออก CAR

บางที่ผู้ที่ดำเนินการแก้ไขทราบสาเหตุของปัญหาดีและผมคิดว่าเค้าทราบวิธีแก้ไขที่ดีที่สุดด้วยซ้ำ แต่ทำไม่ได้ เขียนใน CAR ก็ไม่ได้ ก็เลยต้องตอบแบบแถๆ ไป

 

ที่ผมจะบอกคือทุกอย่างมันมีเหตุและผลที่ต่างกัน เราต้องฟังทุกเหตุและทุกผลแล้วค่อยมาชั่งน้ำหนัก หาทางออกที่ดีที่สุด ไม่ใช่ถูกต้องที่สุด

 

ถือว่าผมมาเล่าให้ฟังแล้วกัน 

 

 

 

ผมเห็นด้วยอย่างยิ่งเลยครับ  แต่บางคนไม่คิดอย่างนี้ พฤติกรรมเห็นชัดเจนว่าไม่ใส่ใจ อันนี้ต่างหากที่เป็นปัญหา, การทำงานในภาคธุรกิจ สิ่งที่ต้องคิดคือ ทำอย่างไรให้ธุรกิจไปต่อได้  เน้นผลิตก็จะขาด Brand Royalty จากลูกค้า และจะขายของไม่ได้ในอนาคต, เน้นคุณภาพเกินความต้องการของลูกค้าก็จะสู้คู่แข่งไม่ได้, ดังนั้นมันต้องไปด้วยกัน ทำแต่พอเหมาะพอดี และดูธรรมชาติขององค์กร วัฒธรรมองค์กรด้วย เอกสารเยอะก็ทำงานช้าลง ไม่มีเอกสารบันทึกเลยก็สอบกลับไม่ได้ไม่มีข้อมูลให้มาวิเคราะห์ปรับปรุง บางอย่างแก้ได้ด้วย QCC, KAIZEN, Visual Control, Pokayoke, เพื่อลดการทำงานที่ไม่จำเป็น ลดขั้นตอน ลดเอกสาร ลดความซับซ้อน หากปรึกษากันได้ระหว่างคนออก CAR ที่มองเห็นปัญหา กับเจ้าของปัญหา เรื่องบางเรื่องก็มีทางออกได้ง่ายขึ้น ..

[iso_man]

นั้นแนะนำว่าการทำอะไรก็แล้วแต่พิจารณาค้นหาความเสี่ยงหรือโอกาสเข้าไปในการทำงาน เพื่อหาวิธีการจัดการลด หรือ บางเรื่องที่หลายท่านบอกว่าลงทุนเยอะ ทำเอกสารมากมาย ไปทำกำหนดการจัดการทั้งการลด หรือ ยอมรับกับความเสี่ยงนั้น ตามความต้องการของ ISO version2015 ที่ต้องการให้เราป้องกันก่อนการแก้ไข