“ทุกครั้งที่ต่อสัญญาบำรุงรักษา ใบเสนอราคาก็ขยับขึ้น แต่พอถึงเวลาที่ระบบจะหยุด มันก็ยังหยุดอยู่ดี” นี่คือประโยคที่ได้ยินบ่อยมากจากโรงงานญี่ปุ่นในประเทศไทย สาเหตุที่ทำให้ค่าบำรุงรักษาระบบงานคาดการณ์ไม่ได้ ไม่ได้อยู่ที่ตัวเลขสูงหรือต่ำ แต่อยู่ที่สัญญารับปากไว้เพียงว่า “ถ้าพังจะซ่อมให้” สิ่งที่โรงงานเดือดร้อนจริง ๆ กลับเป็นอีกฝั่งหนึ่ง คือ “ถ้าสภาพแวดล้อมเปลี่ยน จะแก้ให้ไหม” บทความนี้จะแยกงานบำรุงรักษาออกเป็น 4 ประเภท แยกค่าใช้จ่ายออกเป็น 5 ชั้น แล้วนำสัญญาปีละ 450,000 THB มาเทียบกับสัญญาปีละ 810,000 THB ในกรอบเวลา 5 ปี
ค่าบำรุงรักษาระบบงานคาดการณ์ไม่ได้ เพราะสัญญารับปากไว้แค่ตอนที่ระบบพัง
เวลาที่ได้รับการปรึกษาเรื่องค่าบำรุงรักษา สิ่งแรกที่เราขอดูไม่ใช่ใบเสนอราคา แต่เป็นเอกสารแนบท้ายสัญญา และสิ่งที่เขียนอยู่ในนั้นมักมีเพียงสามเรื่องเท่านั้น หนึ่งคือช่องทางและเวลาทำการของศูนย์รับแจ้ง สองคือการตอบสนองขั้นต้นเมื่อเกิดเหตุขัดข้อง และสามคือการเฝ้าระวังการทำงานตามรอบพร้อมการตรวจสอบการสำรองข้อมูล พูดอีกอย่างคือ ทั้งหมดเป็นคำสัญญาว่าจะ “พาระบบจากสภาพที่พังกลับสู่สภาพเดิม”
แต่ถ้าลองไล่เรียงเหตุผลที่ระบบของโรงงานถูกลงมือแก้ไขจริง ๆ ตลอดหนึ่งปี ภาพจะเปลี่ยนไปทันที ลูกค้ารายใหญ่แจ้งมาว่าขอให้เปลี่ยนรูปแบบใบส่งของเป็นอีกแบบหนึ่ง กลุ่มสินค้าใหม่เริ่มผลิตแล้วจำนวนหลักของรหัสสินค้าในมาสเตอร์ไม่พอ โรงงานแห่งที่ 2 เปิดดำเนินการจนต้องมีแนวคิดเรื่องรหัสสาขาขึ้นมาใหม่ ระบบปฏิบัติการของเซิร์ฟเวอร์หมดระยะการสนับสนุน ฐานข้อมูลอัปเวอร์ชันจนต้องตรวจสอบความเข้ากันได้ของฝั่งแอปพลิเคชัน หรือกฎการคำนวณต้นทุนเปลี่ยนเพราะนโยบายของสำนักงานใหญ่
ไม่มีข้อไหนเลยที่ระบบ “พัง” ระบบยังเดินอยู่วันนี้ ยังเปิดใช้งานได้ตามปกติ แต่ถ้าปล่อยไว้แบบนั้น งานจะเดินต่อไม่ได้ นี่คือขอบเขตของ “เปลี่ยนแล้วต้องแก้” และสัญญาบำรุงรักษารายปีจำนวนมากไม่ได้ครอบคลุมขอบเขตนี้ ที่จริงแล้วสัญญาเขียนไว้ชัดเจนว่าไม่ครอบคลุม เพียงแต่ถูกบีบอัดลงเหลือบรรทัดเดียวว่า “คิดค่าใช้จ่ายแยกตามใบเสนอราคา” ณ วันที่เซ็นสัญญาจึงมองไม่เห็นตัวเลข
โครงสร้างที่ทำให้ค่าบำรุงรักษาคาดการณ์ไม่ได้อยู่ตรงนี้ เพราะช่องของค่าบริการรายปีไม่ได้บรรจุ “เปลี่ยนแล้วต้องแก้” เอาไว้ ตราบใดที่เปรียบเทียบกันด้วยยอดรายปีอย่างเดียว สัญญาที่ถูกกว่าย่อมดูถูกกว่าเสมอ แต่เงินที่จ่ายจริงคือยอดรายปี บวกยอดสะสมของ “ใบเสนอราคาแยกต่างหาก” บวกมูลค่าของเวลาที่ระบบหยุดระหว่างรอการแก้ไข สองก้อนหลังนี้ไม่ปรากฏในตารางค่าบริการรายปี แต่จะโผล่ออกมาในยอดรวม 5 ปี และในจำนวนชั่วโมงที่ระบบหยุดต่อปี
ด้วยเหตุนี้ บทความนี้จึงไม่เปรียบเทียบกันที่ยอดรายปี แต่เปรียบเทียบที่ยอดรวม 5 ปีและเวลาที่ระบบหยุด จากนั้นจะไล่ดูว่าจุดพลิกที่ทำให้สัญญาซึ่งถูกกว่า 44% ต่อปี กลายเป็นแพงกว่า 9.2% เมื่อคิดยอดรวม 5 ปีรวมความสูญเสียจากการหยุดระบบ เกิดขึ้นตรงชั้นไหน สาเหตุของการพลิกอันดับไม่ใช่ “การขึ้นราคา” และไม่ใช่ “ความหย่อนยานของผู้ขาย” แต่คือการตัดชั้นค่าใช้จ่ายออกไปหนึ่งถึงสองชั้นตั้งแต่ตอนออกแบบสัญญา
งบ IT ของบริษัทญี่ปุ่น ยังหมดไปกับการประคองระบบเดิมถึงสามในสี่
เพื่อไม่ให้เป็นแค่ความรู้สึก ขอวางสถิติไว้ตรงนี้ รายงานการสำรวจแนวโน้ม IT ขององค์กร ฉบับปี 2026 โดยสมาคมผู้ใช้ระบบสารสนเทศแห่งญี่ปุ่น (JUAS) เก็บข้อมูลระหว่างวันที่ 5 กันยายน ถึง 24 ตุลาคม 2025 โดยส่งแบบสอบถามไปยังบริษัทจดทะเบียนในตลาดหลักทรัพย์โตเกียวและบริษัทที่เทียบเท่า รวม 4,500 บริษัท และได้รับคำตอบกลับมา 957 บริษัท คิดเป็นอัตราตอบกลับที่ใช้ได้ 21.3% ถือว่าเป็นฐานกลุ่มตัวอย่างที่มากพอจะสะท้อนสภาพจริงของบริษัทจดทะเบียน
ในการสำรวจนี้ สัดส่วนการจัดสรรงบ IT ของปีงบประมาณ 2025 ออกมาเป็นงานประคองธุรกิจเดิม หรือ run the business ซึ่งหมายถึงการดูแลและเดินระบบที่มีอยู่ อยู่ที่ 75.9 เทียบกับงานสร้างมูลค่าใหม่ หรือ value up อยู่ที่ 24.1 เท่ากับว่างบประมาณกว่าสามในสี่ถูกใช้ไปกับการทำให้สิ่งที่มีอยู่แล้วเดินต่อไปได้
พอเจาะเฉพาะภาคการผลิต ตัวเลขยิ่งหนักขึ้น อุตสาหกรรมการผลิตประเภทแปรรูปและประกอบมีสัดส่วนงานสร้างมูลค่าใหม่ในปีงบประมาณ 2025 อยู่ที่ 23.3% กลับด้านก็คืองานประคองธุรกิจเดิมอยู่ที่ 76.7% โรงงานญี่ปุ่นในประเทศไทยส่วนใหญ่จัดอยู่ในหมวดอุตสาหกรรมนี้ และถ้ามองตามขนาดยอดขาย บริษัทที่มียอดขายต่ำกว่าหนึ่งหมื่นล้านเยนมีสัดส่วนปัจจุบันเป็นงานประคองธุรกิจเดิม 78.2 เทียบกับงานสร้างมูลค่าใหม่ 21.8 เห็นได้ชัดว่ายิ่งขนาดเล็ก ยิ่งถูกงานประคองระบบเดิมกินงบไปมาก
สิ่งที่น่าสนใจคือช่องว่างเมื่อเทียบกับเป้าหมาย ภาพรวมตั้งเป้าสัดส่วนงานสร้างมูลค่าใหม่ในอีกสามปีข้างหน้าไว้ที่ 32.7% ส่วนบริษัทที่มียอดขายต่ำกว่าหนึ่งหมื่นล้านเยนก็ยังตั้งเป้าไว้ที่ 30.7% แปลว่าฝั่งองค์กรรู้ตัวดีว่าถูกงานประคองระบบเดิมกินไปมากเกินไป และอยากดันสัดส่วนการลงทุนใหม่ขึ้นไปให้ถึงราวสามส่วนสิบ แต่ในเมื่อสภาพปัจจุบันยังค้างอยู่แถวสองส่วนสิบ ก็หมายความว่าฝั่งการประคองระบบเดิมไม่ได้ลดลงตามแผน
ในการสำรวจเดียวกัน เหตุผลอันดับหนึ่งที่ทำให้งบ IT เพิ่มขึ้นคือ “การปรับปรุง อัปเดต และเสริมกำลังระบบและโครงสร้างพื้นฐานที่มีอยู่เดิม” โดยในบรรดาบริษัทที่งบ IT เพิ่มขึ้น มีผู้ระบุเหตุผลนี้ 66.3% ในแผนปีงบประมาณ 2025 และ 60.3% ในการคาดการณ์ปีงบประมาณ 2026 เหตุผลอันดับหนึ่งของการเพิ่มงบ จึงไม่ใช่การเริ่มสิ่งใหม่ แต่คือการสร้างสิ่งที่มีอยู่แล้วขึ้นมาใหม่
พอเอาสองเรื่องนี้มาซ้อนกัน จะเห็นนัยเชิงปฏิบัติทันที งบประมาณ 75.9% หายไปกับการประคองระบบเดิม และในบรรดาบริษัทที่วางแผนเพิ่มงบ กว่าหกในสิบยกเหตุผลเรื่องการปรับปรุงและอัปเดตโครงสร้างพื้นฐานเดิม ถ้าเป็นเช่นนั้น การออกแบบสัญญาบำรุงรักษาก็ควรมีน้ำหนักเท่ากับการตัดสินใจลงทุน แต่ในหน้างานจริง สัญญาบำรุงรักษามักถูกดันผ่านในฐานะ “เรื่องขออนุมัติต่อสัญญา” โดยดูเพียงว่ายอดเท่าเดิมกับปีที่แล้วหรือไม่ ไม่มีกลไกเชิงระบบที่บังคับให้ทบทวนโครงสร้างชั้นค่าใช้จ่ายข้างใน ถ้ากำลังจะถึงรอบต่อสัญญา ขอให้ดูที่การเพิ่มลดของชั้น ไม่ใช่การเพิ่มลดของตัวเลข
สามเหตุผลที่ทำให้งานบำรุงรักษาในไทยหนักกว่าที่คิด
บริษัทที่มีโครงสร้างเหมือนกับในญี่ปุ่นทุกประการ พอมาตั้งฐานที่ไทย น้ำหนักของงานบำรุงรักษาก็เปลี่ยนไป เหตุผลมีอยู่สามข้อ และทุกข้อยืนยันได้ด้วยตัวเลข
ข้อแรกคือฐานของการใช้เทคโนโลยีดิจิทัลยังบางอยู่ การสำรวจสภาพจริงของบริษัทญี่ปุ่นที่ลงทุนในต่างประเทศ ประจำปีงบประมาณ 2025 ฉบับเอเชียและโอเชียเนีย ขององค์การส่งเสริมการค้าต่างประเทศของญี่ปุ่น (เจโทร) เก็บข้อมูลระหว่างเดือนสิงหาคมถึงกันยายน 2025 ครอบคลุม 20 ประเทศและเขตเศรษฐกิจ มีคำตอบที่ใช้ได้ 5,109 บริษัท ในจำนวนนี้ สัดส่วนบริษัทที่ตอบว่ามีการนำเข้ามาใช้ ใช้งานจริง หรือลงทุนในเทคโนโลยีดิจิทัล อยู่ที่ 53.5% สำหรับภาพรวมทั้งหมด และ 52.1% สำหรับอาเซียน ขณะที่ประเทศไทยอยู่ที่ 46.1% จากบริษัทที่ตอบแบบสอบถาม 583 บริษัท ต่ำกว่าค่าเฉลี่ยอาเซียนอยู่ 6 จุด หลายคนมักมีภาพว่าไทยก้าวหน้ากว่าประเทศรอบข้าง แต่อย่างน้อยในตัวชี้วัดเรื่องการใช้ดิจิทัลของบริษัทญี่ปุ่น สภาพจริงคือยังต่ำกว่า
ข้อที่สองคือเรื่องคน ในหัวข้ออุปสรรคของการสำรวจเดียวกัน “การขาดแคลนบุคลากรด้านดิจิทัล” มาเป็นอันดับหนึ่งที่ 60.7% อันดับสองคือ “ต้นทุนการนำเข้ามาใช้และการดำเนินงานสูง” ที่ 56.0% จากคำตอบที่ใช้ได้ 4,235 บริษัท ถัดมาคือ “ไม่เห็นยอดขายที่คุ้มกับการลงทุน” 26.6% และ “ผสานเข้ากับโครงสร้างพื้นฐานเดิมได้ยาก” 17.0% จุดที่อยากให้สังเกตคือ “ขาดพันธมิตรภายนอกที่เหมาะสม” หยุดอยู่แค่ 10.1% เท่านั้น ปัญหาจึงไม่ใช่ว่าไม่มีพันธมิตร แต่คือถึงมีพันธมิตรแล้ว ฝั่งบริษัทเองก็ไม่มีคนรับลูก โครงสร้างแบบนี้ส่งผลตรงไปที่ค่าบำรุงรักษา เพราะเมื่อภายในองค์กรแยกแยะอาการเบื้องต้นเองไม่ได้ แม้แต่เรื่องเล็กน้อยก็ต้องโยนออกไปข้างนอก ทำให้ชั้นของการตอบสนองขั้นต้นบวมขึ้น
ข้อที่สามคือระยะห่างจากสำนักงานใหญ่ในญี่ปุ่น ไทยกับญี่ปุ่นต่างเวลากัน 2 ชั่วโมง สี่โมงเย็นที่ไทยคือหกโมงเย็นที่ญี่ปุ่น เหตุขัดข้องที่เกิดช่วงเย็นของฝั่งไทยจึงมีโอกาสตรงกับเวลาที่ผู้รับผิดชอบฝั่งญี่ปุ่นเลิกงานไปแล้ว ยิ่งไปกว่านั้น วันหยุดนักขัตฤกษ์ของไทยส่วนใหญ่ไม่ตรงกับของญี่ปุ่น และยังมีช่วงหยุดยาวต่อเนื่องอย่างสงกรานต์ สัญญาที่เขียนเพียงบรรทัดเดียวว่า “ให้บริการในเวลาทำการ” โดยไม่ระบุว่ายึดปฏิทินของประเทศไหน จะกลายเป็นเรื่องเถียงกันทันทีในวันที่ระบบหยุดจริง
ยังมีชั้นของภาษาซ้อนอยู่อีก คนที่สังเกตเห็นความผิดปกติเป็นคนแรกในหน้างานคือพนักงานปฏิบัติการหรือหัวหน้างานชาวไทย ส่วนคนที่รับรายงานคือผู้จัดการโรงงานหรือผู้จัดการฝ่ายบริหารชาวญี่ปุ่น และต่อไปยังฝ่ายระบบสารสนเทศของสำนักงานใหญ่ ถ้าศูนย์รับแจ้งรับได้เฉพาะภาษาไทย หรือรับได้เฉพาะภาษาญี่ปุ่น เส้นทางนี้จะมีการแปลแทรกอยู่ตรงกลาง และคำอธิบายอาการจะผอมลง สิ่งที่ส่งถึงปลายทางเหลือแค่ “ขึ้น error” โดยไม่มีทั้งหน้าจอและรหัสข้อผิดพลาด ผลคือต้องเริ่มแยกแยะอาการกันใหม่ และการกู้คืนก็ช้าลง
ถ้ายังอยู่ในขั้นตอนคิดเรื่องการวางโครงสร้างทีมในไทยตั้งแต่ต้น การอ่านวิธีเลือกบริษัทพัฒนาระบบในประเทศไทย ควบคู่ไปด้วยจะช่วยจัดระเบียบเกณฑ์การคัดเลือกที่มองไปถึงช่วงบำรุงรักษาได้
งานบำรุงรักษามี 4 ประเภท – กู้คืน รักษาสภาพ เปลี่ยนแปลง และต่อยอด

