DECISION RIGHTS LÀ GÌ? CÁCH COO THIẾT KẾ QUYỀN RA QUYẾT ĐỊNH TRONG DOANH NGHIỆP

Một khách hàng lớn yêu cầu giảm giá thêm 5% để chốt hợp đồng ngay trong ngày. Trưởng phòng Sales biết đây là cơ hội quan trọng nhưng không chắc mình có quyền quyết định đến đâu nên chuyển lên Giám đốc Kinh doanh. Giám đốc Kinh doanh lo mức giảm này ảnh hưởng đến biên lợi nhuận nên hỏi Finance. Finance lại muốn biết Operations có đủ năng lực đáp ứng đơn hàng hay không, còn COO cho rằng đây là khách hàng chiến lược nên cần CEO xác nhận. Cuối ngày, tất cả các bộ phận đều đã tham gia nhưng chưa ai thực sự đưa ra quyết định cuối cùng. Trong lúc doanh nghiệp còn đang chờ phê duyệt, khách hàng đã nhận được một đề nghị khác từ đối thủ.

Tình huống này không nhất thiết xuất phát từ việc đội ngũ thiếu năng lực hay thiếu trách nhiệm. Vấn đề nằm ở chỗ tổ chức chưa làm rõ Decision Rights – quyền ra quyết định. Deloitte định nghĩa Decision Rights là các quy tắc và thông lệ xác định ai hoặc nhóm nào được trao quyền ra quyết định, những quyết định nào cần được đưa ra và cách quyền quyết định được phân bổ trong tổ chức. Điều đáng chú ý là nhiều doanh nghiệp thường nhầm Decision Rights với sơ đồ tổ chức hoặc quy trình công việc, trong khi việc biết “ai báo cáo cho ai” chưa đồng nghĩa với việc biết “ai có quyền chốt quyết định gì”.

Đối với COO, đây là một bài toán rất quan trọng bởi tốc độ vận hành không chỉ phụ thuộc vào quy trình chạy nhanh hay chậm mà còn phụ thuộc vào tốc độ ra quyết định. Khi doanh nghiệp nhỏ, Founder hoặc CEO có thể trực tiếp xử lý phần lớn quyết định. Nhưng khi tổ chức mở rộng, số lượng khách hàng, nhân viên, đơn hàng, dự án và ngoại lệ tăng lên rất nhanh. Nếu quyền quyết định vẫn tập trung ở một vài cá nhân, CEO và COO sẽ dần trở thành bottleneck. John&Partners cũng xác định việc “không ai biết rõ mình được quyết định gì và quyết định nào cần escalate lên cấp trên” là một trong những điểm thất bại vận hành phổ biến của hệ điều hành doanh nghiệp.

Vì vậy, thiết kế Decision Rights không đơn giản là “phân bớt việc cho cấp dưới”. COO cần thiết kế một hệ thống trong đó đúng người có quyền đưa ra đúng quyết định, với đủ thông tin, trong một phạm vi được xác định trước và có cơ chế escalation rõ ràng khi vượt giới hạn. Đây chính là cách doanh nghiệp tăng tốc mà vẫn duy trì khả năng kiểm soát.

1. Decision Rights là gì và vì sao sơ đồ tổ chức không đủ để trả lời “ai được quyền quyết”?

Trong nhiều doanh nghiệp, quyền hạn thường được hiểu dựa trên chức danh. Trưởng phòng được mặc định có quyền nhiều hơn nhân viên, Giám đốc có quyền nhiều hơn trưởng phòng và CEO là người có quyền cao nhất. Cách hiểu này đúng ở mức tổng quát nhưng chưa đủ để vận hành một tổ chức phức tạp. Một sơ đồ tổ chức chỉ cho biết mối quan hệ báo cáo, còn Decision Rights phải đi sâu tới từng nhóm quyết định cụ thể. Ví dụ, ai được quyền giảm giá cho khách hàng, ai có thể thay đổi thứ tự ưu tiên sản xuất, ai được phê duyệt một nhà cung cấp mới, ai có quyền tuyển thêm người, ai được quyết định CAPEX và ai được phép dừng dây chuyền khi phát hiện rủi ro chất lượng. Nếu những câu hỏi này chỉ được trả lời bằng câu “tùy trường hợp” hoặc “cứ hỏi sếp”, doanh nghiệp chưa thực sự thiết kế quyền ra quyết định.

