Số hóa dữ liệu: từ giấy tờ, Excel và hệ thống cũ đến một nguồn dữ liệu tin được

"Số hóa dữ liệu" thường được hiểu đơn giản là "chuyển giấy thành file": scan hợp đồng, nhập liệu từ sổ sách vào Excel, hoặc đưa một hệ thống cũ lên cloud. Nhưng phần lớn dự án dừng lại đúng ở bước này — có file PDF, có bảng Excel, nhưng không có một nguồn dữ liệu nào mà các hệ thống khác có thể tin tưởng và dùng trực tiếp. Vấn đề kỹ thuật thật sự của số hóa dữ liệu không nằm ở việc "đọc được chữ", mà ở những bước diễn ra ngay sau đó: chuẩn hóa, đối soát, và hợp nhất thành một nguồn sự thật (single source of truth). Bài viết này phân tích các vấn đề thường gặp và kiến trúc pipeline mà chúng tôi áp dụng để biến dữ liệu rải rác, không đồng nhất thành dữ liệu mà hệ thống vận hành và phân tích có thể dùng trực tiếp.

Vấn đề thật: không phải "đọc được chữ", mà là "đối soát dữ liệu"

Các công cụ OCR/ICR hiện đại — kể cả Vision-Language Model như Qwen3-VL, đã phân tích trong bài viết trước — đạt độ chính xác trên 95% với chữ in và phần lớn chữ viết tay rõ ràng. Nhưng đọc đúng từng ký tự không giải quyết được vấn đề lớn hơn: cùng một khách hàng, sản phẩm hay tài sản thường xuất hiện với nhiều cách viết khác nhau trong nhiều tài liệu và hệ thống — "Nguyễn Văn A", "NGUYEN VAN A", "Nguyen V.A"; mã khách hàng KH-00123 ở hệ thống kế toán nhưng CUST123 ở hệ thống CRM. Một engine đọc đúng 100% ký tự vẫn vô dụng nếu hệ thống đích không biết đây là "cùng một thực thể".

OCR, ICR và giới hạn của "đọc tự động"

OCR (Optical Character Recognition) xử lý tốt văn bản in với layout đơn giản. ICR (Intelligent Character Recognition) cho chữ viết tay có độ chính xác thấp hơn và phụ thuộc nhiều vào chất lượng ảnh chụp/scan. Với tài liệu có bảng biểu phức tạp, đa cột, hoặc layout thay đổi giữa các đơn vị phát hành — hóa đơn, sổ sách kế toán cũ, biểu mẫu viết tay — không có engine nào đạt 100%, và cố ép một ngưỡng độ chính xác cao tuyệt đối thường dẫn đến chi phí compute tăng vọt mà lợi ích cận biên rất nhỏ.

Cách tiếp cận thực tế là confidence-based routing: trường dữ liệu có độ tin cậy cao được tự động đưa vào hệ thống, trường có độ tin cậy thấp được đưa vào hàng chờ cho người kiểm tra. Trong pipeline KYC cho một fintech tier-1 mà chúng tôi triển khai, cách này giúp tự động hóa 92% hồ sơ — 8% còn lại không phải là "thất bại", mà là phần được thiết kế để con người xử lý, vì chi phí tự động hóa phần đó cao hơn giá trị mang lại.

Chuẩn hóa dữ liệu — bước "nhàm chán" quyết định thành bại

Sau khi trích xuất, dữ liệu thô gần như luôn không đồng nhất: ngày tháng viết theo nhiều định dạng (dd/mm/yyyy, yyyy-mm-dd, hoặc "ngày 5 tháng 6"), số điện thoại có hoặc không có mã vùng, địa chỉ viết tắt khác nhau giữa các tài liệu. Nếu bước chuẩn hóa này bị bỏ qua, mọi vấn đề sẽ trồi lên ở downstream — báo cáo sai, dashboard lệch số, hoặc tệ hơn, hệ thống vận hành dùng nhầm dữ liệu mà không ai biết.

Định nghĩa schema đích rõ ràng cho từng trường — kiểu dữ liệu, định dạng, giá trị hợp lệ — trước khi viết bất kỳ script chuyển đổi nào
Validate tại nguồn: kiểm tra checksum số định danh (CCCD, mã số thuế), khoảng giá trị hợp lý (ngày sinh không ở tương lai, số tiền không âm khi không nên âm)
Log lại mọi bản ghi không qua được validation, kèm lý do cụ thể — để review theo lô, không phải sửa tay từng dòng khi phát hiện lỗi về sau

Đây chính là khái niệm data contract mà chúng tôi đã đề cập trong bài viết về pipeline ELT với dbt và Airflow — áp dụng từ bước đầu tiên của số hóa, không phải chỉ ở lớp warehouse.

Entity resolution và Master Data Management (MDM)

