หลายคนคงเคยผ่านหูผ่านตา หลักการตั้งเป้าหมาย ให้ S.M.A.R.T กันมาบ้างแล้ว และจะว่าไป KPI ก็เป็นการตั้งเป้าหมายอย่างหนึ่งการนำหลักการเดียวกันมาใช้น่าจะเป็นแนวทางในการทำ KPI ก็น่าจะได้เช่นกัน
S.M.A.R.T นั้นเป็นหลักในการตรวจสอบการตั้ง Objective ซึ่งหาก search ดูจะพบอยู่เพียบเลยค่ะ แม้จะใช้คำต่างกันบ้าง แต่ก็มีความหมายคล้าย ๆ กันนะคะ ถนัดใช้คำไหนก็เลือกจำตามสะดวกเลยค่ะ
ขอยกตัวอย่างจาก KPI ในครั้งที่แล้ว ที่เราจะวัดการให้บริการอย่างต่อเนื่องของระบบ ด้วยเวลา downtime สะสมภายใน 1 ปี
เมื่อนำ SMARTER มาตรวจสอบว่า KPI นี้ใช้ได้หรือไม่
S - Specific - การระบุให้ชัดเจน เข้าใจได้ตรงกันเป็นสิ่งเดียว ไม่คลุมเครือ
กรณีนี้ระบุชัดเจนว่าเป็นการนับ Downtime ของระบบใด ในกรณีใด หากเป็นกรณีสุดวิสัยเช่นกระแสไฟฟ้าขัดข้องจะไม่นับช่วงเวลาดังกล่าวหรือไม่ (หากระบบไฟฟ้าไม่อยู่ในความดูแลของ Admin แต่ถ้ามีแผนสำรองไฟก็น่าจะนับรวมด้วย)
M - Measurable - สามารถวัดได้ ซึ่งให้ดีที่สุดคือออกมาเป็นตัวเลขได้ ในกรณีนี้สามารถนับเป็นตัวเลข (เวลาสะสม) ได้
A - Agreed - ความเห็นชอบจากผู้เกี่ยวข้อง คือการยอมรับเป้าหมายจากทุกฝ่าย ทั้งผู้ตั้งและผู้นำไปปฎิบัติ รวมทั้งผู้ที่ได้รับผลกระทบ หรือผู้มีส่วนได้ส่วนเสีย ทั้งตัว admin เอง ผู้ใช้งานระบบ และผู้บังคับบัญชา เห็นด้วยกับระดับคะแนนหรือไม่ ในการจัดทำ KPI จึงต้องมีการนำเสนอ ให้หน่วยงานอื่น ๆ ในองค์กรได้ทราบและลงความเห็นชอบเพื่อนำไปสู่การอนุมัติด้วย
R - Realistic - สามารถทำได้จริง โดยพิจารณาทั้งจาก ความเป็นไปได้ , ช่วงเวลา และ ทรัพยากร ที่จะจัดสรรให้ ซึ่งหากพบว่าปีที่ผ่านมามีค่าแตกต่างกันมาก เช่น Downtime สะสมเกินกว่า 2 สัปดาห์ การตั้งระดับคะแนนเป้าหมายที่ downtime ไม่เกิน 3 วันอาจเป็นไปไม่ได้
T - Time framed - มีการระบุกรอบของเวลาชัดเจน ในที่นี้ระบุว่าการนับเวลา downtime เป็นการนับเวลาสะสมภายใน 1 ปี
อีก 2 ข้อซึ่งแนะนำให้ตรวจสอบ เวลาตั้ง KPI คือ Evidence สามารถตรวจสอบผลลัพธ์ ได้ เช่นการมีบันทึก หรือรายงาน และ Review คือมีการตรวจสอบสม่ำเสมอ รวมแล้วก็จะเป็น SMARTER (พอเรียงเป็นคำก็ช่วยให้จำง่ายขึ้น)
Evidence - ในการหยุดให้บริการแต่ละครั้งนั้นมีการบันทึกช่วงเวลาที่ใช้ในการกู้คืนระบบหรือไม่ ซึ่งในการทำงานอาจจะมีระบบ Helpdesk ที่ใช้บันทึกช่วงเวลาตั้งแต่ server down ไปจนถึงช่วงที่สามารถกลับมาใช้งานได้ แต่หากไม่มีการบันทึกมาก่อน อาจจะต้องเริ่มบันทึก เพื่อใช้เป็นหลักฐานในการประเมิน
Review - ในช่วงเวลา 1 ปี จัดให้มีการรายงานช่วงเวลา Downtime สะสมทุกๆ เดือน เพื่อให้ทราบสถานะ เช่นหากพบว่าแค่เดือน มกราคมเดือนเดียว ก็มี downtime สะสมกว่า 1 วันแล้ว ช่วงเวลาที่เหลืออีก 11 เดือน จะทำอย่างไรให้ ระบบสามารถใช้งานได้อย่างต่อเนื่อง ซึ่งน่าจะดีกว่า การรายงานครั้งเดียวเมื่อจะทำการประเมิน
S.M.A.R.T นั้นเป็นหลักในการตรวจสอบการตั้ง Objective ซึ่งหาก search ดูจะพบอยู่เพียบเลยค่ะ แม้จะใช้คำต่างกันบ้าง แต่ก็มีความหมายคล้าย ๆ กันนะคะ ถนัดใช้คำไหนก็เลือกจำตามสะดวกเลยค่ะ
ขอยกตัวอย่างจาก KPI ในครั้งที่แล้ว ที่เราจะวัดการให้บริการอย่างต่อเนื่องของระบบ ด้วยเวลา downtime สะสมภายใน 1 ปี
เมื่อนำ SMARTER มาตรวจสอบว่า KPI นี้ใช้ได้หรือไม่
S - Specific - การระบุให้ชัดเจน เข้าใจได้ตรงกันเป็นสิ่งเดียว ไม่คลุมเครือ
กรณีนี้ระบุชัดเจนว่าเป็นการนับ Downtime ของระบบใด ในกรณีใด หากเป็นกรณีสุดวิสัยเช่นกระแสไฟฟ้าขัดข้องจะไม่นับช่วงเวลาดังกล่าวหรือไม่ (หากระบบไฟฟ้าไม่อยู่ในความดูแลของ Admin แต่ถ้ามีแผนสำรองไฟก็น่าจะนับรวมด้วย)
M - Measurable - สามารถวัดได้ ซึ่งให้ดีที่สุดคือออกมาเป็นตัวเลขได้ ในกรณีนี้สามารถนับเป็นตัวเลข (เวลาสะสม) ได้
A - Agreed - ความเห็นชอบจากผู้เกี่ยวข้อง คือการยอมรับเป้าหมายจากทุกฝ่าย ทั้งผู้ตั้งและผู้นำไปปฎิบัติ รวมทั้งผู้ที่ได้รับผลกระทบ หรือผู้มีส่วนได้ส่วนเสีย ทั้งตัว admin เอง ผู้ใช้งานระบบ และผู้บังคับบัญชา เห็นด้วยกับระดับคะแนนหรือไม่ ในการจัดทำ KPI จึงต้องมีการนำเสนอ ให้หน่วยงานอื่น ๆ ในองค์กรได้ทราบและลงความเห็นชอบเพื่อนำไปสู่การอนุมัติด้วย
R - Realistic - สามารถทำได้จริง โดยพิจารณาทั้งจาก ความเป็นไปได้ , ช่วงเวลา และ ทรัพยากร ที่จะจัดสรรให้ ซึ่งหากพบว่าปีที่ผ่านมามีค่าแตกต่างกันมาก เช่น Downtime สะสมเกินกว่า 2 สัปดาห์ การตั้งระดับคะแนนเป้าหมายที่ downtime ไม่เกิน 3 วันอาจเป็นไปไม่ได้
T - Time framed - มีการระบุกรอบของเวลาชัดเจน ในที่นี้ระบุว่าการนับเวลา downtime เป็นการนับเวลาสะสมภายใน 1 ปี
อีก 2 ข้อซึ่งแนะนำให้ตรวจสอบ เวลาตั้ง KPI คือ Evidence สามารถตรวจสอบผลลัพธ์ ได้ เช่นการมีบันทึก หรือรายงาน และ Review คือมีการตรวจสอบสม่ำเสมอ รวมแล้วก็จะเป็น SMARTER (พอเรียงเป็นคำก็ช่วยให้จำง่ายขึ้น)
Evidence - ในการหยุดให้บริการแต่ละครั้งนั้นมีการบันทึกช่วงเวลาที่ใช้ในการกู้คืนระบบหรือไม่ ซึ่งในการทำงานอาจจะมีระบบ Helpdesk ที่ใช้บันทึกช่วงเวลาตั้งแต่ server down ไปจนถึงช่วงที่สามารถกลับมาใช้งานได้ แต่หากไม่มีการบันทึกมาก่อน อาจจะต้องเริ่มบันทึก เพื่อใช้เป็นหลักฐานในการประเมิน
Review - ในช่วงเวลา 1 ปี จัดให้มีการรายงานช่วงเวลา Downtime สะสมทุกๆ เดือน เพื่อให้ทราบสถานะ เช่นหากพบว่าแค่เดือน มกราคมเดือนเดียว ก็มี downtime สะสมกว่า 1 วันแล้ว ช่วงเวลาที่เหลืออีก 11 เดือน จะทำอย่างไรให้ ระบบสามารถใช้งานได้อย่างต่อเนื่อง ซึ่งน่าจะดีกว่า การรายงานครั้งเดียวเมื่อจะทำการประเมิน
แค่นี้การตั้งค่า KPI ก็ดูจะไม่ยากแล้วล่ะ คราวหน้าลองมาเจาะลึกตัว M - Measurable กันอีกนิด (หลาย ๆ คนคงเคยเจอว่ามีบางอย่างที่ไม่สามารถวัดเป็นตัวเลขได้ไปใช่ไม๊ )
ไม่มีความคิดเห็น:
แสดงความคิดเห็น