Cách chuyển nhận đơn FAX sang Web ── thiết kế giai đoạn vận hành song song và thực tiễn chuyển từng bước

Bài trước “EDI là gì? Cách giúp đặt hàng và nhận đơn giữa doanh nghiệp dễ hơn” đã trình bày cơ chế thay việc người nhận đơn FAX hay email rồi nhập lại bằng trao đổi dữ liệu giữa các hệ thống.

Bài này là phần tiếp. Chủ đề đi một bước khỏi “hiểu cơ chế”, sang cách chuyển đổi.

Yêu cầu “muốn đưa nhận đơn FAX lên Web” thường nối tiếp như thế này.

“Nhưng có đối tác chỉ dùng được FAX”

“Hệ thống quản lý bán hàng muốn giữ nguyên”

“Trong lúc chuyển, đơn hàng không được dừng”

Nghĩa là bài toán thực tế không phải làm hệ thống đặt hàng Web. Là thiết kế giai đoạn chuyển dần sang Web trong khi FAX vẫn còn.

Bài viết này trình bày việc đưa nhận đơn FAX lên Web quanh bốn điểm: thiết kế giai đoạn vận hành song song, import CSV như dạng trung gian, chỉnh sửa master sản phẩm và đối tác, và cách vận động đối tác cùng tham gia.

Đối tượng bài viết là người phụ trách nhận đơn và người phụ trách hệ thống thông tin tại công ty đang nhập tay đơn FAX hay email vào hệ thống quản lý bán hàng. Đọc xong, điều mang về không phải cách làm bản thân hệ thống đặt hàng Web, mà cách dựng kế hoạch chuyển đổi: “đối tác nào, theo thứ tự nào, đo cái gì trong lúc chuyển”. Nếu muốn nắm toàn cảnh cơ chế trước, hãy đọc bài EDI trước.

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

Các điểm chính khi lập kế hoạch đưa nhận đơn FAX lên Web như sau.

• Đặt mục tiêu không phải “bỏ FAX” mà là “giảm số đơn mà người phải nhập”
• Lấy tiền đề giai đoạn FAX và Web chạy song song chắc chắn xảy ra, rồi thiết kế trước thời hạn và cách đo
• Cách tiếp nhận (kênh) có thể nhiều, nhưng xử lý nhận đơn trong công ty gom thành một luồng
• Không đòi nhập trên màn hình Web ngay, mà chuẩn bị import CSV như dạng trung gian
• Màn hình đặt hàng Web đưa master sản phẩm và đối tác ra trước mắt đối tác, nên chỉnh sửa master trước
• Không chuyển tất cả đối tác cùng lúc, mà phân loại theo số lượng và mức hợp tác, rồi chuyển theo thứ tự

JIPDEC (đọc là Jipudekku, 一般財団法人日本情報経済社会推進協会 / Japan Information Economy and Society Promotion Association, tổ chức được biết đến với hệ thống PrivacyMark và vận hành mã doanh nghiệp chuẩn) cũng viết trên trang giải thích nghiệp vụ mã doanh nghiệp chuẩn “Lợi ích của EDI và sự cần thiết của chuẩn”: “Nếu vẫn còn xử lý thủ công, tiếp FAX và điện thoại, thì vẫn phải bố trí nhân sự cho việc đó, không tự động hóa và cơ giới hóa 100% được, và hiệu quả cải thiện năng suất không đạt đầy đủ.” Chính vì vậy, giai đoạn vận hành song song không để “đành phải xảy ra” rồi bỏ đó, mà bản thân kế hoạch làm nó ngắn lại mới là đối tượng thiết kế.

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

