ข้ามไปยังเนื้อหาหลัก
FromNine
เมนู

กระบวนการที่เชื่อมต่อกัน

ทุกคำสั่งซื้ออยู่บนไทม์ไลน์เดียว ตั้งแต่รับคำสั่งซื้อจนได้รับชำระเงิน

Order to Cash, Procure to Pay และงานบริการจนถึงการออกใบแจ้งหนี้ ต้องผ่านหลายระบบ ทั้ง ERP, CRM อีคอมเมิร์ซ คลังสินค้า ขนส่ง และการเงิน เราเชื่อมต่อระบบเหล่านี้ด้วย API และเหตุการณ์ที่มีเอกสารกำกับ ให้ทุกคำสั่งซื้อมีสถานะเดียวในทุกระบบ และส่งข้อยกเว้นแต่ละรายการให้เอเจนต์ที่เตรียมแนวทางแก้ไขเพื่อให้คนอนุมัติ

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

ปรึกษาเรื่องโซลูชันนี้ดูขั้นตอนการทำงาน
ผู้ใช้งานหลัก
  • ฝ่ายบริหารคำสั่งซื้อและบริการลูกค้า
  • ผู้วางแผนซัพพลายเชนและโลจิสติกส์
  • ทีมบัญชีเจ้าหนี้และลูกหนี้
  • ทีมเชื่อมต่อระบบและปฏิบัติการไอที
ตัวอย่างขั้นตอนการทำงาน
  1. 01บันทึกเหตุการณ์ครั้งเดียวระบบ
  2. 02กระจายผ่าน API และเหตุการณ์ระบบ
  3. 03สร้างไทม์ไลน์เดียวต่อคำสั่งซื้อระบบ
  4. 04รวบรวมบริบทและเสนอเอเจนต์ AI
  5. 05อนุมัติภายในเกณฑ์บุคคล
  6. 06ออกใบแจ้งหนี้ จับคู่ และชำระระบบ
  7. 07ทบทวนการไหลของงานและแก้ที่ต้นเหตุบุคคล
คำสั่งซื้อ ใบสั่งซื้อ หรือคำขอบริการบันทึกครั้งเดียวในระบบหลักที่เป็นเจ้าของข้อมูล และกระจายไปยังระบบอื่นผ่าน API และเหตุการณ์ที่มีเอกสารกำกับ เหตุการณ์สถานะสร้างไทม์ไลน์เดียวต่อคำสั่งซื้อ เมื่อขั้นตอนใดล้มเหลวหรือเกินเกณฑ์ที่ยอมรับได้ เอเจนต์รวบรวมบริบทและเสนอแนวทางแก้ไข ซึ่งคนต้องอนุมัติก่อนดำเนินการในระบบหลัก ใบแจ้งหนี้แลกเปลี่ยนและจับคู่ในรูปใบแจ้งหนี้อิเล็กทรอนิกส์แบบมีโครงสร้าง และเจ้าของกระบวนการทบทวนการไหลของงานและสถานะของการเชื่อมต่อ

ก่อนและหลัง

