EDI là gì? Cách giúp đặt hàng và nhận đơn giữa doanh nghiệp dễ hơn ── từ FAX, email, nhập tay sang liên thông dữ liệu

“Đối tác gửi phiếu đặt hàng bằng FAX, nhân viên nhập vào hệ thống quản lý bán hàng.” “Mở Excel đính kèm email, kiểm tra mã sản phẩm và số lượng rồi chép lại.” “Sau khi giao hàng thì lập hóa đơn, phía nhận cũng nhập nội dung đó vào hệ thống kế toán” ── Trong giao dịch giữa doanh nghiệp, cùng thông tin đơn hàng hay hóa đơn đôi khi bị nhiều công ty, nhiều người nhập đi nhập lại.

Cơ chế giảm nhập trùng đó, để dữ liệu đặt hàng, nhận đơn, xuất hàng, hóa đơn đi thẳng giữa các doanh nghiệp, là EDI. Nghe EDI, có thể hình dung hệ thống lớn của doanh nghiệp lớn chạy trên đường truyền riêng, nhưng bản chất đơn giản hơn nhiều. Không phải người đọc lại thông tin tới rồi nhập, mà trao đổi như dữ liệu máy tính xử lý được ngay. Chỉ vậy.

Bài viết này trình bày EDI là gì, khác FAX và email chỗ nào, triển khai thì nghiệp vụ doanh nghiệp dễ hơn thế nào, lấy nghiệp vụ đặt hàng và nhận đơn làm ví dụ. Thuật ngữ chuyên môn giữ tối thiểu, nhưng hãy nắm trước bốn mục sau.

1. Kết luận trước

EDI là cơ chế các doanh nghiệp trao đổi thông tin giao dịch như phiếu đặt hàng, thông báo xuất hàng, hóa đơn dưới dạng dữ liệu điện tử đã thống nhất định dạng trước.

JIPDEC (一般財団法人日本情報経済社会推進協会 / Japan Information Economy and Society Promotion Association) là tổ chức chuẩn hóa và phổ biến ở các lĩnh vực thương mại điện tử, an ninh thông tin, bảo vệ thông tin cá nhân, và liên tục công bố thông tin về mã doanh nghiệp và EDI. Bài này cũng tham chiếu giải thích của tổ chức đó về định nghĩa và hiệu quả của EDI. Giải thích của JIPDEC mô tả EDI là “các doanh nghiệp, cơ quan hành chính, v.v. nối máy tính bằng mạng và tự động trao đổi chứng từ, tài liệu dưới dạng dữ liệu điện tử”, đồng thời giới thiệu cả định nghĩa theo JIS X 7011.

Mục đích triển khai EDI không chỉ là bỏ giấy. Mục đích chính là giảm các việc như sau.

• Nhập tay vừa nhìn FAX hay PDF
• Chép từ Excel sang hệ thống quản lý bán hàng
• Kiểm tra nội dung đã nhập bằng mắt
• Tìm phiếu đặt hàng hay hóa đơn
• Gọi điện hay email xác nhận tình trạng đơn
• Tổng hợp lại dữ liệu doanh thu, tồn kho, hóa đơn

Nói gọn: EDI là cơ chế để dữ liệu từng đứng lại giữa công ty với công ty chảy tiếp được.

Bản đồ tri thức của bài viết này

EDI là cơ chế các doanh nghiệp trao đổi thông tin giao dịch như phiếu đặt hàng, thông báo xuất hàng, hóa đơn dưới dạng dữ liệu điện tử đã thống nhất định dạng trước, nhằm loại bỏ chính việc nhập lại thủ công. Ngoài giảm lỗi chép lại và đẩy nhanh xử lý nhận đơn, hiệu quả chỉ xuất hiện khi dữ liệu nhận được liên thông tới hệ thống tồn kho, xuất hàng, hóa đơn nội bộ; nếu không import mà in ra rồi xử lý tay thì không khác FAX. Định dạng làm riêng từng đối tác làm tăng chi phí, nên EDI theo chuẩn hoặc EDI chung cho SME là lựa chọn thực tế. Hóa đơn điện tử là thực tiễn áp dụng tư duy đó vào lĩnh vực hóa đơn; trước khi triển khai, rà soát cách đặt hàng / nhận đơn hiện tại theo từng đối tác được ưu tiên hơn việc chọn sản phẩm.

