สอบสวนอุบัติเหตุด้วย 5 Whys + Fishbone — สอนใช้จริงเป็นขั้น

วันจันทร์เช้า พนักงานคนหนึ่งลื่นล้มในห้องครัวโรงอาหารโรงงาน ข้อเท้าพลิก หยุดงาน 3 วัน หัวหน้าโรงอาหารบอก จป. ว่า "ก็เขาเดินไม่ระวังเอง" — แล้วก็จบที่ตรงนั้น เดือนต่อมาเกิดเหตุแบบเดิมอีกคน คราวนี้สะโพกหัก

ที่หลายโรงงานเจอแบบนี้คือ "หยุดสอบสวนเร็วเกินไป" — หาคนผิดได้ แต่ไม่ได้แก้ปัญหา กฎหมายไทยกำหนดชัดว่าทุกอุบัติการณ์ต้องสอบสวนหาสาเหตุ และต้องนำผลไปแก้ระบบเพื่อกันเหตุซ้ำ ลองดูกันว่า 2 เครื่องมือมาตรฐานที่ใช้ในวงการ — 5 Whys และ Fishbone — ทำงานอย่างไร เริ่มที่จุดไหน และจะเขียนรายงานออกมาให้ผ่านสายตาผู้บริหารได้ยังไง

ทำไมต้องสอบสวนอุบัติเหตุ

มี 3 เหตุผลที่ทำให้การสอบสวนเป็นงานที่ จป. ทุกคนต้องทำเป็น

เหตุผลที่ 1 — กฎหมายบังคับ กฎกระทรวงระบบการจัดการด้านความปลอดภัย พ.ศ. 2565 ข้อ 10(2) กำหนดให้นายจ้างต้อง "มีการสอบสวนหาสาเหตุของการเกิดอุบัติการณ์ การเจ็บป่วย โรคจากการทำงานหรือความเสียหายต่อทรัพย์สิน" สังเกตคำสำคัญ — กฎหมายไม่ได้กำหนดแค่ "อุบัติเหตุที่บาดเจ็บ" แต่รวมถึง อุบัติการณ์ (incident) ที่ไม่มีคนเจ็บด้วย และรวม ความเสียหายต่อทรัพย์สิน เช่น เครื่องจักรพัง ของหล่นใส่ของ เพลิงไหม้เล็ก ที่ไม่มีคนเจ็บ

เหตุผลที่ 2 — กฎหมายต่อ — ต้องนำผลไปแก้ระบบ ข้อ 10(2) ของกฎกระทรวงเดียวกันบังคับให้ผลสอบสวนต้องนำไปสู่ "การกำหนดมาตรการในการแก้ไขและปรับปรุงระบบการจัดการด้านความปลอดภัย และกำหนดมาตรการป้องกันการเกิดเหตุดังกล่าวซ้ำอีก" ถ้าสอบสวนแล้วไม่ออกมาตรการแก้ — ถือว่ายังทำตามกฎหมายไม่ครบ

เหตุผลที่ 3 — กรณีเหตุร้ายแรง ต้องแจ้งราชการ พ.ร.บ. ความปลอดภัยฯ พ.ศ. 2554 มาตรา 34 วรรคสอง กำหนดให้สถานประกอบกิจการแจ้งการเกิด อุบัติภัยร้ายแรง หรือ การประสบอันตรายจากการทำงาน ต่อพนักงานตรวจความปลอดภัยตามแบบที่อธิบดีประกาศกำหนด รายงานสอบสวนคือเอกสารตั้งต้นที่ทำให้คุณกรอกแบบฟอร์มแจ้งราชการได้ครบทุกช่อง

นอกจาก 3 ข้อนี้ การทบทวนระบบ OSH "อย่างน้อยปีละหนึ่งครั้ง" ก็ต้องเอาผลสอบสวนแต่ละเคสไปวิเคราะห์รวม ดูแนวโน้มข้อบกพร่อง — รายงานสอบสวนจึงไม่ใช่เอกสารแค่ปิดเคส แต่เป็นวัตถุดิบ "เลี้ยง" ระบบให้ดีขึ้นทุกปี