Bài viết này trình bày thiết kế chuyển từng bước nhận đơn FAX, không chuyển toàn bộ sang Web ngay mà lấy mục tiêu giảm số đơn người phải nhập. Kênh tiếp nhận có thể nhiều nhưng xử lý nhận đơn trong công ty gom thành một luồng; chèn import CSV như dạng trung gian, rồi phân loại đối tác A/B/C theo số lượng và mức hợp tác, tạo khuôn với một công ty pilot rồi mở rộng. Giai đoạn vận hành song song đặt hạn và chỉ tiêu bằng số, đo số lượng theo kênh mỗi tháng nhờ cột kênh tiếp nhận. Bảng chuyển mã do phía mình — bên biết thay đổi sản phẩm trước — giữ; sau import CSV là các dạng cao hơn như mã doanh nghiệp chuẩn và EDI.

flowchart LR
    accTitle: Bản đồ tri thức chuyển nhận đơn FAX sang Web từng bước
    accDescr: Sơ đồ thiết kế chuyển từng bước: đặt mục tiêu giảm số đơn người phải nhập, dùng import CSV như dạng trung gian cùng phân loại đối tác và tạo khuôn với một công ty pilot để rút ngắn giai đoạn vận hành song song theo hạn
    fax_order_web_migration["Chuyển nhận đơn FAX sang Web (từng bước)"]
    dual_operation_period["Giai đoạn vận hành song song"]
    transcription_volume_reduction_goal["Mục tiêu giảm số đơn phải nhập tay"]
    all_at_once_web_migration["Chuyển toàn bộ sang Web ngay"]
    indefinite_dual_operation["Vận hành song song vô hạn / cố định"]
    dual_operation_deadline_target["Hạn và chỉ tiêu vận hành song song"]
    channel_migration_kpi["Đo số lượng theo kênh"]
    receiving_channel_field["Cột kênh tiếp nhận"]
    csv_import_intermediate_form["Import CSV làm dạng trung gian"]
    csv_file_format_spec["Thỏa thuận định dạng file CSV"]
    master_data_readiness["Hoàn thiện master sản phẩm và đối tác"]
    pilot_partner_approach["Tạo mẫu với 1 đối tác pilot"]
    partner_classification["Phân loại đối tác (A/B/C)"]
    unified_order_channel_processing["Nhiều kênh tiếp nhận, xử lý nội bộ một luồng"]
    code_mapping_ownership_rule["Quy tắc giữ bảng chuyển mã"]
    all_or_nothing_import_validation["Chính sách dừng cả lô khi có lỗi"]
    import_failure_notification["Thông báo tối thiểu khi import thất bại"]
    cross_channel_rule_consistency["Thống nhất quy tắc vận hành giữa các kênh"]
    duplicate_order_registration["Đăng ký trùng"]
    fax_handling_improvement["Cải thiện cách nhận FAX"]
    edi["EDI (trao đổi dữ liệu điện tử)"]
    standardized_business_code["Mã doanh nghiệp chuẩn"]
    fax_order_web_migration -->|"yêu cầu"| dual_operation_period
    transcription_volume_reduction_goal -->|"khuyến nghị cho"| fax_order_web_migration
    all_at_once_web_migration -->|"có thể gây"| indefinite_dual_operation
    transcription_volume_reduction_goal -->|"ngăn chặn"| all_at_once_web_migration
    dual_operation_deadline_target -->|"giảm thiểu"| indefinite_dual_operation
    channel_migration_kpi -->|"sử dụng"| receiving_channel_field
    dual_operation_deadline_target -->|"xác minh bằng"| channel_migration_kpi
    csv_import_intermediate_form -->|"khuyến nghị cho"| fax_order_web_migration
    csv_import_intermediate_form -->|"sử dụng"| csv_file_format_spec
    csv_import_intermediate_form -->|"yêu cầu"| master_data_readiness
    pilot_partner_approach -->|"yêu cầu"| master_data_readiness
    partner_classification -->|"khuyến nghị cho"| fax_order_web_migration
    partner_classification -->|"nên làm trước"| pilot_partner_approach
    unified_order_channel_processing -->|"khuyến nghị cho"| fax_order_web_migration
    code_mapping_ownership_rule -.->|"khuyến nghị cho"| csv_import_intermediate_form
    all_or_nothing_import_validation -.->|"khuyến nghị cho"| csv_import_intermediate_form
    all_or_nothing_import_validation -->|"yêu cầu"| import_failure_notification
    cross_channel_rule_consistency -->|"khuyến nghị cho"| fax_order_web_migration
    cross_channel_rule_consistency -->|"giảm thiểu"| duplicate_order_registration
    fax_handling_improvement -->|"khuyến nghị cho"| dual_operation_period
    edi -->|"kế nhiệm"| csv_import_intermediate_form
    standardized_business_code -.->|"khuyến nghị cho"| edi
    partner_classification -->|"ngăn chặn"| all_at_once_web_migration

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 23, 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. Vì sao chuyển toàn bộ sang Web ngay dễ thất bại

