Vì sao có nhiều kinh nghiệm quản lý vẫn chưa đủ cho DBA?

Nhiều ứng viên APEL.Q cho DBA là nhà quản lý cấp cao, chủ doanh nghiệp, giám đốc bộ phận, chuyên gia tư vấn, trưởng dự án hoặc người đã có nhiều năm kinh nghiệm trong lĩnh vực chuyên môn. Đây là một lợi thế rất lớn. Kinh nghiệm quản lý giúp ứng viên nhìn thấy vấn đề thật, hiểu bối cảnh tổ chức, tiếp cận dữ liệu thực tiễn và có khả năng phát triển đóng góp ứng dụng.

Tuy nhiên, kinh nghiệm quản lý dù phong phú vẫn chưa tự động đủ cho DBA. DBA là chương trình Tiến sĩ ứng dụng, không phải chương trình xác nhận thâm niên nghề nghiệp. Ứng viên cần chứng minh rằng kinh nghiệm đó có thể được chuyển hoá thành nghiên cứu: có vấn đề nghiên cứu rõ, có câu hỏi nghiên cứu, có khung lý thuyết, có dữ liệu, có phương pháp phân tích, có phát hiện và có đóng góp thực tiễn được xây dựng trên bằng chứng.

Theo Costley và Lester (2012), các chương trình doctorate gắn với thực hành nghề nghiệp cần đánh giá khả năng tạo tri thức từ thực tiễn, không chỉ đánh giá kinh nghiệm thực tiễn. Với APEL.Q, điều này có nghĩa là ứng viên không chỉ cần cho thấy mình đã “làm nhiều”, mà phải cho thấy mình có thể nghiên cứu, phân tích và phát triển tri thức từ những gì đã làm.

Kinh nghiệm quản lý là lợi thế, không phải bằng chứng tự động

Kinh nghiệm quản lý giúp ứng viên có góc nhìn thực tế mà nhiều người nghiên cứu thuần học thuật có thể không có. Một CEO hiểu rõ áp lực chiến lược. Một trưởng phòng nhân sự hiểu khó khăn trong giữ chân nhân viên. Một giám đốc học vụ hiểu vấn đề hỗ trợ học viên. Một trưởng dự án chuyển đổi số hiểu sự kháng cự của người dùng trong tổ chức.

Tuy nhiên, kinh nghiệm chỉ trở thành bằng chứng DBA khi được tổ chức thành nghiên cứu. Nếu ứng viên chỉ nói “tôi có 15 năm kinh nghiệm”, “tôi đã quản lý nhiều dự án”, “tôi đã điều hành doanh nghiệp”, hội đồng vẫn chưa đủ cơ sở để đánh giá năng lực nghiên cứu. Hội đồng cần biết: kinh nghiệm đó tạo ra vấn đề nghiên cứu nào, dữ liệu nào chứng minh vấn đề, ứng viên đã phân tích ra sao, và kết quả có thể đóng góp gì cho quản trị.

Nói cách khác, kinh nghiệm là nguyên liệu. Luận án DBA là sản phẩm nghiên cứu được tạo ra từ nguyên liệu đó.

Chức danh cao không thay thế câu hỏi nghiên cứu

Một hiểu lầm thường gặp là ứng viên có chức danh cao thì hồ sơ tự động mạnh. Chức danh có thể cho thấy mức độ trách nhiệm nghề nghiệp, nhưng không thay thế câu hỏi nghiên cứu.

Ví dụ, một giám đốc vận hành có thể đã quản lý nhiều quy trình phức tạp. Tuy nhiên, nếu luận án không có câu hỏi rõ như “yếu tố nào ảnh hưởng đến hiệu quả tái thiết kế quy trình trong doanh nghiệp dịch vụ?” hoặc “mô hình quản trị nào giúp giảm sai lỗi vận hành trong giai đoạn tăng trưởng nhanh?”, kinh nghiệm đó vẫn chưa được chuyển thành nghiên cứu.