Một điểm rất dễ nhầm khác là giữa Decision Rights và RACI. RACI giúp doanh nghiệp xác định ai là Responsible, Accountable, Consulted và Informed trong một công việc hoặc quy trình. Đây là công cụ rất hữu ích để giảm vùng xám trách nhiệm, và John&Partners cũng đưa RACI cùng Bản đồ quyết định vào thiết kế Operating Model và hệ thống phân quyền. Tuy nhiên, RACI không phải lúc nào cũng trả lời đầy đủ câu hỏi “ai có quyền đưa ra quyết định cuối cùng”. Một phòng ban có thể chịu trách nhiệm chuẩn bị dữ liệu, phòng khác được tham vấn và một giám đốc chịu trách nhiệm tổng thể, nhưng doanh nghiệp vẫn phải xác định rõ ai là Decision Owner có quyền chốt khi các bên không đồng thuận.

Bain & Company phát triển một công cụ Decision Rights có tên RAPID, trong đó các vai trò bao gồm Recommend, Agree, Perform, Input và Decide. Điểm đáng chú ý là Bain nhấn mạnh mỗi quyết định nên có một người giữ vai trò Decide, tức người có quyền đưa ra quyết định cuối cùng và cam kết tổ chức hành động theo quyết định đó. Không nhất thiết doanh nghiệp phải áp dụng RAPID cho mọi việc, nhưng nguyên tắc phía sau rất quan trọng: nếu một quyết định có quá nhiều người cùng có quyền chốt hoặc không ai thực sự có quyền chốt, thời gian ra quyết định sẽ tăng và trách nhiệm cuối cùng trở nên mơ hồ.

Vì vậy, Decision Rights phải được xem là một phần của Operating Model chứ không phải một văn bản phân quyền hành chính đơn lẻ. John&Partners mô tả Operating Model là bản thiết kế cách tổ chức con người, quy trình, dữ liệu và công nghệ để thực thi chiến lược; trong đó hệ điều hành doanh nghiệp cần bao gồm cả cấu trúc, ma trận phân quyền, hệ thống KPI và những cơ chế quản trị giúp tổ chức vận hành đồng bộ. Khi Decision Rights được đặt đúng trong Operating Model, doanh nghiệp mới có thể nối trách nhiệm, quyền hạn và kết quả thành một hệ thống thống nhất.

2. Doanh nghiệp đang có vấn đề Decision Rights khi nào?

Dấu hiệu rõ nhất là những quyết định nhỏ cũng phải đi lên cấp rất cao. Một mức discount không lớn, một vị trí tuyển dụng, một khoản chi ngoài kế hoạch, một thay đổi lịch sản xuất hay một khiếu nại đặc biệt đều cần CEO hoặc COO duyệt. Khi tình trạng này xảy ra thường xuyên, vấn đề không nằm ở việc lãnh đạo quá cẩn thận mà nằm ở chỗ tổ chức chưa xác định rõ phạm vi quyền hạn của các cấp phía dưới. Người quản lý lúc đó có thể chịu trách nhiệm về kết quả nhưng không dám hành động vì không biết giới hạn nào được phép tự quyết. Lựa chọn an toàn nhất về mặt cá nhân luôn là đưa vấn đề lên trên, và theo thời gian cả tổ chức hình thành thói quen escalation.

Một biểu hiện khác là doanh nghiệp có rất nhiều cuộc họp nhưng tốc độ quyết định vẫn chậm. Sales, Operations, Finance và Supply Chain có thể họp đầy đủ, dữ liệu đã được trình bày và các bên đều nêu quan điểm, nhưng cuối buổi vẫn kết thúc bằng câu “để hỏi thêm CEO”. Điều này cho thấy vấn đề không nằm ở thiếu thông tin mà ở thiếu quyền chốt. John&Partners cũng chỉ ra một nghịch lý phổ biến khi doanh nghiệp tăng trưởng: số lượng cuộc họp tăng nhưng tốc độ ra quyết định lại giảm nếu tổ chức thiếu một Operating Rhythm và cơ chế điều hành rõ ràng. Nếu mỗi cuộc họp không gắn với một mục tiêu quyết định cụ thể và không xác định ai có quyền kết thúc cuộc thảo luận, việc tăng số lượng họp chỉ tạo thêm thời gian chờ.

