TOR จ้างดูแลระบบเดิม (Legacy): ข้อกำหนดที่ควรมีและจุดเสี่ยง

TOR (Terms of Reference) จ้างดูแลระบบเดิม คือขอบเขตของงานที่หน่วยงานใช้จ้างผู้รับจ้างมาบำรุงรักษาหรือรับช่วงระบบสารสนเทศที่ใช้งานอยู่ โดยระบุว่าระบบมีอะไร ผู้รับจ้างต้องทำอะไรและวัดผลอย่างไร ส่งหลักฐานอะไรให้คณะกรรมการตรวจรับแต่ละงวด และส่งมอบอะไรคืนเมื่อสิ้นสัญญา

บทความนี้เขียนสำหรับเจ้าหน้าที่ IT และคณะกรรมการร่าง TOR ของหน่วยงานรัฐ รวมถึงฝ่ายจัดซื้อขององค์กรที่ต้องจ้างดูแลระบบที่มีอยู่แล้ว เนื้อหาเน้นการแปลงเรื่องทางเทคนิคให้เป็นข้อความใน TOR ที่ตรวจรับได้ ส่วนวิธีจัดซื้อจัดจ้าง ระบบ e-GP และการรับฟังความคิดเห็นร่าง TOR อยู่ในคู่มือจ้างพัฒนาระบบ IT ภาครัฐ และนิยามของระบบเดิมอยู่ใน Legacy System คืออะไร ตัวบทที่อ้างถึงตรวจ ณ วันที่ 2 พฤศจิกายน 2026 (พ.ศ. 2569) จากสำเนาหน้าราชกิจจานุเบกษาที่หน่วยงานรัฐเผยแพร่ ตามลิงก์ในแหล่งอ้างอิงท้ายบทความ สำหรับระเบียบกระทรวงการคลังว่าด้วยการจัดซื้อจัดจ้างและการบริหารพัสดุภาครัฐ พ.ศ. 2560 (ระเบียบฯ) ตรวจทั้งฉบับที่ประกาศปี 2560 และฉบับแก้ไขที่กรมบัญชีกลางเผยแพร่ (ฉบับที่ 2 พ.ศ. 2564 และฉบับที่ 3 พ.ศ. 2569) ซึ่งไม่ได้เปลี่ยนเนื้อหาของข้อที่บทความนี้อ้าง

TOR จ้างดูแลระบบเดิมต่างจาก TOR จ้างพัฒนาระบบใหม่อย่างไร?

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

ในแง่ประเภทของพัสดุ พ.ร.บ. การจัดซื้อจัดจ้างและการบริหารพัสดุภาครัฐ พ.ศ. 2560 มาตรา 4 นิยาม "พัสดุ" ให้รวมงานบริการ และนิยาม "งานบริการ" ว่าหมายถึงงานจ้างบริการ งานจ้างเหมาบริการ งานจ้างทำของ และการรับขนตามประมวลกฎหมายแพ่งและพาณิชย์ โดยไม่รวมการจ้างลูกจ้างของหน่วยงานของรัฐ การรับขนในการเดินทางไปราชการ งานจ้างที่ปรึกษา งานจ้างออกแบบหรือควบคุมงานก่อสร้าง และการจ้างแรงงาน งานจ้างดูแลระบบโดยทั่วไปจึงจัดเป็นงานบริการ แต่การจัดประเภทของงานจริงให้ยืนยันกับหน่วยพัสดุ เราไม่พบนิยามเฉพาะของ "งานจ้างบำรุงรักษาระบบสารสนเทศ" ใน พ.ร.บ. และระเบียบฯ ที่ตรวจ รายละเอียดของงานจึงต้องมาจาก TOR เป็นหลัก

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

ขอบเขตงานต้องระบุอะไร ถ้าหน่วยงานยังไม่รู้จักระบบทั้งหมด?

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

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

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

TOR ใหม่บังคับให้ผู้รับจ้างเดิมส่งมอบงานได้หรือไม่?

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