Một chủ doanh nghiệp có thể đã xây dựng hệ thống bán hàng thành công. Tuy nhiên, DBA cần đi xa hơn câu chuyện thành công cá nhân. Cần xác định cơ chế, dữ liệu, phân tích và mô hình có thể giúp người khác hiểu hoặc áp dụng trong bối cảnh tương đồng.

Chức danh giúp tạo bối cảnh. Câu hỏi nghiên cứu mới tạo trục học thuật.

Thành tích thực tế không tự động là đóng góp DBA

Một doanh nghiệp tăng trưởng, một dự án thành công, một chương trình đào tạo có nhiều học viên hoặc một hệ thống mới được triển khai hiệu quả đều là thành tích thực tế. Nhưng thành tích không tự động là đóng góp DBA.

Đóng góp DBA cần trả lời: từ thành tích đó, nghiên cứu rút ra được hiểu biết gì có thể chia sẻ, kiểm tra, áp dụng hoặc phát triển? Nếu dự án thành công, vì sao thành công? Những yếu tố nào quan trọng? Dữ liệu nào chứng minh? Mô hình nào có thể được đề xuất? Điều kiện áp dụng là gì? Giới hạn ở đâu?

Ví dụ, ứng viên nói “tôi đã triển khai CRM thành công” là chưa đủ. Một đóng góp DBA có thể là “khung quản trị thay đổi trong triển khai CRM cho đội ngũ bán hàng, gồm tái thiết kế quy trình, huấn luyện theo tình huống, hỗ trợ quản lý tuyến đầu và tích hợp dữ liệu vào đánh giá hiệu suất”. Đóng góp thứ hai có cấu trúc, có thể phân tích và có thể thảo luận học thuật.

Kinh nghiệm cần được chuyển thành vấn đề nghiên cứu

Bước đầu tiên để sử dụng kinh nghiệm quản lý trong DBA là chuyển nó thành vấn đề nghiên cứu. Vấn đề nghiên cứu không nên chỉ là “tôi đã gặp khó khăn này”. Nó cần được diễn đạt như một vấn đề có ý nghĩa cho tổ chức, lĩnh vực hoặc thực hành quản trị.

Ví dụ, kinh nghiệm thực tế là: “nhân viên không chịu dùng hệ thống mới”. Vấn đề nghiên cứu có thể là: “sự thiếu tích hợp giữa hệ thống công nghệ và quy trình làm việc khiến việc chấp nhận CRM trong đội ngũ bán hàng bị hạn chế”. Cách diễn đạt thứ hai có khả năng nghiên cứu cao hơn.

Kinh nghiệm thực tế là: “học viên online hay bỏ học”. Vấn đề nghiên cứu có thể là: “hệ thống hỗ trợ học viên chưa nhận diện được dấu hiệu giảm tương tác trước khi học viên rút khỏi chương trình”. Đây là vấn đề có thể thu thập dữ liệu, phân tích và phát triển mô hình can thiệp.

Kinh nghiệm chỉ trở thành nghiên cứu khi được đặt thành vấn đề có thể điều tra.

Kinh nghiệm cần có dữ liệu đi kèm

Một người quản lý có thể biết rất rõ vấn đề qua quan sát hằng ngày. Tuy nhiên, luận án DBA không thể chỉ dựa trên “tôi thấy”, “tôi nghĩ”, hoặc “theo kinh nghiệm của tôi”. Cần có dữ liệu.

Dữ liệu có thể là khảo sát, phỏng vấn, dữ liệu hệ thống, báo cáo vận hành, phản hồi khách hàng, dữ liệu nhân sự, tài liệu dự án hoặc dữ liệu trước và sau can thiệp. Dữ liệu giúp kinh nghiệm trở thành bằng chứng.

