เหตุใดการเปลี่ยนระบบ Legacy ทั้งหมดจึงล้มเหลวในภาครัฐ (และอะไรคือทางออกที่ได้ผลจริง)

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

“เปลี่ยนระบบเดิมใหม่ทั้งหมด”

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

---

เหตุใดหน่วยงานรัฐจึงพยายามเปลี่ยนระบบ Legacy

ในมุมมองเบื้องต้น การเปลี่ยนระบบทั้งหมดดูเป็นเรื่องสมเหตุสมผล:

• ระบบเดิมดูแลรักษายาก
• ผู้พัฒนาหรือผู้ขายอาจเลิกสนับสนุน
• บุคลากรที่มีทักษะกำลังลดลง
• ประชาชนคาดหวังบริการดิจิทัลที่ทันสมัย

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

---

เหตุใดการเปลี่ยนระบบจึงล้มเหลวในบริบทภาครัฐไทย

1. ระบบ Legacy เป็นระบบสำคัญตามกฎหมายไทย

ระบบภาครัฐจำนวนมาก:

• ต้องทำงานต่อเนื่องตลอดเวลา
• รองรับภารกิจตามกฎหมายหรือระเบียบราชการ
• ไม่สามารถหยุดให้บริการได้

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

---

2. องค์ความรู้เชิงสถาบันฝังอยู่ในระบบและองค์กร

ระบบ Legacy มักสะท้อน:

• การตัดสินใจเชิงนโยบายที่สั่งสมมาหลายทศวรรษ
• ข้อยกเว้น วิธีแก้ปัญหาเฉพาะหน้า และกรณีขอบ
• การตีความกฎหมายและระเบียบปฏิบัติ

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

---

3. ระบบจัดซื้อจัดจ้างและงบประมาณของไทยไม่สอดคล้องกับธรรมชาติของซอฟต์แวร์

กระบวนการจัดซื้อจัดจ้างของภาครัฐไทยโดยทั่วไป:

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

ในขณะที่การพัฒนาซอฟต์แวร์สมัยใหม่ต้องอาศัยการเรียนรู้ การทดลอง และการปรับปรุงอย่างต่อเนื่อง โครงการเปลี่ยนระบบทั้งหมดจึงขัดแย้งกับความเป็นจริงนี้ตั้งแต่เริ่มต้น

---

4. ความเสี่ยงทางการเมืองและการตรวจสอบไม่สมดุล

สำหรับผู้บริหารและผู้มีอำนาจตัดสินใจ:

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

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

---

5. การเปลี่ยนระบบแบบ Big-Bang แทบไม่เคยได้ผลในหน่วยงานหลายฝ่าย

การเปลี่ยนทุกอย่างพร้อมกันหมายถึง:

• การย้ายข้อมูลขนาดใหญ่
• การฝึกอบรมผู้ใช้งานทั้งหมดในเวลาเดียวกัน
• การเปลี่ยนกระบวนการทำงานข้ามหลายหน่วยงาน

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

---

อะไรที่ได้ผลแทน: การปรับปรุงระบบโดยไม่ต้องเปลี่ยนทั้งหมด (แนวทางที่เหมาะกับประเทศไทย)

สถาปัตยกรรมอ้างอิง: ปรับปรุงโดยไม่รื้อระบบเดิม

