Kỳ 1: Vì sao người biết nhiều hơn lại thua?
Chẩn đoán năng lực Customer Offering của ngân hàng và fintech dưới góc nhìn EA
Series: Customer Offering Factory – Góc nhìn Enterprise Architecture · Kỳ 1/3
Lời dẫn: Hai tin nhắn trong cùng một ngày
Sáng ngày 5, lương của Minh về tài khoản ở ngân hàng A, nơi anh đã nhận lương suốt năm năm. Như mọi tháng, Minh chuyển một phần sang ví điện tử B để chi tiêu hằng ngày. Hai phút sau, ví B gửi một thông báo: số dư nhàn rỗi của anh có thể chuyển sang tài khoản tích lũy linh hoạt, rút lúc nào cũng được; đồng thời hạn mức trả sau của anh vừa được nâng lên nhờ lịch sử thanh toán đúng hạn sáu tháng liền. Minh bấm đồng ý cả hai, mất chưa đến một phút.
Chiều cùng ngày, ngân hàng A gửi SMS mời Minh mở thẻ tín dụng với ưu đãi hoàn tiền. Minh đã có đúng chiếc thẻ đó từ hai năm trước, do chính ngân hàng A phát hành.
Nghịch lý nằm ở chỗ ngân hàng A biết về Minh nhiều hơn ví B rất nhiều. Ngân hàng biết thu nhập thực của anh, biết anh có thẻ tín dụng, biết lịch sử vay, biết anh chi tiêu ở đâu qua thẻ. Ví B chỉ thấy một phần nhỏ dòng tiền. Thế nhưng ví B đưa ra đúng offer, đúng thời điểm, còn ngân hàng A đưa ra một offer sai người.
Khoảng cách này không đến từ giao diện ứng dụng đẹp hơn, cũng không chỉ đến từ việc ví B “dùng AI” còn ngân hàng A thì không. Nó đến từ kiến trúc năng lực đứng phía sau: dữ liệu có đến được điểm ra quyết định đúng lúc hay không, có gắn được về đúng một khách hàng hay không, quyết định offer nằm ở đâu, và cần bao nhiêu vòng phê duyệt để một offer mới ra được thị trường.
Luận điểm của series: Cạnh tranh trong ngành tài chính bán lẻ đã chuyển từ “ai có sản phẩm tốt hơn” sang “ai đưa được đúng offer đến đúng người, đúng thời điểm, nhanh nhất và an toàn nhất”. Đây trước hết là một bài toán kiến trúc doanh nghiệp, và cụ thể hơn là bài toán kiến trúc dữ liệu, chứ không chỉ là bài toán marketing hay bài toán mua công cụ AI.
Series sử dụng ba lăng kính quen thuộc của Enterprise Architecture. TOGAF với cách tiếp cận lập kế hoạch dựa trên năng lực (capability-based planning) giúp trả lời câu hỏi tổ chức cần năng lực gì và đi từ hiện trạng đến mục tiêu như thế nào. BIAN cung cấp ngôn ngữ chung về các service domain trong ngân hàng, giúp tách bạch trách nhiệm và tránh trùng lặp. ArchiMate là công cụ mô hình hóa value stream, capability và mối liên hệ với ứng dụng, dữ liệu.
Trọng tâm xuyên suốt của cả series là năng lực dữ liệu. Nếu Customer Offering Factory là một nhà máy, thì dữ liệu là nguyên liệu, AI là động cơ, còn kiến trúc dữ liệu là hệ thống đường ống. Đường ống tắc thì động cơ mạnh đến đâu cũng đứng yên.
Về series này. Series gồm ba kỳ, mỗi kỳ giải quyết một câu hỏi. Kỳ 1 (bài này) chẩn đoán: mô hình cạnh tranh mới là gì, năng lực Customer Offering được định nghĩa và đo lường thế nào, và điểm nghẽn thực sự nằm ở đâu. Kỳ 2 đi sâu vào năng lực dữ liệu và thiết kế kiến trúc dữ liệu, nền móng của toàn bộ cuộc chơi. Kỳ 3 bàn về cách ứng dụng AI, thay đổi tổ chức, governance và lộ trình để đi đầu tại thị trường Việt Nam.
Câu chuyện của Minh dưới dạng một Business Scenario
TOGAF có một kỹ thuật tên là Business Scenario, dùng để mô tả một vấn đề kinh doanh thật trước khi bàn đến giải pháp. Câu chuyện của Minh có đủ năm yếu tố của kỹ thuật này, và series sẽ quay lại nó ở mọi kỳ:
| Yếu tố | Nội dung |
|---|---|
| Vấn đề | Ngân hàng biết nhiều hơn ví B nhưng đưa offer sai sản phẩm và chậm hơn nhiều |
| Môi trường | Dữ liệu chạy batch T+1; mỗi hệ thống giữ một mã khách hàng; quy tắc offer nằm riêng ở từng kênh; chiến dịch chạy theo danh sách |
| Kết quả mong muốn | Không mời khách sản phẩm họ đã có; offer đến trong vài phút sau tín hiệu; mọi offer được kiểm tra consent (chỉ tiêu cụ thể ở mục 2.5) |
| Con người tham gia | Khách hàng, người chịu trách nhiệm offer, chuyên viên rủi ro, bộ phận bảo vệ dữ liệu, nhân viên tư vấn |
| Hệ thống tham gia | Core banking, hệ thống thẻ, CRM, công cụ chiến dịch, ứng dụng di động; trong tương lai thêm decision engine và consent registry |
1. Bối cảnh thị trường Việt Nam
1.1. Khách hàng đã thay đổi kỳ vọng
Thế hệ khách hàng trẻ tại Việt Nam lớn lên cùng trải nghiệm của các nền tảng thương mại điện tử và gọi xe. Ở đó, mọi gợi ý đều mang tính cá nhân, mọi giao dịch hoàn tất trong vài chạm, và nền tảng “nhớ” khách hàng ở mọi lần quay lại. Khi bước sang dịch vụ tài chính, họ mang theo đúng kỳ vọng đó: không muốn điền lại thông tin đã cung cấp, không muốn nhận lời mời cho sản phẩm không liên quan, và muốn được phục vụ ngay tại thời điểm phát sinh nhu cầu.
Nhu cầu tài chính lại có tính thời điểm rất cao. Nhu cầu vay mua xe xuất hiện khi khách đang tìm hiểu giá xe, không phải ba tháng sau. Nhu cầu gửi tiết kiệm mạnh nhất ngay sau ngày nhận lương hoặc nhận thưởng. Nhu cầu bảo hiểm du lịch xuất hiện lúc khách vừa đặt vé máy bay. Offer đến muộn vài ngày thường đã mất giá trị, vì khách đã được một bên khác phục vụ.
1.2. Cấu trúc cạnh tranh nhiều tầng
Thị trường tài chính bán lẻ Việt Nam hiện có ít nhất năm nhóm người chơi cùng tranh giành một khách hàng: ngân hàng quốc doanh với tệp khách hàng và nguồn vốn lớn; ngân hàng thương mại cổ phần đi đầu chuyển đổi số; công ty tài chính tiêu dùng với kinh nghiệm thẩm định nhanh phân khúc khó; ví điện tử và fintech nắm điểm chạm giao dịch hằng ngày; và các ngân hàng số thuần túy được xây dựng trên nền công nghệ mới. Ranh giới giữa các nhóm ngày càng mờ đi khi ngân hàng hợp tác với hệ sinh thái, còn fintech mở rộng sang tín dụng, tiết kiệm và bảo hiểm thông qua đối tác.
Trong cấu trúc này, lợi thế không còn nằm ở việc ai sở hữu sản phẩm. Phần lớn sản phẩm tài chính bán lẻ có thể sao chép trong vài tháng. Lợi thế nằm ở việc ai sở hữu điểm chạm, ai hiểu khách hàng sâu và nhanh hơn, và ai có thể biến hiểu biết đó thành offer với chu kỳ ngắn nhất.
1.3. Khung pháp lý: vừa mở cửa, vừa đặt rào chắn
Môi trường pháp lý tại Việt Nam đang thay đổi theo hướng vừa tạo cơ hội vừa siết trách nhiệm đối với dữ liệu và công nghệ:
-
Bảo vệ dữ liệu cá nhân: Luật Bảo vệ dữ liệu cá nhân số 91/2025/QH15, có hiệu lực từ 01/01/2026 (kế thừa và thay thế phần lớn Nghị định 13/2023/NĐ-CP).
-
Open API trong ngân hàng: Thông tư 64/2024/TT-NHNN, có hiệu lực từ 01/03/2025, quy định danh mục Open API cơ bản, yêu cầu kỹ thuật, an toàn thông tin và trách nhiệm của ngân hàng và bên thứ ba.
-
Cơ chế thử nghiệm có kiểm soát (sandbox): Nghị định 94/2025/NĐ-CP, có hiệu lực từ 01/07/2025.
-
Định danh số và Đề án 06: CCCD gắn chip, VNeID và yêu cầu xác thực sinh trắc học cho giao dịch giá trị lớn giúp chuẩn hóa định danh khách hàng ở quy mô quốc gia.
-
Hạ tầng thông tin tín dụng: CIC và các tổ chức thông tin tín dụng là nguồn dữ liệu quan trọng cho quyết định cấp tín dụng.
1.4. Bản đồ nguồn dữ liệu cho Customer Offering tại Việt Nam
Một điểm đặc thù của Việt Nam là nguồn dữ liệu đang mở rộng nhanh, nhưng phân tán và có mức độ “được phép sử dụng” rất khác nhau. Có thể chia thành bốn nhóm:
| Nhóm nguồn | Ví dụ | Giá trị cho offer | Lưu ý kiến trúc và pháp lý |
|---|---|---|---|
| Nội bộ | Core banking, thẻ, hệ thống khởi tạo khoản vay (LOS), CRM, app/web, tổng đài | Thu nhập, dòng tiền, quan hệ sản phẩm, hành vi sử dụng kênh | Phân tán theo hệ thống, nhiều mã khách hàng, thường chỉ có dạng batch |
| Hạ tầng quốc gia | CIC, dữ liệu dân cư qua Đề án 06, CCCD gắn chip, NAPAS/VietQR | Định danh chuẩn, lịch sử tín dụng toàn ngành | Phạm vi sử dụng bị giới hạn theo mục đích, phải tuân thủ chặt về consent |
| Hệ sinh thái | Thương mại điện tử, viễn thông, tiện ích, bán lẻ, công ty trong cùng tập đoàn | Tín hiệu nhu cầu sớm, dữ liệu thay thế cho người chưa có lịch sử tín dụng | Chia sẻ dữ liệu giữa các pháp nhân cần cơ sở pháp lý và kỹ thuật bảo vệ quyền riêng tư |
| Open API | Dữ liệu tài khoản, giao dịch từ tổ chức khác khi khách hàng đồng ý | Bức tranh tài chính đầy đủ hơn, offer chính xác hơn | Phụ thuộc vào mức độ sẵn sàng của thị trường, cần quản lý consent theo thời gian thực |
1.5. Nghịch lý dữ liệu
Nhiều ngân hàng Việt Nam đang sở hữu khối dữ liệu khách hàng lớn hơn hẳn các fintech, nhưng thời gian để đưa một offer mới ra thị trường vẫn được tính bằng tháng, và offer vẫn thường sai người. Nguyên nhân thường nằm ở ba điểm: dữ liệu không đến được điểm ra quyết định đúng lúc vì phụ thuộc vào batch cuối ngày; dữ liệu không gắn được về đúng một khách hàng vì mỗi hệ thống giữ một mã riêng; và dữ liệu không được phép sử dụng vì thiếu cơ chế quản lý consent đủ chi tiết. Nói cách khác, vấn đề không phải là khối lượng dữ liệu mà là khả năng vận hành dữ liệu.
2. Từ mô hình cũ sang “Customer Offering Factory”
2.1. Mô hình cũ: đẩy sản phẩm theo chiến dịch
Trong mô hình truyền thống, sản phẩm được thiết kế theo từng khối nghiệp vụ (thẻ, cho vay, huy động) và được tham số hóa cứng trong core banking hoặc hệ thống chuyên biệt. Khi muốn thay đổi một điều kiện ưu đãi, đội sản phẩm phải đi qua chuỗi phê duyệt tuần tự gồm Rủi ro, Pháp chế, Tuân thủ, CNTT, rồi mới đến Marketing. Một chiến dịch thường được chạy theo batch: lọc danh sách khách hàng theo vài tiêu chí thô như độ tuổi, thu nhập, khu vực, rồi gửi hàng loạt qua SMS, email hoặc chuyển cho đội bán hàng.
Mô hình này có bốn điểm yếu cấu trúc. Thứ nhất, tốc độ chậm: từ ý tưởng đến khi offer chạm khách hàng mất từ vài tuần đến vài tháng. Thứ hai, cá nhân hóa thấp: phân khúc được định nghĩa từ trước, không phản ánh tình huống hiện tại của khách. Thứ ba, logic quyết định phân tán: mỗi kênh có quy tắc riêng, dẫn đến việc khách nhận các offer mâu thuẫn nhau. Thứ tư, không có vòng học: offer được “bắn” ra nhưng phản hồi của khách hiếm khi được ghi nhận có hệ thống để cải thiện lần sau.
2.2. Mô hình mới: Customer Offering Factory
Customer Offering Factory là cách nhìn hoạt động tạo và phân phối offer như một dây chuyền sản xuất liên tục, có tiêu chuẩn hóa, có kiểm định chất lượng và có cải tiến. Hình ảnh nhà máy giúp làm rõ năm thành phần:
-
Nguyên liệu: dữ liệu khách hàng đã được hợp nhất, làm sạch và sẵn sàng sử dụng; cùng với các “linh kiện sản phẩm” (product building blocks) như mức giá, hạn mức, kỳ hạn, ưu đãi, điều kiện đủ.
-
Dây chuyền: decisioning engine tập trung, nơi kết hợp dữ liệu, mô hình AI và quy tắc nghiệp vụ để quyết định offer nào, cho ai, khi nào.
-
Kiểm định chất lượng: các guardrail về rủi ro, giá, tuân thủ được nhúng sẵn vào dây chuyền, thay vì phê duyệt thủ công từng offer.
-
Phân phối: offer được đẩy ra đúng kênh khách hàng đang hiện diện, theo thời gian thực hoặc gần thời gian thực.
-
Cải tiến liên tục: mọi phản ứng của khách được ghi nhận, quay về huấn luyện lại mô hình và điều chỉnh chiến lược.
Điểm khác biệt căn bản là đơn vị thiết kế không còn là “một sản phẩm cho một phân khúc” mà là “một offer cho một khách hàng trong một ngữ cảnh”. Mục tiêu dài hạn là cá nhân hóa ở mức từng người (segment of one), được kích hoạt bởi sự kiện (event-driven) chứ không chỉ theo lịch chiến dịch.
2.3. So sánh hai mô hình
| Chiều so sánh | Mô hình cũ | Customer Offering Factory |
|---|---|---|
| Đơn vị thiết kế | Sản phẩm cố định theo phân khúc | Offer lắp ghép từ building blocks theo ngữ cảnh |
| Dữ liệu | Rời rạc theo hệ thống, cập nhật cuối ngày | Hợp nhất theo khách hàng, cập nhật theo sự kiện |
| Tốc độ ra thị trường | Vài tuần đến vài tháng | Vài ngày, thậm chí vài giờ cho biến thể trong khuôn khổ đã duyệt |
| Mức cá nhân hóa | Phân khúc thô | Từng khách hàng, từng thời điểm |
| Điểm ra quyết định | Phân tán ở từng kênh | Decisioning tập trung, dùng chung cho mọi kênh |
| Kiểm soát rủi ro | Phê duyệt thủ công từng chiến dịch | Guardrail nhúng sẵn, phê duyệt theo khuôn khổ |
| Đo lường | Tỷ lệ phản hồi chiến dịch | Uplift, giá trị vòng đời, chất lượng danh mục sau offer |
| Vòng học | Gần như không có | Liên tục, tự động hóa một phần |
2.4. Vì sao sự dịch chuyển xảy ra lúc này
Có ba lực đẩy hội tụ. Về công nghệ, chi phí xử lý dữ liệu thời gian thực và triển khai mô hình máy học đã giảm mạnh, trong khi các mô hình ngôn ngữ lớn mở ra khả năng tự động hóa phần nội dung và tư vấn. Về thị trường, các fintech đã chứng minh rằng tốc độ và độ chính xác của offer là yếu tố quyết định tỷ lệ chuyển đổi. Về pháp lý, hạ tầng định danh số và Open API đang dần hoàn thiện, cho phép tiếp cận dữ liệu rộng hơn nhưng cũng đòi hỏi quản trị chặt hơn. Tổ chức nào xây dựng nền tảng sớm sẽ tích lũy được lợi thế về dữ liệu và vòng học mà đối thủ đi sau rất khó đuổi kịp.
2.5. Từ động lực đến mục tiêu đo được
Các lực đẩy ở trên mới là động lực (driver). Muốn biến chúng thành chương trình có thể quản trị, cần đi tiếp ba bước: mục tiêu định hướng (goal), mục tiêu cụ thể có thời hạn (objective), và chỉ số theo dõi (measure). Bảng dưới đây minh họa chuỗi đó. Các chỉ tiêu chỉ mang tính minh họa; mỗi tổ chức cần đặt chỉ tiêu từ hiện trạng của mình. Các mốc TA1, TA2 là các giai đoạn chuyển tiếp được trình bày ở Kỳ 3.
| Động lực | Mục tiêu định hướng | Mục tiêu cụ thể (minh họa) | Chỉ số theo dõi |
|---|---|---|---|
| Fintech thắng ở thời điểm đưa offer | Đưa đúng offer vào đúng lúc | Đến cuối TA2, 80% offer bán chéo được kích hoạt bởi sự kiện, trong vòng 5 phút kể từ tín hiệu | Time-to-decision |
| Chu kỳ ra offer tính bằng tháng | Rút ngắn thời gian ra thị trường | Đến cuối TA1, một biến thể offer trong khuôn khổ đã duyệt của một dòng sản phẩm ra thị trường trong tối đa 5 ngày làm việc | Time-to-offer |
| Offer sai người, như trường hợp của Minh | Không mời khách sản phẩm họ đã có | Sau TA1, tỷ lệ offer trùng sản phẩm khách đang sở hữu dưới 0,5% | Tỷ lệ offer trùng |
| Luật Bảo vệ dữ liệu cá nhân | Cá nhân hóa hợp pháp | Từ TA1, 100% offer được kiểm tra consent tự động | Tỷ lệ offer qua kiểm tra consent |
| Không có vòng học | Học nhanh hơn đối thủ | Đến cuối TA2, 100% chiến dịch có nhóm đối chứng | Tỷ lệ offer có nhóm đối chứng |
Chỉ số theo dõi sẽ trình bày theo năm thuộc tính đo lường ở mục 3.5 và bộ KPI ở Kỳ 3.
3. Định nghĩa “Customer Offering Capability”
3.1. Định nghĩa
Customer Offering Capability là năng lực của tổ chức trong việc nhận biết nhu cầu, thiết kế, ra quyết định, phân phối và liên tục tối ưu các offer tài chính được cá nhân hóa cho từng khách hàng, trong giới hạn khẩu vị rủi ro và yêu cầu tuân thủ, với tốc độ phù hợp với ngữ cảnh của khách hàng.
Theo cách hiểu của TOGAF, capability mô tả “tổ chức có thể làm gì”, độc lập với việc ai làm, làm bằng quy trình hay hệ thống nào. Do đó Customer Offering Capability không đồng nhất với một phòng ban (Marketing hay Sản phẩm), cũng không đồng nhất với một hệ thống (CRM hay campaign tool). Nó là năng lực xuyên chức năng, được tạo thành từ sự phối hợp của con người, quy trình, dữ liệu và công nghệ.
3.2. Phân biệt với các khái niệm gần
| Khái niệm | Trọng tâm | Khác biệt với Customer Offering Capability |
|---|---|---|
| Product Management | Vòng đời của sản phẩm: thiết kế, ra mắt, điều chỉnh, ngừng | Lấy sản phẩm làm trung tâm, trong khi Offering lấy khách hàng và ngữ cảnh làm trung tâm |
| Campaign Management | Lập kế hoạch và thực thi chiến dịch truyền thông | Hướng theo lịch và phân khúc, thiếu quyết định theo thời gian thực cho từng cá nhân |
| Next Best Offer / Action | Lựa chọn hành động tốt nhất cho một khách hàng tại một thời điểm | Là một năng lực con quan trọng nằm trong giai đoạn Decide, không bao trùm toàn bộ chuỗi |
| Customer Offering Capability | Toàn bộ chuỗi từ nhận biết nhu cầu đến học từ kết quả | Bao gồm và kết nối các khái niệm trên thành một dòng giá trị thống nhất |
3.3. Phân rã năng lực
Customer Offering Capability (cấp L1) có thể phân rã thành các năng lực cấp L2 như sau. Mỗi năng lực L2 tiếp tục được chi tiết hóa ở cấp L3 khi lập kế hoạch triển khai.
| Năng lực L2 | Mô tả | Ví dụ năng lực L3 |
|---|---|---|
| Customer Insight & Need Sensing | Hiểu khách hàng và phát hiện nhu cầu | Phát hiện sự kiện đời sống, dự đoán xu hướng mua, phân khúc động |
| Offer Design & Configuration | Thiết kế offer từ các linh kiện sản phẩm | Quản lý danh mục linh kiện, mô phỏng offer, cấu hình khuôn khổ |
| Eligibility & Risk Assessment | Xác định khách có đủ điều kiện và mức rủi ro | Kiểm tra điều kiện, chấm điểm tín dụng, xác định hạn mức |
| Offer Pricing | Định giá theo rủi ro và giá trị khách hàng | Định giá theo rủi ro, định giá động trong biên độ cho phép |
| Offer Decisioning | Chọn offer tốt nhất trong các offer đủ điều kiện | Xếp hạng offer, giải quyết xung đột, kiểm soát tần suất |
| Offer Delivery & Engagement | Đưa offer đến khách đúng kênh, đúng lúc | Điều phối đa kênh, cá nhân hóa nội dung, chọn thời điểm |
| Offer Fulfilment | Chuyển offer được chấp nhận thành sản phẩm đang hoạt động | Onboarding số, eKYC, phê duyệt, giải ngân hoặc kích hoạt |
| Offer Performance & Learning | Đo lường và cải tiến | Đo uplift, thử nghiệm A/B, huấn luyện lại mô hình |
| Offer Governance | Kiểm soát rủi ro, tuân thủ và đạo đức | Quản lý guardrail, quản trị mô hình, kiểm toán quyết định |
3.4. Ánh xạ sang BIAN Service Domains
BIAN giúp tách bạch trách nhiệm giữa các thành phần và tạo ngôn ngữ chung khi làm việc với nhà cung cấp. Dưới đây là các service domain liên quan trực tiếp đến Customer Offering:
| Nhóm | Service Domain (BIAN) | Vai trò trong Customer Offering |
|---|---|---|
| Sản phẩm | Product Design, Product Directory, Product Deployment | Định nghĩa linh kiện sản phẩm, danh mục sản phẩm và việc triển khai sản phẩm ra kênh |
| Hiểu khách hàng | Customer Behavioral Insights, Party Reference Data Directory, Customer Event History | Cung cấp hồ sơ, hành vi và lịch sử tương tác của khách hàng |
| Khớp và đề xuất | Product Matching, Customer Product and Service Eligibility | Khớp sản phẩm với nhu cầu và xác định điều kiện đủ |
| Offer và bán hàng | Customer Offer, Sales Product, Customer Relationship Management | Xử lý offer đến khi khách chấp nhận, hỗ trợ bán hàng |
| Chiến dịch | Customer Campaign Design, Customer Campaign Management | Thiết kế và vận hành các chiến dịch có chủ đích |
| Rủi ro | Customer Credit Rating, Underwriting | Đánh giá tín dụng và thẩm định |
| Tuân thủ | Regulatory Compliance | Đảm bảo offer và quy trình tuân thủ quy định |
3.5. Năm thuộc tính đo lường năng lực
-
Speed (Tốc độ): thời gian từ ý tưởng đến offer trên thị trường, và từ tín hiệu của khách đến lúc offer được đưa ra.
-
Relevance (Độ phù hợp): offer có đúng nhu cầu và đúng thời điểm hay không, đo qua tỷ lệ chuyển đổi và uplift.
-
Scale (Quy mô): khả năng phục vụ hàng triệu khách hàng với chi phí biên thấp.
-
Safety (An toàn): offer nằm trong khẩu vị rủi ro, tuân thủ pháp luật và không gây hại cho khách hàng.
-
Learning (Khả năng học): tốc độ tổ chức cải thiện offer dựa trên kết quả thực tế.
Năm thuộc tính này có quan hệ đánh đổi. Một tổ chức có thể rất nhanh nhưng thiếu an toàn, hoặc rất an toàn nhưng chậm. Customer Offering Factory hướng đến việc nâng đồng thời cả năm thuộc tính, và điều đó chỉ khả thi khi có nền tảng dữ liệu và kiến trúc phù hợp. Năm thuộc tính này cũng là khung để nhóm bộ KPI ở Kỳ 3, nhờ vậy cách đo ở cuối chương trình khớp với cách định nghĩa năng lực ở đầu chương trình.
4. Value Stream “Deliver Personalized Offer”
4.1. Vì sao cần nhìn bằng value stream
Capability map cho biết tổ chức cần năng lực gì, nhưng không cho biết giá trị chảy qua các năng lực đó như thế nào. Value stream bổ sung góc nhìn đó: một chuỗi các giai đoạn tạo ra giá trị cho một bên liên quan. Nói theo TOGAF, value stream trả lời câu hỏi “vì sao” tổ chức cần một năng lực, còn capability trả lời câu hỏi “cần gì”. Khi đặt value stream cạnh capability map, kiến trúc sư có thể chỉ ra chính xác năng lực nào đang là điểm nghẽn của giai đoạn nào.
| Value stream 1: Deliver Personalized Offer | Value stream 2: Launch Offer Envelope | |
|---|---|---|
| Bên khởi tạo | Khách hàng, qua một tín hiệu nhu cầu | Người chịu trách nhiệm offer (Offer Owner), qua một cơ hội kinh doanh hoặc một bài học từ dữ liệu |
| Giá trị nhận được | Khách nhận được offer phù hợp đúng lúc, chấp nhận và dùng được ngay mà không phải khai lại thông tin | Một khuôn khổ offer được duyệt và có hiệu lực trong hệ thống ra quyết định, cùng hiệu quả đo được |
| Nhịp | Giây đến phút, cho từng khách hàng | Ngày đến tuần, cho từng khuôn khổ offer |
| Các giai đoạn | Sense → Understand → Decide → Engage → Fulfil | Design & Configure → Learn, rồi quay lại Design |
4.2. Bảy giai đoạn của nhà máy offer
Giai đoạn 1: Sense (Nhận biết tín hiệu)
Phát hiện các tín hiệu cho thấy khách hàng có thể đang phát sinh nhu cầu: lương về, số dư tăng đột biến, giao dịch tại đại lý ô tô, tìm kiếm sản phẩm vay trên ứng dụng, sắp đáo hạn sổ tiết kiệm. Giá trị đầu ra là một sự kiện có ý nghĩa, đã được gắn với đúng khách hàng.
Giai đoạn 2: Understand (Hiểu khách hàng)
Kết hợp tín hiệu với hồ sơ hợp nhất của khách: sản phẩm đang sở hữu, khả năng tài chính, lịch sử tương tác, các offer đã nhận và đã từ chối. Giá trị đầu ra là bức tranh khách hàng đủ để đánh giá nhu cầu.
Giai đoạn 3: Design & Configure (Thiết kế và cấu hình offer) · value stream 2
Đội sản phẩm định nghĩa các linh kiện và khuôn khổ offer, gồm biên độ giá, hạn mức, kỳ hạn, điều kiện. Khuôn khổ được phê duyệt một lần, sau đó hệ thống có thể tự lắp ghép biến thể cho từng khách hàng trong phạm vi đó.
Giai đoạn 4: Decide (Ra quyết định)
Xác định khách đủ điều kiện với những offer nào, định giá theo rủi ro, rồi chọn offer tốt nhất dựa trên xác suất chấp nhận, giá trị cho tổ chức và lợi ích cho khách hàng. Đồng thời áp dụng quy tắc kiểm soát tần suất để tránh làm phiền khách.
Giai đoạn 5: Engage (Tương tác)
Đưa offer đến khách qua kênh phù hợp nhất tại thời điểm phù hợp nhất, với nội dung được cá nhân hóa: thông báo trong ứng dụng, banner, tin nhắn, cuộc gọi từ nhân viên tư vấn, hoặc gợi ý ngay trong luồng giao dịch.
Giai đoạn 6: Fulfil (Hoàn tất)
Khi khách chấp nhận, chuyển offer thành sản phẩm đang hoạt động với ít ma sát nhất: tự điền thông tin đã có, eKYC, phê duyệt tự động trong khuôn khổ, giải ngân hoặc kích hoạt ngay.
Giai đoạn 7: Learn (Học và tối ưu) · value stream 2
Ghi nhận toàn bộ kết quả, gồm cả việc khách bỏ qua hay từ chối, đo uplift so với nhóm đối chứng, theo dõi chất lượng khoản vay sau giải ngân, rồi đưa ngược vào huấn luyện mô hình và điều chỉnh khuôn khổ offer.
Điều kiện vào và ra của từng giai đoạn
Theo TOGAF, mỗi giai đoạn cần có điều kiện bắt đầu (entrance) và điều kiện kết thúc (exit), và điều kiện kết thúc của giai đoạn trước chính là điều kiện bắt đầu của giai đoạn sau. Viết ra các điều kiện này giúp thấy ngay chỗ nào giá trị bị “rơi” giữa hai giai đoạn. Với value stream 1:
| Giai đoạn | Bắt đầu khi | Kết thúc khi | Giá trị tạo ra | Bên tham gia |
|---|---|---|---|---|
| Sense | Một sự kiện phát sinh tại nguồn (lương về, sổ đáo hạn…) | Sự kiện có ý nghĩa đã gắn với đúng một khách hàng | Nhu cầu được nhận biết | Khách hàng, Dữ liệu |
| Understand | Sự kiện đã gắn khách hàng | Hồ sơ đủ để đánh giá: sản phẩm đang có, khả năng tài chính, consent | Nhu cầu được hiểu đúng | Dữ liệu, Rủi ro |
| Decide | Hồ sơ đã đủ và có khuôn khổ offer đang hiệu lực | Chọn được một offer, hoặc quyết định không offer; quyết định được ghi lại | Offer phù hợp và an toàn | Offer Owner, Rủi ro, Tuân thủ |
| Engage | Offer đã được chọn | Khách phản hồi: chấp nhận, từ chối hoặc bỏ qua; phản hồi được ghi lại | Offer đến đúng kênh, đúng lúc | Kênh, Khách hàng |
| Fulfil | Khách chấp nhận | Sản phẩm đã hoạt động | Khách dùng được ngay | Vận hành, hệ thống khởi tạo khoản vay |
Trong trường hợp của Minh, giá trị rơi ngay ở giai đoạn Understand: sự kiện đã có, nhưng hồ sơ không cho biết anh đang có thẻ tín dụng, nên giai đoạn Decide nhận đầu vào sai.
4.3. Điểm nghẽn điển hình tại các tổ chức Việt Nam
| Giai đoạn | Năng lực hỗ trợ chính | Điểm nghẽn thường gặp |
|---|---|---|
| Sense | Event processing, data integration | Dữ liệu chỉ có sau batch cuối ngày, sự kiện không được chuẩn hóa |
| Understand | Identity resolution, Customer 360 | Một khách hàng có nhiều mã ở nhiều hệ thống, hồ sơ không đầy đủ |
| Design & Configure | Product catalog, offer configuration | Tham số sản phẩm nằm cứng trong core, mỗi thay đổi cần dự án CNTT |
| Decide | Decisioning, credit risk, pricing | Quy tắc nằm rải rác ở từng kênh, phê duyệt thủ công |
| Engage | Omnichannel orchestration | Mỗi kênh một công cụ, không biết khách đã nhận gì ở kênh khác |
| Fulfil | Digital onboarding, eKYC, LOS | Bắt khách nhập lại thông tin, quy trình đứt đoạn giữa số và quầy |
| Learn | Offer history, experimentation | Không lưu lịch sử offer, không có nhóm đối chứng |
4.4. Ma trận Value Stream và Capability
Kỹ thuật cross-mapping giữa value stream stage và capability giúp ưu tiên đầu tư. Ma trận dưới đây đánh dấu mức độ hỗ trợ của từng năng lực L2 (mục 3.3) cho từng giai đoạn (●: hỗ trợ chính, ○: hỗ trợ phụ). Hàng cuối là dải năng lực dữ liệu hỗ trợ: định danh và hồ sơ hợp nhất, xử lý sự kiện, lịch sử offer, consent. Dải này nằm ở tầng khác với các năng lực L2 và sẽ được phân rã ở Kỳ 2.
| Năng lực L2 | Sense | Underst. | Design | Decide | Engage | Fulfil | Learn |
|---|---|---|---|---|---|---|---|
| Customer Insight & Need Sensing | ● | ● | ○ | ○ | ○ | ||
| Offer Design & Configuration | ● | ○ | ○ | ||||
| Eligibility & Risk Assessment | ○ | ○ | ● | ● | |||
| Offer Pricing | ● | ● | ○ | ||||
| Offer Decisioning | ● | ○ | ○ | ||||
| Offer Delivery & Engagement | ● | ○ | |||||
| Offer Fulfilment | ○ | ● | |||||
| Offer Performance & Learning | ○ | ● | |||||
| Offer Governance | ● | ● | ○ | ○ | ○ | ||
| Dải năng lực dữ liệu hỗ trợ | ● | ● | ○ | ● | ○ | ○ | ● |
Lưu ý rằng các hàng là năng lực chứ không phải hệ thống. Một lỗi rất phổ biến là điền vào đây “decisioning engine”, “AI platform” hay “omnichannel”, năng lực phải độc lập với hệ thống.
View Capability-to-Application là nơi đặt các nền tảng, ví dụ:
| Thành phần ứng dụng, nền tảng | Hiện thực hóa chủ yếu năng lực L2 |
|---|---|
| Product catalog, product engine | Offer Design & Configuration, Offer Pricing |
| Decision engine, quản lý quy tắc | Offer Decisioning, Eligibility & Risk Assessment |
| Nền tảng AI/ML | Customer Insight & Need Sensing, Offer Decisioning, Offer Performance & Learning |
| Điều phối đa kênh | Offer Delivery & Engagement |
| Onboarding số, hệ thống khởi tạo khoản vay | Offer Fulfilment |
| Nền tảng thử nghiệm A/B | Offer Performance & Learning |
| Công cụ kiểm soát rủi ro và tuân thủ | Offer Governance |
5. Khung đánh giá năng lực Customer Offering
5.1. Mô hình trưởng thành năm cấp
| Cấp | Tên | Đặc điểm offer | Đặc điểm dữ liệu |
|---|---|---|---|
| 1 | Ad-hoc | Bán hàng dựa vào nhân viên, không có chiến dịch có hệ thống | Dữ liệu nằm trong từng hệ thống, khai thác thủ công |
| 2 | Campaign-based | Chiến dịch hàng loạt theo phân khúc thô, chạy định kỳ | Có kho dữ liệu, cập nhật T+1, nhiều mã khách hàng |
| 3 | Segment-driven | Mô hình propensity, phân khúc chi tiết, có đo hiệu quả | Customer 360 cơ bản, định danh hợp nhất một phần |
| 4 | Real-time personalized | Offer theo sự kiện, decisioning tập trung, đa kênh thống nhất | Event backbone, feature store, offer history, consent registry |
| 5 | AI-native | Tối ưu liên tục, agentic AI trong khuôn khổ guardrail, cá nhân hóa từng người | Data product đầy đủ, vòng học tự động, chia sẻ dữ liệu hệ sinh thái |
Phần lớn tổ chức tài chính tại Việt Nam hiện ở khoảng cấp 2 đến cấp 3, một số đơn vị dẫn đầu đang tiến vào cấp 4 ở một số sản phẩm. Điều quan trọng là năng lực có thể không đồng đều: một tổ chức có thể ở cấp 4 với thẻ tín dụng nhưng chỉ ở cấp 2 với tiền gửi, hoặc ở cấp 3 về Offer Decisioning nhưng chỉ ở cấp 2 về Offer Performance & Learning. Vì vậy, ngoài điểm tổng, nên chấm mức hiện tại và mức mục tiêu cho từng năng lực L2, rồi tô màu lên ma trận ở mục 4.4 (ví dụ ở mục Góc TOGAF cuối bài).
5.2. Các chiều đánh giá và trọng số
| Chiều đánh giá | Trọng số gợi ý | Câu hỏi then chốt |
|---|---|---|
| Dữ liệu | 30% | Định danh có hợp nhất không? Dữ liệu có đến điểm quyết định kịp thời không? Có lưu lịch sử offer và consent dạng cấu trúc không? |
| Decisioning | 15% | Logic quyết định có tập trung không? Có dùng mô hình hay chỉ dùng quy tắc tĩnh? |
| Product modularity | 15% | Có thể tạo biến thể offer mà không cần dự án CNTT không? |
| Kênh | 10% | Các kênh có dùng chung offer và lịch sử liên lạc không? |
| Governance | 10% | Có guardrail tự động và quản trị mô hình không? |
| Tổ chức | 10% | Có đội liên chức năng theo hành trình khách hàng không? |
| Tốc độ | 10% | Time-to-offer và time-to-decision hiện tại là bao nhiêu? |
Dữ liệu được đề xuất trọng số cao nhất vì nó là điều kiện tiên quyết của mọi chiều còn lại: decisioning không có dữ liệu chỉ là quy tắc tĩnh, AI không có dữ liệu chỉ là mô hình trên giấy.
Gợi mở cho Kỳ 2: Điểm nghẽn nằm ở đâu?
Đến đây, bức tranh chẩn đoán đã khá rõ. Cuộc cạnh tranh đã chuyển sang mô hình Customer Offering Factory. Năng lực Customer Offering có thể được định nghĩa, phân rã, ánh xạ sang BIAN và đặt lên hai value stream với bảy giai đoạn. Phần lớn tổ chức tại Việt Nam đang ở cấp 2 đến cấp 3 trên thang trưởng thành.
Nhưng có một chi tiết lặp lại ở mọi phần phân tích. Trong ma trận Value Stream và Capability, dữ liệu xuất hiện ở gần như mọi giai đoạn. Trong khung đánh giá, dữ liệu mang trọng số cao nhất. Và trong câu chuyện của Minh, ngân hàng A thua không phải vì thiếu dữ liệu, mà vì dữ liệu không chảy được đến nơi cần ra quyết định.
Điều đó đặt ra những câu hỏi mà Kỳ 1 chưa trả lời:
-
Năng lực dữ liệu cho Customer Offering gồm chính xác những gì? Vì sao một khối dữ liệu khổng lồ vẫn không tạo ra offer đúng?
-
Vì sao “dữ liệu về offer”, thứ mà hầu hết tổ chức không lưu, lại có thể là tài sản giá trị nhất trong dài hạn?
-
Với một ngân hàng có core banking legacy không thể thay thế, kiến trúc dữ liệu cần được thiết kế thế nào để vẫn đạt tốc độ của fintech?
-
Có cần “real-time hóa” mọi thứ không, và cái giá của việc đó là bao nhiêu?
Kỳ 2: “Đường ống trước, động cơ sau” sẽ trả lời những câu hỏi này, với bản đồ năng lực dữ liệu, mô hình dữ liệu offer và một kiến trúc tham chiếu tám lớp cho Customer Offering.