คุณเคยเปิดระบบลงทะเบียนออนไลน์ของหน่วยงานรัฐแล้วพบหน้าจอ error ไหม? หรือต้องกด "รีเฟรช" ซ้ำหลายรอบเพราะระบบค้าง? หรือไปพบว่าบริการออนไลน์ที่มีอยู่ยังต้องพิมพ์แบบฟอร์มแล้วส่งทางไปรษณีย์อยู่ดี? ประสบการณ์เหล่านี้ไม่ได้เกิดจากความบังเอิญ — มันเป็นอาการของปัญหาเชิงระบบที่ฝังรากลึกในกระบวนการพัฒนาและจัดซื้อจัดจ้าง IT ภาครัฐไทยมายาวนาน

ไทยลงทุน IT ภาครัฐเท่าไหร่ — และได้อะไรกลับมา?

ในช่วงหลายปีที่ผ่านมา ไทยทุ่มงบประมาณด้านดิจิทัลภาครัฐอย่างต่อเนื่อง สำนักงานพัฒนารัฐบาลดิจิทัล (DGA) รายงานงบประมาณด้าน IT ภาครัฐในระดับหลายหมื่นล้านบาทต่อปี โครงการ e-Government ถูกผลักดันมาตั้งแต่ยุค Thailand 4.0 และต่อเนื่องสู่ไทยแลนด์ดิจิทัล อย่างไรก็ตาม ดัชนี UN E-Government Development Index (EGDI) ปี 2024 วางไทยอยู่ในกลุ่ม "High" แต่ยังล้าหลังประเทศอาเซียนอย่างสิงคโปร์และมาเลเซียอย่างมีนัยสำคัญ

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

6 สาเหตุหลักที่ทำให้โครงการ Government IT ล้มเหลว

อินโฟกราฟิก 6 สาเหตุหลักที่ทำให้โครงการ IT ภาครัฐในไทยล้มเหลว: spec ไม่ชัด, จัดซื้อเน้นราคาต่ำสุด, ขาด technical ownership, vendor lock-in, ไม่มี UAT จริง และไม่มีงบ maintenance
6 สาเหตุเชิงระบบ — ไม่ใช่ปัญหาของคนใดคนหนึ่ง แต่เป็นปัญหาของกระบวนการ

1. Spec ไม่ชัด และเปลี่ยนแปลงระหว่างทาง

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

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

2. การจัดซื้อจัดจ้างเน้นราคาต่ำสุด (Lowest Price Wins)

กระบวนการจัดซื้อจัดจ้างตาม พ.ร.บ. การจัดซื้อจัดจ้างและการบริหารพัสดุภาครัฐ พ.ศ. 2560 ให้น้ำหนักกับราคาเป็นหลัก แม้จะมีช่องทางประเมินคุณภาพด้านเทคนิค แต่ในทางปฏิบัติหน่วยงานจำนวนมากยังใช้วิธี "ราคาต่ำสุด" เพื่อลดความเสี่ยงทางการตรวจสอบ

ผลลัพธ์คือ vendor ที่ชนะการประมูลมักต้องตัดทอนคุณภาพเพื่อให้กำไรอยู่รอด ทั้งในแง่ของจำนวน developer, ระดับประสบการณ์ของทีม และคุณภาพ testing ก่อน deploy

3. ขาด Technical Ownership ฝั่งภาครัฐ

หน่วยงานรัฐส่วนใหญ่ไม่มี product owner หรือ technical lead ที่สามารถตัดสินใจด้านเทคนิคได้ เจ้าหน้าที่ IT ภาครัฐมักถูกวางบทบาทเป็น "ผู้ประสานงาน" มากกว่า "เจ้าของผลิตภัณฑ์" ทำให้การตัดสินใจสำคัญ เช่น architecture, security model, หรือ trade-off ระหว่าง feature ต้องรอผ่านหลายชั้น

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

