Kỳ 2: Đường ống trước, động cơ sau
Năng lực dữ liệu và thiết kế kiến trúc dữ liệu cho Customer Offering
Series: Customer Offering Factory – Góc nhìn Enterprise Architecture · Kỳ 2/3
Lời dẫn: Quay lại với chiếc thẻ tín dụng của Minh
Ở Kỳ 1, chúng ta gặp Minh, người nhận được hai tin nhắn trong cùng một ngày. Ví điện tử B, với rất ít dữ liệu, đưa ra đúng offer vào đúng hai phút sau khi lương về. Ngân hàng A, nơi biết về Minh nhiều hơn hẳn, lại mời anh mở chiếc thẻ tín dụng mà anh đã dùng hai năm.
Phần chẩn đoán ở Kỳ 1 đã chỉ ra rằng khoảng cách này không đến từ giao diện hay từ việc “có AI hay không”. Khi đặt value stream “Deliver Personalized Offer” cạnh capability map, dữ liệu xuất hiện ở gần như mọi giai đoạn, và là chiều mang trọng số cao nhất trong khung đánh giá trưởng thành.
Kỳ này giải quyết một vấn đề duy nhất: năng lực dữ liệu cho Customer Offering gồm những gì, và kiến trúc dữ liệu cần được thiết kế thế nào để nuôi được nhà máy offer. Nếu ví AI là động cơ, thì dữ liệu là nhiên liệu và kiến trúc dữ liệu là đường ống. Kỳ này nói về đường ống.
Nội dung đi theo hai phần. Phần 1 xác định năng lực: vì sao dữ liệu quyết định chất lượng offer, bản đồ năng lực dữ liệu, mô hình dữ liệu offer và các data domain. Phần 2 thiết kế kiến trúc: nguyên tắc, ba tầng độ trễ, kiến trúc tham chiếu tám lớp, các mẫu thiết kế, governance và chỉ số đo lường.
1. Năng lực dữ liệu cho Customer Offering
1.1. Vì sao dữ liệu là năng lực quyết định
Có thể diễn đạt chất lượng của một offer bằng một công thức trực quan gồm bốn thừa số:
Chất lượng offer = Độ chính xác định danh × Độ đầy đủ hồ sơ × Độ tươi của dữ liệu × Quyền sử dụng (consent)
Vì là phép nhân, chỉ cần một thừa số bằng không thì cả offer hỏng, bất kể mô hình AI tinh vi đến đâu. Mỗi thừa số tương ứng với một kiểu thất bại quen thuộc:
-
Sai định danh: hệ thống không biết khách đã có sản phẩm, nên mời mở lại đúng sản phẩm đó. Đây chính là trường hợp chiếc thẻ tín dụng của Minh.
-
Thiếu hồ sơ: mô hình không thấy khoản vay của khách ở công ty con, nên đề xuất hạn mức vượt khả năng trả nợ.
-
Dữ liệu cũ: offer gửi tiết kiệm đến sau khi khách đã chuyển tiền đi nơi khác.
-
Thiếu quyền sử dụng: dữ liệu có sẵn nhưng dùng cho mục đích tiếp thị mà khách chưa đồng ý, tạo rủi ro pháp lý và rủi ro uy tín.
Còn một kiểu thất bại thứ năm ít được nhắc đến: không có trí nhớ về offer. Khách đã từ chối một offer ba lần nhưng vẫn tiếp tục nhận nó, vì không hệ thống nào lưu lại phản ứng đó.
1.2. Bản đồ năng lực dữ liệu
Bảng dưới đây phân rã năng lực dữ liệu phục vụ Customer Offering. Đây chính là “dải năng lực dữ liệu hỗ trợ” trong ma trận ở Kỳ 1 mục 4.4: chúng nằm ở tầng hỗ trợ, không đứng ngang hàng với chín năng lực L2 của Customer Offering, nhưng năng lực L2 nào cũng cần đến chúng. Mỗi năng lực được gắn với câu hỏi nghiệp vụ nó giúp trả lời, giúp đối thoại với lãnh đạo kinh doanh bằng ngôn ngữ của họ thay vì ngôn ngữ công nghệ, và với năng lực L2 mà nó phục vụ.
| Năng lực dữ liệu | Câu hỏi trả lời | Nội dung chính | Phục vụ chủ yếu năng lực L2 |
|---|---|---|---|
| Data Acquisition & Integration | Ta có những tín hiệu gì? | Thu nhận dữ liệu từ nguồn nội bộ, hạ tầng quốc gia, hệ sinh thái, Open API; theo batch, CDC, streaming và API | Customer Insight & Need Sensing |
| Customer Identity Resolution & MDM | Đây là ai? | Hợp nhất nhiều mã khách hàng thành một thực thể duy nhất, quản lý golden record | Customer Insight; Eligibility & Risk; Offer Decisioning |
| Customer 360 / Unified Profile | Khách là người như thế nào? | Hồ sơ hợp nhất gồm thông tin định danh, quan hệ sản phẩm, hành vi, khả năng tài chính | Customer Insight; Offer Decisioning |
| Real-time Event Processing | Điều gì vừa xảy ra? | Phát hiện sự kiện giao dịch và sự kiện đời sống theo thời gian thực | Customer Insight & Need Sensing |
| Feature Engineering & Management | Tín hiệu nào có giá trị dự báo? | Tạo, đăng ký, tái sử dụng đặc trưng cho mô hình; đảm bảo nhất quán giữa huấn luyện và vận hành | Eligibility & Risk; Offer Pricing; Offer Decisioning |
| Offer & Interaction History | Ta đã nói gì với khách, và khách phản ứng ra sao? | Lưu toàn bộ vòng đời offer và tương tác trên mọi kênh | Offer Decisioning; Offer Performance & Learning; Offer Governance |
| Consent & Privacy Management | Ta có được phép không? | Quản lý sự đồng ý theo mục đích, kiểm tra tự động trước khi sử dụng dữ liệu | Offer Decisioning; Offer Delivery & Engagement; Offer Governance |
| Data Quality & Observability | Dữ liệu có đáng tin không? | Giám sát độ đầy đủ, chính xác, độ tươi, phát hiện bất thường và drift | Tất cả |
| Metadata, Lineage & Catalog | Vì sao hệ thống đưa ra offer này? | Danh mục dữ liệu, truy vết nguồn gốc đến tận quyết định | Offer Governance |
| Data Sharing & Ecosystem Exchange | Mở rộng dữ liệu bằng cách nào? | Chia sẻ dữ liệu an toàn với đối tác, công ty trong tập đoàn, qua Open API | Customer Insight; Eligibility & Risk |
| Knowledge Management cho GenAI | AI tư vấn dựa trên tri thức nào? | Điều khoản sản phẩm, chính sách, câu hỏi thường gặp được cấu trúc hóa và quản lý phiên bản | Offer Design & Configuration; Offer Delivery & Engagement |
1.3. Offer Data phải là thực thể hạng nhất
Đây là khoảng trống phổ biến và đáng tiếc nhất. Hầu hết tổ chức lưu trữ rất kỹ dữ liệu sản phẩm và giao dịch, nhưng rất ít tổ chức lưu offer như một thực thể có vòng đời riêng. Offer thường chỉ tồn tại thoáng qua trong một file danh sách chiến dịch, hoặc nằm rải rác trong log của từng kênh.
Một Offer Data Model đầy đủ cần ghi nhận các trạng thái trong vòng đời:
| Trạng thái | Ý nghĩa | Dữ liệu cần ghi |
|---|---|---|
| Generated | Offer được tạo cho khách | Khách hàng, offer, phiên bản khuôn khổ, thời điểm, sự kiện kích hoạt |
| Eligible | Khách đủ điều kiện | Kết quả kiểm tra điều kiện, điểm tín dụng, hạn mức, giá đề xuất |
| Selected | Được chọn là offer tốt nhất | Điểm xếp hạng, các offer cạnh tranh bị loại, phiên bản mô hình và rule |
| Presented | Đã hiển thị cho khách | Kênh, vị trí, nội dung, thời điểm |
| Viewed / Engaged | Khách đã xem hoặc tương tác | Hành vi tương tác, thời gian xem |
| Accepted / Declined / Ignored | Phản ứng của khách | Lựa chọn, lý do từ chối nếu có |
| Converted | Offer trở thành sản phẩm đang hoạt động | Mã hợp đồng, giá trị thực tế |
| Outcome | Kết quả sau chuyển đổi | Hành vi trả nợ, mức sử dụng, giá trị vòng đời, khiếu nại |
Lịch sử offer mang lại năm giá trị. Thứ nhất, nó là nguồn nhãn để huấn luyện mô hình: không có dữ liệu “ai đã từ chối” thì không thể dạy mô hình dự đoán ai sẽ chấp nhận. Thứ hai, nó cho phép kiểm soát tần suất, tránh spam offer. Thứ ba, nó là nền tảng để đo uplift thực sự. Thứ tư, nó là bằng chứng giải trình với khách hàng và cơ quan quản lý về lý do một quyết định được đưa ra. Thứ năm, nó đóng vòng học của Offering Factory.
Khuyến nghị: nếu chỉ được làm một việc về dữ liệu trong năm đầu, hãy bắt đầu ghi lại lịch sử offer một cách có cấu trúc. Chi phí thấp, nhưng giá trị tích lũy theo thời gian và không thể làm bù sau này.
1.4. Các Data Domain chính
Áp dụng tư duy domain-driven, dữ liệu cho Customer Offering được tổ chức thành các domain có chủ sở hữu rõ ràng. Cần phân biệt hai khái niệm. Chủ sở hữu của một domain là một đơn vị tổ chức, cụ thể là Data Owner ở mục 2.7. Service domain BIAN cho biết thành phần nào giữ bản gốc của dữ liệu (system of record). Bảng dưới đây ghi service domain chịu trách nhiệm chính cho từng domain:
| Data Domain | Nội dung | Service Domain giữ bản gốc (BIAN) |
|---|---|---|
| Party / Customer | Định danh, thông tin nhân khẩu, quan hệ giữa các bên | Party Reference Data Directory |
| Product | Danh mục sản phẩm, linh kiện, tham số, khuôn khổ offer | Product Directory, Product Design |
| Offer | Vòng đời offer như mục 1.3 | Customer Offer, Product Matching |
| Interaction / Event | Sự kiện trên kênh số, tổng đài, chi nhánh | Customer Event History, Customer Behavioral Insights |
| Transaction | Giao dịch tài khoản, thẻ, thanh toán | Các service domain sản phẩm (Current Account, Card…) |
| Risk & Credit | Điểm tín dụng, hạn mức, dữ liệu CIC | Customer Credit Rating, Underwriting |
| Consent | Sự đồng ý theo mục đích và kênh, thời hạn | Customer Agreement, Regulatory Compliance |
| Channel | Kênh, thiết bị, tùy chọn liên lạc | Customer Access Entitlement, Contact Handler |
| Campaign | Chiến dịch, khuôn khổ, nhóm đối chứng | Customer Campaign Design, Customer Campaign Management |
| Outcome / Feedback | Kết quả sau chuyển đổi, khiếu nại, đánh giá | Customer Behavioral Insights |
Trong ArchiMate, các domain này được thể hiện qua Business Object ở tầng nghiệp vụ và Data Object ở tầng ứng dụng. Mối quan hệ cốt lõi cần mô hình hóa rõ là: Customer nhận Offer, Offer được tạo từ Product, Offer được kích hoạt bởi Event, Offer bị ràng buộc bởi Consent, và Offer dẫn đến Outcome.
1.5. Dữ liệu cần có ở từng giai đoạn của value stream
Không phải giai đoạn nào cũng cần dữ liệu thời gian thực. Việc xác định đúng yêu cầu về độ trễ và chất lượng cho từng giai đoạn giúp tránh đầu tư thừa:
| Giai đoạn | Dữ liệu đầu vào | Data product cần có | Độ trễ | Yêu cầu chất lượng |
|---|---|---|---|---|
| Sense | Sự kiện giao dịch, sự kiện ứng dụng | Event stream đã chuẩn hóa | Giây | Đầy đủ, đúng thứ tự, gắn đúng khách |
| Understand | Hồ sơ, quan hệ sản phẩm, hành vi | Unified Customer Profile | Giây đến phút | Định danh chính xác, độ phủ cao |
| Design | Hiệu quả offer lịch sử, dữ liệu thị trường | Offer analytics mart | Ngày | Nhất quán, có lịch sử |
| Decide | Hồ sơ, feature, điều kiện, CIC, consent | Online feature store, Consent registry | Dưới vài trăm mili giây | Nhất quán với dữ liệu huấn luyện |
| Engage | Tùy chọn kênh, lịch sử liên lạc | Contact history, Channel preference | Giây | Cập nhật xuyên kênh |
| Fulfil | Dữ liệu định danh, thông tin đã có | Pre-fill data service | Giây | Chính xác, đã xác thực |
| Learn | Offer history, outcome | Offer history store, training dataset | Ngày | Đầy đủ, có nhãn, có nhóm đối chứng |
2. Thiết kế Kiến trúc dữ liệu cho Customer Offering
2.1. Nguyên tắc kiến trúc
Theo TOGAF, nguyên tắc kiến trúc là nền tảng để ra các quyết định thiết kế nhất quán. Mỗi nguyên tắc có bốn phần: tên, phát biểu, lý do (lợi ích kinh doanh khi tuân thủ) và hệ quả. Bảy nguyên tắc sau được đề xuất cho kiến trúc dữ liệu phục vụ Customer Offering:
| Nguyên tắc | Phát biểu | Lý do | Hệ quả thiết kế |
|---|---|---|---|
| Độ trễ theo use case | Không “real-time hóa” mọi thứ; mỗi use case chọn tầng độ trễ phù hợp | Chi phí và độ phức tạp tăng rất nhanh ở mỗi tầng; chỉ trả cho tầng mà giá trị của offer thực sự đòi hỏi | Thiết kế ba tầng: batch, near real-time, real-time; tính chi phí cho từng tầng |
| Dữ liệu là sản phẩm | Mỗi domain sở hữu và cam kết chất lượng cho data product của mình | Dữ liệu chỉ tạo giá trị khi có người chịu trách nhiệm về chất lượng và cam kết với bên dùng | Có data product owner, data contract, SLA |
| Một nguồn sự thật cho quyết định | Mọi kênh dùng chung hồ sơ khách hàng và logic quyết định | Một bản dùng chung rẻ hơn và đúng hơn nhiều bản riêng theo kênh; khách không nhận offer mâu thuẫn | Không cho phép kênh tự xây hồ sơ riêng hoặc rule riêng |
| Privacy-by-design | Consent là dữ liệu có cấu trúc, được kiểm tra tự động | Vi phạm consent gây rủi ro pháp lý và mất niềm tin, rất khó khắc phục về sau | Consent registry là thành phần bắt buộc trên đường quyết định |
| Nhất quán huấn luyện và vận hành | Feature dùng để huấn luyện phải giống feature dùng khi ra quyết định | Lệch định nghĩa khiến mô hình tốt khi kiểm thử nhưng kém khi vận hành | Dùng chung một định nghĩa feature cho offline và online |
| Truy vết mọi quyết định | Mỗi offer truy ngược được về dữ liệu, mô hình, quy tắc đã dùng | Có bằng chứng giải trình với khách hàng và cơ quan quản lý; có nhãn để mô hình học | Decision log và lineage là yêu cầu không chức năng bắt buộc |
| Tách lớp dữ liệu khỏi core | Không để core legacy quyết định tốc độ của nhà máy offer | Vòng đời thay đổi của core tính bằng năm, của offer tính bằng ngày | Dùng CDC và event backbone để giải phóng dữ liệu khỏi core |
Các nguyên tắc có lúc kéo về hai phía, và TOGAF yêu cầu ghi rõ nguyên tắc nào được ưu tiên. Hai trường hợp hay gặp: khi chia sẻ dữ liệu giữa các pháp nhân, Privacy-by-design được ưu tiên hơn Dữ liệu là sản phẩm; khi một kênh cần độ trễ rất thấp, Một nguồn sự thật cho quyết định được ưu tiên hơn Độ trễ theo use case, nghĩa là kênh được lưu đệm dữ liệu để đọc nhưng không được giữ logic quyết định riêng.
2.2. Ba tầng độ trễ
Một trong những sai lầm đắt đỏ nhất là yêu cầu mọi thứ phải thời gian thực. Kiến trúc nên phân biệt rõ ba tầng:
| Tầng | Độ trễ | Use case điển hình | Công nghệ tiêu biểu |
|---|---|---|---|
| Batch | Giờ đến ngày (T+1) | Phân khúc, huấn luyện mô hình, báo cáo hiệu quả, chiến dịch định kỳ | Lakehouse, ETL/ELT, orchestration theo lịch |
| Near real-time | Giây đến phút | Trigger theo sự kiện: lương về, đáo hạn sổ, số dư biến động | Event streaming, stream processing, CDC |
| Real-time | Mili giây | Quyết định trong phiên: offer khi khách đang ở màn hình, phê duyệt tức thời | Online feature store, profile store độ trễ thấp, decision engine |
Nguyên tắc thực tế: bắt đầu bằng batch cho phần lớn use case, đầu tư near real-time cho các trigger có giá trị cao, và chỉ dùng real-time cho các điểm quyết định trong phiên thực sự cần. Chi phí và độ phức tạp tăng rất nhanh theo từng tầng.
2.3. Kiến trúc tham chiếu logic
Kiến trúc tham chiếu gồm tám lớp xếp theo dòng chảy của dữ liệu, cùng với các lớp xuyên suốt. Đây là kiến trúc logic, độc lập với công nghệ cụ thể, có thể hiện thực hóa trên nhiều nền tảng khác nhau. Tuy được gọi là kiến trúc dữ liệu vì xoay quanh dòng chảy dữ liệu, tám lớp này trải trên cả ba domain của TOGAF: dữ liệu, ứng dụng (lớp 6 và 7) và công nghệ (lớp 2 đến 4). Bảng phân loại nằm ở mục Góc TOGAF cuối bài.
Lớp 1: Nguồn dữ liệu
Core banking, hệ thống thẻ, LOS, CRM, kênh số, tổng đài, CIC, đối tác hệ sinh thái và Open API. Kiến trúc dữ liệu không thay thế các hệ thống này mà kết nối chúng.
Lớp 2: Thu nhận (Ingestion)
Bốn phương thức song song: CDC (Change Data Capture) đọc thay đổi từ cơ sở dữ liệu của core mà không làm tăng tải hay sửa code core; streaming cho sự kiện từ kênh số; batch cho nguồn chưa hỗ trợ thời gian thực; và API cho dữ liệu từ đối tác. CDC là chìa khóa để “giải phóng” dữ liệu khỏi hệ thống legacy với rủi ro thấp nhất.
Lớp 3: Xương sống sự kiện (Event Backbone)
Nền tảng event streaming đóng vai trò hệ thần kinh của nhà máy offer. Mọi thay đổi quan trọng về khách hàng được phát thành sự kiện đã chuẩn hóa, để nhiều bên tiêu thụ cùng lúc: cập nhật hồ sơ, phát hiện trigger, ghi lịch sử, đẩy vào lakehouse. Cần có schema registry để quản lý cấu trúc sự kiện và tránh việc thay đổi ở nguồn làm gãy hệ thống phía sau.
Lớp 4: Lưu trữ và xử lý
Lớp này có hai đường. Hot path dùng stream processing để phát hiện sự kiện có ý nghĩa và cập nhật hồ sơ, feature theo thời gian thực. Cold path dùng Lakehouse theo kiến trúc Medallion: tầng Bronze lưu dữ liệu thô nguyên trạng, tầng Silver làm sạch, chuẩn hóa và hợp nhất định danh, tầng Gold tạo các data product sẵn sàng sử dụng như hồ sơ khách hàng, offer analytics, training dataset.
Về lựa chọn giữa kiến trúc Lambda (tách đường batch và streaming) và Kappa (mọi thứ đi qua streaming), phần lớn ngân hàng Việt Nam với nhiều hệ thống legacy chạy batch sẽ phù hợp hơn với cách tiếp cận lai: lakehouse là nền tảng chính, streaming bổ sung cho các use case cần độ trễ thấp, và cả hai cùng chia sẻ định nghĩa dữ liệu thống nhất.
Lớp 5: Data Product và phục vụ (Serving)
Đây là lớp tạo ra giá trị trực tiếp cho Customer Offering, gồm các thành phần:
-
Real-time Customer Profile Store: hồ sơ khách hàng hợp nhất, truy vấn được với độ trễ thấp.
-
Feature Store: kho đặc trưng có phần offline phục vụ huấn luyện và phần online phục vụ suy luận, dùng chung định nghĩa.
-
Offer History Store: lưu toàn bộ vòng đời offer theo mô hình ở mục 1.3.
-
Consent Registry: sổ đăng ký sự đồng ý, trả lời được câu hỏi “khách X có cho phép dùng dữ liệu Y cho mục đích Z qua kênh W không” trong vài mili giây.
-
Knowledge Base và Vector Store: tri thức sản phẩm, điều khoản, chính sách đã được chia nhỏ và nhúng vector, phục vụ các ứng dụng GenAI theo kiến trúc RAG.
-
Semantic Layer: định nghĩa thống nhất các chỉ số kinh doanh cho phân tích và báo cáo.
Lớp 6: Quyết định và AI
Decision engine, nơi chạy mô hình (model serving), quy tắc nghiệp vụ và các AI agent. Lớp này đọc dữ liệu từ lớp 5, và quan trọng không kém, ghi ngược decision log về lớp 5 để phục vụ truy vết và học.
Lớp 7: Kích hoạt (Activation)
Đẩy offer ra các kênh qua API, sự kiện, hoặc reverse ETL vào công cụ của kênh. Lớp này đảm bảo một offer được điều phối thống nhất trên mọi kênh.
Lớp 8: Vòng phản hồi (Feedback Loop)
Phản ứng của khách hàng trên kênh được phát thành sự kiện, đi vào event backbone, cập nhật offer history, rồi trở thành dữ liệu huấn luyện. Lớp này biến kiến trúc từ một đường thẳng thành một vòng tròn.
Các lớp xuyên suốt
Data governance, metadata và lineage, thực thi consent, bảo mật (mã hóa, token hóa, che giấu dữ liệu nhạy cảm), và data observability. Đây không phải là “thêm vào sau” mà phải được thiết kế từ đầu, vì chúng quyết định việc kiến trúc có được phép vận hành trong môi trường ngân hàng hay không.
2.4. Các mẫu thiết kế trọng yếu
Identity Resolution
Kết hợp so khớp xác định (deterministic) dựa trên khóa mạnh như số CCCD, số điện thoại đã xác thực, với so khớp xác suất (probabilistic) dựa trên tên, ngày sinh, địa chỉ cho dữ liệu cũ. Kết quả là một golden record với mã khách hàng thống nhất, kèm quy tắc xử lý xung đột khi các nguồn mâu thuẫn. Việc chuyển đổi từ CMND sang CCCD gắn chip là cơ hội lớn để làm sạch định danh trên toàn bộ tệp khách hàng.
Event-driven Customer Profile
Thay vì tính lại toàn bộ hồ sơ mỗi đêm, hồ sơ được cập nhật từng phần khi có sự kiện. Kết hợp với một lần tính lại định kỳ để đối soát và sửa sai lệch.
Feature Store và point-in-time correctness
Khi huấn luyện, mỗi feature phải được lấy đúng giá trị tại thời điểm offer được đưa ra trong quá khứ, không được “nhìn thấy tương lai”. Đây là lỗi tinh vi nhưng phổ biến, khiến mô hình rất tốt khi kiểm thử nhưng kém khi vận hành.
Decision Logging
Mỗi quyết định ghi lại đầy đủ: dữ liệu đầu vào, giá trị feature, phiên bản mô hình, các quy tắc đã áp dụng, các offer bị loại và lý do, kết quả cuối cùng. Đây là nền tảng cho explainability và kiểm toán.
Consent-aware Data Access
Kiểm soát truy cập dựa trên mục đích sử dụng (purpose-based access control): cùng một dữ liệu có thể được phép dùng cho thẩm định tín dụng nhưng không được phép dùng cho tiếp thị. Kiểm tra consent phải nằm trên đường đi của quyết định, không phải kiểm tra thủ công sau.
Privacy-enhancing Technologies
Bí danh hóa (pseudonymization) cho môi trường phân tích; dữ liệu tổng hợp (synthetic data) cho phát triển và thử nghiệm; và data clean room khi hợp tác dữ liệu với đối tác hệ sinh thái, cho phép hai bên cùng phân tích mà không trao đổi dữ liệu cá nhân thô.
Data Contracts
Cam kết chính thức giữa bên tạo dữ liệu và bên sử dụng về cấu trúc, ý nghĩa, chất lượng và SLA. Data contract ngăn tình trạng một thay đổi nhỏ ở hệ thống nguồn làm hỏng mô hình AI mà không ai biết.
2.5. Kiến trúc dữ liệu cho AI và GenAI
-
Quản lý dữ liệu huấn luyện: dataset có phiên bản, nhãn lấy từ offer outcome, nhóm đối chứng được thiết kế từ đầu.
-
Tri thức cho RAG: mỗi tài liệu điều khoản, chính sách phải có chủ sở hữu, phiên bản và ngày hiệu lực. Nếu không, AI sẽ tư vấn theo điều khoản đã hết hạn, một rủi ro tuân thủ nghiêm trọng.
-
Lineage cho explainability: truy vết từ offer về feature, từ feature về nguồn dữ liệu, phục vụ giải thích cho khách hàng và giải trình với cơ quan quản lý.
-
Giám sát drift: phát hiện khi phân bố dữ liệu đầu vào hoặc hành vi khách hàng thay đổi khiến mô hình lỗi thời.
2.6. Lựa chọn kiến trúc theo loại tổ chức
| Loại tổ chức | Điểm xuất phát | Chiến lược kiến trúc phù hợp | Thách thức chính |
|---|---|---|---|
| Ngân hàng có legacy lớn | Nhiều hệ thống, dữ liệu batch, nhiều mã khách hàng | “Bọc và giải phóng”: CDC, event backbone, lớp data product; không thay core | Định danh, tốc độ, quản trị thay đổi |
| Fintech, ngân hàng số | Kiến trúc event-native, dữ liệu hành vi phong phú | Mở rộng nguồn dữ liệu, chuẩn hóa governance khi quy mô tăng | Độ phủ dữ liệu tài chính, tuân thủ |
| Công ty tài chính thuộc tập đoàn | Có dữ liệu hệ sinh thái tiềm năng | Data sharing có kiểm soát, clean room giữa các pháp nhân | Cơ sở pháp lý cho chia sẻ dữ liệu |
Về câu hỏi tự xây hay mua: Customer Data Platform (CDP) thương mại giúp triển khai nhanh cho phần kích hoạt kênh, nhưng ít khi đáp ứng đủ yêu cầu về dữ liệu tài chính, tín dụng và consent của ngân hàng. Cách tiếp cận phổ biến là tự xây lõi Customer 360 và feature store trên nền tảng dữ liệu của tổ chức, mua các thành phần mang tính hàng hóa như event streaming, data quality, catalog.
Với ngân hàng có legacy, chiến lược “bọc và giải phóng” cũng đòi hỏi trả lời rõ: thành phần hiện có nào được giữ, thành phần nào bị thay, và phải xây mới những gì. TOGAF gọi đây là phân tích khoảng cách (gap analysis). Một phiên bản rút gọn:
| Hiện trạng | Mục tiêu | Kết luận |
|---|---|---|
| Mỗi hệ thống một mã khách hàng | Golden record trong Customer MDM | Mã riêng không còn dùng làm khóa chung. Mã nguồn vẫn tồn tại và được MDM tham chiếu chéo |
| Kho dữ liệu T+1 | Lakehouse (cold path) | Cần quyết định: hợp nhất dần, hay giữ song song cho báo cáo theo quy định. Khuyến nghị: giữ song song trong TA1–TA2, đánh giá lại ở TA3; hồ sơ khách hàng chuyển sang profile store |
| Công cụ chiến dịch và file danh sách | Decisioning tập trung và lớp kích hoạt | File danh sách bị loại. Cần quyết định: công cụ chiến dịch chỉ còn thực thi trên kênh, hay bị loại. Khuyến nghị: giữ chức năng quản lý chiến dịch và nhóm đối chứng; danh sách khách hàng do decisioning tạo |
| CRM | Customer MDM, lịch sử liên lạc | Cần quyết định: phạm vi của CRM sau khi có hồ sơ hợp nhất. Khuyến nghị: Contact chuyển về Customer MDM; Lead trở thành khách hàng tiềm năng trong MDM |
| Consent trên giấy hoặc PDF | Consent registry | Thay thế, sau khi số hóa và đánh giá hiệu lực pháp lý của consent cũ |
| Chưa có | Lịch sử offer, feature store, decision log, event backbone | Khoảng trống cần xây hoặc mua |
Các ô “cần quyết định” thường là nơi dự án bị kéo dài nhất, vì chúng chạm đến hệ thống và đơn vị đang vận hành. Nên đưa chúng ra Hội đồng kiến trúc ngay từ đầu thay vì để đến khi triển khai.
2.7. Data Governance cho Customer Offering
-
Vai trò: Data Owner theo từng domain chịu trách nhiệm về chất lượng và quyền truy cập; Data Steward thực thi hằng ngày; Data Product Owner chịu trách nhiệm về giá trị của data product; và đặc biệt là Offer Data Owner cho domain offer, vai trò thường bị bỏ sót.
-
Chính sách: phân loại dữ liệu bao gồm dữ liệu cá nhân nhạy cảm, thời hạn lưu trữ, quy tắc chia sẻ giữa các pháp nhân và xuyên biên giới.
-
Vai trò của EA và ARB: mọi giải pháp mới liên quan đến offer cần thể hiện trong tài liệu kiến trúc (SAD) cách sử dụng data product chung, cách ghi decision log và cách kiểm tra consent. ARB rà soát để ngăn việc mỗi dự án tự xây kho dữ liệu riêng. Trong TOGAF, những cam kết này được ghi thành Architecture Contract giữa nhóm kiến trúc và dự án (xem Kỳ 3 mục 3.4).
2.8. Chỉ số đo năng lực dữ liệu
| Chỉ số | Ý nghĩa |
|---|---|
| Identity match rate | Tỷ lệ bản ghi khách hàng được hợp nhất về một định danh duy nhất |
| Profile completeness | Tỷ lệ thuộc tính quan trọng có giá trị trong hồ sơ khách hàng |
| Data freshness SLA | Tỷ lệ data product đạt cam kết độ tươi theo từng tầng độ trễ |
| Feature reuse rate | Tỷ lệ feature được dùng bởi từ hai mô hình trở lên |
| Time-to-new-feature | Thời gian từ khi có yêu cầu đến khi feature mới sẵn sàng cho vận hành |
| Decision log coverage | Tỷ lệ offer có decision log đầy đủ |
| Consent coverage | Tỷ lệ khách hàng mục tiêu có consent hợp lệ cho mục đích tiếp thị |
2.9. Anti-patterns về dữ liệu
-
Customer 360 kiểu big-bang: dự án kéo dài nhiều năm, cố gắng hợp nhất mọi thứ, nhưng chưa phục vụ được offer nào. Nên làm theo hướng use case dẫn dắt, mỗi giai đoạn có giá trị cụ thể.
-
Data lake thành data swamp: đổ vào rất nhiều nhưng không ai lấy ra dùng được vì thiếu catalog, chất lượng và chủ sở hữu.
-
Feature riêng cho từng mô hình: mỗi đội tự xây feature, cùng một khái niệm có năm định nghĩa khác nhau.
-
Không lưu lịch sử offer: AI không có nhãn để học, tổ chức không có bằng chứng để giải trình.
-
Consent lưu dạng văn bản: không thể kiểm tra tự động khi ra quyết định, dẫn đến hoặc vi phạm hoặc không dám dùng dữ liệu.
-
Real-time hóa mọi thứ: chi phí hạ tầng tăng vọt trong khi phần lớn use case chỉ cần T+1.
Gợi mở cho Kỳ 3: Đường ống đã thông, động cơ ở đâu?
Đến đây, nền móng đã được đặt. Chúng ta có một bản đồ năng lực dữ liệu trả lời được những câu hỏi nghiệp vụ cụ thể, một mô hình dữ liệu offer biến mỗi lần tương tác thành bài học, và một kiến trúc tham chiếu tám lớp cho phép dữ liệu chảy từ core legacy đến điểm quyết định với độ trễ phù hợp, có consent và có truy vết.
Nhưng một đường ống thông suốt mà không có động cơ thì nhà máy vẫn đứng yên. Và một động cơ mạnh trong tay một tổ chức vận hành theo kiểu cũ thì cũng chỉ chạy được nửa công suất. Những câu hỏi còn lại là:
-
AI nên được đặt vào đâu trong bảy giai đoạn của nhà máy offer để tạo giá trị thực, thay vì những POC rời rạc?
-
Agentic AI có thể đảm nhận bao nhiêu phần công việc trong nhà máy offer, và đâu là giới hạn con người phải giữ lại?
-
Ranh giới giữa cá nhân hóa và thao túng hành vi nằm ở đâu, khi AI có thể “học” cách khai thác thiên kiến của khách hàng?
-
Tổ chức, quy trình phê duyệt và vai trò của EA cần thay đổi thế nào?
-
Và cuối cùng: điều kiện cần và đủ để đi đầu tại thị trường Việt Nam là gì, lộ trình ra sao?
Kỳ 3: “AI, con người và điều kiện để đi đầu” sẽ khép lại series với những câu trả lời đó.