Data Migration

Phần mềm mới dựng xong, kiểm thử sạch, người dùng đã đào tạo. Rồi tới câu hỏi mà ai cũng biết sẽ đến: dữ liệu mười năm qua đưa sang thế nào. Đây là giai đoạn kéo tiến độ nhiều nhất trong các dự án thay hệ thống, và cũng là giai đoạn BA khó trốn nhất vì mọi con số lệch đều cần người hiểu nghiệp vụ giải thích.

Chuyển đổi dữ liệu là bài toán nghiệp vụ đội lốt bài toán kỹ thuật. Câu khó nhất luôn là dữ liệu này có còn đúng không, chứ không phải chuyển bằng công cụ gì.

Quy trình

1. Khoanh phạm vi. Chuyển bao nhiêu năm lịch sử, những đối tượng nào. Rất hay gặp phương án: master data chuyển hết, số dư chuyển tại thời điểm cắt, còn giao dịch lịch sử để lại hệ thống cũ ở chế độ chỉ đọc.
2. Ánh xạ trường. Bảng mapping từng trường một: nguồn, đích, kiểu, quy tắc chuyển đổi, giá trị mặc định khi nguồn rỗng. Chỗ này BA làm cùng người dùng nghiệp vụ, không giao cho dev tự quyết.
3. Làm sạch. Xoá bản ghi trùng, chuẩn hoá số điện thoại và tên, bù dữ liệu thiếu, thống nhất đơn vị tính. Việc này phải do phía khách hàng đứng tên, vì chỉ họ mới có quyền nói bản ghi nào bỏ được.
4. Chạy thử. Ít nhất hai lần, tốt nhất là ba. Lần đầu để lộ lỗi, lần hai để đo thời gian chạy, lần ba là diễn tập thật với đúng kịch bản của đêm cutover.
5. Đối soát. Xem mục dưới.
6. Cutover. Chốt giờ đóng hệ thống cũ, chạy lần cuối, kiểm tra, mở hệ thống mới. Kèm một phương án quay lui viết sẵn, có tiêu chí rõ ràng để quyết định dừng.

Đối soát — chỗ BA bị gọi tên lúc nửa đêm

Chạy xong không có nghĩa là xong. Phải chứng minh dữ liệu bên mới bằng bên cũ, và chứng minh bằng con số chứ không bằng cảm giác.

Bộ đối soát tối thiểu:

• Đếm bản ghi: số khách hàng, số sản phẩm, số hợp đồng còn hiệu lực. Lệch bao nhiêu, vì sao lệch, có được chấp nhận không.
• Tổng số dư: tổng công nợ phải thu, phải trả, tồn kho theo giá trị, số dư tài khoản. Với số dư kế toán, mức chấp nhận thường là chênh lệch đúng bằng không.
• Đối soát theo lát cắt: tổng công nợ theo từng khách hàng lớn, tồn kho theo từng kho, chứ đừng chỉ nhìn tổng. Hai sai số ngược dấu triệt tiêu nhau ở tổng là chuyện có thật.
• Kiểm mẫu: chọn 30 bản ghi ngẫu nhiên, mở song song hai hệ thống, so từng trường bằng mắt.

Và luôn có một biên bản đối soát để người có thẩm quyền phía khách ký. Chuyện này ít liên quan tới việc đổ trách nhiệm hơn người ta tưởng: tháng sau, khi kế toán trưởng nói số này sai, cả hai bên còn một mốc chung để bắt đầu nói chuyện.

Ví dụ thực tế

1h30 sáng, đối soát vẫn lệch. Tổng công nợ bên hệ thống mới hụt bên cũ 380 triệu. Đêm cutover này bắt đầu từ 22h thứ sáu, dự kiến xong lúc 3h, và nó là đêm một công ty thương mại chuyển từ phần mềm kế toán cũ sang ERP: 2.680 khách hàng, công nợ phải thu hơn 58 tỷ.

Truy ra sau gần hai tiếng: các hoá đơn có chiết khấu thương mại ghi âm được hệ thống cũ lưu ở một bảng riêng, còn bảng mapping chỉ lấy bảng hoá đơn chính. Đội kỹ thuật sửa script, chạy lại phần công nợ, tới 5h sáng thì khớp. Go-live vẫn diễn ra sáng thứ hai, nhưng cả đội mất trọn cuối tuần.

Lần chạy thử thứ hai đã lệch đúng kiểu này, ở mức 12 triệu. Con số nhỏ, nên nó được ghi vào mục theo dõi sau và cả đội đi tiếp.

Lỗi hay gặp

• Coi chạy thử là việc của đội kỹ thuật, người dùng nghiệp vụ không xem kết quả.
• Bỏ qua chênh lệch nhỏ ở lần chạy thử. Sai số nhỏ trên tập dữ liệu nhỏ sẽ thành sai số lớn trên tập đầy đủ.
• Không tính thời gian chạy thật. Script chạy 2 tiếng với 10% dữ liệu không có nghĩa là 20 tiếng với 100%.
• Quên các trường bắt buộc mới. Hệ thống mới yêu cầu mã ngành nghề cho mọi khách, hệ thống cũ không có, và phải có người ngồi điền 2.700 dòng.
• Không chuẩn bị phương án quay lui, hoặc có mà chưa từng thử.

Mốc thời gian của một dự án chuyển đổi thường được hứa trước khi có ai mở dữ liệu cũ ra đếm thử. Cái đêm 1h30 ở trên là hoá đơn cho lời hứa đó.