4. Vendor Lock-in และ Source Code ไม่ได้คืน

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

"ระบบที่ไม่มีเจ้าของ code คือระบบที่ขึ้นอยู่กับ vendor ตลอดไป — และ vendor รู้ดีกว่าใครว่านั่นหมายความว่าอะไรในการต่อสัญญาครั้งถัดไป"

นอกจากนี้ การใช้ proprietary platform หรือ license ที่ผูกกับ vendor เฉพาะรายยิ่งทำให้ต้นทุนการเปลี่ยนสูงขึ้นทุกปี ระบบเก่าที่ถูก lock จึงค่อย ๆ กลายเป็น legacy system ที่แก้ไขและดูแลได้ยากขึ้นเรื่อย ๆ

5. ไม่มี UAT จริง — ผู้ใช้ไม่ได้มีส่วนร่วม

User Acceptance Testing (UAT) ในหลายโครงการเป็นเพียงพิธีกรรมบนกระดาษ เจ้าหน้าที่ที่ลงนามรับงานมักไม่ใช่คนที่ใช้ระบบจริงในชีวิตประจำวัน และ timeline ที่กระชับทำให้ไม่มีเวลาสำหรับการทดสอบในสถานการณ์จริงอย่างเพียงพอ

ผู้ใช้ปลายทาง — ทั้งเจ้าหน้าที่และประชาชน — มักไม่ได้รับการสัมภาษณ์หรือทดสอบระบบก่อน deploy ทำให้ปัญหา usability ร้ายแรงที่สามารถพบได้ใน sprint แรกกลับถูกค้นพบหลัง go-live ซึ่งแก้ไขได้ยากและแพงกว่าหลายเท่า

6. Maintenance หลัง Go-Live ไม่มีงบ

งบประมาณโครงการ IT ภาครัฐมักถูกจัดสรรเป็น "งบลงทุน" (CAPEX) ในปีเดียว แต่ค่าใช้จ่ายในการดูแลรักษาระบบระยะยาวเป็น "งบดำเนินงาน" (OPEX) ที่ต้องขอใหม่ทุกปี กระบวนการนี้ทำให้หลังจาก go-live ระบบมักไม่ได้รับการ update ด้าน security, bug fix, หรือ feature improvement ที่ตอบสนองต่อการเปลี่ยนแปลงของกฎหมายหรือความต้องการผู้ใช้

ระบบที่ดีในวันแรก จึงกลายเป็นระบบล้าสมัยและไม่ปลอดภัยภายใน 2–3 ปี โดยไม่มีแผนงบประมาณรองรับ การวาง SLA และ managed operations ตั้งแต่วันแรกจึงสำคัญไม่น้อยกว่าการพัฒนาตัวระบบเอง

กรณีศึกษาสมมติ: โครงการ "ระบบขอใบอนุญาตออนไลน์" ของหน่วยงาน X

หมายเหตุ: กรณีนี้เป็นสถานการณ์สมมติที่รวบรวมจากรูปแบบที่พบบ่อยในโครงการภาครัฐ ไม่ได้อ้างอิงโครงการใดโครงการหนึ่งโดยเฉพาะ

หน่วยงาน X ได้รับงบประมาณ 12 ล้านบาทสำหรับพัฒนาระบบขอใบอนุญาตประกอบการออนไลน์ โดยมีเป้าหมายลดเวลาดำเนินการจาก 30 วันเหลือ 7 วัน