1. ตรวจสัญญาเดิมตอนนี้ ว่ากำหนดเรื่องการส่งมอบ source code บัญชีผู้ดูแล และการถ่ายทอดความรู้ไว้อย่างไร และขอรับสิ่งเหล่านั้นก่อนสัญญาเดิมสิ้นสุด รายการที่ควรขอรับอยู่ใน เปลี่ยนผู้รับจ้างดูแลระบบ: ต้องรับมอบอะไรบ้าง
2. เขียนงานรับช่วงไว้ใน TOR ใหม่ ให้ผู้รับจ้างรายใหม่รับสิ่งที่หน่วยงานมี ตรวจว่า build และ deploy ได้จริง เปลี่ยนรหัสผ่านของบัญชีที่ใช้ร่วมกัน และรายงานสิ่งที่ยังขาด
3. ระบุหน้าที่ของหน่วยงาน เช่น ให้สิทธิ์เข้าถึงเครื่องและระบบภายในกี่วันหลังลงนาม และใครเป็นผู้ประสานกับผู้รับจ้างเดิม เพราะงานรับช่วงจะช้าถ้ารอสิทธิ์เข้าถึง

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

Source code บัญชีผู้ดูแล และเอกสาร: เขียนอย่างไรไม่ให้ถูกผูกขาด?

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

• Repository อยู่ในที่ที่หน่วยงานควบคุม ผู้รับจ้างทำงานใน repository นั้นพร้อมประวัติการแก้ไข ไม่ใช่ส่งไฟล์ zip ตอนปลายงวด
• สิทธิในงานที่แก้ไขหรือเพิ่มระหว่างสัญญา ระบุให้ชัดว่าเป็นของใคร และใช้ต่อหรือให้ผู้อื่นแก้ไขต่อได้หรือไม่ ถ้าระบบมีส่วนประกอบที่ผู้รับจ้างเดิมหรือผู้ผลิตถือสิทธิ์ ให้ระบุแยกไว้
• สคริปต์ build, deploy และค่าตั้งระบบ รวมถึง Infrastructure as Code ถ้ามี เป็นสิ่งส่งมอบเช่นเดียวกับ source code
• ทะเบียนบัญชีผู้ดูแล รายการบัญชี ใครถือ และเปลี่ยนรหัสผ่านล่าสุดเมื่อไร โดยรหัสผ่านจริงเก็บในที่เก็บของหน่วยงาน ไม่อยู่ในรายงาน บัญชีระดับผู้ดูแลระบบเป็นของหน่วยงาน ผู้รับจ้างใช้บัญชีรายบุคคลที่ปิดได้เมื่อคนนั้นออกจากโครงการ
• เอกสารและ runbook ที่อัปเดตทุกงวด ขั้นตอนเปิด ปิด และกู้คืนระบบที่คนอื่นทำตามได้ วิธีเขียนให้พอใช้อยู่ใน บทความการรับช่วงระบบที่ไม่มีเอกสาร
• รายการส่วนประกอบภายนอกและไลเซนส์ library และซอฟต์แวร์ที่ระบบใช้ พร้อมเวอร์ชันและเงื่อนไขไลเซนส์

SLA ใน TOR ต้องเขียนอย่างไรให้วัดได้?

ไม่มีตัวเลข SLA ที่ถูกสำหรับทุกระบบ ตัวเลขควรมาจากผลกระทบเมื่อระบบหยุด ช่วงเวลาที่ต้องให้บริการ และงบประมาณ เพราะเป้าหมายที่เข้มขึ้นหมายถึงต้องมีคนเข้าเวร (on-call) มากขึ้นและราคาสูงขึ้น ตัวเลขใน SLA เป็นเป้าหมายที่ผู้รับจ้างตกลงจะทำ ไม่ได้รับประกันว่าระบบจะไม่ล่ม สิ่งที่ทำให้ SLA ตรวจได้จริงคือทุกตัวชี้วัดต้องมีห้าส่วน: นิยาม จุดเริ่มและหยุดนับเวลา แหล่งข้อมูลที่ใช้วัด รอบรายงาน และข้อยกเว้น

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

