เชื่อมระบบใหม่กับระบบเดิมของหน่วยงานรัฐ: รูปแบบข้อมูลและรอบ Security Review

ลองนึกภาพสถานการณ์สมมติ ทีมพัฒนาระบบใหม่ทีมหนึ่งวางแผนงานเชื่อมต่อกับระบบทะเบียนเดิมของหน่วยงานไว้ 2 สัปดาห์ในผังโครงการ ระบบเดิมใช้งานมากว่าสิบปี คนที่เขียนมันไว้ลาออกไปแล้ว เอกสาร API ที่เหลืออยู่คือไฟล์ Word หน้าเดียวที่อัปเดตล่าสุดเมื่อสี่ปีก่อน ในสภาพแบบนี้ งานส่วนนี้อาจกินเวลาไปกว่าสองเดือน เพราะทีมต้องไล่อ่าน field ทีละตัวจากตัวอย่างข้อมูลจริง แล้วยังต้องรอคิวตรวจสอบความปลอดภัยก่อนขอสิทธิ์เข้าถึงระบบจริงอีกรอบหนึ่ง

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

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

รูปแบบข้อมูลที่มักไม่ตรงกัน: ตัวอย่างที่เจอบ่อย

ระบบเดิมของหน่วยงานจำนวนมากไม่มีเอกสาร API ที่เป็นทางการ สิ่งที่มีคือความรู้ในหัวของคนที่เคยดูแลระบบ หรือเอกสารที่เขียนไว้ตอนเริ่มโครงการแล้วไม่เคยอัปเดตตามโค้ดที่เปลี่ยนไป ปัญหาที่ตามมาคือ field mapping ไม่ตรงกัน เช่น ระบบเดิมเก็บเลขบัตรประชาชนเป็น string ปนขีด ส่วนระบบใหม่ต้องการเป็นตัวเลขล้วน หรือรหัสสถานะที่ระบบเดิมใช้เลข 1-5 แต่ไม่มีเอกสารอธิบายว่าแต่ละเลขหมายถึงอะไร ทีมต้องเดาจากข้อมูลตัวอย่างแล้วค่อยถามคนที่ยังจำได้

ปัญหาที่พบบ่อยไม่แพ้กันคือเรื่องการเข้ารหัสตัวอักษร ระบบราชการเก่าบางระบบยังเก็บข้อมูลภาษาไทยด้วยชุดอักขระ TIS-620 ขณะที่ระบบใหม่ทำงานบน UTF-8 เป็นค่าเริ่มต้น ถ้าไม่แปลงให้ถูกต้องระหว่างทาง ชื่อ-นามสกุลภาษาไทยจะกลายเป็นอักขระแปลกปลอมทันที รูปแบบวันที่ก็เป็นอีกจุดที่พลาดกันบ่อย ระบบเดิมอาจเก็บเป็นปี พ.ศ. แบบเลขสี่หลักหรือสองหลัก ส่วนระบบใหม่ต้องการปี ค.ศ. ตามมาตรฐาน ISO 8601 ถ้าทีมไม่ตกลงเรื่องนี้ล่วงหน้า ข้อมูลวันเกิดหรือวันที่อนุมัติจะคลาดเคลื่อนไปหลายสิบหรือหลายร้อยปีโดยไม่มีใครสังเกตจนกว่าจะมีคนร้องเรียน

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

นี่คือจุดที่แผนงานส่วนใหญ่พลาด

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

Batch File กับ Real-time API: เลือกแบบไหน แลกอะไร

เมื่อระบบเดิมไม่มี API ที่พร้อมใช้ ทางเลือกที่เหลือมักเป็นการแลกเปลี่ยนไฟล์แบบ batch เช่น ส่งไฟล์ CSV หรือ fixed-width ผ่าน SFTP ตามรอบเวลาที่ตกลงกัน วิธีนี้พัฒนาเร็วกว่า ทดสอบง่ายกว่า และไม่ต้องเปิดช่องทางเชื่อมต่อแบบ real-time เข้าสู่ระบบเดิมที่อาจไม่ได้ออกแบบมาให้รับโหลดต่อเนื่อง แต่ข้อมูลจะไม่ทันเวลา ถ้าธุรกรรมต้องอัปเดตสถานะทันที เช่น การอนุมัติคำขอที่ผู้ใช้รอผลอยู่หน้าจอ วิธีนี้ใช้ไม่ได้ นอกจากนี้ยังต้องออกแบบขั้นตอน reconciliation คือการตรวจว่าไฟล์ที่ส่งไปครบและตรงกับที่ปลายทางรับจริง เผื่อกรณีไฟล์ขาดหาย ส่งซ้ำ หรือรูปแบบไฟล์เปลี่ยนโดยไม่แจ้งล่วงหน้า

Real-time API ให้ข้อมูลที่ทันเวลากว่า แต่ต้องมีคนดูแลระบบเดิมที่พร้อมเปิด endpoint ใหม่ ต้องมีการยืนยันตัวตนและจำกัดสิทธิ์ที่รัดกุมกว่า และมักต้องผ่านรอบตรวจสอบความปลอดภัยที่เข้มกว่า batch เพราะเป็นช่องทางที่เปิดค้างไว้ตลอดเวลา ไม่ใช่การส่งไฟล์เป็นรอบที่ปิดช่องทางได้ทันทีหลังโอนเสร็จ บางหน่วยงานยังอาจกำหนดให้การเชื่อมต่อแบบนี้ต้องผ่านโครงข่ายเฉพาะ เช่น MPLS หรือ VPN แบบจุดต่อจุด แทนที่จะเปิดผ่านอินเทอร์เน็ตสาธารณะ ซึ่งเพิ่มขั้นตอนการจัดหาและอนุมัติงบประมาณเข้าไปอีกชั้นหนึ่งที่ทีมพัฒนามักไม่ได้นึกถึงตั้งแต่แรก การเลือกระหว่างสองแบบนี้จึงไม่ใช่แค่เรื่องเทคนิค แต่เป็นการแลกระหว่างความเร็วของข้อมูลกับความเร็วของการอนุมัติให้เชื่อมต่อ