สิ่งที่เกิดขึ้น:

  • TOR ถูกเขียนขึ้นในเวลา 2 สัปดาห์ โดยไม่มีการสัมภาษณ์เจ้าหน้าที่ผู้ใช้จริง
  • vendor ที่ชนะเสนอราคาต่ำกว่าคู่แข่ง 40% โดยใช้ทีมพัฒนา 3 คน
  • ระหว่างโครงการ มีการเพิ่ม requirement 11 รายการโดยไม่ปรับ scope หรือ timeline
  • UAT ดำเนินการใน 3 วัน โดยเจ้าหน้าที่ระดับบริหาร ไม่ใช่เจ้าหน้าที่หน้างาน
  • หลัง go-live 6 เดือน พบว่า 60% ของผู้ขอใบอนุญาตยังคงมาติดต่อด้วยตนเองเพราะระบบออนไลน์ "ใช้งานยาก"
  • ไม่มีงบ maintenance ปีถัดไป ระบบไม่ได้รับ update ใด ๆ นาน 18 เดือน

สิ่งที่เรียนรู้: ปัญหาทุกข้อในกรณีนี้สามารถป้องกันได้ด้วยกระบวนการที่ถูกต้องตั้งแต่ต้น ไม่ใช่ด้วยงบที่มากกว่า

แนวทางที่ควรเปลี่ยน

ปรับกระบวนการจัดซื้อจัดจ้าง

เปลี่ยนจาก "ราคาต่ำสุด" เป็นการประเมินแบบ Quality-Price Ratio โดยให้น้ำหนักคะแนนเทคนิคไม่น้อยกว่า 60% ให้ความสำคัญกับ portfolio ของ vendor และประสบการณ์จริงในโครงการที่คล้ายกัน รวมถึงกำหนดให้ vendor นำเสนอ prototype หรือ proof-of-concept ก่อนเซ็นสัญญาเต็มรูปแบบ

นำ Agile Delivery มาใช้อย่างจริงจัง

แบ่งโครงการออกเป็น milestone ที่วัดผลได้จริง ไม่ใช่แค่ "ส่งมอบระบบ" ในวันเดียว กำหนดให้มี sprint review ทุก 2–4 สัปดาห์ และให้ผู้ใช้จริงเข้าร่วม testing ตั้งแต่ต้น การจ่ายเงินตาม milestone ที่ผ่าน UAT จริงจะสร้างแรงจูงใจให้ vendor ทำงานอย่างมีคุณภาพมากกว่าการจ่ายตาม timeline

กำหนด SLA และ Maintenance ในสัญญาตั้งแต่วันแรก

สัญญาทุกฉบับควรระบุ SLA อย่างน้อย 2–3 ปีหลัง go-live รวมถึง response time สำหรับ critical bug, security patch, และ uptime guarantee พร้อมบทลงโทษที่ชัดเจน งบ maintenance ควรถูกวางแผนและจัดสรรพร้อมกับงบพัฒนา ไม่ใช่ค่อยมาคิดภายหลัง บริการ DevOps / SRE managed operations ที่ออกแบบมาเพื่อความต่อเนื่องระยะยาวจึงควรเป็นส่วนหนึ่งของสัญญาตั้งแต่ต้น

UNIXDEV ทำงานกับหน่วยงานภาครัฐและองค์กรขนาดใหญ่มาตั้งแต่ปี 2013 รูปแบบสัญญาที่เราแนะนำลูกค้ารวมถึงการส่งมอบ source code ทั้งหมด, documentation ระดับ developer, และแผน knowledge transfer ให้ทีม IT ของลูกค้าสามารถดูแลระบบต่อได้เองโดยไม่ต้องพึ่งพาเราตลอดไป

Checklist: สิ่งที่หน่วยงานรัฐควรถามก่อนเซ็นสัญญา

อินโฟกราฟิก checklist 5 หมวดที่หน่วยงานรัฐควรถามก่อนเซ็นสัญญาพัฒนาระบบ IT: requirement และ scope, vendor และทีมงาน, source code และ IP, testing และ go-live และ maintenance และ SLA
5 หมวดคำถาม due diligence ก่อนลงนามในสัญญาพัฒนาระบบ IT ภาครัฐ