flowchart LR
    accTitle: Bản đồ tri thức trao đổi dữ liệu giữa doanh nghiệp bằng EDI
    accDescr: Sơ đồ cho thấy EDI ngăn nhập lại thủ công và lỗi chép lại, tự động hóa xử lý nhận đơn cùng liên thông tồn kho, xuất hàng, hóa đơn ra sao; EDI theo chuẩn và EDI chung cho SME đáp ứng vấn đề định dạng riêng từng đối tác thế nào; hóa đơn điện tử áp dụng cùng tư duy vào lĩnh vực hóa đơn ra sao.
    edi["EDI (trao đổi dữ liệu điện tử)"]
    manual_reentry["Nhập lại thủ công thông tin đã nhận"]
    transcription_error["Lỗi nhập khi chép lại"]
    order_processing_lead_time["Lead time xử lý nhận đơn"]
    trading_partner_agreement["Thỏa thuận EDI với đối tác"]
    master_code_alignment["Khớp master mã sản phẩm"]
    order_to_cash_integration["Liên thông tồn kho, xuất hàng, hóa đơn sau nhận đơn"]
    edi_standard_format["EDI theo chuẩn"]
    edi_individual_format["EDI riêng từng đối tác"]
    sme_common_edi["EDI chung cho SME"]
    digital_invoice["Hóa đơn điện tử"]
    current_process_inventory["Rà soát cách đặt hàng / nhận đơn hiện tại"]
    order_status_visibility["Hiển thị tình trạng đơn"]
    task_personalization["Nghiệp vụ phụ thuộc cá nhân"]
    low_frequency_irregular_trading["Giao dịch ít, không theo mẫu"]
    high_frequency_recurring_trading["Giao dịch lặp tần suất cao, theo mẫu"]
    edi -->|"giảm thiểu"| manual_reentry
    manual_reentry -->|"có thể gây"| transcription_error
    edi -.->|"giảm thiểu"| transcription_error
    edi -->|"giảm thiểu"| order_processing_lead_time
    edi -->|"yêu cầu"| trading_partner_agreement
    edi -->|"yêu cầu"| master_code_alignment
    edi -->|"tự động hóa"| order_to_cash_integration
    edi -.->|"yêu cầu"| order_to_cash_integration
    edi -->|"sử dụng"| edi_standard_format
    edi_standard_format -->|"khuyến nghị cho"| edi_individual_format
    sme_common_edi -->|"khuyến nghị cho"| edi_individual_format
    digital_invoice -.->|"sử dụng"| edi
    current_process_inventory -->|"nên làm trước"| edi
    edi -->|"tự động hóa"| order_status_visibility
    order_status_visibility -->|"giảm thiểu"| task_personalization
    edi -.->|"không khuyến nghị"| low_frequency_irregular_trading
    edi -->|"khuyến nghị cho"| high_frequency_recurring_trading

Trong sơ đồ, đường liền nét biểu thị quan hệ luôn đúng và đường nét đứt biểu thị quan hệ có điều kiện (điều kiện nằm trong phần giải thích từng quan hệ trên trang chi tiết). Danh sách đầy đủ các quan hệ (tổng 17, kèm bằng chứng và mức chắc chắn) cùng định nghĩa các khái niệm chính được tập hợp tại trang chi tiết bản đồ tri thức (bằng tiếng Nhật). Dữ liệu: JSON-LD / Turtle

2. Khi nhận đơn không có EDI thì chuyện gì xảy ra

Trước hết, hãy nghĩ nghiệp vụ đặt hàng và nhận đơn không dùng EDI. Bên đặt hàng, nhân viên mua hàng soạn nội dung đơn trên hệ thống của mình hoặc Excel, in thành phiếu đặt hàng, gửi đối tác bằng FAX hoặc email. Bên nhận đơn kiểm tra phiếu tới rồi nhập vào hệ thống quản lý bán hàng của mình. Sau đó lập xác nhận nhận đơn, thông báo xuất hàng, phiếu giao, hóa đơn rồi gửi lại bên đặt; bên đặt lại nhập những thông tin đó vào hệ thống quản lý tồn kho hay hệ thống kế toán.

flowchart TD
    accTitle: Luồng đặt hàng và nhận đơn khi không có EDI
    accDescr: Dữ liệu bị nhập lại hai lần qua tay người.
    A["Bên đặt hàng nhập dữ liệu đơn"] --> B["In phiếu đặt hàng hoặc xuất PDF"]
    B --> C["Gửi bằng FAX hoặc email"]
    C --> D["Nhân viên bên nhận đơn kiểm tra nội dung"]
    D --> E["Nhập lại vào hệ thống bên nhận đơn"]
    E --> F["Tạo dữ liệu xuất hàng và hóa đơn"]
    F --> G["Bên đặt hàng lại nhập vào hệ thống của mình"]

Hình 1: Luồng đặt hàng và nhận đơn khi không có EDI. Dữ liệu bị nhập lại hai lần qua tay người.

Trong luồng này, cùng thông tin như mã sản phẩm, tên hàng, số lượng, đơn giá, hạn giao, nơi giao bị nhập nhiều lần. Dữ liệu đơn ban đầu đã nằm trong máy tính bên đặt, vậy mà sau khi biến thành giấy hay PDF, bên nhận lại phải đọc rồi nhập lại vào máy tính.

