Dữ liệu CRM phức tạp như thế nào?

Mỗi doanh nghiệp đều có hiện trạng và độ trưởng thành trong chiến lược dữ liệu khác nhau. Ta tạm chia thành năm cấp độ: cấp 1 là thấp nhất, đại khái là chỉ toàn Excel và dữ liệu khách hàng được quản lý theo kiểu thân ai nấy lo. Cấp 5 là cao nhất, dữ liệu được tập trung, tổ chức, quản lý bài bản, giải quyết được mọi bài toán về nghiệp vụ và kinh doanh, nói chung là tốt không thể nào tốt hơn.

Excel có lẽ là thứ mà ai cũng nghĩ đến đầu tiên khi cần tập hợp dữ liệu: khả năng lưu trữ lên đến một triệu dòng, xử lý dữ liệu vô cùng linh hoạt với hàng ngàn hàm và công thức, thiết kế biểu đồ đa dạng cùng với sự vi diệu của Macro và trên hết là chi phí chỉ bằng con muỗi khi so với giải pháp khác.

Nhưng dữ liệu doanh nghiệp cần nhiều hơn như thế. Nó đòi hỏi sự tương tác của nhiều phòng ban đội nhóm, với sự phân quyền về chức năng (tạo, xóa, sửa) - và truy xuất dữ liệu (ai được thấy, thao tác dữ liệu nào, thời điểm nào). Vì thế, dù Excel đã Excellent trong việc quản lý dữ liệu cá nhân, nhưng Excel vẫn ngậm ngùi rút khỏi cuộc chơi.

Chia tay Excel sớm để không luyến tiếc và mất thời gian nhấp nhổm “nên hay không Excel”, chúng ta thẳng tiến tới việc xây dựng một chiến lược thực sự. Bất kỳ doanh nghiệp nào cũng có thể chia khách hàng thành hai nhóm: chưa phải khách hàng và đã trở thành khách hàng. - Nhóm “chưa phải khách hàng” thường nằm trên CRM và rải trên ba phân hệ: Marketing, Sales và Service.

- Nhóm “đã trở thành khách hàng” quan trọng hơn nên nếu đầu tư phần mềm sẽ được đầu tư trước: Core banking của ngân hàng, Core Insurance của doanh nghiệp Bảo hiểm, bệnh án điện tử của bệnh viện, eCommerce của doanh nghiệp thương mại điện tử, POS, hệ thống bảo hành, khách hàng thân thiết... Nhu cầu kết nối dữ liệu giữa hai nhóm này hoàn toàn thuận theo tự nhiên, đem lại rất nhiều giá trị, vì vậy, phải tính đến việc kết nối. Về mặt kỹ thuật, có thể chia thành hai xu hướng kết nối: Bền vững và Linh hoạt.

Xu hướng Bền vững

Mục tiêu xây dựng “kho trung tâm” - Golden record of Data, hay System of Record, là nơi kết nối toàn bộ dữ liệu của tất cả các nguồn vào một nơi tập trung, dọn dẹp và làm đẹp đến mức dữ liệu trở thành mẫu mực và sẵn sàng phục vụ cho các mục đích khác. Các công nghệ liên quan có thể kể đến:

- Data lake hay Data pool: dữ liệu được tập trung nhưng chưa được xử lý, chưa được phân nhóm.

- Data Warehouse: dữ liệu được tập trung và sơ chế một phần, chia thành các nhóm dữ liệu nhưng chưa có sự kết nối giữa các nhóm này.

- MDM - Master Data management chính là dạng thức đỉnh cao, dữ liệu đạt đến tiệm cận của sự hoàn hảo. Dữ liệu được kết nối nhưng góc độ tổng hợp từ nhiều nguồn khác nhau chứ không riêng dữ liệu khách hàng nên vẫn xét về dữ liệu khách hàng thì vẫn còn cơ bản.

- Ở cấp độ hoàn hảo về dữ liệu của khách hàng, đó chính là CDM (Customer Data Management) hoặc CDP (Customer Data Platform). Lúc này tại CDM/CDP, dữ liệu khách hàng được chia thành các tập con, nhỏ, chính xác và kết nối chặt chẽ.

Quá trình xây dựng dữ liệu thông thường gồm các bước: tập hợp, lọc trùng, chuẩn hóa, thống nhất và sử dụng. Tuy tên khác nhau nhưng tất cả các bước đều có điểm chung là phức tạp.

- Tập hợp: quá trình này có ba bước cơ bản là ETL. Extract - xuất từ hệ thống cũ; Transform - chuyển đổi định dạng; và Load - Nhập vào hệ thống mới. Do tính chất “Bền vững”, nên yếu tố thời gian thực thường không đặt nặng. Dữ liệu được đổ vào kho trung tâm theo tần suất xác định, phổ biến là hàng ngày - vào đêm khuya hoặc lúc hệ thống không bận rộn.

- Lọc trùng: quá trình này tưởng dễ mà lại khó. Có hai giai đoạn: lọc trùng dữ liệu trước khi đưa vào hệ thống, và lọc trùng dữ liệu mới với dữ liệu đã có trong hệ thống. Cái khó nằm ở chỗ định nghĩa như thế nào là “trùng” nó quá phức tạp. Một dữ liệu có nhiều trường thông tin: Trùng hết tất cả các trường chắc chắn là trùng nhưng trùng một phần cũng là trùng