Ví dụ, thay vì chỉ nói “học viên thường mất động lực”, ứng viên có thể dùng dữ liệu LMS để cho thấy tần suất đăng nhập giảm sau tuần thứ tư, dữ liệu phỏng vấn để giải thích nguyên nhân, và dữ liệu hỗ trợ học viên để xác định khoảng trống phản hồi. Khi đó, kinh nghiệm quản lý được củng cố bằng bằng chứng.

Dữ liệu không nhất thiết phải quá lớn, nhưng phải phù hợp, rõ nguồn và được phân tích có hệ thống.

Kinh nghiệm cần được soi chiếu bằng lý thuyết

DBA là nghiên cứu ứng dụng, nhưng vẫn cần lý thuyết. Lý thuyết giúp ứng viên không chỉ kể lại kinh nghiệm, mà hiểu kinh nghiệm ở mức sâu hơn.

Ví dụ, một nhà quản lý có thể thấy nhân viên không dùng CRM. Lý thuyết chấp nhận công nghệ giúp phân tích nhận thức về tính hữu ích và tính dễ sử dụng. Lý thuyết quản trị thay đổi giúp phân tích truyền thông, lãnh đạo, kháng cự và hỗ trợ tổ chức. Lý thuyết thiết kế công việc giúp phân tích sự phù hợp giữa hệ thống và quy trình.

Tương tự, một nhà quản lý chương trình có thể thấy học viên bỏ học. Các lý thuyết về learner engagement, self-regulated learning hoặc student support giúp phân tích động lực học tập, mức độ tham gia, hỗ trợ học thuật và khả năng tự học.

Lý thuyết không làm kinh nghiệm trở nên xa thực tế. Lý thuyết giúp kinh nghiệm được phân tích sâu và có khả năng đóng góp cho tri thức quản trị.

Kinh nghiệm cần được phản biện

Một người có nhiều kinh nghiệm thường có niềm tin mạnh về vấn đề mình đã trải qua. Đây là lợi thế, nhưng cũng là rủi ro. Ứng viên có thể đã có sẵn câu trả lời trước khi nghiên cứu. Ví dụ, ứng viên tin rằng học viên bỏ học vì thiếu động lực, nhân viên chống CRM vì lười thay đổi, hoặc khách hàng rời bỏ vì giá cao. Dữ liệu có thể cho thấy nguyên nhân khác.

DBA đòi hỏi ứng viên biết phản biện chính giả định của mình. Nếu dữ liệu cho thấy vấn đề không giống điều ứng viên nghĩ ban đầu, ứng viên cần sẵn sàng điều chỉnh. Đây là điểm khác biệt giữa tư duy quản lý thuần tuý và tư duy nghiên cứu.

Theo Schön (1983), người hành nghề chuyên nghiệp cần biết phản tư trong hành động và về hành động. Với DBA, phản tư này cần được nâng lên thành phản biện học thuật: kiểm tra giả định bằng dữ liệu và lý thuyết.

Kinh nghiệm cá nhân cần vượt khỏi câu chuyện cá nhân

Một luận án DBA có thể xuất phát từ trải nghiệm cá nhân, nhưng không nên dừng lại ở câu chuyện cá nhân. Hội đồng cần thấy giá trị rộng hơn: nghiên cứu giúp hiểu một vấn đề quản trị, phát triển một mô hình, đề xuất một khung ứng dụng hoặc tạo ra bài học cho bối cảnh tương đồng.

Ví dụ, câu chuyện “tôi đã xây dựng bộ phận chăm sóc khách hàng thành công” có thể rất ấn tượng, nhưng DBA cần chuyển thành nghiên cứu về “mô hình quản trị trải nghiệm sau mua trong doanh nghiệp dịch vụ”. Câu chuyện “tôi đã giảm tỷ lệ bỏ học” cần chuyển thành “khung can thiệp sớm dựa trên dữ liệu tương tác học tập”.

Khi kinh nghiệm cá nhân được khái quát thành mô hình hoặc khung có điều kiện áp dụng, nó bắt đầu trở thành đóng góp DBA.

