EDI คืออะไร? ทำให้การสั่งซื้อ-รับคำสั่งซื้อระหว่างบริษัทง่ายขึ้นอย่างไร ── จาก FAX อีเมล และการคีย์ด้วยมือสู่การเชื่อมข้อมูล

“ใบสั่งซื้อมาทาง FAX จากคู่ค้า แล้วผู้รับผิดชอบคีย์เข้าสู่ระบบจัดการขาย” “เปิด Excel ที่แนบมากับอีเมล ตรวจรหัสสินค้ากับจำนวน แล้วคัดลอกข้อมูล” “หลังส่งของแล้วสร้างใบวางบิล ฝั่งรับก็คีย์เนื้อหาเดียวกันเข้าสู่ระบบบัญชี” ── ในธุรกรรมระหว่างบริษัท ข้อมูลคำสั่งซื้อหรือข้อมูลวางบิลชุดเดียวกัน บางครั้งถูกคีย์ซ้ำหลายรอบ โดยหลายบริษัทและหลายคน

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

บทความนี้จัดระเบียบว่า EDI คืออะไร ต่างจาก FAX และอีเมลอย่างไร และพอเอามาใช้แล้วงานของบริษัทง่ายขึ้นอย่างไร โดยใช้การสั่งซื้อ-รับคำสั่งซื้อเป็นตัวอย่าง คำเฉพาะจะจำกัดให้น้อย แต่ขอให้จับสี่คำนี้ไว้ก่อน

1. สรุปก่อนเลย

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

มูลนิธิส่งเสริมเศรษฐกิจและสังคมสารสนเทศแห่งญี่ปุ่น (JIPDEC) เป็นองค์กรที่ทำงานด้านมาตรฐานและการเผยแพร่ความรู้ในสาขาพาณิชย์อิเล็กทรอนิกส์ ความมั่นคงของข้อมูล และการคุ้มครองข้อมูลส่วนบุคคล และเปิดเผยข้อมูลเรื่องรหัสองค์กรและ EDI อย่างต่อเนื่อง บทความนี้ก็อ้างคำอธิบายขององค์กรนี้เรื่องนิยามและผลของ EDI คำอธิบายของ JIPDEC อธิบาย EDI ว่า “การที่บริษัทหรือหน่วยงานราชการเชื่อมคอมพิวเตอร์ด้วยเครือข่าย แล้วแลกเปลี่ยนใบสำคัญและเอกสารเป็นข้อมูลอิเล็กทรอนิกส์โดยอัตโนมัติ” และแนะนำนิยามตาม JIS X 7011 ควบคู่กัน

จุดประสงค์ของการนำ EDI มาใช้ ไม่ใช่แค่การเลิกใช้กระดาษ จุดประสงค์หลักคือลดงานแบบนี้

• การคีย์ด้วยมือขณะมอง FAX หรือ PDF
• การคัดลอกข้อมูลจาก Excel เข้าสู่ระบบจัดการขาย
• การตรวจเนื้อหาที่คีย์ด้วยตา
• งานค้นหาใบสั่งซื้อหรือใบวางบิล
• โทรศัพท์หรืออีเมลเพื่อถามสถานะคำสั่งซื้อ
• การรวมยอดข้อมูลยอดขาย สต็อก และวางบิลซ้ำอีกครั้ง

สรุปสั้น ๆ EDI คือกลไกที่ทำให้ข้อมูลซึ่งเคยหยุดค้างระหว่างบริษัท ไหลต่อไปได้ตามที่เป็น

แผนที่ความรู้ของบทความนี้

EDI คือกลไกแลกเปลี่ยนข้อมูลธุรกรรม เช่น ใบสั่งซื้อ ใบแจ้งจัดส่ง และใบวางบิล ระหว่างบริษัท ในรูปข้อมูลอิเล็กทรอนิกส์ตามรูปแบบที่ตกลงไว้ล่วงหน้า และตัดงานให้คนคีย์ซ้ำตั้งแต่ต้น นอกจากการลดข้อผิดพลาดจากการคัดลอกข้อมูลและความเร็วของการรับคำสั่งซื้อ ผลจะเกิดเมื่อเชื่อมข้อมูลที่รับมาไปถึงระบบสต็อก การจัดส่ง และการวางบิลภายในบริษัท ถ้าไม่นำเข้าแต่พิมพ์ให้คนทำ ก็ไม่ต่างจาก FAX รูปแบบที่ทำทีละคู่ค้าทำให้ต้นทุนเพิ่ม จึงควรเลือก EDI ที่อิงมาตรฐานหรือ EDI ร่วมสำหรับ SME เป็นทางเลือกที่ทำได้จริง Digital Invoice คือการนำแนวคิดนี้ไปใช้กับงานวางบิล และก่อนนำมาใช้ ควรทำรายการวิธีสั่งซื้อ-รับคำสั่งซื้อปัจจุบันทีละคู่ค้าให้เสร็จก่อนเลือกผลิตภัณฑ์

