[SW Process] มีกระบวนการที่ดี แต่ทำงานปัญหาเดิมยังอยู่?

มีกระบวนการที่ดี แต่ทำงานปัญหาเดิมยังอยู่? พอไปตรวจสอบเงื่อนไขการตรวจวัดต่างๆ มันก็ผ่านแล้วนะ ทำไหมหละ

ลองมายกตัวอย่างสักกระบวนการดีกว่า

ตัวอย่างกระบวนการที่ผมยกมานั้นเป็นกระบวนการบริการลูกค้า เมื่อเกิดปัญหาการใช้งาน Software โดยใช้ระบบ Ticket Management อย่าง Redmine / Jira เป็นต้นครับ โดยกระบวนการตัวอย่างผมมีรายการละเอียด ดังนี้

• เมื่อลูกค้าพบปัญหาการใช้งาน Software เข้ามาใน Ticket Management โดยอยู่ในสถานะ New
• ทีม Customer Support ได้การแจ้งเตือนว่ามี Incident ใหม่เข้ามาผ่าน Line และดึง Ticket นั้นเข้ามาตรวจสอบเปลี่ยนสถานะจาก New > CS Review และ ในช่วงนี้ Customer Support ต้องทำ
  • สรุปปัญหาที่เกิดขึ้น และข้อมูลจำเป็นว่า พบในเวอร์ชันไหน หน้าจออะไร อะไรที่ผิด และ อะไรที่ถูกต้อง รวมถึงข้อ Exception Message
  • พยายามหาวิธีการแก้ปัญหาเบื่องต้น (Work Around) และแจ้งลูกค้าให้รับทราบ และยอมรับวิธีการแก้ปัญหาเบื่องต้น ถ้าลูกค้า OK ทาง Customer Support เปลี่ยนสถานะจาก CS Review > Resolve ครับ
• ในกรณีที่ CS ไม่สามารถแก้ไขปัญหาได้ ส่งต่อให้ทีม
  • ถ้าส่งให่ทีม Develop เปลี่ยนสถานะจาก CS Review > Dev Review
  • ถ้าส่งให่ทีม Business Analyst เปลี่ยนสถานะจาก CS Review > BA Review
  • เมื่อทีม Develop / Business Analyst หาวิธีการแก้ไขเบื้องต้นได้ หรือสรุปที่มาของปัญหาได้ ส่งให้ Customer Support ตรวจสอบ เปลี่ยนสถานะเป็น CS Review และแจ้งลูกค้า ถ้าลูกค้ายอมรับ และปรับสถานะสถานะ Resolve ครับ
• สถานะ Resolve มีข้อกำหนดว่าต้องเปลี่ยนภายใน 1 วัน ไม่งั้นจะหลุด SLA ได้ครับ อันนี้มีระบบตรวจสอบทุกวัน และเก็บข้อมูล
• หลังจากสถานะ Resolve ไปแล้ว สถานะถัดไป
  • ถ้าไม่ต้องแก้โปรแกรม Customer Support เปลี่ยนสถานะ Wait for Customer ลูกค้าเปลี่ยนสถานะเป็น Close
  • ถ้าแก้โปรแกรม Customer Support เปลี่ยนสถานะ Wait for Develop และ ทีม Develop เปลี่ยนสถานะเป็น Develop (แก้ Code) > Wait for Delivering (QA ตรวจผ่านแล้วรอส่งลูกค้า) > UAT (ติดตั้งที่ Site ลูกค้าแล้ว) ตามลำดับครับ
    • ถ้า UAT ผ่าน ลูกค้าเปลี่ยนสถานะเป็น Close
    • ถ้า UAT ไม่ผ่าน ลูกค้าเปลี่ยนสถานะเป็น Re-Open และทาง Customer Support มาเปลี่ยนสถานะเป้น CS Review ครับ
• Note
  • นิยามของกระบวนการนะครับ ไม่รวมเคสที่ขอเปลี่ยนแปลงการทำงาน Change Request
  • การทำงานจริง Customer Support จะไม่ปรับสถานะ แต่จะเปลี่ยน Assignee แทน

หลังจากใช้กระบวนการนี้ไปปรากฏว่า

นั้นแสดงว่า ปัญหาที่เกิดจากที่แจ้งมาเกี่ยวกับระบบไม่ได้ถูกแก้ไข โดยที่มีบาง Incident เกิน SLA บ้าง ไม่เกินบ้าง ลองมาหา Root Cause กันครับ