สิ่งที่เปลี่ยนไปในงานปฏิบัติการประจำวัน

  1. ปัจจุบัน

    ปัจจุบัน: พิมพ์ซ้ำทุกครั้งที่ส่งต่องาน

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

    เมื่อใช้ระบบ

    เมื่อใช้ระบบ: บันทึกครั้งเดียว ใช้ได้ทุกที่

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

  2. ปัจจุบัน

    ปัจจุบัน: สถานะของเมื่อวาน

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

    เมื่อใช้ระบบ

    เมื่อใช้ระบบ: สถานะปัจจุบันเดียว

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

  3. ปัจจุบัน

    ปัจจุบัน: ข้อยกเว้นจัดการในกล่องอีเมล

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

    เมื่อใช้ระบบ

    เมื่อใช้ระบบ: ข้อยกเว้นมาพร้อมข้อเสนอ

    เอเจนต์รวบรวมข้อมูลเบื้องหลังข้อยกเว้นแต่ละรายการและเสนอแนวทางแก้ไข คนอนุมัติ แก้ไข หรือปฏิเสธบนหน้าจอจัดการข้อยกเว้นเดียว และระบบบันทึกการตัดสินใจ

  4. ปัจจุบัน

    ปัจจุบัน: ข้อมูลหลักที่ไม่ตรงกัน

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

    เมื่อใช้ระบบ

    เมื่อใช้ระบบ: ข้อมูลแต่ละประเภทมีเจ้าของเดียว

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

  5. ปัจจุบัน

    ปัจจุบัน: ทุกการเปลี่ยนแปลงเพิ่มการเชื่อมต่ออีกจุด

    ช่องทางขายใหม่ มาร์เก็ตเพลส หรือนิติบุคคลใหม่ หมายถึงการเชื่อมต่อแบบจุดต่อจุดอีกเส้น ลูกค้าในยุโรปที่ต้องใช้ใบแจ้งหนี้อิเล็กทรอนิกส์ตามกฎของแต่ละประเทศ และ e-Tax Invoice & e-Receipt สำหรับบริษัทที่เลือกใช้ในประเทศ เพิ่มรูปแบบและเครือข่ายเข้าไปในแต่ละกระบวนการอีกชั้น

    เมื่อใช้ระบบ

    เมื่อใช้ระบบ: การเชื่อมต่อใหม่ใช้ข้อตกลงเดิม

    ช่องทาง นิติบุคคล หรือเครือข่ายใบแจ้งหนี้อิเล็กทรอนิกส์ใหม่ เชื่อมกับ API และเหตุการณ์ที่มีเอกสารกำกับเพียงครั้งเดียว แทนการเชื่อมกับทุกระบบแยกกัน

ขั้นตอนการทำงาน

ขั้นตอนการทำงาน

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

ตัวอย่างขั้นตอนการทำงาน

7 ขั้นตอน · จุดตรวจสอบโดยมนุษย์ 1 จุด

ขั้นตอนล้มเหลวหรือเกินเกณฑ์01ระบบบันทึกเหตุการณ์ครั้งเดียว02ระบบกระจายผ่าน API และเหตุการณ์03ระบบสร้างไทม์ไลน์เดียวต่อคำสั่งซื้อ04เอเจนต์ AIรวบรวมบริบทและเสนอ05บุคคลอนุมัติภายในเกณฑ์จุดตรวจสอบโดยมนุษย์06ระบบออกใบแจ้งหนี้ จับคู่ และชำระ07บุคคลทบทวนการไหลของงานและแก้ที่ต้นเหตุ

คำอธิบายสัญลักษณ์

  • ระบบ
  • เอเจนต์ AI
  • บุคคล
  • จุดตรวจสอบโดยมนุษย์
  • เส้นทางกรณียกเว้น

กระบวนการที่เชื่อมต่อกัน: ตัวอย่างขั้นตอนการทำงานพร้อมวงจรข้อยกเว้น

อ่านแผนภาพในรูปแบบข้อความ

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

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