ทำไมต้องแยกงานบำรุงรักษาออกจากงานเปลี่ยนแปลงตั้งแต่ใน TOR?

มาตรา 97 กำหนดว่าสัญญาหรือข้อตกลงเป็นหนังสือที่ลงนามแล้วแก้ไขไม่ได้ เว้นแต่เข้ากรณีที่ระบุไว้ใน (1) ถึง (4) ได้แก่ การแก้ไขตามมาตรา 93 วรรคห้า กรณีที่จำเป็นต้องแก้ไขโดยการแก้ไขนั้นไม่ทำให้หน่วยงานของรัฐเสียประโยชน์ การแก้ไขเพื่อประโยชน์แก่หน่วยงานของรัฐหรือประโยชน์สาธารณะ และกรณีอื่นตามที่กำหนดในกฎกระทรวง โดยอยู่ในดุลพินิจของผู้มีอำนาจที่จะอนุมัติ ถ้าการแก้ไขทำให้ต้องเพิ่มหรือลดวงเงินหรือระยะเวลา ให้ตกลงไปพร้อมกัน ส่วน ระเบียบกระทรวงการคลังฯ พ.ศ. 2560 ข้อ 161 กำหนดว่าการลงนามและการแก้ไขสัญญาเป็นอำนาจของหัวหน้าหน่วยงานของรัฐ

เมื่อแก้สัญญากลางทางทำได้จำกัด TOR จึงควรตอบสามคำถามไว้ล่วงหน้า:

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

คำว่า "ปรับปรุงระบบตามความต้องการของผู้ใช้" โดยไม่มีขอบเขต เป็นที่มาของข้อโต้แย้งที่พบบ่อยระหว่างหน่วยงานกับผู้รับจ้าง ขั้นตอน change request แบบละเอียดอยู่ในบทความสัญญา MA และ SLA

ระบบที่หมด support แล้ว TOR ควรเขียนเรื่องแพตช์อย่างไร?

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

1. ระบุสถานะ support ของแต่ละส่วนประกอบในภาคผนวกรายการระบบ และให้ผู้รับจ้างยืนยันในงวดสำรวจ
2. ส่วนที่ยังมีแพตช์ ให้ติดตั้งภายในเวลาที่กำหนดตามระดับความรุนแรง พร้อมแผนทดสอบและแผนถอยกลับ
3. ส่วนที่ไม่มีแพตช์แล้ว ให้ใช้มาตรการชดเชย เช่น แยกเครือข่าย จำกัดผู้เข้าถึง และเฝ้าระวังเพิ่ม แล้วรายงานสถานะทุกงวด
4. ให้มีรายงานข้อเสนอการอัปเกรดหรือย้ายระบบเป็นสิ่งส่งมอบ แยกจากงบของงานอัปเกรดจริง

มาตรการชดเชยแต่ละแบบ การซื้อ extended support และวิธีตรวจวันหมด support ของแต่ละผลิตภัณฑ์อยู่ใน ระบบเก่าหมด support แต่ยังต้องใช้ต่อ

Backup, log และข้อมูลส่วนบุคคล ต้องเขียนอะไรใน TOR?

Backup และการทดสอบกู้คืน

ระบุขอบเขตของ backup (ฐานข้อมูล ไฟล์ และค่าตั้งระบบ) ความถี่ [__] ระยะเก็บ [__] และที่เก็บที่แยกจากเครื่องหลัก สิ่งที่สำคัญกว่าคือกำหนดให้ทดสอบกู้คืนทุกงวด และส่งบันทึกที่บอกวันที่ทดสอบ สิ่งที่กู้คืน เวลาที่ใช้ และผลการตรวจข้อมูล backup ที่ไม่เคยกู้คืนยังไม่ได้พิสูจน์ว่าใช้ได้ ถ้าหน่วยงานมีแผนกู้คืนจากเหตุร้ายแรง ให้ระบุรอบการซ้อมและผู้ร่วมซ้อมด้วย

