ย้ายการรับคำสั่งซื้อทาง FAX ไปเว็บ ── ออกแบบช่วงใช้งานคู่ขนานและการย้ายแบบเป็นขั้น

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

บทความนี้เป็นภาคต่อ จาก “เข้าใจกลไก” ก้าวไปอีกขั้นเป็น จะย้ายอย่างไร

คำปรึกษาแบบ “อยากย้ายการรับคำสั่งซื้อทาง FAX ไปเว็บ” มักต่อด้วยประโยคแบบนี้

“แต่มีคู่ค้าที่ใช้ได้แค่ FAX”

“ระบบจัดการขายอยากใช้ของเดิม”

“ช่วงสลับระบบ คำสั่งซื้อหยุดไม่ได้”

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

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

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

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

จุดสำคัญตอนวางแผนย้ายการรับคำสั่งซื้อทาง FAX ไปเว็บมีดังนี้

• ตั้งเป้าไม่ใช่ที่ “เลิกใช้ FAX” แต่ที่ “ลดจำนวนคำสั่งซื้อที่คนต้องคีย์”
• ตั้งต้นว่า ช่วงที่ FAX กับเว็บเดินคู่กันต้องเกิดอยู่แล้ว แล้วออกแบบระยะเวลาและวิธีวัดไว้ก่อน
• ช่องทางรับ (channel) จะมีหลายช่องก็ได้ แต่ การประมวลผลคำสั่งซื้อภายในบริษัทให้รวมเป็นสายเดียว
• อย่าขอให้คีย์บนหน้าจอเว็บทันที ให้เตรียม การนำเข้า CSV ในฐานะรูปแบบกลาง
• หน้าจอสั่งซื้อผ่านเว็บเปิดมาสเตอร์สินค้าและคู่ค้าให้คู่ค้าเห็นตรง ๆ จึง จัดระเบียบมาสเตอร์ก่อน
• อย่าสลับคู่ค้าทั้งหมดพร้อมกัน จัดกลุ่มตามจำนวนรายการและความพร้อมร่วมมือ แล้วย้ายทีละกลุ่ม

JIPDEC (จิปเดก, มูลนิธิส่งเสริมเศรษฐกิจและสังคมสารสนเทศแห่งญี่ปุ่น ซึ่งเป็นองค์กรที่รู้จักจากระบบ Privacy Mark และการบริหารรหัสองค์กรมาตรฐาน) ก็ระบุในหน้าอธิบายโครงการรหัสองค์กรมาตรฐาน “ข้อดีของ EDI และความจำเป็นของมาตรฐาน” ว่า “หากยังเหลืองานที่คนทำและการรับมือ FAX กับโทรศัพท์ จำเป็นต้องจัดคนไว้สำหรับงานนั้น จึงทำอัตโนมัติหรือใช้เครื่องจักรได้ไม่ถึง 100% และจะได้ผลด้านประสิทธิภาพไม่เต็มที่” เพราะอย่างนั้น ช่วงใช้งานคู่ขนานจึงไม่ควรปล่อยเป็น “สิ่งที่เกิดเพราะเลี่ยงไม่ได้” แต่ควรถือแผนทำให้ช่วงนั้นสั้นลงเป็นเรื่องที่ต้องออกแบบเอง

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

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

