Custom Service xử lý những yêu cầu nào?

Những yêu cầu di chuyển dữ liệu phi tiêu chuẩn thường khó xử lý vì một lý do mà số lượng bản ghi không thể hiện được: ý nghĩa của dữ liệu không phải lúc nào cũng nằm ngay trong tên trường. Một giá trị Products tùy chỉnh có thể chi phối chức năng tìm kiếm, giá bán hoặc quá trình xử lý đơn hàng. Mã định danh Orders từ hệ thống bên ngoài có thể kết nối cửa hàng với hệ thống kế toán. Bản ghi do ứng dụng quản lý có thể đại diện cho gói đăng ký, số dư điểm thưởng, người bán trên marketplace hoặc một quy trình vận hành.

Nếu chỉ chuyển giá trị mà không hiểu vai trò đó, Cửa hàng đích có thể trông đầy đủ nhưng không còn hỗ trợ đúng hoạt động kinh doanh. Với Dịch vụ chuyển đổi dữ liệu của Next-Cart, Custom Service giải quyết khoảng trống này bằng cách chuyển một yêu cầu phi tiêu chuẩn thành kết quả chuyển đổi đã được thống nhất, với dữ liệu nguồn được mô tả rõ, cách thể hiện trên hệ thống đích, công việc cần xử lý riêng và tiêu chí chấp nhận được xác định rõ.

Mục tiêu không phải là gắn nhãn tùy chỉnh cho toàn bộ dự án. Điều quan trọng là xác định chính xác những yêu cầu mà các chức năng hiện được hỗ trợ và Standard Add-ons chưa đáp ứng đủ, sau đó xác định thế nào là một kết quả sau di chuyển có thể sử dụng được.

Xác định vì sao yêu cầu nằm ngoài phạm vi tiêu chuẩn

Một yêu cầu có thể cần Custom Service khi nguồn dữ liệu, cấu trúc, quy tắc xử lý, mối quan hệ hoặc vị trí cần lưu dữ liệu trên hệ thống đích vượt ngoài phạm vi xử lý tiêu chuẩn được hỗ trợ.

Các câu hỏi này giúp phạm vi tùy chỉnh trở nên rõ ràng và có thể giải thích. Yêu cầu chung chung như "di chuyển toàn bộ dữ liệu tùy chỉnh" không đáp ứng được mục đích đó. Một yêu cầu hữu ích phải xác định bản ghi bị ảnh hưởng, mục đích kinh doanh cần được duy trì, kết quả mong muốn tại Cửa hàng đích và kết quả cần dùng để xác nhận thành công.

Công việc với Custom Platform phải bắt đầu từ mô hình dữ liệu

Custom Platform có thể là Nền tảng nguồn, Nền tảng đích hoặc cả hai. Thách thức không chỉ nằm ở việc thiết lập quyền truy cập. Dự án còn phải xác định cửa hàng đang thể hiện Products, Customers, Orders, nội dung, các mối quan hệ và cấu trúc hỗ trợ như thế nào.

Dữ liệu nguồn hữu ích cho quá trình xem xét có thể gồm:

• mô tả schema hoặc dữ liệu xuất;
• các bản ghi Products, Customers, Orders và nội dung có tính đại diện;
• khóa chính và khóa ngoại;
• mối quan hệ giữa Categories và cấu trúc điều hướng;
• các giá trị trạng thái hoặc loại bản ghi tùy chỉnh;
• tham chiếu đến hình ảnh, tệp và nội dung đa phương tiện;
• thông tin về những hệ thống bên ngoài;
• mô tả cụ thể những kết quả kinh doanh cần tiếp tục sau khi chuyển đổi.

Tiếp theo, quá trình xem xét cần đối chiếu ý nghĩa của dữ liệu nguồn với những gì Nền tảng đích hỗ trợ. Một số bản ghi có thể có cấu trúc tương đương trực tiếp. Những bản ghi khác có thể cần biến đổi giá trị, xác định trường đích tương ứng, sử dụng cấu trúc đích tùy chỉnh hoặc bị loại khỏi phạm vi cùng với một phương án thay thế đã được ghi nhận.

Custom Service không thể khiến mọi cách thể hiện trên hệ thống đích đều trở thành khả thi. Dịch vụ này tạo ra một quy trình có kiểm soát để xác định dữ liệu nào có thể di chuyển, phần nào phải thay đổi và khách hàng nên kỳ vọng kết quả ra sao.

Xem dữ liệu của bên thứ ba như một vấn đề về quyền quản lý