การเก็บ log

พ.ร.บ. ว่าด้วยการกระทำความผิดเกี่ยวกับคอมพิวเตอร์ มาตรา 26 ซึ่งแก้ไขโดยฉบับที่ 2 พ.ศ. 2560 กำหนดให้ "ผู้ให้บริการ" เก็บรักษาข้อมูลจราจรทางคอมพิวเตอร์ไว้ไม่น้อยกว่า 90 วัน และพนักงานเจ้าหน้าที่อาจสั่งให้เก็บเกิน 90 วันแต่ไม่เกินสองปีเป็นกรณีพิเศษ หน้าที่นี้ใช้กับผู้ให้บริการตามที่กฎหมายนิยาม ไม่ได้หมายความว่าทุกระบบต้องเก็บ log 90 วัน ทั้งนี้ ภาคผนวก ก ของประกาศกระทรวงดิจิทัลเพื่อเศรษฐกิจและสังคม เรื่องหลักเกณฑ์การเก็บรักษาข้อมูลจราจรทางคอมพิวเตอร์ของผู้ให้บริการ พ.ศ. 2564 ยกตัวอย่าง "ผู้ให้บริการเข้าถึงระบบเครือข่ายคอมพิวเตอร์สำหรับองค์กร เช่น หน่วยงานราชการ บริษัท หรือสถาบันการศึกษา" ไว้ด้วย หน่วยงานที่เปิดให้บุคลากรเข้าถึงเครือข่ายหรืออินเทอร์เน็ตผ่านระบบของหน่วยงานจึงควรตรวจกับฝ่ายกฎหมายว่าตนมีหน้าที่นี้หรือไม่ สิ่งที่ TOR ควรเขียนคือให้ผู้รับจ้างคงการเก็บ log ตามหน้าที่ที่หน่วยงานมีอยู่ ไม่ลดระยะเก็บหรือปิด log เพื่อประหยัดพื้นที่โดยไม่ได้รับอนุมัติ และรายงานสถานะการเก็บ log ทุกงวด

ข้อมูลส่วนบุคคล

ผู้รับจ้างดูแลระบบที่เข้าถึงฐานข้อมูลประชาชนหรือบุคลากรมักอยู่ในฐานะผู้ประมวลผลข้อมูลส่วนบุคคล พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 มาตรา 40 กำหนดให้ผู้ประมวลผลดำเนินการตามคำสั่งของผู้ควบคุมเท่านั้น จัดให้มีมาตรการรักษาความมั่นคงปลอดภัยที่เหมาะสมและแจ้งผู้ควบคุมเมื่อเกิดเหตุละเมิด และจัดทำบันทึกรายการกิจกรรมการประมวลผล โดยผู้ควบคุมต้องจัดให้มีข้อตกลงระหว่างกันเพื่อควบคุมการดำเนินงานของผู้ประมวลผล TOR จึงควรกำหนดให้มีข้อตกลงการประมวลผลข้อมูล (Data Processing Agreement หรือ DPA) แนบสัญญา หัวข้อที่ควรมีใน DPA อยู่ในคู่มือจ้างพัฒนาระบบ IT ภาครัฐ

การตรวจรับงานดูแลระบบรายงวดต้องใช้หลักฐานอะไร?

มาตรา 100 ให้ผู้มีอำนาจแต่งตั้งคณะกรรมการตรวจรับพัสดุเพื่อรับผิดชอบการบริหารสัญญาและการตรวจรับพัสดุ ระเบียบฯ พ.ศ. 2560 ข้อ 175 กำหนดหน้าที่ของคณะกรรมการตรวจรับไว้หลายข้อ ที่เกี่ยวกับการร่าง TOR โดยตรงมีดังนี้

