Ước lượng công sức chuyển đổi kho dữ liệu: bốn pha chi phí và độ phức tạp của từng đối tượng

Ngân sách cho dự án chuyển đổi kho dữ liệu của ngân hàng thường được trình duyệt dưới dạng một con số duy nhất. Sau vài tháng triển khai, con số này bắt đầu lệch khỏi chi phí thực tế. Nguyên nhân hiếm khi là một sai sót đơn lẻ. Phần lớn trường hợp, toàn bộ dự án được ước lượng theo cùng một cách, trong khi công việc thực chất chia thành nhiều pha có yếu tố chi phối hoàn toàn khác nhau.

Bài viết này trình bày cách lập bản ước lượng mà giám đốc công nghệ thông tin (CIO) hay giám đốc dữ liệu có thể đọc hiểu, chất vấn và bảo vệ trước hội đồng quản trị. Bản ước lượng gồm ba thành phần: bốn pha chi phí, đối tượng được phân nhóm theo độ phức tạp, và một khoản dự phòng riêng cho phần mã không chuyển đổi tự động được. Nội dung của một tuần quét hiện trạng đã được trình bày trong bài trước; bài này tập trung vào bước tiếp theo, tức là quy đổi kết quả quét thành công sức.

Bốn pha, bốn yếu tố chi phối chi phí

Mỗi dự án chuyển đổi gồm bốn pha, và chi phí của từng pha được tính theo cách riêng. Đây chính là điểm mấu chốt: nếu áp một đơn giá theo số bảng cho cả bốn pha, bản ước lượng gần như chắc chắn sai ở ít nhất ba pha.

Kiến trúc và quản trị. Pha này gồm kiến trúc đích, thiết kế workspace và nền tảng, thiết kế luồng nạp dữ liệu, chiến lược di chuyển dữ liệu, chiến lược chuyển đổi mã nguồn (phần nào chuyển đổi tự động, phần nào viết lại thủ công) và kế hoạch kiểm thử, đối soát. Với ngân hàng, pha này còn bao gồm mô hình phân quyền: vai trò trong hệ thống quản lý danh tính được ánh xạ sang quyền truy cập trong Unity Catalog như thế nào, và ai là người phê duyệt. Quy mô của pha này phụ thuộc vào số quyết định cần đưa ra và số bên cần thống nhất, không phụ thuộc vào số đối tượng. Một kho dữ liệu nhỏ tại một ngân hàng chịu giám sát chặt chẽ vẫn có thể cần khối lượng công việc kiến trúc tương đương một kho dữ liệu lớn.

Chuyển đổi và kiểm thử cú pháp. Pha này gồm chuyển đổi mã SQL, thủ tục lưu trữ (stored procedure) và job ETL, di chuyển dữ liệu lịch sử và dữ liệu phát sinh, cùng kiểm thử đơn vị cho từng thành phần đã chuyển đổi. Đây là pha tăng tỷ lệ thuận với danh mục đối tượng, và cũng là pha mà độ phức tạp của từng đối tượng có ảnh hưởng lớn nhất.

Kiểm thử tích hợp hệ thống (SIT) và kiểm thử chấp nhận người dùng (UAT). SIT xác nhận các job đã chuyển đổi chạy đúng thứ tự và cung cấp dữ liệu đúng cho các hệ thống phía sau. UAT xác nhận các báo cáo và số liệu mà nghiệp vụ đang sử dụng không thay đổi so với trước. Tại ngân hàng, kết quả UAT do các đơn vị sở hữu báo cáo quản trị, báo cáo rủi ro và báo cáo gửi cơ quan quản lý quyết định. Thời gian mà các đơn vị này có thể dành cho dự án thường quyết định tiến độ nhiều hơn năng lực của đội ngũ kỹ thuật.