ขั้นอนุมัติคือจุดที่คนเป็นผู้ควบคุม: ไม่มีการบันทึกรายการทางการเงิน การเปลี่ยนราคาหรือวงเงินเครดิต หรือคำมั่นต่อลูกค้า โดยไม่มีคน

  1. ขั้นตอนที่ 1: บันทึกเหตุการณ์ครั้งเดียวระบบ

    คำสั่งขายจากร้านค้าออนไลน์ มาร์เก็ตเพลส EDI หรือทีมขาย ใบสั่งซื้อ หรือคำขอบริการ สร้างในระบบที่เป็นเจ้าของข้อมูล ระบบนั้นเผยแพร่เหตุการณ์ทางธุรกิจในรูปแบบ CloudEvents ซึ่งอธิบายไว้ในข้อตกลง AsyncAPI คำสั่งซื้อและใบแจ้งหนี้จากผู้ขายที่เป็นกระดาษหรือ PDF ผ่านโซลูชันประมวลผลเอกสารอัจฉริยะก่อน

  2. ขั้นตอนที่ 2: กระจายผ่าน API และเหตุการณ์ระบบ

    ชั้นเชื่อมต่อระบบส่งเหตุการณ์ไปยังระบบคลังสินค้า ขนส่ง การเงิน และ CRM ผ่าน API ที่มีเอกสารกำกับ (OpenAPI) ผู้รับข้อความออกแบบให้เป็น idempotent ข้อความซ้ำจึงไม่สร้างการจัดส่งหรือใบแจ้งหนี้ซ้ำ และข้อความที่ส่งไม่สำเร็จรอในคิวข้อผิดพลาดเพื่อส่งใหม่

  3. ขั้นตอนที่ 3: สร้างไทม์ไลน์เดียวต่อคำสั่งซื้อระบบ

    เหตุการณ์สถานะจากทุกระบบ (ยืนยันแล้ว หยิบสินค้าแล้ว จัดส่งแล้ว ส่งถึงแล้ว ออกใบแจ้งหนี้แล้ว ชำระแล้ว) เชื่อมโยงด้วยเลขอ้างอิงทางธุรกิจเป็นไทม์ไลน์เดียว กฎหมุดหมายและเกณฑ์ที่ยอมรับได้สร้างข้อยกเว้นเมื่อขั้นตอนใดล้มเหลว ล่าช้า หรือไม่ตรงกัน เช่น สินค้าขาดสต็อก ราคาเกินเกณฑ์ที่ตกลง การจัดส่งล้มเหลว หรือใบแจ้งหนี้อิเล็กทรอนิกส์ถูกปฏิเสธ

  4. ขั้นตอนที่ 4: รวบรวมบริบทและเสนอเอเจนต์ AI

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

    เส้นทางกรณียกเว้น: ขั้นตอนล้มเหลวหรือเกินเกณฑ์

  5. ขั้นตอนที่ 5: อนุมัติภายในเกณฑ์บุคคล

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

    เส้นทางกรณียกเว้น: ขั้นตอนล้มเหลวหรือเกินเกณฑ์· กลับสู่ขั้นตอนที่ 2

    จุดตรวจสอบโดยมนุษย์

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

  6. ขั้นตอนที่ 6: ออกใบแจ้งหนี้ จับคู่ และชำระระบบ

    ใบแจ้งหนี้ถึงลูกค้าในยุโรปออกจากระบบ ERP เป็นใบแจ้งหนี้อิเล็กทรอนิกส์แบบมีโครงสร้าง (Peppol BIS Billing 3.0, EN 16931) ผ่าน access point และใบกำกับภาษีในประเทศออกผ่าน e-Tax Invoice & e-Receipt เมื่อบริษัทเลือกใช้ ใบแจ้งหนี้จากผู้ขายจับคู่กับใบสั่งซื้อและใบรับสินค้า และสถานะการชำระเงินจากธนาคารหรือผู้ให้บริการชำระเงินปิดไทม์ไลน์

  7. ขั้นตอนที่ 7: ทบทวนการไหลของงานและแก้ที่ต้นเหตุบุคคล

    เจ้าของกระบวนการและทีมเชื่อมต่อระบบทบทวนข้อยกเว้นตามเหตุผล ความล้มเหลวของการเชื่อมต่อ และข้อมูลหลักที่ขัดแย้งกันตามรอบที่กำหนด และแก้ที่ต้นเหตุ ไม่ว่าจะอยู่ในข้อมูลหลัก เกณฑ์ที่ยอมรับได้ หรือการจับคู่ข้อมูล แทนการแก้ข้อยกเว้นเดิมซ้ำ

องค์ประกอบ