โยงต่อ — ระบบบริหารจัดการความปลอดภัย (SMS) ตามกฎ 2565 มีรายละเอียดว่าระบบที่กฎหมายต้องการมี 5 องค์ประกอบอะไรบ้าง การสอบสวนเป็นส่วนหนึ่งของ "การประเมินผลและการทบทวน"

เก็บข้อมูลก่อนเริ่ม — งานที่ต้องทำใน 24 ชั่วโมงแรก

ก่อนจะเข้าสู่เครื่องมือวิเคราะห์ (5 Whys / Fishbone) มีงานเก็บข้อมูลที่ต้องทำให้เสร็จก่อน ถ้าข้ามขั้นนี้ — เครื่องมือวิเคราะห์ใดก็ช่วยไม่ได้ เพราะข้อมูลตั้งต้นผิด

1. รักษาที่เกิดเหตุ (Secure the scene)

ปิดกั้นพื้นที่ — กั้นเทป กรวยจราจร หรือกั้นด้วยคนยืนเฝ้า ห้ามใครเข้าไปเปลี่ยนตำแหน่งของสิ่งของ ห้ามเก็บกวาด ห้ามซ่อม จนกว่า จป. จะถ่ายรูป/วิดีโอครบ ในโรงงานหลายแห่งหัวหน้ากะรีบ "เคลียร์ไลน์" ให้เดินต่อก่อน — นี่คือจุดที่ทำให้หลักฐานหายไปครึ่งหนึ่ง

ข้อยกเว้น — ถ้าผู้บาดเจ็บยังอยู่ในจุด ต้องช่วยก่อน ทุกอย่างรอได้

2. สัมภาษณ์พยานทันที

ความจำของพยานสดที่สุดในช่วง 24 ชั่วโมงแรก ถ้าปล่อยไป 3 วัน ทุกคนจะเริ่ม "ปรับเรื่อง" ให้สอดคล้องกัน ทำให้ข้อมูลผสมกัน

สัมภาษณ์ทีละคน แยกห้อง ถามด้วยคำถามเปิด ไม่ใช่คำถามนำ

• ดี: "ตอนเกิดเหตุ คุณเห็นอะไรบ้าง" (เปิด)
• ไม่ดี: "ตอนนั้นเขาวิ่งใช่ไหม" (นำ — พยานจะตอบใช่ตามที่คุณเดา)

จดบันทึก หรือบันทึกเสียงถ้าพยานอนุญาต ขอลายเซ็นกำกับท้ายบันทึก

3. ถ่ายรูป + วิดีโอ + แผนผัง

ถ่ายรูปจากหลายมุม — มุมกว้าง มุมใกล้ มุมจากด้านบน รวมตำแหน่งสวิตช์เครื่อง ป้ายเตือน พื้นผิว สภาพแสง รวมถึง PPE ที่ผู้บาดเจ็บใส่ (หรือไม่ได้ใส่) ถ้ามีกล้องวงจรปิด — สำเนาคลิปเก็บทันที กล้องบางรุ่นเขียนทับใน 7 วัน

วาดแผนผังคร่าวๆ ของที่เกิดเหตุ ระบุตำแหน่งคน อุปกรณ์ ทิศการเคลื่อนที่ ระยะทาง

4. เก็บ evidence ทางกายภาพ

• PPE ที่เสียหาย — เก็บไว้ ห้ามทิ้ง
• ชิ้นส่วนเครื่องจักรที่หัก
• ตัวอย่างสารเคมีที่หก (ถ้าปลอดภัยจะเก็บ)
• บันทึก log ของเครื่อง — ค่าอุณหภูมิ ความดัน รอบเครื่อง ในช่วงเหตุการณ์
• ใบ permit-to-work ที่อนุมัติให้งานนี้

ลองคิดดู — ถ้าเป็นโรงงานคุณตอนนี้ มีใครรู้บ้างว่าต้อง secure scene ก่อน หรือทุกคนรีบเข้าไปช่วยจัดของเพื่อเดินไลน์ต่อ

5 Whys — เครื่องมือถามทำไม 5 ชั้น

