Thay thế hệ thống doanh nghiệp: Khi nào nên vận hành song song hai hệ thống?

Duy trì hệ thống doanh nghiệp cũ trong thời gian thay thế có thể giúp so sánh kết quả hoặc chuyển công việc theo từng giai đoạn dễ quản lý. Trước khi phê duyệt giai đoạn này, hãy yêu cầu bốn điều: mục đích cụ thể, xác định rõ hệ thống nào lưu hồ sơ có thẩm quyền, người chịu trách nhiệm điều tra sai khác và tiêu chí đã thống nhất để kết thúc việc vận hành song song.

Với CEO, người phụ trách vận hành hoặc giám đốc tài chính, quyết định này liên quan đến cách doanh nghiệp duy trì hồ sơ chính xác và hoàn thành công việc hằng ngày. Câu “Chúng ta sẽ chạy cả hai hệ thống” để lại quá nhiều điều chưa rõ. Đề xuất cần nêu rõ mỗi hệ thống sẽ làm gì, nhân viên sẽ sử dụng hệ thống nào và phương án tạm thời sẽ tốn bao nhiêu.

Ba ý nghĩa khác nhau của việc vận hành cả hai hệ thống

So sánh kết quả. Một hệ thống tiếp tục thực hiện nghiệp vụ thực tế, trong khi hệ thống thay thế tính toán kết quả để đối chiếu. Trong một ví dụ giả định về thay thế hệ thống kế toán, nhóm có thể so sánh các báo cáo cho cùng một kỳ xác định và cùng dữ liệu đầu vào, trong khi hệ thống hiện tại vẫn chịu trách nhiệm phát hành hóa đơn. Việc so sánh phép tính không được vô tình gửi thêm hóa đơn, khoản thanh toán, đơn hàng hoặc email thứ hai.

Hãy thống nhất sai khác nào cần được quan tâm và ai sẽ điều tra. Tổng số khớp nhau vẫn có thể che khuất sai khác ở từng hồ sơ, quy tắc làm tròn hoặc thời điểm ghi nhận. Sao chép dữ liệu thành công vẫn để lại một câu hỏi riêng: nhân viên có thể hoàn thành quy trình cần thiết, kể cả việc sửa lỗi và xử lý ngoại lệ hay không?

Chuyển giao trách nhiệm theo từng giai đoạn. Một chức năng cụ thể hoặc một nhóm khách hàng được chuyển sang hệ thống thay thế, còn công việc khác vẫn ở hệ thống cũ. Mỗi giai đoạn cần hướng dẫn rõ nhân viên nhập thay đổi ở đâu và báo cáo lấy hồ sơ từ hệ thống nào. Việc cả hai ứng dụng cùng khả dụng không có nghĩa cả hai đều có thẩm quyền đối với mọi hồ sơ.

Hướng dẫn của Microsoft về mẫu Strangler Fig mô tả cách chuyển dần chức năng và cuối cùng loại bỏ hệ thống cũ. Cần theo dõi các phụ thuộc và dữ liệu dùng chung trong suốt quá trình. Với người điều hành doanh nghiệp, câu hỏi thiết thực là liệu có thể phân chia trách nhiệm đủ rõ để vận hành và kiểm tra từng giai đoạn hay không.

Chủ động ghi dữ liệu vào cả hai hệ thống. Trong trường hợp này, phần mềm được thiết kế rõ ràng để ghi thay đổi ở hai nơi. Điều đó tạo thêm một nghĩa vụ: giải thích điều gì xảy ra khi một lần ghi thành công còn lần kia thất bại. Phải có người phát hiện sai khác, quyết định hồ sơ nào có thẩm quyền và hoàn tất hoặc sửa phần việc còn thiếu.

Bài giải thích thực tiễn của Ed Murray trên AWS về việc quay lại sau khi di chuyển, đăng năm 2020 minh họa sự phối hợp cần có khi ghi kép và chuyển về hệ thống cũ theo từng bước. Đây là ví dụ kỹ thuật được công bố năm 2020, không phải kế hoạch triển khai có thể áp dụng sẵn. Nhập trùng dữ liệu bằng tay hoặc hứa rằng dữ liệu sẽ tự đồng bộ không giải quyết được các trách nhiệm này.

So sánh việc vận hành song song với một lần chuyển đổi đã diễn tập