สิ่งที่เราจะสร้าง

  1. ชั้นเชื่อมต่อระบบแบบขับเคลื่อนด้วยเหตุการณ์

    API และเหตุการณ์ที่ออกแบบข้อตกลงก่อน ระหว่าง ERP, CRM อีคอมเมิร์ซ คลังสินค้า ขนส่ง และการเงิน กำหนดด้วย OpenAPI และ AsyncAPI ในรูปแบบ CloudEvents บนแพลตฟอร์มเชื่อมต่อระบบที่มีอยู่ หรือสร้างแบบ cloud native

    ดำเนินการโดยการเชื่อมต่อระบบและ API

  2. การจัดข้อมูลหลักให้ตรงกัน

    ระบบหลักและเจ้าของที่ตกลงกันสำหรับข้อมูลแต่ละประเภท กฎจับคู่ลูกค้า ผู้ขาย และสินค้า และรายงานข้อมูลซ้ำและข้อมูลขัดแย้งให้ผู้ที่เป็นเจ้าของ

    ดำเนินการโดยข้อมูลและการวิเคราะห์

  3. ไทม์ไลน์กระบวนการและแดชบอร์ดการไหลของงาน

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

    ดำเนินการโดยซอฟต์แวร์องค์กรและ SaaS

  4. หน้าจอจัดการข้อยกเว้นพร้อมเอเจนต์ที่เสนอแนวทาง

    คิวข้อยกเว้นที่แสดงบริบทที่รวบรวมได้และข้อเสนอของเอเจนต์ พร้อมปุ่มอนุมัติ แก้ไข และปฏิเสธ และบังคับเกณฑ์การอนุมัติของแต่ละประเภทการดำเนินการ ณ จุดที่การดำเนินการเกิดขึ้น

    ดำเนินการโดยเอเจนต์ AI และระบบอัตโนมัติ

  5. ใบแจ้งหนี้อิเล็กทรอนิกส์แบบมีโครงสร้าง

    ใบแจ้งหนี้ Peppol BIS Billing 3.0 และ EN 16931 ในรูป UBL ส่งและรับผ่าน access point ตรวจสอบก่อนส่ง และส่งใบแจ้งหนี้ที่ถูกปฏิเสธไปยังหน้าจอจัดการข้อยกเว้น พร้อมการเชื่อมต่อกับ e-Tax Invoice & e-Receipt สำหรับใบกำกับภาษีในประเทศ

    ดำเนินการโดยการเชื่อมต่อระบบและ API

  6. การดูแลการเชื่อมต่อ

    ติดตามสถานะและแจ้งเตือนรายจุดเชื่อมต่อ คู่มือปฏิบัติงานสำหรับทีมปฏิบัติการ และการส่งข้อความที่ล้มเหลวใหม่อย่างควบคุมได้ ติดตั้งด้วย infrastructure as code ในบัญชีคลาวด์ขององค์กร

    ดำเนินการโดยวิศวกรรมคลาวด์และแพลตฟอร์ม

การเชื่อมต่อระบบ

ข้อมูลนำเข้าและการเชื่อมต่อระบบ

ข้อมูลนำเข้าและช่องทาง

  • คำสั่งซื้อจากร้านค้าออนไลน์และมาร์เก็ตเพลส
  • EDI และข้อความคำสั่งซื้อ B2B อื่น ๆ
  • ใบสั่งซื้อและการยืนยันจากผู้ขาย
  • คำขอบริการและรายงานงานภาคสนาม
  • เหตุการณ์ติดตามพัสดุและการส่งมอบจากผู้ขนส่ง
  • ใบแจ้งหนี้อิเล็กทรอนิกส์ Peppol พร้อมสถานะตอบกลับ และใบกำกับภาษีอิเล็กทรอนิกส์
  • รายการเดินบัญชีและการแจ้งชำระเงินจากธนาคาร

แกนหลักของโซลูชัน

กระบวนการที่เชื่อมต่อกัน

ระบบที่ทำงานร่วมกัน

  • SAP S/4HANA ด้านการขาย การจัดซื้อ และการเงินแพลตฟอร์มSAP
  • Salesforce Sales, Service และ Commerce Cloudแพลตฟอร์มSalesforce
  • Odoo ด้านการขาย สินค้าคงคลัง การจัดซื้อ และบัญชีแพลตฟอร์มOdoo
  • แพลตฟอร์มอีคอมเมิร์ซ มาร์เก็ตเพลส และ API ของผู้ขนส่ง
  • ระบบบริหารคลังสินค้าและระบบบริหารการขนส่ง
  • Peppol access point ระบบ e-Tax Invoice & e-Receipt ธนาคาร และผู้ให้บริการชำระเงิน
  • ระบบจัดการข้อมูลสินค้าและแพลตฟอร์มข้อมูล