Đưa nhận đơn FAX lên Web có đặc điểm không quyết được chỉ theo tiện hệ thống nội bộ. Người gửi đơn là đối tác.

Cách gửi thông báo cho mọi đối tác “từ tháng sau hãy đặt hàng trên Web” dễ dẫn tới các thất bại sau.

• Đối tác chỉ đặt được bằng FAX không còn là “ngoại lệ” mà thành “chướng ngại của kế hoạch”
• Mỗi đối tác hoàn cảnh khác nhau, vậy mà cùng một hạn chót bị áp cho tất cả
• Đơn của đối tác không chuyển vẫn tới bằng FAX, giai đoạn vận hành song song kéo dài vô hạn
• Đánh giá thành “đã lên Web mà người không giảm”, dự án dừng

Nguyên nhân là đã đặt mục tiêu ở “bỏ FAX”.

Đổi mục tiêu thành “giảm số đơn mà người phải nhập” thì kế hoạch thực tế hơn. Ví dụ, chỉ các đối tác chiếm khoảng 70% đơn chuyển sang Web hoặc CSV, thì dù 30% còn lại vẫn FAX, việc nhập tay vẫn giảm rõ.

Không đẩy cả khối cùng lúc, mà đẩy chỗ hiệu quả lớn trước. Đó là nguyên tắc chuyển đổi từng bước.

3. Trạng thái sau chuyển đổi ── nhiều cổng vào, một luồng xử lý nội bộ

Trước khi thiết kế chuyển đổi từng bước, hãy phác trước hình trạng cần tới.

Điểm mấu chốt là tách kênh tiếp nhận khỏi xử lý nhận đơn.

flowchart LR
    accTitle: Nhiều kênh tiếp nhận, một luồng xử lý nội bộ
    accDescr: FAX, đính kèm email, import CSV và màn hình đặt hàng Web đều hội tụ vào dữ liệu đơn hàng dùng chung rồi đi tiếp sang xử lý nội bộ gồm phân bổ tồn kho, xuất hàng và hóa đơn.
    ORDER["Dữ liệu đơn hàng dùng chung<br/>(thống nhất định dạng)"]
    BACK["Xử lý nội bộ<br/>Phân bổ tồn kho · xuất hàng · hóa đơn"]
    subgraph CH["Kênh tiếp nhận"]
        FAX["FAX"]
        MAIL["Đính kèm email"]
        CSV["Import CSV"]
        WEB["Màn hình đặt hàng Web"]
    end
    FAX -->|"Nhân viên nhập"| ORDER
    MAIL -->|"Nhân viên nhập"| ORDER
    CSV -->|"Import tự động"| ORDER
    WEB -->|"Đăng ký tự động"| ORDER
    ORDER --> BACK

Dù có bao nhiêu loại kênh tiếp nhận, miễn định dạng và xử lý dữ liệu đơn hàng phía sau được gom thành một luồng, thì các bước sau như tồn kho, xuất hàng, hóa đơn vẫn chạy chung.

Ngược lại, nếu mỗi kênh có xử lý riêng hay sổ riêng, mỗi lần thêm kênh nghiệp vụ phức tạp thêm, gánh vận hành song song cứ tăng.

