การออกแบบการให้บริการดิจิทัลสำหรับหน่วยงานภาครัฐหลายกรม (บริบทประเทศไทย)

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

บทความนี้นำเสนอแนวคิดเชิงระบบ (systems thinking) สำหรับการออกแบบ Digital Service Delivery ที่เหมาะกับบริบทภาครัฐไทย โดยเน้นการใช้งานได้จริง มากกว่าการเปลี่ยนเทคโนโลยีตามกระแส

---

1. ปัญหาหลักของระบบดิจิทัลภาครัฐไทย: แยกส่วนโดยโครงสร้าง

หน่วยงานรัฐไทยส่วนใหญ่พัฒนาระบบตามโครงสร้างราชการ:

• งบประมาณแยกตามกรม/โครงการ
• ผู้รับจ้างพัฒนาระบบคนละราย
• ฐานข้อมูลและมาตรฐานไม่เหมือนกัน
• ระดับความพร้อมด้านดิจิทัลไม่เท่ากัน

ผลลัพธ์ที่พบได้บ่อย:

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

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

---

2. เปลี่ยนหน่วยออกแบบ: จาก “กรม” เป็น “บริการประชาชน”

หัวใจสำคัญของ GovTech คือการเปลี่ยนคำถาม

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

แทนที่จะถามว่า:

• “กรมนี้ต้องการระบบอะไร”

ให้ถามว่า:

• “ประชาชนหรือผู้ประกอบการต้องผ่านขั้นตอนอะไรบ้าง”

ตัวอย่าง: การขอใบอนุญาตประกอบกิจการ

ในบริบทไทย บริการเดียวอาจเกี่ยวข้องกับ:

• อบต./เทศบาล/อบจ.
• กรมสรรพากร
• หน่วยงานสิ่งแวดล้อม
• หน่วยงานแรงงานหรือสาธารณสุข

แต่สำหรับประชาชน นี่คือ บริการเดียว ไม่ใช่หลายกรม

---

3. หลักการออกแบบ Digital Service สำหรับภาครัฐไทย

3.1 โครงสร้างพื้นฐานดิจิทัลร่วม (Shared Digital Foundations)

ควรมีบริการกลางที่ทุกหน่วยงานใช้ร่วมกัน เช่น:

• ระบบยืนยันตัวตน (เชื่อม NDID / Digital ID)
• ระบบแจ้งเตือน (SMS, Email, LINE OA)
• ระบบชำระเงิน (e-Payment ภาครัฐ)
• ระบบเอกสารและลายเซ็นดิจิทัล
• ระบบบันทึกประวัติและตรวจสอบ (Audit log)

สิ่งเหล่านี้ควรเป็น platform กลาง ไม่ใช่พัฒนาแยกในแต่ละโครงการ

---

3.2 แยกบทบาทให้ชัด: นโยบาย vs ระบบบริการ

สถาปัตยกรรมที่เหมาะสมควรแยก:

• กฎ ระเบียบ และเงื่อนไข (เจ้าของคือหน่วยงาน)
• การประสานงานบริการ (Workflow) ระหว่างหน่วยงาน
• ระบบปฏิบัติการเดิม (legacy / vendor system)

แนวทางนี้ช่วยให้:

• หน่วยงานยังควบคุมอำนาจตามกฎหมาย
• แต่บริการประชาชนทำงานแบบ end-to-end ได้

---

3.3 เชื่อมระบบก่อน แทนที่จะรื้อทั้งหมด

ในความเป็นจริง ระบบเดิมของรัฐ:

• มีสัญญาอยู่
• ไม่สามารถเปลี่ยนทันที
• บางระบบยังจำเป็น

แนวทางที่เหมาะสม:

• ใช้ API / Adapter / Message Queue
• ค่อย ๆ เชื่อมทีละบริการ
• ยอมรับการอยู่ร่วมกันของระบบเก่าและใหม่

ความคืบหน้าที่ต่อเนื่อง สำคัญกว่าความสมบูรณ์แบบ

---

3.4 ตัวอย่าง Python Libraries ที่ใช้ได้จริงในโครงการ GovTech ไทย

ชุดเครื่องมือด้านล่างเป็น Python-based stack ที่พบว่าเหมาะกับบริบทภาครัฐไทย ทั้งด้านเสถียรภาพและการดูแลระยะยาว