Sau chuẩn hóa, bước tiếp theo là xác định: bản ghi nào trong số hàng nghìn bản ghi từ nhiều nguồn thực ra là cùng một thực thể (khách hàng, nhà cung cấp, tài sản, sản phẩm). Đây là entity resolution — kết hợp các kỹ thuật:

Blocking — nhóm các bản ghi có khả năng trùng dựa trên một vài trường dễ so sánh (số điện thoại, mã số thuế, email) để tránh so sánh từng cặp trong toàn bộ dữ liệu — phép so sánh n² không khả thi với hàng triệu bản ghi
Fuzzy matching — so sánh các trường còn lại (tên, địa chỉ) bằng khoảng cách chuỗi (Levenshtein, Jaro-Winkler) để xử lý lỗi chính tả và cách viết khác nhau
Quy tắc hợp nhất (merge rules) — khi nhiều bản ghi được xác định là cùng một thực thể, cần quy tắc rõ ràng để chọn giá trị nào là "đúng" cho mỗi trường — thường là bản ghi mới nhất, hoặc từ nguồn có độ tin cậy cao nhất

Kết quả của entity resolution là một "golden record" — một bản ghi canonical cho mỗi thực thể, kèm một ID duy nhất và liên kết ngược về tất cả bản ghi nguồn đã được hợp nhất vào nó. Giữ liên kết ngược này (provenance) quan trọng không kém golden record — khi phát hiện sai sót, cần biết dữ liệu đến từ đâu để sửa đúng gốc, không chỉ sửa bản tổng hợp.

Chiến lược migration: incremental, không big-bang

Một sai lầm phổ biến là cố di trú toàn bộ dữ liệu và chuyển hẳn sang hệ thống mới trong một lần — "big-bang migration". Khi có vấn đề (luôn có), toàn bộ vận hành bị ảnh hưởng và việc rollback gần như không khả thi sau khi đã chạy một thời gian. Cách tiếp cận an toàn hơn:

Chạy song song (dual-run) — hệ thống cũ và pipeline số hóa cùng hoạt động trong một giai đoạn, đối chiếu kết quả giữa hai bên trước khi cắt hẳn sang hệ thống mới
Di trú theo lô (batch) — theo phòng ban, theo loại tài liệu, hoặc theo khoảng thời gian — mỗi lô được validate độc lập trước khi mở rộng sang lô tiếp theo
Giữ khả năng rollback theo lô — nếu một lô phát hiện vấn đề về chất lượng dữ liệu, chỉ lô đó cần xử lý lại, không phải toàn bộ pipeline

Trong portal nội bộ thay 4 hệ thống legacy mà chúng tôi xây dựng cho một doanh nghiệp, dữ liệu từ 4 hệ thống cũ được hợp nhất theo từng nhóm nghiệp vụ, chạy song song với hệ thống cũ trong vài tuần mỗi nhóm — giảm thời gian onboarding người dùng mới 72% sau khi hoàn tất, vì toàn bộ thông tin nằm ở một nơi với một schema nhất quán.

Kiến trúc tham khảo: pipeline số hóa

Ghép các bước trên thành một pipeline end-to-end:

Nguồn — giấy tờ scan, PDF, file Excel/CSV rải rác, hoặc export từ hệ thống cũ
OCR/ICR hoặc parser — trích xuất dữ liệu thô kèm confidence score cho từng trường
Validate — kiểm tra theo schema đích, định dạng, và quy tắc nghiệp vụ; bản ghi lỗi vào hàng chờ review
Entity resolution / MDM — hợp nhất bản ghi trùng thành golden record, giữ provenance về nguồn gốc
Golden record store — nguồn dữ liệu chính, là input cho cả hệ thống vận hành (CRM, ERP) và lớp Data Analytics phía sau

Điểm quan trọng nhất của kiến trúc này là mỗi bước đều có thể audit độc lập — khi một số liệu ở dashboard trông sai, có thể truy ngược qua từng bước để tìm đúng nguyên nhân, thay vì coi toàn bộ pipeline là một "hộp đen".

Kết luận

Số hóa dữ liệu thành công không được đo bằng việc "đã scan xong bao nhiêu tài liệu", mà bằng việc một hệ thống khác — dashboard, CRM, hay một mô hình dự báo — có thể dùng trực tiếp dữ liệu đó mà không cần ai làm sạch lại bằng tay. OCR/ICR chỉ là bước đầu; chuẩn hóa, entity resolution, và một golden record có provenance rõ ràng là phần quyết định một dự án số hóa có tạo ra giá trị lâu dài hay chỉ là một đợt chuyển file từ giấy sang máy. Đây là loại kiến trúc chúng tôi thiết kế trong lớp Data Analytics cho mỗi Pilot Build có dữ liệu đầu vào từ nhiều nguồn không đồng nhất.