Triển khai vận hành và chạy song song (parallel run). Pha này gồm chuyển giao theo từng giai đoạn, trỏ lại hệ thống nguồn và công cụ BI sang nền tảng mới, thiết lập giám sát, và vận hành song song hệ thống cũ với hệ thống mới cho tới khi kết quả được nghiệm thu. Yếu tố chi phối ở đây là thời gian theo lịch. Nếu giai đoạn chạy song song phải bao trùm một kỳ khoá sổ cuối tháng hoặc cuối quý, chi phí gần như không đổi dù đợt chuyển đổi có năm mươi hay năm trăm đối tượng.

Tách riêng bốn pha còn giúp hội đồng quản trị nhìn rõ mức độ chắc chắn của từng phần. Công sức chuyển đổi có thể đo trước khi dự án bắt đầu. Ngược lại, thời lượng UAT và chạy song song phụ thuộc vào các quyết định do chính ngân hàng đưa ra.

Phân loại đối tượng theo độ phức tạp

Đếm số đối tượng là chưa đủ. Một view đọc từ một bảng và một thủ tục lưu trữ có con trỏ (cursor), SQL động và giao dịch lồng nhau không thể tính là cùng một đơn vị công việc. Lakebridge Analyzer đọc mã nguồn được xuất ra từ hệ thống cũ và xếp từng job hoặc script vào bốn mức: thấp, trung bình, phức tạp và rất phức tạp. Kết quả này cũng là đầu vào cho công cụ tính toán chuyển đổi (Conversion Calculator) để ước lượng công sức.

Trên thực tế, mức độ phức tạp được quyết định bởi một số yếu tố chính:

Quy mô và cấu trúc mã. Độ dài, số câu lệnh, mức độ lồng nhau của logic.
Tính năng đặc thù của hệ quản trị nguồn. Con trỏ, SQL động, hàm độc quyền và các tính năng riêng của kho dữ liệu nguồn như materialized view, tác vụ định lịch hay stream, vốn không có tương đương trực tiếp trên nền tảng đích.
Mức độ phụ thuộc. Số bảng mà một job đọc và ghi, số job và báo cáo khác sử dụng kết quả của job đó.
Vị trí của logic nghiệp vụ. Script SQL chạy độc lập được chuyển đổi theo cách khác với logic nằm trong, hoặc được sinh ra bởi, một công cụ ETL mà ngân hàng muốn tiếp tục sử dụng.

Khi đó, bản ước lượng trở thành một bảng tính thay vì một con số: số đối tượng ở từng mức nhân với công sức cho mỗi đối tượng ở mức đó, tính riêng cho từng đợt. Phần di chuyển dữ liệu cũng được phân loại theo cách tương tự, dựa trên kết quả khảo sát như dung lượng bảng, tần suất thay đổi và khả năng hỗ trợ ghi nhận dữ liệu thay đổi (CDC) của hệ thống nguồn.

Có hai lưu ý. Thứ nhất, mức độ phức tạp phản ánh công sức chuyển đổi, không phản ánh tầm quan trọng nghiệp vụ. Một view đơn giản nhưng cung cấp số liệu cho báo cáo gửi cơ quan quản lý vẫn cần được nghiệm thu kỹ lưỡng. Thứ hai, định mức công sức cho mỗi mức cần do chính đội ngũ thực hiện đưa ra và được kiểm chứng trên mẫu thực tế: chuyển đổi thử một số đối tượng ở mỗi mức ngay từ đầu dự án là cách hiệu chỉnh bảng ước lượng đáng tin cậy nhất.

Khoản dự phòng cho phần mã không tự chuyển đổi được

Databricks công bố Lakebridge có thể tự động hoá tới 80% khối lượng công việc chuyển đổi. Nhìn từ chiều ngược lại, vẫn còn một phần công việc phải xử lý thủ công. Với kho dữ liệu ngân hàng được xây dựng qua mười lăm hay hai mươi năm, phần này thường tập trung ở những đoạn mã lâu đời và quan trọng nhất. Công cụ nào phục vụ giai đoạn nào, và phần việc nào vẫn do con người đảm nhận, được trình bày trong bài bộ công cụ tăng tốc chuyển đổi lên Databricks.

