Cách viết phần đóng góp thực tiễn thành mô hình hoặc khung ứng dụng

Trong luận án DBA theo lộ trình APEL.Q, phần đóng góp thực tiễn là một trong những phần quan trọng nhất. DBA không chỉ yêu cầu ứng viên hiểu lý thuyết, thu thập dữ liệu và phân tích kết quả. DBA còn yêu cầu ứng viên chứng minh nghiên cứu có thể tạo ra giá trị cho thực hành quản trị. Giá trị đó thường được thể hiện qua mô hình, khung ứng dụng, quy trình, bộ tiêu chí, ma trận quyết định hoặc nguyên tắc triển khai.

Tuy nhiên, nhiều ứng viên viết phần đóng góp thực tiễn còn khá chung. Ví dụ: “doanh nghiệp cần nâng cao chất lượng hỗ trợ”, “nhà quản lý cần cải thiện quy trình”, “tổ chức cần tăng cường đào tạo”, hoặc “cần chú trọng trải nghiệm học viên”. Những câu này có thể đúng, nhưng chưa đủ để trở thành đóng góp DBA. Một đóng góp thực tiễn tốt cần cụ thể hơn: ai sử dụng, sử dụng để làm gì, gồm những thành phần nào, dựa trên phát hiện nào, áp dụng trong điều kiện nào và có giới hạn gì.

Theo Van de Ven (2007), nghiên cứu quản trị có giá trị khi tạo ra tri thức có thể kết nối giữa học thuật và thực tiễn quản lý. Với DBA, phần đóng góp thực tiễn chính là nơi thể hiện sự kết nối đó rõ nhất.

Đóng góp thực tiễn là gì?

Đóng góp thực tiễn là phần cho thấy nghiên cứu giúp nhà quản trị, tổ chức, người hành nghề hoặc hệ thống ra quyết định tốt hơn. Đóng góp này không nhất thiết phải là một “phát minh” hoàn toàn mới. Nó có thể là cách tổ chức lại vấn đề, mô hình hoá quy trình, xây dựng khung đánh giá, thiết kế công cụ ra quyết định hoặc đề xuất cách can thiệp dựa trên dữ liệu.

Ví dụ, trong nghiên cứu về học viên trực tuyến, đóng góp thực tiễn có thể là mô hình nhận diện sớm nguy cơ bỏ học. Trong nghiên cứu về triển khai CRM, đóng góp có thể là khung quản trị thay đổi tích hợp giữa công nghệ, quy trình và quản lý tuyến đầu. Trong nghiên cứu về nhân sự, đóng góp có thể là bộ tiêu chí đánh giá trải nghiệm nhân viên mới trong 12 tháng đầu.

Điểm quan trọng là đóng góp phải đi ra từ nghiên cứu. Nó không nên là danh sách khuyến nghị chung được thêm vào cuối luận án. Nó cần được xây dựng từ phát hiện, thảo luận và dữ liệu.

Vì sao nên viết đóng góp thành mô hình hoặc khung?

Mô hình hoặc khung giúp đóng góp trở nên rõ ràng hơn. Nếu ứng viên chỉ viết các khuyến nghị rời rạc, người đọc khó thấy luận án tạo ra giá trị gì. Nếu ứng viên trình bày đóng góp thành mô hình, người đọc có thể thấy cấu trúc, logic, các thành phần và cách sử dụng.

Một mô hình tốt giúp trả lời các câu hỏi: vấn đề cần xử lý là gì, yếu tố nào liên quan, trình tự hành động ra sao, ai chịu trách nhiệm, dữ liệu nào cần theo dõi, và kết quả mong muốn là gì. Một khung tốt giúp nhà quản trị nhìn vấn đề theo hệ thống, thay vì chỉ xử lý từng triệu chứng riêng lẻ.

Ví dụ, thay vì viết “cần hỗ trợ học viên tốt hơn”, ứng viên có thể phát triển “Khung hỗ trợ học viên theo ba tầng”: hỗ trợ phổ quát cho toàn bộ học viên, hỗ trợ mục tiêu cho nhóm có dấu hiệu giảm tương tác, và hỗ trợ chuyên sâu cho nhóm có nguy cơ bỏ học cao. Khung này cụ thể hơn, dễ áp dụng hơn và thể hiện rõ hơn giá trị DBA.