• ตรวจรับให้ถูกต้องครบถ้วน "ตามหลักฐานที่ตกลงกันไว้" และถ้ามีการทดลองหรือตรวจสอบทางเทคนิค อาจเชิญผู้ชำนาญการหรือผู้ทรงคุณวุฒิมาให้คำปรึกษาได้ (ข้อ 175 (2))
• ถ้าส่งถูกต้องแต่ไม่ครบจำนวน หรือครบจำนวนแต่ไม่ถูกต้องทั้งหมด ให้ตรวจรับไว้เฉพาะส่วนที่ถูกต้อง เว้นแต่สัญญากำหนดเป็นอย่างอื่น และรีบรายงานหัวหน้าหน่วยงานของรัฐผ่านหัวหน้าเจ้าหน้าที่ เพื่อแจ้งผู้รับจ้างภายใน 3 วันทำการนับถัดจากวันตรวจพบ (ข้อ 175 (5))
• มติของคณะกรรมการตรวจรับพัสดุต้องเป็นเอกฉันท์ กรรมการที่ไม่เห็นด้วยให้บันทึกความเห็นแย้ง (ข้อ 27)

เมื่อกรรมการทุกคนต้องเห็นตรงกัน เกณฑ์อย่าง "ผู้รับจ้างดูแลให้ระบบใช้งานได้ตามปกติ" จึงตัดสินยาก TOR ควรระบุสิ่งส่งมอบรายงวดที่จับต้องได้ เช่น

ถ้างานงวดใดต้องตรวจทางเทคนิค เช่น ทดสอบกู้คืนต่อหน้ากรรมการ ให้เขียนวิธีตรวจไว้ใน TOR เพื่อให้กรรมการและผู้รับจ้างเตรียมได้ตรงกัน หลักเกณฑ์ในข้อ 175 ที่ยกมาไม่ได้ถูกแก้โดยฉบับที่ 2 และฉบับที่ 3 ที่เราตรวจ แต่ก่อนใช้งานจริงให้ยืนยันฉบับล่าสุดกับหน่วยพัสดุหรือกรมบัญชีกลาง

ข้อสิ้นสุดสัญญาและการส่งต่อให้ผู้รับจ้างรายถัดไปควรมีอะไร?

มาตรา 103 ให้ผู้มีอำนาจบอกเลิกสัญญาได้เมื่อมีเหตุตามที่กำหนด หนึ่งในนั้นคือ "เหตุอื่นตามที่กำหนดไว้ในพระราชบัญญัตินี้หรือในสัญญาหรือข้อตกลง" (มาตรา 103 (3)) ดังนั้นเหตุบอกเลิกและหน้าที่ของผู้รับจ้างเมื่อสัญญาจบ ไม่ว่าจะครบกำหนดหรือเลิกก่อนกำหนด ควรเขียนไว้ในสัญญาและ TOR ตั้งแต่ต้น ข้อที่ควรมี:

• ก่อนสิ้นสุดสัญญา [__ วัน] ส่งชุดส่งมอบ: source code ฉบับล่าสุด ทะเบียนบัญชี เอกสารและ runbook รายการเรื่องที่ยังเปิดอยู่ และปัญหาที่รู้แล้วแต่ยังไม่แก้
• ช่วยถ่ายทอดความรู้ให้ผู้รับจ้างรายถัดไปหรือทีมของหน่วยงาน [__ วันหรือชั่วโมง] และระบุว่ารวมอยู่ในราคาหรือไม่
• ไม่ลบข้อมูล ปิดบัญชี หรือเปลี่ยนรหัสผ่านโดยไม่แจ้ง ระหว่างช่วงส่งต่อ
• คืนหรือลบข้อมูลส่วนบุคคลตามที่กำหนดใน DPA และส่งหลักฐาน
• ให้ข้อนี้มีผลทั้งกรณีครบกำหนดสัญญาและกรณีเลิกสัญญาก่อนกำหนด

ข้อนี้ทำให้ TOR ฉบับถัดไปของหน่วยงานเขียนง่ายขึ้น เพราะหน่วยงานจะมีรายการระบบและเอกสารที่เป็นปัจจุบันอยู่ในมือ