flowchart LR
    accTitle: แผนที่ความรู้การแลกเปลี่ยนข้อมูลระหว่างบริษัทด้วย EDI
    accDescr: แผนภาพที่แสดงว่า EDI ป้องกันการคีย์ซ้ำด้วยคนและข้อผิดพลาดจากการคัดลอกข้อมูลอย่างไร ทำให้การรับคำสั่งซื้อและการเชื่อมสต็อก การจัดส่ง และการวางบิลเป็นอัตโนมัติอย่างไร รูปแบบมาตรฐานและ EDI ร่วมสำหรับ SME ตอบปัญหาของรูปแบบรายคู่ค้าอย่างไร และ Digital Invoice นำแนวคิดนี้ไปใช้ในงานวางบิลอย่างไร
    edi["EDI (การแลกเปลี่ยนข้อมูลอิเล็กทรอนิกส์)"]
    manual_reentry["การให้คนคีย์ข้อมูลที่รับมาซ้ำ"]
    transcription_error["ข้อผิดพลาดจากการคีย์ซ้ำ"]
    order_processing_lead_time["lead time ของการประมวลผลคำสั่งซื้อ"]
    trading_partner_agreement["ข้อตกลง EDI กับคู่ค้า"]
    master_code_alignment["การจัดรหัสสินค้าและมาสเตอร์ให้ตรงกัน"]
    order_to_cash_integration["การเชื่อมสต็อก จัดส่ง และวางบิลหลังรับคำสั่งซื้อ"]
    edi_standard_format["EDI ที่อิงมาตรฐาน"]
    edi_individual_format["EDI แบบรายคู่ค้า"]
    sme_common_edi["EDI ร่วมสำหรับ SME"]
    digital_invoice["Digital Invoice"]
    current_process_inventory["การทำรายการวิธีสั่งซื้อ-รับคำสั่งซื้อปัจจุบัน"]
    order_status_visibility["การมองเห็นสถานะคำสั่งซื้อ"]
    task_personalization["งานที่ผูกกับบุคคล"]
    low_frequency_irregular_trading["ธุรกรรมที่เกิดน้อยและไม่เป็นแบบแผน"]
    high_frequency_recurring_trading["ธุรกรรมซ้ำแบบแผนที่เกิดบ่อย"]
    edi -->|"บรรเทา"| manual_reentry
    manual_reentry -->|"อาจก่อให้เกิด"| transcription_error
    edi -.->|"บรรเทา"| transcription_error
    edi -->|"บรรเทา"| order_processing_lead_time
    edi -->|"ต้องมี"| trading_partner_agreement
    edi -->|"ต้องมี"| master_code_alignment
    edi -->|"ทำอัตโนมัติ"| order_to_cash_integration
    edi -.->|"ต้องมี"| order_to_cash_integration
    edi -->|"ใช้"| edi_standard_format
    edi_standard_format -->|"แนวทางที่แนะนำสำหรับ"| edi_individual_format
    sme_common_edi -->|"แนวทางที่แนะนำสำหรับ"| edi_individual_format
    digital_invoice -.->|"ใช้"| edi
    current_process_inventory -->|"ควรทำก่อน"| edi
    edi -->|"ทำอัตโนมัติ"| order_status_visibility
    order_status_visibility -->|"บรรเทา"| task_personalization
    edi -.->|"ไม่แนะนำให้ใช้กับ"| low_frequency_irregular_trading
    edi -->|"แนวทางที่แนะนำสำหรับ"| high_frequency_recurring_trading

ในแผนภาพ เส้นทึบหมายถึงความสัมพันธ์ที่ถือเสมอ และเส้นประหมายถึงความสัมพันธ์ที่มีเงื่อนไข (เงื่อนไขอยู่ในการอธิบายของแต่ละความสัมพันธ์ในหน้าละเอียด) รายการความสัมพันธ์ทั้งหมด (รวม 17 รายการ พร้อมหลักฐานและระดับความเชื่อมั่น) และนิยามของแนวคิดหลักรวบรวมไว้ที่ หน้าละเอียดของแผนที่ความรู้ (เป็นภาษาญี่ปุ่น) ข้อมูล: JSON-LD / Turtle

2. งานสั่งซื้อ-รับคำสั่งซื้อที่ไม่มี EDI เกิดอะไรขึ้น

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

