Data migration làm mình đau đầu nhất ở một chỗ nghe rất cơ bản, là không hiểu rõ thứ tự các loại data phải migrate, cái gì đi trước, cái gì đi sau, cái gì phụ thuộc cái gì, đổ sai thứ tự một cái là dữ liệu phía sau không còn chỗ mà bám. Theo mình đó cũng là lý do data migration không phải chuyện code với script, nó là chuyện hiểu dữ liệu, hiểu con người, hiểu quy trình, và hiểu cả những ô Excel tưởng vô hại.
mỗi phòng một kiểu#
Phòng kho gọi vật tư là “VT-001”, phòng kế toán gọi là “M001-Vật tư A”, phòng mua hàng ghi là “VatTu A (M001)”. Ví dụ này là giả định, nhưng theo mình nó không xa thực tế lắm, ba phòng ba cái định danh cho cùng một vật tư, và đến lúc team migration hỏi dùng cái nào làm master thì ai cũng bảo của phòng em mới đúng.
Cái bẫy thứ nhất là không có chuẩn dữ liệu chung trước khi migrate. Bạn tưởng mapping là việc của IT, nhưng các phòng ban chưa thống nhất được với nhau thì IT làm gì cũng sai. Chuyện dữ liệu nền này mình có viết trong bài ERP không chạy trên phần mềm, mà chạy trên dữ liệu.
dữ liệu sạch là huyền thoại#
Giả sử khách bảo dữ liệu bọn em sạch lắm, mở file ra thì item code có dấu cách thừa, description có ký tự đặc biệt, có ô ghi “xem file đính kèm” thay vì ghi số. Với master data không sạch, cách mình làm là làm template cho khách điền theo chuẩn rồi hướng dẫn họ điền.
Data clean cũng không phải làm một lần là xong, nó là một vòng lặp, clean rồi review, review lại lòi ra lỗi mới, rồi clean tiếp, không có kỷ luật và process thì cái vòng này kéo dài tới tận ngày cutover. Nên đừng bao giờ tin ai nói data đã sạch, tự mở ra xem, tự chạy validation script, và lúc nào cũng nên có Plan B.
legacy mapping, nỗi ám ảnh của BA#
Theo mình đây là phần BA dễ underestimate nhất, vì ERP chạy trên dữ liệu chứ không chạy trên phần mềm, mapping sai thì hệ thống đúng mấy cũng ra số sai. Giả sử hệ thống cũ chạy nhiều năm, có field “Ghi chú” mà người dùng lại dùng để nhập số PO, có field “Mã khách hàng” dùng chung cho cả nhà cung cấp, hay một date field thiết kế dd/mm/yyyy mà người dùng nhập tháng trước ngày, nhìn trên màn hình thì số đẹp, tới lúc import mới vỡ lẽ.
Legacy mapping vì thế không phải chuyện trường A sang trường B, mà là chuyện hiểu business logic đằng sau từng field, và cái business logic đó thường không có document nào, nó nằm trong đầu mấy anh chị đã dùng hệ thống cũ lâu năm. Thiếu tài liệu thì có khi còn không điều tra nổi tại sao một công thức lại tính như vậy, nó là bug hay là cố ý.
historical data, càng nhiều càng chết#
Câu hỏi kinh điển là mang bao nhiêu năm dữ liệu sang hệ thống mới, và khách thường muốn mang hết, vì lỡ sau này cần đối chiếu. Vấn đề là dữ liệu càng nhiều thì migration càng lâu, performance sau go-live càng ì, còn QA thì không thể verify hết đống data lịch sử.
Theo mình nên migrate tối thiểu, chỉ mang master data với open transactions, tức là PO chưa đóng, SO chưa ship, work order đang chạy, còn dữ liệu lịch sử để lại hệ thống cũ ở chế độ read-only, cần thì làm thêm cái giao diện tra cứu legacy là đủ. Thuyết phục khách chuyện này không dễ, nhưng gồng cả đống data không ai dùng thì còn mệt hơn.
cutover plan không có kịch bản cho ngày tồi tệ nhất#
Cutover plan nào cũng dễ lạc quan. Giả sử plan ghi script chạy mấy tiếng, validation mấy tiếng, sáng mai go-live, rồi script fail giữa chừng, fix mất thêm vài tiếng, validation làm lại, giờ go-live trôi qua mà vẫn chưa xong.
Cái này mình có trải qua một phần, một đêm kiểm kê, 4h chiều mới có file kiểm đếm, upload dữ liệu lên hệ thống mất vài tiếng, cả nhóm ở lại tới 1h đêm mới xong.
Nên cutover plan phải có rollback plan rõ ràng, không phải kiểu hy vọng không sao mà là nếu sai thì làm gì, có backup dữ liệu, có checkpoint để biết dừng đúng lúc, và theo mình quan trọng nhất là dry run trước ngày chính thức, càng sát thật càng tốt. Lần đầu thường lòi lỗi, lần sau ổn hơn, đến lúc thật thì ít nhất bạn biết mình đang đối mặt với cái gì.
không phải việc của một team#
Nói gì thì nói, data migration không phải chuyện một người hay một team làm được mà là chuyện của cả tổ chức, các phòng ban không chịu dành thời gian clean data, thống nhất chuẩn, review mapping thì BA giỏi mấy cũng chịu. Giả sử tới ngày go-live ai cũng biết data chưa sẵn sàng nhưng deadline đã ấn, thế là cứ launch, theo mình kết quả gần như chắc chắn là người dùng ghét hệ thống mới vì data sai, mà lòng tin đã mất thì lấy lại khó lắm.
Còn bạn, đã dính cú data migration nào chưa, và cái bẫy nào làm bạn đau nhất?