ที่มา 5 Whys คือเทคนิคที่ Sakichi Toyoda ผู้ก่อตั้ง Toyota คิดขึ้น และกลายเป็นส่วนหนึ่งของ Toyota Production System จนแพร่ไปทั่วโลก เป็น เครื่องมืออุตสาหกรรม (industry tool) — ไม่ใช่ข้อกำหนดของกฎหมายไทย กฎหมายบอกแค่ "ต้องสอบสวน" แต่ไม่ระบุวิธี — 5 Whys เป็นวิธีที่นิยมเพราะใช้ง่าย ไม่ต้องอบรมพิเศษ

หลักการ

ถามคำว่า "ทำไม" ซ้อนกัน 5 ชั้น โดยแต่ละชั้นต้องใช้คำตอบของชั้นก่อนหน้าเป็นโจทย์

หัวใจคือ — ทุก ๆ "ทำไม" ต้องตอบด้วย ข้อเท็จจริงที่ verify ได้ ไม่ใช่การเดา ถ้าคำตอบเป็นสมมติฐาน ต้องไปหาหลักฐานก่อนจะเดินต่อชั้นถัดไป

ขั้นตอนทำ

ขั้นที่ 1 — เขียน Problem statement ระบุปัญหาเป็นข้อเท็จจริง 1 ประโยค ไม่มีการกล่าวโทษ ไม่มีการเดาสาเหตุ

ตัวอย่างดี — "พนักงานครัว A ลื่นล้มในห้องครัวโรงอาหาร เวลา 08:15 วันที่ 5 พ.ค. ข้อเท้าพลิก หยุดงาน 3 วัน"

ตัวอย่างไม่ดี — "พนักงานประมาทไม่ระวังตัวเอง" (ตัดสินไปแล้ว ไม่ใช่ข้อเท็จจริง)

ขั้นที่ 2 — ถาม "ทำไม" รอบที่ 1 ถึง 5 ใช้ตัวอย่างเดิมเดินต่อ

Q1: ทำไมพนักงานครัว A ลื่นล้ม? A1: เพราะพื้นห้องครัวมีน้ำมันบนกระเบื้อง (verify ด้วยภาพถ่าย)

Q2: ทำไมพื้นห้องครัวมีน้ำมัน? A2: เพราะกระทะทอดน้ำมันกระเด็นออกระหว่างทอด (verify ด้วย CCTV)

Q3: ทำไมน้ำมันกระเด็นออกถึงพื้น? A3: เพราะกระทะวางอยู่บนเตาที่ไม่มี splash guard และระยะระหว่างเตากับทางเดินแคบ 60 ซม.

Q4: ทำไมไม่มี splash guard และทางเดินแคบ? A4: เพราะการออกแบบห้องครัวไม่เคยถูกประเมินอันตรายด้านการลื่นล้ม

Q5: ทำไมไม่เคยประเมินอันตราย? A5: เพราะห้องครัวโรงอาหารถูกจัดอยู่ในกลุ่ม "ไม่ใช่งานผลิต" — ไม่อยู่ใน HIRARC ของกิจการ

หยุดที่ Q5 เพราะคำตอบสุดท้ายอยู่ในระดับ ระบบ แล้ว ไม่ใช่ระดับคน

ขั้นที่ 3 — ตรวจ logic chain อ่านจากบนลงล่าง ทุกประโยคต้องเชื่อมตามตรรกะ — "ถ้า A เกิด → จะมี B เกิดด้วย" ถ้าช่วงไหนเชื่อมไม่ได้ ต้องกลับไปหาข้อมูลเพิ่ม

ขั้นที่ 4 — หยุดเมื่อเจอ root cause ระดับระบบ ไม่จำเป็นต้องครบ 5 — บางเคส 3 ครั้งก็เจอ บางเคสต้องลึกถึง 7

Stop rule — ห้ามจบที่ "human error"

ถ้าคำตอบของ 5 Whys คือ "พนักงานประมาท / ลืม / ไม่ระวัง" — ยังขุดไม่พอ ต้องถามต่อว่า "ทำไมพนักงานถึงทำผิด" — ขุดต่อไปอีก เพราะระบบที่ดีต้องรับมือ human error ได้ ไม่ใช่หวังว่าคนจะไม่ผิด

Fishbone (Ishikawa) — เครื่องมือ 6 ก้าง