Chuyển đổi theo giai đoạn có thể giới hạn lượng công việc thay đổi cùng lúc, nhưng duy trì hai môi trường vận hành làm tăng công việc hỗ trợ, đào tạo, đối soát và tích hợp tạm thời. Hãy tính các chi phí này vào quyết định thay thế, cùng với chi phí gỡ bỏ các kết nối tạm thời.

Trong bài viết năm 2022 Kiến trúc chuyển tiếp, Ian Cartwright, Rob Horn và James Lewis mô tả các cầu nối tạm thời và việc loại bỏ chúng sau này. Kinh nghiệm của họ giải thích vì sao cầu nối có thể hữu ích nhưng vẫn cần ngân sách và kế hoạch kết thúc riêng.

Cũng nên so sánh phương án chuyển đổi một lần đã diễn tập khi hệ thống nhỏ, không thể phân chia trách nhiệm, không có điểm tích hợp phù hợp hoặc thời hạn ngừng hệ thống gấp khiến việc vận hành song song kéo dài không khả thi. Microsoft nêu những giới hạn tương tự về mức độ phù hợp của phương án thay thế dần. Những điều kiện này không khiến chuyển đổi một lần tự động an toàn. Chúng làm cho khâu chuẩn bị, kiểm tra vận hành và thẩm quyền ra quyết định trở nên đặc biệt quan trọng.

Hãy yêu cầu bằng chứng từ buổi diễn tập quá trình chuyển đổi được đề xuất và các điều kiện đã thống nhất để tiếp tục hoặc dừng lại. So sánh hai phương án dựa trên công việc thực tế cần duy trì. Không có thời hạn hay ngưỡng nghiệm thu chung cho mọi trường hợp.

Giao dịch mới làm thay đổi quyết định quay lại

Khi nhân viên đã nhập công việc hợp lệ vào hệ thống thay thế, mở lại ứng dụng cũ có thể khiến các hồ sơ mới hơn không được chuyển theo. Đơn hàng cũng có thể đã kích hoạt giao hàng, thanh toán hoặc tin nhắn, những việc không thể đảo ngược chỉ bằng cách khôi phục cơ sở dữ liệu.

Hướng dẫn chuyển đổi của AWS phân biệt việc quay lại trước khi có dữ liệu mới với việc quay lại sau khi phát sinh giao dịch mới, khi cơ sở dữ liệu ban đầu có thể đã lỗi thời. Trước khi phê duyệt phương án quay lại, hãy yêu cầu cách xử lý cụ thể đối với hồ sơ mới và các hoạt động tiếp theo mà chúng đã kích hoạt. Chỉ có bản sao lưu không chứng minh được rằng hoạt động có thể tiếp tục một cách nhất quán.

Biên bản quyết định cần yêu cầu

Một biên bản ngắn cần giúp những người điều hành doanh nghiệp trả lời các câu hỏi sau:

• Mục đích và phạm vi: Công việc nào đang được so sánh hoặc chuyển giao, và việc duy trì cả hai hệ thống nhằm đạt điều gì?
• Thẩm quyền: Ở mỗi giai đoạn, thay đổi được nhập ở đâu và hồ sơ nào chi phối các báo cáo, hoạt động liên quan?
• Đối soát: Ai điều tra sai khác, chúng được ghi nhận ra sao và ai giải quyết các kết quả bất đồng?
• Nghiệm thu: Bằng chứng nào cho phép chuyển sang giai đoạn tiếp theo, điều gì khiến phải dừng và ai quyết định tiếp tục hay dừng?
• Quay lại: Giao dịch mới và các hoạt động tiếp theo đã hoàn tất sẽ được xử lý ra sao nếu công việc quay về hệ thống cũ?
• Kết thúc: Bằng chứng nào cho phép ngừng hệ thống, ai gỡ bỏ các cầu nối tạm thời và hồ sơ nào cần tiếp tục truy cập theo yêu cầu hiện hành?

Hãy phê duyệt việc vận hành song song khi mục đích và trách nhiệm vận hành xứng đáng với chi phí, đồng thời có lộ trình kết thúc khả thi. Nếu đang đánh giá việc thay thế, dịch vụ thay thế hệ thống cũ của chúng tôi là nơi để trao đổi về hệ thống hiện tại, công việc cần duy trì và các giới hạn khi thay đổi.