Bài 33 · Mô hình định tính, hành vi & ra quyết định trong BĐS

Task–Technology Fit: công nghệ có thực sự phù hợp với nhiệm vụ BĐS?

Một công nghệ có thể dễ dùng, được mọi người thích và vẫn không cải thiện hiệu quả nếu nó không phù hợp với nhiệm vụ. Đây là ý tưởng trung tâm của Task–Technology Fit – TTF.

Goodhue & Thompson (1995) nhấn mạnh rằng công nghệ muốn tạo tác động tới hiệu suất phải vừa được sử dụng, vừa phù hợp với task mà nó hỗ trợ. TTF vì thế đưa câu hỏi 'có dùng không?' sang câu hỏi sâu hơn: 'dùng để làm việc gì và fit tới đâu?'

Chuyên đề: Mô hình định tính, hành vi & ra quyết định trong BĐS · Bài 33 · Hành vi, chấp nhận công nghệ và mô hình lý thuyết

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

1. Ba khối cơ bản

KhốiÝ nghĩa
Task characteristicsĐặc điểm nhiệm vụ cần thực hiện
Technology characteristicsKhả năng/đặc tính công nghệ
Task–Technology FitMức công nghệ đáp ứng yêu cầu task

TTF sau đó liên hệ với utilization và performance impacts. Một hệ thống có fit cao nhưng không dùng do policy/training vẫn không tạo performance. Một hệ thống dùng nhiều nhưng fit thấp có thể tạo workaround và chi phí ẩn.

2. Bắt đầu bằng task, không bắt đầu bằng tính năng

Trong BĐS, task nên được phân rã: tìm dữ liệu giao dịch, kiểm pháp lý, so sánh tài sản, lập báo cáo, follow-up lead, xử lý work order. Sau đó mới hỏi công nghệ có hỗ trợ accuracy, timeliness, accessibility, integration hay flexibility cần cho task không.

Nếu bắt đầu từ danh sách chức năng vendor, đánh giá fit dễ thiên vị theo công nghệ.

3. Ví dụ mapping task–technology

TaskRequirementTechnology capabilityFit
So sánh tài sảnDữ liệu chuẩn hóa, truy xuất nhanhDatabase + GISCao
Đọc hồ sơ scanTrích xuất chính xácOCR/AIVừa
Quyết định pháp lýGiải thích căn cứGenAI không có sourceThấp
Theo dõi leadNhắc lịch, lịch sửCRMCao

4. Dữ liệu TTF nên ở cấp nào?

Một người có thể làm nhiều task và một công nghệ hỗ trợ nhiều task. Dữ liệu tốt nhất có thể ở cấp person × task × technology, thay vì một điểm fit tổng chung.

user_idtask_idtechnology_idfit_scorefrequencyerror_ratetime_saved
U01T03AI014.2Daily3%18 min

Cấu trúc long format này cho phép thấy cùng AI fit cao với task A nhưng thấp với task B.

5. TTF khác PEOU và PU

PEOU hỏi hệ thống có dễ dùng; PU hỏi có hữu ích; TTF hỏi khả năng công nghệ có khớp yêu cầu nhiệm vụ. Một công cụ có thể dễ dùng nhưng không đủ dữ liệu để làm task, nên fit thấp. Hoặc fit cao nhưng giao diện khó, PEOU thấp.

Vì vậy tích hợp TAM–TTF có thể hợp lý khi muốn giải thích cả acceptance và performance, nhưng phải giữ khái niệm riêng.

6. Performance impact cần đo thật

Nếu có thể, nên đo time, error, output quality, throughput hoặc decision quality thay vì chỉ hỏi 'tôi thấy hiệu quả hơn'. Subjective performance hữu ích nhưng dễ common-method bias nếu mọi biến đều từ cùng survey.

Dữ liệu before/after hoặc task experiment rất mạnh cho TTF.

7. Case: AI trích xuất văn bản đất đai

AI fit cao với task nhận dạng số hiệu, ngày, tên cơ quan nếu scan rõ; fit thấp với task kết luận hiệu lực pháp lý vì cần bối cảnh và trách nhiệm chuyên môn. Nếu đánh giá AI chung chung, ta bỏ lỡ ranh giới use case an toàn.

