การเชื่อมต่อ ERP กับระบบอื่น — API, Integration, และสิ่งที่ต้องรู้

ทำไมต้องเชื่อมต่อ ERP กับระบบอื่น?

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

• ลดการกรอกข้อมูลซ้ำ: ข้อมูลไหลจากระบบหนึ่งไปอีกระบบโดยอัตโนมัติ
• ลดความผิดพลาด: ไม่ต้องพิมพ์ซ้ำ = ไม่ผิดพลาดจากการพิมพ์
• ข้อมูล Real-time: ผู้บริหารเห็นข้อมูลล่าสุดจากทุกระบบในที่เดียว
• ประหยัดเวลา: งานที่เคยใช้เวลา 2 ชั่วโมง เหลือ 2 นาที

ระบบที่มักต้องเชื่อมต่อกับ ERP

ระบบ	วัตถุประสงค์	ประเภทการเชื่อมต่อ	ความยาก
GFMIS	ส่งข้อมูลการเงินภาครัฐ	File-based (Export Layout)	ปานกลาง
e-GP (จัดซื้อจัดจ้าง)	ส่งข้อมูลจัดซื้อจัดจ้าง	File-based / API	ปานกลาง
DPIS (บุคลากร)	ข้อมูลพนักงาน/ข้าราชการ	File-based (CSV)	ต่ำ
e-Saraban (สารบรรณ)	เชื่อมเอกสารราชการ	API / Web Service	ปานกลาง-สูง
ธนาคาร	โอนเงิน, Statement, Reconcile	File-based / API	สูง
e-Tax	ส่งข้อมูลภาษีอิเล็กทรอนิกส์	API / XML	ปานกลาง
e-Payment	รับ-จ่ายเงินอิเล็กทรอนิกส์	API (RESTful)	สูง

3 วิธีเชื่อมต่อระบบ

วิธีที่ 1: API (Application Programming Interface)

การเชื่อมต่อผ่าน API เป็นวิธีที่ทันสมัยและยืดหยุ่นที่สุด ระบบส่งและรับข้อมูลผ่าน HTTP/HTTPS แบบ Real-time

• ข้อดี: Real-time, ยืดหยุ่น, รองรับข้อมูลหลากหลายรูปแบบ, ปลอดภัย (HTTPS + Authentication)
• ข้อเสีย: ต้องมีทีม Developer, ระบบปลายทางต้องมี API ให้เรียก, ต้องดูแล Error Handling
• เหมาะกับ: ระบบที่ต้องการข้อมูล Real-time เช่น e-Payment, ระบบธนาคาร

วิธีที่ 2: File-based (ไฟล์ CSV / XML)

ระบบ ERP Export ข้อมูลเป็นไฟล์ CSV หรือ XML ตาม Layout ที่กำหนด แล้วระบบปลายทาง Import ไฟล์นั้นเข้าไป

• ข้อดี: ง่าย ไม่ต้องเขียนโค้ดมาก, ระบบปลายทางเก่าก็รองรับ, ตรวจสอบข้อมูลก่อน Import ได้
• ข้อเสีย: ไม่ Real-time (Batch processing), ต้องมีคน Upload/Download ไฟล์ (ถ้าไม่ Automate), อาจมีปัญหา Encoding
• เหมาะกับ: GFMIS, e-GP, DPIS, ระบบเก่าที่ไม่มี API

วิธีที่ 3: Database-level (เชื่อมฐานข้อมูลตรง)

เชื่อมต่อฐานข้อมูลระหว่าง 2 ระบบโดยตรง เช่น DB Link, Replication, ETL

• ข้อดี: เร็วมาก, ข้อมูลปริมาณมาก, ไม่ต้องผ่าน Middleware
• ข้อเสีย: ความเสี่ยงสูง (ถ้าเขียน SQL ผิดอาจทำข้อมูลเสียหาย), ต้องเปิด Port ฐานข้อมูล (ความเสี่ยงด้านความปลอดภัย), Vendor อาจไม่ Support
• เหมาะกับ: ระบบภายในองค์กรเดียวกัน, Data Warehouse, BI Report

เปรียบเทียบ 3 วิธี

เกณฑ์	API	File-based	Database-level
ความเร็ว	Real-time	Batch (ชั่วโมง/วัน)	Near Real-time
ความยาก	ปานกลาง-สูง	ต่ำ-ปานกลาง	สูง
ความปลอดภัย	สูง (HTTPS + Token)	ปานกลาง (ไฟล์อาจรั่ว)	ต่ำ (เปิด DB Port)
Vendor Support	ดี (มาตรฐาน)	ดี (ง่าย)	จำกัด (ไม่แนะนำ)
การ Maintain	ปานกลาง	ต่ำ	สูง

API 101 — พื้นฐานที่ทีม Implement ควรรู้

REST vs SOAP

เกณฑ์	REST	SOAP
รูปแบบข้อมูล	JSON (เบา อ่านง่าย)	XML (หนัก เข้มงวด)
ความนิยม	สูง (มาตรฐานปัจจุบัน)	ลดลง (ระบบเก่า)
ความง่าย	ง่าย เรียนรู้เร็ว	ซับซ้อน ต้องมี WSDL
เหมาะกับ	Web/Mobile, ระบบใหม่	ระบบเก่า, ต้องการ Transaction