Vấn đề cũng xuất hiện khi Accountability cao nhưng Authority thấp. Một trưởng bộ phận có thể chịu KPI On-Time Delivery nhưng không được điều chỉnh nguồn lực, không được thay đổi thứ tự ưu tiên, không có quyền xử lý ngoại lệ với Sales hoặc nhà cung cấp và mọi thay đổi quan trọng đều phải xin cấp trên. Trong trường hợp này, doanh nghiệp đang yêu cầu người quản lý chịu trách nhiệm cho một kết quả mà họ không có đủ quyền kiểm soát các yếu tố tạo ra kết quả đó. Đây là môi trường dễ dẫn đến đổ lỗi bởi khi KPI không đạt, người chịu trách nhiệm có thể lập luận rằng mình không được trao đủ quyền để hành động.

Một dấu hiệu rất phổ biến khác là CEO hoặc COO trở thành trọng tài liên phòng ban. Khi Sales và Operations bất đồng về ưu tiên đơn hàng thì đưa lên COO, Finance và HR không thống nhất ngân sách thì hỏi CEO, Procurement và Quality tranh luận về nhà cung cấp thì lại chuyển lên Ban Điều hành. Lãnh đạo cấp cao chắc chắn phải tham gia vào một số quyết định có rủi ro hoặc ảnh hưởng lớn, nhưng nếu phần lớn xung đột thường ngày đều phải đưa lên trên thì hệ thống chưa thiết kế đủ rõ quyền hạn ở các điểm giao giữa chức năng. John&Partners cũng đưa cơ cấu tổ chức, RACI, cơ chế phê duyệt và Bản đồ quyết định vào khung đánh giá độ trưởng thành vận hành nhằm giảm sự phụ thuộc vào Founder và nâng cao năng lực quản lý trung gian.

Điểm đáng chú ý là những triệu chứng này có thể tồn tại ngay cả khi sơ đồ tổ chức rất đầy đủ. Doanh nghiệp có CEO, COO, các giám đốc chức năng, trưởng phòng và trưởng nhóm nhưng quyền quyết định thực tế vẫn tập trung ở một vài người. Vì vậy, khi đánh giá Decision Rights, COO không nên chỉ nhìn vào chức danh trên sơ đồ mà cần nhìn vào dòng chảy quyết định thực tế: vấn đề phát sinh ở đâu, phải đi qua bao nhiêu người, thời gian chờ nằm ở bước nào và ai cuối cùng là người có quyền nói “đồng ý” hoặc “không đồng ý”.

3. COO nên thiết kế Decision Rights như thế nào để tăng tốc mà vẫn kiểm soát được rủi ro?

Bước đầu tiên không phải là lập một ma trận khổng lồ cho toàn bộ doanh nghiệp, mà là xác định những quyết định thực sự quan trọng hoặc thường xuyên gây ma sát. Deloitte gọi cách tiếp cận này là xây dựng “decision inventory” – danh mục những quyết định quan trọng mà tổ chức cần đưa ra ở các cấp khác nhau. Danh mục không nhất thiết phải bao phủ mọi quyết định để hữu ích; điều quan trọng là nhận diện những quyết định có ảnh hưởng lớn hoặc thường xuyên bị chậm. Với COO, nhóm này thường bao gồm pricing exception, tuyển dụng, CAPEX, lựa chọn nhà cung cấp, thay đổi kế hoạch sản xuất, xử lý khiếu nại lớn, điều chỉnh ngân sách hoặc các quyết định ảnh hưởng nhiều phòng ban.

Sau khi nhận diện quyết định, COO cần xác định một Decision Owner rõ ràng. Đây là người hoặc cấp có quyền chốt cuối cùng trong phạm vi đã được thiết kế. Việc xác định một người chốt không có nghĩa người đó tự quyết mà không cần dữ liệu hay tham vấn. Quyết định có thể cần Finance cung cấp phân tích tài chính, Operations cung cấp thông tin Capacity và Sales cung cấp bối cảnh khách hàng, nhưng sau khi các input cần thiết được thu thập, phải có một người được trao quyền đưa ra kết luận. Nguyên tắc của Bain về việc mỗi quyết định chỉ có một “D – Decide” cũng nhằm tránh tình trạng nhiều người cùng có quyền cuối cùng khiến trách nhiệm bị phân tán và tốc độ giảm.

