Mở đầu — vì sao bài này quan trọng
Có một sự thật ít ai nói với bạn khi mới lên làm quản lý: phần lớn thời gian của bạn không còn dành cho việc "làm việc" nữa, mà dành cho việc "ra quyết định" và "giúp người khác ra quyết định". Và đây chính là chỗ nhiều first-time manager mắc kẹt.
Bạn có để ý không? Có những cuộc họp kéo dài hai tiếng đồng hồ, mọi người tranh luận sôi nổi, rồi kết thúc mà chẳng ai biết rốt cuộc ai là người chốt. Tuần sau họp lại, vấn đề vẫn nguyên. Hoặc ngược lại: một quyết định được đưa ra chóng vánh, nhưng ba tuần sau bộ phận khác nổi giận vì "sao không hỏi ý kiến tụi tôi". Cả hai tình huống đều có chung một gốc rễ: không ai làm rõ ai đóng vai trò gì trong quyết định đó.
Ở Việt Nam, vấn đề này còn tinh vi hơn. Văn hóa của chúng ta thường mặc định "sếp quyết hết", nên khi bạn muốn phân quyền cho team tự quyết một số việc, mọi thứ trở nên mập mờ: nhân viên không dám quyết vì sợ vượt quyền, còn bạn thì bực vì "sao việc gì cũng phải hỏi tôi". Đây không phải lỗi thái độ. Đây là lỗi thiết kế — bạn chưa định nghĩa rõ luật chơi của việc ra quyết định.
Hai framework trong bài này — RAPID (của Bain & Company) và RACI — chính là công cụ để bạn thiết kế luật chơi đó. Chúng không giúp bạn ra quyết định tốt hơn về mặt nội dung, nhưng chúng giúp bạn ra quyết định nhanh hơn, rõ ràng hơn, và ít drama hơn. Với một first-time manager, đó là một trong những đòn bẩy lớn nhất để team của bạn vận hành trơn tru.
Khái niệm cốt lõi
Vấn đề gốc: nhầm lẫn giữa "tham gia" và "quyết định"
Trước khi đi vào framework, hãy nắm một nguyên tắc nền tảng: tham gia vào quyết định khác với sở hữu quyết định. Rất nhiều xung đột trong team đến từ chỗ ai đó nghĩ rằng "tôi có ý kiến nghĩa là tôi có quyền quyết", trong khi thực tế họ chỉ đóng vai trò góp ý.
Một quyết định lành mạnh cần được đảm nhận rõ ràng ở từng vai. Cả RAPID và RACI đều là các "mô hình phân vai" (role clarity framework). Điểm khác biệt là góc nhìn: RAPID tập trung vào dòng chảy của một quyết định cụ thể, còn RACI tập trung vào ai làm gì trên toàn bộ một dự án hay quy trình.
RAPID — mô hình của Bain & Company
RAPID là từ viết tắt của năm vai trò. Lưu ý: thứ tự chữ cái không phải thứ tự thời gian — Bain cố tình sắp xếp để dễ nhớ, còn trên thực tế trình tự thường là Input → Recommend → Agree → Decide → Perform.
- R — Recommend (Đề xuất): Người này chịu trách nhiệm đưa ra phương án. Họ thu thập dữ liệu, phân tích các lựa chọn, và trình bày đề xuất cụ thể kèm lý do. Đây thường là người "cầm việc" — vất vả nhất trong cả quy trình. Một recommendation tốt không phải là "em thấy nên làm A hoặc B hoặc C", mà là "em đề xuất làm A, vì những lý do sau, và đây là rủi ro của A".
- A — Agree (Đồng thuận / phê duyệt): Người này có quyền phủ quyết (veto) đối với đề xuất. Họ không nhất thiết là sếp; thường là người đại diện cho một ràng buộc bắt buộc — ví dụ phòng Pháp chế phải "agree" với hợp đồng, phòng Tài chính phải "agree" với ngân sách. Nếu người giữ vai A không đồng ý, đề xuất phải được sửa lại. Điểm mấu chốt: vai A nên càng ít người càng tốt. Mỗi người có quyền veto là một nút thắt cổ chai tiềm năng.
- P — Perform (Thực thi): Người hoặc nhóm sẽ triển khai quyết định sau khi được chốt. Nghe có vẻ hiển nhiên, nhưng việc xác định P trước khi quyết định lại cực kỳ quan trọng: người thực thi thường nhìn thấy những trở ngại thực tế mà người quyết định không thấy.
- I — Input (Góp ý): Những người được hỏi ý kiến trước khi ra quyết định. Ý kiến của họ được lắng nghe nhưng không mang tính ràng buộc. Đây là điểm hay bị hiểu lầm nhất. Người giữ vai I cần biết rõ rằng họ đang góp ý, chứ không phải đang bỏ phiếu.
- D — Decide (Quyết định): Người chốt cuối cùng. Chỉ một người duy nhất giữ vai D cho mỗi quyết định. Đây là nguyên tắc bất di bất dịch — nếu có hai người cùng "decide", bạn không có quyết định, bạn có một cuộc đàm phán vô tận. Người D chịu trách nhiệm giải trình cho kết quả.
RACI — mô hình phân vai theo công việc
RACI dùng cho việc phân trách nhiệm trên một dự án hoặc quy trình có nhiều đầu việc. Bốn vai gồm:
- R — Responsible (Người thực hiện): Người trực tiếp làm việc đó. Có thể có nhiều người.
- A — Accountable (Người chịu trách nhiệm cuối): Người sở hữu kết quả, là người "chịu trách nhiệm giải trình". Chỉ một người cho mỗi đầu việc. Đây là vai quan trọng nhất và hay bị bỏ trống nhất.
- C — Consulted (Người được tham vấn): Trao đổi hai chiều — bạn hỏi họ và họ phản hồi trước khi việc được hoàn thành.
- I — Informed (Người được thông báo): Trao đổi một chiều — họ chỉ cần được cập nhật kết quả, không cần tham gia.
Tình huống thực tế
Ví dụ 1 — Chuỗi F&B chọn nhà cung cấp POS (dùng RAPID)
Chị Hương là quản lý vận hành mới được thăng chức tại một chuỗi cà phê 18 chi nhánh ở TP.HCM. Công ty cần chọn phần mềm quản lý bán hàng (POS) mới, ngân sách khoảng 240 triệu đồng/năm. Cuộc họp đầu tiên là một thảm họa: giám đốc marketing muốn phần mềm có tính năng loyalty, kế toán trưởng muốn thứ tích hợp hóa đơn điện tử, còn các cửa hàng trưởng thì than phần mềm nào cũng "khó dùng". Sau hai tuần, chưa có gì nhúc nhích.
Chị Hương quyết định áp RAPID. Chị vẽ ra rõ ràng:
- Recommend: chính chị Hương và một bạn IT — họ khảo sát ba nhà cung cấp, chấm điểm theo tiêu chí, và đề xuất một phương án cụ thể.
- Input: giám đốc marketing (góc độ loyalty), 3 cửa hàng trưởng đại diện (góc độ dễ dùng).
- Agree: kế toán trưởng — vì ràng buộc hóa đơn điện tử là bắt buộc theo luật, nên bạn ấy có quyền veto nếu phần mềm không đáp ứng.
- Decide: giám đốc vận hành (sếp của chị Hương).
- Perform: đội IT và các cửa hàng trưởng khi rollout.
Bài học: phần lớn bế tắc trong quyết định không đến từ thiếu thông tin, mà từ việc mọi người ngầm tưởng mình có quyền quyết. Gọi tên vai trò ra là giải phóng năng lượng bị kẹt.
Ví dụ 2 — Startup fintech triển khai tính năng mới (dùng RACI)
Một startup fintech ở Singapore với team 25 người cần ra mắt tính năng chuyển tiền quốc tế trong 8 tuần. Trước đây họ làm kiểu "ai rảnh thì nhận", dẫn đến tình trạng hai kỹ sư cùng làm một phần API còn phần bảo mật thì không ai đụng tới. Trưởng nhóm sản phẩm, anh Minh — một manager mới lên được 4 tháng — lập một bảng RACI:
| Đầu việc | Product | Backend | Compliance | CEO |
|---|---|---|---|---|
| Thiết kế luồng UX | A/R | I | C | I |
| Xây API chuyển tiền | C | A/R | C | I |
| Kiểm tra tuân thủ AML | I | C | A/R | I |
| Quyết định ngày ra mắt | R | C | C | A |
Một chi tiết đắt giá: ban đầu ô "Xây API" có tới hai người ghi chữ A. Anh Minh phát hiện và sửa ngay — vì hai người Accountable nghĩa là không ai Accountable. Anh giao hẳn cho một backend lead.
Bài học: RACI buộc bạn đối diện với những khoảng xám mà bình thường mọi người né tránh. Quy tắc vàng: mỗi hàng chỉ được có đúng một chữ A.
Ví dụ 3 — Cái bẫy "quyết định bằng đồng thuận" ở một agency
Một agency truyền thông ở Hà Nội có văn hóa rất dân chủ: mọi quyết định lớn đều đưa ra "biểu quyết cả nhóm". Nghe thì đẹp, nhưng chị Lan — account director mới — nhận ra nó đang giết chết tốc độ. Việc chọn concept cho một chiến dịch của khách hàng lớn kéo dài ba cuộc họp vì 8 người không ai chịu ai.
Chị Lan không bỏ tính dân chủ, chị chỉ định nghĩa lại nó. Chị nói rõ với cả nhóm: "Với những quyết định sáng tạo, mọi người là Input — tôi rất muốn nghe. Nhưng người Decide là tôi, vì tôi là người chịu trách nhiệm trước khách hàng." Ban đầu vài bạn hụt hẫng, nhưng sau đó chính họ thừa nhận công việc chạy nhanh hơn hẳn và họ vẫn cảm thấy được lắng nghe.
Bài học: đồng thuận (consensus) không phải lúc nào cũng là mục tiêu. Với quyết định cần tốc độ hoặc có người phải chịu trách nhiệm rõ ràng, một người Decide + nhiều người Input sẽ hiệu quả hơn việc chờ tất cả gật đầu. "Được lắng nghe" khác với "được quyền quyết" — và làm rõ điều này là một hành động tôn trọng, không phải độc đoán.
Hướng dẫn từng bước
Đây là quy trình thực tế để áp dụng cho quyết định tiếp theo của bạn:
- Xác định đúng "đơn vị quyết định". Trước tiên hãy hỏi: đây là một quyết định hay một dự án nhiều đầu việc? Nếu là quyết định đơn lẻ nhưng quan trọng, dùng RAPID. Nếu là chuỗi công việc, dùng RACI. Đừng dùng framework cho những việc nhỏ nhặt — không phải quyết định nào cũng cần bảng biểu.
- Viết ra quyết định thành một câu rõ ràng. Ví dụ: "Chọn nhà cung cấp POS trước ngày 30/6." Nếu bạn không viết được thành một câu, tức là quyết định chưa đủ rõ để phân vai.
- Chỉ định người Decide (RAPID) hoặc Accountable (RACI) trước tiên. Đây luôn là vai khó nhất và quan trọng nhất. Nhớ: chỉ một người. Nếu bạn thấy mình muốn ghi hai cái tên, hãy dừng lại và chọn một.
- Phân biệt rạch ròi Input với Agree. Hỏi từng người liên quan: "Bạn cần được hỏi ý kiến, hay bạn có quyền chặn quyết định này?" Càng ít người có quyền chặn, quyết định càng chạy nhanh.
- Xác định người Recommend / Responsible. Ai là người thực sự cầm việc, thu thập dữ liệu và đề xuất? Đảm bảo người này có đủ thời gian và quyền tiếp cận thông tin.
- Công khai bảng phân vai với tất cả các bên. Đây là bước hay bị bỏ qua nhất. Framework chỉ có tác dụng khi mọi người đều biết mình đóng vai gì. Gửi một email hoặc chia sẻ một bảng đơn giản là đủ.
- Đặt deadline cho quyết định, không chỉ cho công việc. Ghi rõ "quyết định sẽ được chốt vào ngày X". Không có deadline, các quyết định có xu hướng trôi vô thời hạn.
- Sau khi quyết, thông báo cho nhóm Informed. Đóng vòng lặp. Những người chỉ cần biết kết quả cũng xứng đáng được cập nhật đàng hoàng.
Lỗi thường gặp & mẹo
Lỗi 1 — Có nhiều hơn một người Decide/Accountable. Đây là lỗi phổ biến nhất và gây hại nhất. Hai người cùng quyết = không ai quyết. Mẹo: khi lập bảng, quét từng hàng và đảm bảo đúng một chữ D (hoặc A).
Lỗi 2 — Nhầm Input thành Agree. Manager thường vô tình trao quyền veto cho quá nhiều người vì ngại làm mất lòng. Kết quả là một người bất mãn cũng đủ chặn cả quyết định. Hãy dè sẻn với vai Agree.
Lỗi 3 — Bỏ quên vai Perform/Responsible cho đến phút chót. Người thực thi cần được đưa vào bàn sớm, vì họ nhìn thấy những trở ngại thực tế. Quyết định đẹp trên giấy nhưng không triển khai được thì vô nghĩa.
Lỗi 4 — Dùng framework cho mọi thứ. Đừng lập RACI cho việc "chọn quán ăn liên hoan". Framework là dành cho những quyết định đủ lớn để đáng bỏ công. Lạm dụng sẽ khiến team thấy quan liêu và mệt mỏi.
Lỗi 5 — Lập bảng rồi cất tủ. Bảng phân vai chỉ sống khi được nhắc đến trong lúc làm việc. Hãy dán nó vào đầu tài liệu dự án, nhắc lại trong họp.
Mẹo văn hóa Việt Nam: khi bạn giữ vai Decide, đừng biến nó thành "sếp áp đặt". Hãy nói: "Tôi đã nghe kỹ ý kiến mọi người (Input), và với trách nhiệm của mình, tôi chốt phương án A." Cách diễn đạt này vừa giữ được quyền quyết, vừa cho nhóm thấy họ được tôn trọng — điều đặc biệt quan trọng trong môi trường coi trọng sự hòa hợp.
Mẹo phân quyền: RAPID là công cụ tuyệt vời để trao quyền mà không mất kiểm soát. Bạn có thể giao vai Decide cho một nhân viên giỏi với những quyết định nhỏ, trong khi vẫn giữ vai Agree để can thiệp nếu cần. Đây là cách nuôi dưỡng người kế nhiệm.
Bài tập thực hành
Bài tập 1 — Giải phẫu một quyết định đang kẹt. Chọn một quyết định trong team bạn đang bị trì hoãn hoặc gây tranh cãi. Viết nó thành một câu, rồi điền năm vai RAPID: ai Recommend, ai Input, ai Agree, ai Decide, ai Perform. Bạn có phát hiện chỗ nào có nhiều hơn một người Decide, hoặc quá nhiều người Agree không? Hãy sửa lại.
Bài tập 2 — Lập ma trận RACI cho một dự án. Chọn một dự án sắp tới có ít nhất 4 đầu việc. Kẻ bảng với các đầu việc theo hàng và các thành viên theo cột. Điền R/A/C/I vào từng ô. Kiểm tra hai quy tắc: (a) mỗi hàng đúng một chữ A; (b) không có hàng nào toàn chữ I mà thiếu R.
Bài tập 3 — Cuộc trò chuyện làm rõ vai. Chọn một người trong team mà bạn hay bối rối về ranh giới quyền quyết. Hẹn họ 15 phút và cùng thống nhất: với ba loại quyết định thường gặp giữa hai người, ai giữ vai Decide, ai giữ vai Input. Ghi lại kết quả.
Bài tập 4 — Kiểm toán vai Agree. Nhìn lại ba quyết định gần nhất của bạn. Có bao nhiêu người thực sự cần quyền veto? Bạn có đang trao quyền chặn cho những người lẽ ra chỉ nên góp ý không?
Tóm tắt
Ra quyết định là công việc trung tâm của một manager, và phần lớn sự lộn xộn quanh nó không đến từ thiếu thông tin mà từ thiếu rõ ràng về vai trò. Hai framework trong bài giúp bạn thiết kế sự rõ ràng đó:
- RAPID (Recommend, Agree, Perform, Input, Decide) dùng cho một quyết định cụ thể. Ghi nhớ ba nguyên tắc cốt lõi: chỉ một người Decide, dè sẻn với vai Agree, và tách bạch rõ Input (góp ý, không ràng buộc) khỏi quyền phủ quyết.
- RACI (Responsible, Accountable, Consulted, Informed) dùng cho dự án nhiều đầu việc. Quy tắc vàng: mỗi đầu việc đúng một người Accountable.