Đóng góp không nên xuất hiện đột ngột ở cuối luận án

Một lỗi phổ biến là ứng viên chỉ bắt đầu viết đóng góp ở chương kết luận, như một phần bổ sung sau khi đã trình bày xong kết quả. Cách này làm đóng góp có vẻ tách rời khỏi nghiên cứu.

Đóng góp thực tiễn cần được chuẩn bị từ trước. Nó bắt đầu từ câu hỏi nghiên cứu, được hỗ trợ bởi khung lý thuyết, được kiểm tra qua dữ liệu, được hình thành trong chương kết quả và được phát triển đầy đủ trong chương thảo luận. Chương kết luận chỉ tổng hợp lại đóng góp, không nên là nơi đầu tiên tạo ra đóng góp.

Nếu mô hình hoặc khung ứng dụng xuất hiện đột ngột, hội đồng có thể hỏi: mô hình này dựa trên dữ liệu nào? Vì sao có các thành phần này? Vì sao không phải thành phần khác? Mỗi bước trong mô hình được chứng minh ở đâu? Nếu ứng viên không trả lời được, đóng góp sẽ bị xem là ý kiến tư vấn, không phải đóng góp nghiên cứu.

Bước 1: Xác định vấn đề thực tiễn mà đóng góp sẽ giải quyết

Trước khi xây dựng mô hình, ứng viên cần xác định rõ vấn đề thực tiễn mà mô hình muốn xử lý. Không nên tạo mô hình quá rộng.

Ví dụ, nếu luận án nghiên cứu học viên trực tuyến, vấn đề thực tiễn có thể không phải là “cải thiện toàn bộ chất lượng đào tạo”, mà là “nhận diện và can thiệp sớm đối với học viên có nguy cơ giảm tương tác”. Nếu luận án nghiên cứu CRM, vấn đề có thể không phải là “chuyển đổi số doanh nghiệp”, mà là “làm thế nào để đội ngũ bán hàng chấp nhận và sử dụng CRM trong quy trình làm việc hằng ngày”.

Vấn đề càng rõ, mô hình càng dễ thiết kế. Nếu vấn đề quá rộng, mô hình sẽ chung chung. Nếu vấn đề đủ cụ thể, mô hình có thể có cấu trúc, người dùng và dữ liệu đầu vào rõ hơn.

Bước 2: Rút các thành phần của mô hình từ phát hiện nghiên cứu

Mô hình hoặc khung ứng dụng nên được xây dựng từ các phát hiện chính. Ứng viên có thể xem lại chương kết quả và chương thảo luận để xác định các yếu tố lặp lại.

Ví dụ, nghiên cứu về học viên trực tuyến có thể có các phát hiện sau: học viên giảm tương tác sau tuần thứ tư, phản hồi học thuật chậm làm tăng rủi ro bỏ học, học viên cần hỗ trợ khác nhau theo mức độ tự chủ, và dữ liệu LMS có thể phát hiện dấu hiệu rủi ro sớm. Từ đó, mô hình có thể gồm bốn thành phần: theo dõi dữ liệu tương tác, phân loại rủi ro, can thiệp hỗ trợ cá nhân hoá, và theo dõi phục hồi.

Nghiên cứu về CRM có thể có các phát hiện: nhân viên không chống lại công nghệ nói chung, mà chống lại quy trình sử dụng không phù hợp; quản lý tuyến đầu ảnh hưởng mạnh đến hành vi sử dụng; đào tạo kỹ thuật không đủ nếu không gắn với tình huống bán hàng; và dữ liệu CRM chưa được dùng trong họp quản trị. Từ đó, khung đóng góp có thể gồm bốn trụ cột: tái thiết kế quy trình, huấn luyện theo tình huống, quản lý tuyến đầu, và tích hợp dữ liệu vào quản trị hiệu suất.

Cách làm này giúp mô hình có nền tảng dữ liệu rõ.

Bước 3: Chọn dạng đóng góp phù hợp

Không phải nghiên cứu nào cũng cần tạo “mô hình”. Đôi khi “khung ứng dụng”, “quy trình”, “bộ tiêu chí” hoặc “ma trận quyết định” phù hợp hơn. Ứng viên nên chọn dạng đóng góp theo bản chất của phát hiện.