จากตรงนี้จะเริ่มเข้าสู่การแยกส่วน งานที่คำว่าบำรุงรักษาครอบคลุมอยู่นั้น แบ่งได้เป็น 4 ประเภทที่มีธรรมชาติต่างกัน การแบ่งแบบนี้เป็นการจัดหมวดเชิงปฏิบัติเพื่อใช้ถกเรื่องค่าใช้จ่าย และไม่จำเป็นต้องตรงกับถ้อยคำในสัญญาเสมอไป ด้วยเหตุนี้เองจึงคุ้มค่าที่จะเอาสัญญาของบริษัทตัวเองมาอ่านใหม่โดยจับใส่ 4 หมวดนี้ ว่าครอบคลุมไปถึงไหน
การกู้คืน หรือการพาสิ่งที่พังกลับสู่สภาพเดิม คือการรับมือกับเหตุขัดข้อง เช่น กระบวนการหยุดเพราะ error เซิร์ฟเวอร์ไม่ตอบสนอง หรือมีบางหน้าจอเท่านั้นที่เปิดไม่ได้ ครอบคลุมตั้งแต่การแยกแยะสาเหตุ การหลบเลี่ยงชั่วคราว ไปจนถึงมาตรการแก้ไขถาวร สัญญาส่วนใหญ่เขียนขึ้นโดยมีขอบเขตนี้เป็นแกนกลาง แต่ต้องระวังว่า “ถึงแค่การตอบสนองขั้นต้น” กับ “จนกู้คืนเสร็จ” มีเนื้อหาต่างกันมาก เรื่องนี้จะกลับมาพูดอีกครั้งในหัวข้อ SLA
การรักษาสภาพ หรือการดูแลไม่ให้พัง คือการสำรองข้อมูลพร้อมทดสอบการกู้คืนข้อมูล การเฝ้าระวังปริมาณการใช้ดิสก์และล็อก การติดตั้งแพตช์ความปลอดภัย การต่ออายุใบรับรอง และการจัดระเบียบฐานข้อมูลใหม่ ล้วนเป็นงานเชิงป้องกัน ตัวงานเองดูจืดชืด ทำไปก็ไม่มีใครสังเกต ในทางกลับกัน ต่อให้หยุดทำไปสักครึ่งปีก็ยังไม่มีอะไรเกิดขึ้น จึงกลายเป็นขอบเขตที่ถูกเล็งไว้ตัดงบเป็นอันดับต้น ๆ และผลของการตัดงบจะโผล่ขึ้นมาให้เห็นราวปีที่สาม
การเปลี่ยนแปลง หรือการปรับสร้างใหม่ให้เข้ากับข้อเรียกร้องจากภายนอก คือการรองรับการแก้กฎหมาย การเปลี่ยนแบบฟอร์มเอกสารและการเชื่อมข้อมูลตามที่ลูกค้าร้องขอ การขยายมาสเตอร์และทบทวนการออกแบบสิทธิ์เมื่อเพิ่มสาขา รวมถึงการอัปเดตเมื่อระบบปฏิบัติการหรือฐานข้อมูลหมดระยะการสนับสนุน เป็นงานที่ระบบไม่ได้พัง แต่ถ้าปล่อยไว้แบบเดิมจะใช้งานไม่ได้ จึงต้องลงมือแก้ และในระบบของโรงงาน แรงงานคนที่เสียไปจริงส่วนใหญ่ก็อยู่ตรงนี้
การต่อยอด หรือการเติมมูลค่าใหม่ คือการรองรับเครื่องมือพกพาสำหรับบันทึกผลการผลิต การดึงข้อมูลจากเครื่องจักร การเพิ่มแดชบอร์ด และการเชื่อมต่อใหม่กับระบบอื่น ส่วนนี้ชัดเจนว่าเป็นงานพัฒนา และยังเป็นที่ถกเถียงได้ว่าควรรวมไว้ในสัญญาบำรุงรักษาหรือไม่ อย่างไรก็ตาม การเข้าใจผิดที่พบบ่อยคืองานที่ตั้งใจแยกออกมาเป็น “การต่อยอด” แท้จริงแล้วเป็น “การเปลี่ยนแปลง”
ความหมายเชิงปฏิบัติของการแบ่ง 4 หมวดอยู่ตรงที่ ความสามารถในการคาดการณ์ค่าใช้จ่ายของแต่ละหมวดไม่เท่ากัน การกู้คืนและการรักษาสภาพนั้น เมื่อกำหนดขนาดและโครงสร้างของระบบได้แล้ว ก็ประเมินแรงงานได้เกือบครบ การเปลี่ยนแปลงขึ้นอยู่กับความเปลี่ยนแปลงของสภาพแวดล้อมภายนอก จึงคาดเวลาที่จะเกิดไม่ได้ แต่ถ้ามองในช่วง 5 ปี พูดได้เต็มปากว่า “ต้องเกิดขึ้นอย่างน้อยไม่กี่รายการแน่นอน” ส่วนการต่อยอดเกิดจากการตัดสินใจเชิงบริหาร จึงไม่แน่นอนโดยสมบูรณ์
สิ่งที่คาดการณ์ได้ให้ใส่ในค่าคงที่ สิ่งที่คาดไม่ได้แต่ต้องเกิดแน่ให้ใส่เป็นโควตาแรงงาน ส่วนสิ่งที่ไม่แน่นอนโดยสมบูรณ์ให้เสนอราคาเป็นรายครั้ง นี่คือหลักการออกแบบชั้นค่าใช้จ่าย แต่ในสัญญาจริง มีเพียงสิ่งที่คาดการณ์ได้เท่านั้นที่เข้าไปอยู่ในค่าคงที่ ขณะที่สิ่งที่ต้องเกิดแน่กลับตกไปอยู่ในการเสนอราคารายครั้ง หัวข้อถัดไปจะดูว่ามันตกไปได้อย่างไร
สัญญาบำรุงรักษารายปีครอบคลุมจริงเพียง 1.5 ใน 4 ประเภท
ถ้าเอาเอกสารแนบท้ายของสัญญาบำรุงรักษารายปีที่ทำกันจริงในไทยมาจับใส่ 4 หมวด ส่วนใหญ่จะออกมาแบบนี้ การกู้คืนรวมอยู่ด้วย แต่มีข้อจำกัดว่า “ถึงแค่การตอบสนองขั้นต้นในเวลาทำการวันธรรมดา” และงานมาตรการแก้ไขถาวรอาจคิดตามค่าใช้จ่ายจริง การรักษาสภาพรวมอยู่เพียงบางส่วน การเฝ้าระวังและการตรวจสอบการสำรองข้อมูลอยู่ในสัญญา แต่การติดตั้งแพตช์และการตรวจสอบเวอร์ชันถูกระบุว่า “ไม่อยู่ในขอบเขต” หรือ “คิดแยกต่างหาก” การเปลี่ยนแปลงไม่รวมอยู่ด้วย และการต่อยอดยิ่งไม่ต้องพูดถึง
นับดูแล้วได้หนึ่งประเภทกับอีกครึ่งประเภท จาก 4 ประเภท คำว่า “1.5 ประเภท” มีความหมายแบบนั้น เพราะในสัญญาเขียนคำว่าบำรุงรักษาเอาไว้ จึงอ่านได้เหมือนว่าครอบคลุมทั้ง 4 ประเภท แต่สิ่งที่รับปากไว้จริงมีเพียงการกู้คืน กับการรักษาสภาพเพียงบางส่วน
ข้อเท็จจริงนี้เองไม่ได้แปลว่าผู้ขายไม่ซื่อสัตย์ เพราะแรงงานสำหรับงานเปลี่ยนแปลงนั้นคาดการณ์ล่วงหน้าไม่ได้ ถ้าเอาไปใส่ในค่าคงที่ ใบเสนอราคาจะพุ่งขึ้นทันที และในสถานการณ์ที่ถูกเอายอดรายปีไปวางเทียบกับคู่แข่ง ฝ่ายที่บวกแรงงานซึ่งคาดไม่ได้เข้าไปด้วยย่อมแพ้เป็นธรรมดา ผลลัพธ์คือตลาดทั้งตลาดถูกปรับให้เหมาะสมไปในทิศทาง “ถอดงานเปลี่ยนแปลงออกจากค่ารายปี” วิธีเปรียบเทียบของฝั่งผู้ซื้อจึงเป็นตัวกำหนดเนื้อในของสัญญามาโดยตลอด
แล้วฝั่งผู้ซื้อควรตรวจสอบอะไร ในวงต่อสัญญา ลองยื่นคำถามชุดนี้เป็นลายลักษณ์อักษรดู ถ้าคำตอบไม่ครบ แปลว่าสัญญานั้นยังคงเป็น 1.5 ประเภทเหมือนเดิม
- งานที่เกิดขึ้นในรอบ 12 เดือนที่ผ่านมา ถูกจัดเป็นการกู้คืน การรักษาสภาพ การเปลี่ยนแปลง หรือการต่อยอด อย่างละกี่รายการและใช้แรงงานเท่าไร ระบุออกมาได้หรือไม่
- ในจำนวนนั้น มีกี่รายการที่กลายเป็นใบเสนอราคาเพิ่มเติม และรวมเป็นเงินเท่าไร
- ในรายการของการรักษาสภาพ อะไรที่ทำจริงไปแล้วและอะไรที่ยังไม่ได้ทำ เหตุผลที่ยังไม่ได้ทำคืออะไร
- การเปลี่ยนแปลงที่คาดว่าจะเกิดใน 12 เดือนข้างหน้า เท่าที่ทราบมีอะไรบ้าง ระบุออกมาเป็นรายการได้หรือไม่
- ระบบปฏิบัติการ ฐานข้อมูล และมิดเดิลแวร์ที่ใช้อยู่ หมดระยะการสนับสนุนเมื่อไร ใครเป็นคนติดตาม
โดยเฉพาะข้อสุดท้ายได้ผลมาก เพราะวันหมดระยะการสนับสนุนของระบบปฏิบัติการและฐานข้อมูลเป็นหนึ่งในไม่กี่ “การเปลี่ยนแปลง” ที่รู้เวลาเกิดแน่นอนล่วงหน้า ถ้ารู้วันที่อยู่แล้วแต่ยังไม่ได้ตั้งงบไว้ ก็แปลว่าไม่มีใครในสัญญานั้นดูแลชั้นของการเปลี่ยนแปลงเลย
การเก็บผลของการจัดหมวดไว้ในตารางหนึ่งหน้า จะกลายเป็นวัตถุดิบที่แข็งแรงในการเจรจาต่อสัญญาครั้งถัดไป เพราะจะถามได้ว่า “ปีที่แล้วงานเปลี่ยนแปลงเกิดขึ้นเท่านี้รายการ ใช้แรงงานเท่านี้ และมีค่าใช้จ่ายเพิ่มเท่านี้ ถ้าเอาส่วนนี้ไปทำเป็นโควตาแรงงานแบบคงที่ ค่ารายปีจะเป็นเท่าไร” การย้ายบทสนทนาจากการเทียบยอดรายปี ไปสู่การเทียบชั้นค่าใช้จ่าย คือเป้าหมายของเรื่องนี้
ค่าบำรุงรักษาต้องมองเป็น 5 ชั้น
การแบ่ง 4 หมวดคือการแยกว่า “จะทำอะไรบ้าง” ถัดไปคือการแยกว่า “จ่ายเงินไปกับอะไรบ้าง” ถ้าแบ่งค่าบำรุงรักษาออกเป็น 5 ชั้น จะเปรียบเทียบระหว่างสัญญาได้
| ชั้น | เนื้อหา | สัญญา A | สัญญา B |
|---|---|---|---|
| ชั้น 1 ไลเซนส์และค่าสมัครสมาชิก | ค่าบำรุงรักษาแพ็กเกจ ไลเซนส์ฝั่งเครื่องผู้ใช้ | 216,000 | 216,000 |
| ชั้น 2 โครงสร้างพื้นฐาน | เซิร์ฟเวอร์ ระบบปฏิบัติการ ฐานข้อมูล การสำรองข้อมูล วงจรสื่อสาร | 150,000 | 150,000 |
| ชั้น 3 การตอบสนองขั้นต้น | ศูนย์รับแจ้ง การแยกแยะอาการ งานกู้คืน | 84,000 | 240,000 |
| ชั้น 4 การรองรับการเปลี่ยนแปลง | โควตางานจริงสำหรับการแก้กฎหมาย เพิ่มแบบฟอร์ม ขยายมาสเตอร์ | 0 | 135,000 |
| ชั้น 5 การรักษาองค์ความรู้ | ปรับปรุงเอกสารข้อกำหนด ตรวจนับโครงสร้างปีละครั้ง เอกสารส่งมอบงาน | 0 | 69,000 |
| รวม | 450,000 | 810,000 |
หน่วยเป็น THB และเป็นยอดรายปี ต่อไปจะอธิบายวิธีอ่านตารางนี้ทีละชั้น
ชั้น 1 คือค่าบำรุงรักษาที่จ่ายให้ผู้ขายในกรณีที่ใช้ผลิตภัณฑ์แบบแพ็กเกจ และไลเซนส์ฝั่งเครื่องผู้ใช้ ชั้นนี้มีช่องว่างในการต่อรองน้อย แทนที่จะไล่ขอส่วนลด การตรวจนับจำนวนไลเซนส์ที่ไม่ได้ใช้แล้วตัดออกทุกปีจะได้ผลแน่นอนกว่า เพราะสมมติฐานคือมีผู้ใช้ 20 คน จึงต้องเช็กว่าส่วนของคนที่ลาออกหรือย้ายหน่วยงานยังค้างอยู่หรือไม่
ชั้น 2 คือค่าใช้จ่ายของตัวเซิร์ฟเวอร์ ระบบปฏิบัติการ ฐานข้อมูล สื่อสำรองข้อมูล และวงจรสื่อสาร ถ้าเป็นออนพรีมิสก็คือค่าเสื่อมราคาและค่าบำรุงรักษา ถ้าเป็นคลาวด์ก็คือค่าบริการรายเดือน สิ่งที่มักถูกมองข้ามในชั้นนี้คือการทดสอบกู้คืนข้อมูลจากไฟล์สำรอง เพราะมีหลายกรณีมากที่สำรองข้อมูลไว้อย่างเดียวโดยไม่เคยตรวจสอบว่ากู้กลับมาได้จริงไหม การสำรองข้อมูลอยู่ในชั้น 2 แต่การทดสอบกู้คืนตกไปอยู่ที่ชั้น 3 หรือชั้น 5 จึงไม่ถูกระบุไว้ในขอบเขตงานของชั้นไหนเลย และลงเอยด้วยการที่ไม่มีใครลงมือทำ
ชั้น 3 คือการดูแลศูนย์รับแจ้ง และการแยกแยะอาการพร้อมงานกู้คืนเมื่อเกิดเหตุขัดข้อง ส่วนต่างระหว่าง 84,000 ของสัญญา A กับ 240,000 ของสัญญา B คือความกว้างของช่วงเวลาให้บริการ ว่าเฉพาะเวลาทำการวันธรรมดาหรือรวมนอกเวลาด้วย คือความต่างว่างานกู้คืนคิดตามค่าใช้จ่ายจริงหรือรวมอยู่ในสัญญา และคือความต่างว่าให้แบกงานเชิงป้องกันอย่างการติดตั้งแพตช์และการเฝ้าระวังความจุไว้ด้วยหรือไม่ ชั้นนี้เชื่อมตรงกับคุณภาพการตอบสนอง การเลือกฝั่งที่ถูกกว่าแบบตรงไปตรงมาจึงย้อนกลับมาเป็นเวลาที่ระบบหยุด
ชั้น 4 คือโควตาแรงงานสำหรับการรองรับการเปลี่ยนแปลง สัญญา A เป็นศูนย์ แปลว่าทุกครั้งที่มีการเปลี่ยนแปลงเกิดขึ้น ต้องเสนอราคาเป็นรายครั้ง ส่วน 135,000 ของสัญญา B คือค่าใช้จ่ายสำหรับกันแรงงานจำนวนหนึ่งไว้ล่วงหน้าตลอดทั้งปี ถ้าใช้โควตาไม่หมดแล้วยกยอดไปปีถัดไปได้หรือหมดอายุ ต้องเขียนระบุไว้ในสัญญา
ชั้น 5 คือค่าใช้จ่ายเพื่อเก็บรักษาองค์ความรู้ ทั้งการปรับปรุงเอกสารข้อกำหนด การตรวจนับโครงสร้างปีละครั้ง และการจัดทำเอกสารส่งมอบงาน ชั้นนี้เห็นผลได้ยากที่สุด และถูกตัดเป็นอันดับแรก ผลของการตัดจะโผล่ขึ้นมาพร้อมกันทีเดียว ในวินาทีที่ผู้รับผิดชอบเปลี่ยนคน หรือในวินาทีที่คิดจะเปลี่ยนผู้ขาย
ชั้น 1 และชั้น 2 ของสัญญา A กับ B มียอดเท่ากัน ส่วนที่ต่างกันคือชั้น 3 ชั้น 4 และชั้น 5 นั่นคือ “ส่วนที่มีคนเข้ามาเกี่ยวข้อง” เท่านั้น สัญญาที่ถูกกว่าจึงไม่ใช่สัญญาที่ค่าของสิ่งของถูกกว่า แต่คือสัญญาที่ลดการมีส่วนร่วมของคนลง
ประมาณการเฉพาะของเรา – เทียบสัญญาปีละ 450,000 THB กับปีละ 810,000 THB ในระยะ 5 ปี
จากตรงนี้จะคำนวณด้วยกรณีตัวอย่างที่เป็นรูปธรรม สิ่งที่จะแสดงต่อไปนี้เป็นประมาณการของกรณีตัวอย่างเท่านั้น ตัวเลขจริงจะเปลี่ยนไปตามขนาดการติดตั้ง ขอบเขตงาน และโครงสร้างสาขา ขอให้ดูที่โครงสร้างว่าส่วนต่างเกิดขึ้นที่ชั้นไหนและอันดับสลับกันตรงจุดใด มากกว่าดูที่ตัวเลขเอง
สมมติฐานมีดังนี้ โรงงานแปรรูปและประกอบสัญชาติญี่ปุ่นในจังหวัดพระนครศรีอยุธยา ประเทศไทย พนักงาน 300 คน มีระบบบริหารการผลิตที่ติดตั้งไว้เมื่อ 5 ปีก่อน ครอบคลุมตั้งแต่การรับคำสั่งซื้อจนถึงการส่งมอบ มีผู้ใช้ 20 คน โครงสร้างเป็นเซิร์ฟเวอร์ออนพรีมิส 1 เครื่องกับเครื่องผู้ใช้ 20 เครื่อง ค่าติดตั้งเริ่มต้นซึ่งรวมซอฟต์แวร์ ฮาร์ดแวร์ และการก่อสร้างระบบ อยู่ที่ 4,500,000 THB และกำหนดให้กำไรที่สูญเสียไปต่อหนึ่งชั่วโมงที่ระบบหยุดอยู่ที่ 22,000 THB
ขอเสริมเรื่องวิธีตั้งค่ากำไรที่สูญเสีย ในที่นี้เป็นการประมาณจากผลรวมของโอกาสที่เสียไปเพราะการส่งมอบหยุดชะงัก บวกกับแรงงานส่วนเพิ่มที่เกิดจากการสลับไปทำงานด้วยมือ ในทางปฏิบัติควรเริ่มจากตัวเลขหยาบ ๆ ด้วยการเอายอดส่งมอบต่อเดือนหารด้วยชั่วโมงทำงาน แล้วค่อยปรับโดยแยกงานที่ถอยกลับไปทำมือได้ออกจากงานที่ทำไม่ได้ ขอให้อ่านโดยแทนที่ด้วยตัวเลขของบริษัทท่านเอง
โรงงานแห่งนี้กำลังเปรียบเทียบสองทางเลือกในการต่อสัญญาบำรุงรักษา
| ทางเลือก | เนื้อหา | ค่ารายปี (THB) | สัดส่วนต่อค่าติดตั้งเริ่มต้น |
|---|---|---|---|
| สัญญา A | รับแจ้งเหตุขัดข้องและเฝ้าระวังพื้นฐานเท่านั้น เวลาทำการวันธรรมดา งานกู้คืนคิดตามค่าใช้จ่ายจริง | 450,000 | 10.0% |
| สัญญา B | สัญญาแบบครอบคลุม รวมโควตาแรงงานสำหรับการเปลี่ยนแปลงและการรักษาองค์ความรู้ | 810,000 | 18.0% |
ความสัมพันธ์คือสัญญา A ถูกกว่าสัญญา B อยู่ 44% เมื่อวัดที่ค่ารายปี ถ้ามองเป็นสัดส่วนต่อค่าติดตั้งเริ่มต้นก็คือ 10.0% กับ 18.0% หากยกข้อมูลสาธารณะในญี่ปุ่นมาเป็นค่าอ้างอิง เว็บไซต์ช่วยจัดหาผู้พัฒนาระบบชื่อ System Kanji ซึ่งปรับปรุงข้อมูลเมื่อวันที่ 10 ตุลาคม 2025 ระบุค่าบำรุงรักษาโดยไม่รวมค่าจ้างบริการภายนอกไว้ที่ราว 5% ของค่าพัฒนา และราว 15% สำหรับระบบขนาดใหญ่ ข้อมูลนี้ไม่ใช่สถิติปฐมภูมิ แต่เป็นค่าประมาณที่ฝั่งผู้ให้บริการนำเสนอ เมื่อเทียบกันแล้ว 10.0% ของสัญญา A อยู่ในกรอบค่าประมาณ ส่วน 18.0% ของสัญญา B อยู่สูงกว่ากรอบเล็กน้อย
ถ้าดูเฉพาะค่ารายปี การตัดสินใจเลือกสัญญา A ดูมีเหตุผลอย่างยิ่ง ส่วนต่างคือ 360,000 THB ต่อปี และ 1,800,000 THB ในระยะ 5 ปี เป็นตัวเลขที่เขียนลงในเอกสารขออนุมัติได้ว่า “ลดค่าบำรุงรักษาลง 44%”
และเมื่อผ่านไป 5 ปี ยอดสะสมของค่าสัญญาจะออกมาแบบนี้ สัญญา A อยู่ที่ 2,250,000 THB ส่วนสัญญา B อยู่ที่ 4,050,000 THB ถึงตรงนี้ยังเป็นไปตามแผน ปัญหาอยู่ที่ค่าใช้จ่ายซึ่งไม่ได้ปรากฏในตารางนี้ต่างหาก
อนึ่ง หากต้องการไล่ดูตั้งแต่โครงสร้างของค่าติดตั้งตั้งต้น การอ่านค่าใช้จ่ายและโครงสร้างของการพัฒนาระบบงาน ไว้ก่อน จะช่วยให้เห็นภาพว่าค่าบำรุงรักษาผูกอยู่กับส่วนไหนของค่าใช้จ่ายเริ่มต้น
ค่าใช้จ่ายที่หลุดออกนอกสัญญาคืออะไรบ้าง
ต่อไปนี้คือรายการค่าใช้จ่ายที่หลุดออกนอกสัญญา จากงานที่เกิดขึ้นจริงตลอด 5 ปี จำนวนเงินเป็น THB และเป็นยอดรวม 5 ปี
| รายการ | สัญญา A | สัญญา B |
|---|---|---|
| การแก้ไขแบบฟอร์มและการเชื่อมข้อมูลตามข้อเรียกร้องของลูกค้า (2 รายการ) | 240,000 และ 180,000 | รวมอยู่ในสัญญา |
| การอัปเดตเมื่อระบบปฏิบัติการและฐานข้อมูลหมดระยะการสนับสนุน (ปีที่ 3) | 520,000 | 260,000 |
| การขยายมาสเตอร์และการเปลี่ยนการออกแบบสิทธิ์เมื่อเพิ่มสาขา | 160,000 | รวมอยู่ในสัญญา |
| การกู้คืนนอกเวลาทำการและวันหยุด (5 ครั้ง คิดตามค่าใช้จ่ายจริง) | 125,000 | รวมอยู่ในสัญญา |
| การสำรวจสถานะปัจจุบันเพราะไม่มีเอกสารข้อกำหนดหลงเหลือ | 300,000 | รวมอยู่ในสัญญา |
| การเพิ่มฟังก์ชันขนาดใหญ่ (1 รายการ) | ไม่นับรวมในสัญญา | 300,000 |
| ยอดรวมย่อย | 1,525,000 | 560,000 |
มาไล่ดูทีละรายการว่าเกิดขึ้นเพราะอะไร
การแก้ไขแบบฟอร์มและการเชื่อมข้อมูล (2 รายการ) กรณีแรกคือลูกค้ารายใหญ่เปลี่ยนรูปแบบข้อมูลการส่งมอบจนรายการข้อมูลของ EDI เพิ่มขึ้น อีกกรณีคือลูกค้าอีกรายเปลี่ยนเลย์เอาต์ของใบส่งของที่กำหนดไว้ ทั้งสองกรณีไม่ได้เกิดจากความต้องการของฝั่งเรา แต่เป็นการเปลี่ยนแปลงที่จำเป็นเพื่อรักษาธุรกิจไว้ ในทางปฏิบัติจึงไม่มีทางเลือกที่จะปฏิเสธ ในสัญญา A กลายเป็นใบเสนอราคาเพิ่มเติม 240,000 และ 180,000 ส่วนในสัญญา B ถูกดูดซับไว้ด้วยโควตาแรงงานของชั้น 4
การอัปเดตเมื่อระบบปฏิบัติการและฐานข้อมูลหมดระยะการสนับสนุน เกิดขึ้นในปีที่ 3 เมื่อระยะการสนับสนุนของระบบปฏิบัติการเซิร์ฟเวอร์และฐานข้อมูลมาถึงกำหนด จึงต้องตรวจสอบความเข้ากันได้ของแอปพลิเคชัน ทดสอบการทำงานในสภาพแวดล้อมทดสอบ และสลับไปใช้งานจริง สัญญา A อยู่ที่ 520,000 สัญญา B อยู่ที่ 260,000 เหตุที่สัญญา B ก็ยังไม่เป็นศูนย์ เพราะค่าไลเซนส์และงานสลับสู่ระบบจริงเกินโควตาแรงงาน แต่ที่ยังต่างกันถึง 260,000 เป็นเพราะในสัญญา B มีการตรวจนับโครงสร้างตามชั้น 5 จึงมีเอกสารบันทึกโครงสร้างปัจจุบันไว้แล้ว ทำให้บีบขั้นตอนการสำรวจให้สั้นลงได้
การขยายมาสเตอร์และการเปลี่ยนการออกแบบสิทธิ์เมื่อเพิ่มสาขา เมื่อโรงงานแห่งที่ 2 เริ่มเดินเครื่อง จึงจำเป็นต้องเพิ่มรหัสสาขา เพิ่มคุณสมบัติในมาสเตอร์สินค้า และเปลี่ยนการออกแบบสิทธิ์การเข้าถึงแยกตามสาขา ระบบไม่ได้พัง แต่ถ้าไม่แก้ไขส่วนนี้ก็บริหารผลการผลิตของสาขาใหม่ไม่ได้ สัญญา A จึงมีค่าใช้จ่ายเพิ่ม 160,000 หากอยู่ในขั้นพิจารณาขยายระบบไปยังสาขาต่างประเทศ สิ่งที่เกิดขึ้นเมื่อขยายระบบไปยังโรงงานในต่างประเทศ ก็เป็นข้อมูลที่ใช้อ้างอิงได้
การกู้คืนนอกเวลาทำการและวันหยุด (5 ครั้ง) สัญญา A ครอบคลุมเฉพาะเวลาทำการวันธรรมดา เหตุขัดข้องในกะกลางคืนและวันหยุดจึงคิดตามค่าใช้จ่ายจริง รวม 5 ครั้งใน 5 ปี เป็นเงิน 125,000 THB ในแง่จำนวนเงินอาจดูน้อย แต่แก่นของรายการนี้ไม่ใช่ค่าใช้จ่าย หากคือเวลารอคอยกว่าที่การตอบสนองจะเริ่มต้น ซึ่งจะไปสะท้อนอยู่ในเวลาที่ระบบหยุดในหัวข้อถัดไป
การสำรวจสถานะปัจจุบันเพราะไม่มีเอกสารข้อกำหนดหลงเหลือ นี่คือค่าใช้จ่ายที่มองเห็นยากที่สุดในรอบ 5 ปี เพราะสัญญา A ตัดชั้น 5 ให้เป็นศูนย์ จึงมีแต่เอกสารข้อกำหนดจากตอนติดตั้งเมื่อ 5 ปีก่อนเท่านั้น การแก้ไขที่เพิ่มเข้าไประหว่างทางไม่ถูกสะท้อนลงในเอกสาร และผู้รับผิดชอบทั้งฝั่งญี่ปุ่นและฝั่งไทยก็เปลี่ยนคนไปแล้ว พอถึงปีที่ 4 ที่คิดจะทำการแก้ไขขนาดใหญ่ ต้องเสียเงิน 300,000 THB ไปกับการสำรวจว่า “ตอนนี้ระบบเป็นอย่างไร” ก่อนเป็นอันดับแรก นี่ไม่ใช่ค่าใช้จ่ายสำหรับฟังก์ชันที่สร้างขึ้น แต่เป็นค่าใช้จ่ายเพื่อนึกให้ออกว่าเคยสร้างอะไรไว้
การเพิ่มฟังก์ชันขนาดใหญ่ (1 รายการ) ยอด 300,000 ของสัญญา B เป็นงานต่อยอดที่ชัดเจน คือการเพิ่มกลไกการบันทึกผลการผลิต และเนื่องจากเกินโควตาแรงงานจึงคิดเป็นค่าใช้จ่ายแยกต่างหาก ส่วนที่ระบุช่องของสัญญา A ว่า “ไม่นับรวมในสัญญา” เพราะในสัญญา A งานนี้ถูกพับไป จึงไม่ถูกบันทึกเป็นค่าใช้จ่าย ไม่ใช่ว่าประหยัดเงินได้ แต่คือการปรับปรุงนั้นไม่ได้เกิดขึ้นเลย นี่คือความสูญเสียที่ไม่ปรากฏบนตาราง
เมื่อรวมค่าสัญญาเข้ากับค่าใช้จ่ายนอกสัญญา สัญญา A อยู่ที่ 3,775,000 THB และสัญญา B อยู่ที่ 4,610,000 THB ส่วนต่างของค่าสัญญาซึ่งเคยอยู่ที่ 1,800,000 THB ในระยะ 5 ปี หดลงมาเหลือ 835,000 THB ตรงจุดนี้ ถึงอย่างนั้นสัญญา A ก็ยังถูกกว่าอยู่ดี การพลิกอันดับยังอยู่อีกขั้นถัดไป
เมื่อใส่มูลค่าของเวลาที่ระบบหยุดลงไป อันดับจะสลับกัน