Kinh nghiệm quản lý thường thiếu phần phương pháp

Nhiều nhà quản lý xử lý vấn đề rất hiệu quả, nhưng không ghi lại quy trình dưới dạng phương pháp nghiên cứu. Họ có thể đã phỏng vấn nhân viên, phân tích số liệu, thử nghiệm giải pháp, đo kết quả, nhưng tất cả diễn ra trong thực tiễn quản lý, không được trình bày như nghiên cứu.

Trong APEL.Q, ứng viên cần tái cấu trúc kinh nghiệm này thành phương pháp. Cần nêu rõ dữ liệu nào được dùng, thu thập khi nào, từ ai, bằng cách nào, phân tích ra sao, kết quả được đánh giá thế nào và giới hạn là gì.

Ví dụ, nếu ứng viên đã triển khai một giải pháp đào tạo nội bộ, chương phương pháp cần nêu dữ liệu trước đào tạo, dữ liệu sau đào tạo, nhóm người tham gia, công cụ đánh giá, phản hồi người học và cách phân tích thay đổi. Nếu thiếu bước này, luận án dễ giống báo cáo dự án hơn là nghiên cứu DBA.

Kinh nghiệm cần có minh chứng vai trò cá nhân

Với nhà quản lý cấp cao, nhiều thành quả là kết quả của cả tổ chức hoặc đội ngũ. Vì vậy, ứng viên cần làm rõ vai trò cá nhân. Hội đồng không thể mặc định mọi thành quả của tổ chức đều là đóng góp nghiên cứu cá nhân của ứng viên.

Ứng viên cần nêu rõ mình đã trực tiếp làm gì: xác định vấn đề, thiết kế chiến lược, thu thập dữ liệu, phân tích báo cáo, xây dựng mô hình, triển khai giải pháp, đánh giá kết quả hay viết tài liệu. Nếu có thể, nên có thư xác nhận, biên bản dự án, báo cáo có tên, email phân công hoặc tài liệu minh chứng.

Vai trò cá nhân rõ giúp kinh nghiệm quản lý trở thành minh chứng có giá trị hơn trong APEL.Q.

Kinh nghiệm chưa được viết lại theo ngôn ngữ học thuật

Một rào cản khác là ngôn ngữ. Nhà quản lý thường viết theo ngôn ngữ hành động: vấn đề, giải pháp, kết quả, KPI, triển khai, hiệu quả. Luận án DBA cần thêm ngôn ngữ nghiên cứu: vấn đề nghiên cứu, câu hỏi, khung lý thuyết, dữ liệu, phương pháp, phát hiện, thảo luận, đóng góp và giới hạn.

Ví dụ, trong báo cáo quản lý, ứng viên có thể viết: “Chúng tôi cải thiện quy trình để tăng tỷ lệ hoàn thành.” Trong luận án, cần viết: “Dữ liệu cho thấy quy trình hỗ trợ hiện tại thiếu điểm can thiệp trong giai đoạn học viên giảm tương tác. Nghiên cứu phát triển mô hình hỗ trợ theo giai đoạn nhằm cải thiện khả năng duy trì học tập.”

Hai cách viết không mâu thuẫn. Cách viết thứ hai phù hợp hơn với DBA vì có dữ liệu, phát hiện và mô hình nghiên cứu.

Cách chuyển kinh nghiệm quản lý thành nền tảng DBA

Ứng viên có thể chuyển kinh nghiệm quản lý thành nền tảng DBA qua sáu bước.

Bước thứ nhất là chọn một vấn đề quản trị cụ thể từ kinh nghiệm. Không chọn quá rộng. Bước thứ hai là biến vấn đề đó thành câu hỏi nghiên cứu. Bước thứ ba là xác định dữ liệu đã có và dữ liệu cần bổ sung. Bước thứ tư là chọn khung lý thuyết giúp giải thích vấn đề. Bước thứ năm là phân tích dữ liệu để tạo phát hiện. Bước thứ sáu là phát triển đóng góp thực tiễn thành mô hình, khung hoặc quy trình.