Đơn tới bằng FAX, lúc nhân viên nhập xong, cũng phải thành cùng một dữ liệu đơn hàng như các kênh khác. Có thể nói chuyển đổi chính là việc giảm số đơn chảy ở hàng “nhân viên nhập” trong hình này, và tăng số đơn chảy ở hàng “import tự động” và “đăng ký tự động”.

Không nhất thiết phải thay hệ thống quản lý bán hàng hiện có. Chỉ cần xác nhận được là có thêm được cổng vào cho dữ liệu đơn hàng (chức năng import CSV, liên thông database, API, v.v.), thì giữ cơ chế hiện tại vẫn đi tiếp được. Điểm xác nhận này đã được trình bày trong “Xác nhận kết nối với hệ thống nội bộ” của bài EDI trước.

4. Import CSV như dạng trung gian

Nhờ đối tác nhảy thẳng từ FAX sang nhập trên màn hình Web đôi khi là gánh nặng lớn với họ.

Từ phía người đặt hàng, nhập trên màn hình Web nghĩa là “lấy đơn đã làm trên hệ thống đặt hàng hay Excel của mình, rồi nhập lại một lần nữa trên màn hình của đối phương”. Nếu đối tác đã tạo dữ liệu đơn hàng bằng cơ chế của họ, thì nhận nguyên file rồi import khiến việc của cả hai bên ít hơn.

Vì vậy, như dạng trung gian, hãy chuẩn bị import CSV (hoặc Excel).

Giai đoạn 1: Nhận CSV đính kèm email, nhân viên nạp bằng chức năng import
Giai đoạn 2: Đối tác upload CSV từ trang Web, hệ thống import tự động
Giai đoạn 3: Đối tác đã thành nếp chuyển sang màn hình đặt hàng Web hoặc EDI

Ngay giai đoạn 1, so với nhập tay vừa nhìn phiếu đặt hàng, thời gian nhập và lỗi chép lại đã giảm rõ. Thay đổi phía đối tác chỉ ở mức “cái từng gửi FAX thì gửi đính kèm email”, nên dễ xin hợp tác — đó cũng là lợi.

Khi thiết kế import CSV, tối thiểu hãy quyết các mục sau.

Trong sáu mục này, chỗ thực tế tranh cãi nhất là hệ mã. “Để đối tác gửi bằng mã sản phẩm của họ” hay “để họ đổi sang mã của mình rồi gửi” quyết bên nào giữ bảng chuyển mã. Bộ phận kinh doanh nói “nhờ đối tác gửi bằng mã của mình thì dễ hơn”; bộ phận hệ thống thông tin nói “giữ bảng chuyển mã theo từng đối tác là gánh”.

Chỗ chốt là: bảng chuyển mã do bên biết thay đổi sản phẩm trước giữ. Bên biết hàng mới và hàng ngừng trước là phía mình, nên để phía mình chuyển mã thì mỗi lần thêm/bỏ hàng không phải nhờ mọi đối tác “hãy thay bảng mã”. Cách bắt đối tác nhớ mã của mình lúc bắt đầu thì dễ, nhưng mỗi lần thêm/bỏ hàng lại phải liên lạc theo đầu người. Xong vòng này trước khi chuyển thì sau không phải giải thích lại “vì sao thiết kế thế này”.

Một điểm nữa gắn thẳng với vận hành là cách trả lỗi. Import về nguyên tắc nên “dừng cả lô khi có lỗi” (một hàng sai thì không import gì). An toàn hơn đuổi theo đơn đã vào một phần. Nhưng điều đó chỉ đứng nếu việc dừng chắc chắn tới được ai đó. Cấu hình tối thiểu như sau.

• Email nội bộ ── tự gửi “import thất bại” tới mailing list phụ trách nhận đơn. Tiêu đề có tên file và tên đối tác; thân thư liệt kê số hàng lỗi và nguyên nhân (ví dụ “mã sản phẩm ABC-123 không có trong master”).
• Lịch sử import trên màn hình quản trị ── màn hình thấy được thành công / thất bại / chưa xử lý. Lỡ email, nhìn đây lúc đầu ngày vẫn biết.
• Liên lạc với đối tác ── ban đầu không tự trả lời; nhân viên nội bộ xem xong rồi liên lạc. Tới giai đoạn upload trên Web, chuyển sang hiện lỗi ngay trên màn hình upload.

