ต้นทุนทิพย์ในสูตรราคาน้ำมันและในงบไอที: ตรวจค่าสมมุติที่ไม่เคยเทียบกับของจริง

วันที่ 28 ตุลาคม 2026 รัฐมนตรีว่าการกระทรวงพลังงานลงนามคำสั่งถอดค่าใช้จ่ายสามรายการออกจากสูตรคำนวณราคาน้ำมันหน้าโรงกลั่น ได้แก่ ค่าขนส่ง ค่าประกันภัย และค่าสูญเสียระหว่างขนส่ง ซึ่งตามที่กระทรวงแถลง คิดจากสมมติฐานว่าน้ำมันถูกขนส่งมาจากสิงคโปร์ และอยู่ในสูตรมาตั้งแต่ปี 2547 คำสั่งนี้มีผลวันที่ 29 ตุลาคม 2026

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

เกิดอะไรขึ้นกับสูตรราคาน้ำมัน และเราอ่านถึงไหน

ตามที่ Thai PBS และ The Standard รายงานเมื่อ 28 ตุลาคม 2026 โดยอ้างแถลงของกระทรวงพลังงาน คำสั่งนี้ยกเลิกค่าขนส่ง ค่าประกันภัย และค่าสูญเสียระหว่างขนส่งที่คิดจากเส้นทางสมมุติ ลดค่าสำรองน้ำมันเหลือสองในสามของเดิมให้สอดคล้องกับปริมาณสำรองจริง และประเมินว่าราคาหน้าโรงกลั่นจะลดลง 0.0875–0.3548 บาทต่อลิตร โดยดีเซล B7 ลดมากที่สุดที่ 0.3548 บาทต่อลิตร ทั้งนี้ราคาหน้าโรงกลั่นตามนิยามของ สนพ. คือราคาน้ำมันสำเร็จรูปที่ยังไม่ได้รวมภาษี กองทุน และค่าการตลาด

เราต้องบอกตรง ๆ ว่าตัวเลขเหล่านี้เป็นคำของกระทรวงที่สื่อรายงานซ้ำ เรายังไม่ได้เห็นตัวคำสั่งหรือมติ กบง. ที่เป็นเอกสารทางการ สื่อที่เราอ่านไม่ได้อธิบายวิธีนับ 22 ปี และไม่ได้ให้สัดส่วนว่าน้ำมันกลั่นในประเทศเท่าใด การลดที่ว่าเป็นราคาหน้าโรงกลั่น ไม่ใช่ราคาหน้าปั๊ม The Standard ระบุว่ากระทรวงจะหารือกับกองทุนน้ำมันเรื่องการส่งผ่านไปยังราคาปลีก โดยยังไม่มีกรอบเวลา เรายืนยันไม่ได้ว่าราคาปลีกจะลดเท่าใด นอกจากนี้ผู้แทนสภาองค์กรของผู้บริโภคเสนอว่ายังมีรายการอื่นที่ควรตรวจสอบเพิ่ม ซึ่งเป็นความเห็นของเขา (สภาองค์กรของผู้บริโภค) เราจึงไม่ใช้บทความนี้ตัดสินเรื่องพลังงาน และใช้ข้อเท็จจริงข้างต้นเพียงเป็นตัวอย่างของรูปแบบเท่านั้น

ค่าสมมุติในงบไอทีหน้าตาเป็นอย่างไร

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

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

• ความจุที่จองไว้บน Cloud ตามพีคที่คาดไว้ ซึ่งไม่เคยกลับไปเทียบกับพีคที่เกิดขึ้นจริง

• เงินสำรองของโครงการ ที่ตั้งเป็นสัดส่วนคงที่ของมูลค่างาน โดยไม่ผูกกับความเสี่ยงจริงของงานนั้น

• ค่าบำรุงรักษารายปี ที่คิดเป็นสัดส่วนของราคาซอฟต์แวร์ ไม่ได้คิดจากงานที่ผู้ให้บริการทำจริง

• พื้นที่เก็บข้อมูลหรือสำรองข้อมูล ที่คำนวณจากอัตราการโตที่สมมุติไว้ตั้งแต่วันออกแบบ

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

ทำไมค่าสมมุติอยู่ได้นานกว่าที่คิด

จากที่เห็น ค่าสมมุติอยู่ยาวด้วยสี่เหตุผล

• ตอนตั้งมีเหตุผล สมมติฐานที่ใช้อ้างอิงตลาดหรือมาตรฐานของวันนั้นอาจถูกต้อง เราไม่ได้ตรวจประวัติของสูตรน้ำมัน จึงไม่ขอบอกว่าตอนตั้งไม่สมเหตุสมผล

• มันอยู่ในสูตรที่ไม่มีใครเปิด ตัวเลขสุดท้ายผ่านการอนุมัติแล้ว คนที่เห็นมีแต่ยอดรวม ไม่ได้เห็นส่วนประกอบ

• ไม่มีเจ้าของคำถาม ว่ายังจริงไหม ทุกคนรับผิดชอบการใช้ตัวเลข แต่ไม่มีใครรับผิดชอบการทบทวนตัวเลข

• ตัวเลขข้างเคียงสอดคล้องกัน งบรวมไม่เกิน ใบเสนอราคาเทียบกันได้ ไม่มีสัญญาณเตือนอะไรที่ทำให้ใครต้องเปิดสูตร

เหตุผลที่สามสำคัญที่สุดในความเห็นของเรา เพราะเมื่อมีเจ้าของคำถาม สามเหตุผลที่เหลือแก้ได้เกือบหมด