Cửa hàng thường phụ thuộc vào dữ liệu do ứng dụng, plugin, module, extension hoặc dịch vụ kết nối tạo ra. Việc một bảng hoặc trường dữ liệu tồn tại không chứng minh rằng dữ liệu đó cần được di chuyển. Một số bản ghi là nguồn dữ liệu chính thức. Số khác chỉ là bộ nhớ đệm, nhật ký, giá trị được tính toán từ dữ liệu khác hoặc phần còn sót lại của chức năng đã ngừng sử dụng.

Quá trình xem xét tùy chỉnh cần xác định:

1. hệ thống nào chịu trách nhiệm quản lý dữ liệu;
2. quy trình kinh doanh nào sử dụng dữ liệu đó;
3. dữ liệu có còn là nguồn thông tin chính thức được quy trình nghiệp vụ sử dụng làm căn cứ hay không;
4. dữ liệu thuộc về bản ghi được di chuyển nào;
5. Cửa hàng đích hoặc hệ thống kết nối cần làm gì với dữ liệu;
6. kết quả sẽ được xác thực bằng cách nào.

Đánh giá theo hệ thống chịu trách nhiệm quản lý và quy trình tiếp tục sử dụng dữ liệu có giá trị hơn việc sao chép mọi trường phi tiêu chuẩn. Dữ liệu không còn hệ thống hoặc quy trình sử dụng về sau có thể tạo ra thông tin thừa hay xung đột. Ngược lại, dữ liệu giữ vai trò vận hành liên tục có thể đặc biệt quan trọng dù chỉ nằm trong một trường.

Những trường hợp thường gặp gồm:

• mã định danh gói đăng ký liên kết với Products hoặc Customers;
• số dư điểm thưởng gắn với danh tính trong bản ghi Customers;
• quyền sở hữu của người bán trên marketplace liên kết với Products và Orders;
• mã tham chiếu phục vụ xử lý đơn hàng gắn với các dòng trong Orders;
• mã định danh PIM liên kết với bản ghi Products;
• nhóm phân loại báo cáo gắn với Products, Customers hoặc Orders.

Duy trì mã định danh bên ngoài và các mối liên kết cần thiết

Mã định danh bên ngoài chỉ có giá trị khi mối quan hệ liên quan vẫn được duy trì. Việc sao chép mã định danh Products trong ERP vào một trường văn bản bất kỳ có thể giữ nguyên chuỗi ký tự nhưng làm hỏng quy trình đang phụ thuộc vào mã đó.

Phạm vi tùy chỉnh cần xác định:

• hệ thống chịu trách nhiệm quản lý mã định danh;
• bản ghi được di chuyển mà mã định danh tham chiếu đến;
• yêu cầu về tính duy nhất và định dạng;
• giá trị có thể thay đổi hay không;
• trường đích tương thích sẽ nhận dữ liệu;
• quy trình tích hợp hoặc báo cáo sẽ sử dụng giá trị đó;
• thông tin cần kiểm tra để xác nhận mối quan hệ.

Chẳng hạn, duy trì mã tham chiếu Orders có thể đòi hỏi nhiều hơn việc di chuyển giá trị ở phần thông tin chung. Bộ phận chăm sóc khách hàng, xử lý đơn hàng hoặc kế toán có thể cần mã tham chiếu được liên kết đúng với bản ghi Orders, các mặt hàng đã mua và thông tin giao dịch liên quan.

Việc triển khai tích hợp vẫn là phần riêng, trừ khi được ghi rõ trong phạm vi đã thống nhất. Custom Service có thể duy trì dữ liệu và mối quan hệ cần được xử lý trong quá trình di chuyển theo phạm vi được chấp nhận. Dịch vụ không tự động xây dựng hoặc vận hành mọi hệ thống sẽ sử dụng dữ liệu đó về sau.

Mô tả phép biến đổi riêng theo giá trị kinh doanh cần duy trì

Cần xem xét cách xử lý dữ liệu riêng khi các chức năng tiêu chuẩn hiện có không tạo ra được kết quả mong muốn. Các trường hợp phổ biến gồm:

• kết hợp nhiều trường nguồn vào một trường đích;
• tách một giá trị nguồn sang nhiều trường đích;
• chuẩn hóa các giá trị thiếu nhất quán;
• chuyển trạng thái nguồn sang trạng thái phù hợp trên hệ thống đích;
• tái cấu trúc bản ghi do ứng dụng quản lý;
• duy trì mối quan hệ phi tiêu chuẩn;
• đối chiếu bản ghi bằng mã định danh riêng của dự án;
• áp dụng quy tắc không có trong Standard Add-ons.