Vấn đề không phải thông tin chưa được số hóa. Vấn đề là thông tin đã từng là dữ liệu bị biến thành tài liệu cho người đọc, rồi phía bên kia biến lại thành dữ liệu.

3. Dùng EDI thì đặt hàng và nhận đơn đổi thế nào

Với EDI, dữ liệu đơn tạo trên hệ thống bên đặt được chuyển sang định dạng hệ thống bên nhận đọc được, rồi gửi nguyên. Bên nhận không nhập vừa nhìn phiếu đặt hàng, mà import dữ liệu đã nhận vào hệ thống quản lý bán hàng.

flowchart LR
    accTitle: Luồng đặt hàng và nhận đơn khi dùng EDI
    accDescr: Các bước in, kiểm tra bằng mắt và nhập lại ở Hình 1 đã biến mất.
    A[Hệ thống mua hàng bên đặt hàng] --> B[Dữ liệu đơn hàng]
    B --> C[Gửi và chuyển đổi qua EDI]
    C --> D[Hệ thống quản lý bán hàng bên nhận đơn]
    D --> E[Xác nhận nhận đơn]
    D --> F[Thông báo xuất hàng]
    D --> G[Dữ liệu hóa đơn]
    E --> C
    F --> C
    G --> C
    C --> A

Hình 2: Luồng đặt hàng và nhận đơn khi dùng EDI. Các bước “in”, “kiểm tra bằng mắt”, “nhập lại” ở Hình 1 đã biến mất.

Bên đặt gửi dữ liệu đơn sang bên nhận; bên nhận trả dữ liệu xác nhận nhận đơn, xuất hàng, hóa đơn. Điểm mấu chốt là dữ liệu đi từ hệ thống sang hệ thống, không kẹp bước người nhìn tài liệu rồi chép lại.

Giải thích của JIPDEC mô tả EDI như cơ chế chuyển dữ liệu định dạng riêng của từng công ty sang định dạng chuẩn, rồi phía nhận chuyển từ định dạng chuẩn về định dạng của mình.

4. EDI khác email, PDF, Excel ở điểm nào

Đôi khi nghĩ “đã gửi phiếu đặt hàng PDF bằng email nên đã số hóa rồi”. Đúng là nhanh hơn gửi giấy bưu điện, cũng dễ lưu hơn. Nhưng nếu phía nhận vẫn nhìn PDF rồi nhập vào hệ thống, thì bản thân việc nhập vẫn còn. Khác biệt sắp như sau.

Trong giải thích của JIPDEC, ảnh scan chứng từ hay email viết như văn thường được phân biệt với dữ liệu EDI mà máy tính xử lý lại được. Cách người nhập tay trên màn hình Web, xét chặt, cũng khác trao đổi tự động giữa máy tính.

Tuy nhiên, dùng PDF hay Excel bản thân không xấu. Điều quan trọng là thông tin nhận được xử lý thế nào sau đó. “Người nhìn PDF rồi nhập”, “mở Excel rồi copy”, “nạp CSV thẳng vào hệ thống”, “đăng ký tự động qua API” ── cùng là “file điện tử” nhưng gánh bước sau khác hẳn. Khi đánh giá hiệu quả EDI, cần nhìn không chỉ cách gửi mà cả người làm gì sau khi nhận.

4.1. Bản đồ những thứ được gọi là “EDI”

Đến đây viết gộp “EDI”, nhưng khi bắt đầu xem xét sẽ gặp nhiều tên gọi. Nắm vị trí tương đối trước thì đọc mô tả sản phẩm đỡ lạc.

Trục phân loại chỉ có hai. Một là định dạng trao đổi là spec riêng từng đối tác hay chuẩn đã đồng thuận rộng. Hai là cuối cùng người còn thao tác màn hình hay dữ liệu đi từ hệ thống sang hệ thống. Đặt hiện trạng và các phương án lên hai trục này thì thấy chỗ nào sửa sẽ ra hiệu quả.

5. Thông tin EDI có thể trao đổi

EDI không chỉ là cơ chế cho phiếu đặt hàng. Nhiều loại thông tin phát sinh trong giao dịch giữa doanh nghiệp đều trao đổi được.

Ví dụ, lúc vừa nhận dữ liệu đặt hàng, hệ thống bên nhận cũng có thể làm các bước sau.

1. Kiểm tra số đơn có trùng không
2. Kiểm tra mã sản phẩm có tồn tại không
3. Phân bổ tồn kho
4. Tính hạn giao
5. Gửi chỉ thị xuất hàng tới kho
6. Trả xác nhận nhận đơn cho bên đặt

