Root Cause Analysis Series: Fishbone Diagram (Ishikawa) วิเคราะห์สาเหตุปัญหาแบบก้างปลา

Fishbone Diagram คืออะไร และที่มาจากไหน

Fishbone Diagram คือแผนภาพที่ช่วยให้ทีมระบุสาเหตุของปัญหาอย่างเป็นระบบ โดยแสดงความสัมพันธ์ของปัจจัยต่าง ๆ ที่อาจนำไปสู่ปัญหาผ่านโครงสร้างคล้ายกระดูกปลา หัวของปลาแสดงปัญหาหลัก และก้างปลาแตกแขนงเป็นหมวดหมู่ของปัจจัยที่เกี่ยวข้อง เช่น บุคลากร (People), กระบวนการ (Process), เทคโนโลยี (Technology), ข้อมูล (Data), สภาพแวดล้อม (Environment) และการบริหารจัดการ (Management)

เครื่องมือนี้ถูกคิดค้นโดย Kaoru Ishikawa นักวิชาการและวิศวกรชาวญี่ปุ่น ราวปี 1968 ใช้ครั้งแรกที่ Kawasaki Steel เพื่อควบคุมคุณภาพในโรงงานอุตสาหกรรม ก่อนกลายเป็นหนึ่งในเครื่องมือพื้นฐานของขบวนการ Japanese Quality Management และแพร่หลายในภาคธุรกิจ การบริหารโครงการ และ Digital Product ทั่วโลก

การสร้างเว็บไซต์องค์กร (Corporate Website) มักต้องอาศัยความร่วมมือจากหลายฝ่าย ทั้งทีมการตลาด ทีมประชาสัมพันธ์ ทีมนักลงทุนสัมพันธ์ และทีม IT ซึ่งหากขาดการจัดการที่เหมาะสม ความล่าช้าในการส่งข้อมูลหรือให้ Feedback จะเกิดขึ้นบ่อยและส่งผลกระทบต่อระยะเวลาและทรัพยากรของโครงการ

ขั้นตอนการใช้งาน Fishbone Diagram พร้อมตัวอย่าง Corporate Website

ขั้นตอนที่ 1: กำหนดปัญหาหลัก

ปัญหาคือ: "ความล่าช้าในการทำเว็บไซต์องค์กร จากการส่งข้อมูลและ Feedback ไม่ทันกำหนด"

นำปัญหานี้มาเขียนไว้ที่ "หัวปลา" ของแผนภาพ ปัญหาควรเขียนเป็นประโยคที่สังเกตได้และวัดได้ เช่น ระบุว่าล่าช้ากี่สัปดาห์เทียบกับ Timeline เดิม

ขั้นตอนที่ 2: ระบุหมวดหมู่หลักของสาเหตุ (Main Categories)

หมวดหมู่มาตรฐานในอุตสาหกรรมคือ 6M (Man, Machine, Method, Material, Measurement, Environment) แต่หมวดหมู่นี้ออกแบบสำหรับโรงงานผลิต ไม่ลงตัวกับโปรเจกต์ดิจิทัล สำหรับกรณีนี้จึงเลือกหมวดหมู่ที่ตรงบริบทมากกว่า ได้แก่ People, Process, Communication และ Management

ขั้นตอนที่ 3: วิเคราะห์ปัจจัยย่อยภายใต้แต่ละหมวดหมู่

People (บุคลากร): ทีมงานหลักไม่มีเวลาให้ข้อมูลเนื่องจากมีภาระงานหลักอื่น และไม่มีผู้รับผิดชอบหลักที่ชัดเจนในแต่ละทีม

Process (กระบวนการทำงาน): ไม่มี Timeline กลางที่ทุกทีมรับทราบและยึดตามร่วมกัน ขั้นตอนการอนุมัติมีหลายชั้นและซ้ำซ้อนจนทำให้เกิดความล่าช้าในแต่ละรอบ

Communication (การสื่อสาร): ใช้ช่องทางการสื่อสารหลายช่องทางพร้อมกัน ทำให้ข้อมูลกระจัดกระจายและตรวจสอบได้ยาก และไม่มีระบบติดตามสถานะ Feedback แบบรวมศูนย์

Management (การบริหารจัดการ): ไม่มี Project Owner ที่ดูแลภาพรวมและประสานงานข้ามทีม การจัดประชุมเพื่อติดตามความคืบหน้าไม่สม่ำเสมอ

ขั้นตอนที่ 4: สังเคราะห์สาเหตุร่วมและระบุต้นเหตุของปัญหา

เมื่อดูจากทุกปัจจัยร่วมกัน จะพบว่าต้นเหตุของปัญหาคือ "การขาดความเป็นเจ้าของโปรเจกต์แบบรวมศูนย์ (Project Ownership)" และ "กระบวนการสื่อสารและติดตามงานที่ไม่มีโครงสร้าง" ทั้งสองรากเหง้าส่งผลซึ่งกันและกัน ทำให้ปัญหาความล่าช้าวนซ้ำในทุกรอบของโครงการ ขั้น Synthesis นี้คือหัวใจของ Fishbone หากข้ามไปก็จะได้แค่แผนภาพที่ดูดี แต่ไม่มี Insight ไปต่อ