API และระบบบริการ

• FastAPI + Uvicorn/Gunicorn
• Django (เหมาะกับ back-office และ workflow เจ้าหน้าที่)

ข้อมูลและฐานข้อมูล

• PostgreSQL + psycopg / asyncpg
• SQLAlchemy + Alembic

การเชื่อมต่อระบบอื่น (Integration)

• httpx + tenacity (เรียก API หน่วยงานอื่นอย่างทนทาน)
• Celery + Redis/RabbitMQ (งานเบื้องหลัง)

Workflow ระยะยาว (เหมาะกับบริการข้ามกรม)

• Temporal Python SDK (ลดปัญหา job ค้าง / ข้อมูลตกหล่น)

ความมั่นคงปลอดภัยและตรวจสอบ

• Authlib, python-jose, cryptography
• jsonschema (บังคับมาตรฐานข้อมูล)

การติดตามและตรวจสอบระบบ

• OpenTelemetry + Prometheus
• structlog / loguru

ข้อสังเกต: โครงการรัฐที่ล้มเหลวมักไม่ได้ล้มเพราะโค้ด แต่ล้มเพราะไม่มี observability และมาตรฐานข้อมูลร่วม

---

4. สถาปัตยกรรมอ้างอิง (แนวคิด)

ประชาชน / ผู้ประกอบการ
        |
        v
+---------------------+
| Government Service  |
| Portal (Web/Mobile) |
+---------------------+
        |
        v
+-----------------------------+
| Service Orchestration Layer |
| - Workflow                  |
| - Rules / Policy            |
| - Status Tracking           |
+-----------------------------+
        |
        +-------------+-------------+-------------+
        |             |             |
        v             v             v
+------------+ +--------------+ +---------------+
| กรม A      | | กรม B        | | ระบบภายนอก   |
| (Legacy)   | | (Modern)     | | / Vendor      |
+------------+ +--------------+ +---------------+

แนวคิดสำคัญ:

• หน่วยงานเชื่อมระบบ ครั้งเดียว
• บริการสามารถนำไปใช้ซ้ำได้หลายกรณี

---

5. ธรรมาภิบาล (Governance) สำคัญกว่าการเขียนโค้ด

ระบบจะยั่งยืนได้ ต้องมีการกำหนด:

• เจ้าของข้อมูล (Data ownership)
• มาตรฐาน API และข้อมูลกลาง
• กระบวนการเปลี่ยนแปลงกฎระเบียบ
• งบประมาณสำหรับ platform กลาง

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

• ออกแบบสถาปัตยกรรม
• ดูแล platform
• ควบคุมคุณภาพการเชื่อมระบบ

---

6. โมเดลการพัฒนาที่เหมาะกับราชการไทย

หลีกเลี่ยงโครงการแบบ Big Bang

แนวทางที่ได้ผล:

1. เลือกบริการที่ประชาชนใช้บ่อย
2. เชื่อมเฉพาะระบบที่จำเป็น
3. เห็นผลภายใน 3–6 เดือน
4. ใช้ซ้ำกับบริการถัดไป

ความเชื่อมั่นเกิดจาก ผลงานที่ใช้งานได้จริง ไม่ใช่เอกสารยุทธศาสตร์

---

7. ตัวชี้วัดความสำเร็จที่เหมาะสม

• จำนวนขั้นตอนที่ลดลง
• เวลาที่ประชาชนประหยัดได้
• การใช้ข้อมูลร่วมกันระหว่างหน่วยงาน
• ค่าใช้จ่ายซ้ำซ้อนที่ลดลง

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

---

8. บทสรุป

Digital Service Delivery สำหรับภาครัฐไทย เป็นโจทย์ การออกแบบระบบราชการให้ทำงานร่วมกันได้ ไม่ใช่แค่โจทย์ IT

แนวทางที่พิสูจน์แล้ว:

• คิดจากบริการ ไม่ใช่โครงสร้าง
• มี platform กลางที่ใช้ร่วมกัน
• เชื่อมระบบก่อนรื้อระบบ
• มีกลไกกำกับดูแลที่ชัด แต่ไม่เทอะทะ

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