Phạm vi công việc của dự án chuyển đổi thường được xác định quá muộn và quá sơ lược. Nhiều đội ngũ bắt đầu từ danh sách dữ liệu xuất ra, tổng số bản ghi theo từng loại dữ liệu hoặc giả định rằng mọi dữ liệu đều nên được di chuyển. Cách làm này có vẻ thận trọng nhưng thường né tránh câu hỏi lập kế hoạch quan trọng hơn: doanh nghiệp phải tiếp tục làm được những gì sau khi chuyển đổi?
Cửa hàng không chỉ phụ thuộc vào việc các bản ghi có tồn tại hay không. Products phải tiếp tục sử dụng được trong hoạt động thương mại, đường dẫn duyệt Products phải dễ hiểu, lịch sử Customers và Orders vẫn phải hỗ trợ vận hành, còn những trang quan trọng đối với hoạt động kinh doanh phải tiếp tục phục vụ đúng mục đích. Nếu phạm vi công việc chỉ được xác định bằng số lượng bản ghi, những mất mát quan trọng có thể chỉ được phát hiện khi dự án đã bước vào giai đoạn rà soát cuối.
Cách xác định phạm vi hiệu quả hơn phải bắt đầu từ những gì cửa hàng cần tiếp tục làm được sau khi chuyển đổi. Từ đó, doanh nghiệp mới có thể quyết định dữ liệu, cấu trúc và chức năng nào thuộc trách nhiệm của dự án, thay đổi nào có thể chấp nhận và nội dung nào cần được rà soát kỹ trước khi triển khai.
Xác định rõ dự án phải xử lý và chịu trách nhiệm đến đâu
Phạm vi dự án phải cho biết đội ngũ cần xử lý những gì, được phép thay đổi điều gì, nội dung nào có thể loại trừ và trường hợp nào cần rà soát riêng. Ranh giới này rộng hơn một danh sách loại bản ghi, vì dữ liệu chỉ có giá trị khi các mối quan hệ, chức năng và ngữ cảnh kinh doanh đi kèm vẫn sử dụng được.
Để có thể triển khai, phạm vi công việc cần làm rõ:
- những kết quả kinh doanh nào phải tiếp tục được duy trì sau khi chính thức vận hành;
- những loại dữ liệu, loại nội dung và cấu trúc hỗ trợ nào được đưa vào;
- những bản ghi hoặc khoảng lịch sử nào có thể được chủ động loại trừ;
- những khác biệt giữa các nền tảng nào có thể chấp nhận nếu ý nghĩa kinh doanh vẫn được duy trì;
- những nội dung nào cần rà soát mẫu trước khi phương án chuyển đổi được xem là đủ an toàn;
- ai cần xác nhận kết quả có chấp nhận được hay không.
Cách xác định này biến phạm vi công việc thành một công cụ quản trị. Dự án có cơ sở để quyết định những gì phải được di chuyển, những gì có thể thay đổi, những gì có thể được làm sạch và những gì không nên được xem là yêu cầu bắt buộc trước khi chính thức vận hành.
Bắt đầu từ những kết quả doanh nghiệp cần tiếp tục đạt được
Phạm vi dự án nên được xây dựng từ kết quả kinh doanh thay vì bắt đầu bằng các nhóm dữ liệu có thể xuất ra. Khả năng chuyển Products, Customers, Orders, Categories hoặc nội dung chỉ là bước đầu. Phạm vi phải bảo đảm cửa hàng sau chuyển đổi tiếp tục hỗ trợ đúng những hoạt động doanh nghiệp phụ thuộc.
Các kết quả thường cần được duy trì gồm:
| Nhóm kết quả | Những gì dự án phải duy trì | Nội dung nên ưu tiên rà soát |
|---|---|---|
| Quá trình khách hàng mua Products | Customers có thể chọn và mua đúng Products | Variants, tùy chọn, mức giá, cách thể hiện thông tin tồn kho, hình ảnh, trạng thái Products |
| Khả năng tìm thấy Products trong catalog | Customers có thể tìm Products qua các đường dẫn duyệt quen thuộc | Categories, collections, bộ lọc, trường tìm kiếm, landing pages |
| Khả năng tiếp tục sử dụng dữ liệu Customers | Nhân viên có thể hiểu thông tin Customers sau khi chính thức vận hành | Tài khoản, địa chỉ, tham chiếu Orders, trạng thái đồng ý, mức độ phù hợp của phân khúc |
| Khả năng vận hành | Đội ngũ nội bộ có thể tiếp tục các quy trình quan trọng | Lịch sử đơn hàng, tham chiếu xử lý đơn hàng, ghi chú hỗ trợ, mã định danh bên ngoài |
| Duy trì hoạt động thương mại | Các quy tắc ảnh hưởng trực tiếp đến doanh thu được xác định và xử lý rõ trong phạm vi | Khuyến mãi, Coupons, quy tắc giá, ngữ cảnh Taxes, nhóm Customers ưu tiên |
| Duy trì SEO | Các trang quan trọng vẫn truy cập được và phục vụ đúng mục đích | URL, chuyển hướng, metadata, trang nội dung, đường dẫn landing có giá trị cao |
Bắt đầu từ kết quả giúp phạm vi công việc không trở nên quá rộng hoặc quá sơ lược. Doanh nghiệp có thể phân dữ liệu thành ba nhóm: thiết yếu; hữu ích nhưng không quyết định khả năng vận hành; và dữ liệu lịch sử hoặc lỗi thời có thể loại khỏi phạm vi mà không ảnh hưởng đến mức độ sẵn sàng.
Xác định các loại dữ liệu chính và cấu trúc hỗ trợ
Phạm vi dữ liệu và chức năng cần xử lý thường bắt đầu từ các loại dữ liệu chính nhưng không nên dừng ở đó. Bản ghi cốt lõi thường chỉ giữ được giá trị khi các cấu trúc hỗ trợ được di chuyển cùng với đầy đủ thông tin và mối liên hệ cần thiết.
Các nhóm cốt lõi thường gồm:
- Products;
- Customers;
- Orders;
- Categories hoặc collections;
- Reviews;
- Coupons và chương trình khuyến mãi;
- Taxes và các tham chiếu cấu hình liên quan;
- CMS Pages;
- Blog Posts có vai trò quan trọng đối với traffic, việc thúc đẩy khách hàng thực hiện hành động mong muốn hoặc khả năng tiếp tục sử dụng nội dung.
Các cấu trúc hỗ trợ sau cũng thường cần được đưa vào phạm vi công việc:
- variants và tùy chọn Products;
- hình ảnh Products và variants;
- thuộc tính Products được dùng cho bộ lọc, so sánh hoặc merchandising;
- địa chỉ Customers và trạng thái tài khoản;
- quan hệ giữa Products, bundles, grouped items hoặc quy tắc cross-sell;
- quy tắc gán Products vào Categories và đường dẫn duyệt Products;
- quy tắc đủ điều kiện áp dụng khuyến mãi và điều kiện Coupons;
- URL, metadata, chuyển hướng và đường dẫn landing quan trọng đối với SEO;
- metadata vận hành cần cho báo cáo, hỗ trợ, xử lý đơn hàng hoặc hệ thống bên ngoài;
- các trường do app, plugin, module hoặc extension quản lý và có ảnh hưởng đến chức năng trên giao diện cửa hàng hoặc phần quản trị.
Một cửa hàng nhỏ vẫn có thể đòi hỏi phạm vi công việc rộng nếu hoạt động thương mại phụ thuộc vào nhiều lớp cấu trúc. Một cửa hàng lớn có thể có phạm vi công việc hẹp hơn khi doanh nghiệp chủ động loại trừ dữ liệu lịch sử không còn sử dụng và xác định rõ những gì phải tiếp tục dùng được.
Phân loại dữ liệu và yêu cầu theo cách cần xử lý
Phạm vi dự án dễ quản lý hơn khi mỗi nhóm dữ liệu hoặc yêu cầu được xác định rõ cách xử lý. Có nội dung phải giữ nguyên kết quả kinh doanh, có nội dung được phép thay đổi cấu trúc, có dữ liệu nên làm sạch, và cũng có phần có thể chủ động loại trừ hoặc cần rà soát riêng.
| Cách xử lý trong phạm vi dự án | Ý nghĩa | Trường hợp minh họa |
|---|---|---|
| Phải duy trì | Kết quả kinh doanh không thể thay đổi mà không tạo rủi ro | Products bán chạy phải giữ được quy tắc mua hàng và cách được ghi nhận trong Orders |
| Có thể biến đổi | Cấu trúc có thể thay đổi nếu ý nghĩa kinh doanh vẫn ở mức chấp nhận được | Cây Categories có thể trở thành collections hoặc nhóm điều hướng trên Nền tảng đích |
| Có thể làm sạch | Dữ liệu nên được sửa hoặc hợp nhất trước hoặc trong quá trình lập kế hoạch | Các giá trị thuộc tính trùng lặp có thể được chuẩn hóa trước khi ảnh hưởng đến việc rà soát bộ lọc |
| Có thể loại trừ | Dữ liệu không cần cho việc chính thức vận hành hoặc hoạt động về sau | Products lỗi thời, chiến dịch đã hết hạn, Customers thử nghiệm cũ, bản nháp nội dung không dùng |
| Cần rà soát riêng | Yêu cầu có thể vượt ngoài cách xử lý thông thường giữa các nền tảng | các trường tùy chỉnh, mã định danh của hệ thống bên ngoài, dữ liệu do extension quản lý, quy tắc hoặc cách xử lý bất thường |
Cách phân loại này giúp đội ngũ không xem mọi khác biệt là lỗi. Một số thay đổi vẫn giữ đúng mục đích kinh doanh, một số giúp dữ liệu dễ sử dụng hơn, còn một số có thể làm gián đoạn vận hành. Những khác biệt đó phải được thống nhất trước khi bắt đầu rà soát kết quả.
Xác định những chức năng phải tiếp tục hoạt động đúng mục đích
Ưu tiên cao nhất là những dữ liệu và chức năng mà doanh nghiệp không thể để mất sau khi chuyển đổi. Cấu trúc trên Nền tảng đích có thể khác, nhưng cửa hàng vẫn phải hỗ trợ đúng mục đích kinh doanh và quy trình sử dụng mà doanh nghiệp phụ thuộc.
Những chức năng thường thuộc nhóm này gồm:
- Products bán chạy vẫn giữ được cách khách hàng mua Products trong thực tế;
- mối quan hệ giữa Customers và Orders cần thiết cho hoạt động hỗ trợ;
- cấu trúc Categories hoặc collections định hướng cách Customers duyệt Products;
- chương trình khuyến mãi và quy tắc giá ảnh hưởng trực tiếp đến doanh thu;
- nhóm hoặc phân khúc Customers ảnh hưởng đến giá, quyền truy cập, thông tin liên lạc hoặc quy trình dịch vụ;
- các trang có giá trị cao mang lại traffic đáng kể, thúc đẩy khách hàng thực hiện hành động mong muốn hoặc củng cố uy tín thương hiệu.
Những nội dung này phải quyết định cách chọn mẫu và thứ tự ưu tiên xác thực. Không nên chờ đến khi toàn bộ dữ liệu đã được di chuyển mới kiểm tra. Nếu Nền tảng đích buộc một chức năng quan trọng phải vận hành theo cách khác, đội ngũ cần sớm xác định cách thể hiện mới có chấp nhận được hay không, cần điều chỉnh dữ liệu hay phải thay đổi phạm vi dự án.
Xác định nội dung có thể được thể hiện khác trên Nền tảng đích
Một số nội dung vẫn phải phục vụ đúng mục đích dù Nền tảng đích tổ chức hoặc hiển thị chúng theo cách khác. Không phải lúc nào cũng có một cấu trúc mới tương ứng trực tiếp, nhất là khi hai nền tảng sử dụng mô hình catalog, Customers, nội dung hoặc khuyến mãi khác nhau.
Những cách thể hiện khác thường gặp gồm:
- quy tắc tổ chức Categories được thể hiện bằng collections, menu, tags hoặc landing pages;
- nhóm Customers được thể hiện bằng phân khúc, tags, danh sách hoặc quy tắc;
- thuộc tính Products được thể hiện bằng trường, metafields, thông số kỹ thuật, giá trị tùy chọn hoặc nguồn dữ liệu cho bộ lọc;
- nội dung CMS được thể hiện bằng page builder, theme hoặc mô hình block khác;
- quy tắc khuyến mãi được thể hiện bằng hệ thống quy tắc hoặc mô hình giảm giá khác.
Những thay đổi này không tự động là lỗi. Điều cần đánh giá là cách thể hiện mới có tiếp tục hỗ trợ đúng mục đích kinh doanh hay không. Nếu Customers vẫn tìm, đánh giá và mua Products đúng cách, khác biệt về cấu trúc có thể chấp nhận. Nếu thay đổi làm sai giá, điều kiện áp dụng, khả năng tìm Products, việc sử dụng dữ liệu trong hỗ trợ hoặc ý nghĩa báo cáo, nội dung đó cần được rà soát kỹ hơn và có quyết định rõ ràng.
Nhận diện dữ liệu chỉ có giá trị khi các mối quan hệ được giữ đúng
Nhiều vấn đề không xuất phát từ việc thiếu bản ghi mà từ việc các bản ghi không còn liên kết đúng với nhau. Products, Customers, Orders, Reviews, Coupons và nội dung chỉ tiếp tục sử dụng được khi những mối quan hệ quan trọng vẫn chính xác.
Những mối quan hệ cần đặc biệt lưu ý gồm:
- Orders cần liên kết đúng với Customers và Products;
- Reviews cần liên kết đúng với Products, Customers, trạng thái đánh giá và trạng thái kiểm duyệt;
- Coupons cần giữ đúng điều kiện về Products, Categories, Customers hoặc ngày áp dụng;
- Products cần giữ đầy đủ thông tin liên quan về Categories, Manufacturers, Taxes, tồn kho và media;
- bản ghi Customers cần địa chỉ, lịch sử đơn hàng, trạng thái đồng ý hoặc trạng thái tài khoản để tiếp tục dễ hiểu;
- trang nội dung cần URL, chuyển hướng, hình ảnh, metadata và ngữ cảnh điều hướng để tiếp tục hữu ích.
Kế hoạch xác định phạm vi không cần mô tả mọi mối quan hệ ở mức kỹ thuật chi tiết. Nội dung đó thuộc phần phân tích sâu hơn về cấu trúc và mối quan hệ giữa các loại dữ liệu. Tuy nhiên, kế hoạch phải xác định những trường hợp bản ghi chỉ còn sử dụng được khi duy trì đúng mối liên hệ với các bản ghi khác. Nếu không, dự án có thể giữ đúng số lượng bản ghi nhưng làm mất ngữ cảnh cần thiết để sử dụng chúng.
Đưa dữ liệu và quy tắc do hệ thống bên ngoài quản lý vào kế hoạch từ đầu
Phạm vi thường bị đánh giá thấp vì đội ngũ chỉ kiểm kê nội dung hiển thị trên giao diện cửa hàng mà bỏ qua các trường, quy tắc, mã định danh và dữ liệu do extension quản lý ở phía sau.
Lớp dữ liệu và quy tắc ẩn này có thể gồm:
- các trường tùy chỉnh của Products được dùng cho hiển thị, bộ lọc, merchandising hoặc báo cáo;
- chương trình khách hàng thân thiết, Reviews, đăng ký định kỳ, tìm kiếm hoặc cá nhân hóa do app, plugin, module hoặc extension quản lý;
- metadata Orders cần cho hỗ trợ, hoàn tiền, xử lý đơn hàng hoặc báo cáo;
- mã định danh cần cho ERP, CRM, vận chuyển, Taxes, marketing automation hoặc marketplace;
- quy tắc tùy chỉnh đối với collections, landing pages hoặc cách duyệt Products;
- quy tắc kinh doanh nằm ngoài nền tảng nhưng ảnh hưởng đến hoạt động của cửa hàng.
Nếu những yếu tố này ảnh hưởng đáng kể đến doanh thu, khả năng tìm Products, vận hành hoặc khả năng tiếp tục sử dụng dữ liệu Customers, chúng phải xuất hiện sớm trong quá trình xác định phạm vi. Không nên để chúng chỉ được phát hiện trong lần xác thực cuối.
Các quy tắc và cách xử lý tùy chỉnh quan trọng cũng cần được phân loại theo giá trị kinh doanh. Một số trường chỉ có ý nghĩa lịch sử. Một số hữu ích cho quản trị. Một số khác thiết yếu đối với trải nghiệm khách hàng, giá, xử lý đơn hàng hoặc khả năng tiếp tục hoạt động của hệ thống bên ngoài. Chỉ những phần thiết yếu và có ý nghĩa vận hành mới nên làm tăng phạm vi công việc.
Chủ động lựa chọn dữ liệu thực sự cần di chuyển
Chỉ di chuyển dữ liệu cần thiết có thể là một quyết định lập kế hoạch hiệu quả. Nhiều doanh nghiệp không cần toàn bộ bản ghi lịch sử để sẵn sàng chính thức vận hành.
Phạm vi chọn lọc có thể ưu tiên:
- Products đang hoạt động và cấu trúc catalog hiện hành;
- Customers đang hoạt động;
- Orders gần đây cần cho hỗ trợ hoặc tham chiếu kế toán;
- CMS Pages và Blog Posts có giá trị cao;
- Categories, collections, URL và landing pages ưu tiên;
- bản ghi cần cho hệ thống bên ngoài hoặc quy trình sau khi chính thức vận hành.
Tuy nhiên, phạm vi chọn lọc không tự động trở nên đơn giản. Độ phức tạp tăng khi quy tắc lựa chọn quá cụ thể, phụ thuộc vào mối quan hệ hoặc có khả năng làm thay đổi ý nghĩa của các bản ghi liên quan. Chẳng hạn, di chuyển Orders gần đây mà không có Customers, Products, Coupons hoặc tham chiếu xử lý đơn hàng liên quan có thể khiến lịch sử đơn hàng thiếu ngữ cảnh cần thiết cho hỗ trợ khách hàng, kế toán và rà soát xử lý đơn hàng.
Vì vậy, phạm vi dữ liệu được lựa chọn cần dựa trên kết quả kinh doanh, không chỉ trên mục tiêu giảm số lượng.
Xác định quy tắc chọn và loại dữ liệu trước khi triển khai
Quyết định lọc dữ liệu cần được xác định trước khi triển khai. Số lượng bản ghi ước tính theo từng loại dữ liệu giúp lập kế hoạch và ước tính khả năng xử lý dữ liệu cần thiết, nhưng không tự động xác định bản ghi nào nên được di chuyển.
Một quyết định lọc cần làm rõ:
- những bản ghi nào được đưa vào;
- những bản ghi nào bị loại trừ;
- vì sao quy tắc lựa chọn hỗ trợ mục tiêu kinh doanh;
- quy tắc có ảnh hưởng đến dữ liệu liên kết hay không;
- có thể xác thực lựa chọn sau khi di chuyển hay không;
- ai chấp nhận hệ quả của phần lịch sử bị loại trừ.
Một số yêu cầu lọc tương đối đơn giản, chẳng hạn loại trừ Products không còn hoạt động hoặc chỉ di chuyển Orders sau một ngày cụ thể. Yêu cầu khác phức tạp hơn, đặc biệt khi phụ thuộc vào nhiều điều kiện, các trường tùy chỉnh, giá trị trạng thái của bên thứ ba, mã định danh bên ngoài hoặc quy tắc về mối quan hệ. Khi nhu cầu lọc vượt ngoài các quy tắc lựa chọn thông thường, yêu cầu có thể cần được rà soát theo hướng lọc bản ghi có chọn lọc hoặc thiết kế phương án chuyển đổi tùy chỉnh.
Tách khối lượng dữ liệu cần di chuyển khỏi các yếu tố ảnh hưởng đến chi phí
Những gì dự án phải xử lý có thể ảnh hưởng đến chi phí theo nhiều cách khác nhau và không nên được gộp vào một con số ước tính duy nhất. Khối lượng bản ghi ảnh hưởng đến khả năng xử lý dữ liệu cần thiết. Trách nhiệm triển khai ảnh hưởng đến hoạt động phối hợp và khối lượng công việc. Các điều chỉnh có giới hạn về lọc, liên kết trường hoặc cấu hình bổ sung thêm công việc xác định được. Cách xử lý phi tiêu chuẩn áp dụng cho yêu cầu cần tùy chỉnh hoặc thay đổi vượt ngoài cách xử lý thông thường.
| Quyết định về phạm vi công việc | Ảnh hưởng đến chi phí |
|---|---|
| Khối lượng Products, Customers, Orders và Blog Posts được tính | Xác định khả năng xử lý khối lượng dữ liệu cần thiết hoặc nhu cầu bổ sung dung lượng. |
| Khách hàng tự thực hiện hoặc có chuyên gia phụ trách | Làm thay đổi trách nhiệm, hoạt động phối hợp và giả định chi phí của dự án. |
| Lọc, liên kết trường hoặc cấu hình có giới hạn rõ ràng | Bổ sung khối lượng công việc tương ứng khi áp dụng. |
| các trường tùy chỉnh, dữ liệu bên thứ ba, cách xử lý Custom Platform, biến đổi riêng hoặc yêu cầu tùy chỉnh về lọc hay liên kết trường | Có thể cần rà soát thiết kế phương án chuyển đổi tùy chỉnh và thống nhất một phạm vi công việc riêng. |
Sự phân tách này ngăn hai sai lầm đối lập. Một cửa hàng lớn không nên bị phân loại là cần thiết kế phương án tùy chỉnh chỉ vì cần xử lý nhiều dữ liệu hơn. Một cửa hàng nhỏ cũng không nên được xem là có phạm vi công việc đơn giản khi dữ liệu quan trọng đối với hoạt động kinh doanh cần cách xử lý riêng. Trước khi lựa chọn phương án và rà soát chi phí, doanh nghiệp cần ghi rõ khối lượng dữ liệu, trách nhiệm, yêu cầu biến đổi và kết quả dự kiến phải được kiểm tra trong phạm vi công việc.
Thống nhất trước những thay đổi có thể chấp nhận
Kế hoạch về phạm vi công việc không chỉ cần nêu những gì được đưa vào mà còn phải xác định khác biệt nào có thể chấp nhận.
Các thay đổi có thể chấp nhận gồm:
- cách tổ chức nội bộ thay đổi nhưng quy trình vẫn sử dụng được;
- cách đặt tên hoặc nhóm Categories được điều chỉnh mà không làm ảnh hưởng đến mục đích duyệt Products;
- bố cục nội dung có thể thay đổi nếu trang vẫn dễ truy cập, rõ ràng và không làm giảm khả năng khách hàng thực hiện hành động mong muốn;
- vị trí trường theo chuẩn của nền tảng thay thế cách sắp xếp các trường tùy chỉnh trước đây;
- Products đã ngừng hoạt động hoặc nội dung lỗi thời được chủ động loại trừ;
- quy tắc chiến dịch cũ được xây dựng lại thay vì di chuyển nguyên trạng.
Ghi nhận thay đổi có thể chấp nhận giúp quá trình rà soát diễn ra thuận lợi hơn. Người rà soát có thể phân biệt khác biệt dự kiến trên Nền tảng đích với trường hợp dự án không đáp ứng phạm vi công việc đã thống nhất. Nếu không có sự phân biệt này, mọi khác biệt đều có thể trở thành tranh luận ở giai đoạn cuối.
Dùng phạm vi đã thống nhất để ưu tiên nội dung cần rà soát
Phạm vi công việc đã xác định phải tạo cơ sở cho các quyết định lập kế hoạch tiếp theo. Phạm vi này phải giúp doanh nghiệp xác định điều gì làm dự án trở nên phức tạp, phương án nào phù hợp với yêu cầu và quá trình xác thực cần chứng minh điều gì.
Danh sách ưu tiên rà soát hữu ích gồm:
| Mức ưu tiên | Hạng mục thuộc phạm vi | Mục đích rà soát |
|---|---|---|
| Rất quan trọng | Doanh thu, checkout, hỗ trợ, SEO, khả năng tiếp tục hoạt động của hệ thống bên ngoài | Xác nhận không còn vấn đề làm cản trở việc chính thức vận hành |
| Cao | Khả năng tìm Products trong catalog, khả năng tiếp tục sử dụng dữ liệu Customers, nội dung ưu tiên | Xác nhận các quy trình quan trọng vẫn sử dụng được |
| Trung bình | Tiện ích quản trị, tham chiếu lịch sử, cách tổ chức nội bộ | Xác nhận các thay đổi đã được hiểu và có thể chấp nhận |
| Thấp | Dữ liệu lỗi thời, trùng lặp hoặc không còn dùng | Xác nhận việc chủ động loại trừ hoặc làm sạch |
Cách ưu tiên này tránh việc rà soát mọi nội dung với mức độ như nhau, khiến dữ liệu lịch sử ít giá trị tiêu tốn lượng thời gian tương đương với chức năng quan trọng trước khi chính thức vận hành. Tài liệu về phạm vi công việc phải cho người rà soát biết nên dành nhiều thời gian nhất cho đâu và cần mức độ chứng minh nào.
Một bản mô tả phạm vi dự án đầy đủ cần làm rõ điều gì?
Một bản mô tả phạm vi công việc của dự án chuyển đổi cần làm rõ:
- những gì doanh nghiệp không thể để mất sau khi chính thức vận hành;
- những loại dữ liệu và loại nội dung nào được đưa vào;
- những cấu trúc hỗ trợ và mối quan hệ nào cần được xử lý rõ ràng;
- dữ liệu nào có thể được biến đổi, làm sạch, loại trừ hoặc hoãn lại;
- những khác biệt nền tảng nào đã được hiểu và có thể chấp nhận;
- những nội dung nào cần rà soát riêng hoặc xử lý tùy chỉnh;
- bản ghi nào cần được lựa chọn hoặc lọc và vì sao;
- ưu tiên rà soát nào chứng minh dự án đã đáp ứng phạm vi công việc đã thống nhất.
Mức độ rõ ràng này không đòi hỏi tài liệu hoàn hảo. Điều cần thiết là đánh giá có hệ thống về những gì cửa hàng sau chuyển đổi phải tiếp tục làm được.
Kết luận
Phạm vi công việc của dự án chuyển đổi không chỉ trả lời câu hỏi “dữ liệu nào cần được di chuyển?”. Phạm vi này còn phải trả lời “những gì phải tiếp tục hoạt động sau khi chuyển đổi, cấu trúc nào hỗ trợ kết quả đó và thay đổi nào có thể chấp nhận?”. Khi phạm vi công việc được xác định dựa trên các kết quả phải duy trì, cấu trúc hỗ trợ, chức năng phụ thuộc vào mối quan hệ, quy tắc lựa chọn dữ liệu và việc chủ động chấp nhận khác biệt của Nền tảng đích, các bước lập kế hoạch về sau sẽ dễ kiểm soát hơn.
Hãy xác định phạm vi công việc dựa trên những gì doanh nghiệp phải tiếp tục làm được sau khi chính thức vận hành. Sau đó, dùng phạm vi này để quyết định yếu tố nào làm dự án trở nên phức tạp, phương án chuyển đổi nào phù hợp và quá trình xác thực phải chứng minh điều gì trước khi cửa hàng được xem là sẵn sàng.
Câu hỏi thường gặp
Phạm vi công việc của dự án chuyển đổi có phải lúc nào cũng bao gồm mọi dữ liệu không?
Phạm vi công việc của dự án chuyển đổi không phải lúc nào cũng bao gồm mọi dữ liệu. Chỉ di chuyển dữ liệu cần thiết là một lựa chọn hợp lệ nếu doanh nghiệp xác định rõ phạm vi công việc và hiểu ảnh hưởng đối với chức năng của dữ liệu liên kết, khả năng sử dụng trong hỗ trợ, báo cáo, dữ liệu Customers và mục tiêu chính thức vận hành. Phạm vi không cần bao gồm mọi bản ghi. Điều bắt buộc là dữ liệu đã chọn phải tiếp tục hỗ trợ những kết quả mà doanh nghiệp phụ thuộc.
Sai lầm lớn nhất khi xác định phạm vi công việc là gì?
Một trong những sai lầm phổ biến nhất là xác định phạm vi công việc là “mọi thứ” mà không quyết định những gì thực sự cần được duy trì. Điều đó trì hoãn những đánh giá khó hơn về các chức năng không được phép gián đoạn, thay đổi có thể chấp nhận, dữ liệu bị loại trừ, việc làm sạch và thứ tự ưu tiên rà soát.
Products, Customers và Orders có đủ để xác định phạm vi công việc không?
Chỉ Products, Customers và Orders thường không đủ để xác định đầy đủ phạm vi công việc. Cấu trúc hỗ trợ như variants, thuộc tính, cách khách hàng duyệt Products, hình ảnh, chương trình khuyến mãi, URL, metadata vận hành, địa chỉ Customers, tham chiếu Orders và chức năng do app, plugin, module hoặc extension quản lý thường mang ý nghĩa kinh doanh giúp dữ liệu chính tiếp tục phục vụ đúng mục đích.
Khi nào kết quả xác định phạm vi công việc cần được chuyển sang rà soát chuyên sâu?
Cần rà soát chuyên sâu khi bản ghi quan trọng, mối quan hệ, cấu trúc tùy chỉnh, mã định danh bên ngoài hoặc yêu cầu biến đổi không thể được xử lý đầy đủ trong phạm vi công việc thông thường được hỗ trợ. Trước khi xem xét các phương án, cần ghi nhận ý nghĩa kinh doanh, kết quả dự kiến, mẫu đại diện và công việc còn phải thực hiện trên Nền tảng đích.