Thiết kế “lỗi đã ghi log, hãy tự xem” không hợp giai đoạn vận hành song song. Nhân viên đang kín việc xử lý FAX.

CSV trông đơn giản, nhưng dễ vướng ở mã ký tự, xuống dòng, dấu phẩy và dấu ngoặc kép. Các lưu ý kỹ thuật khi triển khai xử lý import được gom trong “Hướng dẫn thực tế xử lý file CSV”.

Import CSV không phải dạng cuối, mà là dạng trung gian. Định nghĩa trường và hệ mã quyết ở đây sẽ thành nền cho đặt hàng Web và EDI về sau.

5. Chỉnh sửa master sản phẩm và đối tác trước

Với nhận đơn FAX, chỗ master thiếu do nhân viên gánh.

Ví dụ, phiếu đặt ghi tên hàng cũ, nhân viên vẫn đọc “đây là hàng hiện hành này” rồi nhập. Đơn vị ghi “thùng”, họ nhớ một thùng bao nhiêu cái rồi quy đổi.

Sang import CSV hay đặt hàng Web, việc đọc thay đó do máy làm. Hơn nữa, trên màn hình đặt hàng Web, master sản phẩm hiện nguyên trước mắt đối tác.

Vì vậy, trước khi chuyển, tối thiểu cần chỉnh các mục sau.

• Sắp mã sản phẩm (dọn hàng ngừng, gộp trùng, bảng tương ứng mã cũ–mới)
• Thống nhất cách viết tên hàng (tên có đưa ra được cho đối tác không)
• Đơn vị và số lượng trong kiện (quan hệ lẻ · thùng · pallet, số lượng đặt tối thiểu)
• Mã đối tác và mã nơi giao (cách xử lý một đối tác có nhiều nơi giao)
• Giá áp dụng và điều kiện hợp đồng theo đối tác quản ở đâu

Điều quan trọng là đừng chờ master hoàn hảo rồi mới bắt đầu. Chờ thì việc chuyển không bao giờ khởi.

Cách thực tế là chỉnh trước đúng phạm vi sản phẩm và nơi giao mà đối tác chuyển đầu (pilot) đang dùng, rồi mở rộng mỗi lần thêm đối tác. Bản thân việc chỉnh sửa master gắn vào các pha của chuyển đổi từng bước.

6. Thiết kế giai đoạn vận hành song song

FAX và Web (CSV) chạy song song chắc chắn xảy ra trong thời gian chuyển. Không thiết kế mà để mặc, vận hành song song thành thường trực, thành trạng thái “thêm kênh bao nhiêu thì việc tăng bấy nhiêu”.

Thiết kế giai đoạn vận hành song song, cụ thể, là quyết các việc sau.

6.1. Quyết thời hạn và chỉ tiêu

Quyết bằng số “đến khi nào, bao nhiêu phần đơn được import tự động”. Ví dụ dạng “trong 6 tháng, tỷ lệ nhận đơn FAX từ 70% xuống 30%”.

Vận hành song song không hạn chót sẽ cố định luôn. Dù không đạt, có hạn chót thì dẫn tới hành động hỏi từng đối tác “vì sao chưa chuyển”.

6.2. Đo số lượng theo kênh mỗi tháng

Tiến độ chuyển theo dõi bằng số, không bằng cảm giác.

• Số đơn theo kênh (FAX, đính kèm email, CSV, Web)
• Số đơn nhập tay và thời gian mất
• Số lỗi import và nguyên nhân
• Số lần sửa nhập và đăng ký trùng

Cùng tư duy với các chỉ số nên đo sau khi triển khai nêu ở bài trước. Đo tách theo kênh thì thấy “tác động đối tác nào thì hiệu quả lớn”.