flowchart LR
    accTitle: แผนที่ความรู้การย้ายคำสั่งซื้อทาง FAX ไปเว็บแบบเป็นขั้น
    accDescr: แผนภาพที่แสดงการออกแบบการย้ายแบบเป็นขั้น โดยตั้งเป้าที่การลดจำนวนคำสั่งซื้อที่คนต้องคีย์ ใช้การนำเข้า CSV เป็นรูปแบบกลาง จัดกลุ่มคู่ค้าและทำแม่แบบกับไพลอต แล้วลดช่วงใช้งานคู่ขนานให้สั้นลงด้วยเส้นตาย
    fax_order_web_migration["การย้ายคำสั่งซื้อทาง FAX ไปเว็บ (แบบเป็นขั้น)"]
    dual_operation_period["ช่วงใช้งานคู่ขนาน"]
    transcription_volume_reduction_goal["เป้าลดจำนวนคำสั่งซื้อที่คนต้องคีย์"]
    all_at_once_web_migration["การย้ายไปเว็บทั้งหมดในครั้งเดียว"]
    indefinite_dual_operation["การตรึงช่วงคู่ขนานแบบไม่มีกำหนด"]
    dual_operation_deadline_target["เส้นตายและค่าเป้าหมายของช่วงใช้งานคู่ขนาน"]
    channel_migration_kpi["การวัดจำนวนแยกตามช่องทาง"]
    receiving_channel_field["คอลัมน์ช่องทางรับ"]
    csv_import_intermediate_form["การนำเข้า CSV ในฐานะรูปแบบกลาง"]
    csv_file_format_spec["ข้อตกลงรูปแบบไฟล์ CSV"]
    master_data_readiness["การจัดระเบียบมาสเตอร์สินค้าและคู่ค้า"]
    pilot_partner_approach["การทำแม่แบบกับไพลอต 1 ราย"]
    partner_classification["การจัดกลุ่มคู่ค้า (A/B/C)"]
    unified_order_channel_processing["ช่องทางรับหลายช่อง งานภายในสายเดียว"]
    code_mapping_ownership_rule["กฎผู้ถือตารางแปลงรหัส"]
    all_or_nothing_import_validation["นโยบายหยุดนำเข้าทั้งไฟล์เมื่อมีข้อผิดพลาด"]
    import_failure_notification["ชุดแจ้งขั้นต่ำเมื่อนำเข้าล้มเหลว"]
    cross_channel_rule_consistency["การจัดกฎปฏิบัติงานให้เหมือนกันทุกช่องทาง"]
    duplicate_order_registration["การลงทะเบียนซ้ำ"]
    fax_handling_improvement["การปรับปรุงวิธีรับ FAX"]
    edi["EDI (การแลกเปลี่ยนข้อมูลอิเล็กทรอนิกส์)"]
    standardized_business_code["รหัสองค์กรมาตรฐาน"]
    fax_order_web_migration -->|"ต้องมี"| dual_operation_period
    transcription_volume_reduction_goal -->|"แนวทางที่แนะนำสำหรับ"| fax_order_web_migration
    all_at_once_web_migration -->|"อาจก่อให้เกิด"| indefinite_dual_operation
    transcription_volume_reduction_goal -->|"ป้องกัน"| all_at_once_web_migration
    dual_operation_deadline_target -->|"บรรเทา"| indefinite_dual_operation
    channel_migration_kpi -->|"ใช้"| receiving_channel_field
    dual_operation_deadline_target -->|"ตรวจยืนยันด้วย"| channel_migration_kpi
    csv_import_intermediate_form -->|"แนวทางที่แนะนำสำหรับ"| fax_order_web_migration
    csv_import_intermediate_form -->|"ใช้"| csv_file_format_spec
    csv_import_intermediate_form -->|"ต้องมี"| master_data_readiness
    pilot_partner_approach -->|"ต้องมี"| master_data_readiness
    partner_classification -->|"แนวทางที่แนะนำสำหรับ"| fax_order_web_migration
    partner_classification -->|"ควรทำก่อน"| pilot_partner_approach
    unified_order_channel_processing -->|"แนวทางที่แนะนำสำหรับ"| fax_order_web_migration
    code_mapping_ownership_rule -.->|"แนวทางที่แนะนำสำหรับ"| csv_import_intermediate_form
    all_or_nothing_import_validation -.->|"แนวทางที่แนะนำสำหรับ"| csv_import_intermediate_form
    all_or_nothing_import_validation -->|"ต้องมี"| import_failure_notification
    cross_channel_rule_consistency -->|"แนวทางที่แนะนำสำหรับ"| fax_order_web_migration
    cross_channel_rule_consistency -->|"บรรเทา"| duplicate_order_registration
    fax_handling_improvement -->|"แนวทางที่แนะนำสำหรับ"| dual_operation_period
    edi -->|"เป็นรุ่นถัดจาก"| csv_import_intermediate_form
    standardized_business_code -.->|"แนวทางที่แนะนำสำหรับ"| edi
    partner_classification -->|"ป้องกัน"| all_at_once_web_migration

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

2. เหตุใดการย้ายไปเว็บทั้งหมดในครั้งเดียวจึงมักล้มเหลว

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

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

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

ต้นเหตุคือการตั้งเป้าที่ “เลิกใช้ FAX”

