Một công nghệ có nhiều chức năng chưa chắc được dùng. Người dùng trước hết tự hỏi: công cụ này có giúp công việc tốt hơn không, và sử dụng có tốn quá nhiều công sức không? Technology Acceptance Model – TAM – cô đọng bài toán chấp nhận công nghệ vào hai nhận thức rất nổi tiếng: perceived usefulness và perceived ease of use.
TAM đặc biệt hữu ích khi mục tiêu nghiên cứu là chấp nhận một hệ thống cụ thể ở cấp cá nhân. Nhưng chính vì đơn giản và nổi tiếng, TAM cũng rất dễ bị lạm dụng: thêm biến tùy ý, đo một lần rồi tuyên bố hành vi, hoặc dùng TAM cho câu hỏi thực ra là chất lượng hệ thống.
Chuyên đề: Mô hình định tính, hành vi & ra quyết định trong BĐS · Bài 27 · 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. Hai cấu trúc cốt lõi
Perceived Usefulness – PU, nhận thức về tính hữu ích là mức người dùng tin rằng sử dụng hệ thống sẽ cải thiện hiệu quả công việc. Perceived Ease of Use – PEOU, nhận thức về tính dễ sử dụng là mức người dùng tin rằng sử dụng hệ thống không đòi hỏi quá nhiều nỗ lực.
Davis phát triển và kiểm định các thang đo PU và PEOU; nghiên cứu năm 1989 cho thấy tính hữu ích có liên hệ mạnh với sử dụng, và dễ sử dụng có quan hệ với hữu ích cũng như chấp nhận.
2. Cấu trúc TAM nên được hiểu theo phiên bản nghiên cứu
TAM gốc bao gồm PU, PEOU, thái độ, ý định và sử dụng. Nhiều nghiên cứu sau rút gọn, bỏ thái độ và cho PU/PEOU tác động trực tiếp tới ý định. Vì vậy khi viết “dùng TAM”, phải vẽ rõ phiên bản nào, không được mặc nhiên coi mọi sơ đồ có PU–PEOU là TAM chuẩn.
Một quan hệ quan trọng thường được giữ là PEOU → PU: công nghệ dễ dùng có thể được cảm nhận hữu ích hơn vì giảm effort và làm lợi ích dễ đạt.
3. TAM trả lời câu hỏi nào?
- Người dùng có thấy hệ thống hữu ích cho công việc không?
- Họ có thấy khó sử dụng không?
- Hai nhận thức này có liên hệ với ý định sử dụng không?
- Ý định có chuyển thành sử dụng thật không?
TAM không trực tiếp trả lời hệ thống có dữ liệu chính xác hay không, chất lượng dịch vụ hỗ trợ có tốt hay không, hay công nghệ có phù hợp task hay không. Những câu hỏi đó thuộc D&M IS Success, TTF hoặc các mô hình khác.
4. Cấu trúc dữ liệu khảo sát TAM
| respondent_id | PU1 | PU2 | PU3 | PEOU1 | PEOU2 | PEOU3 | BI1 | BI2 | ACTUAL_USE |
|---|---|---|---|---|---|---|---|---|---|
| U001 | 6 | 6 | 7 | 4 | 5 | 4 | 6 | 6 | 12 |
Một người là một dòng. Các cột PU/PEOU/BI là biến quan sát của các cấu trúc tiềm ẩn. ACTUAL_USE nên lấy từ log nếu có. Nếu hệ thống chưa triển khai, chỉ có thể nghiên cứu intention/anticipated acceptance, phải nói rõ.
5. Ví dụ thang đo trong ngữ cảnh BĐS
Với phần mềm hỗ trợ định giá, câu PU nên xoay quanh hiệu quả công việc: giảm thời gian, nâng chất lượng phân tích, hỗ trợ ra quyết định. PEOU tập trung học và thao tác: dễ học, dễ tương tác, dễ trở nên thành thạo. Không nên biến PU thành câu hỏi về “tôi thích hệ thống” hoặc PEOU thành “hệ thống có giao diện đẹp”.
6. Mẫu khảo sát và thời điểm đo
Đo TAM trước khi người dùng từng trải nghiệm sẽ dễ phản ánh kỳ vọng hơn trải nghiệm. Nếu muốn đánh giá chấp nhận thực tế, nên cho dùng thử hoặc đo sau một giai đoạn sử dụng. Thiết kế tốt có thể đo trước triển khai, sau đào tạo và sau vài tháng để thấy nhận thức thay đổi.
7. Case: môi giới dùng CRM tích hợp AI
Nếu PU thấp vì môi giới không thấy CRM giúp chốt giao dịch, thêm tutorial chưa chắc hiệu quả. Nếu PU cao nhưng PEOU thấp do nhập dữ liệu phức tạp, cải thiện luồng nhập và tự động hóa có thể tác động mạnh. TAM giúp phân biệt hai kiểu vấn đề.
8. Từ khảo sát tới mô hình đo lường
PU và PEOU là cấu trúc tiềm ẩn nên cần kiểm độ tin cậy và giá trị hội tụ/phân biệt trước khi diễn giải đường quan hệ. Không nên chỉ tính trung bình câu hỏi rồi chạy hồi quy mà bỏ kiểm thang đo nếu nghiên cứu theo SEM.
Bài 43 sẽ đi sâu cách chuyển mô hình lý thuyết thành giả thuyết, thang đo và dữ liệu.
9. TAM và biến kiểm soát
Tuổi, kinh nghiệm số, loại công việc hoặc mức bắt buộc có thể ảnh hưởng kết quả, nhưng không phải vì vậy mà thêm tất cả vào mô hình chính. Biến kiểm soát nên có lý do và được tách khỏi các cấu trúc cốt lõi.
10. Khi nào không nên dùng TAM?
- Đơn vị phân tích là doanh nghiệp → cân nhắc TOE.
- Câu hỏi là hệ thống thành công tới đâu → D&M.
- Câu hỏi là công nghệ có fit với task → TTF.
- Câu hỏi là tiếp tục dùng sau trải nghiệm → ECM.
- Câu hỏi là chuyển từ nền tảng cũ sang mới → PPM.
11. Sai lầm thường gặp
- Thêm hàng chục biến rồi vẫn gọi là TAM.
- Đo một câu cho mỗi cấu trúc.
- Nhầm PEOU với chất lượng hệ thống.
- Dùng intention thay actual use nhưng kết luận như hành vi.
- Không chỉ rõ phiên bản TAM.
12. Bài tập thực hành
Chọn một công nghệ BĐS: CRM, GIS web, AI định giá, ký số hoặc ứng dụng cư dân. Viết 4 item PU, 4 item PEOU, 3 item BI, xác định cách lấy log use, và nêu thời điểm đo. Sau đó giải thích một can thiệp nếu PU thấp và một can thiệp nếu PEOU thấp.
13. Measurement model của TAM
PU và PEOU thường được xem là latent constructs phản ánh qua nhiều item. Trước khi kiểm đường PU → BI hay PEOU → PU, cần kiểm item có tải đúng cấu trúc, độ tin cậy và phân biệt PU với PEOU. Nếu item PU thực chất hỏi “dễ dùng” thì mô hình đo lường đã sai trước khi structural model bắt đầu.
Trong nghiên cứu học thuật có thể dùng CFA/SEM; trong nghiên cứu quản trị nhỏ, ít nhất cần kiểm consistency và nội dung item. Không nên lấy Cronbach’s alpha cao làm bằng chứng duy nhất rằng thang đo đúng.
14. TAM theo thời gian
PEOU thường quan trọng ở giai đoạn học; sau khi đã quen, PU có thể trở nên nổi bật hơn. Vì vậy kết quả survey sau 30 phút demo không nên suy rộng cho sử dụng sáu tháng. Nếu mục tiêu là triển khai thật, nên thiết kế wave: trước dùng → sau onboarding → sau usage ổn định.
Log use có thể gồm active days, task completion và feature depth. Một người login mỗi ngày nhưng chỉ xem dashboard khác một người hoàn tất workflow chính.
Ghi nhớ trong 30 giây
- TAM cốt lõi: tính hữu ích và tính dễ sử dụng.
- PU/PEOU là nhận thức, không phải chất lượng khách quan.
- Cần tách ý định khỏi sử dụng thực tế.
- Thang đo nhiều biến quan sát tốt hơn một câu đơn.
- TAM phù hợp cấp cá nhân và một công nghệ cụ thể.
Nguồn tham khảo
- Davis, F.D. (1989), Perceived Usefulness, Perceived Ease of Use, and User Acceptance of Information Technology, MIS Quarterly 13(3), 319–340, DOI 10.2307/249008.
- Davis, Bagozzi & Warshaw (1989), User Acceptance of Computer Technology: A Comparison of Two Theoretical Models, Management Science 35(8), 982–1003.
Bài tiếp theo: TAM mở rộng: niềm tin, rủi ro, chất lượng thông tin và các biến bổ sung