ออกแบบ webhook ส่งข้อมูลปิดการขายจาก LINE เข้า ERP/ระบบสั่งซื้อภายใน โดยไม่ทำให้ order พัง

ทีม IT ของบริษัทจำหน่ายอุปกรณ์การแพทย์แห่งหนึ่งเคยเล่าให้ผมฟังถึงเหตุการณ์ที่กลายเป็นบทเรียนราคาแพง — พวกเขาทำ webhook เชื่อมจากเครื่องมือแชท LINE เข้าระบบ ERP ภายในองค์กร เพื่อให้พอแอดมินปิดดีลในแชท ระบบจะสร้างใบสั่งซื้อ (order) อัตโนมัติทันที ฟังดูดี แต่ผ่านไปสองสัปดาห์ ฝ่ายคลังพบว่ามี order ซ้ำกันกว่า 40 รายการ เพราะทุกครั้งที่ webhook ยิงไม่สำเร็จแล้วระบบลองส่งซ้ำ (retry) มันสร้าง order ใหม่ทุกครั้งโดยไม่เช็กว่าเคยสร้างไปแล้วหรือยัง

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

บทความนี้จะพาดูว่า webhook ที่เชื่อม LINE เข้า ERP หรือระบบสั่งซื้อภายใน ควรออกแบบยังไงให้ปลอดภัยพอสำหรับข้อมูลที่กระทบเงินจริงและสต๊อกจริง ไม่ใช่แค่ ‘เชื่อมได้’ แต่ต้อง ‘เชื่อมได้อย่างน่าเชื่อถือ’

ทำไมการเชื่อมเข้า ERP ต่างจากการเชื่อมเข้า CRM หรือ dashboard

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

ด้วยเหตุนี้ webhook ที่เชื่อมเข้า ERP จึงต้องออกแบบด้วยมาตรฐานที่เข้มกว่าการเชื่อมระบบรายงานทั่วไปมาก และควรมีทีม IT หรือวิศวกรระบบเข้ามาร่วมออกแบบตั้งแต่ต้น ไม่ใช่ปล่อยให้ฝ่ายการตลาดทำเองทั้งหมด ต่างจากการเชื่อมข้อมูลเข้า CRM เป็นแหล่งลีดที่ทนต่อความผิดพลาดได้มากกว่า เพราะ CRM ไม่ได้กระทบสต๊อกหรือเงินจริงโดยตรง

หัวใจสำคัญ: idempotency key ป้องกัน order ซ้ำ

หลักการง่าย ๆ ที่ป้องกันปัญหา order ซ้ำได้เกือบทั้งหมดคือการกำหนด ‘idempotency key’ ให้กับทุกเหตุการณ์ปิดดีล เช่น รหัสอ้างอิงเฉพาะของดีลนั้นในระบบแชท เมื่อ webhook ยิงมาถึง ERP ฝั่งรับต้องเช็กก่อนว่ารหัสนี้เคยถูกประมวลผลไปแล้วหรือยัง ถ้าเคยแล้วให้ข้ามไปเลย ไม่สร้าง order ใหม่ซ้ำ

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

ลำดับการไหลของข้อมูลที่แนะนำ

1. แอดมินกดปิดดีลในเครื่องมือแชท ระบบสร้าง event พร้อม idempotency key เฉพาะของดีลนั้น
2. ส่ง event เข้าคิวข้อความ (message queue) ก่อน ไม่ยิงตรงเข้า ERP ทันที เพื่อรองรับกรณี ERP ปิดปรับปรุงระบบชั่วคราวโดยไม่ทำให้ข้อมูลหาย
3. ตัวประมวลผลกลาง (worker) ดึง event จากคิว ตรวจสอบ idempotency key กับ log ที่เคยประมวลผลแล้ว ถ้าซ้ำให้ข้าม ถ้าใหม่ให้สร้าง order
4. ถ้าการสร้าง order ล้มเหลว ให้ retry ตามรอบเวลาที่กำหนด (เช่น ทุก 5 นาที สูงสุด 5 ครั้ง) แล้วถ้ายังไม่สำเร็จให้แจ้งเตือนทีม IT แทนที่จะปล่อยให้ล้มเหลวเงียบ ๆ
5. บันทึก log ทุกขั้นตอนไว้ตรวจสอบย้อนหลังได้ เพราะเมื่อเกี่ยวข้องกับเงินจริง ฝ่ายบัญชีจะต้องการหลักฐานเสมอเมื่อมีข้อสงสัย

ใครควรเป็นคนสร้างส่วนนี้ และเครื่องมือช่วยได้แค่ไหน

งานระดับนี้ควรมีวิศวกรระบบหรือทีม IT ภายในเป็นผู้ดูแลส่วนที่เชื่อมต่อกับ ERP โดยตรง เพราะเป็นระบบที่กระทบเงินและสต๊อก ส่วนฝั่งต้นทางคือเครื่องมือ tracking ที่ผูกกับ LINE OA ก็ควรเลือกตัวที่มีการส่งข้อมูลแบบ server-to-server ที่เสถียรและมี log การส่งที่ตรวจสอบย้อนหลังได้ ไม่ใช่แค่ปุ่ม export ธรรมดา ระบบอย่าง linli ที่รองรับการยิง webhook พร้อมข้อมูลอ้างอิงที่จำเป็นก็ช่วยลดงานฝั่งต้นทางได้มาก แต่ส่วนการออกแบบความปลอดภัยฝั่ง ERP ยังต้องเป็นความรับผิดชอบของทีม IT ภายในอยู่ดี

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

ทดสอบยังไงก่อนปล่อยใช้จริงกับ order จริง

• จำลองการยิง webhook ซ้ำโดยตั้งใจ เพื่อเช็กว่าระบบสร้าง order ซ้ำหรือไม่ ก่อนอนุญาตให้ไปแตะข้อมูลจริง
• จำลองสถานการณ์ ERP ล่มระหว่างรับ event เพื่อดูว่า retry logic ทำงานถูกต้องและไม่ทำข้อมูลหาย
• ทดสอบกับดีลมูลค่าสูงและดีลที่มีส่วนลดพิเศษ เพราะเป็นเคสที่มักมีฟิลด์ข้อมูลซับซ้อนกว่าดีลปกติ
• ให้ฝ่ายบัญชีตรวจสอบ order ที่เกิดจากระบบใหม่คู่ขนานกับกระบวนการเดิมสักหนึ่งรอบบัญชี ก่อนตัดสินใจเลิกกระบวนการเดิมทั้งหมด

สรุป

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

บทเรียนจากเคส order ซ้ำ 40 รายการที่เล่าไปตอนต้น ไม่ได้แปลว่าไม่ควรทำระบบแบบนี้ แต่แปลว่าต้องทำให้ถูกวิธีตั้งแต่แรก — มี idempotency key มี retry logic ที่รอบคอบ และมีทีมที่เข้าใจทั้งฝั่งแชทและฝั่ง ERP ร่วมออกแบบไปด้วยกัน

• ใช้ idempotency key ทุก event เพื่อป้องกัน order ซ้ำเมื่อ webhook ถูกยิงซ้ำ
• ส่ง event ผ่านคิวข้อความก่อนเข้า ERP เพื่อรองรับกรณีระบบปลายทางล่มชั่วคราว
• งานเชื่อมต่อ ERP ต้องมีทีม IT ร่วมออกแบบ ไม่ใช่ภาระของฝ่ายการตลาดฝ่ายเดียว

คำถามที่พบบ่อย