ก่อนเซ็นสัญญาดูแลระบบรายปี ต้องดูอะไรให้ไม่โดนลอยแพ

ทุกครั้งที่สัญญาพัฒนาระบบจบลง อีกสัญญาหนึ่งเริ่มต้นทันที คือสัญญาดูแลระบบรายปีที่มักถูกมองข้ามเพราะเซ็นในช่วงที่ทุกคนอยากปิดโครงการเร็ว ๆ คำถามที่มักไม่มีใครถามในห้องประชุมตอนนั้นคือ ถ้าระบบมีปัญหาตอนตีสาม จะได้รับความช่วยเหลือภายในกี่ชั่วโมง และถ้าผู้ให้บริการทำไม่ได้ตามที่คุยไว้ปากเปล่า องค์กรมีอะไรอ้างอิงได้บ้าง บทความนี้เขียนจากมุมของทีมที่ต้องอยู่กับสัญญาดูแลไปอีกหลายปี ไม่ใช่มุมของคนที่เซ็นแล้วเดินออกจากห้องประชุม

เพราะสัญญาฉบับนี้จะถูกเปิดอ่านซ้ำที่สุด

สัญญาดูแล ไม่ใช่แค่เอกสารแนบท้ายสัญญาพัฒนา

องค์กรส่วนใหญ่ให้ความสำคัญกับสัญญาพัฒนาระบบมาก เพราะมีมูลค่าสูงและใช้เวลาตรวจนานหลายสัปดาห์ ฝ่ายกฎหมายอ่านทุกข้อ ฝ่ายจัดซื้อเทียบราคาหลายเจ้า แต่พอถึงสัญญาดูแลระบบรายปีที่ตามมา กลับมักตรวจแบบผ่าน ๆ เพราะดูเหมือนเป็นเรื่องรองที่แนบมาพร้อมกัน ทั้งที่มูลค่ารวมตลอดอายุสัญญาดูแลมักสูงกว่าค่าพัฒนาครั้งแรกในระยะยาว

สิ่งที่เกิดขึ้นตามมาคือคำถามว่าสัญญาฉบับนี้เขียนไว้ว่าอย่างไร มากกว่าคำถามว่าระบบถูกสร้างมาดีแค่ไหน เพราะระบบที่ออกแบบมาดีที่สุดก็ยังมีวันที่ต้องพึ่งทีมดูแลอยู่ดี ไม่ว่าจากบั๊กที่หลุดรอดมา การเปลี่ยนแปลงของ dependency ภายนอก หรือโหลดการใช้งานที่เพิ่มขึ้นเกินที่ออกแบบไว้แต่แรก วันที่ปัญหาเกิดขึ้นจริง เอกสารที่ทีมไอทีขององค์กรจะหยิบขึ้นมาอ่านคือสัญญาดูแลระบบ ไม่ใช่สัญญาพัฒนาที่เซ็นไปแล้วหลายเดือนก่อน

แยกให้ชัด Response Time ไม่ใช่ Resolution Time

กับดักที่พบบ่อยที่สุดคือสัญญาพูดถึง "เวลาตอบสนอง" แบบรวม ๆ โดยไม่แยกสองค่านี้ออกจากกัน Response Time คือเวลาที่ผู้ดูแลรับทราบและเริ่มดำเนินการหลังได้รับแจ้ง ส่วน Resolution Time คือเวลาที่ปัญหาถูกแก้จนใช้งานได้จริง สองค่านี้ต่างกันมากในทางปฏิบัติ

ตัวอย่างเช่น สัญญาอาจเขียนว่า รับทราบภายใน 1 ชั่วโมง และแก้ไขให้แล้วเสร็จภายใน 8 ชั่วโมง สำหรับปัญหาระดับรุนแรงที่สุด ตัวเลขจริงต้องต่อรองกันตามความสำคัญของระบบแต่ละองค์กร ประเด็นสำคัญคือสัญญาต้องระบุทั้งสองค่าแยกกันเสมอ องค์กรที่เจอปัญหาจริงมักพบว่าผู้ให้บริการรับทราบไว แต่ไม่มีข้อผูกพันเรื่องเวลาแก้ไขเลย ระบบล่มอยู่ได้เป็นวัน ขณะที่สัญญาระบุแค่ว่า "ตอบกลับภายใน 1 ชั่วโมง" ซึ่งเป็นจริงตลอดเวลา เพราะไม่มีใครผูกพันว่าต้องแก้เสร็จเมื่อไร