flowchart TD
    accTitle: กระบวนการสั่งซื้อ-รับคำสั่งซื้อเมื่อไม่มี EDI
    accDescr: แผนภาพที่แสดงว่าข้อมูลคำสั่งซื้อถูกพิมพ์หรือแปลงเป็น PDF แล้วส่งทาง FAX หรืออีเมล ฝั่งผู้รับคีย์ซ้ำ จากนั้นฝั่งผู้สั่งซื้อคีย์ข้อมูลจัดส่งและข้อมูลวางบิลเข้าสู่ระบบตนเองอีกครั้ง
    A["ฝั่งผู้สั่งซื้อคีย์ข้อมูลคำสั่งซื้อ"] --> B["พิมพ์ใบสั่งซื้อหรือแปลงเป็น PDF"]
    B --> C["ส่งทาง FAX หรืออีเมล"]
    C --> D["ผู้รับผิดชอบฝั่งผู้รับตรวจเนื้อหา"]
    D --> E["คีย์ซ้ำเข้าสู่ระบบฝั่งผู้รับ"]
    E --> F["สร้างข้อมูลจัดส่งและข้อมูลวางบิล"]
    F --> G["ฝั่งผู้สั่งซื้อคีย์เข้าสู่ระบบตนเองอีกครั้ง"]

ภาพ 1: กระบวนการสั่งซื้อ-รับคำสั่งซื้อเมื่อไม่มี EDI ข้อมูลถูกคีย์ซ้ำด้วยมือสองครั้ง

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

ปัญหาไม่ใช่ว่าข้อมูลยังไม่เป็นอิเล็กทรอนิกส์ ปัญหาคือข้อมูลที่ถูกสร้างเป็นข้อมูลแล้ว ถูกแปลงเป็นเอกสารให้คนอ่าน แล้วฝั่งรับแปลงกลับเป็นข้อมูลอีกครั้ง

3. ใช้ EDI แล้วการสั่งซื้อ-รับคำสั่งซื้อเปลี่ยนอย่างไร

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

flowchart LR
    accTitle: กระบวนการสั่งซื้อ-รับคำสั่งซื้อเมื่อใช้ EDI
    accDescr: แผนภาพที่แสดงว่าข้อมูลคำสั่งซื้อไหลจากระบบจัดซื้อฝั่งผู้สั่งซื้อผ่าน EDI ไปยังระบบจัดการขายฝั่งผู้รับ และข้อมูลยืนยันการรับคำสั่งซื้อ การแจ้งจัดส่ง และข้อมูลวางบิลกลับมาตามเส้นทางเดียวกัน
    A[ระบบจัดซื้อฝั่งผู้สั่งซื้อ] --> B[ข้อมูลคำสั่งซื้อ]
    B --> C[การส่งและแปลงผ่าน EDI]
    C --> D[ระบบจัดการขายฝั่งผู้รับคำสั่งซื้อ]
    D --> E[ยืนยันการรับคำสั่งซื้อ]
    D --> F[แจ้งการจัดส่ง]
    D --> G[ข้อมูลวางบิล]
    E --> C
    F --> C
    G --> C
    C --> A

ภาพ 2: กระบวนการสั่งซื้อ-รับคำสั่งซื้อเมื่อใช้ EDI ขั้นตอน “พิมพ์” “ตรวจด้วยตา” และ “คีย์ซ้ำ” ที่อยู่ในภาพ 1 หายไปแล้ว

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

คำอธิบายของ JIPDEC อธิบาย EDI ว่าเป็นกลไกที่แปลงข้อมูลรูปแบบเฉพาะของแต่ละบริษัทไปสู่รูปแบบมาตรฐาน แล้วฝั่งรับแปลงจากรูปแบบมาตรฐานกลับสู่รูปแบบของตนเอง

4. EDI ต่างจากอีเมล PDF และ Excel อย่างไร

บางครั้งคิดว่า “ส่งใบสั่งซื้อเป็น PDF ทางอีเมลแล้ว จึงถือว่าทำอิเล็กทรอนิกส์แล้ว” จริงอยู่ เร็วกว่าส่งกระดาษทางไปรษณีย์ และเก็บรักษาง่ายขึ้น แต่ถ้าฝั่งรับยังคีย์เข้าสู่ระบบขณะมอง PDF งานคีย์เองยังอยู่ ความต่างจัดได้ดังนี้

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

อย่างไรก็ตาม การใช้ PDF หรือ Excel เองไม่ใช่เรื่องเสีย หัวใจคือข้อมูลที่รับมาถูกประมวลผลต่ออย่างไร “คนมอง PDF แล้วคีย์” “เปิด Excel แล้วคัดลอก” “นำ CSV เข้าสู่ระบบโดยตรง” “ลงทะเบียนอัตโนมัติผ่าน API” ── แม้เป็น “ไฟล์อิเล็กทรอนิกส์” เหมือนกัน ภาระของงานด้านหลังต่างกันสิ้นเชิง ตอนตัดสินผลของ EDI ต้องดูไม่ใช่แค่วิธีส่ง แต่ดูว่าหลังรับแล้วคนทำอะไรอยู่