การควบคุม

การควบคุมที่ออกแบบไว้ตั้งแต่ต้น

ขอบเขตการเข้าถึง

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

การตรวจทานโดยมนุษย์

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

การตรวจสอบย้อนหลังได้

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

การคุ้มครองข้อมูล

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

ความโปร่งใสของ AI

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

การวัดผล

สิ่งที่เราจะวัดผล

เราตกลงตัวชี้วัดเหล่านี้ร่วมกับคุณในขั้นสำรวจความต้องการ และใช้ค่าฐานจากบันทึกของระบบและการเชื่อมต่อปัจจุบันก่อนเปลี่ยนแปลงสิ่งใด

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

จะไม่กำหนดเป้าหมายจนกว่าจะมีค่าฐานสำหรับเปรียบเทียบ

การนำไปใช้งาน

วิธีที่เราจะนำขึ้นใช้งานจริง

  1. ระยะที่ 01

    สำรวจความต้องการและแผนผังกระบวนการ

    กระบวนการเดียว เช่น Order to Cash ของช่องทางขายเดียว และข้อยกเว้นประเภทเดียว เราทำแผนผังระบบ การเชื่อมต่อ เจ้าของข้อมูล และวิธีจัดการข้อยกเว้นในปัจจุบัน

    เกณฑ์การผ่านระยะ

    • ทำแผนผังกระบวนการ ระบบ และเจ้าของข้อมูลแล้ว
    • ตกลงข้อยกเว้นประเภทแรกและเกณฑ์การอนุมัติแล้ว
    • เก็บค่าฐานจากบันทึกปัจจุบันแล้ว

  2. ระยะที่ 02

    การเชื่อมต่อและไทม์ไลน์

    API และเหตุการณ์ที่มีเอกสารกำกับสำหรับระบบในขอบเขต และไทม์ไลน์ที่ทำงานคู่กับการเชื่อมต่อเดิมโดยไม่เปลี่ยนแปลงสิ่งเดิม

    เกณฑ์การผ่านระยะ

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

  3. ระยะที่ 03

    นำร่องหน้าจอจัดการข้อยกเว้น

    เอเจนต์เสนอแนวทางแก้ไขสำหรับข้อยกเว้นประเภทที่เลือก และคนอนุมัติทุกข้อเสนอ เราเปรียบเทียบข้อเสนอกับสิ่งที่เจ้าหน้าที่จะทำ

    เกณฑ์การผ่านระยะ

    • คุณภาพข้อเสนอผ่านเกณฑ์ที่ตกลง
    • กำหนดเกณฑ์และผู้อนุมัติตามประเภทการดำเนินการแล้ว
    • ฝ่ายการเงินและฝ่ายควบคุมภายในทบทวนบันทึกการตรวจสอบแล้ว

  4. ระยะที่ 04

    ขยายผลและปลดระวาง

    เพิ่มประเภทข้อยกเว้น ช่องทาง นิติบุคคล และกระบวนการ เช่น Procure to Pay โดยใช้ข้อตกลงเดิม การเชื่อมต่อแบบจุดต่อจุดเดิมปิดทีละเส้น

    เกณฑ์การผ่านระยะ

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

ใช้กับงานใดได้บ้าง

  • การผลิตและอุตสาหกรรม

    คำสั่งซื้อแบบผลิตตามสั่งและอะไหล่ จาก ERP ไปยังคลังสินค้าและผู้ขนส่ง โดยจับคู่การยืนยันจากผู้ขายและใบแจ้งหนี้กับใบสั่งซื้อ

  • พลังงานและสาธารณูปโภค

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

  • คมนาคมและโครงสร้างพื้นฐาน

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

  • ภาครัฐ

    Procure to Pay ของหน่วยงานภาครัฐ โดยจับคู่ใบแจ้งหนี้แบบมีโครงสร้างกับใบสั่งซื้อและใบรับสินค้าก่อนจ่ายเงิน ตามแนวทางที่หน่วยงานภาครัฐในยุโรปใช้

ตัวอย่างประกอบ