Vấn đề là lấy số đó bằng cách nào. Quyết “hàng tháng hãy đếm” mà không có cơ chế thì tháng đầu đã dừng. Cách chắc là thêm một trường đo vào chính dữ liệu đơn hàng.

Nếu hệ thống quản lý bán hàng hiện có không thêm cột được, hãy giữ log của xử lý import và màn hình nhập ở bảng riêng rồi tổng hợp từ đó. Dù cách nào, cách đo phải quyết trước khi bắt đầu chuyển. Tiêu chí phán pha ở chương 8 dựa trên tỷ lệ kênh; không lấy được tỷ lệ thì không quyết được đi pha tiếp hay đứng lại.

6.3. Thống nhất quy tắc vận hành giữa các kênh

Rối trong giai đoạn vận hành song song dễ xảy ra khi quy tắc nghiệp vụ khác nhau theo kênh.

• Giờ chốt nhận đơn FAX và Web có giống nhau không
• Đổi đơn / hủy đơn nhận ở kênh nào (đơn nhận trên Web mà đổi bằng FAX thì phải đối chiếu)
• Cách báo khi thiếu hàng có đổi theo kênh không
• Số đơn có duy nhất xuyên kênh không (cần để phát hiện đăng ký trùng)

Đặc biệt, mẫu “đặt trên Web, ngay sau đó đổi bằng điện thoại hay FAX” chắc chắn xảy ra. Hãy quyết trước kênh nào nhận thay đổi, ai sửa dữ liệu nào.

6.4. Cách nhận FAX cũng là đối tượng cải thiện

Trong giai đoạn vận hành song song, FAX còn. Đã lấy tiền đề còn, thì xử lý phía FAX cũng là đối tượng cải thiện.

• Nhận FAX trên máy đa năng, xuất PDF, bỏ quản lý giấy
• Gom PDF đã nhận vào thư mục đơn hàng, quản trạng thái xử lý (chưa xử lý / đã nhập / tạm giữ)
• Nối bản FAX gốc (PDF) sau khi nhập với dữ liệu đơn hàng bằng số đơn, để sau còn đối chiếu được

Nghĩ “FAX rồi cũng mất nên không đụng” thì gánh trong giai đoạn vận hành song song không xuống. Cho tới khi chuyển xong, xử lý FAX cũng là một kênh nhập vào cùng dữ liệu đơn hàng.

7. Cách vận động đối tác cùng tham gia

Thành bại của chuyển đổi từng bước do cách tác động đối tác hơn là việc trong công ty.

7.1. Phân loại đối tác

Không đối xử mọi đối tác như nhau — hãy phân loại trước.

Hiệu quả do A và B quyết. Ép C chuyển thì tốn chi phí, nên nói thẳng “chúng tôi vẫn nhận FAX” với những đối tác này được.

7.2. Chọn một đối tác pilot

Không chuyển song song nhiều công ty từ đầu; hãy chốt vận hành với một công ty trước. Tiêu chí chọn giống bài trước.

• Số giao dịch lớn, dễ đo hiệu quả
• Đơn mang tính đị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

Với pilot, làm “khuôn” gồm format CSV, cách liên lạc khi lỗi, bảng tương ứng master, văn bản hướng dẫn; từ công ty thứ hai trở đi tái sử dụng khuôn đó.

7.3. Giới thiệu bằng lợi ích của đối tác

Với đối tác, đổi cách đặt hàng là yêu cầu vì tiện mình. Hướng dẫn hãy nói bằng lợi ích của họ, không phải bằng hiệu quả của mình.

• Xác nhận nhận đơn trả ngay, khỏi gọi hỏi “đã tới chưa”
• Giảm giao sai / sai số lượng vì đọc nhầm
• Tự xem được lịch sử đơn, đặt lại dễ hơn (với đặt hàng Web)
• Hết việc gửi FAX và gửi lại khi lỗi gửi

Kèm theo, vài sự chiếu cố thực tế cũng có hiệu quả.