ถ้าเปลี่ยนเป้าเป็น “ลดจำนวนคำสั่งซื้อที่คนต้องคีย์” แผนจะทำได้จริงขึ้น ตัวอย่างเช่น ถ้าเฉพาะคู่ค้ารายใหญ่ที่ครอง 70% ของคำสั่งซื้อย้ายไปเว็บหรือ CSV แม้ 30% ที่เหลือยังใช้ FAX งานคีย์ก็ลดลงมาก

อย่าขยับทั้งหมดในครั้งเดียว ให้ขยับจากจุดที่ได้ผลมากก่อน นี่คือหลักของการย้ายแบบเป็นขั้น

3. ภาพหลังย้าย ── ทางเข้าหลายช่อง งานภายในสายเดียว

ก่อนออกแบบการย้ายแบบเป็นขั้น ให้วาดรูปที่ต้องการไว้ก่อน

หัวใจคือ แยกช่องทางรับ ออกจากการประมวลผลคำสั่งซื้อ

flowchart LR
    ORDER["ข้อมูลคำสั่งซื้อร่วม<br/>(รูปแบบเดียวกัน)"]
    BACK["งานภายในบริษัท<br/>จองสต็อก / จัดส่ง / วางบิล"]
    subgraph CH["ช่องทางรับคำสั่งซื้อ"]
        FAX["FAX"]
        MAIL["ไฟล์แนบอีเมล"]
        CSV["นำเข้า CSV"]
        WEB["หน้าจอสั่งซื้อผ่านเว็บ"]
    end
    FAX -->|"ผู้รับผิดชอบคีย์ข้อมูล"| ORDER
    MAIL -->|"ผู้รับผิดชอบคีย์ข้อมูล"| ORDER
    CSV -->|"นำเข้าอัตโนมัติ"| ORDER
    WEB -->|"ลงทะเบียนอัตโนมัติ"| ORDER
    ORDER --> BACK

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

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

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

ไม่จำเป็นต้องรื้อระบบจัดการขายเดิมเสมอไป ถ้ายืนยันได้ว่าเพิ่มทางเข้าข้อมูลคำสั่งซื้อได้ (ฟังก์ชันนำเข้า CSV, การเชื่อมฐานข้อมูล, API เป็นต้น) ก็เดินต่อโดยคงกลไกปัจจุบันได้ จุดตรวจนี้จัดไว้แล้วใน “ตรวจการเชื่อมต่อเข้าสู่ระบบภายในบริษัท” ของบทความ EDI ตอนก่อนหน้า

4. การนำเข้า CSV ในฐานะรูปแบบกลาง

การให้คู่ค้ากระโดดจาก FAX ไปคีย์บนหน้าจอเว็บทันที อาจเป็นภาระหนักสำหรับฝั่งคู่ค้า

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

จึงเตรียมการนำเข้า CSV (หรือ Excel) เป็นรูปแบบกลาง

ขั้นที่ 1: รับ CSV เป็นไฟล์แนบอีเมล ให้ผู้รับผิดชอบโหลดด้วยฟังก์ชันนำเข้า
ขั้นที่ 2: คู่ค้าอัปโหลด CSV จากหน้าเว็บ แล้วนำเข้าอัตโนมัติ
ขั้นที่ 3: คู่ค้าที่งานเป็นแบบแผนแล้วไปหน้าจอสั่งซื้อผ่านเว็บหรือ EDI

แม้แค่ขั้นที่ 1 เวลาคีย์และข้อผิดพลาดจากการคัดลอกข้อมูลก็ลดลงมากเมื่อเทียบกับการคีย์ขณะมองใบสั่งซื้อ ข้อดีอีกข้อคือฝั่งคู่ค้าเปลี่ยนแค่ “สิ่งที่เคยส่งทาง FAX เปลี่ยนเป็นไฟล์แนบอีเมล” จึงขอความร่วมมือได้ง่าย

ตอนออกแบบการนำเข้า CSV ให้ตัดสินอย่างน้อยรายการต่อไปนี้

ใน 6 รายการนี้ สิ่งที่ถกเถียงจริงมากที่สุดคือ ระบบรหัส ว่า “ให้คู่ค้าส่งด้วยรหัสสินค้าของเขา” หรือ “ให้แปลงเป็นรหัสของเราแล้วส่งมา” จะกำหนดว่าใครถือตารางแปลงรหัส ฝ่ายขายมักพูดว่า “ให้คู่ค้าส่งด้วยรหัสของเราจะสบายกว่า” ส่วนฝ่ายระบบมักพูดว่า “ถือตารางแปลงรหัสทีละคู่ค้าเป็นภาระ”

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

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

