การวางระบบ ServiceNow สำหรับองค์กรไทยคืองานแบบไหน — ขั้นตอนการทำงาน ระยะเวลาที่เป็นจริง สิ่งที่ทีมของคุณเองต้องเตรียม และจุดที่โครงการมักผิดพลาด เขียนโดยที่ปรึกษาที่ได้รับ ServiceNow certification ซึ่งประจำอยู่ที่กรุงเทพฯ
การวางระบบ ServiceNow ไม่ใช่การติดตั้งซอฟต์แวร์ แพลตฟอร์มทำงานอยู่แล้วก่อนที่คุณจะเริ่ม สิ่งที่คุณกำลังลงทุนคือการตัดสินใจ — จะทำให้กระบวนการใดเป็นมาตรฐาน Service Catalogue จะให้บริการอะไรบ้าง ข้อมูลใน CMDB จะถูกเติมและรักษาความถูกต้องอย่างไร และระบบเดิมระบบใดต้องคุยกับ ServiceNow ได้ ส่วนการ configure คือส่วนที่ง่ายที่สุด จุดที่ทำให้โครงการสำเร็จหรือสะดุดคือการทำให้องค์กรตกลงกันเรื่องกระบวนการได้
ทุกโครงการปรับให้เข้ากับลูกค้าแต่ละราย แต่ลำดับขั้นตอนด้านล่างนี้ใช้ร่วมกันในทุกโครงการที่เราส่งมอบในประเทศไทย
เราสำรวจสิ่งที่คุณใช้งานอยู่ในปัจจุบัน ทั้งเครื่องมือ กระบวนการ ปริมาณงาน ปัญหาที่พบ และระบบที่ต้องเชื่อมต่อ ผลลัพธ์คือภาพขอบเขตและปริมาณงานที่อ้างอิงจากสภาพแวดล้อมจริงของคุณ ไม่ใช่การประเมินแบบทั่วไป
Workshop ร่วมกับเจ้าของบริการเพื่อสรุปว่า Incident, Request, Change และ Problem จะทำงานอย่างไรจริง ๆ ทุกการตัดสินใจถูกบันทึกและอนุมัติก่อนเริ่ม configure เพราะการกลับมารื้อข้อสรุประหว่างพัฒนาคือสาเหตุหลักที่ทำให้โครงการบานปลาย
Configure แพลตฟอร์มเป็นรอบ ๆ (sprint) โดยทีมของคุณได้เห็นระบบที่ใช้งานได้จริงตั้งแต่เนิ่น ๆ เราใช้พฤติกรรมมาตรฐานของ ServiceNow ทุกจุดที่เหมาะสม และเก็บการปรับแต่งไว้เฉพาะจุดที่ต่างจริง เพราะโค้ดที่เขียนเองคือสิ่งที่ทำให้การ upgrade ในอนาคตยากขึ้น
เชื่อมแพลตฟอร์มเข้ากับ directory service อีเมล ระบบ monitoring และระบบงานหลักที่อยู่ในขอบเขต จากนั้นย้ายเฉพาะประวัติข้อมูลที่จำเป็นจริงจากระบบเดิม องค์กรส่วนใหญ่ต้องการข้อมูลย้อนหลังน้อยกว่าที่คิดไว้ตอนแรกมาก
User Acceptance Testing กับผู้ที่ต้องใช้เครื่องมือนี้ทุกวันจริง ตามด้วยการอบรมแยกตามบทบาท — การอบรมผู้ปฏิบัติงานกับการอบรมผู้ใช้ทั่วไปเป็นคนละเรื่องกัน และไม่ควรรวมเป็นครั้งเดียว
ตัดระบบเข้าสู่การใช้งานจริง ตามด้วยช่วงสนับสนุนเข้มข้นที่ปัญหาเรื่อง routing การมอบหมายงาน และการแจ้งเตือน ถูกแก้ภายในไม่กี่ชั่วโมงแทนที่จะรอรอบพัฒนาถัดไป ขั้นตอนนี้คือขั้นตอนที่ถูกตัดออกจากงบประมาณบ่อยที่สุด และเป็นขั้นตอนที่มีคนเสียดายภายหลังมากที่สุด
สาเหตุที่พบบ่อยที่สุดของการที่โครงการ ServiceNow ล่าช้า ไม่ใช่ฝั่งผู้ให้บริการ แต่คือเวลาของฝั่งลูกค้า
ต้องมีผู้สนับสนุนโครงการที่ชี้ขาดข้อขัดแย้งเรื่องกระบวนการระหว่างหน่วยงานได้อย่างรวดเร็ว หากไม่มี workshop ออกแบบจะได้ผลลัพธ์เป็นทางเลือกแทนที่จะเป็นข้อสรุป และงานพัฒนาจะเริ่มไม่ได้
เจ้าของกระบวนการ Incident, Change และ Request ต้องมีเวลาให้ช่วงออกแบบอย่างแท้จริง ไม่ใช่เพียงมาเข้าประชุมพอเป็นพิธี ควรใส่เวลาส่วนนี้ไว้ในแผนโครงการ เพราะเป็นต้นทุนจริง
Directory, อีเมล, ระบบ monitoring และทุกระบบในขอบเขตการเชื่อมต่อ ต้องมี account, endpoint และคนที่รู้จักระบบนั้นจริง ความล่าช้าเรื่องสิทธิ์เข้าถึงคือสิ่งที่ทำให้ตารางงานเลื่อนอย่างเงียบที่สุด
ต้องมีผู้รับผิดชอบสื่อสารกับผู้ใช้ว่าอะไรจะเปลี่ยนและเปลี่ยนเมื่อไร แพลตฟอร์มที่สมบูรณ์แบบทางเทคนิคแต่ไม่มีใครรู้ ก็ยังถูกข้ามไปใช้ LINE หรือโทรศัพท์อยู่ดี
รูปแบบที่เราพบซ้ำ ๆ ในองค์กรไทย ลองใช้ตรวจสอบแผนงานของคุณเอง
การลอก workflow เดิมมาไว้บนเครื่องมือใหม่อย่างซื่อสัตย์ ให้ผลลัพธ์เป็นปัญหาเดิมบนแพลตฟอร์มที่แพงขึ้น ช่วงวางระบบคือช่วงเดียวที่การเปลี่ยนกระบวนการเป็นไปได้ในทางการเมืององค์กร การใช้โอกาสนั้นไปกับการลอกของเดิมคือการทิ้งโอกาสไป
ทุก script ที่เขียนเองและทุกตารางที่แก้ไข คือต้นทุนที่คุณต้องจ่ายซ้ำทุกครั้งที่ upgrade องค์กรที่ยึดกับค่ามาตรฐานให้มากที่สุด จะเคลื่อนตัวได้เร็วกว่าไปอีกหลายปีข้างหน้า
CMDB ที่ทะเยอทะยานแต่ไม่มีใครดูแล จะกลายเป็นข้อมูลที่ไม่มีใครเชื่อถือภายในไม่กี่เดือน และ CMDB ที่ไม่มีใครเชื่อถือแย่กว่าการไม่มีเลย ควรเริ่มจาก Configuration Item ที่กระบวนการของคุณอ้างอิงถึงจริง
การอบรมรวมครั้งเดียวก่อน go-live ไม่เปลี่ยนพฤติกรรมคน ทีมผู้ปฏิบัติงานต้องได้ลงมือจริงในสภาพแวดล้อมที่พังได้ และต้องได้ทำมากกว่าหนึ่งครั้ง
การยอมรับระบบถูกตัดสินในไม่กี่สัปดาห์หลัง go-live ถ้าปัญหา routing และการมอบหมายงานช่วงแรกถูกกองไว้ใน backlog ผู้ใช้จะสรุปว่าเครื่องมือใช้ไม่ได้ และกลับไปใช้ช่องทางเดิมอย่างถาวร
แพลตฟอร์มต้องมีเจ้าของภายในที่ระบุชื่อได้ สำหรับดูแล backlog การปล่อยรุ่นใหม่ และธรรมาภิบาลของกระบวนการ หากไม่มี ระบบจะค่อย ๆ เบี่ยงเบนออกจากการออกแบบ และคุณค่าของโครงการจะเสื่อมลงอย่างเงียบ ๆ
เนื้อหาเชิงปฏิบัติสำหรับองค์กรที่กำลังพิจารณาหรือใช้งาน ServiceNow ในประเทศไทย
คำถามที่องค์กรไทยถามเราบ่อยที่สุดก่อนเริ่มโครงการ ServiceNow
โครงการระยะแรกที่มีขอบเขตชัดเจน — โดยทั่วไปคือ ITSM ส่วน Incident, Request และ Change พร้อม Service Catalogue — มักใช้เวลาประมาณ 3 ถึง 5 เดือนนับจากวันเริ่มโครงการจนถึงวัน go-live ระยะเวลาจะยืดออกเมื่อมีการเชื่อมต่อกับระบบ ERP หรือ HR เดิมขององค์กร เมื่อยังไม่ได้ข้อสรุปเรื่องกระบวนการก่อนเริ่มพัฒนา หรือเมื่อทีมงานฝั่งลูกค้าให้เวลาได้เพียงบางส่วน EmpowerAll จะทำ Discovery ก่อนเสมอ เพื่อให้ระยะเวลาที่ประเมินอ้างอิงจากสภาพแวดล้อมจริงขององค์กรคุณ ไม่ใช่จากแม่แบบทั่วไป
ไม่จำเป็นทั้งหมด แต่ต้องได้ข้อสรุปว่า Incident, Request และ Change ควรไหลอย่างไรก่อนเริ่มการ configure ระบบ ServiceNow มาพร้อมกระบวนการมาตรฐานที่สอดคล้องกับ ITIL อยู่แล้ว โครงการที่ประสบความสำเร็จมากที่สุดคือโครงการที่เลือกใช้ค่ามาตรฐานในจุดที่ดีพออยู่แล้ว และเก็บการออกแบบเฉพาะไว้สำหรับจุดที่องค์กรแตกต่างจริง ๆ การพยายามลอกกระบวนการเดิมที่มีปัญหาอยู่แล้วมาไว้บนแพลตฟอร์มใหม่ คือความผิดพลาดที่มีต้นทุนสูงที่สุดที่เราพบบ่อยที่สุด
ได้ และเราสนับสนุนให้เป็นเช่นนั้น ที่ปรึกษาของเราทำงานเคียงข้างผู้ดูแลระบบและเจ้าของกระบวนการของคุณ เพื่อให้เกิดการถ่ายทอดความรู้ระหว่างโครงการ ไม่ใช่หลังจบโครงการ และภายใต้รูปแบบ Service on Demand คุณยังสามารถเรียกใช้ผู้เชี่ยวชาญที่ได้รับ certification ได้หลัง go-live โดยไม่ต้องมีสัญญาผูกมัดระยะยาว
ได้ทั้งสองภาษา ทั้ง workshop เอกสารกระบวนการ การอบรม และการสนับสนุนหลังใช้งาน สามารถดำเนินการเป็นภาษาไทยหรือภาษาอังกฤษ ที่ปรึกษาของเราประจำอยู่ที่กรุงเทพฯ ไม่ได้บินเข้ามาเฉพาะช่วง workshop ดังนั้นการอบรมผู้ใช้งานและการสื่อสารการเปลี่ยนแปลงจึงทำได้ในภาษาที่พนักงานของคุณใช้ทำงานจริง
ช่วง 8 ถึง 12 สัปดาห์แรกหลัง go-live คือช่วงที่ตัดสินว่าองค์กรจะยอมรับระบบใหม่หรือไม่ ช่วงนี้ต้องมี hypercare — มีคนคอยเฝ้าคิวงาน แก้ปัญหาการ routing และการมอบหมายงานได้อย่างรวดเร็ว และคอยโค้ชทีมผู้ปฏิบัติงาน เราวางแผน hypercare ไว้ในโครงการตั้งแต่ต้น แทนที่จะแยกขายเป็นบริการ support ต่างหาก