จุดเสี่ยงที่พบบ่อยใน TOR ระบบเดิมมีอะไรบ้าง?

เช็กลิสต์หัวข้อ TOR จ้างดูแลระบบเดิม (คัดลอกไปใช้ได้)

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

1. วัตถุประสงค์ ระยะเวลาสัญญา และการแบ่งงวด
2. ภาคผนวกรายการระบบ: แอปพลิเคชัน ฐานข้อมูล เซิร์ฟเวอร์ เวอร์ชัน การเชื่อมต่อ สภาพแวดล้อม ไลเซนส์ และสถานะ support
3. งวดแรก: สำรวจและรับช่วงระบบ ยืนยันรายการระบบ รายงานส่วนที่ขาด และรายการความเสี่ยง
4. หน้าที่ของหน่วยงาน: สิทธิ์เข้าถึง ผู้ประสานงาน และการประสานกับผู้รับจ้างเดิม
5. ขอบเขตงานบำรุงรักษา: สิ่งที่รวม และสิ่งที่ไม่รวม
6. งานเปลี่ยนแปลง: นิยาม ขั้นตอนขอ ประเมิน อนุมัติ และแหล่งงบ
7. ระดับความรุนแรงและตัวชี้วัด SLA: นิยาม จุดเริ่มและหยุดนับ แหล่งข้อมูลที่ใช้วัด รอบรายงาน และข้อยกเว้น
8. ช่องทางรับแจ้งปัญหาและเวลาให้บริการ
9. แพตช์ ส่วนประกอบที่หมด support และมาตรการชดเชย
10. Backup ระยะเก็บ การทดสอบกู้คืนทุกงวด และแผนกู้คืนจากเหตุร้ายแรง
11. การเก็บ log ตามหน้าที่ของหน่วยงาน
12. ความมั่นคงปลอดภัยและทะเบียนบัญชีผู้ดูแล
13. ข้อมูลส่วนบุคคลและข้อตกลงการประมวลผลข้อมูล (DPA)
14. Source code, repository, สคริปต์ build และ deploy, เอกสาร, runbook และสิทธิในงานที่แก้ไข
15. สิ่งส่งมอบและหลักฐานตรวจรับรายงวด
16. ผู้รับผิดชอบหลักและผู้สำรองของผู้รับจ้าง
17. การส่งมอบเมื่อสิ้นสุดหรือเลิกสัญญา และการถ่ายทอดความรู้ให้ผู้รับจ้างรายถัดไป
18. เหตุบอกเลิกสัญญาที่กำหนดไว้ในสัญญา (ร่างร่วมกับหน่วยพัสดุ)

ประเมินระบบเดิมก่อนร่าง TOR

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

บริการ ดูแลและปรับปรุงระบบเดิม ของ UNIXDEV เริ่มจากประเมิน source code, dependencies, วิธี deploy, ข้อมูล และผู้ถือสิทธิ์ในระบบ แล้วส่งมอบภาพรวมระบบและสิ่งที่ยังขาด รายการความเสี่ยงและลำดับแก้ไข แผนรับช่วงที่มี backup, restore และ rollback และขอบเขต MA ที่แยกงานแก้ไข งานดูแล และฟีเจอร์ใหม่ออกจากกัน

เราไม่รับประกัน zero downtime ผลกระทบและช่วงหยุดระบบที่ต้องใช้ประเมินได้หลังตรวจสถาปัตยกรรมและ dependencies ของระบบจริง

UNIXDEV ลงทะเบียนเป็นผู้ค้าในระบบ e-GP แล้ว และได้รับการรับรอง ISO 9001:2015, ISO/IEC 29110-4-1:2018 และ ISO/IEC 27001:2022 ถ้าหน่วยงานต้องการจ้างผู้ประเมินก่อน และให้ผู้ประเมินรายเดียวกันยื่นข้อเสนอในโครงการเดียวกันด้วย ควรสอบถามหน่วยพัสดุก่อนว่ามีข้อจำกัดหรือไม่

