Ma trận phân quyền ra quyết định cho startup

Giao việc chưa đồng nghĩa giao quyền

Một nhân viên được giao xử lý khiếu nại nhưng không biết có thể đổi hàng hay hoàn tiền trong điều kiện nào sẽ phải chuyển từng trường hợp về chủ. Vấn đề chưa chắc nằm ở tinh thần chủ động; có thể người đó chưa có quyền, dữ liệu hoặc tiêu chuẩn để quyết.

GitLab công khai cách gắn quyết định với một Directly Responsible Individual, người chịu trách nhiệm trực tiếp, thu thập dữ liệu và cân nhắc lựa chọn. BHKD vận dụng nguyên tắc đầu mối rõ ràng vào bảng đơn giản dưới đây; đây không phải bản sao toàn bộ mô hình GitLab.

Mẫu ma trận có thể điền ngay

Các con số trong bảng là giả định minh họa. Doanh nghiệp cần đặt mức giới hạn phù hợp với biên lợi nhuận, điều khoản, rủi ro và năng lực nhân sự. Không chỉ đặt một trần tiền rồi coi mọi trường hợp dưới trần là an toàn.

Với mỗi hàng, bổ sung nơi lưu bằng chứng, thời gian cần phản hồi và người thay thế khi đầu mối vắng mặt. Nếu hai người cùng có quyền quyết cuối, hãy nói rõ khi nào quyền chuyển từ người này sang người kia.

Tách ba mức: tự quyết, tham vấn, xin duyệt

Tự quyết: đầu mối được ra quyết định trong phạm vi đã thống nhất và cập nhật sau đó. Tham vấn: đầu mối hỏi người có dữ liệu liên quan nhưng vẫn chịu trách nhiệm quyết. Xin duyệt: cần người được chỉ định phê chuẩn trước khi cam kết với bên ngoài.

Ví dụ, điều phối có thể tham vấn kho để xác nhận năng lực giao, thay vì để cả kho lẫn sale đồng phê duyệt một thay đổi nhỏ. Với một cam kết bồi thường vượt khung, đầu mối phải xin duyệt. Sự khác nhau nằm ở người quyết cuối và thời điểm được hành động.

Giới hạn tốt phải mô tả cả ngoại lệ

Một khoản hoàn tiền nhỏ vẫn có thể liên quan khiếu nại nhạy cảm hoặc dấu hiệu gian lận. Một thay đổi không phát sinh chi phí vẫn có thể ảnh hưởng dữ liệu khách hàng. Vì vậy, hãy bổ sung điều kiện ngoài phạm vi dựa trên tác động và mức độ khó đảo ngược.

Đặt cách chuyển cấp cụ thể: gửi tóm tắt tình huống, hai lựa chọn, tác động và thời hạn cần quyết. Không phản hồi chưa có nghĩa được tự động thông qua. Doanh nghiệp phải thống nhất phương án khi người duyệt vắng mặt, đặc biệt với cam kết khó thu hồi.

Nhật ký quyết định giúp kiểm tra mà không duyệt lại mọi việc

Mẫu ngắn gồm: ngày, vấn đề, người quyết, thông tin đã dùng, lựa chọn, giới hạn áp dụng và ngày xem lại. Chỉ ghi những quyết định đủ quan trọng để học hoặc truy vết, không biến từng thao tác thông thường thành một báo cáo.

Trong một tình huống giả định, quản lý CSKH hoàn 600.000 đồng theo chính sách đổi trả nhưng khách vẫn tiếp tục khiếu nại. Nhật ký cho phép xem vấn đề do chính sách, bằng chứng hay lời hứa trước bán. Nếu founder chỉ nhìn số tiền hoàn, rất dễ sửa sai nguyên nhân.

Thử một tuần và đánh giá cả tốc độ lẫn chất lượng

Đo thời gian từ lúc phát sinh đến lúc có quyết định, số lần chuyển cấp và số quyết định phải sửa. Nếu ít chuyển cấp hơn nhưng lỗi tăng, cần bổ sung dữ liệu, huấn luyện hoặc thu hẹp phạm vi. Nếu mọi việc vẫn quay về founder, kiểm tra xem quyền mới có được tôn trọng hay bị phủ quyết tùy hứng.

Khi quy tắc đã chạy được, đưa vào SOP và tài liệu giao việc. Quyền quyết định không đứng riêng: nó cần đầu ra rõ, người hiểu việc và một nhịp phản hồi giúp điều chỉnh sớm.

Gợi ý hành động