ขั้นตอนที่ 5: สรุปแนวทางแก้ไขที่ตรงต้นเหตุ

ต้นเหตุ: ขาด Project Ownership

แนวทางแก้ไข: กำหนด Project Owner จากฝ่ายที่มีอำนาจตัดสินใจข้ามทีม และให้ Project Owner มีหน้าที่ Escalate เมื่อมีทีมใดส่งข้อมูลล่าช้าเกินกำหนดที่ตกลงกันไว้

ต้นเหตุ: ขาดโครงสร้างการสื่อสารและติดตามงาน

แนวทางแก้ไข: กำหนด Single Communication Channel สำหรับโปรเจกต์นี้โดยเฉพาะ, ตั้ง Review Checkpoint ในปฏิทินล่วงหน้าตั้งแต่วันแรก และใช้เครื่องมือติดตาม Feedback แบบรวมศูนย์ที่ทุกทีมเข้าถึงได้ในที่เดียว

ข้อผิดพลาดที่พบบ่อยในการทำ Fishbone Diagram

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

ข้อที่สองคือ สับสนระหว่างอาการกับสาเหตุ หลายทีมเขียน "เว็บล่าช้า" ไว้ในก้างปลาแทนที่จะเป็นปัจจัยที่ทำให้ล่าช้า แผนภาพที่ได้จึงเป็นแค่ List of Symptoms ไม่ใช่ Root Cause Analysis

ข้อที่สามคือ หยุดที่การวาดแผนภาพแล้วจบ Fishbone Diagram จะมีคุณค่าก็ต่อเมื่อทีมทำ Synthesis ต่อ คือมองภาพรวมเพื่อหารากเหง้าที่ปัจจัยหลายตัวชี้ไปร่วมกัน หากข้ามขั้นนี้จะได้แค่ Brainstorming Output

Fishbone Diagram เหมาะกับการวิเคราะห์ปัญหาแบบไหน

Fishbone Diagram เหมาะสำหรับปัญหาที่มีหลายปัจจัยเกี่ยวข้องพร้อมกัน โดยเฉพาะงานที่ต้องอาศัยหลายทีม หลายกระบวนการ หรือหลายมุมมองในการวิเคราะห์ เช่น Cross-functional Projects ปัญหาที่เกิดซ้ำแต่ยังหาสาเหตุไม่ได้ชัดเจน หรือสถานการณ์ที่แต่ละฝ่ายมีความเห็นไม่ตรงกันเกี่ยวกับต้นตอของปัญหา โครงสร้างการจัดกลุ่มสาเหตุช่วยให้ทีมรวบรวมและพิจารณาความเป็นไปได้ได้อย่างเป็นระบบ ลดการด่วนสรุปหรือโยนความรับผิดไปยังทีมใดทีมหนึ่งตั้งแต่ต้น

อย่างไรก็ตาม Fishbone Diagram ไม่เหมาะกับปัญหาที่มีลำดับเหตุและผลชัดเจนเพียงเส้นทางเดียว เพราะอาจเพิ่มความซับซ้อนโดยไม่จำเป็น นอกจากนี้ยังไม่เหมาะสำหรับการประเมินความเสี่ยงล่วงหน้า ซึ่ง FMEA จะตอบโจทย์กว่า และไม่เหมาะกับการวิเคราะห์ความสัมพันธ์แบบ AND/OR ระหว่างปัจจัย ซึ่งเป็นจุดแข็งของ FTA

Fishbone Diagram เทียบกับเครื่องมืออื่นใน RCA Series

ใน Root Cause Analysis Toolkit ของ SUFFIX: Problem-Analysis (4-axis Framework) เป็น Gateway ที่ช่วยจัดประเภทปัญหาก่อนเลือกเครื่องมือ, Fact-Based Thinking ฉบับ McKinsey ช่วยตั้ง Problem Statement ให้แม่นยำ, 5 Whys ขุดลึกในสายเหตุเดียวเหมาะกับปัญหาที่มี Hypothesis เบื้องต้น, Fault-Tree Analysis ใช้ตรรกะ AND/OR แยกความสัมพันธ์ปัจจัย, FMEA ใช้ป้องกันเชิงรุก, Change Analysis ใช้เมื่อมีจุดเปลี่ยนชัดเจน, Barrier Analysis ใช้เมื่อต้องดูว่าด่านป้องกันใดพัง, Parent Cause และ Management Oversight เน้นมิติองค์กรและความรับผิดชอบ ส่วน Fishbone Diagram เด่นที่สุดเมื่อต้องการระดมความคิดครอบคลุมทุกมิติพร้อมกันในทีมที่มีหลายฝ่าย เพราะโครงสร้างแบบหมวดหมู่ช่วยให้ไม่มีมิติใดถูกมองข้าม