Incident, Request, Change และ Problem Management บน ServiceNow — แต่ละกระบวนการออกแบบอย่างไร เหตุใด CMDB ที่อยู่เบื้องหลังจึงเป็นตัวตัดสินว่าทั้งหมดนี้จะได้ผลหรือไม่ และจะทยอยใช้งานเป็นระยะที่คุ้มค่าในตัวเองได้อย่างไร ส่งมอบเป็นภาษาไทยหรืออังกฤษจากกรุงเทพฯ
องค์กรส่วนใหญ่มาถึง ServiceNow ITSM จากระบบ ticketing เดิม จากกล่องอีเมลกลาง หรือทั้งสองอย่าง และสิ่งที่พวกเขามองหาไม่ใช่การเปิด ticket ที่เร็วขึ้น แต่คือการมองเห็น — บริการใดที่ล้มเหลวจริง การเปลี่ยนแปลงใดเป็นต้นเหตุ และความผิดพลาดเดิมกลับมาเกิดซ้ำที่จุดใด สิ่งเหล่านี้ต้องการให้กระบวนการหลักทั้งสี่อยู่บนแพลตฟอร์มเดียวกัน บนฐานข้อมูล configuration ที่สะท้อนความเป็นจริง
ทุกสิ่งที่เหลือในแพลตฟอร์ม ITSM ขึ้นอยู่กับว่าสี่กระบวนการนี้ถูกออกแบบมาดีหรือไม่
กู้คืนบริการให้เร็วที่สุด การตัดสินใจที่สำคัญคือการ routing การคำนวณลำดับความสำคัญ และการมอบหมายงาน หากออกแบบผิด ตัวชี้วัดปลายทางทั้งหมดจะไร้ความหมาย เพราะงานไปกองอยู่ผิดคิวก่อนที่ใครจะเริ่มลงมือ
แคตตาล็อกสิ่งที่ผู้ใช้ขอได้ พร้อม workflow การให้บริการเบื้องหลังแต่ละรายการ บททดสอบของแคตตาล็อกที่ดีคือพนักงานเลือกใช้มันแทนการทักหาคนโดยตรงหรือไม่ ซึ่งทำให้การใช้ถ้อยคำและการจัดหมวดหมู่เป็นการตัดสินใจเชิงธุรกิจ ไม่ใช่เรื่องของ IT อย่างเดียว
ควบคุมการเปลี่ยนแปลงโดยไม่กลายเป็นอุปสรรค เส้นทางการอนุมัติควรสะท้อนความเสี่ยงจริง เมื่อทุกการเปลี่ยนแปลงต้องผ่านคณะกรรมการชุดเดียวกัน ทีมงานจะหาทางเลี่ยงกระบวนการ และคุณจะสูญเสียการมองเห็นซึ่งเป็นเหตุผลที่มีกระบวนการนี้ตั้งแต่แรก
กระบวนการที่ถูกข้ามบ่อยที่สุด และเป็นกระบวนการที่ลดปริมาณงานได้จริง หากไม่มี ทีมงานจะแก้ incident เดิมซ้ำแล้วซ้ำเล่า และไม่มีใครเป็นเจ้าของต้นเหตุที่แท้จริง
ประโยชน์ทุกข้อของ ITSM ที่เกินไปกว่าการเปิด ticket ได้เร็วขึ้น ล้วนขึ้นอยู่กับการรู้ว่าคุณมีอะไรอยู่ และอะไรพึ่งพาอะไร
เติมเฉพาะ Configuration Item ที่กระบวนการของคุณอ้างอิงถึงในวันนี้ CMDB ที่แคบแต่คนเชื่อถือ มีค่ามากกว่า CMDB ที่ครบถ้วนแต่ข้อมูลเพี้ยนไปแล้วภายในสองไตรมาส
Discovery และการเชื่อมต่อระบบคือสิ่งที่ทำให้ CMDB เป็นปัจจุบัน การดูแลด้วยมือล้มเหลวอย่างคาดเดาได้ ไม่ใช่เพราะคนไม่ใส่ใจ แต่เพราะไม่มีใครมีหน้าที่หลักคือการอัปเดตข้อมูลที่ไม่มีใครเห็นว่าถูกใช้
การรู้ว่าคุณมีเซิร์ฟเวอร์สองร้อยเครื่องคือการทำ inventory การรู้ว่าเครื่องใดในนั้นที่ระบบเงินเดือนพึ่งพาอยู่คือ service management และนั่นคือสิ่งที่ทำให้การประเมินผลกระทบเป็นไปได้
Configuration Item ทุกประเภทต้องมีเจ้าของที่ระบุชื่อได้ ซึ่งรับผิดชอบความถูกต้องของข้อมูล ข้อมูลที่ไม่มีเจ้าของจะเสื่อมลงอย่างเงียบ ๆ และมักถูกค้นพบระหว่างเกิด incident ซึ่งเป็นจังหวะที่แย่ที่สุด
วิธีที่เราจัดลำดับการปล่อยระบบ ITSM เพื่อให้แต่ละระยะให้คุณค่าก่อนที่ระยะถัดไปจะเริ่ม
สองกระบวนการที่มีปริมาณงานสูงที่สุด พร้อม Service Catalogue ที่ใช้งานได้จริง เห็นผลลัพธ์ที่ดีขึ้นภายในไม่กี่เดือน และองค์กรได้เรียนรู้แพลตฟอร์มจากกระบวนการที่สัมผัสทุกวัน
Change Management ที่การอนุมัติอิงตามความเสี่ยง บน CMDB ที่มีขอบเขตเท่ากับบริการที่ Change ส่งผลกระทบจริง การวางระยะนี้เป็นลำดับที่สองหมายความว่ามันมาถึงผู้ใช้ที่เชื่อมั่นในเครื่องมืออยู่แล้ว
จัดการกับปริมาณงานที่เกิดซ้ำ และลดคำถามซ้ำด้วย Knowledge ระยะนี้คือจุดที่จำนวน ticket เริ่มลดลงจริง ไม่ใช่แค่ถูกประมวลผลได้เร็วขึ้น
Dashboard ที่ตอบคำถามของผู้บริหารได้ มีการทบทวนอย่างสม่ำเสมอ และมีเจ้าของภายในที่ระบุชื่อได้คอยดูแล backlog นี่คือสิ่งที่ทำให้แพลตฟอร์มพัฒนาต่อไปหลังผู้ให้บริการถอนตัว
เนื้อหาเชิงปฏิบัติสำหรับองค์กรที่กำลังพิจารณาหรือใช้งาน ServiceNow ในประเทศไทย
คำถามที่องค์กรไทยถามเมื่อกำลังเปรียบเทียบ ITSM บน ServiceNow กับเครื่องมือที่ใช้อยู่
ITSM (IT Service Management) บน ServiceNow คือชุด workflow ที่จัดการว่างานด้าน IT จะไปถึงคนที่ถูกต้องและถูกแก้ไขอย่างไร — Incident เมื่อมีสิ่งใดเสีย Request เมื่อมีผู้ต้องการบางสิ่ง Change เมื่อมีการแก้ไขระบบ และ Problem เมื่อความผิดพลาดเดิมเกิดซ้ำ ServiceNow ให้กระบวนการเหล่านี้มาในรูป workflow ที่ปรับแต่งได้บนแพลตฟอร์มเดียว โดยมีฐานข้อมูล configuration ร่วมกันอยู่เบื้องหลัง
ไม่จำเป็น ค่ามาตรฐานของ ServiceNow สอดคล้องกับ ITIL อยู่แล้ว ซึ่งทำให้ ITIL เป็นเส้นทางที่ง่ายที่สุด แต่คุณไม่จำเป็นต้องรับกรอบทั้งหมดมาใช้ ในทางปฏิบัติ องค์กรไทยส่วนใหญ่ใช้ค่ามาตรฐานแนว ITIL สำหรับ Incident และ Request แล้วออกแบบ Change Management ให้เข้ากับข้อกำหนดด้านการอนุมัติและการตรวจสอบของตนเอง
ระบบ ticketing บันทึกว่ามีคนร้องขอบางอย่าง ส่วน ITSM เชื่อมโยงบันทึกนั้นเข้ากับบริการและ Configuration Item ที่อยู่เบื้องหลัง ทำให้คุณเห็นผลกระทบ ระบุสาเหตุที่เกิดซ้ำ และควบคุมการเปลี่ยนแปลงได้ ความต่างที่เห็นชัดที่สุดอยู่ที่รายงาน — ระบบ ticketing บอกว่าคุณปิดงานไปกี่ใบ ส่วน ITSM บอกว่าทำไมงานเหล่านั้นถึงเกิดขึ้น
ได้ แพลตฟอร์มรองรับภาษาไทยสำหรับผู้ใช้ทั่วไป รายการใน Service Catalogue บทความ Knowledge และการแจ้งเตือน และสามารถใช้งานสองภาษาพร้อมกันได้ เพื่อให้พนักงานไทยและทีมต่างประเทศทำงานบน instance เดียวกัน EmpowerAll จัดทำเอกสารกระบวนการและการอบรมได้ทั้งภาษาไทยและภาษาอังกฤษ
ควรทยอยเป็นระยะเกือบทุกกรณี การปล่อยระยะแรกที่ครอบคลุม Incident, Request และ Service Catalogue ที่ใช้งานได้จริง จะให้คุณค่าที่มองเห็นได้เร็ว และทำให้องค์กรได้เรียนรู้พฤติกรรมของแพลตฟอร์ม จากนั้น Change, Problem และ CMDB ที่มีธรรมาภิบาลจึงตามมาบนทีมที่เข้าใจเครื่องมืออยู่แล้ว ซึ่งช่วยให้การยอมรับระบบดีขึ้นอย่างเห็นได้ชัด