“ระบบล่ม” ประโยคบาดจิตบาดใจ คนทำงาน IT เมื่อระบบไม่ได้ล่ม
เหตุการณ์สมมติในองค์กร(ขนาดใหญ่) แห่งหนึ่ง
เมื่อผู้ใช้งานระบบ ซึ่งเป็นพนักงานในองค์กร ที่ต้องดึงข้อมูลลูกค้ามาใช้งาน เจอว่าหน้าจอระบบดึงข้อมูลลูกค้าไม่ขึ้น เลยแจ้งไปในกรุ๊ปไลน์ที่มีผู้บริหารระดับสูง ว่า “ระบบล่มค่า”
เอาล่ะสิ นายใหญ่สั่งลงมาที่ฝ่าย IT จนเป็นเรื่องใหญ่มาก
หน่วยงานที่เป็นเจ้าของระบบ หัวหน้าฝ่ายก็ไม่รู้ว่า ลูกน้องตัวเอง ไปแจ้งว่า “ระบบล่ม”
หนึ่งวันที่เป็นเรื่องเป็นราวใหญ่โต จนกระทั่งสืบหาสาเหตุเจอว่า
1. มีหน่วยงาน IT ย่อย ที่เป็น Support ของระบบงานนี้ Programmer ได้ทำการ Update Sourcecode และ Update SQL Database Production โดยไม่ Where ทำให้ข้อมูลลูกค้าหายหมดเกลี้ยง
2. ระบบยังใช้งานได้ตามปกติ Server, Network ใดๆ ปกติหมด ไม่ได้ล่ม แต่สิ่งที่หายไปคือ ข้อมูลลูกค้า
เรื่องนี้สอนอะไรเราบ้าง ในมุมของ IT
1. ทำไมองค์กรไม่ทำ Change Management ทำไมถึงปล่อยให้ Programmer เข้าถึง Production ได้เลย
2. ทำไมถึง Update Sourcecode และ SQL บน Production โดยไม่ทำการทดสอบ ไม่มีกระบวนการทำ Change Configuration ไม่มีการทำ Test , Staging นอกจากนั้น เมื่อ Update Production แล้ว (ถ้ารู้ว่าไม่มีตัวเทสอยู่แล้ว) ทำไมไม่ Test in Production จะได้เจอปัญหาก่อนที่ End User จะเจอ
3. กระบวนการ Report Incident การแจ้งงาน (ไม่รู้ว่ามีหรือเปล่า) แต่ปล่อยให้พนักงานแจ้ง Incident ผ่าน Group Line ว่า “ระบบล่ม” ทั้งที่ตัวระบบ ไม่ได้ล่ม ยังสามารถเข้าใช้งานได้ปกติ แต่ตัวระบบส่วนที่มีปัญหาจริงๆ คือ ข้อมูลที่หายไป
เห็นได้ชัดว่ากระบวนการ IT ของบริษัทนี้มีปัญหา
ในมุมของการสื่อสาร
หลังจากสืบทราบหา Root Cause กันเสร็จ Director ของพนักงานอบรมพนักงานยกใหญ่ ในการเรื่องการ สื่อสารที่ตัวพนักงานที่แจ้งปัญหา แยกไม่ออกว่า ควรจะแจ้งงานทางไหน และแจ้งงานอย่างไรให้ตรงจุด
ถ้าเปรียบ ระบบงาน ในองค์กร คือ บ้านหลังนึง (ในหมู่บ้านที่อยู่กันหลายหลังและมีนิติบุคคลดูแล)
พนักงาน (End User) ในฐานะซึ่งเป็นผู้อยู่อาศัยในบ้าน เข้าไปเจอ ว่ามีของสำคัญหาย แต่ดันไปแจ้งกับนิติบุคคล (IT) ว่าบ้านพัง
พังยังไง? เดี๋ยวก่อน! บ้านไม่ได้พัง แต่ของในบ้านหาย มันคนละเรื่องกันนะ
พนักงานเองก็ไม่ได้มีความรู้ความเข้าใจในด้าน IT เรียกได้ว่า ใช้อย่างเดียวจริงๆ ผู้บริหารก็หลอนๆ กันไป วันไหนโดนแจ้งว่าระบบจะล่มจะดาวน์ หน่วยงาน IT ถูกมองว่าเป็นหน่วยงานที่ไม่มีเสถียรภาพ
ทางแก้ที่แนะนำ คือมองเรื่องนี้เป็นโอกาสดี เมื่อมีเหตุการณ์เกิด หน่วยงาน IT ควรรีบเสนอให้ Implement Change Management Process ขึ้นมาด่วนๆ อาจจะลองดูตาม ITIL หรือ ISO27001 เป็นแนวทาง โดยให้ผู้บริหารสนับสนุน ใช้จังหวะนี้ขอ Sponsor ในการทำเป็น Project Transform องค์กร ทำเสร็จก็สื่อสารกับพนักงานและหน่วยงาน IT ย่อยๆ ภายใน ถือเป็นการปรับปรุง Process ไม่ให้เกิดเหตุการณ์แบบนี้อีกในอนาคต
โฆษณา
- ดาวน์โหลดแอปพลิเคชัน
- © 2024 Blockdit
