ปิดดีลในแชท LINE แล้วต้องวิ่งไปคีย์ใบสั่งขายใน SAP เอง: จะย่อ Order-to-Cash ให้สั้นลงยังไง
สรุปสั้น ๆ
Order-to-Cash ใน SAP มีหลายขั้นตอนที่ออกแบบมาเพื่อความถูกต้องทางบัญชี ไม่ใช่ความเร็ว การเชื่อมข้อมูลจากแชท LINE เข้าไปจึงไม่ใช่การ 'ข้าม' ขั้นตอนเดิม แต่คือการทำให้ขั้นตอนแรก (สร้างใบสั่งขาย) เกิดขึ้นอัตโนมัติแทนการคีย์มือ โดยขั้นตอนควบคุมทางบัญชีที่เหลือยังคงอยู่ครบ
โรงงานผลิตบรรจุภัณฑ์แห่งหนึ่งที่ผมเคยเข้าไปช่วยวางกระบวนการขาย ใช้ SAP เป็นระบบหลักมาสิบกว่าปี ทุกใบสั่งขาย ใบส่งของ และใบแจ้งหนี้ไหลผ่าน SAP ทั้งหมดตามมาตรฐานที่ฝ่ายบัญชีวางไว้ แต่ทีมขายเริ่มเปิดแชท LINE OA รับออร์เดอร์ซ้ำจากลูกค้าประจำ เพราะลูกค้าชอบพิมพ์สั่งของสั้น ๆ มากกว่าส่งอีเมล PO เป็นทางการทุกครั้ง
ปัญหาที่ตามมาคือทุกครั้งที่ลูกค้าสั่งผ่านแชท พนักงานขายต้องอ่านข้อความ จดรายการ แล้วไปเปิดหน้าจอ SAP คีย์ใบสั่งขายด้วยมือทีละบรรทัด ในวันที่ออร์เดอร์เยอะ ขั้นตอนนี้กินเวลาเป็นชั่วโมงและเกิดความผิดพลาดบ่อย เช่น พิมพ์รหัสสินค้าผิด หรือใส่จำนวนผิดหลัก
บทความนี้จะเล่าวิธีที่โรงงานนี้ใช้ลดขั้นตอนคีย์มือ โดยยังคงให้ SAP ควบคุมกระบวนการบัญชีทั้งหมดเหมือนเดิม ไม่ใช่การสร้างระบบคู่ขนานที่แยกออกจาก SAP
ทำความเข้าใจ Order-to-Cash ก่อนคิดเรื่องเชื่อมระบบ
Order-to-Cash ใน SAP ประกอบด้วยขั้นตอนหลักที่เชื่อมกันเป็นลูกโซ่ ตั้งแต่สร้างใบสั่งขาย (Sales Order) ตรวจสอบสต๊อกและวงเงินเครดิต ส่งของ (Delivery) ออกใบแจ้งหนี้ (Billing) จนถึงรับชำระและปิดบัญชี แต่ละขั้นตอนมีการควบคุมที่ฝ่ายบัญชีตั้งใจวางไว้เพื่อป้องกันความผิดพลาด เช่น การเช็กวงเงินเครดิตก่อนอนุมัติออร์เดอร์ใหญ่
จุดสำคัญที่ต้องเข้าใจคือ การเชื่อม LINE เข้า SAP ไม่ควรพยายามข้ามขั้นตอนควบคุมเหล่านี้เพื่อความเร็ว เพราะจะสร้างความเสี่ยงทางบัญชีที่ใหญ่กว่าปัญหาเดิม สิ่งที่ควรทำคือทำให้ 'ขั้นตอนแรก' ของลูกโซ่นี้ — การสร้างใบสั่งขายจากข้อมูลแชท — เกิดขึ้นอัตโนมัติแทนการคีย์มือ ส่วนขั้นตอนควบคุมที่เหลือยังเดินตามกระบวนการ SAP เดิมทุกอย่าง
สถาปัตยกรรมที่แนะนำ: ผ่าน middleware ไม่ยิงตรงเข้า SAP
SAP มีช่องทางเชื่อมต่อมาตรฐานอย่าง IDoc และ BAPI ที่รองรับการสร้างใบสั่งขายจากระบบภายนอกอยู่แล้ว แต่ไม่แนะนำให้เครื่องมือแชท LINE ยิงข้อมูลตรงเข้า SAP โดยไม่ผ่านชั้นกลาง เพราะ SAP เป็นระบบที่กระทบเงินและสต๊อกโดยตรง ความผิดพลาดเล็กน้อยจากฝั่งแชทอาจสร้างปัญหาใหญ่ในบัญชี ในลักษณะเดียวกับที่อธิบายไว้ในการออกแบบ webhook เชื่อม LINE เข้า ERP ทั่วไปเพียงแต่ SAP มีมาตรฐานเฉพาะทางของตัวเองที่ต้องเคารพ เช่น รูปแบบ IDoc ที่ต้องตรงเป๊ะ
แนวทางที่ปลอดภัยกว่าคือให้เครื่องมือแชทส่งข้อมูลออร์เดอร์ไปยังชั้นกลางก่อน ชั้นกลางแปลงข้อมูลให้ตรงรูปแบบที่ SAP ต้องการ ตรวจสอบความถูกต้องเบื้องต้น (รหัสสินค้ามีจริงไหม จำนวนสมเหตุสมผลไหม) แล้วจึงส่งเข้า SAP ผ่าน BAPI มาตรฐาน หากข้อมูลไม่ผ่านการตรวจสอบ ให้ส่งกลับไปแจ้งพนักงานขายทันทีเพื่อแก้ไข ไม่ใช่ปล่อยให้ SAP ปฏิเสธเงียบ ๆ
| ขั้นตอน | ทำที่ไหน | หมายเหตุ |
|---|---|---|
| รับคำสั่งซื้อจากแชท | เครื่องมือ tracking LINE | แปลงข้อความเป็นรายการสินค้า+จำนวน |
| ตรวจสอบความถูกต้องเบื้องต้น | ชั้นกลาง (middleware) | เช็กรหัสสินค้า จำนวน วงเงินขั้นต้น |
| สร้างใบสั่งขายจริง | SAP ผ่าน BAPI/IDoc | ยังผ่านการเช็กเครดิตและสต๊อกของ SAP ตามปกติ |
อย่าลืมเรื่องวงเงินเครดิตและการอนุมัติ
จุดที่หลายโปรเจกต์มองข้ามคือลูกค้าที่สั่งผ่านแชทบางรายอาจสั่งเกินวงเงินเครดิตที่ตกลงกันไว้ ถ้าระบบสร้างใบสั่งขายอัตโนมัติโดยไม่เช็กจุดนี้ อาจเกิดกรณีส่งของไปแล้วแต่เกินวงเงินที่อนุมัติ ซึ่งเป็นปัญหาที่ฝ่ายการเงินจะทวงถามทันที
ทางแก้คือให้ SAP ยังคงเป็นผู้ตัดสินใจสุดท้ายเรื่องวงเงินเครดิตเหมือนเดิม ชั้นกลางมีหน้าที่แค่ส่งข้อมูลเข้าไปให้ครบถ้วนถูกต้อง ถ้าออร์เดอร์ไหนติดเงื่อนไขเครดิต ให้ SAP ค้างไว้รออนุมัติตามกระบวนการปกติ แล้วแจ้งกลับไปยังแอดมินแชทว่าออร์เดอร์นี้ต้องรอ ไม่ใช่ปล่อยผ่านไปเพื่อความเร็ว
แนะนำให้เริ่มจากสินค้ากลุ่มเดียวก่อน
- เลือกกลุ่มสินค้าที่ราคาคงที่และไม่มีส่วนลดพิเศษซับซ้อนมาทดลองก่อน เพราะ logic การคำนวณราคาง่ายกว่า ลดความเสี่ยงตอนเริ่มระบบ
- จำกัดกลุ่มลูกค้าที่ใช้ระบบนี้ในช่วงแรกเฉพาะลูกค้าประจำที่มีวงเงินเครดิตชัดเจนอยู่แล้ว ไม่ใช่ลูกค้าใหม่ที่ยังไม่มีประวัติ
- ให้ฝ่ายบัญชีตรวจสอบใบสั่งขายที่เกิดจากระบบใหม่คู่ขนานกับกระบวนการคีย์มือเดิมสักหนึ่งรอบบัญชีเต็ม ก่อนตัดสินใจขยายไปสินค้าหรือกลุ่มลูกค้าอื่น
สรุป
การเชื่อมแชท LINE เข้า SAP ไม่ใช่การพยายามหลบเลี่ยงกระบวนการ Order-to-Cash ที่มีอยู่ แต่คือการทำให้ขั้นตอนแรกซึ่งเดิมต้องพึ่งคนคีย์มือ กลายเป็นอัตโนมัติ ในขณะที่การควบคุมทางบัญชีของ SAP ยังทำงานเหมือนเดิมทุกจุด
ถ้าองค์กรของคุณกำลังคิดจะทำโปรเจกต์แบบนี้ ให้เริ่มจากสินค้ากลุ่มเล็กและลูกค้าที่มีประวัติชัดเจนก่อน แล้วให้ฝ่ายบัญชีร่วมตรวจสอบทุกขั้นตอน ก่อนจะขยายไปสู่ออร์เดอร์ที่ซับซ้อนกว่านั้น
- ให้ SAP ยังคงควบคุมขั้นตอนเครดิตและบัญชีเหมือนเดิม อย่าพยายามข้ามขั้นตอนควบคุมเพื่อความเร็ว
- ใช้ชั้นกลางตรวจสอบข้อมูลก่อนส่งเข้า SAP ผ่าน BAPI/IDoc ไม่ยิงตรงจากเครื่องมือแชท
- เริ่มจากสินค้ากลุ่มเดียวและลูกค้าประจำที่มีวงเงินเครดิตชัดเจนก่อนขยายระบบ
คำถามที่พบบ่อย
ระบบนี้จะทำให้ฝ่ายบัญชีเสียการควบคุมกระบวนการไหม
ไม่เสีย เพราะออกแบบให้ SAP ยังคงเป็นผู้ตัดสินใจสุดท้ายในทุกขั้นตอนที่เกี่ยวกับเงินและสต๊อก ชั้นกลางทำหน้าที่แค่แปลงและส่งข้อมูลให้ครบถ้วน ไม่ได้ข้ามการควบคุมใด ๆ ของ SAP
ถ้าลูกค้าพิมพ์สั่งของแบบไม่เป็นทางการ ระบบจะแปลเป็นรายการสินค้าได้แม่นแค่ไหน
ความแม่นยำขึ้นกับการตั้งค่าคำสั่งซื้อที่พบบ่อยไว้ล่วงหน้า และควรมีขั้นตอนให้แอดมินยืนยันรายการก่อนส่งเข้าชั้นกลางเสมอ ไม่ควรปล่อยให้ระบบตีความและส่งเข้า SAP โดยไม่มีมนุษย์ยืนยันในช่วงแรก
จำเป็นต้องใช้ BAPI หรือมีทางเลือกอื่นไหม
BAPI เป็นวิธีมาตรฐานที่ SAP รองรับดีที่สุดสำหรับการสร้างใบสั่งขายจากภายนอก แต่บาง SAP version หรือ S/4HANA อาจมี API แบบ OData ให้ใช้แทนได้ ควรปรึกษาทีม SAP Basis ภายในว่าระบบที่องค์กรใช้รองรับช่องทางไหนบ้าง
ต้นทุนของการทำโปรเจกต์นี้สูงไหม
ขึ้นกับความซับซ้อนของ logic ราคาและเงื่อนไขเครดิตที่ต้องรองรับ งานระดับพื้นฐานกับสินค้ากลุ่มเดียวมักมีต้นทุนไม่สูงมาก แต่ถ้าต้องรองรับส่วนลดหรือสัญญาราคาพิเศษหลายแบบ ต้นทุนและเวลาจะเพิ่มขึ้นตามความซับซ้อนนั้น
แล้วธุรกิจที่ไม่ได้ใช้ SAP แต่ใช้ POS หรือระบบอื่นล่ะ
หลักการแยกชั้นกลางและตรวจสอบข้อมูลก่อนส่งเข้าระบบหลังบ้านยังใช้ได้เหมือนกัน เพียงแต่ช่องทางเชื่อมต่อจะเปลี่ยนไปตามระบบที่ใช้ ซึ่งเป็นแนวคิดเดียวกับที่ใช้ตอน<a href="/blog/legacy-pos-line-integration">เชื่อมข้อมูลแชทเข้าระบบ POS เก่าที่ไม่มี API เปิด</a>
บทความที่เกี่ยวข้อง
