Mở đầu — vì sao bài này quan trọng
Suốt 58 bài trước, bạn đã học từng mảnh ghép riêng lẻ: SQL, schema design, API spec, integration pattern, data migration, security, observability, vendor selection... Mỗi thứ là một kỹ năng. Nhưng trong đời thực, không ai trả lương cho bạn để làm tốt từng mảnh ghép tách rời. Người ta trả lương cho bạn để ghép tất cả lại với nhau, dưới áp lực, với deadline thật, với tiền thật và với rủi ro thật.
Bài này là bài "tổng duyệt". Tôi sẽ dẫn bạn đi qua một dự án mà gần như mọi Technical BA trong ngành tài chính Việt Nam đều sẽ chạm tới ít nhất một lần trong sự nghiệp: migration core banking — thay "trái tim" của một ngân hàng. Đây là loại dự án đắt nhất, dài nhất, rủi ro cao nhất mà một ngân hàng từng làm. Một ngân hàng tier-2 ở Việt Nam thường chi từ 15 đến 40 triệu USD và mất 18–36 tháng cho một cuộc thay core. Nếu hỏng, không chỉ mất tiền — khách hàng không rút được tiền, ATM đứng, ngân hàng nhà nước hỏi thăm, báo chí đăng tin, và niềm tin mất hàng năm mới xây lại được.
Tại sao Technical BA lại quan trọng trong cuộc chơi này? Vì giữa đội nghiệp vụ (chỉ hiểu sản phẩm) và đội kỹ thuật/vendor (chỉ hiểu hệ thống), có một khoảng trống khổng lồ. Người lấp khoảng trống đó — người dịch được "tiền lãi tiết kiệm tính theo phương pháp 365 ngày thực tế của ngân hàng cũ" thành "tham số interest_basis = ACT/365 trong product factory của Temenos" — chính là bạn. Làm tốt, dự án sống. Làm dở, dự án thành thảm họa được kể lại trong các hội thảo.
Khái niệm cốt lõi
Bối cảnh dự án mẫu
Tôi sẽ dùng một dự án giả định nhưng sát thực tế làm xương sống cho cả bài. Gọi là "Ngân hàng An Bình" (ABBank giả định, tier-2):
- Hệ thống cũ: core legacy chạy 15 năm, viết trên nền COBOL/AS400, batch xử lý ban đêm, không có API thực thụ.
- Hệ thống mới: Temenos T24 (Transact) — core banking phổ biến nhất ở Đông Nam Á, dùng bởi nhiều ngân hàng VN.
- Scope dữ liệu: 2 triệu khách hàng, 5 triệu tài khoản, ~120 triệu giao dịch lịch sử cần xét migration.
- Timeline: 24 tháng, ngân sách ~22 triệu USD.
- Team: vendor triển khai (SI), nhà cung cấp Temenos, IT nội bộ, và 4 Technical BA phụ trách 4 luồng nghiệp vụ: Customer & CIF, Deposit/Savings, Loan, và Payment/Integration.
Vì sao migration core khó hơn migration thông thường
Một migration ứng dụng web bình thường, dữ liệu sai thì sửa, downtime vài giờ là chấp nhận được. Core banking thì khác về bản chất:
- Dữ liệu là tiền. Sai số dư một tài khoản là sai tiền của khách. Không có khái niệm "sai một chút cũng được".
- Không thể tắt ngân hàng quá lâu. Cutover thường gói gọn trong một kỳ nghỉ lễ dài (Tết, lễ 30/4) — 48 đến 72 giờ là tối đa.
- Đối soát phải khớp đến từng đồng. Tổng tài sản, tổng nợ, tổng số dư từng loại tài khoản trên hệ cũ và hệ mới phải bằng nhau tuyệt đối tại thời điểm cutover.
- Ràng buộc pháp lý. Ngân hàng Nhà nước yêu cầu báo cáo không gián đoạn; dữ liệu lịch sử phải giữ đủ theo quy định lưu trữ (thường 10 năm).
Mô hình chuyển đổi: Big Bang vs Phased
Đây là quyết định kiến trúc lớn nhất, và Technical BA phải hiểu rõ để tư vấn:
- Big Bang: chuyển toàn bộ trong một lần cutover. Rủi ro tập trung nhưng tránh được giai đoạn "hai hệ thống chạy song song" cực kỳ phức tạp. Phù hợp ngân hàng nhỏ, scope gọn.
- Phased / Module-by-module: chuyển từng phân hệ (ví dụ chuyển Deposit trước, Loan sau). Giảm rủi ro mỗi lần, nhưng phải duy trì đồng bộ hai chiều giữa core cũ và core mới trong nhiều tháng — và đây là phần ác mộng về kỹ thuật.
- Parallel Run: cho cả hai hệ chạy đồng thời trên cùng dữ liệu một thời gian, đối soát kết quả trước khi chính thức tắt hệ cũ.
Vai trò cụ thể của Technical BA trong dự án core
Đừng nghĩ BA chỉ "viết requirement". Trong dự án core, bạn sẽ chịu trách nhiệm cho:
- Data mapping specification: dịch từng trường dữ liệu hệ cũ sang model Temenos, kèm quy tắc transform.
- Gap analysis: so sánh nghiệp vụ hiện tại với khả năng "out-of-the-box" của T24, xác định cái gì customize.
- Reconciliation rules: định nghĩa quy tắc đối soát số dư, số lượng record, control total.
- Cutover runbook: kịch bản từng phút cho 48–72 giờ chuyển đổi, kèm điều kiện rollback.
- UAT design: thiết kế kịch bản test nghiệp vụ để key user xác nhận hệ mới làm đúng.
Tình huống thực tế
Tình huống 1 — "Lãi cộng dồn bốc hơi" do hiểu sai cách tính lãi
Ở ABBank, đội Deposit migration làm mapping số dư tài khoản tiết kiệm khá thuận lợi: trường BALANCE hệ cũ map sang WORKING.BALANCE của T24. UAT vòng một, số dư khớp 100%, ai cũng vui.
Nhưng Technical BA luồng Deposit — tên Hương — phát hiện một vấn đề mà các con số tổng không cho thấy: hệ cũ lưu lãi dồn tích chưa nhập gốc (accrued interest) ở một trường riêng ACR_INT, tính theo cơ sở ACT/365. Trong khi mặc định, sản phẩm tiết kiệm cấu hình trên T24 lại đang để ACT/360. Với từng tài khoản, chênh lệch chỉ vài nghìn đồng. Nhưng nhân với 1,2 triệu tài khoản tiết kiệm và cộng dồn qua kỳ tính lãi tiếp theo, tổng chênh lệch lên tới hơn 4 tỷ đồng — toàn bộ là tiền ngân hàng "ăn bớt" của khách hàng một cách vô ý.
Hương xử lý bằng cách: (1) viết một mapping rule riêng cho trường accrued interest, (2) yêu cầu vendor cấu hình lại interest_basis của từng product line cho khớp hệ cũ, và (3) bổ sung một test case đối soát riêng cho accrued interest, không gộp chung với số dư gốc.
Bài học: Control total tổng khớp KHÔNG có nghĩa là dữ liệu đúng. Tiền có nhiều "tầng" — số dư khả dụng, số dư khả dụng, lãi dồn tích, phí treo — và mỗi tầng cần một quy tắc đối soát riêng. Technical BA giỏi luôn hỏi: "Ngoài số dư chính, còn loại tiền nào bị giấu ở trường phụ không?"
Tình huống 2 — Khách hàng "tách đôi" vì mã định danh không thống nhất
Luồng Customer/CIF gặp vấn đề kinh điển của ngành ngân hàng VN: một người có thể tồn tại nhiều lần trong hệ cũ. Bác Tâm mở sổ tiết kiệm năm 2010 bằng CMND 9 số, mở thẻ năm 2018 bằng CCCD 12 số, và vay tiêu dùng năm 2021 cũng bằng CCCD nhưng nhân viên gõ nhầm một chữ số. Trong hệ cũ, bác Tâm là 3 khách hàng khác nhau.
Nếu migration "y nguyên", hệ T24 mới sẽ có 3 CIF cho cùng một người — sai về định danh khách hàng, vi phạm yêu cầu KYC, và làm hỏng mọi báo cáo "tổng dư nợ theo khách hàng" mà ngân hàng nhà nước yêu cầu.
Technical BA luồng CIF, anh Dũng, đối mặt một lựa chọn khó: deduplication (gộp khách trùng) ngay trong migration, hay migration nguyên trạng rồi gộp sau? Anh chọn cách trung gian: xây một bộ quy tắc matching (so khớp theo CCCD chuẩn hóa + ngày sinh + họ tên đã bỏ dấu) để gắn cờ các bản ghi nghi trùng, rồi đẩy danh sách "nghi trùng" cho đội nghiệp vụ review thủ công trước cutover. Khoảng 38.000 cặp nghi trùng được phát hiện; sau review, ~31.000 cặp được xác nhận gộp.
Quan trọng nhất: anh viết rõ trong spec rằng việc gộp không được làm mất lịch sử giao dịch — các account của 3 CIF cũ phải được trỏ về 1 CIF mới, mọi giao dịch vẫn truy vết được.
Bài học: Migration là cơ hội vàng để làm sạch dữ liệu, nhưng làm sạch là quyết định nghiệp vụ, không phải kỹ thuật. Technical BA phải đưa quyết định "gộp hay không gộp" lên bàn nghiệp vụ với số liệu rõ ràng, chứ không tự ý quyết trong code.
Tình huống 3 — Cutover suýt rollback vì một file batch không chạy
Đêm cutover thật, rơi vào kỳ nghỉ lễ 4 ngày. Runbook chia làm 3 pha: extract & freeze hệ cũ (giờ thứ 0–8), load & transform vào T24 (giờ 8–30), reconcile & smoke test (giờ 30–44), mở cửa (giờ 44).
Đến giờ thứ 26, đội phát hiện luồng giao dịch thẻ ATM/POS của ngày cuối chưa được tích hợp vào snapshot — vì file đối soát từ hệ thống chuyển mạch (NAPAS) về trễ 3 giờ so với lịch. Nếu mở cửa mà thiếu, số dư hàng chục nghìn khách bị sai vào sáng đầu tiên.
Đây là lúc decision gate trong runbook phát huy tác dụng. Technical BA phụ trách Payment đã định nghĩa sẵn một điểm quyết định: "Nếu file NAPAS chưa khớp trước giờ thứ 34 → kích hoạt rollback". Nhờ có ngưỡng rõ ràng, team không hoảng loạn tranh cãi. Họ chờ, nhận file lúc giờ thứ 31, load bổ sung, đối soát lại, và mở cửa đúng hạn. Nếu file về sau giờ 34, họ đã rollback có kỷ luật thay vì "cố đấm ăn xôi".
Bài học: Một cutover runbook tốt không phải là danh sách việc cần làm — nó là tập hợp các điểm quyết định có ngưỡng định lượng và điều kiện rollback rõ ràng. Technical BA là người định nghĩa các ngưỡng đó từ trước, khi đầu óc còn tỉnh táo, chứ không phải lúc 3 giờ sáng khi mọi người đang kiệt sức.
Hướng dẫn từng bước
Đây là khung công việc của Technical BA xuyên suốt một dự án core migration. Bạn không làm một mình, nhưng bạn là người chịu trách nhiệm chính cho các artifact dưới đây.
Bước 1 — Discovery & As-Is documentation. Lập danh mục mọi sản phẩm, mọi loại tài khoản, mọi quy tắc nghiệp vụ của hệ cũ. Đặc biệt săn lùng các "tri thức ẩn" chỉ nằm trong đầu nhân viên cũ — cách tính phí ngoại lệ, các sản phẩm legacy đã ngừng bán nhưng còn khách đang dùng. Kết quả: As-Is Product Catalog.
Bước 2 — Gap Analysis. Đặt từng nghiệp vụ As-Is cạnh khả năng out-of-the-box của T24. Phân loại mỗi gap thành: (a) cấu hình được (configuration), (b) cần customize, hoặc (c) đổi quy trình nghiệp vụ để khớp chuẩn hệ mới (process change). Khuyến nghị mạnh: ưu tiên đổi quy trình hơn customize, vì customize làm dự án đắt và khó nâng cấp về sau.
Bước 3 — Data Mapping Specification. Với mỗi entity (Customer, Account, Transaction, Loan...), lập bảng map: trường nguồn → trường đích → quy tắc transform → quy tắc xử lý null/giá trị lỗi. Đây là tài liệu bạn sẽ chỉnh sửa nhiều nhất.
Bước 4 — Định nghĩa Reconciliation Rules. Với mỗi nhóm dữ liệu, xác định control total cần khớp: tổng số record, tổng số dư theo loại, số tài khoản theo trạng thái. Định nghĩa ngưỡng chấp nhận (lý tưởng là 0 chênh lệch về tiền).
Bước 5 — Mock Run nhiều vòng. Chạy thử migration trên bản sao dữ liệu thật (đã ẩn danh nếu cần), đối soát, sửa, lặp lại. Dự án thực tế thường cần 3–6 vòng mock run. Mỗi vòng phải giảm dần số lỗi.
Bước 6 — UAT. Thiết kế kịch bản để key user nghiệp vụ tự tay thực hiện giao dịch trên hệ mới và xác nhận kết quả khớp kỳ vọng. BA viết test case, business ký xác nhận.
Bước 7 — Cutover Runbook & Dry Run. Viết kịch bản từng giờ, kèm điểm quyết định và điều kiện rollback. Quan trọng: tổ chức dry-run cutover — diễn tập toàn bộ kịch bản như thật, bấm giờ, để biết 48 giờ có đủ không.
Bước 8 — Cutover thật & Hypercare. Sau khi mở cửa, có giai đoạn "hypercare" 2–4 tuần với đội trực sẵn xử lý sự cố tức thì. BA túc trực để diễn giải các sai khác nghiệp vụ phát sinh.
Lỗi thường gặp & mẹo
Lỗi 1 — Coi reconciliation là việc cuối cùng. Nhiều team chỉ nghĩ tới đối soát khi đã load xong. Sai. Quy tắc đối soát phải được thiết kế NGAY từ bước data mapping — vì chính nó định nghĩa thế nào là "migration thành công". Mẹo: với mỗi mapping rule, viết luôn câu hỏi "làm sao tôi chứng minh nó đúng?".
Lỗi 2 — Bỏ quên dữ liệu lịch sử và các trạng thái biên. Tài khoản đã đóng, khoản vay đã tất toán, khách hàng đã chết nhưng còn số dư thừa kế... đây là những ca dễ bị bỏ sót và cũng dễ gây sự cố nhất. Mẹo: luôn migration và đối soát cả các bản ghi "trạng thái đặc biệt", đừng chỉ test trên tài khoản active đẹp đẽ.
Lỗi 3 — Customize quá nhiều để "giữ y nguyên hệ cũ". Mỗi customize là một món nợ kỹ thuật bạn phải trả khi T24 nâng cấp phiên bản. Mẹo: thách thức mọi yêu cầu "phải giống hệ cũ" bằng câu hỏi "đây là yêu cầu nghiệp vụ bắt buộc hay chỉ là thói quen?".
Lỗi 4 — Runbook không có điều kiện rollback định lượng. "Nếu có vấn đề thì rollback" là vô dụng lúc 3 giờ sáng. Mẹo: mỗi pha phải có ngưỡng số (ví dụ "chênh lệch số dư > 0 đồng → dừng") và một người duy nhất có quyền ra quyết định go/no-go.
Lỗi 5 — Quên đối soát các hệ ngoại vi. Core không sống một mình — nó kết nối Internet Banking, ATM switch, NAPAS, hệ thống báo cáo NHNN, CIC. Migration core mà quên test lại các tích hợp này là tự đào hố. Mẹo: lập danh mục mọi hệ thống "vệ tinh" và lên kế hoạch test tích hợp riêng cho từng cái.
Mẹo tổng: Trong dự án này, tài sản giá trị nhất của bạn là một bảng truy vết (traceability matrix) nối: yêu cầu nghiệp vụ → mapping rule → test case → kết quả reconciliation. Khi ai đó hỏi "trường này tại sao lại có giá trị này", bạn lần ngược được trong 30 giây thay vì 3 ngày.
Bài tập thực hành
- Viết một mapping rule hoàn chỉnh. Cho trường
CUST_DOB(ngày sinh) ở hệ cũ lưu dạng chuỗiDDMMYYYYvà có khoảng 2% bản ghi bị rỗng hoặc giá trị00000000. Hãy viết mapping spec sang trườngDATE.OF.BIRTHcủa T24 (định dạngYYYYMMDD), nêu rõ quy tắc transform và quy tắc xử lý dữ liệu lỗi/null. Bạn sẽ làm gì với 2% bản ghi xấu — chặn migration hay cho qua với giá trị mặc định? Giải thích lựa chọn.
- Thiết kế bộ reconciliation cho phân hệ Deposit. Liệt kê tối thiểu 5 control total bạn sẽ đối soát giữa hệ cũ và T24, và với mỗi cái nêu ngưỡng chấp nhận. Nhớ bài học từ Tình huống 1.
- Viết một đoạn cutover runbook. Cho pha "reconcile & smoke test" (giờ 30–44). Định nghĩa ít nhất 2 điểm quyết định (decision gate) với ngưỡng định lượng và hành động rollback tương ứng.
- Phân tích tình huống dedup. Quay lại Tình huống 2: nếu đội nghiệp vụ không kịp review 38.000 cặp nghi trùng trước cutover, bạn sẽ đề xuất phương án dự phòng nào để vừa kịp tiến độ vừa không tạo ra dữ liệu sai? Viết 1 đoạn lập luận.
Tóm tắt
Migration core banking là bài kiểm tra cuối cùng và khắc nghiệt nhất của một Technical BA — nơi mọi kỹ năng rời rạc bạn đã học phải hợp lại thành một năng lực duy nhất: biến rủi ro hàng chục triệu USD thành một chuỗi quyết định có kiểm soát. Những điểm cốt lõi cần khắc cốt:
- Tiền có nhiều tầng. Số dư tổng khớp không đồng nghĩa dữ liệu đúng — phải đối soát từng loại tiền, kể cả lãi dồn tích và phí treo.
- Làm sạch dữ liệu là quyết định nghiệp vụ, không phải quyết định kỹ thuật — BA đưa nó lên bàn nghiệp vụ với số liệu, không tự quyết trong code.
- Reconciliation phải thiết kế từ đầu, song hành với mapping, vì nó định nghĩa thế nào là thành công.
- Cutover runbook giá trị nằm ở các điểm quyết định có ngưỡng định lượng và điều kiện rollback rõ ràng — được viết lúc tỉnh táo, không phải lúc 3 giờ sáng.
- Traceability matrix nối requirement → mapping → test → reconciliation là tài sản cứu mạng bạn xuyên suốt dự án.