Ví dụ, từ kinh nghiệm “đã quản lý chương trình online nhiều năm”, ứng viên có thể chọn vấn đề “học viên giảm tương tác trong 12 tuần đầu”. Câu hỏi nghiên cứu là “hệ thống hỗ trợ học viên nên được thiết kế thế nào để nhận diện và can thiệp sớm?”. Dữ liệu gồm LMS, phỏng vấn học viên và tài liệu hỗ trợ. Lý thuyết gồm learner engagement và student support. Phân tích tạo ra phát hiện về điểm rủi ro. Đóng góp là mô hình can thiệp sớm.

Đây là cách kinh nghiệm được nâng cấp thành luận án DBA.

Những lỗi thường gặp của ứng viên giàu kinh nghiệm

Lỗi thứ nhất là cho rằng thâm niên nghề nghiệp đủ thay thế nghiên cứu. DBA cần nhiều hơn thâm niên.

Lỗi thứ hai là kể quá nhiều câu chuyện thành công nhưng thiếu dữ liệu.

Lỗi thứ ba là đưa ra kết luận quá mạnh dựa trên kinh nghiệm cá nhân.

Lỗi thứ tư là thiếu khung lý thuyết vì cho rằng thực tiễn đã đủ rõ.

Lỗi thứ năm là nhầm báo cáo tư vấn với luận án DBA.

Lỗi thứ sáu là không làm rõ vai trò cá nhân trong thành quả của tổ chức.

Lỗi thứ bảy là không chấp nhận dữ liệu trái với giả định ban đầu.

Lỗi thứ tám là viết luận án như tài liệu quản lý nội bộ, thiếu ngôn ngữ học thuật.

Kết luận

Kinh nghiệm quản lý là một lợi thế rất lớn trong APEL.Q cho DBA, nhưng chưa tự động đủ để đáp ứng chuẩn Tiến sĩ ứng dụng. DBA không chỉ đánh giá việc ứng viên đã làm gì trong nghề nghiệp, mà đánh giá khả năng ứng viên chuyển kinh nghiệm đó thành nghiên cứu có câu hỏi rõ, dữ liệu phù hợp, phương pháp minh bạch, phân tích có cơ sở và đóng góp thực tiễn có cấu trúc.

Ứng viên có nhiều kinh nghiệm cần tránh xem kinh nghiệm như bằng chứng tự đủ. Thay vào đó, cần xem kinh nghiệm như nguồn dữ liệu, nguồn vấn đề và nguồn bối cảnh để phát triển nghiên cứu. Khi kinh nghiệm được soi chiếu bằng lý thuyết, kiểm tra bằng dữ liệu và trình bày thành mô hình hoặc khung ứng dụng, nó mới trở thành nền tảng mạnh cho luận án DBA.

Trong APEL.Q, người có kinh nghiệm không cần bắt đầu từ con số không. Nhưng họ vẫn cần thực hiện bước quan trọng nhất: chuyển từ người đã làm thành người nghiên cứu điều mình đã làm, để tạo ra tri thức có giá trị cho thực hành quản trị.

Tài liệu tham khảo

Costley, C., & Lester, S. (2012). Work-based doctorates: Professional extension at the highest levels. Studies in Higher Education, 37(3), 257–269.

Fox, M., Martin, P., & Green, G. (2007). Doing practitioner research. SAGE Publications.

Schön, D. A. (1983). The reflective practitioner: How professionals think in action. Basic Books.

Scott, D., Brown, A., Lunt, I., & Thorne, L. (2004). Professional doctorates: Integrating professional and academic knowledge. Open University Press.

Wellington, J., & Sikes, P. (2006). “A doctorate in a tight compartment”: Why do students choose a professional doctorate and what impact does it have on their personal and professional lives? Studies in Higher Education, 31(6), 723–734.