8. Diagnostic use của TTF

Khi fit thấp, có ba hướng: đổi task, đổi technology hoặc redesign workflow. Ví dụ không cần ép AI làm quyết định cuối; có thể dùng AI để trích xuất và để chuyên viên xác nhận. Đây là thiết kế human-in-the-loop dựa trên fit.

9. TTF trong lựa chọn phần mềm BĐS

Có thể dùng TTF trước procurement: lập task inventory, requirement, candidate capability, gap và criticality. Đây là cách giảm tình trạng mua phần mềm vì demo đẹp nhưng không fit workflow.

10. Sai lầm

  • Đánh giá công nghệ chung không gắn task.
  • Nhầm fit với ease of use.
  • Chỉ dùng perception mà không có performance data.
  • Gộp nhiều task đối lập thành một score.
  • Không xét task frequency/criticality.

11. Bài tập thực hành

Chọn 5 nhiệm vụ BĐS và một công nghệ. Với mỗi task, viết requirement, capability, fit, KPI performance và rủi ro. Xác định task nào nên tự động hóa, hỗ trợ hay giữ hoàn toàn cho con người.

12. Xây Task Inventory trước khi đo TTF

Task inventory nên ghi frequency, criticality, data need, time sensitivity, error cost và collaboration requirement. Hai task đều “phân tích tài sản” nhưng một task định giá sơ bộ và một task quyết định tín dụng có error cost rất khác.

task_idfrequencycriticalityaccuracy_needtime_need
T01DailyMediumMediumHigh
T02WeeklyCriticalVery HighMedium

13. Fit có thể là profile, không chỉ một điểm

Một technology có thể fit cao về speed nhưng thấp về explainability, cao về accessibility nhưng thấp về data quality. Tổng hợp thành một score duy nhất có thể che trade-off. Với decision-critical task, nên giữ profile dimensions và gate conditions.

Ví dụ AI định giá có speed fit rất cao nhưng explainability fit thấp; kết luận phù hợp có thể là “dùng để screening, không dùng để quyết định cuối”.

14. TTF cho AI: từ “AI có tốt không?” sang “AI tốt cho task nào?”

Đây là một trong những ứng dụng TTF có giá trị nhất hiện nay. Một mô hình ngôn ngữ có thể fit tốt với tóm tắt, soạn nháp và chuẩn hóa văn bản; fit trung bình với trích xuất dữ liệu khi scan kém; fit thấp với kết luận pháp lý cuối cùng nếu thiếu nguồn và accountability. Đánh giá AI ở cấp sản phẩm chung sẽ bỏ mất khác biệt này.

Nên tạo task-risk matrix: task frequency, error consequence, reversibility và human review requirement. Fit cao nhưng hậu quả sai rất lớn vẫn có thể chỉ cho phép “assist”, không “automate”.

15. TTF và redesign workflow

Khi công nghệ không fit, không phải lúc nào cũng cần thay công nghệ. Có thể chia task thành các bước: AI trích xuất → rule engine kiểm format → chuyên gia xác nhận. Mỗi công nghệ được dùng ở phần nó fit nhất. Đây là logic phối hợp người–công nghệ thay vì hỏi hệ thống có thay người hay không.

Ghi nhớ trong 30 giây

  • TTF hỏi công nghệ có phù hợp nhiệm vụ không.
  • Fit khác usefulness và ease of use.
  • Đơn vị person×task×technology rất hữu ích.
  • Nên đo performance thật nếu có.
  • TTF giúp xác định ranh giới use case của AI/PropTech.

Nguồn tham khảo

  • Goodhue & Thompson (1995), Task-Technology Fit and Individual Performance, MIS Quarterly 19(2), 213–236, DOI 10.2307/249689.

Bài tiếp theo: DeLone & McLean IS Success Model: chất lượng hệ thống, thông tin, hài lòng và lợi ích

📚 Xem toàn bộ 33 bài trong series Mô hình định tính, hành vi & ra quyết định trong BĐS