ผู้ผลิตชิ้นส่วนยานยนต์ที่ส่งออกไปยุโรป

สถานการณ์
ตัวอย่าง: ผู้ผลิตชิ้นส่วนยานยนต์ขนาดกลางที่ขายให้ลูกค้าในประเทศไทยผ่านทีมขายและ EDI และส่งออกให้ลูกค้าในยุโรป จากโรงงาน 2 แห่ง คำสั่งซื้อต้องพิมพ์ซ้ำในระบบ ERP ผู้ขนส่งแจ้งปัญหาการจัดส่งทางอีเมล และใบแจ้งหนี้ถึงลูกค้าในประเทศกับลูกค้าในยุโรปออกคนละวิธี
ระบบ
คำสั่งซื้อ สต็อก การจัดส่ง และใบแจ้งหนี้ไหลเป็นเหตุการณ์ระหว่าง EDI ระบบ ERP ระบบคลังสินค้า และผู้ขนส่ง และทุกคำสั่งซื้อมีไทม์ไลน์เดียว ใบแจ้งหนี้ถึงลูกค้าในยุโรปออกเป็นใบแจ้งหนี้อิเล็กทรอนิกส์แบบมีโครงสร้างผ่าน access point ตามรูปแบบที่ลูกค้าแต่ละประเทศต้องใช้ และใบกำกับภาษีในประเทศออกผ่าน e-Tax Invoice & e-Receipt เมื่อบริษัทเลือกใช้
การควบคุมโดยมนุษย์
สินค้าขาดสต็อกและการจัดส่งล้มเหลวเข้าสู่หน้าจอจัดการข้อยกเว้นเดียว เอเจนต์เสนอวันจัดส่งใหม่หรือการแบ่งส่ง ฝ่ายบริการลูกค้าอนุมัติทุกข้อเสนอ การเปลี่ยนราคาและใบลดหนี้ต้องให้ฝ่ายการเงินอนุมัติ
สิ่งที่เราจะวัด
สัดส่วนคำสั่งซื้อที่ไม่ต้องทำด้วยมือแยกตามลูกค้าและช่องทาง ข้อยกเว้นตามเหตุผลและเวลาแก้ไข และอัตราการปฏิเสธใบแจ้งหนี้อิเล็กทรอนิกส์แยกตามประเทศปลายทาง

ประเทศไทย

กระบวนการเดียว หลายประเทศ หลายข้อกำหนด

บริษัทไทยที่ขายให้ลูกค้าในยุโรปหรือมีบริษัทในเครือที่นั่น มักใช้กระบวนการ Order to Cash และ Procure to Pay เดียวกันบน ERP ผู้ขนส่ง และธนาคารที่ต่างกัน ประเทศในยุโรปบังคับใช้ใบแจ้งหนี้อิเล็กทรอนิกส์ในวันที่ต่างกัน และชุดมาตรการภาษีมูลค่าเพิ่มในยุคดิจิทัล (ViDA) ของสหภาพยุโรป ทำให้ใบแจ้งหนี้อิเล็กทรอนิกส์แบบมีโครงสร้างเป็นค่าเริ่มต้นสำหรับการขายระหว่างธุรกิจภายในสหภาพยุโรปตั้งแต่ 1 กรกฎาคม 2573 ในประเทศไทย e-Tax Invoice & e-Receipt ของกรมสรรพากรเป็นระบบที่ผู้ประกอบการเลือกใช้โดยสมัครใจ เราออกแบบชั้นเชื่อมต่อระบบชั้นเดียว โดยรูปแบบและเครือข่ายของแต่ละประเทศอยู่หลังเหตุการณ์ชุดเดียวกัน ข้อกำหนดใหม่จึงหมายถึงตัวเชื่อมต่อใหม่ ไม่ใช่กระบวนการใหม่