อีกจุดที่ควรถามคือ Response Time นับจากเวลาไหน บางสัญญานับจากเวลาที่ระบบตรวจพบปัญหาอัตโนมัติ บางสัญญานับจากเวลาที่มีคนโทรแจ้งเข้าไป ความต่างนี้อาจกินเวลาไปหลายชั่วโมงโดยไม่มีใครรู้ตัว ถ้าไม่ได้ระบุจุดเริ่มนับไว้ชัดเจนตั้งแต่แรก และควรระบุด้วยว่านับเฉพาะเวลาทำการ หรือนับต่อเนื่องตลอด 24 ชั่วโมง เพราะสองแบบนี้ให้ผลต่างกันมากสำหรับระบบที่มีปัญหาช่วงวันหยุดยาว

ระดับความรุนแรง ต้องนิยามไว้ก่อนเกิดเหตุ

สัญญาดูแลที่ดีจะแบ่งระดับความรุนแรงของปัญหาไว้ล่วงหน้า เพื่อให้ทั้งสองฝ่ายรู้ตรงกันว่าเหตุการณ์แบบไหนต้องได้รับการตอบสนองเร็วแค่ไหน ปัญหาคือหลายสัญญาเขียนคำว่า "วิกฤต" หรือ "รุนแรง" ไว้ลอย ๆ โดยไม่มีคำนิยาม เมื่อเกิดเหตุจริงจึงกลายเป็นการถกเถียงว่าเคสนี้นับเป็นระดับไหน แทนที่จะได้ลงมือแก้ปัญหาทันที

โครงสร้างที่พบบ่อยในสัญญาดูแลระบบทั่วไปมักแบ่งเป็นสามถึงสี่ระดับ ตัวอย่างเช่น ระดับสูงสุดคือระบบหลักใช้งานไม่ได้ทั้งหมด ระดับกลางคือบางฟังก์ชันใช้งานไม่ได้แต่ระบบโดยรวมยังทำงาน และระดับต่ำคือปัญหาเล็กน้อยที่ไม่กระทบการทำงานประจำวัน จำนวนระดับที่เหมาะสมขึ้นกับความซับซ้อนของระบบแต่ละองค์กร สิ่งสำคัญกว่าจำนวนคือแต่ละระดับต้องมีคำนิยามที่ชัดจนไม่ต้องตีความตอนเกิดเหตุจริง เช่น ระบุว่าฟังก์ชันไหนบ้างที่ถ้าใช้งานไม่ได้ถือเป็นระดับสูงสุด ไม่ใช่ปล่อยให้ทั้งสองฝ่ายตีความกันสดในวันที่ระบบล่ม

การกำหนดเกณฑ์ตัดสินใจไว้ล่วงหน้าแบบนี้สำคัญไม่ต่างจากตอนเกิดเหตุจริง ซึ่งเป็นประเด็นที่เราเคยเล่าไว้ละเอียดกว่านี้ใน เรื่องการตัดสินใจตอนระบบล่ม หลักการเดียวกันนี้ใช้ได้กับการนิยามระดับความรุนแรงในสัญญาดูแลเช่นกัน คือเกณฑ์ต้องเป็นตัวเลขหรือเงื่อนไขที่ตรวจสอบได้ ไม่ใช่ความรู้สึกของฝ่ายใดฝ่ายหนึ่ง และช่องทางการสื่อสารระหว่างเกิดเหตุที่บทความนั้นพูดถึง ก็ควรถูกระบุไว้ในสัญญาดูแลด้วยเช่นกัน ไม่ใช่แค่ตกลงกันปากเปล่าตอนเซ็นสัญญา

ขอบเขตที่สัญญาครอบ และสิ่งที่ไม่ครอบ