ที่มา Fishbone Diagram ถูกพัฒนาโดย Kaoru Ishikawa นักวิชาการคุณภาพชาวญี่ปุ่น ในช่วงปี 1960 ใช้กับวงการ Quality Control ก่อน แล้วลามมาที่ Safety ทีหลัง ก็เป็น เครื่องมือมาตรฐานอุตสาหกรรม เช่นเดียวกับ 5 Whys ไม่ใช่ข้อบังคับของกฎหมายไทย

เมื่อไหร่ใช้ Fishbone

• เคสที่มี หลายปัจจัย ซ้อนกัน — ไม่มีสาเหตุเดียวที่ชัด
• เคสที่ทีมสอบสวนเห็นไม่ตรงกันว่าควรขุดด้านไหน
• เคสซับซ้อนที่ 5 Whys ไม่ครอบ (5 Whys เก่งเรื่อง linear chain แต่ไม่เก่งเรื่อง multi-factor)

โครงสร้าง 6M

ก้างปลา 6 ก้างที่ใช้กันใน Safety คือ 6M Framework

ก้าง	ครอบคลุม	ตัวอย่างคำถาม
Man (คน)	ทักษะ การอบรม ภาวะ การมีอยู่ของคน	ผ่านอบรมงานนี้หรือยัง · พักผ่อนพอไหม · มีจำนวนคนพอไหม
Machine (เครื่องจักร)	สภาพเครื่อง การบำรุงรักษา การออกแบบ	เครื่องอายุเท่าไหร่ · มี guard ครบไหม · ตรวจซ่อมล่าสุดเมื่อไหร่
Material (วัสดุ)	คุณภาพวัสดุ การจัดเก็บ SDS	วัสดุได้สเปกไหม · เก็บถูกที่ไหม · ฉลากชัดไหม
Method (วิธีการ)	SOP ขั้นตอน permit	มี SOP ไหม · พนักงานทำตามไหม · permit ครบไหม
Measurement (การวัด)	การตรวจสอบ การวัดค่า	มีค่ามาตรฐานไหม · เครื่องวัดสอบเทียบล่าสุดเมื่อไหร่
Mother Nature (สภาพแวดล้อม)	แสง อุณหภูมิ ความชื้น พื้น เสียง	แสงพอไหม · พื้นลื่นไหม · ร้อนเกินไปไหม

ขั้นตอนทำ

1. เขียนหัวปลา — ปัญหาเดียวที่ต้องหาสาเหตุ (เหมือน problem statement ของ 5 Whys)
2. วาดก้าง 6 ก้าง — Man / Machine / Material / Method / Measurement / Mother Nature
3. Brainstorm สาเหตุย่อย — ทีมช่วยกันคิดทุกสาเหตุที่เป็นไปได้ในแต่ละก้าง โดยไม่ตัดสินก่อน
4. Verify ด้วย evidence — แต่ละสาเหตุที่ขึ้น diagram ต้อง verify ว่า "เกิดจริง" หรือ "เป็นไปได้" — เก็บเฉพาะที่ verify ได้
5. Highlight contributing causes — วงกลม 3-5 ก้างย่อยที่ส่งผลจริงที่สุด เพื่อกำหนดมาตรการ

ตัวอย่างกรณีพนักงานลื่นในห้องครัว — Fishbone อาจชี้ว่า contributing causes มาจาก 3 ก้างพร้อมกัน

• Method — ไม่มี SOP ทำความสะอาดน้ำมันระหว่างกะ
• Machine — เตาไม่มี splash guard
• Mother Nature — กระเบื้องผิวเรียบไม่กันลื่น + แสงในจุดเตาไม่พอ

5 Whys vs Fishbone — เลือกใช้ตอนไหน

สถานการณ์	ใช้ตัวไหน
เหตุการณ์มี chain ชัด สาเหตุหลักเดียว	5 Whys
เหตุการณ์มีหลายปัจจัยซ้อน ไม่ชัดว่าเริ่มที่ไหน	Fishbone
ทีมเห็นไม่ตรงกันว่าควรขุดด้านไหน	Fishbone (ครอบทุกก้าง)
ต้องอธิบายให้ผู้บริหารที่ไม่ใช่ Safety เข้าใจเร็ว	5 Whys (linear อ่านง่าย)
Audit ISO 45001 / SMS 2565	ใช้ได้ทั้งคู่ — แต่ Fishbone ทำให้ครอบสาเหตุเชิงระบบครบกว่า