ส่งข้อมูลระบบเท่าที่มี เช่น ชื่อระบบ เทคโนโลยี จำนวนเครื่อง และสิ่งที่ได้รับมอบจากผู้รับจ้างเดิม ผ่านแบบฟอร์มส่งโจทย์ได้

แหล่งอ้างอิงและอ่านต่อ

• พ.ร.บ. การจัดซื้อจัดจ้างและการบริหารพัสดุภาครัฐ พ.ศ. 2560: ราชกิจจานุเบกษา เล่ม 134 ตอนที่ 24 ก วันที่ 24 กุมภาพันธ์ 2560 (มาตรา 4, 8, 9, 97, 100, 103) · สำเนาที่กรมบัญชีกลางเผยแพร่
• ระเบียบกระทรวงการคลังว่าด้วยการจัดซื้อจัดจ้างและการบริหารพัสดุภาครัฐ พ.ศ. 2560: ราชกิจจานุเบกษา เล่ม 134 ตอนพิเศษ 210 ง วันที่ 23 สิงหาคม 2560 (ข้อ 27, 161, 175) · สำเนาที่กรมบัญชีกลางเผยแพร่ ตรวจร่วมกับฉบับแก้ไขที่ 2 พ.ศ. 2564 และฉบับที่ 3 พ.ศ. 2569 ซึ่งไม่ได้เปลี่ยนเนื้อหาของข้อที่อ้าง ก่อนใช้งานจริงให้ยืนยันฉบับล่าสุดกับหน่วยพัสดุหรือกรมบัญชีกลาง
• พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562: ราชกิจจานุเบกษา เล่ม 136 ตอนที่ 69 ก วันที่ 27 พฤษภาคม 2562 (มาตรา 40) · สำเนาที่สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคลเผยแพร่
• พ.ร.บ. ว่าด้วยการกระทำความผิดเกี่ยวกับคอมพิวเตอร์ (ฉบับที่ 2) พ.ศ. 2560: ราชกิจจานุเบกษา เล่ม 134 ตอนที่ 10 ก วันที่ 24 มกราคม 2560 (มาตรา 26 ที่แก้ไขโดยมาตรา 17) · สำเนา
• ประกาศกระทรวงดิจิทัลเพื่อเศรษฐกิจและสังคม เรื่องหลักเกณฑ์การเก็บรักษาข้อมูลจราจรทางคอมพิวเตอร์ของผู้ให้บริการ พ.ศ. 2564: ราชกิจจานุเบกษา เล่ม 138 ตอนพิเศษ 188 ง วันที่ 13 สิงหาคม 2564 (ภาคผนวก ก) · สำเนา
• บทความที่เกี่ยวข้อง: จ้างพัฒนาระบบ IT ภาครัฐ วิธีจัดซื้อ e-GP TOR และงบ MA
• บทความที่เกี่ยวข้อง: สัญญา MA และ SLA ดูแลระบบ
• บทความที่เกี่ยวข้อง: เปลี่ยนผู้รับจ้างดูแลระบบ ต้องรับมอบอะไรบ้าง
• บทความที่เกี่ยวข้อง: รับดูแลระบบเก่าที่ไม่มีเอกสาร
• บทความที่เกี่ยวข้อง: ระบบเก่าหมด support แต่ยังต้องใช้ต่อ
• บทความที่เกี่ยวข้อง: Legacy System คืออะไร
• บทความที่เกี่ยวข้อง: ทำไมโครงการ IT ภาครัฐจึงล้มเหลว
• บทความที่เกี่ยวข้อง: Managed Services หรือทีม IT ภายใน
• บทความทั้งหมดในหมวดระบบ IT สำหรับหน่วยงานภาครัฐ
• บทความทั้งหมดในหมวดดูแลและปรับปรุงระบบเดิม

บทความโดย UNIXDEV Team · 2 พฤศจิกายน 2026 · สรุปเพื่อประกอบการวางแผน ไม่ใช่คำแนะนำทางกฎหมาย