ทำไมปัญหาเดิมถูกแก้ซ้ำทุกเดือน: สร้างคลังความรู้ภายในที่ไม่ต้องพึ่งความจำใครคนเดียว
สรุปสั้น ๆ
ปัญหาการตั้งค่าระบบวัดผล LINE ส่วนใหญ่ไม่ใช่ปัญหาใหม่ มันเป็นปัญหาเดิมที่เคยมีคนแก้มาแล้ว เพียงแต่ไม่มีใครจดไว้ที่ไหน คลังความรู้ภายในที่ดีไม่ใช่เอกสารหนา แต่คือระบบค้นหาที่เร็วพอจะใช้ได้จริงตอนหน้างาน
AM คนหนึ่งของ Bluewave Media ใช้เวลาสองชั่วโมงในบ่ายวันหนึ่งเพื่อแก้ปัญหาแท็กลูกค้าซ้อนกันของร้านขนมหวาน SweetNest จนสำเร็จ สัปดาห์ถัดมา AM อีกคนหนึ่งเจอปัญหาแบบเดียวกันเป๊ะกับลูกค้าอีกราย และใช้เวลาแก้อีกสองชั่วโมงเต็มโดยไม่รู้เลยว่าเพื่อนร่วมทีมเพิ่งแก้ปัญหานี้ไปเมื่อสัปดาห์ก่อน
เมื่อหัวหน้าทีมมารู้เรื่องนี้ทีหลัง คำถามที่ผุดขึ้นมาไม่ใช่ ‘ทำไมสองคนนี้ไม่คุยกัน’ แต่คือ ‘ทำไมทีมถึงไม่มีที่ที่เก็บวิธีแก้ปัญหาให้คนอื่นค้นหาได้’ เพราะปัญหาแบบนี้ไม่ได้เกิดครั้งเดียว มันเกิดซ้ำเรื่อย ๆ กับทีมที่ไม่มีระบบบันทึกความรู้
ปัญหาลึกกว่านั้นคือ ถ้า AM คนที่รู้วิธีแก้ลาออกไปเมื่อไหร่ ความรู้นั้นจะหายไปทั้งหมด ทีมจะต้องเริ่มไล่หาวิธีแก้ใหม่ตั้งแต่ศูนย์ทุกครั้งที่คนเปลี่ยน
ทำไมการพึ่งความจำคนในทีมถึงพังเมื่อทีมโตขึ้น
ตอนทีมมีสามคน การถามกันปากเปล่ายังพอไหว เพราะทุกคนนั่งใกล้กันและรู้ว่าใครรู้อะไร แต่พอทีมโตขึ้นเป็นสิบกว่าคนดูแลลูกค้าหลายสิบราย การถามปากเปล่ากลายเป็นคอขวด เพราะคนที่รู้คำตอบอาจไม่ว่าง หรือลืมไปแล้วว่าเคยแก้ปัญหานี้อย่างไร
ยิ่งไปกว่านั้น ความรู้ที่ถ่ายทอดปากเปล่าไม่มีทางตรวจสอบย้อนหลังได้ว่าถูกต้องหรือทันสมัยอยู่หรือไม่ ต่างจากบันทึกที่เป็นลายลักษณ์อักษรซึ่งสามารถอัปเดตและอ้างอิงวันที่ได้ชัดเจน
สิ่งที่ควรบันทึกทุกครั้งหลังแก้ปัญหาเสร็จ
- อาการที่ลูกค้าหรือทีมสังเกตเห็น เขียนด้วยคำที่คนอื่นจะค้นหาเจอ ไม่ใช่คำเฉพาะที่มีแต่คนแก้เข้าใจ
- สาเหตุที่แท้จริงหลังตรวจสอบ ไม่ใช่แค่อาการที่เห็น เพราะบางครั้งอาการเดียวกันมีสาเหตุต่างกันได้
- ขั้นตอนที่ใช้แก้จริง พร้อมภาพหน้าจอถ้าเกี่ยวกับการตั้งค่าที่อธิบายเป็นคำยาก
- เวลาที่ใช้แก้และความเสี่ยงที่ควรระวังถ้าเจอเคสคล้ายกันในอนาคต
ทำให้ค้นหาเจอได้จริง ไม่ใช่แค่มีเอกสารกองไว้
เอกสารที่ดีแต่หาไม่เจอ มีค่าเท่ากับไม่มีเอกสารเลย ทีมจึงตั้งกฎว่าทุกบันทึกต้องมีคำค้นหลักอย่างน้อยสามคำที่คนอื่นน่าจะพิมพ์ค้นเวลาเจอปัญหาคล้ายกัน และจัดหมวดตามประเภทปัญหา เช่น ปัญหาแท็ก ปัญหา webhook ปัญหาริชเมนู แทนที่จะเรียงตามวันที่บันทึกอย่างเดียว
การจัดหมวดแบบนี้ยังช่วยตอนส่งต่องานระหว่าง AMด้วย เพราะคนใหม่สามารถไล่อ่านตามหมวดปัญหาที่พบบ่อยของบัญชีนั้นได้ทันที แทนที่จะต้องไล่ถามทีละคน
ทำอย่างไรให้คลังความรู้ไม่กลายเป็นสุสานเอกสารเก่า
ความเสี่ยงของคลังความรู้คือถ้าไม่มีใครอัปเดต มันจะเต็มไปด้วยวิธีแก้ที่ล้าสมัยตาม LINE ที่เปลี่ยนแปลงฟีเจอร์อยู่เรื่อย ๆ ทีมจึงกำหนดให้ทุกครั้งที่มีคนใช้บันทึกเก่าแล้วพบว่าใช้ไม่ได้แล้ว ต้องรีบแก้ไขหรือทำเครื่องหมายว่าล้าสมัยทันที ไม่ปล่อยไว้ให้คนหลังมาเจอปัญหาซ้ำ
การตรวจสอบระหว่างการทำQA ประจำวันก็เป็นโอกาสที่ดีในการทบทวนว่าบันทึกไหนควรอัปเดต เพราะเป็นช่วงที่ทีมอยู่ในโหมดตรวจสอบระบบอยู่แล้ว
สรุป
ปัญหาเดิมที่ถูกแก้ซ้ำทุกเดือนไม่ใช่สัญญาณว่าทีมไม่เก่ง แต่เป็นสัญญาณว่าทีมยังไม่มีที่เก็บความรู้ที่ค้นหาได้จริง การลงทุนเวลาสิบนาทีบันทึกหลังแก้ปัญหาแต่ละครั้ง คืนทุนเร็วกว่าที่คิดเมื่อปัญหาเดิมโผล่มาอีกครั้ง
เคส SweetNest สอนทีม Bluewave Media ว่าความรู้ที่ดีที่สุดคือความรู้ที่คนอื่นหาเจอโดยไม่ต้องถามเจ้าของความรู้เดิม เพราะนั่นคือสิ่งที่ทำให้ทีมสเกลได้จริงโดยไม่พังตอนคนเปลี่ยน
- บันทึกอาการ สาเหตุ วิธีแก้ และเวลาที่ใช้ ทุกครั้งหลังแก้ปัญหาเสร็จ
- จัดหมวดตามประเภทปัญหาให้ค้นหาเจอง่าย ไม่ใช่เรียงตามวันที่อย่างเดียว
- ทบทวนและอัปเดตบันทึกเก่าที่ล้าสมัย อย่าปล่อยให้กลายเป็นสุสานเอกสาร
คำถามที่พบบ่อย
คลังความรู้ควรใช้เครื่องมืออะไร ต้องซับซ้อนไหม
ไม่จำเป็นต้องซับซ้อน เอกสารที่ค้นหาได้และแก้ไขร่วมกันได้ก็เพียงพอแล้วสำหรับทีมขนาดเล็กถึงกลาง สิ่งสำคัญกว่าเครื่องมือคือวินัยในการบันทึกอย่างสม่ำเสมอ
ใครควรเป็นคนรับผิดชอบดูแลคลังความรู้นี้
ควรมีคนหนึ่งรับผิดชอบภาพรวมว่าเป็นระเบียบและไม่ซ้ำซ้อน แต่ทุกคนในทีมควรมีหน้าที่บันทึกเองหลังแก้ปัญหาเสร็จ ไม่ใช่ผลักภาระให้คนคนเดียวเขียนทั้งหมด
ถ้าทีมเล็กมากแค่สองสามคน ยังจำเป็นต้องทำไหม
จำเป็น เพราะยิ่งเริ่มทำตั้งแต่ทีมเล็ก ยิ่งสร้างนิสัยได้ง่ายกว่า และเมื่อทีมโตขึ้นในอนาคตจะมีฐานความรู้พร้อมอยู่แล้วแทนที่จะต้องเริ่มสร้างตอนสายเกินไป
ควรบันทึกทุกปัญหาหรือแค่ปัญหาที่ซับซ้อน
แนะนำให้บันทึกทุกปัญหาที่ใช้เวลาแก้เกินสิบนาที เพราะปัญหาที่ดูเล็กน้อยบางอย่างอาจเกิดซ้ำบ่อยกว่าปัญหาซับซ้อนเสียอีก
จะรู้ได้ยังไงว่าคลังความรู้กำลังได้ผล
สังเกตจากเวลาเฉลี่ยที่ใช้แก้ปัญหาซ้ำลดลง และจำนวนครั้งที่ AM ใหม่ถามคำถามเดิมที่คนอื่นเคยเจอมาแล้วลดลงด้วย
ควรเปิดให้ลูกค้าเห็นคลังความรู้นี้ไหม
โดยทั่วไปควรเก็บไว้เป็นเอกสารภายในทีมเท่านั้น เพราะมีรายละเอียดเชิงเทคนิคและบางครั้งพูดถึงข้อผิดพลาดในอดีตที่ไม่จำเป็นต้องให้ลูกค้าเห็นโดยตรง
บทความที่เกี่ยวข้อง