Ví dụ:

(1) Nam Nguyễn - Thành phố HCM

(2) Nam Nguyễn - TP HCM

(3) Nguyễn Nam - Thành phố HCM

Như 3 trường hợp trên, cái nào là trùng cái nào?

Ở cấp cơ bản, hệ thống chỉ có thể định nghĩa trùng theo tiêu chí xác định: trùng tên và số điện thoại là trùng - tức là trùng 100%. Theo cơ chế này, cả ba dữ liệu trên đều không trùng.

Nhưng ở cấp độ cao hơn, hệ thống có thể cho phép mã hóa thông tin các trường thành các dãy số và dùng một ngưỡng mờ (fuzzy), ví dụ là 80% để so trùng. Theo cơ chế này, cả ba dữ liệu trên đều trùng.

Vậy phát hiện trùng xong thì phải làm gì? Bài toán này cũng thuộc dạng khó hạng nhất và phương án giải quyết cũng chưa bao giờ làm người giải thấy dễ dàng.

- Ở cấp độ cơ bản, nếu hai records bị trùng, thì giữ lại một, và xoá đi một. That’s it!

- Ở cấp độ nâng cao, hệ thống cho phép gộp - merge - các records lại để tạo thành một bản ghi tổng hợp dựa trên các luật được định nghĩa sẵn. Ví dụ: ưu tiên dữ liệu mới/cũ hơn, ưu tiên nguồn A hơn nguồn B, ưu tiên dữ liệu dài hơn...

- Ở cấp độ “vũ trụ”, hệ thống quan sát cách xử lý của người dùng rồi đưa ra cách xử lý linh hoạt cho từng trường hợp.

Tất nhiên là phương án nào cũng có sai số, nhưng với tập dữ liệu quá lớn thì phải đánh đổi và chấp nhận một tỷ lệ sai sót nhất định. Tỷ lệ này thường được gọi là các ngưỡng rủi ro (risk thresholds).

Đối với các hệ thống tốt, sẽ cho phép linh hoạt cài đặt tỷ lệ này cho cả phần kiểm tra trùng lẫn xử lý gộp. Ví dụ: nếu tỷ lệ trùng trên 80% thì cho phép hệ thống tự lọc trùng và gộp, nếu dưới 80% thì sẽ gửi Email cho Admin để xử lý thủ công. Sau khi được làm sạch, dữ liệu được đưa về các vùng dữ liệu (Datamart), hoặc phân loại, hoặc chẳng cần phân chia gì... mà chờ hệ thống khác tới query.

Tới đây, chúng ta đã điểm qua vài nét chính của xu hướng “Bền vững”, hãy tiến thêm bước nữa tới xu hướng “Linh hoạt”, một xu hướng ngày càng trở nên phổ biến và có nhiều ưu điểm vượt trội.

Xu hướng Linh hoạt

Xu hướng chính là cơ sở của việc triển khai Micro-service, có ba trụ cột chính: mapping, phân quyền và trao đổi thông tin.

- Mapping: Thay vì tập hợp hết dữ liệu lại một chỗ như “Bền vững”, xu hướng “Linh hoạt” không đòi hỏi điều đó. Dữ liệu cứ lưu chỗ nó đang ở, chỉ cần khai báo địa chỉ. Sẽ có một cơ chế mapping dữ liệu với địa chỉ tương ứng để truy xuất khi cần thiết.

- Nôm na như sau: Thông tin Khách hàng được quy định tên, email và địa chỉ nhà nằm ở ứng dụng eCommerce, số điện thoại thì lấy từ ứng dụng Giao hàng, tài khoản Facebook thì từ ứng dụng chăm sóc khách hàng. Khi bất kỳ hệ thống nào cần truy xuất thông tin khách hàng, hệ thống sẽ tự động truy xuất tới các ứng dụng tương ứng để tổng hợp.

- Phân quyền: Đối với một doanh nghiệp có nhiều ứng dụng, việc quy định tài khoản nào được truy cập dữ liệu/ứng dụng/hệ thống nào với quyền gì (ghi/xoá/đọc/thay đổi) rất phức tạp và thường xuyên thay đổi. Một giải pháp nhạc trưởng điều phối tài nguyên và truy cập sẽ đảm đương việc này. Giải pháp thường được dùng chính là Kubernetes, một ứng dụng mã nguồn mở dùng để quản lý ứng dụng và service.

- Trao đổi thông tin: Sau khi đã hoàn chỉnh việc phân quyền và mapping, các ứng dụng sẽ bắt đầu truy xuất dữ liệu và cần một cơ chế điều phối để đảm bảo hiệu năng khi lượng dữ liệu lớn và thông tin đáp ứng trên thời gian thực hoặc gần thực. Giải pháp thường được dùng chính là Kafka, nền tảng event streaming mã nguồn mở của Apache. Bộ đôi Kubernetes và Kafka là một trong những lựa chọn hàng đầu của việc xây dựng hạ tầng kiến trúc của xu hướng linh hoạt trong thời gian gần đây.

Phần này đang đi hơi xa về công nghệ, đặc biệt là đối với bạn đọc không phải chuyên ngành kỹ thuật nên bài viết sẽ được dừng tại đây. Nếu không hiểu lắm những gì bên trên thì chỉ cần nhớ “dữ liệu trên CRM cũng thật phức tạp”, vậy là cũng thành công rồi.