งบประมาณโครงการ ServiceNow ไปอยู่ที่ไหนกันแน่ การตัดสินใจข้อใดที่ขยับตัวเลขมากที่สุด และคำถามที่ทำให้ข้อเสนอจากผู้ให้บริการสองรายเปรียบเทียบกันได้จริง คู่มือสำหรับผู้ซื้อ จากที่ปรึกษาที่กำหนดขอบเขตโครงการเหล่านี้เป็นอาชีพ
งบประมาณ ServiceNow ส่วนใหญ่ผิดพลาดในรูปแบบเดียวกัน คือองค์กรตั้งงบเฉพาะค่า implementation ได้รับอนุมัติ แล้วจึงค้นพบว่าค่า license และต้นทุนการดูแลระบบหลังจากนั้นไม่เคยอยู่ในตัวเลขเลย การแยกทั้งสามส่วนออกจากกันตั้งแต่ต้นทำให้ business case มั่นคง และช่วยให้ไม่ต้องมีบทสนทนาที่ลำบากใจในปีที่สอง
หากคุณต้องการตัวเลขที่เล็กลง นี่คือปัจจัยที่ได้ผลจริง และปัจจัยที่ดูเหมือนจะได้ผลเท่านั้น
ตัวแปรที่ใหญ่ที่สุดเพียงตัวเดียว ระบบคลาวด์สมัยใหม่ที่มีเอกสาร API ชัดเจนนั้นตรงไปตรงมา ส่วนระบบ on-premise เดิมที่ไม่มี API หรือระบบที่ทีมเจ้าของไม่มีเวลาให้ อาจมีต้นทุนสูงกว่าหลายเท่าสำหรับการเชื่อมต่อที่ดูเหมือนกัน
องค์กรที่ยอมรับค่ามาตรฐานของ ServiceNow ในจุดที่ดีพออยู่แล้ว ใช้งบน้อยกว่าองค์กรที่ออกแบบทุก workflow ใหม่อย่างมีนัยสำคัญ การปรับแต่งไม่ได้เป็นเพียงต้นทุนการพัฒนา แต่เป็นภาษีถาวรที่จ่ายทุกครั้งที่ upgrade
ลูกค้าเกือบทุกรายขอย้ายข้อมูลทั้งหมดในตอนแรก และเกือบทุกรายไม่ได้ต้องการขนาดนั้น โดยทั่วไป incident ที่ยังเปิดอยู่บวกกับประวัติที่ปิดแล้วในช่วงเวลาที่กำหนด ก็เพียงพอทั้งต่อการปฏิบัติงานและการตรวจสอบ ด้วยปริมาณงานเพียงเศษเสี้ยว
ทุกผลิตภัณฑ์ที่เพิ่มเข้ามาทวีคูณงานออกแบบ ทดสอบ และอบรม และยืดระยะเวลาก่อนที่ใครจะเห็นคุณค่า การแบ่งปล่อยเป็นระยะช่วยลดทั้งต้นทุนและความเสี่ยง
เจ้าของกระบวนการที่เข้าร่วมได้เพียงบางเวลาทำให้ระยะเวลาโครงการยืดออก และเวลาที่ยืดออกคือต้นทุน นี่คือปัจจัยที่ลูกค้ามองข้ามบ่อยที่สุดเวลาเปรียบเทียบข้อเสนอ
การตัดงบอบรมดูเหมือนเป็นการประหยัด และมักเป็นการตัดที่แพงที่สุดในรายการนี้ แพลตฟอร์มที่พนักงานเลี่ยงไม่ใช้ ให้ผลตอบแทนเป็นศูนย์ ไม่ว่าจะสร้างมาถูกเพียงใด
รวมถึงเราด้วย คำตอบที่สอดคล้องกันต่อคำถามเหล่านี้จะทำให้ข้อเสนอสองฉบับเปรียบเทียบกันได้จริง
การอนุมัติมักขึ้นอยู่กับสิ่งที่หลีกเลี่ยงได้มากกว่าตัวเลขต้นทุน นี่คือรายการผลประโยชน์ที่ทนต่อการตรวจสอบ
ชั่วโมงที่ปัจจุบันหมดไปกับการส่งต่องานด้วยมือ การตามอนุมัติผ่านแชท และการกรอกข้อมูลเดิมซ้ำในหลายระบบ วัดได้ก่อนเริ่มโครงการ ซึ่งเป็นสิ่งที่ทำให้การอ้างผลลัพธ์ภายหลังน่าเชื่อถือ
สัดส่วนของ incident ที่เกิดซ้ำ Problem Management และการลดคำถามซ้ำด้วย Knowledge ช่วยลดปริมาณงาน แทนที่จะเพียงประมวลผลได้เร็วขึ้น เป็นผลประโยชน์ที่ทบต้นขึ้นทุกปี
บันทึกการเปลี่ยนแปลง การอนุมัติ และข้อมูลทรัพย์สิน ถูกรวบรวมอย่างต่อเนื่องแทนการเร่งประกอบขึ้นใหม่เมื่อใกล้กำหนดส่ง องค์กรที่มีภาระรายงานต่อหน่วยงานกำกับดูแล มักพบว่ารายการนี้เพียงรายการเดียวก็เพียงพอต่อการอนุมัติ
Software Asset Management และ Discovery มักเผยให้เห็นสิทธิ์การใช้งานที่จ่ายเงินแล้วแต่ไม่ได้ใช้ และฮาร์ดแวร์ที่ไม่มีใครระบุที่มาได้ นี่เป็นหนึ่งในไม่กี่ผลประโยชน์ที่ปรากฏในบัญชีการเงินโดยตรง
เนื้อหาเชิงปฏิบัติสำหรับองค์กรที่กำลังพิจารณาหรือใช้งาน ServiceNow ในประเทศไทย
คำถามที่องค์กรไทยถามเราเมื่อกำลังจัดทำ business case สำหรับ ServiceNow
สามส่วนที่แยกจากกัน และมักถูกสับสนรวมกัน ส่วนแรกคือค่า subscription license ที่จ่ายให้ ServiceNow ซึ่งขึ้นกับผลิตภัณฑ์ที่เปิดใช้และจำนวนผู้ใช้งาน ส่วนที่สองคือค่า implementation ซึ่งเป็นต้นทุนครั้งเดียวของการออกแบบ configure เชื่อมต่อระบบ ย้ายข้อมูล และอบรม ส่วนที่สามคือต้นทุนการดูแลระบบหลังจากนั้น ทั้งผู้ดูแลระบบภายใน งานพัฒนาเพิ่มเติม และการ upgrade ข้อเสนอที่พูดถึงเฉพาะส่วนกลางถือว่ายังไม่ครบ
เพราะตัวเลขที่ไม่มีขอบเขตงานกำกับย่อมทำให้เข้าใจผิด และในงานที่ปรึกษาและบริการมืออาชีพ ตัวเลขที่ประกาศไว้จะชวนให้เปรียบเทียบข้อเสนอที่เทียบกันไม่ได้ ผู้ให้บริการสองรายที่เสนอยอดรวมเท่ากัน อาจต่างกันมหาศาลในเรื่องปริมาณการออกแบบกระบวนการ งานเชื่อมต่อระบบ และการสนับสนุนหลัง go-live ที่รวมอยู่ เราเลือกที่จะสำรวจสภาพแวดล้อมของคุณก่อน แล้วให้ตัวเลขที่คุณใช้อ้างอิงได้จริง
ปรับให้อยู่บนฐานเดียวกันก่อนเทียบยอดรวม ตรวจสอบว่าแต่ละข้อเสนอครอบคลุมโมดูลเดียวกัน จำนวนและความซับซ้อนของการเชื่อมต่อเท่ากัน ปริมาณการย้ายข้อมูลเท่ากัน ขอบเขตการอบรมเท่ากัน และระยะ hypercare เท่ากัน แล้วถามแต่ละรายว่าราคาจะเปลี่ยนอย่างไรหากสมมติฐานข้อใดข้อหนึ่งไม่เป็นจริง ความต่างของยอดรวมมักกลายเป็นความต่างของสมมติฐาน ไม่ใช่ของอัตราค่าบริการ
การเชื่อมต่อระบบ และการตัดสินใจเรื่องกระบวนการที่ไม่ลงตัว ตามลำดับ ทุกระบบที่เชื่อมเพิ่มขึ้นหมายถึงงานออกแบบ พัฒนา ทดสอบ และจัดการข้อผิดพลาดที่เพิ่มตาม และระบบเดิมหรือระบบ on-premise ที่ไม่มี API สมัยใหม่มีต้นทุนสูงกว่าระบบคลาวด์ที่มี API หลายเท่า ส่วนการตัดสินใจที่ไม่ลงตัวมีต้นทุนสูงกว่าอีก เพราะทำให้งานพัฒนาหยุดชะงักทั้งที่ทีมงานถูกจองเวลาไว้แล้ว
ได้ และมักเป็นแนวทางที่ถูกต้อง การปล่อยระยะแรกที่มีขอบเขตเพียง Incident, Request และ Service Catalogue ช่วยสร้างฐานของแพลตฟอร์ม พิสูจน์คุณค่าให้ผู้สนับสนุนโครงการเห็น และทำให้ทีมได้เรียนรู้พฤติกรรมของระบบ การขยายบนฐานที่ใช้งานได้จริงมีต้นทุนต่ำกว่าและเสี่ยงน้อยกว่าโครงการใหญ่ครั้งเดียวที่ต้องถูกตั้งแต่แรก