Bài 12 – Khách hàng – hợp đồng – giao dịch – tài sản liên kết với nhau thế nào? tiếp tục bộ xương V2 của Hệ thống thông tin BĐS. Mục tiêu không phải học thuộc tên bảng, mà hiểu cách mô hình hóa thế giới BĐS thành dữ liệu có định danh, quan hệ, thời gian, nguồn và trách nhiệm quản trị.
Biên soạn: ThS. Nguyễn Mạnh Hùng
Đơn vị: GV. Khoa QLĐĐ&BĐS – ĐH Nông Lâm TP.HCM
Email: nguyenmanhhung@hcmuaf.edu.vn
Cập nhật 30/09/2026: Bài viết phục vụ học tập và giảng dạy trong series Hệ thống thông tin BĐS V2. Nội dung giữ ranh giới với Tin học BĐS và Phân tích TTBĐS: tập trung vào mô hình dữ liệu, quy trình, kiến trúc, quản trị và tích hợp; không biến bài thành hướng dẫn thao tác SQL/GIS hay mô hình thống kê.
Ranh giới với các series khác: Bài tập trung vào mô hình dữ liệu và governance. Kỹ thuật lập trình, SQL, API và phân tích thống kê được dẫn chiếu nhưng không dạy lại.
1. Một người có thể là nhiều vai trò trong cùng hệ thống
Trong CRM, “khách hàng” thường được dùng như một nhãn chung. Nhưng cùng một cá nhân có thể là người quan tâm, người mua, người thuê, người đại diện doanh nghiệp, người đồng ký hợp đồng hoặc người liên hệ vận hành. Nếu mô hình gắn vai trò trực tiếp vào hồ sơ cá nhân, một người có nhiều vai trò sẽ gây xung đột. Nên tách Party/Customer khỏi Role và bối cảnh của vai trò.
2. Tài sản phải có danh tính độc lập
Tài sản không nên “thuộc” bảng giao dịch. Một căn hộ có thể được rao bán, cho thuê nhiều lần, có nhiều hợp đồng theo thời gian và xuất hiện trong nhiều chiến dịch. PropertyID độc lập giúp nối CRM, inventory, hợp đồng, vận hành và BI mà không tạo bản sao tài sản cho mỗi giao dịch.
3. Giao dịch là một quá trình có trạng thái
Giao dịch có thể đi từ inquiry, qualified, viewing, offer, booking, negotiation đến contract hoặc lost/cancelled. Mỗi trạng thái có thời điểm, người chịu trách nhiệm và lý do. Vì vậy Transaction/Opportunity nên là thực thể riêng, không chỉ là cột status trong Customer.
| Thực thể | Không nên nhầm với | Quan hệ chính |
|---|---|---|
| Party/Customer | Lead hoặc hợp đồng | Có nhiều vai trò |
| Property | Listing | Xuất hiện trong nhiều giao dịch |
| Transaction | Contract | Quá trình thương mại |
| Agreement | Opportunity | Nghĩa vụ/điều khoản |
| Role | Identity | Vai trò theo bối cảnh |
4. Hợp đồng là thực thể pháp lý/thương mại riêng
Hợp đồng cần số, loại, bên tham gia, tài sản/phạm vi, ngày hiệu lực, ngày hết hạn, giá trị, điều khoản và file. Hợp đồng có thể được gia hạn, phụ lục, chấm dứt hoặc thay thế; không nên nhồi toàn bộ vào bảng giao dịch vì vòng đời sau ký dài hơn vòng đời bán hàng.
5. Mô hình Party–Role–Agreement
Một cách thiết kế bền vững là Party giữ danh tính, PartyRole giữ vai trò trong bối cảnh, Agreement giữ quan hệ hợp đồng và Asset/Property giữ đối tượng. Transaction nối quá trình thương mại tới Agreement. Cách này cho phép một tổ chức có nhiều người đại diện và một hợp đồng có nhiều bên.
6. Customer Master và bài toán trùng khách
Khách có thể vào từ website, sự kiện, Zalo, sàn môi giới và hệ thống chăm sóc. Mỗi nguồn có thể ghi tên/số điện thoại khác nhau. Customer Master cần cơ chế matching, merge, survivorship và giữ cross-reference tới ID nguồn. Không nên xóa mất lịch sử nguồn chỉ vì đã hợp nhất.
7. Consent và mục đích sử dụng dữ liệu
Thông tin khách không chỉ là dữ liệu bán hàng. Hệ thống cần biết dữ liệu được thu từ đâu, mục đích gì, có được phép liên hệ/kênh nào và chia sẻ cho ai. Đây là lớp quản trị dữ liệu cần được thiết kế cùng mô hình, không bổ sung sau khi CRM đã chạy.
8. Từ giao dịch sang vận hành
Sau khi ký hợp đồng thuê/mua, cùng hồ sơ khách và tài sản có thể chuyển sang cổng cư dân/tenant, billing, work order hoặc property management. Nếu các hệ thống không dùng định danh chung, người dùng phải nhập lại và dễ tạo một “khách mới” dù là cùng người.
Khung thiết kế nâng cao: từ khái niệm đến hệ thống có thể vận hành
Ở góc dữ liệu doanh nghiệp, mô hình chỉ có giá trị khi chuyển được thành quy tắc vận hành. Mỗi đối tượng phải có định danh, owner, source, trạng thái, thời gian, quyền truy cập và quy tắc thay đổi. Nếu thiếu một trong các lớp này, mô hình ER đẹp vẫn có thể tạo dữ liệu không đáng tin.
| Lớp kiểm soát | Câu hỏi thiết kế | Bằng chứng nghiệm thu |
|---|---|---|
| Identity | Cùng một đối tượng được nhận diện thế nào? | ID/namespace/crosswalk |
| Semantics | Trường này nghĩa chính xác là gì? | Data dictionary/code list |
| Source | Ai/cái gì khẳng định dữ liệu? | Source + provenance |
| Time | Đúng ở thời điểm nào? | Effective/version fields |
| Ownership | Ai chịu trách nhiệm? | Data owner/steward |
| Access | Ai xem/sửa/duyệt? | Role/permission/audit |
| Change | Thay đổi qua quy trình nào? | Workflow/event/version |
Một kiến trúc thực tế thường có Customer Master ở lớp MDM; CRM lưu lead/opportunity; Contract/Lease system lưu agreement; Property Master lưu asset; hệ thống billing/operations dùng lại PartyID và PropertyID. Integration phát sự kiện CONTRACT_SIGNED để mở tenant account thay vì nhập tay.
Một nguyên tắc quan trọng là không để schema vật lý quyết định nghiệp vụ. Nếu hệ thống hiện tại có một cột nhưng nghiệp vụ thực tế là quan hệ nhiều–nhiều, hãy sửa mô hình thay vì ép nghiệp vụ vào cột. Ngược lại, không cần tạo hàng chục thực thể chỉ để thể hiện sự 'đúng chuẩn' nếu tổ chức không có use case và governance tương ứng.
Tình huống thiết kế và phòng thí nghiệm quyết định
Tình huống giả lập: chị A điền form mua căn, chồng chị A là người ký đồng mua; sau đó căn được cho Công ty B thuê, nhưng chị A là người liên hệ nhận hóa đơn. Nếu CRM dùng 'customer_id' cho mọi vai trò, hệ thống sẽ nhầm. Hãy tách identity, role, agreement và transaction.
| Bước | Việc phải làm | Câu hỏi phản biện |
|---|---|---|
| 1. Xác định đối tượng | Liệt kê entity/domain | Có đang trộn object với document/process? |
| 2. Xác định quan hệ | Cardinality + role | M:N có thuộc tính riêng không? |
| 3. Gắn thời gian | Effective/version/event | Có tái dựng lịch sử được không? |
| 4. Gắn nguồn | Source/provenance | Ai chứng minh dữ liệu? |
| 5. Gắn governance | Owner/permission | Ai có quyền sửa? |
| 6. Test ngoại lệ | Split/merge/correction | Mô hình có vỡ khi nghiệp vụ khó? |
Sinh viên không cần viết code ở bước này. Yêu cầu là vẽ mô hình, giải thích từng quan hệ và chứng minh mô hình xử lý được ngoại lệ. Nếu một thiết kế chỉ chạy trong ví dụ 'mỗi tài sản một chủ, mỗi khách một hợp đồng' thì chưa đủ cho BĐS thực tế.
Kiểm soát chất lượng dữ liệu và khả năng truy vết
Chất lượng dữ liệu không chỉ là “đủ trường”. Với mô hình BĐS, cần kiểm tra ít nhất tính đầy đủ, hợp lệ, nhất quán, duy nhất, kịp thời và truy vết được nguồn. Một record có đầy đủ thông tin nhưng source không rõ vẫn có rủi ro cao; một record đúng nhưng đã hết hiệu lực cũng không nên dùng cho quyết định hiện tại.
| Chiều chất lượng | Ví dụ lỗi | Kiểm soát |
|---|---|---|
| Completeness | Thiếu ID/source/effective date | Required rule + exception queue |
| Validity | Loại quyền ngoài code list | Reference data validation |
| Consistency | CRM và master khác loại tài sản | Reconciliation |
| Uniqueness | Hai record cùng đối tượng | Matching/duplicate workflow |
| Timeliness | Thông tin quá hạn | Expiry/SLA |
| Traceability | Không biết dữ liệu từ đâu | Provenance/audit |
Hãy luôn thêm exception workflow. Dữ liệu thực tế không bao giờ sạch tuyệt đối; hệ thống trưởng thành không phải hệ thống “không có lỗi” mà là hệ thống phát hiện, phân công, xử lý và học từ lỗi có cấu trúc.
Khung áp dụng thực tế
- Vẽ Party–Role–Transaction–Agreement–Property.
- Xác định Customer Master ID và source IDs.
- Thiết kế trạng thái opportunity không trùng contract status.
- Mô phỏng handoff từ Sales sang vận hành.
Những sai lầm cần tránh
- Dùng Customer như một bảng chứa mọi thứ.
- Tạo bản sao Property cho mỗi listing/giao dịch.
- Nhầm opportunity với hợp đồng.
- Merge khách mà xóa mất source ID và consent.
Bài tập thực hành
Chọn một hệ thống thật hoặc giả lập. Không bắt đầu bằng giao diện. Hãy viết danh sách đối tượng nghiệp vụ, quan hệ, mã định danh, source, thời gian hiệu lực, người chịu trách nhiệm và các ngoại lệ. Sau đó vẽ mô hình khái niệm và dùng ít nhất hai tình huống khó để phá thử mô hình. Cuối cùng ghi rõ phần nào là dữ liệu chủ, phần nào là giao dịch, phần nào là tài liệu và phần nào là lịch sử.
Câu hỏi tự kiểm tra
- Đối tượng chính của mô hình là gì và có định danh độc lập không?
- Quan hệ nào là 1:N, quan hệ nào thực chất là M:N?
- Mô hình có giữ được source và lịch sử hay chỉ trạng thái hiện tại?
- Ai là Data Owner và ai được quyền sửa?
- Nếu hai hệ thống có ID khác nhau, ta nối chúng bằng cơ chế nào?
- Thiết kế có đứng vững khi xảy ra split, merge, correction hoặc nhiều chủ thể không?
Kiểm thử mô hình bằng các ngoại lệ thường gặp trong BĐS
Một mô hình tốt phải xử lý được ngoại lệ trước khi triển khai. Hãy thử năm nhóm: nhiều chủ thể, nhiều hệ định danh, thay đổi theo thời gian, hồ sơ đến muộn/sửa sai và tách–hợp đối tượng. Nếu phải sửa cấu trúc bảng mỗi khi gặp ngoại lệ, conceptual model chưa đủ tổng quát.
| Ngoại lệ | Câu hỏi test | Dấu hiệu mô hình yếu |
|---|---|---|
| Nhiều chủ thể | Một quyền có 3 bên thì sao? | Chỉ có owner_id |
| Nhiều ID | CRM/GIS/ERP dùng mã khác? | Join bằng tên/địa chỉ |
| Thời gian | Xem trạng thái 2 năm trước? | Chỉ giữ current |
| Correction | Sửa sai có xóa lịch sử? | Overwrite |
| Split/Merge | Đối tượng mới kế thừa gì? | Không có lineage |
Sau mỗi test, không chỉ sửa schema. Hãy hỏi liệu lỗi nằm ở định nghĩa nghiệp vụ, code list, workflow hay governance. Nhiều vấn đề dữ liệu không thể giải quyết chỉ bằng thêm cột.
Decision log cho thiết kế dữ liệu
Mỗi quyết định mô hình quan trọng nên có nhật ký: vấn đề, các phương án, lựa chọn, lý do, tác động, người phê duyệt và ngày xem lại. Ví dụ quyết định chọn một PropertyMasterID nội bộ thay vì dùng mã CRM cần ghi rõ vì sao: CRM ID phụ thuộc ứng dụng và có thể đổi khi thay CRM. Decision log giúp đội ngũ sau này hiểu ý định thiết kế thay vì suy đoán từ schema.
Ghi nhớ trong 30 giây
- Khách hàng không đồng nghĩa người ký hợp đồng; cùng một cá nhân/tổ chức có thể giữ nhiều vai trò.
- Giao dịch là quá trình; hợp đồng là một kết quả pháp lý/thương mại của quá trình đó.
- Tài sản cần định danh độc lập với khách hàng và hợp đồng để dùng xuyên nhiều hệ thống.
- CRM, hợp đồng và vận hành nên dùng khóa dùng chung thay vì sao chép hồ sơ.
- Customer Master phải quản lý hợp nhất danh tính nhưng vẫn giữ nguồn và lịch sử.
Nguồn tham khảo
- Bài giảng Hệ thống thông tin BĐS 2026–2027, Buổi 2 – mô hình ER, khóa chính/khóa ngoại và chuẩn hóa.
- DAMA-DMBOK2 – Master Data Management và quản trị dữ liệu chủ.
- Laudon & Laudon – Management Information Systems.
- CBRE/Yardi – kiến trúc dữ liệu khách hàng, lease và property management được dùng như tham khảo thực tiễn doanh nghiệp.
Bài tiếp theo: “Mã định danh BĐS, địa chỉ và mã không gian giúp đồng bộ dữ liệu ra sao?”.