องค์ประกอบสุดท้ายคือเวลาที่ระบบหยุด ระหว่างที่ระบบหยุด จะออกคำสั่งส่งมอบไม่ได้ และบันทึกผลการผลิตก็ไม่ได้ ต่อให้หมุนงานด้วยกระดาษกับไวต์บอร์ดไปก่อน ก็ยังต้องตามคีย์ข้อมูลย้อนหลังหลังจากกู้คืนระบบเสร็จ
| ทางเลือก | เวลาที่ระบบหยุดต่อปี | ความสูญเสียจากการหยุดต่อปี (THB) | ความสูญเสียจากการหยุดใน 5 ปี (THB) |
|---|---|---|---|
| สัญญา A | 18 ชั่วโมง | 396,000 | 1,980,000 |
| สัญญา B | 6 ชั่วโมง | 132,000 | 660,000 |
18 ชั่วโมงต่อปีกับ 6 ชั่วโมงต่อปี ต่างกันอยู่ 12 ชั่วโมง พอบอกว่าปีละ 12 ชั่วโมงก็ดูเหมือนไม่ใช่ส่วนต่างที่มากมาย แต่เมื่อคูณด้วย 22,000 THB ต่อชั่วโมง จะกลายเป็น 264,000 THB ต่อปี และ 1,320,000 THB ในระยะ 5 ปี
เหตุผลที่ทำให้เกิดส่วนต่างมีอยู่สามข้อ ข้อแรกคือเวลารอคอยกว่าการตอบสนองจะเริ่ม สัญญา A ครอบคลุมเฉพาะเวลาทำการวันธรรมดา เหตุการณ์ที่เกิดในคืนวันศุกร์จึงไม่ขยับเลยจนถึงเช้าวันจันทร์ ข้อที่สองคือความเร็วในการแยกแยะอาการ สัญญา B รักษาข้อมูลโครงสร้างไว้ด้วยชั้น 5 จึงเดาได้เร็วว่าควรไปดูตรงไหน ข้อที่สามคือการมีหรือไม่มีงานป้องกัน สัญญา B รวมการติดตั้งแพตช์และการเฝ้าระวังความจุไว้ในชั้น 3 ด้วย จำนวนครั้งที่เกิดเหตุจึงน้อยลงตั้งแต่ต้นทาง เนื่องจากยอดของชั้น 1 และชั้น 2 เท่ากันทั้งสองทางเลือก ส่วนต่างตรงนี้จึงเกิดจากการมีส่วนร่วมของคน ไม่ใช่จากอุปกรณ์
ต่อไปคือยอดรวม 5 ปี
| ทางเลือก | ยอดรวม 5 ปี (THB) | สัดส่วนเท่าตัวต่อค่าติดตั้งเริ่มต้น |
|---|---|---|
| สัญญา A | 5,755,000 | 1.28 เท่า |
| สัญญา B | 5,270,000 | 1.17 เท่า |
อันดับสลับกันเรียบร้อย ส่วนต่างคือ 485,000 THB ผลลัพธ์คือสัญญา A แพงกว่าสัญญา B อยู่ 9.2% สัญญาที่ถูกกว่า 44% เมื่อวัดที่ค่ารายปี กลายเป็นแพงกว่า 9.2% เมื่อคิดยอดรวม 5 ปีรวมความสูญเสียจากการหยุดระบบ นี่คือการพลิกอันดับที่เป็นแกนกลางของบทความนี้
สิ่งสำคัญคือ การพลิกอันดับครั้งนี้ไม่ได้เกิดเพราะ “ผู้ขายของสัญญา A ไม่ดี” ผู้ขายของสัญญา A ทำงานตรงตามสัญญาทุกประการ สาเหตุของการพลิกคือการผลักชั้น 4 ซึ่งเป็นการรองรับการเปลี่ยนแปลง และชั้น 5 ซึ่งเป็นการรักษาองค์ความรู้ ออกไปนอกค่าใช้จ่ายตั้งแต่ขั้นออกแบบสัญญา พร้อมกับทำให้ชั้น 3 ซึ่งเป็นการตอบสนองขั้นต้นบางลง เพราะตัดชั้น 4 ออก การแก้ไขแบบฟอร์ม 420,000 THB และการเพิ่มสาขา 160,000 THB จึงกลายเป็นการเสนอราคารายครั้ง เพราะตัดชั้น 5 ออก จึงไม่รู้ว่าสถานะปัจจุบันเป็นอย่างไร ต้องเสียไปกับการสำรวจอีก 300,000 THB และเพราะทำให้ชั้น 3 บางลง ค่าใช้จ่ายจริงของการทำงานนอกเวลา 125,000 THB กับเวลารอคอยจึงสะสมเพิ่มขึ้น ยอดรวมย่อยของค่าใช้จ่ายนอกสัญญาจึงไปถึง 1,525,000 THB และความล่าช้าในการแยกแยะอาการทำให้เวลาที่ระบบหยุดเพิ่มเป็น 3 เท่า
ขอเพิ่มอีกเรื่องหนึ่ง สัดส่วนเท่าตัวต่อค่าติดตั้งเริ่มต้นใช้เป็นจุดตั้งต้นของการวางแผนงบประมาณได้ แต่ขอให้จับแยกเป็นสองชั้น ส่วนที่ต้องตั้งเป็นงบรายจ่ายจริงคือค่าสัญญาบวกค่าใช้จ่ายนอกสัญญา ซึ่งอยู่ที่ 0.84 เท่าของค่าติดตั้งเริ่มต้นสำหรับสัญญา A ถึง 1.02 เท่าสำหรับสัญญา B ส่วนต้นทุนรวมที่นับความสูญเสียจากการหยุดระบบเข้าไปด้วยจะขึ้นไปถึง 1.17 เท่าและ 1.28 เท่า แต่ส่วนนี้ไม่ใช่รายจ่าย หากเป็นโอกาสที่สูญไป จึงเป็นตัวเลขที่ควรดูในฝั่งการตัดสินใจลงทุน ไม่ใช่ในเอกสารงบประมาณ พูดกลับกันก็คือ ต่อให้กดค่ารายปีให้เหลือ 10.0% ของค่าใช้จ่ายเริ่มต้น ยอดรวม 5 ปีก็ยังบวมได้ถึง 1.28 เท่า ขนาดของการลดค่ารายปี ไม่เท่ากับขนาดของการลดยอดรวม
SLA รับปากเรื่องเวลาตอบกลับ ไม่ใช่เวลากู้คืน
สิ่งที่ถูกอ่านผิดมากที่สุดในสัญญาคือนิยามของเวลาใน SLA หรือข้อตกลงระดับการให้บริการ ความสามารถในการอ่านตรงนี้ให้ถูกต้อง จะเปลี่ยนการประเมินเวลาที่ระบบหยุดไปเลย
เวลาตอบกลับ คือเวลานับตั้งแต่รับแจ้งเหตุขัดข้อง จนถึงตอนที่ให้คำตอบขั้นต้นกลับไป เมื่อมีข้อความตอบกลับมาว่า “รับเรื่องแล้ว กำลังเริ่มตรวจสอบ” นาฬิกาเรือนนี้ก็หยุดเดิน
เวลากู้คืน คือเวลาจนกว่าบริการจะกลับสู่สภาพที่ใช้งานได้ แน่นอนว่าสิ่งที่โรงงานสนใจคืออย่างหลัง แต่สัญญาบำรุงรักษาจำนวนมากไม่ได้รับปากเรื่องเวลากู้คืน เหตุผลชัดเจนมาก เพราะในขั้นที่ยังไม่รู้สาเหตุของเหตุขัดข้อง ย่อมรับปากเวลากู้คืนไม่ได้ ถ้าเป็นฮาร์ดแวร์เสียหาย การจัดหาอะไหล่อาจกินเวลาหลายวัน ถ้าเป็นข้อมูลเสียหาย ก็ไม่รู้ว่าการกู้ข้อมูลจะใช้เวลากี่ชั่วโมง การไม่เขียนสิ่งที่รับปากไม่ได้ลงในสัญญา จึงเป็นการตัดสินใจที่ถูกต้องในมุมของผู้ขาย
ปัญหาคือฝั่งผู้ซื้ออ่านข้อความว่า “ตอบสนองภายใน 4 ชั่วโมง” เป็น “ซ่อมเสร็จใน 4 ชั่วโมง” ข้อความนี้เกือบทั้งหมดหมายถึงเวลาตอบกลับ ในวงต่อสัญญา ขอให้ตรวจสอบประเด็นเหล่านี้ทีละข้อ
- เวลาดังกล่าวคือเวลาตอบกลับหรือเวลากู้คืน เขียนไว้ในข้อสัญญาข้อใดและเขียนอย่างไร
- มีการกำหนดค่าเป้าหมายของเวลากู้คืนหรือไม่ โดยเป็นเป้าหมายก็ได้ไม่ต้องเป็นการรับประกัน ถ้าไม่ได้กำหนดไว้ ขอค่ามัธยฐานและค่าสูงสุดของผลงานที่ผ่านมาได้หรือไม่
- แบ่งระดับความรุนแรงของเหตุขัดข้องเป็นกี่ระดับ และนิยามด้วยตัวอย่างที่เป็นรูปธรรมหรือไม่ว่าเหตุการณ์แบบใดอยู่ระดับใด
- เวลาตอบกลับเปลี่ยนไปอย่างไรตามระดับความรุนแรง
จากนั้น สำหรับฐานปฏิบัติการในไทย จำเป็นต้องเคาะนิยามของตัวเวลาเองให้ชัด
- “เวลาทำการ” หมายถึงกี่โมงถึงกี่โมง เป็นเวลาไทยหรือเวลาญี่ปุ่น
- วันหยุดนักขัตฤกษ์ยึดปฏิทินของประเทศไหน ช่วงวันหยุดยาวอย่างสงกรานต์จัดการอย่างไร
- ช่องทางรับแจ้งนอกเวลาทำการคืออะไร โทรศัพท์ อีเมล หรือแชต และใครเป็นคนรับ
- โครงสร้างค่าบริการนอกเวลาทำการเป็นอย่างไร คิดต่อการเรียกหนึ่งครั้ง หรือคิดเป็นอัตราต่อชั่วโมง มีจำนวนชั่วโมงขั้นต่ำที่เรียกเก็บหรือไม่
- ภาษาที่รับแจ้งคือภาษาไทย ญี่ปุ่น หรืออังกฤษ ถ้ามีหลายภาษา ช่วงเวลาใดใช้ภาษาใดได้
อย่ามองข้ามหัวข้อเรื่องภาษา เพราะคนที่สังเกตเห็นความผิดปกติเป็นคนแรกในหน้างานคือพนักงานชาวไทย และการที่คนคนนั้นติดต่อผู้ขายได้โดยตรงหรือไม่ จะเปลี่ยนความเร็วของการเคลื่อนไหวช่วงแรก ถ้าโครงสร้างบังคับให้ต้องผ่านผู้บริหารชาวญี่ปุ่นก่อน แล้วผู้บริหารคนนั้นติดประชุมอยู่ การเคลื่อนไหวช่วงแรกก็หยุดอยู่ตรงนั้น ยิ่งถ้าออกแบบให้ต้องข้ามเวลาต่างกัน 2 ชั่วโมงไปขอคำตัดสินจากฝ่ายระบบสารสนเทศของสำนักงานใหญ่ ก็ยิ่งช้าลงไปอีก
ต่อให้ในสัญญาเขียนว่า “รองรับภาษาญี่ปุ่น” แต่ถ้าหมายถึงเฉพาะเวลา 9 นาฬิกาถึง 18 นาฬิกาตามเวลาญี่ปุ่น ก็แปลว่าหลังบ่ายสี่โมงของไทยแทบไม่มีการให้บริการเลย เพียงแค่เคาะบรรทัดนี้ให้ชัด เวลาที่ระบบหยุดต่อปีก็เปลี่ยนไปแล้ว
ประเด็นที่มีผลเฉพาะกับสัญญาบำรุงรักษาในไทยและอาเซียน
ต่อไปนี้คือประเด็นที่ไม่ปรากฏในสัญญาภายในประเทศญี่ปุ่น แต่จะโผล่ขึ้นมาเมื่อดำเนินงานในไทย
ความเคลื่อนไหวของใบกำกับอิเล็กทรอนิกส์ ระบบ e-Tax Invoice และ e-Receipt ของไทย ณ ปี 2026 ยังเป็นการใช้งานแบบสมัครใจ การบังคับใช้ใบกำกับอิเล็กทรอนิกส์สำหรับธุรกรรมแบบ B2B ยังไม่ได้ถูกบัญญัติเป็นกฎหมาย อย่างไรก็ตาม มาตรการจูงใจยังคงมีอยู่ โดยการลงทุนในใบกำกับอิเล็กทรอนิกส์และการหักภาษี ณ ที่จ่ายแบบอิเล็กทรอนิกส์ สามารถนำมาหักเป็นรายจ่ายได้ 200% และมีอัตราภาษีหัก ณ ที่จ่ายพิเศษที่ 1% ในเดือนมิถุนายน 2026 คณะรัฐมนตรีได้อนุมัติการขยายเวลาไปจนถึงสิ้นปี 2027 แต่พระราชกฤษฎีกาและกฎกระทรวงยังไม่ได้ประกาศออกมา นอกจากนี้ ผู้ประกอบการที่มียอดขายต่อปีไม่เกิน 30,000,000 THB สามารถใช้รูปแบบอย่างง่ายผ่านอีเมลได้
ในมุมของสัญญาบำรุงรักษา สิ่งสำคัญไม่ใช่ข้อเท็จจริงที่ว่า “เป็นการใช้งานแบบสมัครใจ” แต่คือการที่ถึงจะสมัครใจ ก็ยังมีเส้นทางที่ทำให้ต้องรองรับอยู่ดี หากลูกค้ารายใหญ่ร้องขอให้รับส่งเอกสารด้วยใบกำกับอิเล็กทรอนิกส์เพื่อเพิ่มประสิทธิภาพของฝั่งตัวเอง ต่อให้ไม่มีข้อบังคับทางกฎหมายก็หลีกเลี่ยงไม่ได้ที่จะต้องรองรับ และการแก้ไขครั้งนี้ไม่ใช่การรองรับการแก้กฎหมาย แต่เป็นการรองรับข้อเรียกร้องของลูกค้า ถ้านิยามการรองรับการเปลี่ยนแปลงในสัญญาถูกจำกัดไว้เพียง “การแก้ไขอันเนื่องมาจากการแก้กฎหมายของไทย” การแก้ไขครั้งนี้จะอยู่นอกสัญญา การขยายนิยามให้ครอบคลุมถึง “การแก้ไขอันเนื่องมาจากการแก้กฎหมายและข้อเรียกร้องของลูกค้ารายสำคัญ” หรือไม่ จึงสร้างส่วนต่างระดับหลายแสน THB
ภาษาและเวอร์ชันของเอกสาร มีหน้างานจำนวนมากที่ยังไม่ได้ตัดสินใจว่าจะดูแลเอกสารข้อกำหนดและคู่มือไว้ในภาษาใด ถ้าดูแลไว้เฉพาะภาษาญี่ปุ่น ผู้รับผิดชอบชาวไทยก็อ่านไม่ได้ ถ้ามีแต่ภาษาไทย สำนักงานใหญ่ก็อ่านไม่ได้ ในทางปฏิบัติ การแบ่งแบบนี้ใช้ได้ผล คือเลย์เอาต์หน้าจอและขั้นตอนการใช้งานทำเป็นภาษาไทยและภาษาญี่ปุ่น ส่วนโครงสร้างระบบและข้อกำหนดของอินเทอร์เฟซทำเป็นภาษาอังกฤษ ถ้าไม่เขียนไว้ในสัญญาว่าเอกสารใดดูแลด้วยภาษาใด ก็จะมีเรื่องให้เถียงกันทุกครั้งที่ปรับปรุงเอกสาร
การหมุนเวียนของคน ดังที่กล่าวไปแล้วว่าอุปสรรคอันดับหนึ่งในการสำรวจของเจโทรคือ “การขาดแคลนบุคลากรด้านดิจิทัล” ที่ 60.7% ในตลาดแรงงานไทย การเปลี่ยนงานเป็นเรื่องปกติ และการที่ผู้ดูแลระบบเปลี่ยนคนทุก 2 ถึง 3 ปีก็ไม่ใช่เรื่องแปลก เรื่องนี้ไม่ได้เกิดเฉพาะฝั่งบริษัทเราเท่านั้น แต่เกิดกับฝั่งผู้ขายด้วย ด้วยเหตุนี้ชั้น 5 หรือการรักษาองค์ความรู้จึงได้ผล เพราะเป็นการออกแบบบนสมมติฐานว่าความรู้ที่ผูกติดกับตัวคนจะต้องสูญหายไปแน่นอน จึงยอมจ่ายค่าถอดความรู้ลงเป็นเอกสารทุกปี
การหมุนเวียนของพนักงานประจำต่างประเทศ ผู้บริหารชาวญี่ปุ่นจะเปลี่ยนคนทุก 3 ถึง 5 ปี คนที่เซ็นสัญญากับคนที่ตัดสินใจต่อสัญญาจึงเป็นคนละคน ถ้าไม่มีการส่งต่อว่าทำไมคนก่อนหน้าจึงเลือกสัญญาแบบนั้น สิ่งที่เหลืออยู่ในวงต่อสัญญาก็จะมีแค่การตัดสินใจว่า “แพงเกินไป เอาแบบถูกกว่า” ขอแนะนำให้เก็บเจตนาของการออกแบบสัญญาไว้ในบันทึกหนึ่งหน้า โดยเขียนแยกตามชั้นว่าทำไมจึงจ่ายเงินจำนวนนี้ เพียงเท่านี้คุณภาพของการต่อสัญญาครั้งถัดไปก็เปลี่ยนไปแล้ว
การทบทวนการเลือกระบบเอง บางครั้งสาเหตุที่งานบำรุงรักษาหนักเกินไปไม่ได้อยู่ที่สัญญา แต่อยู่ที่โครงสร้างของระบบเอง ระบบที่พัฒนาขึ้นใหม่ทั้งหมดและถูกปรับแต่งมากเกินไป จำเป็นต้องสำรวจขอบเขตผลกระทบทุกครั้งที่แก้ไข ชั้น 3 และชั้น 4 จึงบวมขึ้นในเชิงโครงสร้าง หากอยู่ในขั้นพิจารณาถึงขั้นเปลี่ยนระบบ ลองใช้การเปรียบเทียบและเกณฑ์การเลือกระบบบริหารการผลิต ทบทวนรายชื่อผู้สมัครจากแกนของความง่ายในการบำรุงรักษาดู
ชุด 4 อย่างที่ป้องกันการถูกผูกติดกับผู้ขาย (vendor lock-in)