มาตรฐานแลกเปลี่ยนข้อมูลที่หน่วยงานรัฐกำหนดไว้

สำนักงานพัฒนารัฐบาลดิจิทัล (DGA) วางกรอบมาตรฐานที่เรียกว่า TGIX (Thailand Government Information Exchange) ไว้สำหรับการเชื่อมโยงและแลกเปลี่ยนข้อมูลระหว่างหน่วยงานรัฐ กรอบนี้แบ่งเป็นสองส่วนหลัก คือมาตรฐานด้านการเชื่อมต่อ (Linkage Standards) ที่ว่าด้วยสถาปัตยกรรมและช่องทางเชื่อมต่อ กับมาตรฐานด้านความหมายของข้อมูล (Semantic Standards) ที่ว่าด้วยนิยามและโครงสร้างของข้อมูลที่แลกเปลี่ยนกัน (ที่มา: DGA, เข้าถึง 2026-09-29) นอกจากนี้ตาม พ.ร.บ. การบริหารงานและการให้บริการภาครัฐผ่านระบบดิจิทัล พ.ศ. 2562 หน่วยงานรัฐมีหน้าที่ต้องเชื่อมโยงและแลกเปลี่ยนข้อมูลดิจิทัลที่ตนจัดทำและครอบครองตามที่หน่วยงานรัฐอื่นร้องขอ (มาตรา 13) ทีมที่ทำงานกับหน่วยงานรัฐจึงควรถามตั้งแต่ต้นว่าโครงการนี้ต้องอ้างอิงมาตรฐาน TGIX ด้วยหรือไม่ เพราะถ้าใช่ การออกแบบโครงสร้างข้อมูลต้องคำนึงถึงรูปแบบที่ DGA กำหนดไว้ ไม่ใช่ออกแบบตามความสะดวกของระบบใหม่ฝ่ายเดียว

หน่วยงานจำนวนมากเชื่อมต่อผ่านศูนย์แลกเปลี่ยนข้อมูลกลางที่เรียกว่า GDX (Government Data Exchange) ซึ่งทำหน้าที่เป็นประตูเชื่อมระหว่างระบบของผู้ขอข้อมูลกับระบบของเจ้าของข้อมูล โดยไม่ได้เก็บข้อมูลไว้ที่ตัวเอง (ที่มา: DGA GDX, เข้าถึง 2026-09-29) ถ้าโครงการของคุณต้องเชื่อมกับหน่วยงานรัฐ ควรถามตั้งแต่ต้นว่าการเชื่อมต่อจะผ่าน GDX หรือเชื่อมตรงกับระบบเดิม เพราะสองเส้นทางนี้อาจมีขั้นตอนอนุมัติและผู้อนุมัติต่างกัน

รอบตรวจสอบความปลอดภัย: ขั้นตอนที่กินเวลาแต่มักไม่อยู่ใน timeline

ก่อนได้สิทธิ์เข้าถึงระบบจริงของหน่วยงาน โครงการส่วนใหญ่ต้องผ่านการตรวจสอบด้านความปลอดภัยของทีม IT Security ภายในหน่วยงานนั้นเอง ซึ่งเป็นคนละขั้นตอนกับมาตรฐานและแพลตฟอร์มกลางอย่าง TGIX หรือ GDX ขั้นตอนนี้มักรวมการตรวจสอบ source code การสแกนช่องโหว่ การขออนุมัติเปิด firewall เฉพาะจุด และบางครั้งต้องมีเอกสารยืนยันว่าระบบใหม่ปฏิบัติตามมาตรฐานการแลกเปลี่ยนข้อมูลที่หน่วยงานกำหนด บางหน่วยงานยังกำหนดให้มีการเซ็น NDA แยกต่างหากสำหรับทีมที่จะเข้าถึงข้อมูล และกำหนดระดับชั้นความลับของข้อมูลที่ขอเชื่อมต่อ ซึ่งส่งผลต่อว่าใครในทีมมีสิทธิ์เห็นข้อมูลจริงได้บ้าง

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

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

ถ้าระบบเดิมมีเอกสารครบและมาตรฐานชัดอยู่แล้ว

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

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

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

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

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

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

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

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

• ตกลงรูปแบบการแลกเปลี่ยนข้อมูล (batch หรือ real-time) การเข้ารหัสตัวอักษร รูปแบบวันที่ และ field mapping ให้เป็นเอกสารที่ทั้งสองฝ่ายเซ็นรับรู้ตรงกัน ก่อนเริ่มเขียนโค้ดเชื่อมต่อจริง

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

สรุป

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

ทีม Superdev พัฒนาระบบมาตรฐาน Enterprise บน Google Cloud และ Microsoft Azure และอยู่เบื้องหลังโปรเจ็กต์ขององค์กรขนาดใหญ่ทั้งภาครัฐและเอกชน

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