ปัญหา IT ที่แก้ไปแล้วกลับมาซ้ำอีก เป็นสัญญาณชัดเจนว่าทีมยังแก้ไขที่ "อาการ" ไม่ใช่ "สาเหตุที่แท้จริง" RCA (Root Cause Analysis) หรือการวิเคราะห์สาเหตุต้นตอคือกระบวนการที่ช่วยให้ทีม IT ขุดลึกถึงต้นเหตุของปัญหา เพื่อแก้ไขได้ตรงจุดและป้องกันไม่ให้เกิดซ้ำ บทความนี้อธิบาย RCA คืออะไร และวิธีเขียน RCA แบบ 5W1H ที่ใช้ได้จริงในงาน IT Support
RCA คืออะไร?
RCA ย่อมาจาก Root Cause Analysis แปลว่า "การวิเคราะห์สาเหตุที่แท้จริง" เป็นกระบวนการที่ใช้ในงาน IT Service Management (ITSM) เพื่อตอบคำถามว่า "ปัญหานี้เกิดขึ้นเพราะอะไรจริงๆ?" ไม่ใช่แค่ "ทำอะไรไปแล้วหาย"
ตัวอย่างที่เห็นได้ชัด: พนักงานแจ้งว่าเครื่องคอมพิวเตอร์เปิดไม่ติด ทีม IT รีสตาร์ทแล้วหาย ปิด Ticket แต่สัปดาห์หน้าเกิดอีก ถ้ามีการทำ RCA จะพบว่าสาเหตุจริงๆ คือ Power Supply เสื่อม ต้องเปลี่ยน ไม่ใช่แค่รีสตาร์ท
ทำไม IT Support ต้องทำ RCA?
- ลดปัญหาซ้ำซ้อน — ปัญหาที่วิเคราะห์สาเหตุได้จะไม่กลับมาอีก
- สร้าง Knowledge Base — RCA ที่บันทึกดีสามารถแปลงเป็น FAQ ให้พนักงานแก้ปัญหาเองได้ในอนาคต
- พัฒนาทีม — ช่วยให้ Support ใหม่เรียนรู้จากปัญหาจริงที่เกิดขึ้นในองค์กร
- ลดต้นทุน — ปัญหาที่ไม่กลับมาซ้ำ = ชั่วโมงการทำงานที่ประหยัดได้
- ปฏิบัติตามมาตรฐาน ITSM — ทั้ง ITIL และ ISO 20000 กำหนดให้มีกระบวนการ Problem Management ที่รวม RCA ไว้ด้วย
Framework 5W1H สำหรับ RCA
วิธีที่ใช้งานได้จริงและจำง่ายที่สุดสำหรับทีม IT คือ 5W1H — ถามคำถาม 6 ข้อที่ครอบคลุมทุกมิติของปัญหา
What — เกิดอะไรขึ้น?
อธิบายปัญหาให้ชัดเจน ระบุอาการที่สังเกตได้ ผลกระทบที่เกิดขึ้น และขอบเขตของปัญหา (กี่คน กี่เครื่อง)
Why — เกิดขึ้นเพราะอะไร?
นี่คือหัวใจของ RCA ให้ถาม "ทำไม?" ซ้ำ 3–5 ครั้ง (5 Whys Technique) จนถึงสาเหตุที่แท้จริง ไม่หยุดแค่อาการแรก
When — เกิดเมื่อไร?
ระบุเวลาที่เกิดปัญหาครั้งแรก เกิดซ้ำบ่อยแค่ไหน มีรูปแบบหรือไม่ (เช่น เกิดทุกเช้าวันจันทร์ หรือหลัง Windows Update)
Where — เกิดที่ไหน?
ระบุสถานที่ อุปกรณ์ ระบบ หรือ Application ที่ได้รับผลกระทบ ช่วยจำกัดขอบเขตการค้นหาสาเหตุ
Who — ใครเกี่ยวข้อง?
ผู้ใช้ที่ได้รับผลกระทบ ผู้ที่เกี่ยวข้องกับระบบ และผู้ที่รับผิดชอบการแก้ไข ช่วยกำหนดว่าใครควรได้รับการแจ้งและใครต้องดำเนินการ
How — แก้ไขอย่างไร?
อธิบายวิธีแก้ปัญหาเป็น Step-by-step ที่ Support คนอื่นสามารถทำตามได้ และมาตรการป้องกันไม่ให้เกิดซ้ำ
ตัวอย่าง RCA จริง: Internet ใช้ไม่ได้ทั้งออฟฟิศ
พนักงานทุกคนในชั้น 3 ใช้อินเทอร์เน็ตไม่ได้ตั้งแต่เวลา 09:15 น. รวม 47 คน ระบบ ERP และ Cloud drive ใช้ไม่ได้
ทำไม Internet ใช้ไม่ได้? → Switch ชั้น 3 หยุดทำงาน
ทำไม Switch หยุดทำงาน? → ไฟ UPS ดับกะทันหัน
ทำไม UPS ดับ? → Battery UPS เสื่อมสภาพ ไม่รองรับโหลด
ทำไมไม่รู้ว่า Battery เสื่อม? → ไม่มีระบบ Monitor UPS
Root Cause: ขาด Preventive Maintenance และ Monitoring สำหรับ Network Infrastructure
21 เมษายน 2569 เวลา 09:15 น. ใช้งานไม่ได้นาน 2 ชั่วโมง 15 นาที
ชั้น 3 อาคาร A ห้อง Server Room ตู้ Rack ที่ 2 UPS Model APC SMT1500RM
พนักงาน 47 คน ชั้น 3 / แจ้ง IT Support: คุณสมชาย / แก้ไข: ทีม Network / เจ้าของ UPS: ฝ่าย IT Infrastructure
แก้ไขระยะสั้น: เปลี่ยน Battery UPS ชั้น 3 ทันที, Failover ผ่าน Switch ชั้น 2 ชั่วคราว
ป้องกันระยะยาว: 1) ตรวจสอบ Battery UPS ทุก UPS ในอาคาร 2) ติดตั้ง SNMP Monitoring 3) เพิ่ม PM Schedule ตรวจ Battery ทุก 6 เดือน
เทคนิค 5 Whys: ถามให้ถึงต้นตอ
เทคนิค 5 Whys คือการถาม "ทำไม?" ซ้ำๆ จนกว่าจะพบสาเหตุที่แก้ไขได้จริง โดยทั่วไปใช้ 3–5 ครั้ง หัวใจสำคัญคืออย่าหยุดแค่คำตอบแรก
| ระดับ | คำถาม | คำตอบ |
|---|---|---|
| Why 1 | ทำไม Email ส่งไม่ได้? | Server ไม่ตอบสนอง |
| Why 2 | ทำไม Server ไม่ตอบสนอง? | Disk เต็ม 100% |
| Why 3 | ทำไม Disk เต็ม? | Log files สะสมโดยไม่ถูกลบ |
| Why 4 | ทำไม Log ไม่ถูกลบ? | Script cleanup ไม่ทำงาน |
| Root Cause | ทำไม Script ไม่ทำงาน? | Cron job หายไปหลัง OS Upgrade เดือนที่แล้ว |
คำตอบสุดท้ายคือสิ่งที่แก้ได้จริงและป้องกันได้ — เพิ่ม Cron job monitoring และ Log rotation policy อย่างถาวร ไม่ใช่แค่ลบ Log แล้วปิด Ticket
RCA กับ Knowledge Base — ต่อยอดให้เกิดประโยชน์
RCA ที่บันทึกดีสามารถแปลงเป็น FAQ Article ให้พนักงานค้นหาและแก้ปัญหาเองได้ในอนาคต โดยเฉพาะส่วน "How" ที่เขียนเป็น Step-by-step ชัดเจน ระบบ ITSM ที่ดีจะมีฟีเจอร์ให้ Support คลิก "Publish FAQ" จาก RCA ได้โดยตรง ไม่ต้องเขียนใหม่
ข้อมูลจาก Ticket ที่มี RCA ครบถ้วนยังช่วยให้ AI ทำงานได้แม่นยำขึ้น เช่น การแนะนำแนวทางแก้ปัญหาอัตโนมัติสำหรับ Ticket ใหม่ที่มีอาการคล้ายกัน
ข้อผิดพลาดที่พบบ่อยในการทำ RCA
- หยุดที่อาการแรก — เช่น บอกว่าสาเหตุคือ "เครื่องแฮง" โดยไม่ขุดต่อว่าทำไมแฮง
- โทษคน ไม่โทษกระบวนการ — RCA ที่ดีหาว่า "กระบวนการอะไรบกพร่อง" ไม่ใช่ "ใครผิด"
- ไม่บันทึกมาตรการป้องกัน — แก้ปัญหาได้แต่ไม่มีการป้องกัน ปัญหาจะกลับมาซ้ำ
- เขียน RCA หลังจากลืมรายละเอียดแล้ว — ควรเขียนทันทีหรือภายใน 24 ชั่วโมงหลังแก้ปัญหา
- ไม่แชร์กับทีม — RCA ที่ไม่มีใครอ่านไม่ต่างจากไม่มี RCA
RCA ใน ITSM: ระบบที่ดีช่วยอย่างไร?
ระบบ ITSM ที่มีฟีเจอร์ RCA built-in จะช่วยให้กระบวนการนี้เกิดขึ้นจริงในองค์กร ไม่ใช่แค่ในนโยบายที่ไม่มีใครทำ สิ่งที่ระบบควรมี:
- Form RCA แบบ 5W1H ที่กรอกได้ง่ายใน Ticket
- AI แนะนำ RCA — ดึงข้อมูลจาก Ticket เก่าที่คล้ายกันมาเป็นจุดเริ่มต้น
- ปุ่ม "Publish as FAQ" — แปลง How ใน RCA เป็น Knowledge Article ได้โดยตรง
- Report ที่แสดง Ticket ที่ยังไม่มี RCA เมื่อ Close แล้ว
1StopService มีฟีเจอร์ RCA Form (5W1H) และ AI ช่วยแนะนำแนวทาง RCA จาก Ticket ที่ผ่านมา พร้อม Checklist ITSM ครบวงจร ที่ทีม IT ควรรู้
ลองใช้ระบบที่มี RCA Form + AI ครบในที่เดียว
ทดลองใช้ 1StopService ฟรี 30 วัน ครบทุกฟีเจอร์ ไม่ต้องใส่บัตรเครดิต
เริ่มทดลองฟรีเลย