วิธีตรวจ: ทะเบียนสมมติฐาน

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

• ชื่อบรรทัดและยอดที่จ่ายต่อปี

• สมมติฐานที่อยู่เบื้องหลัง เช่น จำนวนผู้ใช้ พีค อัตราการโต

• สมมติฐานนั้นมาจากไหน ใครตั้ง เมื่อไร

• ค่าจริงล่าสุดที่วัดได้ และวัดจากอะไร

• ช่องว่างระหว่างสมมติฐานกับค่าจริง

• เจ้าของที่ต้องตอบ และวันที่จะทบทวนครั้งต่อไป

ช่องที่สี่คือช่องที่หลายองค์กรเติมไม่ได้ เพราะไม่มีใครเคยวัด ซึ่งก็เป็นข้อมูลที่มีค่าในตัวมันเอง แปลว่าบรรทัดนั้นยังเป็นค่าสมมติล้วน ๆ ไม่มีของจริงมายืนยัน ความจุที่จองไว้บน Cloud เป็นตัวอย่างที่ตรวจง่าย เพราะระบบ monitoring เก็บค่าการใช้จริงอยู่แล้ว วิธีวางแผนความจุที่อ้างอิงพีคจริงอยู่ในบทความเรื่อง capacity planning

ตัวอย่างการตรวจหนึ่งบรรทัด

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

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

2. ขอรายงานการใช้งานจากระบบของผู้ให้บริการ หรือดึงจากระบบ identity ขององค์กรเอง ให้ได้จำนวนผู้ใช้ที่ใช้งานจริงในรอบล่าสุด

3. เทียบสองตัวเลข ถ้าใกล้กัน สมมติฐานยังใช้ได้ ถ้าห่างกันมาก ให้ตรวจว่าเกิดจากบัญชีที่ไม่มีเจ้าของ พนักงานที่ออกไปแล้ว หรือการใช้งานที่ลดลงจริง

4. นำผลไปคุยกับผู้ให้บริการก่อนรอบต่ออายุ โดยมีตัวเลขจริงและวิธีที่ได้มาอยู่ในมือ

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

สัญญาณเตือนว่ามีค่าสมมุติซ่อนอยู่

เมื่อไม่มีเวลาไล่ทุกบรรทัด เราใช้สัญญาณเหล่านี้คัดว่าบรรทัดไหนควรตรวจก่อน

• ตัวเลขกลมผิดปกติ และไม่เปลี่ยนเลยตลอดหลายรอบสัญญา ทั้งที่ธุรกิจเปลี่ยน

• ไม่มีใครในทีมอธิบายได้ว่าตัวเลขมาจากไหน นอกจากคำว่าเป็นมาตรฐาน หรือทำกันมาแบบนี้

• ผู้ขายแสดงสูตรหรือที่มาของตัวเลขไม่ได้ แต่ยอดรวมถูกเสนอเป็นก้อนเดียว

• บรรทัดนั้นคิดเป็นสัดส่วนของบรรทัดอื่น ไม่ได้คิดจากปริมาณงานหรือการใช้งานที่วัดได้

• ระบบวัดผลที่องค์กรมีอยู่ไม่เคยถูกใช้เทียบกับบรรทัดนั้นเลย

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

เขียนสัญญาให้ปรับตามค่าจริงได้

เมื่อรู้ว่าบรรทัดไหนเป็นสมมติฐาน คำถามถัดไปคือสัญญาเปิดทางให้ปรับหรือไม่ เรามองสามเรื่องที่ควรอยู่ในสัญญา ซึ่งเป็นข้อเสนอของเรา ไม่ใช่ข้อบังคับของกฎหมาย

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

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

• วันทบทวนที่เขียนไว้ ไม่ปล่อยให้เป็นคำสัญญาปากเปล่า

แนวทางเขียนเงื่อนไขทำนองนี้ เราเขียนไว้ในบทความเรื่องเงื่อนไขใน TOR และเรื่องการอ่านสัญญาดูแลระบบรายปีอยู่ในบทความเรื่องสัญญา MA และ SLA

เมื่อค่าสมมุติถูกถอดออก อย่าตัดทุกอย่าง

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

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

ข้อจำกัดที่ต้องบอกตรง ๆ

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

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

ข้อโต้แย้งที่ได้ยินบ่อย

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

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

จะเริ่มตรงไหน

1. เลือกสามบรรทัดที่เป็นเงินก้อนใหญ่ที่สุด ในงบไอทีหรือสัญญาที่จ่ายต่อเนื่อง

2. ถามว่าแต่ละบรรทัดมาจากสมมติฐานอะไร และใครเป็นคนตั้งเมื่อไร

3. หาค่าจริงมาเทียบ จากระบบ monitoring ใบเสร็จผู้ให้บริการ หรือรายงานการใช้งาน

4. ระบุเจ้าของและวันทบทวน ของแต่ละบรรทัด เป็นชื่อคนและวันที่ ไม่ใช่ชื่อแผนก

5. ใส่เงื่อนไขปรับตามค่าจริงและสิทธิตรวจสอบ ในสัญญาฉบับถัดไปที่ต่ออายุ

สรุป

ถ้าจะหยิบไปใช้อย่างเดียวจากบทความนี้ ให้เลือกบรรทัดที่ใหญ่ที่สุดในงบไอทีหนึ่งบรรทัด แล้วถามว่าตัวเลขนี้มาจากสมมติฐานอะไร และมีใครเทียบมันกับของจริงล่าสุดเมื่อไร ถ้าไม่มีใครตอบได้ บรรทัดนั้นคือจุดเริ่มต้นของการตรวจ

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