Sau khi xuất hàng, từ thực tế xuất có thể ghi nhận doanh thu và tạo dữ liệu hóa đơn. Nghĩa là EDI không chỉ là chức năng truyền thông; nó là nền để lấy đặt hàng / nhận đơn làm cửa vào, rồi nối tiếp tồn kho, xuất hàng, doanh thu, hóa đơn.

6. EDI làm nghiệp vụ doanh nghiệp dễ hơn thế nào

Như đã thấy từ chương 2 tới chương 4, hiệu quả trực tiếp của EDI là “không còn nhập tay vừa nhìn phiếu đặt hàng”. Chương này chia sáu mục những gì xảy ra phía sau. Hiệu quả không chỉ giảm công nhập.

6.1. Thời gian nhân viên dành cho xử lý ngoại lệ

Hết nhập tay thì cách dùng thời gian của nhân viên đổi. Không phải mọi đơn đều người xử lý; đơn thường chạy tự động, chỉ đơn cần phán đoán người mới xem. Đơn người nên xem, ví dụ:

• Đơn thiếu tồn kho
• Đơn hạn giao khác thường
• Đơn mã sản phẩm chưa đăng ký
• Đơn số lượng lớn
• Đơn cần xác nhận đơn giá hay điều kiện hợp đồng

Khi đang chạy theo nhập liệu, các xác nhận này dễ bị để sau. Giá trị của EDI nằm ở “thời gian đã giảm dùng được cho những đơn đáng chú ý”, hơn là ở “việc giảm”.

6.2. Giảm lỗi nhập

Việc người nhập có xác suất sai nhất định. Nhầm một chữ số mã sản phẩm, nhập 100 thay vì 10, nhầm nơi giao, đọc sai hạn giao mong muốn, đăng ký trùng cùng một đơn — loại đó.

Với EDI, nếu dữ liệu gốc sai thì vẫn có vấn đề. Nhưng dữ liệu đã tạo đúng không cần phía kia nhập lại, nên lỗi phát sinh lúc chép lại giảm được. Cơ quan Doanh nghiệp vừa và nhỏ Nhật Bản (中小企業庁) cũng nêu hiệu quả số hóa đặt hàng / nhận đơn gồm tăng hiệu suất công việc, giảm lỗi do người, và dễ tìm lại hồ sơ giao dịch.

6.3. Xử lý nhận đơn nhanh hơn

Với FAX hay email, xử lý nhận đơn chưa bắt đầu cho tới khi nhân viên nhận ra đã tới, kiểm tra nội dung, nhập xong. Ngày nhiều đơn thì phát sinh chờ nhập; nhân viên nghỉ thì xử lý chậm.

Với EDI, dữ liệu nhận được nạp tự động vào hệ thống, nên ngay sau khi nhận đơn có thể bắt đầu tiếp nhận, kiểm tra tồn kho, tính hạn giao, chỉ thị xuất hàng tới kho, trả xác nhận nhận đơn. Nhận đơn nhanh hơn thì thời gian tới lúc xuất hàng cũng dễ rút. JIPDEC cũng nêu hiệu quả EDI gồm tăng hiệu suất và tốc độ công việc văn phòng, giao hàng just-in-time, rút lead time, nén tồn kho.

6.4. Dễ nắm tình trạng đơn

Khi giấy, FAX, email, Excel lẫn nhau, mất thời gian để biết “đơn đó hiện ra sao”. Phải lần lượt xem hộp thư nhân viên, thư mục dùng chung, hồ sơ giấy, hệ thống quản lý bán hàng.

Với EDI, lấy số đơn làm gốc, liên kết và quản được các thông tin sau.

• Nhận đơn lúc nào
• Nạp thành công chưa
• Đã trả xác nhận nhận đơn chưa
• Đã xuất hàng chưa
• Đã nghiệm thu chưa
• Đã xuất hóa đơn chưa
• Có lỗi hay gửi lại không

Khi nhận hỏi, xác nhận từ lịch sử xử lý, không dựa trí nhớ nhân viên hay email cá nhân.

6.5. Nối được với tồn kho, xuất hàng, kế toán

Nếu dữ liệu nhận được liên thông với hệ thống nội bộ, các bước sau đăng ký nhận đơn cũng tự động được.

flowchart TD
    accTitle: Các bước nội bộ sau khi nhận dữ liệu đơn hàng
    accDescr: Nối tới đâu quyết hiệu quả triển khai.
    A["Nhận dữ liệu đơn hàng"] --> B["Đăng ký nhận đơn"]
    B --> C["Phân bổ tồn kho"]
    C --> D["Chỉ thị xuất hàng"]
    D --> E["Ghi nhận doanh thu"]
    E --> F["Tạo dữ liệu hóa đơn"]
    F --> G["Đối chiếu thu tiền"]

Hình 3: Các bước nội bộ mà dữ liệu đơn hàng đã nhận đi qua. Nối tới đâu quyết hiệu quả triển khai.