สัญญาดูแลส่วนใหญ่ครอบคลุมการแก้บั๊กและปัญหาที่เกิดจากระบบเดิม แต่มักไม่ครอบคลุมการเพิ่มฟีเจอร์ใหม่ การเชื่อมต่อระบบอื่นเพิ่มเติม หรือปัญหาที่เกิดจากการเปลี่ยนแปลงฝั่งผู้ใช้เอง เช่น การอัปเกรดเบราว์เซอร์หรือระบบปฏิบัติการ จุดที่ควรถามให้ชัดคือ งานที่อยู่กึ่งกลางระหว่างสองฝั่งนี้ เช่น การปรับแต่งประสิทธิภาพเมื่อผู้ใช้เพิ่มขึ้น หรือการอัปเดตไลบรารีเพื่อปิดช่องโหว่ด้านความปลอดภัย จะถูกนับเป็นงานดูแลตามสัญญา หรือเป็นงานเพิ่มเติมที่ต้องคิดค่าใช้จ่ายแยก

ถ้าเอกสารสถาปัตยกรรมและสิทธิ์เข้าถึงบัญชีคลาวด์ถูกกำหนดไว้ชัดเจนตั้งแต่ขั้น TOR ตอนสร้างระบบ ตามที่เราเคยเขียนไว้ใน เงื่อนไข TOR ที่ทำให้ระบบดูแลต่อได้ การเขียนขอบเขตของสัญญาดูแลจะง่ายขึ้นมาก เพราะไม่ต้องมานั่งเถียงกันว่าใครเป็นเจ้าของเอกสารหรือบัญชีส่วนไหน องค์กรที่ข้ามขั้นตอนนี้ตอน TOR มักต้องมาแก้ปัญหาซ้ำตอนเจรจาสัญญาดูแล เพราะไม่มีเอกสารอ้างอิงว่าใครมีสิทธิ์อะไรบ้าง

เครดิตหรือบทลงโทษเมื่อผิดสัญญา มีจริงหรือแค่ลอยในหัวข้อ

หลายสัญญาระบุตัวเลข Response Time และ Resolution Time ไว้อย่างสวยงาม แต่ไม่มีข้อความใดเลยที่บอกว่าจะเกิดอะไรขึ้นถ้าผู้ให้บริการทำไม่ได้ตามนั้น ไม่มีเครดิตคืน ไม่มีบทลงโทษ ไม่มีแม้แต่ข้อกำหนดให้ต้องรายงานสาเหตุ ตัวเลขที่ไม่มีผลตามมาเมื่อผิดสัญญา ในทางปฏิบัติก็แทบไม่ต่างจากไม่มีตัวเลขเลย

ตัวอย่างของโครงสร้างเครดิตที่ตรวจสอบได้จริง ดูได้จากผู้ให้บริการ cloud รายใหญ่ที่เผยแพร่เงื่อนไขต่อสาธารณะ เช่น หน้า Google Compute Engine SLA ระบุไว้ว่า หาก Uptime รายเดือนอยู่ระหว่าง 99.00% ถึงต่ำกว่า 99.99% ลูกค้าได้รับเครดิตคืน 10% ของค่าบริการเดือนนั้น หากอยู่ระหว่าง 95.00% ถึงต่ำกว่า 99.00% ได้เครดิตคืน 25% และหากต่ำกว่า 95.00% ได้เครดิตคืนเต็ม 100% (เข้าถึงเมื่อเดือนกันยายน 2569) ตัวเลขชุดนี้เป็นของบริการระดับ cloud infrastructure ระดับโลก ไม่ใช่มาตรฐานตลาดไทยหรือของ Superdev แต่เป็นตัวอย่างที่แสดงให้เห็นว่าเครดิตที่ผูกกับ Uptime แบบเป็นขั้นบันไดมีหน้าตาเป็นอย่างไร และควรใช้เป็นจุดตั้งต้นในการต่อรองสัดส่วนที่เหมาะกับระบบของแต่ละองค์กร ไม่ใช่ตัวเลขที่ต้องยึดตามทุกตัว เพราะบริบทของระบบระดับ global cloud infrastructure กับระบบองค์กรขนาดกลางในไทยต่างกันมาก

สิ่งที่ควรมีอย่างน้อยคือข้อกำหนดให้ผู้ให้บริการต้องแจ้งเหตุผลเป็นลายลักษณ์อักษรเมื่อทำไม่ได้ตามสัญญา ส่วนเรื่องเครดิตค่าบริการหรือบทลงโทษทางการเงิน เป็นเรื่องที่ต่อรองได้ตามความสำคัญของระบบและงบประมาณ ไม่ได้มีสูตรตายตัวว่าต้องมีเสมอไป

ช่องทางแจ้งงานและเวลาทำการ อย่าให้เหลือแค่เบอร์เดียว