เคสจริงในโรงงานมักใช้ 2 ตัวร่วมกัน — Fishbone ก่อนเพื่อจัดกลุ่มสาเหตุ แล้วเลือกก้างย่อยที่สำคัญ ลึกต่อด้วย 5 Whys

ข้อผิดพลาดที่เจอบ่อย

หลายคนทำสอบสวนแล้วได้รายงานที่ "ดูดี" แต่ไม่ลดอุบัติเหตุจริง เพราะติด pattern เหล่านี้

1. หยุดที่ "human error" เป็นกับดักคลาสสิก — เจอคนผิดก็จบ ไม่ขุดต่อว่าทำไมระบบถึงปล่อยให้คนพลาดได้ ผลคือ — มาตรการแก้กลายเป็น "อบรมพนักงานเพิ่ม" / "ตักเตือน" ซึ่งไม่ยั่งยืน

2. Blame culture ถ้าวัฒนธรรมในบริษัท "ใครผิดต้องโดน" — พยานจะไม่กล้าพูดความจริง ข้อมูลที่ได้จะ bias หมด ทางแก้ — ประกาศชัดว่า "การสอบสวนนี้ไม่ใช่เพื่อหาคนลงโทษ แต่เพื่อแก้ระบบ"

3. ไม่ verify ด้วย evidence ใช้คำว่า "น่าจะ" / "คิดว่า" ใน 5 Whys หรือ Fishbone — ทุกสาเหตุที่ขึ้นรายงานต้องมีหลักฐานยืนยัน รูป CCTV log บันทึก สัมภาษณ์

4. มาตรการแก้ไม่ตรงสาเหตุ root cause บอกว่า "ห้องครัวไม่อยู่ใน HIRARC" แต่ corrective action เขียนว่า "อบรมพนักงานครัว 1 ชม." — ไม่ตรง root cause ที่แท้ต้องคือ "เพิ่มห้องครัวเข้า HIRARC + ทำ JSA ของงานทอด"

5. ไม่ระบุ Owner + Due date มาตรการที่ไม่มีคนรับผิดชอบและกำหนดเวลา = มาตรการที่ไม่ทำ ทุกข้อต้องระบุชื่อคนและวันเสร็จ

6. สอบสวนเฉพาะเหตุที่บาดเจ็บ กฎหมายข้อ 10(2) บอกว่ารวมถึง อุบัติการณ์ที่ไม่บาดเจ็บ และ ความเสียหายต่อทรัพย์สิน ด้วย ถ้าเก็บแค่เคสที่บาดเจ็บ — พลาด near-miss ที่จริงๆ มีค่าวิเคราะห์มาก

7. ลืมแจ้งราชการเมื่อเป็นอุบัติภัยร้ายแรง มาตรา 34 วรรคสอง บังคับให้แจ้งพนักงานตรวจความปลอดภัย ถ้าไม่แจ้งมีโทษตามกฎหมาย — อย่าให้รายงานสอบสวนของตัวเองดีแต่พลาดขั้นนี้

ตัวเชื่อมต่อ — การป้องกันเหตุซ้ำที่ยั่งยืน คือเปลี่ยน reactive (สอบสวนหลังเกิด) → proactive (หาความเสี่ยงก่อนเกิด) เครื่องมือสำคัญตัวหนึ่งคือ JSA (Job Safety Analysis) — แตกงานเป็นขั้น วิเคราะห์ก่อนลงมือ

เทมเพลตรายงานสอบสวนอุบัติเหตุ

โครงสร้างมาตรฐานที่ใช้ได้ทุกเคส — กฎหมายไม่ได้กำหนดฟอร์ม แต่ข้อมูลต่อไปนี้คือ minimum ที่รายงานทุกฉบับควรมี

รายงานสอบสวนอุบัติเหตุ — เลขที่ INC-2026-001

ส่วนที่ 1: ข้อมูลทั่วไป
- วันเวลาที่เกิด: ___________
- สถานที่: ___________ (ระบุจุดละเอียด)
- ผู้บาดเจ็บ/ผู้เกี่ยวข้อง: ___________
- ประเภทเหตุ: บาดเจ็บ / near-miss / ทรัพย์สินเสียหาย
- ความรุนแรง: ปฐมพยาบาล / หยุดงาน N วัน / พิการ / เสียชีวิต