สภาพที่เปลี่ยนสัญญาไม่ได้ ตัวมันเองก็คือค่าใช้จ่ายอย่างหนึ่ง เพราะจะกลายเป็นต้องยอมรับการขึ้นราคา และต่อให้ไม่พอใจคุณภาพการตอบสนองก็ไม่มีวัตถุดิบไว้ต่อรอง สิ่งที่ควรเขียนลงในสัญญาเพื่อรักษาความเป็นไปได้ในการเปลี่ยนผู้ขาย มีอยู่ 4 อย่างต่อไปนี้
เอกสารการออกแบบ ทั้งข้อกำหนดหน้าจอ ข้อกำหนดแบบฟอร์ม การออกแบบทางกายภาพของฐานข้อมูลและนิยามตาราง ข้อกำหนดอินเทอร์เฟซกับระบบอื่น รายการงานประมวลผลแบบแบตช์และลำดับการทำงาน เงื่อนไขคือเอกสารเหล่านี้ต้องสะท้อนสภาพ ณ ปัจจุบัน ไม่ใช่สภาพ ณ ตอนติดตั้ง จึงต้องเขียนหน้าที่ในการปรับปรุงเอกสารทุกครั้งที่แก้ไขระบบลงในสัญญา และตรวจสอบปีละครั้งว่าไม่มีส่วนต่างหลงเหลือ งานนี้เองคือชั้น 5
ซอร์สโค้ดหรือข้อมูลการตั้งค่า ถ้าเป็นการพัฒนาขึ้นใหม่ทั้งหมด ก็คือซอร์สโค้ดพร้อมคู่มือขั้นตอนการคอมไพล์และการนำไปเดินระบบ ถ้าเป็นแพ็กเกจ ก็คือเนื้อหาการตั้งค่าที่ปรับแต่งไว้ นิยามของแบบฟอร์มที่เพิ่มเข้าไป การตั้งค่าเวิร์กโฟลว์ และตารางสิทธิ์ ต่อให้ได้ยินว่า “ส่งมอบซอร์สโค้ดไปแล้ว” ก็มีกรณีที่ในมือมีแต่เวอร์ชันเมื่อ 5 ปีก่อน ขอให้ตรวจสอบไปจนถึงว่าเวอร์ชันล่าสุดอยู่ในการดูแลของใครและเก็บไว้ที่ไหน
รูปแบบการส่งออกข้อมูล ต้องส่งออกมาสเตอร์ทั้งหมดและธุรกรรมทั้งหมดในรูปแบบที่อ่านได้จากภายนอกอย่าง CSV หรือรูปแบบทั่วไปอื่น ๆ ได้ และต้องมีเอกสารนิยามรายการข้อมูลของไฟล์ที่ส่งออกด้วย จุดที่มักถูกมองข้ามตรงนี้คือความหมายของค่ารหัส ต่อให้ช่องสถานะมีเลข 3 อยู่ แต่ถ้าไม่มีตารางเทียบว่า 3 หมายถึงอะไร ข้อมูลก็ย้ายระบบไม่ได้ ขอให้ตัดสินจากการที่ข้อมูลซึ่งส่งออกมาแล้วตีความเองได้หรือไม่ ไม่ใช่จากการที่มีฟังก์ชันส่งออกหรือไม่
ขั้นตอนและระยะเวลาการส่งมอบงาน ให้เขียนเป็นข้อสัญญาว่าเมื่อสัญญาสิ้นสุด จะส่งมอบอะไรให้ผู้ขายรายถัดไปหรือให้บริษัทเราเอง และจะดำเนินการภายในระยะเวลาและปริมาณแรงงานเท่าใด ถ้อยคำนามธรรมอย่าง “จะให้ความร่วมมือเมื่อสิ้นสุดสัญญา” ใช้งานจริงไม่ได้ ต้องเขียนถึงรายการสิ่งส่งมอบ ระยะเวลาส่งมอบงาน เช่น 30 วันก่อนสัญญาสิ้นสุด ปริมาณแรงงานในช่วงเวลานั้น และการแบ่งภาระค่าใช้จ่าย จึงจะเกิดผลบังคับใช้จริง
ถ้าสัญญาไม่มี 4 อย่างนี้ พอสัญญาสิ้นสุดก็จะไม่เหลืออะไรอยู่ในมือ และเมื่อไม่เหลืออะไร ผู้ขายรายถัดไปก็ต้องเริ่มจากการสำรวจสถานะปัจจุบัน ค่าสำรวจสถานะปัจจุบัน 300,000 THB ที่เห็นในกรณีตัวอย่าง ก็คือค่าใช้จ่ายที่เกิดขึ้นในสภาพแบบนี้พอดี
ขอเสนอวิธีตรวจสอบชุด 4 อย่างในทางปฏิบัติหนึ่งวิธี ปีละครั้ง ให้ถามตัวเองว่า “ถ้าความสัมพันธ์กับผู้ขายจบลงวันนี้ จะส่งมอบงานให้ผู้ขายรายอื่นได้ภายใน 90 วันหรือไม่” ถ้ามีองค์ประกอบใดที่รู้สึกว่าส่งมอบไม่ได้ นั่นแหละคือรูปธรรมของการถูกผูกติดกับผู้ขาย เอกสารการออกแบบเก่าเกินไปหรือเปล่า ไม่รู้ความหมายของค่ารหัสใช่หรือไม่ หรือมีวิธีปฏิบัติงานที่มีเพียงคนบางคนเท่านั้นที่รู้ ให้ระบุออกมาให้ชัดเจน แล้วใช้เป็นวัตถุดิบต่อรองในการต่อสัญญาครั้งถัดไป
เส้นแบ่งระหว่างการทำเองกับการจ้างภายนอก
ถ้าจ้างภายนอกทั้งหมด ชั้น 3 จะบวม ถ้าทำเองทั้งหมด ระบบจะหยุดในวินาทีที่คนลาออก การวางเส้นแบ่งไว้ตรงไหนจึงเป็นหัวใจของการออกแบบ เส้นแบ่งที่ใช้ได้ผลในทางปฏิบัติคือ ให้การรับแจ้งขั้นต้นและการดูแลมาสเตอร์ทำเองในพื้นที่ ส่วนการรองรับการเปลี่ยนแปลงและการอัปเดตโครงสร้างพื้นฐานให้จ้างภายนอก
สิ่งที่ควรทำเองในพื้นที่ อย่างแรกคือการรับแจ้งขั้นต้น เป็นบทบาทของการรับเหตุการณ์ที่ส่งขึ้นมาจากหน้างาน แล้วลงมือแยกแยะอาการในก้าวแรก พูดให้เป็นรูปธรรมคือการแยกให้ออกว่า error นั้นเกิดกับคนเดียวหรือเกิดกับทุกคน เกิดเฉพาะบางหน้าจอหรือทุกฟังก์ชัน ก่อนหน้านั้นทำอะไรไว้ และเป็นปัญหาของเครือข่ายหรือของแอปพลิเคชัน การมีหรือไม่มีขั้นตอนนี้อยู่ในบริษัท จะเปลี่ยนจำนวนเรื่องที่ต้องโยนออกไปข้างนอกอย่างมาก ดังที่กล่าวไปแล้วว่าชั้น 3 คือค่าใช้จ่ายของการมีส่วนร่วมของคน เมื่อจำนวนเรื่องที่โยนออกไปลดลง ผลจึงเกิดขึ้นโดยตรง
อย่างที่สองคือการดูแลมาสเตอร์ ไม่ว่าจะเป็นสินค้า คู่ค้า ราคาต่อหน่วย ศูนย์งาน และสิทธิ์ การเพิ่มและการแก้ไขข้อมูลเหล่านี้เกิดขึ้นทุกวัน และถ้าจ้างภายนอก ก็จะเกิดการร้องขอและเวลารอคอยทีละรายการ หลักการคือจัดทำเอกสารกฎการลงทะเบียนมาสเตอร์ แล้วให้ผู้รับผิดชอบภายในบริษัทเป็นผู้ดำเนินการ แต่งาน “เปลี่ยนโครงสร้างของมาสเตอร์” เป็นอีกเรื่องหนึ่ง เพราะอยู่ในขอบเขตของการรองรับการเปลี่ยนแปลง เส้นแบ่งจึงเป็นแบบนี้ การลงทะเบียนข้อมูลหนึ่งรายการลงในมาสเตอร์สินค้าคือทำเอง ส่วนการเพิ่มคุณสมบัติหนึ่งคอลัมน์ให้มาสเตอร์สินค้าคือจ้างภายนอก
อย่างที่สามคือการตรวจสอบการทำงานประจำวัน ทั้งการตรวจด้วยตาว่าการสำรองข้อมูลจบสมบูรณ์หรือไม่ การตรวจความจุดิสก์ และการตรวจบันทึกข้อผิดพลาดของวันก่อนหน้า ตัวงานใช้เวลาราววันละ 10 นาที และถ้ามีคู่มือขั้นตอน พนักงานชาวไทยก็ทำได้
สิ่งที่ควรจ้างภายนอก คือการรองรับการเปลี่ยนแปลงและการอัปเดตโครงสร้างพื้นฐาน ทั้งการแก้ไขโปรแกรม การเปลี่ยนโครงสร้างฐานข้อมูล การอัปเวอร์ชันระบบปฏิบัติการและมิดเดิลแวร์ และการตัดสินใจติดตั้งแพตช์ความปลอดภัย งานเหล่านี้เกิดไม่บ่อย แต่ผลกระทบเมื่อล้มเหลวนั้นใหญ่ การที่ความถี่ต่ำหมายความว่าต่อให้ทำเองก็ไม่เกิดความชำนาญ แทนที่จะแบกงานที่ทำปีละ 2 ครั้งไว้ในบริษัท การยกให้ฝ่ายที่ทำงานนี้อยู่ทุกวันทำ ย่อมเร็วกว่าและปลอดภัยกว่า
เงื่อนไขที่ทำให้เส้นแบ่งนี้ทำงาน มีอยู่ 2 ข้อ ข้อแรกคือผู้รับผิดชอบฝั่งทำเองต้องไม่มีเพียงคนเดียว เพราะการเปลี่ยนงานเป็นเรื่องปกติในไทย จึงจำเป็นต้องปั้นคนที่รับแจ้งขั้นต้นได้ไว้อย่างน้อย 2 คน อีกข้อหนึ่งคือต้องกำหนดขอบเขตความรับผิดชอบของฝั่งทำเองและฝั่งจ้างภายนอกไว้เป็นลายลักษณ์อักษร เพราะเส้นแบ่งอย่าง “มาสเตอร์ทำเอง เปลี่ยนโครงสร้างให้ภายนอก” ถ้าตกลงกันด้วยปากเปล่าจะคลุมเครือแน่นอน ต้องกำหนดไปจนถึงว่าเมื่อเกิดเหตุการณ์ที่ตัดสินไม่ได้ว่าเป็นงานฝั่งไหน ใครจะเป็นคนตัดสิน
เมื่อใช้เส้นแบ่งนี้ ก็จะเห็นเหตุผลว่าทำไมชั้น 3 ของสัญญา B จึงอยู่ในระดับ 240,000 THB เพราะเมื่อแยกแยะอาการขั้นต้นได้ภายในบริษัทแล้ว ข้อมูลที่ส่งต่อออกไปภายนอกจะถูกจัดระเบียบมาแล้ว แรงงานฝั่งผู้ขายจึงลดลง การทำเองไม่ใช่การย้ายค่าใช้จ่ายเข้ามาไว้ในบริษัท แต่คือการลดปริมาณแรงงานโดยรวม
10 ข้อที่ต้องตกลงเป็นลายลักษณ์อักษรก่อนเซ็นสัญญา
ก่อนเข้าสู่การเจรจาต่อสัญญาหรือเปลี่ยนผู้ขาย ขอให้เขียน 10 ข้อต่อไปนี้ลงบนกระดาษ ทุกข้อเป็นหัวข้อที่ใช้งานไม่ได้ถ้าตกลงกันด้วยปากเปล่า
- ระบุขอบเขตของงานบำรุงรักษาให้ชัดด้วยการแบ่ง 4 หมวด คือการกู้คืน การรักษาสภาพ การเปลี่ยนแปลง และการต่อยอด โดยเฉพาะว่าการเปลี่ยนแปลงรวมอยู่ด้วยหรือไม่ ถ้ารวมอยู่ให้เขียนเป็นตัวเลขว่ากี่คนวันต่อปี
- เขียนเวลาให้บริการว่าเริ่มกี่โมงถึงกี่โมงตามเวลาไทย และยึดวันหยุดนักขัตฤกษ์ตามปฏิทินของประเทศใด
- ระบุให้ชัดว่าเวลาใน SLA คือเวลาตอบกลับหรือเวลากู้คืน และรับค่าเป้าหมายของเวลากู้คืนหรือค่ามัธยฐานของผลงานที่ผ่านมาเป็นลายลักษณ์อักษร
- แบ่งระดับความรุนแรงของเหตุขัดข้องออกเป็นราว 3 ระดับ และเขียนตัวอย่างเหตุการณ์ที่เข้าข่ายแต่ละระดับอย่างน้อยระดับละ 3 ตัวอย่าง
- เขียนภาษาที่รับแจ้งและช่องทางรับแจ้งแยกตามช่วงเวลา ว่าภาษาไทย ญี่ปุ่น หรืออังกฤษ ใช้ได้เมื่อใด
- เขียนโครงสร้างค่าบริการสำหรับนอกเวลาทำการและวันหยุด ว่าคิดต่อการเรียกหนึ่งครั้งหรือคิดเป็นอัตราต่อชั่วโมง และมีจำนวนชั่วโมงขั้นต่ำที่เรียกเก็บหรือไม่
- เขียนเรื่องโควตาแรงงานของการรองรับการเปลี่ยนแปลงว่าส่วนที่ใช้ไม่หมดจะยกยอดไปหรือหมดอายุ และถ้าเกินโควตาจะคิดอัตราต่อหน่วยเท่าไร
- เขียนชุด 4 อย่าง คือเอกสารการออกแบบ ซอร์สโค้ดหรือข้อมูลการตั้งค่า รูปแบบการส่งออกข้อมูล และขั้นตอนการส่งมอบงาน ไว้เป็นรายการสิ่งส่งมอบ
- ใส่การตรวจนับโครงสร้างและการปรับปรุงเอกสารข้อกำหนดปีละครั้งไว้ในสัญญา โดยระบุช่วงเวลาที่ดำเนินการและสิ่งส่งมอบ
- เขียนระยะเวลาส่งมอบงาน ปริมาณแรงงานในการส่งมอบงาน และการแบ่งภาระค่าใช้จ่ายเมื่อสัญญาสิ้นสุด ไว้เป็นข้อสัญญา
ลองนับดูว่าในสัญญาเดิมเขียนไว้ครบกี่ข้อจาก 10 ข้อนี้ ถ้าน้อยกว่า 5 ข้อ สัญญานั้นคุ้มค่าที่จะทบทวนโดยไม่เกี่ยวกับว่าค่ารายปีมากหรือน้อย โดยเฉพาะข้อที่ 3 ซึ่งว่าด้วยเวลาตอบกลับหรือเวลากู้คืน และข้อที่ 8 ซึ่งว่าด้วยชุด 4 อย่าง เป็นหัวข้อที่ความสูญเสียจากการไม่ได้เขียนไว้สูงที่สุด
ตัวงานเขียนเองก็มีความหมายเช่นกัน เพราะพอพยายามเติม 10 ข้อนี้ให้เต็ม จะเจอเรื่องที่ฝั่งบริษัทเรายังไม่ได้ตัดสินใจแน่นอน เช่น พอจะนิยามว่า “เหตุขัดข้องที่มีความรุนแรงสูงคืออะไร” ก็จะเกิดการถกเถียงภายในว่าระหว่างเหตุการณ์ที่ทำให้การส่งมอบหยุด กับเหตุการณ์ที่ทำให้การปิดบัญชีรายเดือนล่าช้า อย่างไหนหนักกว่ากัน การถกเรื่องนี้ให้จบก่อนเซ็นสัญญา จะทำให้การตัดสินใจตอนเกิดเหตุจริงเร็วขึ้น
5 รูปแบบความผิดพลาดที่พบบ่อย
ขอยก 5 ความผิดพลาดที่เห็นมาจริงในโรงงานญี่ปุ่นในประเทศไทย
ตัดสินใจจากการเทียบค่ารายปีอย่างเดียว เป็นรูปแบบที่พบมากที่สุด คือเอาใบเสนอราคาหลายเจ้ามาวางเรียง แล้วประเมินไล่จากค่ารายปีที่ถูกที่สุด เนื่องจากเป็นการเทียบสิ่งที่มีโครงสร้างชั้นต่างกันด้วยตัวเงินอย่างเดียว สัญญาที่ตัดชั้น 4 และชั้น 5 ออกจึงชนะเสมอ แล้วอีก 5 ปีต่อมาก็จะเกิดการพลิกอันดับแบบเดียวกับกรณีตัวอย่างในบทความนี้ ทางแก้คือให้ผู้ขายแยกใบเสนอราคาออกเป็นรายชั้น เพียงร้องขอว่า “รบกวนแจกแจงเป็นชั้น 1 ถึงชั้น 5” ก็จะได้รูปแบบที่เปรียบเทียบกันได้
ไม่มีใครติดตามวันหมดระยะการสนับสนุน วันหมดระยะการสนับสนุนของระบบปฏิบัติการและฐานข้อมูลถูกประกาศล่วงหน้าหลายปี ถึงอย่างนั้นก็ยังมีกรณีที่เพิ่งรู้ตัวก่อนกำหนด 3 เดือนแล้วต้องรับมือแบบฉุกเฉินอยู่ไม่ขาด การรับมือแบบฉุกเฉินทำให้อัตราค่าแรงงานสูงขึ้น และเมื่อไม่มีเวลาทดสอบ ความเสี่ยงของการสลับระบบก็สูงขึ้นด้วย ทางแก้คือทำตารางหนึ่งหน้ารวมวันหมดระยะการสนับสนุนของผลิตภัณฑ์ทั้งหมดที่ใช้งานอยู่ แล้วปรับปรุงทุกปี อีกวิธีคือเขียนในสัญญาให้ผู้ขายรับหน้าที่ติดตามเรื่องนี้
หยุดการปรับปรุงเอกสารข้อกำหนด เวลาตัดงบ สิ่งที่ถูกยกขึ้นมาเป็นตัวเลือกอันดับแรกคือค่าใช้จ่ายในการปรับปรุงเอกสาร หยุดไปแล้วครึ่งปีก็ยังไม่มีอะไรเกิดขึ้น ปัญหาจะโผล่ตอนที่ผู้รับผิดชอบเปลี่ยนคน และตอนที่คิดจะเปลี่ยนผู้ขาย ในกรณีตัวอย่าง การตัดสินใจนี้ย้อนกลับมาเป็นค่าสำรวจสถานะปัจจุบัน 300,000 THB ในปีที่ 4 คิดเสียว่าจะถูกเรียกเก็บย้อนหลังเป็นหลายเท่าของยอดที่ตัดไป จะใกล้เคียงความจริงมากกว่า
ไม่วางการรับแจ้งขั้นต้นไว้ในบริษัท คือการดำเนินงานแบบส่งต่อเหตุการณ์ที่ขึ้นมาจากหน้างานออกไปภายนอกทั้งดุ้น เมื่อไม่มีการแยกแยะอาการ ฝั่งผู้ขายจึงต้องเริ่มจากการตรวจสอบพื้นฐาน ทำให้มีการรับส่งไปมาเพิ่มขึ้นและการกู้คืนล่าช้า อีกทั้งจำนวนเรื่องก็ไม่ลดลง ชั้น 3 จึงบวม ทางแก้เป็นไปตามเส้นแบ่งในหัวข้อก่อนหน้า คือวางคนที่แยกแยะอาการขั้นต้นได้ไว้ในบริษัทอย่างน้อย 2 คน
ไม่เขียนเรื่องการสิ้นสุดสัญญาไว้ในสัญญา ตราบใดที่ความสัมพันธ์ยังดี ก็ไม่มีใครพูดเรื่องการสิ้นสุด แต่พอผ่านไป 5 ปีโดยไม่มีข้อสัญญาเรื่องการสิ้นสุด เมื่อคิดจะเปลี่ยนจริงกลับพบว่าในมือไม่มีเอกสารที่อธิบายความหมายของข้อมูลได้เลย ผลคือต้องล้มเลิกการเปลี่ยน และต้องใช้สัญญาเดิมต่อไปโดยไม่มีช่องว่างต่อรองเงื่อนไข ความผิดพลาดนี้ไม่ปรากฏเป็นตัวเงินบนตาราง จึงมองเห็นได้ยากที่สุด ขอให้เขียนวิธีจบเอาไว้ตั้งแต่วันที่เซ็นสัญญา
คำถามที่พบบ่อย
ค่าบำรุงรักษาระบบงานอยู่ที่ประมาณเท่าไร
ไม่มีสถิติปฐมภูมิ ค่าอ้างอิงที่พอมีคือ เว็บไซต์ช่วยจัดหาผู้พัฒนาระบบชื่อ System Kanji ซึ่งปรับปรุงข้อมูลเมื่อวันที่ 10 ตุลาคม 2025 ระบุค่าบำรุงรักษาโดยไม่รวมค่าจ้างบริการภายนอกไว้ที่ราว 5% ของค่าพัฒนา และราว 15% สำหรับระบบขนาดใหญ่ ส่วนค่าจ้างบริการภายนอกนั้น ระบุไว้ในฐานะระดับราคาภายในประเทศญี่ปุ่นที่ 200,000 JPY ถึง 500,000 JPY ต่อเดือน ซึ่งเป็นจำนวนเงินสกุลเงินเยน ไม่ใช่ THB อย่างไรก็ตาม นี่เป็นค่าประมาณที่ฝั่งผู้ให้บริการนำเสนอ ไม่ใช่ตัวเลขที่มาจากการสำรวจเชิงสถิติ ในกรณีตัวอย่างของบทความนี้ กำหนดให้สัญญา A อยู่ที่ 10.0% หรือ 450,000 THB และสัญญา B อยู่ที่ 18.0% หรือ 810,000 THB เมื่อเทียบกับค่าติดตั้งเริ่มต้น 4,500,000 THB ขอให้เปรียบเทียบว่าครอบคลุมตั้งแต่ชั้น 1 ถึงชั้น 5 ไปถึงไหน มากกว่าเปรียบเทียบด้วยอัตราส่วน
ควรทบทวนสัญญาบำรุงรักษาทุกกี่ปี
แทนที่จะยึดจำนวนปีของสัญญา ขอแนะนำให้แยกหน่วยของการทบทวนออกจากกัน ระดับของค่ารายปีให้ตรวจสอบทุกปี โครงสร้างชั้น ซึ่งหมายถึงว่าอะไรรวมอยู่และอะไรไม่รวมอยู่ ให้ทบทวนทุก 2 ถึง 3 ปี และในจังหวะที่ใกล้ถึงเวลาอัปเดตโครงสร้างพื้นฐาน นั่นคือเมื่อระบบปฏิบัติการหรือฐานข้อมูลใกล้หมดระยะการสนับสนุน ให้ทบทวนทั้งหมดในปีก่อนหน้านั้นเสมอ การหมุนสามวงจรนี้แยกกัน จะลดภาระของการต้องเจรจาใหม่ทั้งหมดในทุกครั้งที่ต่อสัญญา นอกจากนี้ ถ้าช่วงเวลาเปลี่ยนตัวผู้บริหารชาวญี่ปุ่นมาซ้อนกับการต่อสัญญา คุณภาพของการตัดสินใจจะลดลง จึงควรเลื่อนช่วงเวลาให้เหลื่อมกันหากทำได้
อยากลดค่ารายปี ควรตัดจากชั้นไหนก่อน
ลำดับที่ปลอดภัยที่สุดคือชั้น 1 หรือไลเซนส์ เพราะการตรวจนับไลเซนส์ที่ไม่ได้ใช้ทุกปีจะลดจำนวนลงได้โดยไม่กระทบงาน ถัดมาคือชั้น 2 ซึ่งยังมีช่องให้ลดลงได้ด้วยการย้ายจากออนพรีมิสไปคลาวด์หรือทบทวนวิธีสำรองข้อมูล ส่วนกรณีที่จะตัดชั้น 3 ขอให้ดำเนินการควบคู่ไปกับการวางการรับแจ้งขั้นต้นไว้ในบริษัท เพราะถ้าบีบเฉพาะช่วงเวลาให้บริการโดยไม่ลดจำนวนเรื่อง ผลจะย้อนกลับมาที่เวลาที่ระบบหยุด ส่วนการตัดชั้น 4 และชั้น 5 นั้นไม่แนะนำ ดังที่เห็นในกรณีตัวอย่าง ยอดที่ลดได้จากการถอดสองชั้นนี้ออก จะย้อนกลับมาในรูปของค่าใช้จ่ายนอกสัญญาและความสูญเสียจากการหยุดระบบ
การรองรับใบกำกับอิเล็กทรอนิกส์ของไทยรวมอยู่ในสัญญาบำรุงรักษาหรือไม่
ส่วนใหญ่ไม่รวมอยู่ ระบบ e-Tax Invoice และ e-Receipt ของไทย ณ ปี 2026 ยังเป็นการใช้งานแบบสมัครใจ และการบังคับใช้ใบกำกับอิเล็กทรอนิกส์สำหรับธุรกรรม B2B ยังไม่ได้ถูกบัญญัติเป็นกฎหมาย ดังนั้นภายใต้นิยาม “การแก้ไขอันเนื่องมาจากการแก้กฎหมาย” จึงอยู่นอกขอบเขต แต่หากถูกลูกค้าร้องขอให้รับส่งเอกสารในรูปแบบอิเล็กทรอนิกส์ ต่อให้ไม่มีข้อบังคับทางกฎหมายก็จำเป็นต้องรองรับ จุดชี้ขาดจึงอยู่ที่ว่าได้ขยายนิยามการรองรับการเปลี่ยนแปลงในสัญญาไปถึง “การแก้ไขอันเนื่องมาจากการแก้กฎหมายและข้อเรียกร้องของลูกค้ารายสำคัญ” หรือไม่ อนึ่ง มาตรการจูงใจในปัจจุบันคือการลงทุนในใบกำกับอิเล็กทรอนิกส์และการหักภาษี ณ ที่จ่ายแบบอิเล็กทรอนิกส์ นำมาหักเป็นรายจ่ายได้ 200% และมีอัตราภาษีหัก ณ ที่จ่ายพิเศษที่ 1% โดยในเดือนมิถุนายน 2026 คณะรัฐมนตรีได้อนุมัติการขยายเวลาไปจนถึงสิ้นปี 2027 แต่พระราชกฤษฎีกาและกฎกระทรวงยังไม่ได้ประกาศออกมา ส่วนผู้ประกอบการที่มียอดขายต่อปีไม่เกิน 30,000,000 THB สามารถใช้รูปแบบอย่างง่ายผ่านอีเมลได้
ถ้าเขียนว่า “ตอบสนองภายใน 4 ชั่วโมง” แปลว่าจะกู้คืนเสร็จใน 4 ชั่วโมงหรือไม่
ไม่ใช่ ข้อความนี้เกือบทั้งหมดหมายถึงเวลาตอบกลับ นั่นคือเวลาตั้งแต่รับแจ้งจนถึงการตอบกลับขั้นต้น สัญญาที่รับประกันเวลากู้คืน ซึ่งหมายถึงเวลาจนกว่าบริการจะกลับสู่สภาพที่ใช้งานได้ มีอยู่ไม่มาก เพราะในขั้นที่ยังไม่ทราบสาเหตุ ย่อมรับปากเวลากู้คืนไม่ได้ ในวงต่อสัญญา ขอให้ตรวจสอบจากตัวบทว่าเวลานั้นคือเวลาตอบกลับหรือเวลากู้คืน และสำหรับเวลากู้คืน ให้ขอรับค่าเป้าหมายเป็นลายลักษณ์อักษร โดยไม่ต้องเป็นการรับประกันก็ได้ หรือขอค่ามัธยฐานและค่าสูงสุดของผลงานที่ผ่านมา
อยากเปลี่ยนผู้ขาย ควรเริ่มตรวจสอบจากอะไร
เริ่มจากการตรวจสอบว่ามีอะไรเหลืออยู่ในมือบ้าง มีเอกสารการออกแบบที่สะท้อนสภาพ ณ ปัจจุบันหรือไม่ ซอร์สโค้ดหรือข้อมูลการตั้งค่าที่ปรับแต่งไว้ถูกเก็บรักษาไว้ในเวอร์ชันล่าสุดหรือไม่ ส่งออกข้อมูลทั้งหมดได้หรือไม่ และมีเอกสารนิยามรายการข้อมูลพร้อมตารางเทียบค่ารหัสหรือไม่ และในสัญญามีข้อกำหนดเรื่องการส่งมอบงานหรือไม่ ถ้าครบทั้ง 4 ข้อนี้ การเปลี่ยนผู้ขายก็เป็นไปได้จริง ถ้ายังไม่ครบ ผู้ขายรายถัดไปจะต้องเริ่มจากการสำรวจสถานะปัจจุบัน และจะเกิดค่าใช้จ่ายส่วนนั้นขึ้นมา การเจรจาให้ครบทั้ง 4 ข้อเสียก่อนในระหว่างที่ยังอยู่ในสัญญาเดิม แล้วค่อยเข้าสู่การพิจารณาเปลี่ยนผู้ขาย จะให้ผลที่ถูกกว่าในบั้นปลาย
ถ้าไม่มีเจ้าหน้าที่ฝ่ายระบบสารสนเทศในบริษัท จะดำเนินงานได้หรือไม่
ต่อให้ไม่มีคนประจำเต็มเวลา ถ้ามีคน 2 คนที่ทำการรับแจ้งขั้นต้นและการดูแลมาสเตอร์ได้ ก็หมุนงานไปได้ สิ่งที่ต้องการไม่ใช่ความรู้ด้านการพัฒนา แต่คือความสามารถในการแยกแยะเหตุการณ์และสื่อสารออกไปอย่างถูกต้อง ขอให้เลี่ยงโครงสร้างที่ฝากไว้กับคนเพียงคนเดียว เพราะการเปลี่ยนงานเป็นเรื่องปกติในไทย และการดำเนินงานจะหยุดทันทีในวินาทีที่คนคนนั้นลาออก ในการสำรวจของเจโทรเองก็มี “การขาดแคลนบุคลากรด้านดิจิทัล” ขึ้นเป็นอุปสรรคอันดับหนึ่งที่ 60.7% การจัดหาบุคลากรจึงไม่ใช่เงื่อนไขตั้งต้น แต่เป็นโจทย์ที่ต้องใส่ไว้ในการออกแบบว่าจะทำอย่างต่อเนื่อง
สรุป
ขอสรุปประเด็นสำคัญของบทความนี้
ค่าบำรุงรักษาคาดการณ์ไม่ได้ ไม่ใช่เพราะจำนวนเงินสูง แต่เพราะสัญญารับปากไว้เพียงว่า “ถ้าพังจะซ่อมให้” สิ่งที่โรงงานต้องการจริงคือ “ถ้าสภาพแวดล้อมเปลี่ยน จะแก้ให้” ซึ่งเนื้อหาของมันคือการแก้กฎหมาย ข้อเรียกร้องของลูกค้า การขยายมาสเตอร์เมื่อเพิ่มสาขา และการหมดระยะการสนับสนุนของระบบปฏิบัติการและฐานข้อมูล ส่วนต่างนี้ไม่ปรากฏในค่ารายปี แต่ปรากฏในยอดรวม 5 ปีและเวลาที่ระบบหยุด
งานบำรุงรักษาแบ่งได้เป็น 4 ประเภท คือการกู้คืน การรักษาสภาพ การเปลี่ยนแปลง และการต่อยอด สิ่งที่สัญญาบำรุงรักษารายปีทั่วไปครอบคลุมจริงมีเพียงการกู้คืนกับการรักษาสภาพบางส่วน คือ 1.5 ใน 4 ประเภท ส่วนค่าใช้จ่ายให้มองเป็น 5 ชั้น ได้แก่ ไลเซนส์ โครงสร้างพื้นฐาน การตอบสนองขั้นต้น การรองรับการเปลี่ยนแปลง และการรักษาองค์ความรู้ สิ่งที่ทำให้สัญญาต่างกันคือชั้น 3 ถึงชั้น 5 เท่านั้น นั่นคือส่วนที่มีคนเข้ามาเกี่ยวข้อง
ในการประมาณการของกรณีตัวอย่าง สัญญา A ที่ปีละ 450,000 THB ถูกกว่าสัญญา B ที่ปีละ 810,000 THB อยู่ 44% แต่เมื่อคิดยอดรวม 5 ปีซึ่งประกอบด้วยค่าสัญญา ค่าใช้จ่ายนอกสัญญา และความสูญเสียจากการหยุดระบบ กลับกลายเป็น 5,755,000 THB เทียบกับ 5,270,000 THB ทำให้สัญญา A แพงกว่าอยู่ 9.2% สาเหตุของการพลิกอันดับคือสัญญา A ผลักชั้น 4 ซึ่งเป็นการรองรับการเปลี่ยนแปลง และชั้น 5 ซึ่งเป็นการรักษาองค์ความรู้ ออกไปนอกค่าใช้จ่าย พร้อมกับทำให้ชั้น 3 ซึ่งเป็นการตอบสนองขั้นต้นบางลง เพราะตัดชั้น 4 ออก ทุกครั้งที่มีการเปลี่ยนแปลงจึงต้องเสนอราคารายครั้ง เพราะตัดชั้น 5 ออก จึงไม่รู้สถานะปัจจุบันจนเกิดค่าใช้จ่ายในการสำรวจ และเพราะทำให้ชั้น 3 บางลง งานนอกเวลาทำการจึงกลายเป็นการคิดตามค่าใช้จ่ายจริง อีกทั้งการแยกแยะอาการก็ช้าลงจนเวลาที่ระบบหยุดเพิ่มเป็น 3 เท่า ทั้งหมดนี้เป็นเพียงประมาณการของกรณีตัวอย่าง จำนวนเงินจะเปลี่ยนไปตามโครงสร้างและขอบเขตงาน สิ่งที่อยากให้ดูจึงไม่ใช่จำนวนเงิน แต่คือโครงสร้างว่าการตัดชั้นไหนออกจะย้อนกลับมาที่จุดใด
ในแง่วิธีอ่านสัญญา ขอให้ตรวจสอบให้แน่ชัดเสมอว่าเวลาใน SLA คือเวลาตอบกลับหรือเวลากู้คืน สำหรับฐานปฏิบัติการในไทย ต้องเขียนลงเป็นลายลักษณ์อักษรไปจนถึงนิยามของเวลาทำการ การยึดวันหยุดของประเทศใด เวลาที่ต่างจากสำนักงานใหญ่ในญี่ปุ่น 2 ชั่วโมง และภาษาที่รับแจ้งว่าจะเป็นภาษาไทย ญี่ปุ่น หรืออังกฤษ และถ้าไม่เขียนชุด 4 อย่าง คือเอกสารการออกแบบ ซอร์สโค้ดหรือข้อมูลการตั้งค่า รูปแบบการส่งออกข้อมูล และขั้นตอนกับระยะเวลาการส่งมอบงาน ไว้ในสัญญา พอสัญญาสิ้นสุดก็จะไม่เหลืออะไรอยู่ในมือ
สำหรับโครงสร้างการดำเนินงาน เส้นแบ่งที่ทำงานได้จริงคือให้การรับแจ้งขั้นต้นและการดูแลมาสเตอร์ทำเองในพื้นที่ ส่วนการรองรับการเปลี่ยนแปลงและการอัปเดตโครงสร้างพื้นฐานให้จ้างภายนอก และฝั่งที่ทำเองต้องมีคนไว้อย่างน้อย 2 คนเสมอ
ถ้าใกล้ถึงรอบต่อสัญญาบำรุงรักษาแล้ว ขอให้เริ่มจากการเอาสัญญาเดิมมาจับใส่ 4 หมวดและ 5 ชั้น แล้วดูว่าช่องไหนยังว่างอยู่ ถ้าช่องว่างอยู่ที่ชั้น 4 และชั้น 5 แปลว่าสัญญานั้นกำลังเอายอดรวมและเวลาที่ระบบหยุดของอีก 5 ปีข้างหน้าไปวางเป็นหลักประกัน เพื่อแลกกับค่ารายปีที่ถูกลง
หากอยู่ในขั้นที่เพียงอยากให้ช่วยดูว่าเนื้อหาสัญญาปัจจุบันเหมาะสมกับการดำเนินงานของบริษัทท่านหรือไม่ ก็ยินดีเช่นกัน TOMAS TECH ดูแลงานติดตั้งและบำรุงรักษาระบบงาน รวมถึงระบบบริหารการผลิต ให้แก่โรงงานญี่ปุ่นในประเทศไทย และรับปรึกษาทั้งการอ่านโครงสร้างชั้นของสัญญา และการจัดระเบียบโครงสร้างการดำเนินงานบนสมมติฐานว่าจะใช้สัญญากับผู้ขายรายเดิมต่อไป เรายินดีรับปรึกษาแม้ในขั้นที่ยังไม่ได้คิดจะเปลี่ยนผู้ขาย เพียงแต่อยากจัดระเบียบสถานะปัจจุบันก่อน ติดต่อได้ที่หน้าติดต่อเรา
แหล่งข้อมูลอ้างอิง
- สมาคมผู้ใช้ระบบสารสนเทศแห่งญี่ปุ่น (JUAS) — รายงานการสำรวจแนวโน้ม IT ขององค์กร ฉบับปี 2026 (เมษายน 2026)
- สมาคมผู้ใช้ระบบสารสนเทศแห่งญี่ปุ่น (JUAS) — หน้าแนะนำการสำรวจแนวโน้ม IT ขององค์กร (การสำรวจปีงบประมาณ 2025)
- องค์การส่งเสริมการค้าต่างประเทศของญี่ปุ่น (เจโทร) — การสำรวจสภาพจริงของบริษัทญี่ปุ่นที่ลงทุนในต่างประเทศ ปีงบประมาณ 2025 ฉบับเอเชียและโอเชียเนีย (การสำรวจปีงบประมาณ 2025)
- องค์การส่งเสริมการค้าต่างประเทศของญี่ปุ่น (เจโทร) — เอกสารแถลงข่าวของการสำรวจฉบับเดียวกัน (การสำรวจปีงบประมาณ 2025)
- VATupdate — ความเคลื่อนไหวล่าสุดของใบกำกับอิเล็กทรอนิกส์ในประเทศไทย (กรกฎาคม 2026)
- System Kanji — ราคาตลาดของค่าบำรุงรักษาในการพัฒนาระบบ (ปรับปรุงเดือนตุลาคม 2025)