Nếu nghiên cứu chỉ ra các thành phần liên quan với nhau, mô hình có thể phù hợp. Nếu nghiên cứu chỉ ra các nhóm yếu tố cần xem xét, khung ứng dụng có thể phù hợp. Nếu nghiên cứu chỉ ra trình tự hành động, quy trình sẽ phù hợp. Nếu nghiên cứu cần hỗ trợ đánh giá, bộ tiêu chí hoặc ma trận có thể phù hợp.

Ví dụ, nghiên cứu về rủi ro bỏ học có thể tạo quy trình can thiệp sớm. Nghiên cứu về năng lực lãnh đạo có thể tạo khung năng lực. Nghiên cứu về lựa chọn chiến lược chuyển đổi số có thể tạo ma trận quyết định. Nghiên cứu về đánh giá hồ sơ APEL.Q có thể tạo bảng tiêu chí hoặc scorecard.

Dạng đóng góp nên phục vụ người sử dụng, không chỉ phục vụ hình thức luận án.

Bước 4: Đặt tên rõ cho mô hình hoặc khung

Một đóng góp thực tiễn nên có tên rõ. Tên không cần quá hoa mỹ, nhưng cần phản ánh đúng chức năng.

Ví dụ:

“Mô hình hỗ trợ học viên trực tuyến theo giai đoạn rủi ro”

“Khung quản trị thay đổi trong triển khai CRM”

“Quy trình 4 bước chuyển dữ liệu học tập thành can thiệp hỗ trợ”

“Bộ tiêu chí đánh giá mức độ sẵn sàng APEL.Q cho DBA”

“Ma trận ưu tiên can thiệp đối với học viên có nguy cơ bỏ học”

Tên rõ giúp người đọc nhớ đóng góp của luận án. Nó cũng giúp ứng viên trình bày tốt hơn trong buổi bảo vệ.

Bước 5: Giải thích từng thành phần của mô hình

Sau khi trình bày mô hình, ứng viên cần giải thích từng thành phần. Không nên chỉ đưa một sơ đồ rồi để người đọc tự hiểu.

Ví dụ, nếu mô hình có bốn thành phần: nhận diện rủi ro, phân loại nhóm học viên, can thiệp hỗ trợ và theo dõi phục hồi, ứng viên cần giải thích từng thành phần. Nhận diện rủi ro dựa trên dữ liệu nào? Phân loại nhóm học viên theo tiêu chí nào? Can thiệp hỗ trợ gồm những hoạt động gì? Theo dõi phục hồi bằng chỉ số nào?

Mỗi thành phần nên liên hệ với phát hiện nghiên cứu. Ví dụ: “Thành phần nhận diện rủi ro được xây dựng từ phát hiện rằng học viên giảm tương tác thường có dấu hiệu trước khi chính thức rút khỏi chương trình”. Cách viết này cho thấy mô hình không phải suy nghĩ chủ quan của ứng viên.

Bước 6: Chỉ ra người sử dụng mô hình

Đóng góp thực tiễn cần có người sử dụng rõ. Ứng viên nên xác định ai có thể dùng mô hình: ban lãnh đạo, quản lý chương trình, đội ngũ học vụ, phòng nhân sự, quản lý bán hàng, cố vấn học tập, chuyên viên chăm sóc khách hàng, hoặc nhà quản lý dự án.

Ví dụ, mô hình hỗ trợ học viên có thể dành cho quản lý chương trình và đội ngũ học vụ. Khung quản trị thay đổi CRM có thể dành cho giám đốc kinh doanh, quản lý tuyến đầu và nhóm triển khai công nghệ. Bộ tiêu chí đánh giá APEL.Q có thể dành cho ứng viên, cố vấn học thuật và chuyên gia đánh giá.

Nếu không xác định người sử dụng, đóng góp sẽ dễ bị chung chung. Một mô hình tốt cần trả lời: ai sẽ dùng, dùng khi nào và dùng để ra quyết định gì.

Bước 7: Chỉ ra dữ liệu đầu vào và đầu ra

Một khung ứng dụng tốt nên có dữ liệu đầu vào và kết quả đầu ra rõ. Điều này giúp mô hình có tính thực hành hơn.