Authentication — วิธียืนยันตัวตน

• API Key: วิธีง่ายที่สุด ส่ง Key ไปใน Header ทุกครั้ง เหมาะกับ Internal API
• OAuth 2.0: มาตรฐานสำหรับ Third-party access ปลอดภัยสูง ใช้กับ API สาธารณะ
• JWT (JSON Web Token): Token ที่มีข้อมูลผู้ใช้อยู่ข้างใน ไม่ต้อง Query DB ทุกครั้ง อ่านเพิ่มเติมเรื่อง การยืนยันตัวตนแบบ 2FA

Best Practices สำหรับ Integration

• Error Handling: ต้องจัดการทุก Error Case — ระบบปลายทางล่ม, ข้อมูลไม่ถูก Format, Timeout ต้องมี Retry Logic และแจ้งเตือนทีม
• Retry Logic: ถ้าเชื่อมต่อไม่สำเร็จ ให้ Retry 3 ครั้ง ห่างกัน 1, 5, 15 นาที (Exponential Backoff) ก่อน Mark เป็น Failed
• Logging: บันทึก Log ทุก Transaction — ใคร ส่งอะไร เมื่อไหร่ ผลลัพธ์อะไร เพื่อ Troubleshoot เมื่อมีปัญหา
• Monitoring: ตั้ง Alert เมื่อ Error Rate สูงเกิน Threshold หรือระบบไม่ตอบสนอง อ่านเพิ่มเติมเรื่อง Disaster Recovery
• Idempotency: ส่งข้อมูลเดิมซ้ำต้องได้ผลลัพธ์เดิม ไม่สร้าง Record ซ้ำ
• Version Control: API ต้องมี Versioning (v1, v2) เพื่อให้อัพเดทได้โดยไม่กระทบระบบที่เชื่อมต่ออยู่

Checklist เตรียมพร้อมก่อนเชื่อมต่อ 10 ข้อ

#	รายการตรวจสอบ
1	ระบุระบบปลายทางที่ต้องเชื่อมต่อทั้งหมด + เจ้าของระบบ
2	กำหนดวิธีเชื่อมต่อ (API / File / Database) สำหรับแต่ละระบบ
3	ขอ API Document / File Layout จากระบบปลายทาง
4	กำหนด Data Mapping (ข้อมูลอะไรส่งไป-กลับ, Format อะไร)
5	กำหนดความถี่ (Real-time / ทุกชั่วโมง / วันละครั้ง)
6	เตรียม Test Environment สำหรับทดสอบ (ห้ามทดสอบกับ Production)
7	กำหนด Error Handling + Retry Logic
8	วาง Security — Authentication, Encryption, Firewall Rules
9	ทดสอบ Integration อย่างน้อย 2 รอบ ก่อน Go-Live
10	จัดทำ Monitoring + Alert สำหรับ Production

ภาครัฐ: การเชื่อมต่อกับ GFMIS และ e-GP

GFMIS (Government Fiscal Management Information System)

GFMIS เป็นระบบบริหารการเงินการคลังภาครัฐ การเชื่อมต่อกับ GFMIS มักใช้วิธี File-based โดย ERP จะ Export ข้อมูลตาม Layout ที่กรมบัญชีกลางกำหนด แล้ว Upload ผ่าน GFMIS Terminal หรือ Web

• ข้อมูลที่ส่ง: ขอเบิกเงิน, ตั้งหนี้, บันทึกบัญชี, รายงานงบการเงิน
• รูปแบบไฟล์: Text file ตาม Layout กำหนด (Fixed-width หรือ Delimited)
• ความถี่: วันละ 1-2 ครั้ง (Batch)
• สิ่งที่ต้องระวัง: Layout อาจเปลี่ยนแปลง ต้องติดตามประกาศจากกรมบัญชีกลาง

e-GP (Electronic Government Procurement)

ระบบจัดซื้อจัดจ้างภาครัฐ สามารถเชื่อมต่อได้ 2 วิธี:

• Export Layout: ERP Export ข้อมูลจัดซื้อเป็นไฟล์ แล้ว Upload เข้า e-GP — วิธีที่ใช้กันทั่วไป
• API: บาง Version ของ e-GP รองรับ Web Service สำหรับส่งข้อมูลอัตโนมัติ — ต้องตรวจสอบกับ สำนักงบประมาณ

การเชื่อมต่อระบบเป็นส่วนที่ต้องวางแผนตั้งแต่ ช่วง Pre-Project ไม่ใช่รอจนถึงก่อน Go-Live แล้วค่อยเริ่มทำ เพราะการขอ API Document, ประสานงานกับเจ้าของระบบปลายทาง, และทดสอบ Integration อาจใช้เวลา 4-8 สัปดาห์

"ระบบ ERP ที่ดี ไม่ใช่ระบบที่ทำได้ทุกอย่างเอง แต่คือระบบที่เชื่อมต่อกับระบบอื่นได้อย่างราบรื่น"