Tiếp theo là thiết kế ngưỡng quyền hạn, bởi Decision Rights hiếm khi chỉ là “được quyết” hoặc “không được quyết”. Một Sales Manager có thể được tự quyết discount đến 3%, Sales Director quyết từ 3% đến 7% sau khi kiểm tra Margin, COO phê duyệt từ 7% đến 10%, còn những trường hợp vượt ngưỡng hoặc liên quan khách hàng chiến lược mới cần CEO. Tương tự, CAPEX có thể được phân tầng theo giá trị đầu tư, tuyển dụng phân theo cấp bậc hoặc ngân sách, trong khi các quyết định vận hành được phân theo mức độ ảnh hưởng tới khách hàng, chất lượng, pháp lý và Business Continuity. Khi ngưỡng được xác định trước, quản lý không cần “đoán xem lần này có nên hỏi sếp hay không”.

COO cũng phải thiết kế rõ cơ chế escalation. Escalation không nên xảy ra chỉ vì người quản lý cảm thấy không chắc chắn, mà phải gắn với các điều kiện đã được thống nhất như vượt ngân sách, vượt mức rủi ro, ảnh hưởng nhiều Business Unit, có yếu tố pháp lý, tác động tới khách hàng chiến lược hoặc đe dọa gián đoạn hoạt động. Điều này giúp escalation trở thành một cơ chế quản trị thay vì một thói quen tâm lý. Khi vấn đề nằm trong phạm vi đã phân quyền, người quản lý phải thực hiện quyền của mình và chịu trách nhiệm với kết quả; khi vượt phạm vi, hệ thống tự chỉ ra cấp tiếp theo cần tham gia.

Cuối cùng, Decision Rights cần được kết nối với KPI, dữ liệu và Operating Rhythm. Người có quyền quyết phải nhận được thông tin đủ tốt vào đúng thời điểm, và kết quả của quyết định phải được theo dõi để tổ chức học được điều gì hiệu quả. Nếu giao quyền mà không có dữ liệu, doanh nghiệp có thể tăng tốc nhưng giảm chất lượng quyết định. Nếu có dữ liệu nhưng không giao quyền, Dashboard chỉ giúp mọi người nhìn thấy vấn đề nhanh hơn trong khi vẫn phải chờ phê duyệt. John&Partners cũng đặt phân quyền ra quyết định cùng hệ thống KPI, nhịp điều hành và chuẩn hóa quy trình trong trụ cột kiểm soát vận hành của chương trình COO, cho thấy các thành phần này cần được thiết kế đồng thời thay vì tách rời.

4. Vai trò của COO không phải quyết thay mọi người mà là thiết kế một tổ chức biết tự quyết đúng cấp

Một COO giỏi xử lý vấn đề rất nhanh có thể vô tình tạo ra một rủi ro giống CEO: cả tổ chức bắt đầu đưa những tình huống khó lên COO vì biết rằng người này sẽ giải quyết được. Sau một thời gian, CEO có thể được giảm tải nhưng COO lại trở thành bottleneck mới. Điều này cho thấy việc “có một COO mạnh” chưa đủ để xây hệ thống vận hành mạnh. COO cần chuyển vai trò từ Decision Maker sang Decision System Designer, tức không chỉ đưa ra quyết định tốt mà còn thiết kế cách tổ chức đưa ra quyết định tốt ngay cả khi COO không trực tiếp tham gia.

Một câu hỏi rất hữu ích đối với COO là: “Tại sao quyết định này lại phải đến tôi?”. Nếu đó là quyết định chiến lược, có rủi ro lớn hoặc ảnh hưởng nhiều phần của doanh nghiệp thì việc COO tham gia hoàn toàn hợp lý. Nhưng nếu cùng một loại quyết định xuất hiện hàng chục lần mỗi tháng và lần nào cũng phải đưa lên COO, đó thường là tín hiệu cần thiết kế lại Decision Rights. Quyết định cần được phân loại, ngưỡng được xác định và quyền được chuyển xuống cấp gần thông tin nhất nhưng vẫn đủ năng lực để chịu trách nhiệm.

Đây cũng là một điều kiện quan trọng để doanh nghiệp scale. Khi có một văn phòng và vài chục nhân viên, CEO hoặc COO có thể xử lý phần lớn ngoại lệ. Nhưng khi doanh nghiệp có nhiều chi nhánh, nhà máy hoặc Business Unit, mô hình này không thể nhân bản. John&Partners nhấn mạnh rằng trước khi mở rộng, COO cần thiết lập kỷ luật thực thi, phân quyền bằng RACI và Bản đồ quyết định nhằm loại bỏ vùng xám trách nhiệm. Nếu không, doanh nghiệp chỉ nhân rộng số lượng vấn đề cần đưa về trụ sở thay vì nhân rộng năng lực tự vận hành.