อีกจุดที่มองข้ามบ่อยคือช่องทางแจ้งปัญหา สัญญาบางฉบับระบุเพียงอีเมลเดียวหรือเบอร์เดียว โดยไม่มีช่องทางสำรองเมื่อคนรับเรื่องหลักไม่ว่าง ควรถามให้ชัดว่ามีกี่ช่องทาง แต่ละช่องทางมีเวลาทำการเท่าไร และนอกเวลาทำการปกติ มีช่องทางฉุกเฉินหรือไม่ สำหรับระบบที่ต้องทำงานตลอด 24 ชั่วโมง ข้อนี้สำคัญไม่แพ้ตัวเลข Response Time เลย บางองค์กรพบว่าช่องทางฉุกเฉินที่เขียนไว้ในสัญญาเป็นเบอร์ที่ไม่มีใครรับสายนอกเวลาทำการจริง เพราะไม่เคยทดสอบโทรเข้าไปเลยตั้งแต่เซ็นสัญญา

เอกสารแนบท้ายสัญญาที่มักถูกลืม

นอกจากตัวเลขและเงื่อนไข ยังมีเอกสารประกอบสามอย่างที่ควรผูกไว้กับสัญญาดูแลตั้งแต่แรก แต่มักถูกลืมจนต้องมาตามหากันทีหลัง อย่างแรกคือรายการทรัพย์สินของระบบ เช่น โดเมน ใบรับรอง SSL และบริการภายนอกที่ระบบพึ่งพา พร้อมวันหมดอายุของแต่ละรายการ อย่างที่สองคือผังการยกระดับปัญหา (escalation matrix) ที่ระบุว่าถ้าคนรับเรื่องระดับแรกแก้ไม่ได้ภายในเวลาที่กำหนด เรื่องจะถูกส่งต่อไปหาใคร อย่างที่สามคือรายชื่อผู้ติดต่อของทั้งสองฝ่ายที่อัปเดตอยู่เสมอ ไม่ใช่ชื่อคนที่ลาออกไปแล้วสองปีก่อน

เอกสารทั้งสามอย่างนี้มักไม่ถูกเขียนไว้ในตัวสัญญาโดยตรง แต่ถูกผูกไว้เป็นภาคผนวกที่อัปเดตได้ง่ายกว่าการแก้สัญญาหลักทุกครั้ง วิธีที่ใช้ได้ผลคือกำหนดในสัญญาว่าภาคผนวกเหล่านี้ต้องได้รับการทบทวนทุกกี่เดือน และทั้งสองฝ่ายต้องยืนยันความถูกต้องเป็นลายลักษณ์อักษรทุกรอบ แทนที่จะปล่อยให้ข้อมูลเก่าค้างอยู่จนกว่าจะมีปัญหาแล้วค่อยพบว่าข้อมูลผิด องค์กรที่กำลังวางแนวทางดูแลระบบของตัวเองในระยะยาว สามารถดูภาพรวมแนวทางที่เราวางไว้สำหรับองค์กรได้ที่หน้า บริการของเราสำหรับองค์กร เพื่อเป็นข้อมูลประกอบการตัดสินใจ

ข้อเสียที่ต้องพูดให้ชัดคือ การเจรจาเงื่อนไขทุกข้อข้างต้นอย่างละเอียดต้องใช้เวลาและอาจทำให้กระบวนการเซ็นสัญญาช้าลงกว่าเดิม ถ้าระบบของคุณเป็นระบบภายในที่มีผู้ใช้ไม่กี่สิบคนและหยุดใช้งานชั่วคราวได้โดยไม่กระทบธุรกิจ การไล่เจรจาทุกข้อแบบนี้อาจไม่คุ้มกับเวลาที่เสียไป คำแนะนำในกรณีนั้นคือเลือกเจรจาเฉพาะข้อที่สำคัญที่สุดสองสามข้อ แล้วเพิ่มความละเอียดในรอบต่อสัญญาเมื่อระบบมีความสำคัญมากขึ้นตามการใช้งานจริง

ข้อโต้แย้งที่ได้ยินบ่อย: ทำงานกันมานาน ไว้ใจกันอยู่แล้ว