ส่วนที่ 2: ลำดับเหตุการณ์ (Chronology)
- เล่าตามเวลาจริง ทีละนาที จากก่อนเกิดเหตุถึงหลังเหตุ
- อิงข้อเท็จจริง ไม่ใส่ความเห็น

ส่วนที่ 3: หลักฐาน
- รูปถ่าย (แนบหมายเลข)
- CCTV (ระบุไฟล์)
- รายชื่อพยานสัมภาษณ์
- บันทึกเครื่อง / SDS / permit

ส่วนที่ 4: การวิเคราะห์สาเหตุ
- ใช้ 5 Whys / Fishbone / ทั้งคู่ — แนบ diagram
- ระบุ root cause (1-3 ข้อ)
- ระบุ contributing factors

ส่วนที่ 5: มาตรการแก้ไขและป้องกัน
| มาตรการ | Hierarchy of Control | Owner | Due date | Status |
|---|---|---|---|---|
| | Elimination / Substitution / Engineering / Admin / PPE | | | |

ส่วนที่ 6: บทเรียน (Lessons learned)
- 2-3 บทเรียนสำหรับทั้งกิจการ
- จะสื่อสารผ่านช่องทางใด (Toolbox Talk / training / SOP update)

ส่วนที่ 7: การแจ้งราชการ (ถ้าเข้าเกณฑ์)
- ส่งแบบแจ้งตามมาตรา 34 วรรคสอง วันที่ ___________
- เลขรับ ___________

ลงนาม
- ผู้สอบสวน (จป.) ___________  วันที่ ___________
- ผู้ทบทวน (หัวหน้าหน่วยงาน) ___________  วันที่ ___________
- ผู้อนุมัติ (นายจ้าง/ผู้บริหาร) ___________  วันที่ ___________

หัวใจของส่วนที่ 5 คือ Hierarchy of Control — มาตรการที่ดีต้องอยู่ในชั้นบน (Elimination → Engineering) ไม่ใช่กระจุกที่ Admin/PPE ทุกข้อ

Checklist สรุปสั้น

ก่อนปิดเคส ตรวจตัวเองด้วยรายการนี้

• secure scene ภายใน 1 ชั่วโมงแรก
• สัมภาษณ์พยานสดภายใน 24 ชั่วโมง
• ถ่ายรูป/วิดีโอ/CCTV เก็บไว้ครบ
• เก็บ evidence ทางกายภาพ (PPE / ชิ้นส่วน / log)
• เขียน problem statement เป็นข้อเท็จจริง ไม่ตัดสิน
• วิเคราะห์ด้วย 5 Whys และ/หรือ Fishbone
• ทุก "ทำไม" และทุกก้างย่อย verify ด้วย evidence
• root cause อยู่ในระดับระบบ ไม่หยุดที่ "human error"
• corrective actions ตรงกับ root cause ทุกข้อ
• ทุกมาตรการมี Owner + Due date
• มาตรการเน้น Engineering/Elimination ไม่กระจุก PPE/Admin
• แจ้งราชการตามมาตรา 34 ถ้าเข้าเกณฑ์อุบัติภัยร้ายแรง
• สื่อสารบทเรียนผ่าน Toolbox Talk หรือ SOP update
• บันทึกเข้าระบบ และนับรวมในการทบทวนระบบประจำปี

คำถามที่พบบ่อย

Q1 — เหตุเล็กๆ ที่ไม่บาดเจ็บ ต้องสอบสวนไหม

ต้อง — กฎกระทรวง 2565 ข้อ 10(2) เขียนไว้ชัดว่ารวม "อุบัติการณ์" และ "ความเสียหายต่อทรัพย์สิน" ไม่ใช่แค่เหตุที่บาดเจ็บ ในทางปฏิบัติ แนะนำให้ทำ "Mini investigation" สั้นๆ สำหรับ near-miss — ใช้ 5 Whys 3-4 ชั้นก็พอ

Q2 — 5 Whys ต้องครบ 5 ครั้งเสมอไหม