Ngược lại, dù nhận dữ liệu đơn bằng EDI, nếu in ra rồi người nhập vào hệ thống quản lý bán hàng, thì hiệu quả hạn chế. JIPDEC cũng giải thích: nhận dữ liệu EDI mà không nạp vào hệ thống nội bộ, in ra rồi xử lý tay, thì khác FAX không nhiều. EDI không phải chỉ triển khai truyền thông với đối tác; quan trọng là dữ liệu nhận được chảy tới đâu trong nghiệp vụ nội bộ.

6.6. Dùng dữ liệu giao dịch cho quyết định kinh doanh

Phiếu đặt hàng nhận bằng giấy hay PDF, dù lưu, cũng khó dùng để tổng hợp. Với EDI, thông tin giao dịch được tích lũy như dữ liệu có cấu trúc, nên nối được sang các phân tích sau.

• Lượng nhận đơn theo sản phẩm
• Diễn biến doanh thu theo đối tác
• Xu hướng đơn theo ngày trong tuần / khung giờ
• Tình hình chậm hạn giao
• Sản phẩm hay hết hàng
• Thời gian từ đặt hàng tới xuất hàng
• Giao dịch nhiều trả hàng hay sửa

JIPDEC cũng cho rằng dữ liệu EDI, ngoài nghiệp vụ hàng ngày như phân bổ tồn kho, sắp xếp sản xuất, kiểm hàng nhập xuất, ghi nhận phải thu, còn dùng được làm chất liệu quyết định kinh doanh như phân tích hàng bán chạy, spend analysis, dự báo nhu cầu. Tạo trạng thái thu thập được dữ liệu bằng EDI không chỉ hiệu quả nghiệp vụ, mà còn là tiền đề tối ưu tồn kho và dự báo nhu cầu về sau.

7. Hiệu quả EDI qua một ví dụ đơn giản

Giả sử một công ty bán buôn mỗi ngày nhận 100 đơn bằng FAX hoặc email, và trung bình mất 3 phút để nhập một đơn vào hệ thống quản lý bán hàng rồi kiểm tra nội dung.

100 đơn × 3 phút = 300 phút → 5 giờ mỗi ngày

Sau khi triển khai EDI, 80 đơn nạp tự động, chỉ 20 đơn còn lại người xác nhận, thì thành:

20 đơn × 3 phút = 60 phút → 1 giờ mỗi ngày

Đây là ví dụ đã giản lược, nhưng việc nhập từ 5 giờ xuống 1 giờ. Thực tế, thời gian đọc FAX khó đọc, sửa nhập sai, gọi xác nhận nội dung đơn, tìm phiếu đặt hàng, tổng hợp danh sách đơn, bàn giao giữa nhân viên cũng có thể giảm. Hiệu quả triển khai EDI không chỉ chi phí trực tiếp kiểu “giảm tiền giấy”; ý nghĩa lớn nằm ở việc giảm những xác nhận, nhập, sửa nhỏ lặp mỗi ngày.

7.1. Ước tính bằng số liệu của chính công ty

100 đơn · 3 phút ở trên chỉ là ví dụ. Hãy gắn số của công ty mình. Chỉ cần bốn số.

(1) Số đơn nhận mỗi ngày                       …… A đơn
(2) Thời gian nhập và kiểm tra mỗi đơn         …… B phút
(3) Tỷ lệ dự kiến EDI xử lý tự động được       …… C ％
(4) Số ngày làm việc trong năm                 …… D ngày

Thời gian đang mất          = A × B                    (phút/ngày)
Thời gian còn lại sau EDI   = A × (1 - C ÷ 100) × B    (phút/ngày)
Thời gian giảm mỗi ngày     = A × (C ÷ 100) × B        (phút/ngày)
Thời gian giảm mỗi năm      = thời gian giảm mỗi ngày × D ÷ 60  (giờ/năm)

“Tỷ lệ xử lý tự động được” ở (3) do độ nhiều ngoại lệ ở các chương sau quyết. Đừng đặt giá trị cao từ đầu; hãy bắt đầu bằng việc đếm vài đối tác đứng đầu chiếm bao nhiêu phần tổng số đơn. Số đơn theo đối tác ra khi lập bảng ở chương 11.1.

Lưu ý, phép tính này cho ra thời gian giảm được, không phải chi phí nhân sự giảm nguyên. Chỉ khi quyết thời gian trống dùng vào việc gì (nâng chất xử lý ngoại lệ, chuyển sang việc khác, giảm tăng ca) thì mới thành số giải thích được như hiệu quả triển khai.

8. Lợi ích EDI theo từng bộ phận

Cải thiện nghiệp vụ nhờ EDI không giới hạn ở bộ phận nhận đơn.