4.1. แผนที่ของสิ่งที่ถูกเรียกว่า “EDI”

ถึงตรงนี้เขียนรวมว่า “EDI” แต่พอเริ่มพิจารณาจริง จะเจอหลายชื่อ ถ้าจับตำแหน่งของภาพรวมไว้ก่อน จะไม่งงตอนอ่านคำอธิบายผลิตภัณฑ์

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

5. ข้อมูลที่แลกเปลี่ยนด้วย EDI ได้

EDI ไม่ใช่กลไกเฉพาะใบสั่งซื้อ สามารถแลกเปลี่ยนข้อมูลหลากชนิดที่เกิดในธุรกรรมระหว่างบริษัทได้

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

1. ตรวจว่าเลขที่คำสั่งซื้อซ้ำหรือไม่
2. ตรวจว่ารหัสสินค้ามีอยู่หรือไม่
3. จองสต็อก
4. คำนวณกำหนดส่ง
5. ส่งคำสั่งจัดส่งไปคลัง
6. ส่งยืนยันการรับคำสั่งซื้อกลับฝั่งผู้สั่งซื้อ

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

6. EDI ทำให้งานของบริษัทง่ายขึ้นอย่างไร

ดังที่เห็นในบทที่ 2 ถึงบทที่ 4 ผลโดยตรงของ EDI คือ “งานคีย์ขณะมองใบสั่งซื้อหายไป” บทนี้จัดว่าหลังจากนั้นเกิดอะไรขึ้น เป็น 6 ข้อ ผลไม่ได้จำกัดแค่การลดชั่วโมงคีย์

6.1. เวลาของผู้รับผิดชอบหันไปรับมือข้อยกเว้นได้

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

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

ในสภาพที่ถูกงานคีย์ไล่ งานตรวจเหล่านี้มักถูกเลื่อน คุณค่าของ EDI อยู่ที่ “เอาเวลาที่ลดได้ไปใช้กับคำสั่งซื้อที่ควรใส่ใจ” มากกว่า “งานลดลง”

6.2. ลดข้อผิดพลาดจากการคีย์ได้

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

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

6.3. ประมวลผลการรับคำสั่งซื้อได้เร็วขึ้น

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

กับ EDI นำข้อมูลที่รับเข้าสู่ระบบอัตโนมัติได้ จึงเริ่มงานรับคำสั่งซื้อ ตรวจสต็อก คำนวณกำหนดส่ง ส่งคำสั่งจัดส่งไปคลัง และตอบยืนยันการรับคำสั่งซื้อ ได้ทันทีหลังรับคำสั่งซื้อ ถ้าการประมวลผลการรับคำสั่งซื้อเร็วขึ้น เวลาก่อนจัดส่งก็สั้นลงได้ง่าย JIPDEC ก็ยกผลของ EDI ว่า ประสิทธิภาพและความเร็วของงานธุรการดีขึ้น การส่งของแบบ just-in-time, lead time ที่สั้นลง และการลดสต็อก

6.4. ดูสถานะคำสั่งซื้อได้ง่ายขึ้น

เมื่อกระดาษ, FAX, อีเมล และ Excel ปนกัน การไล่ว่า “คำสั่งซื้อนั้นตอนนี้อยู่สถานะใด” ใช้เวลา เพราะต้องไล่ดูกล่องจดหมายของผู้รับผิดชอบ โฟลเดอร์ร่วม แฟ้มกระดาษ และระบบจัดการขาย ตามลำดับ

กับ EDI ใช้เลขที่คำสั่งซื้อเป็นต้นเป็นเกณฑ์ แล้วผูกข้อมูลต่อไปนี้มาจัดการได้

• รับคำสั่งซื้อเมื่อใด
• นำเข้าสำเร็จหรือไม่
• ส่งยืนยันการรับคำสั่งซื้อกลับแล้วหรือยัง
• จัดส่งแล้วหรือยัง
• ตรวจรับแล้วหรือยัง
• วางบิลแล้วหรือยัง
• เกิดข้อผิดพลาดหรือการส่งซ้ำหรือไม่

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

6.5. เชื่อมต่อไปยังงานสต็อก การจัดส่ง และบัญชีได้

ถ้าเชื่อมข้อมูลที่รับมากับระบบภายในบริษัท งานด้านหลังหลังจากลงทะเบียนรับคำสั่งซื้อก็ทำอัตโนมัติได้