flowchart TB
    Citizens["ประชาชน / ภาคธุรกิจ"]
    Channels["ช่องทางดิจิทัล
(เว็บ / มือถือ / พอร์ทัล)"]
    Gateway["API Gateway / ชั้นบูรณาการระบบ"]
    Workflow["Workflow และ Case Management"]
    Data["แบบจำลองข้อมูลกลาง
(Master Data)"]
    Legacy["ระบบแกนหลักเดิม
(Mainframe / ERP / Registry)"]

    Citizens --> Channels
    Channels --> Gateway
    Gateway --> Workflow
    Workflow --> Data
    Data --> Legacy

    Gateway --> Legacy

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

---

แนวคิดหลัก: ปรับปรุงระบบโดยไม่สร้างความสะดุด

ทางเลือกไม่ใช่การหยุดนิ่ง แต่คือการ พัฒนาโดยไม่รบกวนภารกิจหลัก

---

1. เพิ่มชั้นดิจิทัล แทนการเขียนระบบแกนใหม่

แทนที่จะเปลี่ยนระบบ Legacy หน่วยงานสามารถ:

• รักษาระบบแกนหลักให้ทำงานต่อไป
• เพิ่มชั้นบูรณาการด้านบน
• เปิดการใช้งานผ่าน API

แนวทางนี้ช่วยให้ระบบใหม่ถูกพัฒนาได้โดยไม่กระทบเสถียรภาพของระบบเดิม

แนวคิดสำคัญ: เปลี่ยนวิธีที่ระบบสื่อสารกัน ก่อนเปลี่ยนวิธีทำงานภายใน

---

2. เปลี่ยนระบบแบบค่อยเป็นค่อยไป ให้สอดคล้องกับรอบงบประมาณ

ฟังก์ชันใหม่ควร:

• พัฒนานอกระบบเดิม
• ค่อย ๆ ย้ายภาระงานออกจากระบบเก่า
• เปลี่ยนทีละโมดูลตามเวลา

แนวทางนี้ช่วยลดความเสี่ยงและเปิดโอกาสให้เรียนรู้ระหว่างทาง

---

3. มาตรฐานข้อมูลต้องมาก่อนอินเทอร์เฟซ

หน้าจออาจดึงดูดความสนใจ แต่ข้อมูลคือสิ่งที่สร้างความยั่งยืน

สิ่งที่ควรให้ความสำคัญ ได้แก่:

• คำจำกัดความข้อมูลกลางร่วมกัน
• ความชัดเจนของเจ้าของข้อมูลหลัก
• กฎการตรวจสอบข้อมูลที่สอดคล้องกัน

เมื่อข้อมูลมีมาตรฐาน ระบบหลายชุดสามารถอยู่ร่วมและพัฒนาไปพร้อมกันได้อย่างปลอดภัย

---

4. มองระบบ Legacy เป็นบริการ ไม่ใช่อุปสรรค

ระบบเดิมสามารถ:

• ถูกห่อหุ้ม (wrap)
• แยกขอบเขต
• เฝ้าติดตาม
• ลดความซับซ้อนลงทีละขั้น

เมื่อมองระบบ Legacy เป็นบริการหนึ่งในระบบนิเวศ จะไม่กลายเป็นตัวถ่วงการพัฒนาอีกต่อไป

---

เป้าหมายที่สมจริงกว่าสำหรับ GovTech ไทย

เป้าหมายของการเปลี่ยนผ่านดิจิทัลภาครัฐไม่ควรเป็น:

“เปลี่ยนระบบเก่าให้หมด”

แต่ควรเป็น:

“ทำให้ระบบสามารถพัฒนาและปรับตัวได้”

ระบบที่ปรับตัวได้:

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

---

บทสรุป

ระบบ Legacy จะกลายเป็นปัญหา ก็ต่อเมื่อเรามองมันเป็นศัตรู ในความเป็นจริง ระบบเหล่านี้คือบันทึกขององค์ความรู้เชิงสถาบันและความต่อเนื่องของภารกิจรัฐ

การพัฒนา GovTech ที่ประสบความสำเร็จในประเทศไทย คือการเคารพความเป็นจริงนี้ และปรับการเปลี่ยนแปลงทางเทคโนโลยีให้สอดคล้องกับกฎหมาย ระเบียบจัดซื้อจัดจ้าง และความต่อเนื่องในระยะยาว โดยเน้นสถาปัตยกรรม การบูรณาการ และการเปลี่ยนแปลงอย่างค่อยเป็นค่อยไป

การเปลี่ยนทุกอย่างพร้อมกันอาจดูยิ่งใหญ่

แต่การทำให้ระบบพัฒนาได้ คือสิ่งที่ได้ผลจริง