Khách hàng đổi số điện thoại. Sales cập nhật trong app quản lý khách hàng.
Đến chiều, nhân viên hỗ trợ vẫn gọi số cũ. Thông tin họ đang dùng nằm trong một app khác, được nhập lại từ lần tiếp nhận trước.
Hai bên đều đã làm đúng phần việc của mình. Tuy nhiên, mỗi bên đang giữ một phiên bản thông tin khách hàng.
Để giải quyết tình huống này, chúng ta cần phân biệt hai việc: chia sẻ dữ liệu giữa các app và liên kết từng bản ghi với đúng đối tượng.
1. Bắt đầu từ trách nhiệm quản lý dữ liệu
Giả sử doanh nghiệp có hai app:
-
App Quản lý khách hàng: lưu hồ sơ khách hàng và thông tin liên hệ.
-
App Hỗ trợ khách hàng: tiếp nhận yêu cầu, phân công người xử lý và ghi nhận kết quả.
Trong phương án minh họa này, nhóm thống nhất hồ sơ khách hàng được cập nhật tại app Quản lý khách hàng. App Hỗ trợ sử dụng những thông tin cần thiết từ đó.
Hai app vẫn phục vụ những công việc riêng:
| Nhóm thông tin | Nơi chịu trách nhiệm cập nhật |
|---|---|
| Mã khách hàng, tên, thông tin liên hệ | App Quản lý khách hàng |
| undefined | ---- |
| Nội dung yêu cầu, người phụ trách, tiến độ xử lý | App Hỗ trợ khách hàng |
| undefined | ---- |
Việc phân chia này giúp xác định nơi cần sửa khi phát hiện thông tin sai.
Trong Cleeksy DOP, mô hình Publish/Consume phục vụ việc chia sẻ dữ liệu giữa các app, đồng thời giữ rõ nguồn dữ liệu chuẩn và phạm vi truy cập. Nội dung này được trình bày trong tài liệu Chia sẻ dữ liệu giữa các app.
2. Publish và Consume là gì?
Publish là thiết lập dữ liệu mà app nguồn cho phép app khác sử dụng.
Consume là sử dụng dữ liệu đã được app nguồn chia sẻ.
Dữ liệu được chia sẻ thường được tổ chức thành một dataset, tức tập dữ liệu, gồm phạm vi bản ghi, các trường thông tin và điều kiện truy cập. Trong ngữ cảnh này, Publish phục vụ chia sẻ giữa các app; dữ liệu vẫn nằm trong thực thể của app nguồn.
Theo tài liệu Publish/Consume của Cleeksy DOP, app nguồn xác định tập bản ghi, trường thông tin và phạm vi quyền được chia sẻ.
Với ví dụ khách hàng, nhóm có thể đề xuất chia sẻ:
-
Mã khách hàng.
-
Tên khách hàng.
-
Người liên hệ.
-
Số điện thoại và email phục vụ hỗ trợ.
Những ghi chú thương lượng hoặc thông tin thương mại nội bộ có thể được giữ ngoài phạm vi chia sẻ nếu bộ phận hỗ trợ không cần dùng.
Câu hỏi cần chốt là: người xử lý yêu cầu cần biết những gì để làm việc?
3. Connected app đóng vai trò gì?
Trong Cleeksy DOP, Connected app, kết nối ứng dụng, là một loại nguồn dữ liệu dùng để kết nối giữa các app.
App sử dụng chọn nguồn được chia sẻ và xác nhận quyền truy cập khi cấu hình kết nối hoặc trường dữ liệu liên quan. Consume diễn ra trong quá trình này, không nhất thiết là một bước thao tác riêng trước đó.
Bạn có thể xem cách hoạt động trong tài liệu Connected app.
Với trường hợp đang xét:
-
App Quản lý khách hàng cung cấp dữ liệu cần dùng.
-
App Hỗ trợ kết nối đến nguồn dữ liệu đó.
-
Sau đó, từng yêu cầu hỗ trợ cần được gắn với đúng hồ sơ khách hàng.
Đây là lúc Data Connection xuất hiện.
4. Data Connection là gì?
Data Connection, liên kết dữ liệu, là trường dùng để tạo quan hệ giữa các bản ghi.
Trong cùng một app, trường này có thể liên kết trực tiếp đến thực thể liên quan. Với dữ liệu giữa các app, liên kết đi qua Connected app đã được chia sẻ. Cách phân biệt hai trường hợp được giải thích trong tài liệu Data Connection một chiều.
Ví dụ minh họa:
| Bản ghi yêu cầu hỗ trợ | Nội dung | Hồ sơ khách hàng được liên kết |
|---|---|---|
| HT-101 | Cần hướng dẫn sử dụng | KH-024 |
| undefined | ---- | ---- |
| HT-108 | Báo lỗi đăng nhập | KH-024 |
| undefined | ---- | ---- |
| HT-115 | Cần hỗ trợ cấu hình | KH-039 |
| undefined | ---- | ---- |
Hai yêu cầu đầu liên quan đến cùng khách hàng KH-024, nhưng vẫn là hai công việc riêng với nội dung và tiến độ riêng.
Khi tạo yêu cầu mới, nhân viên chọn đúng hồ sơ khách hàng. Nhóm có thể dùng mã định danh ổn định để phân biệt các khách trùng tên, thay vì dựa hoàn toàn vào tên hoặc số điện thoại có thể thay đổi.
5. Lookup giúp hiển thị thông tin từ hồ sơ liên kết
Sau khi biết yêu cầu thuộc khách hàng nào, màn hình hỗ trợ cần hiển thị thông tin để nhân viên làm việc.
Lookup, tra cứu dữ liệu, là trường lấy giá trị từ bản ghi liên kết để hiển thị. Trong Cleeksy DOP, Lookup là trường chỉ đọc; giá trị thay đổi theo dữ liệu nguồn. Đặc điểm này được nêu trong tài liệu Lookup.
Ví dụ thiết kế:
| Trường trên yêu cầu hỗ trợ | Cách sử dụng |
|---|---|
| Khách hàng | Data Connection đến hồ sơ KH-024 |
| undefined | ---- |
| Tên khách hàng | Lookup từ hồ sơ đã chọn |
| undefined | ---- |
| Số điện thoại liên hệ | Lookup từ hồ sơ đã chọn |
| undefined | ---- |
| Nội dung cần hỗ trợ | Nhân viên nhập cho yêu cầu này |
| undefined | ---- |
| Kết quả xử lý | Người phụ trách cập nhật |
| undefined | ---- |
Như vậy, nhân viên hỗ trợ làm việc trên yêu cầu của mình, đồng thời tham chiếu thông tin liên hệ từ hồ sơ khách hàng.
Khi kiểm thử, cần đổi thử số điện thoại ở nguồn, rồi kiểm tra lại thông tin hiển thị tại yêu cầu hỗ trợ. Đây là cách xác nhận cấu hình thực tế đang đáp ứng đúng nhu cầu.
6. Phân biệt bốn khái niệm trong cùng một tình huống
| Khái niệm | Vai trò trong ví dụ |
|---|---|
| Publish | App Quản lý khách hàng xác định thông tin được chia sẻ |
| undefined | ---- |
| Consume | App Hỗ trợ sử dụng nguồn đã được chia sẻ |
| undefined | ---- |
| Data Connection | Gắn yêu cầu HT-101 với hồ sơ KH-024 |
| undefined | ---- |
| Lookup | Hiển thị tên, số điện thoại từ hồ sơ KH-024 |
| undefined | ---- |
Publish/Consume giải quyết phạm vi chia sẻ giữa các app. Data Connection xác định quan hệ giữa các bản ghi. Lookup đưa những thông tin cần dùng từ bản ghi liên kết lên màn hình làm việc.
7. Dùng chung dữ liệu cần đi cùng phân quyền
Bộ phận hỗ trợ cần dùng số điện thoại để liên hệ khách. Điều đó chưa xác định ai được quyền thay đổi số điện thoại trong hồ sơ gốc.
Nhóm cần thống nhất trách nhiệm cập nhật và cách đề nghị sửa khi phát hiện sai lệch.
Trong Cleeksy DOP, quyền truy cập có thể được tổ chức theo vai trò, bản ghi và trường thông tin. Khi chia sẻ giữa các app, cần kiểm tra cả phạm vi dữ liệu nguồn lẫn quyền của người dùng ở app sử dụng. Xem thêm tài liệu Mô hình phân quyền.
Một tình huống nên kiểm thử: nhân viên mở được yêu cầu hỗ trợ, nhưng không nhìn thấy số điện thoại. Lúc này, cần kiểm tra quyền và phạm vi chia sẻ trước khi kết luận liên kết bị lỗi.
8. Có cần kết nối hai chiều?
Nếu app Hỗ trợ chủ yếu cần tham chiếu hồ sơ khách hàng, có thể bắt đầu bằng liên kết một chiều.
Liên kết hai chiều chỉ nên được cân nhắc khi có nhu cầu tương tác từ cả hai phía, với trách nhiệm cập nhật và quy tắc kiểm soát rõ ràng. Tài liệu Data Connection hai chiều khuyến nghị xác định bên phụ trách từng nhóm thông tin, thời điểm cập nhật và cách tránh sửa chéo.
Chẳng hạn, nếu nhân viên hỗ trợ nhận được số điện thoại mới, nhóm cần chọn một cách xử lý:
-
Gửi đề nghị cập nhật đến người quản lý hồ sơ.
-
Hoặc cho phép người hỗ trợ cập nhật một số thông tin trong phạm vi được giao.
Lựa chọn phụ thuộc vào cách doanh nghiệp vận hành và cấu hình quyền tương ứng.
9. Kiểm tra gì trước khi đưa vào sử dụng?
Với ví dụ này, có thể thử các tình huống:
-
Tạo yêu cầu và chọn đúng khách hàng.
-
Có hai khách trùng tên.
-
Khách thay đổi thông tin liên hệ.
-
Người dùng thiếu quyền xem một trường.
-
Một hồ sơ không còn thuộc phạm vi chia sẻ.
-
Nhân viên phát hiện dữ liệu nguồn sai và cần đề nghị chỉnh sửa.
Nếu Lookup trống, phần khắc phục sự cố trong tài liệu Lookup gợi ý kiểm tra liên kết đã chọn, trường nguồn được chia sẻ, nguồn kết nối và quyền truy cập.
Cũng cần phân biệt thông tin hiện tại với thông tin tại thời điểm phát sinh công việc. Số điện thoại để gọi hôm nay và số điện thoại khách đã cung cấp lúc gửi yêu cầu có thể phục vụ hai nhu cầu khác nhau. Nếu cần giữ lịch sử, nhóm nên thiết kế cách lưu riêng và đặt tên rõ ràng.
Thử áp dụng: chọn một thông tin đang được nhập lại ở nhiều nơi. Ai chịu trách nhiệm cập nhật thông tin đó? Những nhóm khác cần xem, sửa hay giữ lại phiên bản tại một thời điểm?
Bạn đang mất nhiều thời gian đối chiếu dữ liệu nào nhất? Chia sẻ tình huống trong Community để cùng bàn cách tổ chức phù hợp.