เหตุใดโครงการซอฟต์แวร์ภาครัฐจึงล้มเหลว — และจะป้องกันได้อย่างไรก่อนเริ่มเขียนโค้ด

บทนำ: ความล้มเหลวไม่ใช่ปัญหาทางเทคโนโลยี

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

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

งบประมาณถูกใช้ไป ระบบถูกส่งมอบ แต่สิ่งที่เกิดขึ้นคือ

เจ้าหน้าที่ยังคงกลับไปใช้ Excel
ประชาชนยังต้องมาติดต่อที่เคาน์เตอร์
ข้อมูลซ้ำซ้อนระหว่างหน่วยงาน
การเชื่อมโยงระบบไม่เกิดขึ้นจริง

ความจริงที่มักถูกมองข้ามคือ

โครงการซอฟต์แวร์ภาครัฐส่วนใหญ่ล้มเหลว ตั้งแต่ก่อนมีการเขียนโค้ดแม้แต่บรรทัดเดียว

5 สาเหตุหลักที่โครงการซอฟต์แวร์ภาครัฐล้มเหลว

1. เริ่มต้นที่เทคโนโลยี แทนที่จะเริ่มจากปัญหา

หลายโครงการเริ่มต้นด้วยแนวคิดว่า

“ต้องการระบบอัจฉริยะ”
“ต้องมีแอปพลิเคชันมือถือ”
“ควรใช้ AI / คลาวด์ / บล็อกเชน”

แต่ไม่ได้เริ่มจากคำถามว่า

การตัดสินใจใดควรถูกปรับปรุง
งานใดถูกทำซ้ำอยู่ในปัจจุบัน
ข้อมูลใดมาถึงช้าเกินไป

การเลือกเทคโนโลยีโดยไม่กำหนดโจทย์ที่ชัดเจน มักนำไปสู่ความผิดหวังเสมอ

2. ข้อกำหนดถูกเขียนเพื่อการจัดซื้อ ไม่ใช่เพื่อการใช้งานจริง

เอกสารข้อกำหนดของโครงการภาครัฐมักมีลักษณะ

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

ผลลัพธ์ที่เกิดขึ้นคือ

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

ระบบที่ตรงตามเอกสาร แต่ไม่ตรงกับการทำงานจริง ยังคงถือเป็นระบบที่ล้มเหลว

3. มองข้ามหรือประเมินระบบเดิมต่ำเกินไป

องค์กรปกครองส่วนท้องถิ่นในประเทศไทยส่วนใหญ่มีระบบเดิมอยู่แล้ว เช่น

ระบบการเงิน
ระบบบุคลากร
ฐานข้อมูลทะเบียน
ระบบ GIS หรือรายงาน

โครงการใหม่มักสมมติว่า ระบบเหล่านี้สามารถ

ถูกแทนที่ได้ง่าย
ย้ายข้อมูลได้โดยไม่มีปัญหา
หรือไม่จำเป็นต้องคำนึงถึง

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

4. วัดความสำเร็จจาก “การส่งมอบ” ไม่ใช่ “การใช้งานจริง”

หลายโครงการถูกสรุปว่าสำเร็จเมื่อ

ระบบถูกติดตั้ง
มีการอบรมผู้ใช้งาน
มีการลงนามรับมอบงาน

แต่ความสำเร็จที่แท้จริงควรถามว่า

เจ้าหน้าที่ยังใช้งานอยู่หลัง 6 เดือนหรือไม่
งานเอกสารถูกลดลงจริงหรือไม่
การตัดสินใจดีขึ้นหรือรวดเร็วขึ้นหรือไม่

หากไม่มีการใช้งานจริง การส่งมอบย่อมไม่มีความหมาย

5. ไม่มีเจ้าของระบบหลังเปิดใช้งาน

ในหลายโครงการภาครัฐของไทย ความรับผิดชอบของระบบจะไม่ชัดเจนหลังงบประมาณสิ้นสุดหรือมีการโยกย้ายบุคลากร

หลังจากระบบเปิดใช้งาน

ผู้รับจ้างยุติบทบาท
ทีมโครงการยุบตัว
ความรู้เกี่ยวกับระบบสูญหาย

หากขาด

ผู้รับผิดชอบที่ชัดเจน
เอกสารระบบ
แผนบำรุงรักษาระยะยาว

ระบบจะค่อย ๆ เสื่อมสภาพ จนต้องเริ่มโครงการใหม่อีกครั้ง

การป้องกันความล้มเหลว ก่อนเริ่มเขียนโค้ด

flowchart TB
  subgraph Current_State["สภาพปัจจุบัน (ที่พบได้บ่อย)"]
    Citizens["ประชาชน / ภาคธุรกิจ"] --> Channels["ช่องทางบริการ
(เคาน์เตอร์ / โทรศัพท์ / เว็บ)"]
    Channels --> Forms["แบบฟอร์มและการกรอกข้อมูลด้วยมือ"]
    Forms --> DeptApps["ระบบของแต่ละหน่วยงาน
(การเงิน / บุคคล / ทะเบียน / GIS)"]
    DeptApps --> Excel["ไฟล์ Excel และกระบวนงานนอกระบบ"]
    Excel --> Reports["รายงานล่าช้าและข้อมูลซ้ำซ้อน"]
  end

  Current_State -->|"ไม่มีการออกแบบการเชื่อมโยง"| Pain["ภาระงานสูง
การใช้งานต่ำ และต้องแก้ไขซ้ำ"]

  subgraph Target_State["สภาพเป้าหมาย (ออกแบบตามความเป็นจริง)"]
    Citizens2["ประชาชน / ภาคธุรกิจ"] --> Channels2["ช่องทางบริการที่สอดคล้องกัน
(เคาน์เตอร์ / โทรศัพท์ / เว็บ)"]
    Channels2 --> Case["ชั้นงานบริการ / เวิร์กโฟลว์
(กระบวนการมาตรฐาน)"]
    Case --> API["ชั้นการเชื่อมโยงระบบ
(API / ข้อความ)"]
    API --> Core["ระบบหลักเดิม
(การเงิน / บุคคล / ทะเบียน / GIS)"]
    API --> Data["โครงสร้างข้อมูลร่วม
และธรรมาภิบาลข้อมูล"]
    Data --> Dash["รายงานและร่องรอยการตรวจสอบที่ทันเวลา"]
  end

  Pain --> Principles["หลักการออกแบบเชิงป้องกัน
(เริ่มจากการตัดสินใจ, ทำความเข้าใจเวิร์กโฟลว์,
ทดสอบด้วย POC, และการดูแลระยะยาว)"]
  Principles --> Target_State