flowchart TD
    accTitle: งานด้านหลังในบริษัทหลังจากรับข้อมูลคำสั่งซื้อ
    accDescr: แผนภาพที่แสดงงานด้านหลังตั้งแต่รับข้อมูลคำสั่งซื้อ ลงทะเบียนรับคำสั่งซื้อ จองสต็อก คำสั่งจัดส่ง บันทึกรายได้ สร้างข้อมูลวางบิล จนถึงกระทบยอดรับเงิน
    A["รับข้อมูลคำสั่งซื้อ"] --> B["ลงทะเบียนรับคำสั่งซื้อ"]
    B --> C["จองสต็อก"]
    C --> D["คำสั่งจัดส่ง"]
    D --> E["บันทึกรายได้"]
    E --> F["สร้างข้อมูลวางบิล"]
    F --> G["กระทบยอดรับเงิน"]

ภาพ 3: งานด้านหลังในบริษัทที่ข้อมูลคำสั่งซื้อที่รับมาเดินผ่าน ว่าเชื่อมไปได้ไกลแค่ไหนคือสิ่งที่กำหนดผลของการนำมาใช้

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

6.6. ใช้ข้อมูลธุรกรรมกับการตัดสินใจทางธุรกิจได้

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

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

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

7. คิดผลของ EDI จากตัวอย่างง่าย

สมมติบริษัทค้าส่งรับคำสั่งซื้อ 100 รายการต่อวันทาง FAX หรืออีเมล และใช้เวลาเฉลี่ย 3 นาทีต่อรายการในการคีย์เข้าสู่ระบบจัดการขายแล้วตรวจเนื้อหา

100 รายการ × 3 นาที = 300 นาที → 5 ชั่วโมงต่อวัน

หลังนำ EDI มาใช้ สมมติให้นำเข้าอัตโนมัติ 80 รายการ และให้คนตรวจเหลือ 20 รายการ จะได้แบบนี้

20 รายการ × 3 นาที = 60 นาที → 1 ชั่วโมงต่อวัน

เป็นตัวอย่างที่ทำให้เรียบง่าย แต่งานคีย์จาก 5 ชั่วโมงเหลือ 1 ชั่วโมง ในทางปฏิบัติ นอกจากนี้ยังมีโอกาสที่เวลาตรวจ FAX ที่อ่านยาก การแก้คีย์ผิด โทรถามเนื้อหาคำสั่งซื้อ งานค้นหาใบสั่งซื้อ การรวมรายการคำสั่งซื้อ และการส่งต่องานระหว่างผู้รับผิดชอบ จะลดลงด้วย ผลของการนำ EDI มาใช้ ไม่ได้อยู่ที่ต้นทุนตรงอย่าง “ค่ากระดาษลด” อย่างเดียว ความหมายใหญ่คือลดงานตรวจ คีย์ และแก้เล็ก ๆ ที่เกิดซ้ำทุกวันได้

7.1. คำนวณด้วยตัวเลขของตนเอง

100 รายการกับ 3 นาทีด้านบนเป็นเพียงตัวอย่าง ลองใส่ตัวเลขของตนเองแล้วคำนวณ ต้องการแค่สี่ตัวเลข

(1) จำนวนคำสั่งซื้อต่อวัน                         …… A รายการ
(2) เวลาคีย์และตรวจต่อ 1 รายการ                 …… B นาที
(3) สัดส่วนที่คาดว่าทำอัตโนมัติด้วย EDI ได้       …… C %
(4) จำนวนวันทำการใน 1 ปี                         …… D วัน

เวลาที่ใช้ในปัจจุบัน     = A × B                        (นาที/วัน)
เวลาที่เหลือหลังใช้ EDI  = A × (1 - C ÷ 100) × B        (นาที/วัน)
เวลาที่ลดได้ต่อวัน       = A × (C ÷ 100) × B            (นาที/วัน)
เวลาที่ลดได้ต่อปี        = เวลาที่ลดได้ต่อวัน × D ÷ 60  (ชั่วโมง/ปี)

“(3) สัดส่วนที่ทำอัตโนมัติได้” ถูกกำหนดด้วยปริมาณข้อยกเว้นที่จะพูดในบทถัดไป อย่าตั้งค่าสูงตั้งแต่ต้น ให้เริ่มจากนับว่าคู่ค้าอันดับต้นไม่กี่รายที่จำนวนรายการมาก ครองกี่ % ของทั้งหมด จำนวนรายการแยกตามคู่ค้าจะออกมาเมื่อทำตารางในบทที่ 11.1

อนึ่ง ตัวเลขจากประมาณนี้คือเวลาที่ลดได้ ไม่ใช่ค่าแรงที่ตัดได้ทันที ตัวเลขจะอธิบายเป็นผลของการนำมาใช้ได้ก็ต่อเมื่อตัดสินด้วยว่าจะเอาเวลาที่ว่างไปทำอะไร (ยกระดับคุณภาพการรับมือข้อยกเว้น, โยนไปงานอื่น, ลดล่วงเวลา)

8. ข้อดีของ EDI มองทีละฝ่ายงาน

การปรับปรุงงานด้วย EDI ไม่จำกัดแค่ฝ่ายรับคำสั่งซื้อ

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