ไม่ — เลข 5 เป็นเลขเชิงสัญลักษณ์ของเทคนิคนี้ บางเคส 3 ครั้งก็เจอ root cause บางเคสต้องลึก 7 หลักคือหยุดเมื่อคำตอบขึ้นระดับ "ระบบ" ที่แก้ได้ด้วยมาตรการเชิงโครงสร้าง — ไม่ใช่หยุดเพราะนับครบ

Q3 — สอบสวนแล้วเจอว่าเป็นความผิดของพนักงานชัดเจน ทำยังไง

ขุดต่อ — แม้พนักงานทำผิดจริง ก็ต้องถามว่า "ทำไมระบบถึงปล่อยให้คนนี้พลาดได้" ทุกระบบ Safety ที่ดีต้อง robust ต่อ human error — ถ้าระบบที่มีอยู่ขึ้นกับ "คนไม่พลาดเลย" ก็แปลว่าระบบยังไม่ดีพอ มาตรการที่ออกควรครอบทั้ง 2 ด้าน — ทบทวนกับพนักงาน (admin) + แก้ที่ระบบ (engineering)

Q4 — กฎหมายไทยบังคับให้ใช้ 5 Whys หรือ Fishbone ไหม

ไม่บังคับ — กฎหมายไทย (SMS 2565 ข้อ 10) บอกแค่ว่าต้องสอบสวนหาสาเหตุและออกมาตรการ ไม่ระบุวิธี 5 Whys และ Fishbone เป็น เครื่องมืออุตสาหกรรม ที่นิยมใช้ทั่วโลกเพราะใช้ง่าย ผู้ตรวจ ISO 45001 / SMS audit จะดูที่ "กระบวนการสอบสวนทำเป็นระบบไหม" — ไม่ได้ดูว่าใช้เครื่องมือยี่ห้อไหน

Q5 — เหตุเกิดวันศุกร์ตอนเย็น สอบสวนได้ตอนจันทร์เช้าไหม

ได้ส่วน "วิเคราะห์" แต่ส่วน "เก็บข้อมูล" ต้องเริ่มทันที — secure scene + สัมภาษณ์ผู้เห็นเหตุการณ์ที่ยังอยู่กะนั้น + ถ่ายรูป CCTV ภายใน 24 ชม. ทำให้ครบก่อน คนปวดข้อมูลสดทรงจำดี เครื่องบางตัวเขียน log ทับเอง

สรุป

• กฎหมายไทย — SMS 2565 ข้อ 10(2) บังคับให้สอบสวนทุกอุบัติการณ์ ไม่ใช่แค่เหตุที่บาดเจ็บ — และต้องนำผลไปแก้ระบบ
• กรณีร้ายแรง — มาตรา 34 วรรคสอง บังคับให้แจ้งราชการตามแบบที่อธิบดีประกาศ
• 5 Whys + Fishbone เป็น เครื่องมือมาตรฐานอุตสาหกรรม ไม่ใช่ข้อบังคับกฎหมาย — แต่เป็นวิธีที่ใช้ได้ดี ไม่ต้องอบรมพิเศษ
• เก็บข้อมูลก่อนวิเคราะห์ — secure scene · สัมภาษณ์สด · เก็บหลักฐาน
• ห้ามหยุดที่ "human error" — ขุดต่อให้ถึงระบบ
• มาตรการแก้ต้องตรง root cause + มี Owner + Due date + ไม่กระจุก PPE/Admin

ลองเริ่มที่เคสเล็กในไลน์คุณก่อน — เลือก near-miss ที่เกิดเมื่อสัปดาห์ก่อน แล้วลองทำ 5 Whys 5 ชั้น เอาออกมาแสดงในประชุม Toolbox Talk ครั้งหน้า ทีมจะเริ่มเห็นว่า "การสอบสวน" ไม่ใช่กระบวนการหาคนผิด แต่เป็นเครื่องมือทำให้ที่ทำงานปลอดภัยขึ้น

รายงานสอบสวนทุกฉบับยังเป็นข้อมูล Lagging indicator ที่สำคัญสำหรับวัดผลระบบ Safety — โยงต่อไปอ่าน KPI ความปลอดภัย — Leading vs Lagging เพื่อรวมตัวเลขสอบสวนเข้ากับ dashboard ภาพรวม