• การทำงานจริง Customer Support ไม่ปรับสถานะ แต่จะเปลี่ยน Assignee
  • พบว่าการ Query ตรวจสอบงานนั้นยากกว่าเดิม และสับสนด้วย เพราะไม่รู้ว่า Incident ไหนถูกตรวจสอบไปแล้ว
• การเข้าไป Audit Incident ที่ถูก Mark สถานะ Resolve (ลูกค้าสามารถยอมรับวิธีการแก้ปัญหาเบื่องต้น (Work Around) ได้) แต่จริงๆ แล้วพบว่า
  • มันไม่ได้แก้ปัญหาเลย ใส่แค่ว่าอยู่ระหว่างการหาสาเหตุ และดองมานาน จนอยู่ๆมาวันนึงก็ส่งต่อมาให้ทีมงานข้างหลัง แต่ไม่มีข้อมูลใดๆ ที่สามารถช่วยลดเวลาให้ทีม BA / DEV ที่เข้ามารับช่วงต่อได้เลย ดังรูป
  • หรือ ไม่จะเป็นอีกเคสลัดขั้นตอน ระบบตรวจสอบ SLA โดยการชิงเปลี่ยนสถานะ Resolve ก่อนจะครบเวลา 24 ชั่วโมง หรือ 1 วัน
  • ซึ่งการทำแบบนี้ มันแอบสร้างระเบิดเวลากับลูกค้าไว้ แล้วรอจนระเบิดออกมา เช่น ว่า ลูกค้าโวยว่า บริษัททราบปัญหาแล้ว ทำไมถึงไม่แก้ไข รอมา 3 เดือนแล้ว !!!
• พอปัญหานี้มันสะสมมานานๆแล้ว สุดท้ายฝั่งทีมหลังบ้าน DEV / BA ต้องสละเวลามาจัดการกับปัญหา เพราะลูกค้าโวย หรือ ต้องปิดให้ได้ตามสัญญา่ เช่น 180 วัน ซึ่งมันจะไปส่งผลกระทบกับงานในส่วนอื่นๆได้ เช่น งาน R&D แต่ผู้บริหารไม่รู้นะว่ามาจากส่วนนี้

สรุป

• ควรการตรวจสอบกระบวนการ เพื่อป้องกันผู้ปฏิบัติงานลัดขั้นตอน โดยใช้ขั้นตอนของกระบวนการเนี่ยแหละ ปรับเป็นประโยชน์ส่วนตัว แต่องค์กรจะแย่เอา
• นอกจากนี้ควรหาสาเหตุด้วยว่าทำไมผู้ปฏิบัติงานลัดขั้นตอน เช่น
  • เวลาไม่เพียงพอ
  • ใช้ระบบงานที่ Support อยู่ได้ไม่คล่อง
  • ไม่เข้าใจปัญหาของลูกค้า
  • อธิบายสื่อสาร Flow งานกับลูกค้าไม่ชัดเจน และต้องให้ลูกค้านั้นยอมรับด้วย ยกตัวอย่าง เช่น นิยามของ Status Resolve
• ควรการนำข้อมูลจากหลายๆแหล่งเข้ามาดูภาพรวมด้วยกัน อาทิ เช่น ทำไมทีม Support ตีความปัญหาจัดการปัญหาเบื้องต้นได้ทุก Incident แต่ทำไมทีมที่จัดการงานปลายทางถึงได้ใช้ Effort สูงขึ้นผิดปกติ
• นอกจากการพัฒนากระบวนการแล้ว สิ่งที่หลายองค์กรมักลืมกัน คือ ตัวบุคคลที่ปฏิบัติงานเอง แม้ว่าทำตามกระบวนการได้ครบ แต่ถ้าไม่สามารถเข้าใจงานที่ทำได้ มันออกจะดูแย่ว่าหุ่นยนต์ หรือ AI บางตัวในสมัยนี้นะ ความรู้ความเข้าใจในงานจริงๆ ควรเข้าใจก่อน แล้วค่อยนำกระบวนการมาครอบอีกทีครับ

สุดท้าย

• ลัดขั้นตอน = โกง แหละ
• Blog นี้ บอกถึงปัญหาที่แท้จริงในการ Support แม้ Process จะสวยหรู แต่ถ้าผู้ปฏิบัติงานขาดความรู้และความเข้าใจในส่วนงานที่ตัวเองรับผิดชอบ ในที่นี้เป็นความเข้าใจใน Software ที่ Support แม้ว่าจะอธิบายกระบวนการได้ดีแค่ไหน แต่ปัญหายังคงค้างอยู่ หรือป่าว
• อย่างที่บอก Process นี้ไม่รวมเคส Change Request ถ้าให้เล่าเดียวยาว เขียนได้อีกหลาย Story เลย 55555