9. นำ EDI มาใช้แล้ว ไม่ได้แปลว่างานทั้งหมดเป็นอัตโนมัติ

EDI เป็นกลไกที่สะดวก แต่ไม่ได้แปลว่าแค่นำมาใช้แล้วงานทั้งหมดจะเป็นอัตโนมัติ

9.1. ต้องมีข้อตกลงกับคู่ค้า

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

ข้อตกลงเหล่านี้มีชั้น JIPDEC จัดเป็น 5 ชั้น ถ้าคุยเรื่อง “จะใส่ EDI” แล้วเข้าใจผิดว่ากำลังคุยชั้นใด การถกจะไม่ชนกัน

การเทียบผลิตภัณฑ์หรือบริการมักเอียงไปสองชั้นบน (โปรโตคอลการสื่อสารกับ syntax rule) แต่สิ่งที่ยากตอนนำมาใช้คือสามชั้นล่าง โดยเฉพาะ “message และรายการข้อมูล” คืองานจัดรหัสใน 9.2 ที่จะพูดถัดไป ถ้าไม่คุยกับคู่ค้าให้แน่นตรงนี้แล้วเลือกแต่ผลิตภัณฑ์ จะย้อนกลับมาแก้ทีหลัง

9.2. ต้องจัดรหัสสินค้าและรายการอื่นให้ตรงกัน

ฝั่งผู้สั่งซื้อกับฝั่งผู้รับ บางครั้งใช้รหัสต่างกันสำหรับสินค้าเดียวกัน เช่น ฝั่งผู้สั่งซื้อใช้รหัส A-001 ฝั่งผู้รับใช้ 100245 กรณีนี้ต้องมีตารางคู่สำหรับแปลงรหัส นอกจากรหัสสินค้า ยังจัดรายการแบบนี้ด้วย

• รหัสคู่ค้า
• รหัสจุดส่งของ
• หน่วย
• จำนวนต่อหีบห่อ
• ประเภทภาษี
• สกุลเงิน
• รูปแบบวันที่
• รหัสอักขระ

แม้ส่งรับข้อมูลได้ ถ้าความหมายของฟิลด์ไม่ตรงกัน ก็ไม่กลายเป็นธุรกรรมที่ถูกต้อง

9.3. งานข้อยกเว้นยังเหลือ

แม้ประมวลผลคำสั่งซื้อปกติอัตโนมัติได้ ธุรกรรมข้อยกเว้นอย่างสต็อกไม่พอ, สินค้าเลิกผลิต, ราคาต่างจากปกติ, คำสั่งซื้อเร่งด่วน, การแก้คำสั่งซื้อ, การยกเลิกคำสั่งซื้อ, การส่งของแบ่งงวด, การคืนของ และข้อมูลไม่ครบ ยังเหลือ

สิ่งสำคัญไม่ใช่ฝืนทำอัตโนมัติทั้งหมด การออกแบบที่ทำได้จริงคือแยกงานปกติกับงานข้อยกเว้น งานปกติทำอัตโนมัติ แล้วส่งเฉพาะรายที่ต้องตัดสินให้คน “คำสั่งซื้อที่คนควรดู” ในบทที่ 6.1 คือข้อยกเว้นที่พูดตรงนี้

9.4. เกิดช่วงใช้ร่วมกับ FAX และอีเมล

ไม่ใช่คู่ค้าทุกรายจะย้ายสู่ EDI พร้อมกันได้ ดังนั้นช่วงต้นของการนำมาใช้ วิธีรับหลายแบบอย่าง EDI, หน้าจอเว็บ, อัปโหลด CSV, อีเมล, FAX และโทรศัพท์ อาจเดินขนานกัน

ในสภาพนี้ แม้ใส่ EDI แล้ว ก็ยังลดผู้รับผิดชอบงานเดิมทันทีไม่ได้ เพื่อให้ผลสูงขึ้น ต้องย้ายจากคู่ค้าที่ปริมาณธุรกรรมมากก่อน แล้วลดจำนวนรายการที่ยังทำด้วยมือ JIPDEC ก็ชี้ว่า ถ้ายังเหลืองานที่คนทำอย่าง FAX และโทรศัพท์ ยังต้องมีคนรับมืองานนั้น และจะได้ผลด้านประสิทธิภาพไม่เต็มที่ เหตุผลที่ในประมาณการบทที่ 7.1 ควรตั้ง “สัดส่วนที่ทำอัตโนมัติได้” ให้ต่ำไว้ ก็อยู่ตรงนี้

10. บริษัทที่ EDI เหมาะด้วย

EDI เป็นกลไกที่ได้ผลง่าย โดยเฉพาะกับบริษัทแบบนี้

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

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