Ví dụ, trong mô hình cảnh báo sớm học viên, dữ liệu đầu vào có thể gồm số lần đăng nhập, tỷ lệ hoàn thành bài học, thời gian phản hồi hỗ trợ, số yêu cầu hỗ trợ, kết quả bài tập và phản hồi học viên. Đầu ra có thể là nhóm rủi ro thấp, trung bình, cao và hành động hỗ trợ tương ứng.

Trong khung quản trị CRM, dữ liệu đầu vào có thể gồm tỷ lệ sử dụng hệ thống, phản hồi người dùng, dữ liệu quy trình bán hàng, số lần nhập liệu thiếu và đánh giá của quản lý tuyến đầu. Đầu ra có thể là danh sách rào cản, mức độ sẵn sàng và kế hoạch can thiệp.

Khi có đầu vào và đầu ra rõ, mô hình không còn là ý tưởng trừu tượng. Nó trở thành công cụ quản trị.

Bước 8: Trình bày điều kiện áp dụng

Không có mô hình nào phù hợp cho mọi bối cảnh. Ứng viên cần trình bày điều kiện áp dụng của mô hình hoặc khung.

Ví dụ, mô hình hỗ trợ học viên trực tuyến có thể phù hợp với chương trình học online, người học trưởng thành, học bán thời gian và có LMS ghi nhận dữ liệu tương tác. Nó có thể không phù hợp trực tiếp với chương trình học hoàn toàn trực tiếp hoặc nhóm học viên không sử dụng nền tảng số.

Khung quản trị CRM có thể phù hợp với doanh nghiệp có đội ngũ bán hàng, hệ thống CRM và quy trình bán hàng có thể chuẩn hoá. Nó có thể cần điều chỉnh nếu áp dụng trong doanh nghiệp siêu nhỏ hoặc tổ chức chưa có dữ liệu quy trình.

Việc nêu điều kiện áp dụng giúp đóng góp có trách nhiệm hơn và dễ bảo vệ hơn.

Bước 9: Nêu giới hạn của mô hình

Một mô hình DBA tốt cần có giới hạn. Không nên trình bày mô hình như giải pháp chắc chắn thành công. Mô hình được xây dựng từ dữ liệu trong một bối cảnh nhất định, nên cần được hiểu trong phạm vi đó.

Ứng viên có thể viết: “Mô hình này được phát triển từ dữ liệu của một chương trình trực tuyến cụ thể và chưa được kiểm định trên nhiều tổ chức khác nhau. Vì vậy, mô hình nên được xem như khung ứng dụng ban đầu, cần điều chỉnh khi áp dụng trong các bối cảnh có đặc điểm người học, hệ thống hỗ trợ hoặc công nghệ khác.”

Cách viết này không làm giảm giá trị mô hình. Nó làm mô hình trở nên học thuật và trung thực hơn.

Bước 10: Liên kết mô hình với đóng góp học thuật

Dù phần này tập trung vào đóng góp thực tiễn, ứng viên vẫn nên liên kết mô hình với đóng góp học thuật. Một mô hình thực tiễn tốt có thể giúp mở rộng cách hiểu về một khái niệm hoặc lý thuyết.

Ví dụ, mô hình hỗ trợ học viên theo giai đoạn rủi ro có thể đóng góp vào cách hiểu learner engagement như một quá trình thay đổi theo thời gian, không phải trạng thái cố định. Khung quản trị CRM có thể mở rộng cách tiếp cận chấp nhận công nghệ bằng cách nhấn mạnh vai trò của quy trình và quản lý tuyến đầu. Mô hình APEL.Q scorecard có thể đóng góp vào cách đánh giá năng lực nghiên cứu trước đó theo tiêu chí có cấu trúc.

Liên kết này giúp luận án không bị xem là báo cáo tư vấn thuần tuý. Nó cho thấy thực tiễn và học thuật được kết nối.

Cách trình bày mô hình trong luận án

Mô hình nên được trình bày bằng cả sơ đồ và phần giải thích. Sơ đồ giúp người đọc nhìn thấy cấu trúc tổng thể. Phần giải thích giúp người đọc hiểu logic và bằng chứng.