Vị trí thông tin rõ hơn, người không phải phụ trách cũng xem tình trạng dễ hơn, nên EDI giảm không chỉ công nhập mà cả sự phụ thuộc vào cá nhân.

9. Triển khai EDI không có nghĩa mọi thứ đều tự động

EDI là cơ chế tiện, nhưng không phải triển khai xong là mọi việc tự động.

9.1. Cần thỏa thuận với đối tác

Để trao đổi dữ liệu giữa doanh nghiệp, tối thiểu cần quyết: trao đổi thông tin nào, dùng định dạng dữ liệu nào, gửi nhận lúc nào, xử lý đổi đơn / hủy đơn thế nào, lỗi thì làm gì, gửi lại cùng dữ liệu thì xử lý thế nào, và thời điểm nào đơn được coi là chính thức.

Các thỏa thuận này có tầng. JIPDEC sắp thành năm tầng sau. Nếu nhầm “đưa EDI vào” đang nói tầng nào, thảo luận sẽ không khớp.

So sánh sản phẩm và dịch vụ dễ lệch về hai tầng trên (giao thức truyền thông và quy tắc cú pháp), nhưng chỗ vất khi triển khai là ba tầng dưới. Đặc biệt “thông điệp và trường dữ liệu” chính là chỉnh mã ở 9.2; chưa chốt với đối tác mà đã chọn sản phẩm thì sau phải làm lại.

9.2. Cần thống nhất mã sản phẩm

Bên đặt và bên nhận đôi khi dùng mã khác nhau cho cùng sản phẩm. Bên đặt là A-001, bên nhận là 100245 — kiểu đó. Khi ấy cần bảng tương ứng để chuyển mã. Ngoài mã sản phẩm, còn sắp các mục sau.

• Mã đối tác
• Mã nơi giao
• Đơn vị
• Số lượng trong kiện
• Phân loại thuế
• Tiền tệ
• Định dạng ngày
• Mã ký tự

Gửi nhận được dữ liệu mà nghĩa các trường không khớp thì không thành giao dịch đúng.

9.3. Xử lý ngoại lệ vẫn còn

Dù đơn thường xử lý tự động được, các giao dịch ngoại lệ vẫn còn: thiếu tồn kho, hàng ngừng, giá khác thường, đơn khẩn, đổi đơn, hủy đơn, giao chia, trả hàng, dữ liệu thiếu.

Điều quan trọng không phải cố tự động hóa hết. Tách xử lý thường và xử lý ngoại lệ, tự động hóa xử lý thường, chỉ việc cần phán đoán mới chuyển cho người — thiết kế đó thực tế. “Đơn người nên xem” ở chương 6.1 chính là ngoại lệ ở đây.

9.4. Sẽ có giai đoạn dùng song song FAX và email

Không phải mọi đối tác chuyển sang EDI cùng lúc. Vì vậy giai đoạn đầu, nhiều cách tiếp nhận có thể chạy song song: EDI, màn hình Web, upload CSV, email, FAX, điện thoại.

Ở trạng thái này, dù triển khai EDI cũng không giảm ngay nhân viên nghiệp vụ cũ. Để tăng hiệu quả, cần chuyển lần lượt từ đối tác khối lượng lớn, giảm số đơn còn làm tay. JIPDEC cũng chỉ ra: nếu xử lý tay như FAX hay điện thoại còn, vẫn cần người ứng phó, hiệu quả cải thiện năng suất khó đạt đủ. Lý do chương 7.1 nên đặt “tỷ lệ xử lý tự động được” khiêm tốn cũng nằm đây.

10. Doanh nghiệp phù hợp với EDI

EDI dễ ra hiệu quả đặc biệt với các doanh nghiệp sau.

• Mỗi ngày hoặc mỗi tuần đặt hàng / nhận đơn với cùng đối tác
• Số đơn hoặc số dòng chi tiết nhiều
• Đang chép từ FAX hay email vào hệ thống
• Đang phát sinh nhập sai hoặc đăng ký trùng
• Nhiều cuộc gọi hay email xác nhận đơn
• Sau nhận đơn còn xử lý tồn kho, xuất hàng, hóa đơn
• Nhân viên nghỉ thì xử lý tắc
• Tổng hợp lịch sử đơn hay tình trạng giao dịch mất thời gian

Ngược lại, đối tác chỉ giao dịch vài lần mỗi năm, hoặc giao dịch nội dung đơn mỗi lần khác lớn, thì chi phí xây và vận hành EDI có thể lớn hơn hiệu quả.

Có triển khai EDI hay không không quyết chỉ theo quy mô công ty. Cơ quan Doanh nghiệp vừa và nhỏ Nhật Bản cũng xây “EDI chung cho SME” nhằm chuẩn hóa nghiệp vụ đặt hàng / nhận đơn cho doanh nghiệp vừa và nhỏ, và cho thấy hiệu quả nghiệp vụ khi giảm terminal chuyên dụng và giấy, quản chứng từ thống nhất như dữ liệu. Điều cần nhìn không phải số nhân viên, mà lượng nhập, xác nhận, chép lại đang lặp.