การตัดสินว่าจะนำ EDI มาใช้หรือไม่ ไม่ได้ดูจากขนาดบริษัทอย่างเดียว สำนักงานวิสาหกิจขนาดกลางและขนาดย่อมของญี่ปุ่น ก็จัดทำ “EDI ร่วมสำหรับ SME” ที่ทำให้งานสั่งซื้อ-รับคำสั่งซื้อเป็นมาตรฐานสำหรับ SME และแสดงประสิทธิภาพงานจากการลดเครื่องเฉพาะทางและกระดาษ แล้วจัดการใบสำคัญเป็นข้อมูลจุดเดียว สิ่งที่ควรมองไม่ใช่จำนวนพนักงาน แต่เป็นปริมาณงานคีย์ ตรวจ และคัดลอกข้อมูลที่เกิดซ้ำ

11. วิธีเดินเมื่อพิจารณานำ EDI มาใช้

ตอนพิจารณา EDI ไม่ต้องเลือกผลิตภัณฑ์หรือวิธีสื่อสารตั้งแต่ต้น ให้จัดระเบียบงานปัจจุบันก่อน

11.1. ทำรายการวิธีสั่งซื้อ-รับคำสั่งซื้อปัจจุบัน

จัดข้อมูลต่อไปนี้ทีละคู่ค้า

พอจัดแบบนี้ จะเห็นคู่ค้าหรืองานที่ได้ผลจากการทำ EDI มาก จำนวนรายการและเวลาที่จะใส่ในประมาณการบทที่ 7.1 ก็เอาจากตารางนี้ได้

11.2. เริ่มจากหนึ่งรายที่ปริมาณธุรกรรมมาก

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

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

ตั้งวิธีปฏิบัติงานกับหนึ่งรายแล้ว จึงขยายไปคู่ค้ารายอื่น

11.3. จำกัดสิ่งที่แลกเปลี่ยน

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

1. ขั้นที่ 1: ข้อมูลคำสั่งซื้อ
2. ขั้นที่ 2: ยืนยันการรับคำสั่งซื้อ / ตอบกำหนดส่ง
3. ขั้นที่ 3: ใบแจ้งจัดส่ง
4. ขั้นที่ 4: ข้อมูลวางบิล

การเพิ่มเป้าทีละขั้น ทำให้ดูผลได้โดยไม่กระแทกหน้างานมากเกินไป

11.4. ตรวจการเชื่อมต่อเข้าสู่ระบบภายในบริษัท

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

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

สิ่งสำคัญคือตรวจวิธีเชื่อมกับระบบเดิม ก่อนเลือกผลิตภัณฑ์ ถ้าตรงนี้รู้ว่า “นำเข้า-ส่งออก CSV ไม่ได้” หรือ “ไม่มี API” สิ่งที่มาก่อนการเลือกบริการ EDI คือการแก้ฝั่งระบบเดิม หรือการเตรียมกลไกตัวกลาง

12. ตัวชี้วัดที่อยากวัดหลังนำ EDI มาใช้

พอใส่ EDI แล้ว อย่าจบที่ “ใช้ได้แล้ว” ให้ตรวจว่างานเปลี่ยนไปแค่ไหน ตัวอย่างเช่น เทียบตัวชี้วัดต่อไปนี้ก่อนและหลังนำมาใช้ ถ้าเอาตัวเลขที่ใช้ในประมาณการบทที่ 7.1 ไปแทนด้วยค่าวัดจริง จะเห็นช่องว่างระหว่างที่คาดกับที่เป็นจริงตามนั้น

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

สิ่งสำคัญของ EDI ไม่ใช่ว่าส่งข้อมูลได้หรือไม่ ประเมินจากว่างานมือลดจริง การประมวลผลเร็วขึ้น และความผิดพลาดลดลงหรือไม่

สรุป

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

การเปลี่ยนแปลงหลักที่คาดจาก EDI มีดังนี้

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

อย่างไรก็ตาม การทำสัญญาบริการ EDI อย่างเดียวไม่พอ ต้องจัดข้อมูลอย่างรหัสสินค้า ตกลงกฎการปฏิบัติงานกับคู่ค้า และทำให้ดึงข้อมูลเข้าสู่ระบบภายในที่มีอยู่ได้

จุดตั้งต้นของการนำ EDI มาใช้ ไม่ใช่ “จะใช้ผลิตภัณฑ์ใด” แต่คือการไล่ว่าในงานปัจจุบันข้อมูลชุดเดียวกันถูกคีย์กี่ครั้ง หาจุดที่คนขนข้อมูลระหว่าง FAX, อีเมล, Excel, หน้าจอเว็บ และระบบจัดการขาย แล้วแทนที่งานที่มีจำนวนรายการมากและเป็นแบบแผน ด้วยการเชื่อมข้อมูลตามลำดับ นั่นคือทางที่ทำได้จริง