ข้อโต้แย้งที่พบบ่อยคือ องค์กรทำงานกับผู้พัฒนาเจ้านี้มาหลายปี ความสัมพันธ์ดี ทำไมต้องเขียนเงื่อนไขละเอียดขนาดนี้ คำถามนี้สมเหตุสมผล คำตอบไม่ใช่ว่าความไว้ใจไม่สำคัญ ความไว้ใจสำคัญมาก แต่สัญญาไม่ได้เขียนไว้สำหรับวันที่ทุกอย่างราบรื่น

คนที่ดูแลระบบฝั่งผู้ให้บริการอาจเปลี่ยนทีมไปแล้ว ฝั่งองค์กรเองก็อาจมีคนใหม่มารับช่วงต่อที่ไม่รู้ข้อตกลงปากเปล่าเดิม สัญญาที่เขียนชัดเจนคือเอกสารที่ปกป้องทั้งสองฝ่ายในวันที่คนหน้างานเปลี่ยนไปแล้ว ไม่เกี่ยวกับว่าวันนี้ไว้ใจกันมากแค่ไหน

ถ้ายังไม่เคยเจรจาสัญญาดูแลแบบนี้มาก่อน จะเริ่มตรงไหน

สำหรับทีมที่ไม่เคยผ่านการเจรจาสัญญาดูแลระบบแบบละเอียดมาก่อน ไม่จำเป็นต้องเริ่มจากศูนย์ในทุกหัวข้อพร้อมกัน วิธีที่ใช้ได้ผลคือเริ่มจากการขอสัญญาฉบับร่างจากผู้ให้บริการ แล้วไล่เทียบกับหัวข้อในบทความนี้ทีละข้อว่าข้อไหนมีอยู่แล้ว ข้อไหนขาดไป จากนั้นเลือกสองหรือสามข้อที่กระทบความเสี่ยงขององค์กรมากที่สุดมาต่อรองก่อน แทนที่จะพยายามแก้ทุกข้อพร้อมกันในรอบเดียว

ขั้นต่อมาคือให้ทีมไอทีภายในที่ต้องอยู่กับระบบจริงเป็นคนอ่านสัญญาก่อนเซ็น ไม่ใช่ปล่อยให้ฝ่ายจัดซื้อหรือฝ่ายกฎหมายอ่านเพียงลำพัง เพราะคนที่รู้ว่าเงื่อนไขข้อไหนใช้ได้จริงในสถานการณ์แบบไหน คือคนที่ต้องโทรแจ้งปัญหาเข้าไปตอนระบบมีปัญหาจริง ไม่ใช่คนที่เซ็นอนุมัติงบประมาณ

---

สรุป

สัญญาดูแลระบบที่ดีวัดกันที่ตัวเลขทุกตัวตรวจสอบได้และมีความหมายเมื่อเกิดปัญหาจริง มากกว่าความสวยงามของตัวเลขบนกระดาษ ถ้าจะหยิบไปใช้อย่างเดียวจากบทความนี้ ให้แยก Response Time กับ Resolution Time ออกจากกันให้ชัด และถามหาข้อกำหนดว่าจะเกิดอะไรขึ้นเมื่อผู้ให้บริการทำไม่ได้ตามที่ตกลง สองข้อนี้เพียงอย่างเดียวก็ช่วยลดความเสี่ยงได้มากกว่าที่คิด

หากองค์กรของคุณกำลังจะเซ็นหรือต่อสัญญาดูแลระบบ และอยากให้มีคนช่วยอ่านทบทวนเงื่อนไขก่อนตัดสินใจ เรายินดีคุยด้วย ไม่มีกำหนดเวลาบังคับ และไม่ต้องรีบตัดสินใจ

หากต้องการคุยรายละเอียดของโครงการ ติดต่อเราได้ที่ 088-983-9386 หรืออีเมล [email protected] สำนักงานของเราอยู่ที่บางกะปิ กรุงเทพฯ สำหรับองค์กรที่ยังอยู่ระหว่างร่างขอบเขตงาน เรายินดีนัดคุยเพื่อทำความเข้าใจโจทย์ก่อน โดยยังไม่ต้องมีเอกสารครบ และหากคุยแล้วพบว่าโจทย์ยังไม่ถึงเวลาต้องพัฒนาระบบใหม่ เราจะบอกตรง ๆ เพราะการเริ่มโครงการผิดจังหวะ มีต้นทุนสูงกว่าการรออีกหนึ่งไตรมาส