11. Cách tiến hành khi cân nhắc triển khai EDI

Khi xem xét EDI, không cần chọn sản phẩm hay cách truyền thông từ đầu. Trước hết, sắp xếp nghiệp vụ hiện tại.

11.1. Lập danh sách cách đặt hàng / nhận đơn hiện tại

Với từng đối tác, sắp các thông tin sau.

Sắp thế này thì thấy đối tác và nghiệp vụ hiệu quả EDI hóa lớn. Số lượng và thời gian đưa vào phép tính chương 7.1 cũng lấy từ bảng này.

11.2. Bắt đầu từ một đối tác có khối lượng lớn

Lấy mọi đối tác từ đầu thì mục điều chỉnh tăng, triển khai kéo dài. Thực tế là chọn trước một đối tác khớp các điều sau.

• Số giao dịch nhiều
• Đơn định hình nhiều
• Nhân viên hai bên liên lạc dễ
• Có hiểu về liên thông hệ thống
• Dễ đo hiệu quả

Chốt cách vận hành với một công ty, rồi mới mở sang đối tác khác.

11.3. Thu hẹp phạm vi trao đổi

Không cần ngay từ đầu lấy hết báo giá, nhận đơn, xuất hàng, nghiệm thu, hóa đơn, thanh toán. Ví dụ, EDI hóa trước đúng dữ liệu đơn đang nặng nhập nhất, rồi mở dần như sau.

1. Giai đoạn 1: Dữ liệu đơn hàng
2. Giai đoạn 2: Xác nhận nhận đơn · trả lời hạn giao
3. Giai đoạn 3: Thông báo xuất hàng
4. Giai đoạn 4: Dữ liệu hóa đơn

Tăng đối tượng từng bước thì vừa kìm tác động hiện trường vừa xác nhận hiệu quả.

11.4. Xác nhận kết nối với hệ thống nội bộ

Dù triển khai dịch vụ EDI, nếu không nạp được dữ liệu vào hệ thống quản lý bán hàng hiện có thì nhập tay vẫn còn. Hãy xác nhận trước các điểm sau.

• Có chức năng nhập xuất CSV không
• Dùng API được không
• Liên thông với database được không
• Chuyển mã sản phẩm làm ở đâu
• Chống trùng dữ liệu nhận thế nào
• Lỗi báo cho ai
• Lịch sử xử lý để ở đâu

Quan trọng là xác nhận cách nối với hệ thống hiện có trước khi chọn sản phẩm. Nếu ở đây biết “không nhập xuất CSV được”, “không có API”, thì việc trước không phải chọn dịch vụ EDI mà là sửa hệ thống hiện có hoặc chuẩn bị cơ chế trung chuyển.

12. Chỉ số nên đo sau khi triển khai EDI

Sau khi triển khai EDI, đừng dừng ở “dùng được rồi”; hãy xác nhận nghiệp vụ đổi bao nhiêu. Ví dụ, so các chỉ số sau trước và sau. Thay số dùng ở phép tính chương 7.1 bằng số đo thực thì thấy luôn khoảng cách giữa giả định và thực tế.

• Thời gian nhập nhận đơn
• Thời gian xử lý xong một đơn
• Số lần sửa nhập
• Số đăng ký trùng
• Số lần hỏi xác nhận đơn
• Số lần chậm xuất hàng
• Tỷ lệ đơn xử lý được bằng EDI
• Tỷ lệ đơn ngoại lệ người đã xác nhận

Điều quan trọng với EDI không phải gửi được dữ liệu. Đánh giá bằng việc làm tay thực sự giảm, xử lý nhanh hơn, sai ít hơn.

Tóm tắt

EDI là cơ chế trao đổi thông tin phát sinh giữa doanh nghiệp — đơn hàng, xuất hàng, hóa đơn — dưới dạng dữ liệu điện tử mà máy tính xử lý được ngay. Chỉ đổi FAX sang email thì giấy có thể giảm nhưng nhập tay vẫn còn. Hiệu quả thực của EDI nằm ở việc dữ liệu nhận từ đối tác nối thẳng vào các hệ thống nội bộ như quản lý bán hàng, tồn kho, xuất hàng, kế toán.

Các thay đổi chính kỳ vọng từ EDI như sau.

• Giảm nhập tay vừa nhìn phiếu đặt hàng
• Giảm lỗi nhập do chép lại
• Nhanh hơn từ nhận đơn tới xuất hàng
• Dễ xác nhận tình trạng xử lý đơn và hóa đơn
• Nối tồn kho, xuất hàng, doanh thu, hóa đơn
• Dùng dữ liệu giao dịch đã tích lũy cho tổng hợp và dự báo nhu cầu
• Giảm nghiệp vụ phụ thuộc vào từng nhân viên

