- แอปใหม่ที่ไม่เชื่อมกับระบบบัญชีและสต็อกทำให้พนักงานต้องคีย์ข้อมูลสองที่ แล้วตัวเลขสองฝั่งจะเริ่มไม่ตรงกัน
- ก่อนเชื่อมต้องตกลงให้ได้ว่าข้อมูลแต่ละอย่างยึดระบบไหนเป็นหลัก และถ้าส่งไม่ผ่านจะเกิดอะไรขึ้น
- ทำรายงานเทียบยอดระหว่างสองระบบให้เสร็จก่อนสร้างตัวเชื่อม จะรู้ปัญหาภายในวันเดียว ไม่ต้องรอถึงวันปิดงบ
ปัญหาส่วนใหญ่เกิดที่รอยต่อระหว่างระบบ
ภาพที่เห็นบ่อยคือพนักงานขายรับออเดอร์ในแอปใหม่ จากนั้นฝ่ายบัญชีคีย์ใบเดียวกันเข้าโปรแกรมบัญชีอีกรอบ บริษัทจึงมีตัวเลขสองชุดที่ควรเท่ากันแต่ไม่มีอะไรบังคับให้เท่า ทุกครั้งที่คนคีย์ซ้ำ ตัวเลขสองชุดมีโอกาสห่างกันออกไปอีกนิด
อาการมักเผยตัวช้า ออเดอร์หนึ่งใบตกหล่นในวันที่งานยุ่ง ราคาในแอปยังเป็นราคาเดือนก่อนเพราะมีคนแก้ใน ERP ที่เดียว สต็อกที่แอปแสดงตามหลังคลังจริงครึ่งวัน พอถึงสิ้นเดือน ฝ่ายบัญชีต้องใช้เวลาหลายวันไล่หาว่าส่วนต่างมาจากใบไหน
งานส่วนนี้เป็นงานที่ Vibe Code ช่วยได้น้อย AI เขียนโค้ดเรียก API ได้เร็วมากเมื่อมีเอกสารอธิบาย API ที่ดี แต่ความรู้ที่งานเชื่อมระบบต้องใช้ส่วนใหญ่ไม่เคยถูกเขียนเป็นเอกสาร ฝ่ายขายกับคลังใช้รหัสสินค้าคนละชุด ลูกค้ารายเดียวมีสามรหัสเพราะเคยเปิดบิลจากสามสาขา ช่องหมายเหตุถูกฝ่ายบัญชีใช้เก็บเลขใบสั่งซื้อของลูกค้ามาสิบปี เรื่องแบบนี้อยู่ในหัวของคนทำงานและในข้อมูลเก่า ต้องมีคนไปนั่งถามและเปิดข้อมูลดู
สี่คำถามที่ต้องตอบก่อนสร้างตัวเชื่อม
การเชื่อมระบบคล้ายการให้สองแผนกใช้สมุดบัญชีเล่มเดียวกัน ก่อนเริ่มต้องตกลงว่าใครเป็นคนเขียน ใครอ่านอย่างเดียว เขียนเมื่อไร และถ้าเขียนผิดใครเป็นคนแก้ สี่คำถามนี้ต้องได้คำตอบจากฝ่ายธุรกิจ ทีมเทคนิคตอบแทนไม่ได้
ข้อมูลแต่ละอย่างยึดระบบไหนเป็นหลัก
ข้อมูลทุกชนิดควรมีระบบเดียวที่เป็นตัวจริง เรียกว่า Source of Truth เช่น ราคาขายยึด ERP จำนวนสต็อกยึดระบบคลัง ข้อมูลติดต่อลูกค้ายึดแอป ระบบอื่นอ่านไปใช้ได้แต่ห้ามแก้ ถ้าปล่อยให้แก้ได้สองที่ จะไม่มีใครตอบได้ว่าตัวเลขไหนถูก
ส่งเมื่อไร และไปทางไหน
ข้อมูลบางอย่างต้องถึงเกือบทันที เช่น สต็อกของสินค้าที่ขายเร็ว บางอย่างส่งเป็นรอบตอนกลางคืนก็พอ เช่น ยอดขายที่ลงบัญชี ยิ่งส่งถี่ ระบบยิ่งซับซ้อนและแพงขึ้น จึงควรเลือกรอบจากผลเสียของข้อมูลที่ช้า
ถ้าส่งไม่ผ่านจะเกิดอะไรขึ้น
เครือข่ายหลุดกลางทางเป็นเรื่องปกติ ระบบต้นทางจึงต้องส่งซ้ำได้ และการส่งซ้ำต้องไม่สร้างเอกสารใบที่สอง คุณสมบัตินี้เรียกว่า Idempotency รายการที่ส่งไม่ผ่านหลายรอบต้องไปค้างอยู่ในที่ที่คนเห็น และมีชื่อคนรับผิดชอบเข้าไปจัดการ
ใครตรวจยอด และตรวจเมื่อไร
ตัวเชื่อมที่ทำงานถูกวันนี้อาจผิดในวันที่มีคนเพิ่มประเภทส่วนลดใหม่ การเทียบยอดระหว่างสองระบบทุกวัน หรือ Reconciliation จึงเป็นส่วนหนึ่งของระบบ และควรมีตั้งแต่วันแรกที่เปิดใช้
| วิธีเชื่อม | เหมาะเมื่อ | ข้อควรระวัง |
|---|---|---|
| เรียก API ของระบบปลายทาง | ระบบมี API และผู้ขายรองรับการใช้งาน | โควตาจำนวนครั้งต่อวัน และค่าลิขสิทธิ์ของโมดูล API |
| ไฟล์นำเข้าและส่งออกตามรอบ | ระบบเก่าไม่มี API แต่นำเข้าไฟล์ได้ | ข้อมูลช้าตามรอบ และต้องมีวิธีจัดการไฟล์ที่นำเข้าไม่ผ่าน |
| อ่านฐานข้อมูลของระบบเดิมโดยตรง | ไม่มีทางอื่น และผู้ขายระบบยินยอม | การเขียนตรงเสี่ยงทำข้อมูลเสียและอาจผิดเงื่อนไขการรับบริการ ควรจำกัดไว้ที่การอ่าน |
| ให้โปรแกรมกดหน้าจอแทนคน | ระบบปิดทุกทาง และปริมาณงานน้อย | หยุดทำงานเมื่อหน้าจอของระบบเดิมเปลี่ยน |
สำหรับทีมพัฒนา · รายละเอียดเชิงเทคนิค
ใช้ Idempotency Key ต่อเอกสาร ส่งผ่าน Outbox และ Message Queue พร้อม Retry แบบ Backoff และ Dead-letter Queue ที่มีหน้าจอให้คนจัดการ เก็บตารางจับคู่รหัสสินค้าและรหัสลูกค้าไว้ที่ชั้นกลาง ตรวจ Schema ของข้อมูลขาเข้า เฝ้าดูความล่าช้าและอัตราผิดพลาดของคิว และมี Contract Test กับ API ของผู้ขายเพื่อจับการเปลี่ยนแปลงก่อนถึง Production
กรณีจำลอง
ผู้จัดจำหน่ายวัสดุก่อสร้างกับปูนที่ถูกส่งสองเที่ยว
ผู้จัดจำหน่ายวัสดุก่อสร้างรายหนึ่งทำแอปให้ร้านค้าช่วงสั่งของเอง แอปส่งออเดอร์เข้า ERP ผ่าน API วันที่ฝนตกหนัก อินเทอร์เน็ตของคลังหลุดเป็นช่วง ๆ แอปส่งออเดอร์ไปแล้วรอคำตอบจนหมดเวลา จึงส่งซ้ำตามที่ถูกตั้งไว้ ERP ได้รับออเดอร์เดียวกันสองครั้งและออกใบจัดของสองใบ รถบรรทุกปูนจึงไปถึงร้านเดียวกันสองเที่ยว บริษัทรู้เรื่องเมื่อเจ้าของร้านโทรมาปฏิเสธรับของเที่ยวที่สอง
ทีมแก้สองจุด จุดแรกคือให้แอปแนบรหัสอ้างอิงเดิมทุกครั้งที่ส่งซ้ำ และให้ฝั่งรับตรวจรหัสนี้ก่อนสร้างเอกสาร จุดที่สองคือรายงานเทียบยอดที่รันทุกเช้า เทียบจำนวนออเดอร์และยอดเงินของเมื่อวานระหว่างแอปกับ ERP รายงานนี้จับปัญหาอีกชนิดได้ในสัปดาห์ถัดมา คือออเดอร์ที่ถูกยกเลิกในแอปแต่ยังค้างอยู่ใน ERP ซึ่งไม่มีใครเคยรู้ว่าเกิดขึ้น
ตรวจยอดก่อนเชื่อม
- เลือกเอกสารหนึ่งชนิดที่จะไหลข้ามระบบ เช่น ใบสั่งขาย
- กำหนดตัวเลขที่สองฝั่งต้องตรงกันทุกวัน เช่น จำนวนใบ ยอดเงินรวม และจำนวนชิ้นต่อรหัสสินค้า
- สร้างรายงานที่ดึงตัวเลขจากสองระบบมาวางคู่กัน โดยทดลองกับข้อมูลที่คีย์มือของเดือนที่แล้ว
- อ่านส่วนต่างที่รายงานจับได้ทีละรายการ แต่ละรายการคือกฎหนึ่งข้อที่ตัวเชื่อมต้องรองรับ
- เมื่อเปิดใช้ตัวเชื่อม ให้รายงานรันทุกเช้า และระบุชื่อคนที่ต้องปิดส่วนต่างภายในวันนั้น
หลักฐานที่ควรเก็บคือจำนวนส่วนต่างรายวันและเวลาที่ใช้ปิดแต่ละรายการ วิธีนี้สะดุดเมื่อสองระบบนิยามคำเดียวกันต่างกัน เช่น ยอดขายของฝั่งหนึ่งรวมภาษีแต่อีกฝั่งไม่รวม กรณีนั้นฝ่ายบัญชีต้องตกลงนิยามให้เสร็จก่อน
การย้ายข้อมูลเก่ามักถูกประเมินต่ำที่สุด
เมื่อระบบใหม่ต้องเริ่มด้วยข้อมูลลูกค้า สินค้า และยอดค้างจากระบบเดิม งานย้ายข้อมูลจะกินเวลามากกว่าที่ใครคาด เพราะข้อมูลเก่ามีรายการซ้ำ ช่องว่าง และรูปแบบที่เปลี่ยนไปตามยุคของคนคีย์
ลำดับงานที่ปลอดภัยมีสี่ขั้น ขั้นแรกทำความสะอาดข้อมูล รวมรายการซ้ำและเติมช่องที่จำเป็น ขั้นที่สองเขียนตารางจับคู่ว่าช่องไหนของระบบเดิมไปลงช่องไหนของระบบใหม่ ซึ่งเรียกว่า Data Mapping ขั้นที่สามย้ายทดลองและให้เจ้าของข้อมูลตรวจตัวอย่าง ขั้นสุดท้ายรันสองระบบคู่กันช่วงหนึ่งก่อนตัดเข้าระบบใหม่ และต้องมีแผนย้อนกลับเผื่อวันตัดระบบมีปัญหา
ยังไม่ควรลงทุนเชื่อมระบบ ถ้าเข้าข้อใดข้อหนึ่ง
- ปริมาณเอกสารน้อยจนการคีย์มือสัปดาห์ละครั้งถูกกว่าค่าสร้างและดูแลตัวเชื่อม
- ระบบปลายทางจะถูกเปลี่ยนภายในหนึ่งปี
- ยังไม่มีเจ้าของข้อมูลที่ตัดสินได้เมื่อสองระบบขัดกัน
- ผู้ขายระบบเดิมไม่อนุญาตหรือไม่รองรับการเชื่อมต่อ
การวัดผลให้ดูตัวเลขที่ฝ่ายบัญชีและฝ่ายปฏิบัติการรู้สึกได้ ได้แก่ชั่วโมงคีย์ซ้ำที่หายไป จำนวนส่วนต่างต่อวัน เวลาที่ใช้ปิดส่วนต่าง และจำนวนวันที่ใช้ปิดบัญชีสิ้นเดือน ถ้ารันคู่กันครบสองสัปดาห์แล้วส่วนต่างยังไม่ลดลง ให้เลื่อนวันตัดระบบออกไปก่อน และกลับไปดูว่ากฎข้อไหนยังไม่ถูกรองรับ
ให้แอปใหม่กับระบบเดิมรายงานตัวเลขเดียวกัน
ฝ่ายบัญชีของคุณเป็นเจ้าของผังบัญชีและกฎการลงรายการ ฝ่ายคลังเป็นเจ้าของรหัสสินค้าและวิธีนับสต็อก ผู้ขาย ERP รู้ข้อจำกัดของระบบตัวเอง DNA Maker นั่งไล่เอกสารหนึ่งใบจากต้นทางถึงปลายทางกับคนทั้งสามกลุ่ม แล้วเขียนเป็นแผนผังรอยต่อ ว่าช่องไหนไปลงช่องไหน ระบบไหนเป็นหลักของข้อมูลแต่ละชนิด ส่งรอบละเท่าไร และถ้าส่งไม่ผ่านใครต้องทำอะไร
จากแผนผังนั้นเราสร้างชั้นเชื่อมระบบที่มีคิว การส่งซ้ำที่ไม่สร้างเอกสารซ้ำ ตารางจับคู่รหัส และรายงานเทียบยอดรายวัน พร้อม Dashboard ให้ฝ่ายบัญชีเห็นรายการที่ค้าง งานเริ่มจากเอกสารชนิดเดียว รันคู่กับการคีย์มือจนส่วนต่างเป็นศูนย์ต่อเนื่อง แล้วจึงตัดเข้าระบบใหม่และขยายไปเอกสารชนิดถัดไป ถ้าทีมของคุณคีย์เอกสารชนิดไหนซ้ำบ่อยที่สุด นำตัวอย่างสิบใบของเอกสารนั้นจากทั้งสองระบบมาคุยกับเราได้
SOFTWARE ENGINEERING GLOSSARY
คลังคำศัพท์การพัฒนาซอฟต์แวร์
คำชุดนี้ใช้คุยกับทีมพัฒนาและผู้ขายระบบเดิมเมื่อวางแผนเชื่อมระบบ คำถามในคอลัมน์ขวาช่วยให้เห็นว่าใครเป็นเจ้าของแต่ละขั้น
| คำศัพท์ | คืออะไร | ตัวอย่างที่เข้าใจง่าย | คำถามที่ผู้บริหารควรถามทีมพัฒนา |
|---|---|---|---|
| Reconciliation | การเทียบตัวเลขของสองระบบว่าตรงกัน และไล่หาสาเหตุของรายการที่ไม่ตรง | ทุกเช้ารายงานเทียบจำนวนออเดอร์และยอดเงินของเมื่อวานระหว่างแอปกับ ERP | ใครเป็นคนปิดส่วนต่าง และต้องปิดภายในกี่ชั่วโมง? |
| Data Migration | การย้ายข้อมูลจากระบบเดิมเข้าระบบใหม่ รวมการทำความสะอาดและการตรวจหลังย้าย | ย้ายรายชื่อลูกค้าแปดพันรายเข้าระบบใหม่ หลังรวมรายที่ซ้ำกันแล้ว | หลังย้าย เราตรวจอย่างไรว่าข้อมูลครบและยอดค้างตรงกับระบบเดิม? |
| Data Mapping | ตารางที่บอกว่าข้อมูลช่องไหนของระบบหนึ่งตรงกับช่องไหนของอีกระบบ | รหัสสินค้าของฝ่ายขายจับคู่กับรหัสสินค้าของคลังทีละรายการ | ใครเป็นเจ้าของตารางนี้ และเมื่อมีสินค้าใหม่ใครเป็นคนเพิ่ม? |
| Middleware | ซอฟต์แวร์ตัวกลางที่รับข้อมูลจากระบบหนึ่ง แปลงรูปแบบ แล้วส่งต่อให้อีกระบบ | ตัวกลางรับออเดอร์จากแอป แปลงรหัสสินค้า แล้วส่งเข้า ERP | ถ้าตัวกลางหยุดทำงาน รายการที่ค้างอยู่ไปอยู่ที่ไหน และใครได้รับแจ้ง? |
| Message Queue | ที่พักข้อมูลระหว่างสองระบบ รายการเข้าคิวรอส่งและไม่หายแม้ปลายทางล่มชั่วคราว | ERP ปิดปรับปรุงหนึ่งชั่วโมง ออเดอร์รออยู่ในคิว แล้วทยอยเข้าเมื่อระบบกลับมา | คิวยาวสุดได้แค่ไหนก่อนที่ธุรกิจจะเดือดร้อน และเรารู้ได้จากอะไร? |
| Parallel Run | การใช้ระบบเดิมกับระบบใหม่คู่กันช่วงหนึ่ง เพื่อเทียบผลก่อนเลิกระบบเดิม | ฝ่ายบัญชีคีย์มือต่ออีกสองสัปดาห์ขณะที่ตัวเชื่อมทำงาน แล้วเทียบยอดทุกวัน | เกณฑ์อะไรที่บอกว่าเลิกรันคู่ได้ และใครเป็นคนตัดสิน? |
| Cutover | ช่วงเวลาที่สลับจากระบบเดิมไประบบใหม่จริง | คืนวันเสาร์หยุดรับออเดอร์สองชั่วโมง ย้ายยอดค้าง แล้วเปิดระบบใหม่เช้าวันอาทิตย์ | ถ้าคืนตัดระบบมีปัญหา เราย้อนกลับได้ถึงกี่โมง และใครเป็นคนสั่ง? |