• แจ้งอีเมลภายในบริษัท ── ส่ง “นำเข้าล้มเหลว” อัตโนมัติไปยัง mailing list ของทีมรับคำสั่งซื้อ หัวเรื่องใส่ชื่อไฟล์และชื่อคู่ค้า เนื้อความเรียงเลขแถวที่ผิดและสาเหตุ (เช่น “รหัสสินค้า ABC-123 ไม่มีในมาสเตอร์”)
• ประวัติการนำเข้าบนหน้าจอจัดการ ── เตรียมหน้าจอที่เห็นสำเร็จ ล้มเหลว และยังไม่ประมวลผลเป็นรายการ แม้พลาดอีเมล ดูที่นี่ตอนเช้าก็รู้ได้
• การติดต่อคู่ค้า ── ช่วงแรกอย่าตอบกลับอัตโนมัติ ให้ผู้รับผิดชอบภายในตรวจเนื้อหาก่อนแล้วค่อยติดต่อ พอเข้าสู่ขั้นอัปโหลดบนเว็บ จึงย้ายไปแสดงข้อผิดพลาดทันทีบนหน้าจออัปโหลด

การออกแบบแบบ “ข้อผิดพลาดอยู่ในล็อกแล้ว กรุณาตรวจเอง” ไม่เหมาะกับช่วงใช้งานคู่ขนาน เพราะผู้รับผิดชอบยุ่งอยู่กับงาน FAX อยู่แล้ว

CSV ดูเรียบง่าย แต่เป็นรูปแบบที่มีหลุมพรางเรื่องรหัสอักขระ, ขึ้นบรรทัดใหม่ และการจัดการจุลภาคกับอัญประกาศ ข้อควรระวังทางเทคนิคตอนอิมพลีเมนต์การนำเข้าสรุปไว้ใน “คู่มือปฏิบัติการประมวลผลไฟล์ CSV”

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

5. จัดระเบียบมาสเตอร์สินค้าและคู่ค้าก่อน

ในการรับคำสั่งซื้อทาง FAX ช่องโหว่ของมาสเตอร์ถูกผู้รับผิดชอบดูดซับไว้

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

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

ดังนั้น ก่อนย้ายอย่างน้อยต้องจัดระเบียบดังนี้

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

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

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

6. การออกแบบช่วงใช้งานคู่ขนาน

ช่วงที่ FAX กับเว็บ (CSV) เดินคู่กัน ระหว่างการย้ายต้องเกิดอยู่แล้ว ถ้าไม่ได้ออกแบบแล้วปล่อยไว้ การเดินคู่จะกลายเป็นสภาพปกติ และกลายเป็นสถานะ “งานเพิ่มเท่ากับจำนวนช่องทางที่เพิ่ม”

การออกแบบช่วงใช้งานคู่ขนาน คือการตัดสินเรื่องต่อไปนี้โดยรูปธรรม

6.1. กำหนดระยะเวลาและค่าเป้าหมาย

ตัดสินเป็นตัวเลขว่า “ภายในเมื่อใด สัดส่วนเท่าใดของจำนวนคำสั่งซื้อจะเป็นการนำเข้าอัตโนมัติ” เช่น “ใน 6 เดือน ให้สัดส่วนคำสั่งซื้อทาง FAX จาก 70% เหลือ 30%”

การเดินคู่ที่ไม่มีเส้นตายจะตรึงเป็นสภาพถาวร แม้ไปไม่ถึงเป้า ถ้ามีเส้นตาย ก็จะนำไปสู่การไปถามทีละคู่ค้าว่า “ทำไมการย้ายไม่เดิน”

6.2. วัดจำนวนรายการแยกตามช่องทางทุกเดือน

ความคืบหน้าของการย้ายให้ตามด้วยจำนวน ไม่ใช่ด้วยความรู้สึก

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

เป็นแนวคิดเดียวกับ ตัวชี้วัดที่อยากวัดหลังนำมาใช้ ที่ยกในบทความก่อนหน้า การวัดแยกตามช่องทางทำให้เห็นว่า “เข้าหาคู่ค้ารายใดแล้วได้ผลมาก”

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

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

6.3. จัดกฎการปฏิบัติงานให้เหมือนกันทุกช่องทาง

ความสับสนในช่วงใช้งานคู่ขนานมักเกิดเมื่อกฎงานต่างกันตามช่องทาง

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

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