Vai trò này được thể hiện khá rõ trong chương trình COO – Chief Operating Officer của John&Partners. Chương trình xác định một trong những vấn đề khi tổ chức mở rộng là việc ra quyết định chậm lại, CEO quá tải và đội ngũ quản lý trung gian gặp khó khăn khi hệ thống phụ thuộc vào nỗ lực cá nhân. Trong nội dung đào tạo, trụ cột “Kiểm soát vận hành – từ hỗn loạn đến ổn định” bao gồm thiết kế mô hình vận hành và phân quyền ra quyết định, còn trụ cột “Quản trị & kỷ luật triển khai” đi sâu vào Ma trận phân quyền và Bản đồ quyết định. Điều này phản ánh đúng yêu cầu của vai trò COO: không chỉ chạy hoạt động hằng ngày mà phải xây một cơ chế trong đó quyền, trách nhiệm và dữ liệu được kết nối thành hệ điều hành.

Khi Decision Rights được thiết kế tốt, CEO không còn phải quyết mọi việc, COO không trở thành người chữa cháy thay CEO và quản lý trung gian không chỉ đóng vai trò truyền thông tin lên trên. Mỗi cấp biết mình được quyết gì, trong giới hạn nào, cần tham vấn ai và khi nào phải escalation. Khi đó, tốc độ quyết định có thể tăng mà kiểm soát không bị mất đi. Đây chính là một trong những dấu hiệu cho thấy doanh nghiệp đang chuyển từ quản trị bằng cá nhân sang quản trị bằng hệ thống.

Kết luận

Decision Rights là cơ chế giúp doanh nghiệp xác định rõ ai có quyền đưa ra quyết định, quyết định trong phạm vi nào, cần lấy input từ ai và khi nào phải escalation lên cấp cao hơn. Khi quyền quyết định mơ hồ, tổ chức sẽ họp nhiều nhưng chốt chậm, quản lý chịu trách nhiệm nhưng không đủ quyền hành động và CEO hoặc COO dần trở thành bottleneck của toàn hệ thống.

Với COO, mục tiêu không phải giành quyền quyết định về mình mà là thiết kế một hệ thống giúp đúng người có thể đưa ra đúng quyết định ở đúng cấp. Khi trách nhiệm, quyền hạn, KPI, dữ liệu và cơ chế escalation được kết nối, doanh nghiệp mới có khả năng tăng tốc vận hành và mở rộng mà không phải tăng tương ứng mức độ can thiệp của lãnh đạo.

Câu hỏi thường gặp

Decision Rights là gì? Decision Rights là các quy tắc và cơ chế xác định cá nhân hoặc nhóm nào được trao quyền đưa ra những quyết định cụ thể trong tổ chức, đồng thời làm rõ phạm vi và cách quá trình quyết định diễn ra.

Decision Rights khác RACI như thế nào? RACI tập trung làm rõ Responsible, Accountable, Consulted và Informed trong công việc, trong khi Decision Rights tập trung trực tiếp hơn vào câu hỏi ai có quyền đưa ra quyết định cuối cùng và trong điều kiện nào quyền đó được sử dụng.

Vì sao Decision Rights quan trọng khi doanh nghiệp scale? Khi quy mô tăng, số lượng quyết định và điểm phối hợp cũng tăng. Nếu quyền quyết định vẫn tập trung ở CEO hoặc một vài lãnh đạo, hàng chờ quyết định sẽ hình thành và làm chậm toàn tổ chức.

Có nên phân quyền càng nhiều càng tốt không? Không. Phân quyền phải đi cùng phạm vi, ngưỡng rủi ro, dữ liệu và cơ chế escalation. Mục tiêu là đưa quyền đến đúng cấp, không phải đẩy mọi quyết định xuống thấp nhất.

COO có vai trò gì trong thiết kế Decision Rights? COO cần nhận diện những quyết định quan trọng, xác định Decision Owner, thiết kế ngưỡng phân quyền và escalation, sau đó tích hợp chúng với Operating Model, KPI, quy trình và nhịp điều hành doanh nghiệp. John&Partners cũng đưa phân quyền ra quyết định, Ma trận phân quyền và Bản đồ quyết định vào nội dung cốt lõi của chương trình COO.

Muốn xây dựng một hệ thống trong đó đúng người có thể ra đúng quyết định mà không phải liên tục chờ CEO? Tìm hiểu chương trình COO – Chief Operating Officer tại John&Partners.