Phép biến đổi cần được mô tả thành quy tắc, kèm các trường hợp minh họa và ngoại lệ.

Yêu cầu chưa đủ rõ:

Sửa các trạng thái Orders.

Yêu cầu rõ ràng hơn:

Chuyển từng giá trị trạng thái Orders đã được phê duyệt từ hệ thống nguồn sang trạng thái đích tương ứng, giữ lại giá trị trạng thái nguồn ban đầu để phục vụ kiểm tra khi đã thống nhất và xác thực trên các bản ghi Orders đã hoàn tất, đã hủy, đã hoàn tiền và đã được xử lý một phần.

Yêu cầu rõ ràng hơn cho biết điều kiện nguồn, kết quả đích và cách chứng minh. Nhờ đó, công việc có thể được xác định phạm vi, báo giá, triển khai và nghiệm thu.

Nhận biết khi nào yêu cầu Add-on đã trở thành tùy chỉnh

Standard Add-ons giải quyết những yêu cầu có phạm vi hỗ trợ rõ ràng:

• Data Filter chọn bản ghi cần di chuyển bằng điều kiện theo trường cho từng loại dữ liệu;
• Advanced Data Mapping chuyển trường nguồn được hỗ trợ sang trường đích tương thích;
• Advanced Database Mapping liên kết các trường được hỗ trợ và cột cơ sở dữ liệu bên dưới với trường hoặc cột đích tương thích, nhưng chỉ khi cả Nền tảng nguồn và Nền tảng đích đều là Open Source;
• Data Transformation biến đổi các giá trị đã chọn ở trường đích trong quá trình di chuyển dữ liệu.

Custom Service trở nên cần thiết khi:

• Standard Add-on phải thay đổi cách hoạt động và trở thành Tailored Add-on;
• không Standard Add-on nào phù hợp nên cần Custom Add-on;
• bản ghi hoặc mối quan hệ làm cơ sở cho yêu cầu chưa được hỗ trợ;
• yêu cầu cần cách xử lý riêng vượt quá chức năng hiện có của Add-on.

Add-on vẫn có thể nằm trong một dự án Custom Service. Add-on giải quyết một chức năng xử lý có phạm vi cụ thể, còn Custom Service xác định kết quả phi tiêu chuẩn rộng hơn.

Dùng kết quả kiểm tra thực tế để xác định yêu cầu Custom Service

Yêu cầu Custom Service cần cung cấp đủ thông tin để đánh giá tính khả thi và xác định cách nghiệm thu kết quả.

Mẫu và dữ liệu dùng để đánh giá phải bao gồm cả trường hợp khó, không chỉ các bản ghi đơn giản, không có ngoại lệ. Một quy tắc tùy chỉnh hoạt động tốt với Products thông thường vẫn có thể thất bại khi bản ghi thiếu mã định danh, có giá trị trùng lặp hoặc chứa mối quan hệ bất thường.

Phạm vi được chấp nhận cần nêu rõ dữ liệu nào sẽ được trích xuất, biến đổi, liên kết hoặc bàn giao. Phạm vi cũng phải xác định phần bị loại trừ, những nội dung phụ thuộc vào chức năng mà Nền tảng đích hỗ trợ và trách nhiệm triển khai nào vẫn được thực hiện riêng.

Tách công việc di chuyển dữ liệu khỏi triển khai trên hệ thống đích

Custom Service có thể xác định cách xử lý di chuyển dữ liệu riêng. Dịch vụ không tự động bao gồm:

• thiết kế theme hoặc storefront;
• cài đặt ứng dụng hoặc extension;
• phát triển và triển khai tích hợp;
• thiết lập thanh toán, vận chuyển, thuế hoặc email;
• xây dựng lại toàn bộ quy trình làm việc;
• cấu hình vận hành;
• mọi cách hoạt động của hệ thống nguồn mà Nền tảng đích không thể hỗ trợ.

Sự phân tách này không chỉ liên quan đến điều khoản phạm vi mà còn giúp duy trì tính chính xác của quyết định chuyển đổi. Một bản ghi có thể được di chuyển đúng nhưng quy trình trên hệ thống đích dùng bản ghi đó vẫn chưa được triển khai. Ngược lại, một ứng dụng đích có thể đã được cài đặt nhưng dữ liệu mà ứng dụng cần lại chưa được duy trì trong quá trình di chuyển.

Phạm vi cần thể hiện rõ điểm bàn giao. Chẳng hạn, mã định danh bên ngoài có thể được di chuyển vào trường đích đã thống nhất, còn công việc tích hợp riêng sẽ kết nối trường đó với ERP.