Data Act ของสหภาพยุโรปซึ่งใช้บังคับตั้งแต่ 12 กันยายน 2568 กำหนดกฎการย้ายระหว่างผู้ให้บริการประมวลผลข้อมูล เราจึงทำให้ข้อตกลงเหตุการณ์และการส่งออกข้อมูลพกพาได้ เอเจนต์บนหน้าจอจัดการข้อยกเว้นออกแบบโดยคำนึงถึง EU AI Act การเชื่อมต่อมีบันทึกการเข้าถึงและส่วนประกอบที่มีเอกสารกำกับ สำหรับลูกค้าในยุโรปที่ต้องแสดงความมั่นคงปลอดภัยของห่วงโซ่อุปทานตาม NIS2 และข้อมูลส่วนบุคคลของลูกค้าในประเทศไทยได้รับการคุ้มครองตาม PDPA

คำถามเกี่ยวกับกระบวนการที่เชื่อมต่อกัน

ต้องใช้แพลตฟอร์มเดียวสำหรับทุกอย่างหรือไม่

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

ต้องเปลี่ยนมิดเดิลแวร์ที่ใช้เชื่อมต่อระบบอยู่หรือไม่

ไม่ต้อง หากยังทำงานได้ดี เราสร้างบนแพลตฟอร์มเชื่อมต่อระบบหรือ message broker ที่คุณใช้อยู่ และเพิ่มข้อตกลง การติดตาม และการส่งใหม่ในจุดที่ยังขาด หากยังไม่มี เราสร้างแบบ cloud native อ่านเพิ่มเติมเรื่องการเชื่อมต่อระบบและ API

เอเจนต์ดำเนินการเองได้หรือไม่

ได้เฉพาะภายในเกณฑ์ที่คุณตกลงสำหรับแต่ละประเภทการดำเนินการ และเฉพาะการดำเนินการที่ผลกระทบต่ำและย้อนกลับได้ เช่น การส่งข้อความที่ล้มเหลวใหม่ การบันทึกรายการทางการเงิน ราคา วงเงินเครดิต และคำมั่นต่อลูกค้าต้องมีคนอนุมัติเสมอ อ่านบทความเอเจนต์ AI กับการอนุมัติโดยมนุษย์

ข้อกำหนดเรื่องใบแจ้งหนี้อิเล็กทรอนิกส์เข้ามาเกี่ยวข้องอย่างไร

ประเทศในยุโรปบังคับใช้ใบแจ้งหนี้อิเล็กทรอนิกส์ในวันที่ต่างกัน และชุดมาตรการภาษีมูลค่าเพิ่มในยุคดิจิทัล (ViDA) ของสหภาพยุโรปทำให้ใบแจ้งหนี้อิเล็กทรอนิกส์แบบมีโครงสร้างเป็นค่าเริ่มต้นสำหรับการขายระหว่างธุรกิจภายในสหภาพยุโรปตั้งแต่ 1 กรกฎาคม 2573 ในประเทศไทย e-Tax Invoice & e-Receipt ของกรมสรรพากรเป็นระบบที่ผู้ประกอบการเลือกใช้โดยสมัครใจ เราถือว่าใบแจ้งหนี้อิเล็กทรอนิกส์เป็นอีกเหตุการณ์หนึ่งในกระบวนการ: ออกจาก ERP ส่งผ่าน access point หรือระบบที่เกี่ยวข้อง และจัดการบนหน้าจอจัดการข้อยกเว้นเมื่อถูกปฏิเสธ ดูบทความคู่มือใบแจ้งหนี้อิเล็กทรอนิกส์ Peppol

จะหลีกเลี่ยงการเชื่อมต่อแบบจุดต่อจุดที่เปราะบางอีกชุดได้อย่างไร

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

ขอบเขตแรกมีลักษณะอย่างไร

กระบวนการเดียวและข้อยกเว้นประเภทเดียว เช่น Order to Cash ของช่องทางขายเดียว โดยมีสินค้าขาดสต็อกเป็นข้อยกเว้นแรก ขอบเขตนี้พิสูจน์เหตุการณ์ ไทม์ไลน์ และขั้นตอนการอนุมัติ ก่อนเพิ่มส่วนอื่น อ่านเรื่องแนวทางของเรา

ปรึกษาเรื่องคำสั่งซื้อและใบแจ้งหนี้

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

ปรึกษาเรื่องโซลูชันนี้ดูข้อมูลการเชื่อมต่อระบบ