• Quy trình thao tác gom vào một tờ hướng dẫn (quy mô đủ với vài màn hình)
• Nêu rõ ngày bắt đầu và giai đoạn dùng chung (“Từ tháng ◯ cũng nhận trên Web. FAX vẫn dùng chung trong thời gian này”)
• Vài lần đầu, FAX hay Web gửi tới đều nhận, hỏi là đáp ngay

Không khuyến nghị ngay từ đầu thông báo “FAX sẽ bỏ vào tháng ◯”. Chỉ nói hạn khi chuyển đã chạy và đối tác còn lại đã ít — giữ quan hệ hơn.

Về số hóa đặt hàng / nhận đơn của doanh nghiệp vừa và nhỏ, Cơ quan Doanh nghiệp vừa và nhỏ Nhật Bản (中小企業庁) giới thiệu các nỗ lực chuẩn hóa gồm EDI chung và hiệu quả của chúng. Nếu hiệp hội ngành hoặc đối tác chính đã theo chuẩn đó, hãy cân nhắc khớp chuẩn thay vì format riêng.

8. Mô hình chuyển đổi từng bước

Nội dung đến đây được sắp thành mô hình theo thời gian. Thời hạn chỉ là ví dụ; số đối tác và tổ chức nội bộ sẽ làm nó đổi.

“Sắp xếp hiện trạng” của pha 0 dùng được nguyên lập danh sách cách đặt hàng / nhận đơn giới thiệu ở bài trước.

Nếu đang phân vân bản thân quản lý nhận đơn nên chuyển sang hệ thống Web hay giữ ứng dụng desktop, khung phán đoán được trình bày trong “Có nên đưa ứng dụng Windows lên Web”. Đưa kênh tiếp nhận lên Web và đưa hệ thống nội bộ lên Web có thể phán tách nhau.

9. Vướng mắc thường gặp và cách xử lý

Cuối cùng, gom các vướng dễ xảy ra khi chuyển thực tế.

Tóm tắt

Đưa nhận đơn FAX lên Web không phải việc làm hệ thống, mà là việc thiết kế thời gian chuyển.

• Mục tiêu đặt ở “giảm số đơn mà người phải nhập”, không phải “bỏ FAX”
• Kênh tiếp nhận có thể nhiều, nhưng dữ liệu đơn hàng và xử lý trong công ty gom thành một luồng
• Không đòi nhập trên màn hình Web ngay; chèn dạng trung gian import CSV
• Chỉnh sửa master tiến từng bước từ phạm vi đối tác chuyển đầu
• Giai đoạn vận hành song song có hạn và chỉ tiêu; đo tiến độ bằng số theo kênh
• Phân loại đối tác theo số lượng và mức hợp tác, làm khuôn với một công ty pilot rồi mới mở rộng

Như bài trước đã trình bày, hiệu quả của EDI hay đặt hàng Web do dữ liệu nhận được chảy tới đâu trong nghiệp vụ nội bộ quyết. Thiết kế chuyển đổi là kế hoạch tăng, theo thứ tự không gượng, tỷ lệ đơn nhập vào luồng đó.

Dành cho ai đang cân nhắc đưa đặt hàng / nhận đơn lên Web

Đang xem lại nhận đơn FAX nhưng phân vân bắt đầu từ đâu — phối hợp đối tác, nối hệ thống quản lý bán hàng hiện có, format CSV, cách chỉnh sửa master — thì cần bắt đầu từ việc sắp xếp số đơn theo kênh hiện tại.

KomuraSoft LLC nhận tư vấn thiết kế và triển khai liên thông import CSV / đặt hàng Web trên ứng dụng nghiệp vụ Windows và database hiện có, cũng như sắp xếp chính kế hoạch chuyển đổi.

Không lấy tiền đề thay toàn bộ; cấu hình giữ cơ chế quản lý bán hàng hiện tại, chỉ thêm dần kênh tiếp nhận, cũng cân nhắc được.

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.