ถึงผู้ที่กำลังพิจารณาการเชื่อมข้อมูลในงานสั่งซื้อ-รับคำสั่งซื้อ

หากอยากทำให้งานสั่งซื้อ-รับคำสั่งซื้อระหว่างบริษัทมีประสิทธิภาพขึ้น แต่ไม่รู้ว่าจะมองงาน FAX อีเมล และ Excel ปัจจุบันใหม่จากตรงไหน จำเป็นต้องจัดระเบียบขั้นตอนของงานก่อน

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

KomuraSoft LLC รับปรึกษาเรื่องการจัดสภาพปัจจุบันและวิธีทำให้เกิดขึ้นจริง สำหรับการเชื่อมงานที่รวมแอปธุรกิจ Windows เดิม, CSV, ไฟล์ความยาวคงที่, ฐานข้อมูล และระบบเว็บ

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

อ้างอิง

• JIPDEC (มูลนิธิส่งเสริมเศรษฐกิจและสังคมสารสนเทศแห่งญี่ปุ่น), EDI คืออะไร. ว่าด้วยนิยามของ EDI (การที่บริษัทหรือหน่วยงานราชการเชื่อมคอมพิวเตอร์ด้วยเครือข่าย แล้วแลกเปลี่ยนใบสำคัญและเอกสารเป็นข้อมูลอิเล็กทรอนิกส์โดยอัตโนมัติ), นิยามตาม JIS X 7011, กลไกแปลงระหว่างรูปแบบเฉพาะของแต่ละบริษัทกับรูปแบบมาตรฐาน, และการที่ภาพสแกนหรืออีเมลข้อความทั่วไปถูกแยกออกจากข้อมูล EDI
• JIPDEC, ข้อดีของ EDI และความจำเป็นของมาตรฐาน EDI. ว่าด้วยประสิทธิภาพและความเร็วของงานธุรการ การส่งของแบบ just-in-time, lead time ที่สั้นลง การลดสต็อก การตัดข้อผิดพลาดจากคน การใช้กับการวิเคราะห์สินค้าขายดี, spend analysis และการพยากรณ์ความต้องการ, การที่ถ้าไม่ตามมาตรฐานต้องมีกลไกแปลงทีละคู่ค้าและต้นทุนไม่คุ้ม, ห้าเรื่องที่ต้องตกลง (โปรโตคอลการสื่อสาร, syntax rule, message และรายการข้อมูล, ข้อตกลงการปฏิบัติงาน, ข้อตกลงพื้นฐานทางการค้า), และการที่ถ้าพิมพ์ข้อมูลที่รับมาให้คนทำ แทบไม่ต่างจาก FAX
• สำนักงานวิสาหกิจขนาดกลางและขนาดย่อมของญี่ปุ่น, การทำดิจิทัลงานสั่งซื้อ-รับคำสั่งซื้อ (EDI ร่วมสำหรับ SME). ว่าด้วยประสิทธิภาพงานที่สูงขึ้น ข้อผิดพลาดจากคนที่ลดลง และการค้นหาบันทึกธุรกรรมที่ดีขึ้นจากการทำดิจิทัลงานสั่งซื้อ-รับคำสั่งซื้อ และการจัดทำ “EDI ร่วมสำหรับ SME” ที่ทำให้งานสั่งซื้อ-รับคำสั่งซื้อเป็นมาตรฐานสำหรับ SME
• สำนักงานดิจิทัลของญี่ปุ่น, JP PINT (สเปกมาตรฐานของใบกำกับอิเล็กทรอนิกส์). ว่าด้วยสำนักงานดิจิทัลของญี่ปุ่น ในฐานะ Peppol Authority ของญี่ปุ่น บริหารและเปิดเผยสเปกมาตรฐานใบกำกับอิเล็กทรอนิกส์ของญี่ปุ่น “JP PINT” ที่แลกเปลี่ยนบนเครือข่าย Peppol

บทความที่เกี่ยวข้อง

บทความล่าสุดที่มีแท็กเดียวกัน เพื่อเจาะลึกหัวข้อใกล้เคียง

หัวข้อที่เกี่ยวข้อง

หน้าเหล่านี้วางหัวข้อไว้ในบริบทที่กว้างขึ้นของบริการและการตัดสินใจ

บริการที่เกี่ยวข้องกับหัวข้อนี้

บทความนี้เกี่ยวข้องโดยตรงกับบริการต่อไปนี้

โปรไฟล์ผู้เขียน

หน้าแนะนำผู้เขียนบทความ

Go Komura

ผู้แทนของ KomuraSoft LLC

เชี่ยวชาญด้านการพัฒนาซอฟต์แวร์ Windows ที่ปรึกษาเทคนิค และการตรวจสอบบั๊ก โดยเฉพาะโปรเจกต์ที่มีระบบเดิมและบั๊กที่ทำซ้ำได้ยาก