Một cách trình bày tốt gồm: giới thiệu mục đích của mô hình, sơ đồ mô hình, giải thích từng thành phần, liên hệ từng thành phần với phát hiện, nêu cách sử dụng mô hình, nêu điều kiện áp dụng, nêu giới hạn.

Không nên để sơ đồ quá phức tạp. Một mô hình quá nhiều mũi tên, quá nhiều khối và quá nhiều thuật ngữ có thể gây khó hiểu. Mô hình tốt nên đủ đơn giản để sử dụng, nhưng đủ sâu để phản ánh phát hiện nghiên cứu.

Ví dụ cấu trúc một phần đóng góp thực tiễn

Ứng viên có thể viết phần đóng góp thực tiễn theo cấu trúc sau:

Thứ nhất, nhắc lại vấn đề thực tiễn mà nghiên cứu xử lý.
Thứ hai, tóm tắt phát hiện dẫn đến đóng góp.
Thứ ba, giới thiệu mô hình hoặc khung đề xuất.
Thứ tư, giải thích từng thành phần của mô hình.
Thứ năm, trình bày cách sử dụng mô hình trong thực tiễn.
Thứ sáu, nêu điều kiện áp dụng và giới hạn.
Thứ bảy, liên hệ mô hình với đóng góp học thuật hoặc hướng nghiên cứu tiếp theo.

Cấu trúc này giúp phần đóng góp rõ, có logic và dễ bảo vệ.

Những lỗi thường gặp khi viết đóng góp thực tiễn

Lỗi thứ nhất là viết đóng góp quá chung, chỉ như lời khuyên quản lý.

Lỗi thứ hai là tạo mô hình nhưng không liên kết với dữ liệu.

Lỗi thứ ba là mô hình quá phức tạp, khó hiểu và khó sử dụng.

Lỗi thứ tư là không xác định ai sẽ dùng mô hình.

Lỗi thứ năm là không nêu điều kiện áp dụng và giới hạn.

Lỗi thứ sáu là đưa ra cam kết quá mạnh, như mô hình chắc chắn giải quyết được vấn đề.

Lỗi thứ bảy là tách đóng góp thực tiễn khỏi lý thuyết, khiến luận án giống báo cáo tư vấn hơn là nghiên cứu DBA.

Kết luận

Phần đóng góp thực tiễn là nơi luận án DBA thể hiện giá trị ứng dụng rõ nhất. Trong lộ trình APEL.Q, phần này càng quan trọng vì ứng viên cần chứng minh rằng nền tảng nghiên cứu cũ, dữ liệu thực tiễn và phân tích mới đã được nâng cấp thành một công trình có giá trị cho quản trị.

Ứng viên nên chuyển đóng góp thành mô hình, khung, quy trình, bộ tiêu chí hoặc ma trận ứng dụng nếu phù hợp. Đóng góp cần xuất phát từ phát hiện nghiên cứu, có người sử dụng rõ, có dữ liệu đầu vào, có đầu ra, có điều kiện áp dụng và có giới hạn. Một mô hình tốt không chỉ làm luận án đẹp hơn, mà giúp hội đồng thấy rõ nghiên cứu có thể tạo ra giá trị thực tế như thế nào.

Trong DBA, đóng góp thực tiễn không phải là phần trang trí cuối luận án. Đó là kết quả của toàn bộ quá trình nghiên cứu: từ vấn đề, lý thuyết, phương pháp, dữ liệu, phát hiện đến thảo luận. Khi phần này được viết tốt, luận án sẽ thể hiện đúng tinh thần Tiến sĩ ứng dụng.

Tài liệu tham khảo

Coghlan, D., & Brannick, T. (2014). Doing action research in your own organization (4th ed.). SAGE Publications.

Denyer, D., Tranfield, D., & Van Aken, J. E. (2008). Developing design propositions through research synthesis. Organization Studies, 29(3), 393–413.

Romme, A. G. L. (2003). Making a difference: Organization as design. Organization Science, 14(5), 558–573.

Van de Ven, A. H. (2007). Engaged scholarship: A guide for organizational and social research. Oxford University Press.

Whetten, D. A. (1989). What constitutes a theoretical contribution? Academy of Management Review, 14(4), 490–495.