Tuy nhiên, chỉ ký dịch vụ EDI thì chưa đủ. Cần sắp dữ liệu như mã sản phẩm, chốt quy tắc vận hành với đối tác, và nạp được dữ liệu vào hệ thống nội bộ hiện có.

Điểm xuất phát triển khai EDI không phải “dùng sản phẩm nào”, mà là điều tra cùng một thông tin đang bị nhập bao nhiêu lần trong nghiệp vụ hiện tại. Tìm chỗ người đang chuyển thông tin giữa FAX, email, Excel, màn hình Web, hệ thống quản lý bán hàng, rồi từ những việc số lượng lớn và định hình, lần lượt thay bằng liên thông dữ liệu — đó là cách thực tế.

Dành cho ai đang cân nhắc liên thông dữ liệu đặt hàng và nhận đơn

Muốn hiệu quả hóa đặt hàng / nhận đơn giữa doanh nghiệp nhưng không biết bắt đầu xem lại vận hành FAX · email · Excel từ đâu, thì trước hết cần sắp xếp luồng nghiệp vụ.

Xác nhận đang nhận thông tin từ đối tác bằng định dạng nào, nhập vào hệ thống nội bộ nào, rồi nối sang tồn kho · xuất hàng · hóa đơn thế nào, thì thấy phạm vi tự động hóa được.

KomuraSoft LLC nhận tư vấn sắp xếp hiện trạng và cách hiện thực liên thông nghiệp vụ gồm ứng dụng nghiệp vụ Windows hiện có, CSV, file độ dài cố định, database, hệ thống Web.

Không lấy tiền đề thay toàn bộ; cấu hình giữ cơ chế hiện tại và chỉ giảm phần nhập tay cũng cân nhắc được.

Liên kết tham khảo

• JIPDEC (一般財団法人日本情報経済社会推進協会 / Japan Information Economy and Society Promotion Association), EDI là gì. Về định nghĩa EDI (các doanh nghiệp, cơ quan hành chính, v.v. nối máy tính bằng mạng và tự động trao đổi chứng từ, tài liệu dưới dạng dữ liệu điện tử), định nghĩa theo JIS X 7011, cơ chế chuyển đổi qua lại giữa định dạng riêng của từng công ty và định dạng chuẩn, và việc ảnh scan hay email văn thường được phân biệt với dữ liệu EDI.
• JIPDEC, Lợi ích của EDI và sự cần thiết của chuẩn EDI. Về tăng hiệu suất và tốc độ công việc văn phòng, giao hàng just-in-time, rút lead time, nén tồn kho, loại lỗi do người, dùng cho phân tích hàng bán chạy, spend analysis và dự báo nhu cầu, việc không theo chuẩn thì phải có cơ chế chuyển đổi theo từng đối tác nên chi phí không tương xứng, năm hạng mục cần thỏa thuận (giao thức truyền thông, quy tắc cú pháp, thông điệp và trường dữ liệu, quy ước vận hành nghiệp vụ, quy ước cơ bản giao dịch), và việc in dữ liệu nhận rồi xử lý tay thì khác FAX không nhiều.
• Cơ quan Doanh nghiệp vừa và nhỏ Nhật Bản (中小企業庁), Số hóa đặt hàng / nhận đơn (EDI chung cho SME). Về tăng hiệu suất công việc, giảm lỗi do người, dễ tìm lại hồ sơ giao dịch nhờ số hóa đặt hàng / nhận đơn, và việc xây “EDI chung cho SME” nhằm chuẩn hóa nghiệp vụ đặt hàng / nhận đơn cho doanh nghiệp vừa và nhỏ.
• Digital Agency (デジタル庁), JP PINT (spec chuẩn hóa đơn điện tử). Về việc Digital Agency, với tư cách Peppol Authority của Nhật, quản lý và công bố spec chuẩn hóa đơn điện tử Nhật “JP PINT” trao đổi trên mạng Peppol.

Bài viết liên quan

Các bài viết gần đây có cùng thẻ để tìm hiểu sâu hơn những chủ đề lân cận.

Chủ đề liên quan

Các trang này đặt chủ đề trong bối cảnh rộng hơn của dịch vụ và quyết định.

Dịch vụ liên quan đến chủ đề này

Bài viết liên quan trực tiếp đến các dịch vụ sau.

Hồ sơ tác giả

Trang giới thiệu tác giả bài viết.

Go Komura

Đại diện của KomuraSoft LLC

Chuyên về phát triển phần mềm Windows, tư vấn kỹ thuật và điều tra lỗi, đặc biệt trong các dự án có hệ thống hiện hữu và lỗi khó tái hiện.