Kể cả khi dùng công cụ chuyển đổi, kế hoạch vẫn phải dành riêng một phần thời gian phát triển cho các hàm và mẫu mã (pattern) không chuyển đổi được, cùng với kiểm thử đơn vị, đối soát dữ liệu và kiểm thử tích hợp đi kèm. Những sprint đầu thường chuyển đổi được ít hơn các sprint sau, vì quy tắc chuyển đổi cho các mẫu mã riêng của ngân hàng được bổ sung dần trong quá trình thực hiện; khi các quy tắc này đã đầy đủ, tỷ lệ tự động hoá sẽ tăng lên.

Ba nguyên tắc giúp khoản dự phòng đứng vững khi trình duyệt:

Tách thành một dòng riêng trong bản ước lượng, không gộp vào đơn giá từng đối tượng, để hội đồng quản trị theo dõi được khoản này được sử dụng ra sao.
Xác định quy mô dựa trên kết quả quét hiện trạng. Tỷ lệ đối tượng ở mức phức tạp và rất phức tạp, cùng số tính năng đặc thù của hệ quản trị nguồn được phát hiện, cho biết khoản dự phòng cần lớn đến đâu.
Theo dõi mức sử dụng theo từng đợt. Nếu đợt đầu dùng ít hơn kế hoạch, các đợt sau được ước lượng lại bằng số liệu thực tế; nếu dùng nhiều hơn, chênh lệch được phát hiện sớm thay vì đến cuối dự án mới lộ ra.

Những câu hỏi ngân hàng nên đặt ra với mọi bản ước lượng

Dù bản ước lượng do đội ngũ nội bộ hay đối tác lập, năm câu hỏi sau giúp phân biệt một bản ước lượng có cơ sở với một bản ước lượng lạc quan:

Bốn pha có được tính chi phí riêng, kèm cơ sở tính cho từng pha hay không?
Bao nhiêu đối tượng thuộc từng mức độ phức tạp, và việc phân loại có dựa trên mã nguồn thực tế hay không?
Khoản dự phòng cho phần mã không tự chuyển đổi được là bao nhiêu, và được theo dõi bằng cách nào?
Giai đoạn chạy song song kéo dài bao lâu, bao trùm những kỳ khoá sổ nào, và ai phía ngân hàng là người nghiệm thu?
Những đợt nào nằm trong phạm vi, và ngân hàng có thể dừng lại sau bất kỳ đợt nào hay không?

Bản ước lượng trả lời được các câu hỏi này có thể đem ra so sánh, chất vấn và quản lý. Bản ước lượng không trả lời được thường phình ra trong quá trình thực hiện.

Cách Sancire lập bản ước lượng

Gói Quét hiện trạng chuyển đổi của Sancire kéo dài một tuần và cung cấp đầy đủ các đầu vào nêu trên: danh mục đối tượng phân loại theo độ phức tạp, kế hoạch theo đợt, sổ rủi ro và báo giá cố định cho từng đợt, trong đó bốn pha được trình bày tách bạch. Việc chuyển đổi được thực hiện theo từng đợt trong gói Chuyển đổi; mỗi đợt được nghiệm thu và thanh toán hoàn tất trước khi bắt đầu đợt tiếp theo.

Nguồn: Bài giới thiệu Lakebridge trên blog Databricks, ngày 12/6/2025. Tài liệu Lakebridge Analyzer và tài liệu bộ chuyển đổi của Lakebridge, tra cứu ngày 16/10/2026. Lakebridge phát triển nhanh; danh sách hệ thống nguồn và bộ chuyển đổi được hỗ trợ cần đối chiếu tài liệu hiện hành trước khi lập kế hoạch.