ก่อนลงนามในสัญญาพัฒนาระบบ IT ใด ๆ หน่วยงานควรตรวจสอบว่าได้คำตอบที่ชัดเจนสำหรับทุกข้อด้านล่างนี้แล้ว:

ด้าน Requirement และ Scope

  • มีการสัมภาษณ์ผู้ใช้จริง (ทั้งเจ้าหน้าที่และประชาชน) ก่อนเขียน TOR หรือไม่?
  • Requirement ทุกข้อมีเกณฑ์วัดผล (Acceptance Criteria) ที่ชัดเจนหรือไม่?
  • มีกระบวนการที่ชัดเจนสำหรับ change request กลางทางหรือไม่?

ด้าน Vendor และทีมงาน

  • vendor มี portfolio งานคล้ายกันที่สามารถตรวจสอบได้หรือไม่?
  • ทีมที่จะทำงานจริงคือทีมที่นำเสนอในข้อเสนอหรือไม่?
  • vendor มีประกันภัยความรับผิดชอบวิชาชีพ (Professional Indemnity Insurance) หรือไม่?

ด้าน Source Code และ IP

  • สัญญาระบุชัดว่า source code ทั้งหมดเป็นทรัพย์สินของหน่วยงานภาครัฐหรือไม่?
  • จะได้รับ repository access, documentation และ deployment scripts ทั้งหมดหรือไม่?
  • มี escrow agreement หรือข้อกำหนดสำรองสำหรับกรณี vendor ปิดกิจการหรือไม่?

ด้าน Testing และ Go-Live

  • UAT จะดำเนินการโดยใคร และมีกำหนดเวลาเพียงพอหรือไม่ (ขั้นต่ำ 2–4 สัปดาห์)?
  • มีแผน pilot กับผู้ใช้จริงก่อน full rollout หรือไม่?
  • มีแผน rollback ในกรณีที่ระบบมีปัญหาหลัง go-live หรือไม่?

ด้าน Maintenance และ SLA

  • สัญญากำหนด SLA สำหรับ uptime, response time และ security patch หรือไม่?
  • มีงบ maintenance วางแผนไว้อย่างน้อย 3 ปีหลัง go-live หรือไม่?
  • มีแผน knowledge transfer ให้ทีม IT ภาครัฐสามารถดูแลระบบต่อได้หรือไม่?

สรุป

ปัญหาของ Government IT ในไทยไม่ได้เกิดจากความขาดแคลนงบประมาณ และไม่ได้เกิดจากความล้มเหลวของ "คน" ใดคนหนึ่ง แต่เกิดจาก ระบบและกระบวนการ ที่ออกแบบมาเพื่อลดความเสี่ยงทางการตรวจสอบ ไม่ใช่เพื่อให้ได้ซอฟต์แวร์ที่ดี

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

โครงการที่ดีสามารถทำได้ภายในงบประมาณที่มีอยู่ — สิ่งที่ต้องเปลี่ยนคือวิธีคิดและกระบวนการ

พร้อมเริ่มต้นโครงการ IT ภาครัฐที่ทำได้จริง?

UNIXDEV มีประสบการณ์กับโครงการภาครัฐและองค์กรขนาดใหญ่กว่า 71 แห่ง ภายใต้มาตรฐาน ISO 9001:2015 และ ISO/IEC 29110 เราพร้อมให้คำปรึกษาตั้งแต่ขั้นตอน requirement analysis, เลือก architecture ที่เหมาะสม ไปจนถึงการวางแผน SLA และ maintenance ระยะยาว ดูบริการทั้งหมดได้ที่หน้า บริการของเรา หรือ ติดต่อทีมงาน เพื่อพูดคุยเบื้องต้น

ขอ Proposal โครงการ IT ภาครัฐ →

บทความโดย UNIXDEV Team · Craft code · Ship systems · Scale impact
ISO 9001:2015 · ISO/IEC 29110-4-1:2018 · ก่อตั้งปี 2013 · unixdev.co.th