6.4. ถือวิธีรับ FAX เป็นเป้าปรับปรุงด้วย

ในช่วงใช้งานคู่ขนาน FAX ยังอยู่ ถ้าตั้งต้นว่ายังอยู่ กระบวนการฝั่ง FAX ก็เป็นเป้าปรับปรุงเช่นกัน

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

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

7. วิธีชวนคู่ค้าให้ร่วมด้วย

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

7.1. จัดกลุ่มคู่ค้า

อย่าปฏิบัติต่อคู่ค้าทุกรายเหมือนกัน ให้จัดกลุ่มก่อน

ผลถูกกำหนดโดย A และ B การฝืนขยับคู่ค้ากลุ่ม C มักได้แต่ต้นทุน จึงบอกได้ตรง ๆ ว่า “เรารับ FAX ต่อไปด้วย”

7.2. เลือกคู่ค้าไพลอต 1 ราย

อย่าย้ายหลายรายขนานกันตั้งแต่ต้น ให้ตั้งการปฏิบัติงานกับ 1 รายก่อน เกณฑ์เลือกเหมือนบทความก่อนหน้า

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

กับไพลอต ให้สร้าง “แม่แบบ” ทั้งรูปแบบ CSV, วิธีติดต่อตอนมีข้อผิดพลาด, ตารางคู่มาสเตอร์, เอกสารชี้แจง แล้วเอาแม่แบบนั้นไปใช้กับรายที่ 2 เป็นต้นไป

7.3. ชี้แจงด้วยประโยชน์ของอีกฝ่าย

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

• ใบยืนยันการรับคำสั่งซื้อกลับมาทันที จึงไม่ต้องโทรถามว่า “ถึงหรือยัง”
• การจัดส่งผิดและการผิดจำนวนจากการอ่านผิดลดลง
• ดูประวัติคำสั่งซื้อเองได้ สั่งซ้ำง่ายขึ้น (กรณีสั่งซื้อผ่านเว็บ)
• งานส่ง FAX และการส่งซ้ำตอนส่งไม่สำเร็จหายไป

ควบคู่กัน การดูแลเชิงปฏิบัติก็ได้ผล

• รวมขั้นตอนการใช้งานไว้คู่มือแผ่นเดียว (ให้ขอบเขตที่อธิบายด้วยหน้าจอไม่กี่หน้าก็พอ)
• ระบุวันเริ่มและช่วงใช้ร่วมให้ชัด (“ตั้งแต่เดือน … รับทางเว็บด้วย FAX ยังใช้ร่วมไปได้ในช่วงนี้”)
• ช่วงแรก ๆ รับทั้งที่ส่งทาง FAX และทางเว็บ และตอบคำถามทันที

อนึ่ง ไม่แนะนำให้เริ่มด้วยประกาศว่า “จะเลิก FAX ในเดือน …” ควรถึงเรื่องเส้นตายเมื่อการย้ายเดินไปแล้ว และคู่ค้าที่เหลือเหลือน้อย เพื่อไม่ให้สัมพันธ์เสีย

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

8. กรณีตัวอย่างของการย้ายแบบเป็นขั้น

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

เฟส 0 “จัดสภาพปัจจุบัน” ใช้ การทำรายการวิธีสั่งซื้อ-รับคำสั่งซื้อ ที่แนะนำในบทความก่อนหน้าได้เลย

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

9. จุดสะดุดที่พบบ่อยและวิธีรับมือ

สุดท้าย สรุปจุดสะดุดที่เกิดง่ายในการย้ายจริง

สรุป

การย้ายการรับคำสั่งซื้อทาง FAX ไปเว็บ เป็นงานออกแบบช่วงย้าย มากกว่าเป็นงานสร้างระบบ

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

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

ถึงผู้ที่กำลังพิจารณาย้ายการสั่งซื้อ-รับคำสั่งซื้อไปเว็บ

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

KomuraSoft LLC รับปรึกษา Windows Custom Software Development สำหรับการออกแบบและอิมพลีเมนต์การเชื่อมการนำเข้า CSV และการสั่งซื้อผ่านเว็บ โดยใช้แอปธุรกิจ Windows และฐานข้อมูลที่มีอยู่ รวมถึงการจัดระเบียบแผนการย้ายเอง

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

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

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

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

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

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

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

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

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

Go Komura

ผู้แทนของ KomuraSoft LLC

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