Đặt kỳ vọng thực tế về khác biệt giữa các nền tảng

Custom Service không thể buộc hai nền tảng hoạt động giống hệt nhau. Tùy chọn Products, nhóm Customers, trạng thái Orders, cấu trúc nội dung, URL và dữ liệu ứng dụng có thể không có cấu trúc tương đương trực tiếp trên hệ thống đích.

Kết quả khả thi có thể là:

• giữ nguyên trực tiếp;
• biến đổi sang cấu trúc được hệ thống đích hỗ trợ;
• chuyển dữ liệu sang trường đích phù hợp;
• duy trì một phần giá trị kinh doanh;
• xuất dữ liệu để sử dụng riêng;
• loại khỏi phạm vi kèm phương án thay thế đã được ghi nhận.

Kết quả phù hợp phụ thuộc vào mục đích kinh doanh và những gì Nền tảng đích hỗ trợ. Tái tạo chính xác mọi chi tiết không phải lúc nào cũng là mục tiêu tốt nhất. Một cách thể hiện đơn giản hơn trên hệ thống đích có thể phù hợp hơn nếu vẫn duy trì được kết quả cần thiết mà không mang theo quy tắc xử lý của hệ thống nguồn đã lỗi thời.

Phân biệt phạm vi, trách nhiệm thực hiện và giá

Custom Service xác định công việc cần xử lý riêng. Expert Handle xác định chuyên gia có phụ trách thực hiện các công việc di chuyển dữ liệu đã thống nhất hay không.

Vì vậy, dự án Custom Service có thể:

• do khách hàng chủ động thực hiện, trong đó phạm vi bao gồm công việc tùy chỉnh nhưng khách hàng vẫn trực tiếp thực hiện các công việc di chuyển dữ liệu; hoặc
• do chuyên gia phụ trách thực hiện, với Expert Handle nằm trong phạm vi được chấp nhận.

Mức giá Custom Service hiển thị bắt đầu từ giá Standard Service của Entity Points Plan đã chọn. Mức này xác lập phần chi phí nền tương ứng với dung lượng. Tổng giá cuối cùng sẽ cộng thêm báo giá cho công việc tùy chỉnh đã thống nhất, Add-ons đã mua nếu có, Expert Handle khi được bao gồm và các chi phí khác thuộc phạm vi đã chấp nhận.

Khi công việc tùy chỉnh được bổ sung vào Dịch vụ chuyển đổi dữ liệu đã mua, báo giá được chấp nhận sẽ làm thay đổi tổng giá trị của dịch vụ. Số tiền đã thanh toán trước đó vẫn được ghi nhận và khách hàng chỉ thanh toán phần chênh lệch cần bổ sung. Nguyên tắc tương tự áp dụng cho Tailored Add-ons và Custom Add-ons.

Chưa thể xác định tổng giá cuối cùng một cách có trách nhiệm khi kết quả phi tiêu chuẩn chưa được mô tả đủ rõ để xác định phạm vi. Việc chấp nhận và mua hạng mục nâng cấp theo báo giá sẽ tích hợp công việc vào cùng Dịch vụ chuyển đổi dữ liệu. Giao dịch này không tạo lộ trình mới hoặc kéo dài thời hạn dịch vụ một năm.

Xác thực kết quả đã được xử lý riêng

Công việc tùy chỉnh cần cơ sở nghiệm thu riêng, phù hợp với chính yêu cầu đó. Việc chỉ so sánh tổng số bản ghi không đủ khi kết quả phụ thuộc vào ý nghĩa, phép biến đổi hoặc mối quan hệ.

Quá trình xác thực cần đối chiếu:

• bản ghi mẫu từ nguồn;
• quy tắc biến đổi hoặc xử lý đã thống nhất;
• cách thể hiện dữ liệu tại Cửa hàng đích;
• bản ghi liên quan hoặc mã định danh bên ngoài;
• hành vi kinh doanh dự kiến;
• cách xử lý ngoại lệ;
• quyết định Đạt, Cần theo dõi hoặc Chặn.

Khách hàng vẫn chịu trách nhiệm xác thực cuối cùng. Điều này đặc biệt quan trọng đối với công việc tùy chỉnh vì tiêu chuẩn chấp nhận thường phụ thuộc vào kiến thức kinh doanh không thể suy ra chỉ từ schema nguồn.

Quyết định Cần theo dõi phải xác định vấn đề vẫn chưa được làm rõ, hệ quả kinh doanh, nội dung còn cần kiểm chứng và người chịu trách nhiệm giải quyết. Nếu thiếu phần diễn giải này, quá trình xác thực tùy chỉnh chỉ dừng ở việc liệt kê các quan sát, không tạo ra được quyết định nghiệm thu có cơ sở.

Kết luận

Next-Cart Custom Service xử lý những phần của quá trình chuyển đổi cần diễn giải riêng, quy tắc xử lý được thiết kế theo dự án, Add-ons phải điều chỉnh, phân tích Custom Platform, mối quan hệ phi tiêu chuẩn hoặc cách thể hiện dữ liệu trên hệ thống đích cần được xác định riêng.

Một yêu cầu tùy chỉnh được xác định tốt phải bắt đầu từ ý nghĩa kinh doanh cần duy trì và cách kiểm tra kết quả. Phạm vi đó xác định bên quản lý dữ liệu, mục đích kinh doanh cần được duy trì, cách Cửa hàng đích cần thể hiện kết quả, công việc di chuyển dữ liệu phải thực hiện, phần triển khai còn tách biệt và cách chứng minh kết quả đạt yêu cầu.

Custom Service không phải lời hứa tái tạo mọi cách hệ thống hoạt động nguồn. Đây là cách có kiểm soát để đạt kết quả khả thi gần nhất và có thể kiểm thử khi cách xử lý được hỗ trợ cùng Standard Add-ons chưa đáp ứng đủ.

Câu hỏi thường gặp

Custom Service có chỉ dành cho Custom Platform không?

Custom Service không chỉ dành cho Custom Platform. Dịch vụ còn áp dụng cho các trường tùy chỉnh, dữ liệu của bên thứ ba, mã định danh bên ngoài, cách xử lý riêng, Tailored Add-ons, Custom Add-ons và các yêu cầu phi tiêu chuẩn khác.

Mọi trường tùy chỉnh đều cần Custom Service không?

Không phải trường tùy chỉnh nào cũng cần Custom Service. Quyết định phụ thuộc vào trường dữ liệu có được hỗ trợ hay không, ý nghĩa kinh doanh của trường, vị trí cần thể hiện trên hệ thống đích và cách liên kết trường hiện có đã đáp ứng đủ hay chưa.

Custom Service khác Standard Add-on như thế nào?

Standard Add-on giải quyết nhu cầu lọc bản ghi, biến đổi giá trị hoặc chuyển trường dữ liệu trong phạm vi hỗ trợ rõ ràng. Custom Service dành cho yêu cầu đã điều chỉnh, chưa được hỗ trợ hoặc cần cách xử lý riêng và phải xác định phạm vi theo từng dự án.

Custom Service có luôn bao gồm Expert Handle không?

Custom Service không phải lúc nào cũng bao gồm Expert Handle. Dự án có thể do khách hàng chủ động thực hiện. Expert Handle chỉ được bao gồm khi phần thực hiện do chuyên gia phụ trách nằm trong phạm vi tùy chỉnh đã chấp nhận.

Custom Service có thể tái tạo chính xác mọi cách hệ thống hoạt động nguồn không?

Custom Service không thể tái tạo chính xác mọi cách hệ thống hoạt động nguồn. Kết quả phụ thuộc vào tình trạng dữ liệu nguồn, những gì Nền tảng đích hỗ trợ, phạm vi được chấp nhận và kết quả khách hàng cần kiểm tra trước khi phê duyệt.

Yêu cầu Custom Service cần cung cấp những thông tin và mẫu nào?

Cần có bản ghi đại diện, bên quản lý dữ liệu và mục đích kinh doanh, cách thể hiện mong muốn trên hệ thống đích, quy tắc biến đổi hoặc mối quan hệ, các ngoại lệ, hệ thống liên quan và những trường hợp dùng để xác thực.

Công việc triển khai trên Nền tảng đích có tự động được bao gồm không?

Công việc triển khai trên Nền tảng đích không tự động được bao gồm. Thiết kế, cài đặt ứng dụng, triển khai tích hợp và cấu hình vận hành vẫn là các hạng mục riêng, trừ khi được ghi rõ trong phạm vi đã chấp nhận.

Vì sao mức giá Custom Service chỉ là giá khởi điểm?

Mức giá này xác lập phần chi phí Standard Service tương ứng với dung lượng của Entity Points Plan đã chọn. Tổng giá cuối cùng phụ thuộc vào công việc tùy chỉnh đã thống nhất, Add-ons, Expert Handle khi được bao gồm và các chi phí khác thuộc phạm vi đã chấp nhận. Đối với công việc được bổ sung về sau, số tiền đã thanh toán vẫn được ghi nhận và khách hàng chỉ thanh toán phần chênh lệch.