TÁI CẤU TRÚC DOANH NGHIỆP: MỔ XẺ ĐIỂM NGHẼN CỐT LÕI TRONG VẬN HÀNH VÀ QUẢN TRỊ. CHỦ ĐỀ HÔM NAY: TRÙNG LẶP PHÊ DUYỆT GIỮA 2–3 CẤP QUẢN LÝ.

Khi tốc độ thị trường yêu cầu khả năng xoay chuyển linh hoạt và ra quyết định thần tốc, bất kỳ ma sát nào trong guồng máy vận hành cũng đều trở thành gánh nặng chi phí khổng lồ. Việc phân tích quy trình làm việc liên phòng ban để xác định các điểm chồng chéo và tắc nghẽn—đặc biệt là trong quy trình phê duyệt và ra quyết định—không còn là một hoạt động cải tiến định kỳ, mà là nhiệm vụ sống còn quyết định sự tồn vong và khả năng tăng trưởng bền vững. Nếu doanh nghiệp của bạn đang vật lộn với thời gian phản hồi chậm chạp, hay nhân viên cấp dưới liên tục gửi yêu cầu phê duyệt lên ba cấp quản lý khác nhau cho cùng một khoản mục chi tiêu nhỏ, đó chính là tín hiệu cho thấy đã đến lúc phải can thiệp bằng các biện pháp tái cấu trúc chiến lược.

Chúng ta sẽ cùng nhau phân tích chi tiết quy trình làm việc liên phòng để tìm điểm chồng chéo, tắc nghẽn, và đi sâu vào một vấn đề kinh điển nhưng dai dẳng trong quản trị: sự TRÙNG LẶP PHÊ DUYỆT GIỮA CÁC CẤP QUẢN LÝ.

Mục lục

• Phần I: Bối Cảnh Chiến Lược Về Tái Cấu Trúc Vận Hành và Quy Trình (Kinh nghiệm thực chiến)
• 1.1. Tái Cấu Trúc: Định nghĩa lại từ góc độ Tối ưu hóa Dòng chảy Giá trị
• 1.2. Phân tích Dòng chảy Quy trình Liên phòng: Tại sao đây là điểm khởi đầu?
• 1.3. Ánh xạ các điểm ma sát (Friction Points)
• Phần II: Phân Tích Điểm Nghẽn Cốt Lõi: Quy Trình Phê Duyệt và Ra Quyết Định
• 2.1. Quy trình Phê duyệt: Khái niệm, Mục đích và Rủi ro Kiểm soát
• 2.2. Nền móng của sự Phức tạp: Sự phát triển phi tuyến tính của tổ chức
• Phần III: Mổ Xẻ Vấn Đề Trùng Lặp Phê Duyệt Giữa 2–3 Cấp Quản Lý (Vấn đề cốt lõi)
• 3.1. Các Dạng Trùng Lặp Phê Duyệt Thường Gặp
• 3.2. Hậu quả Định Lượng và Định Tính của việc phê duyệt chồng chéo
• 3.3. Nguồn gốc Sâu xa của sự Chồng chéo: Văn hóa, Cơ chế Kiểm soát và Hệ thống ERP
• 3.4. Rủi ro về Kiểm toán và Tính tuân thủ (Compliance)
• Phần IV: Xây Dựng Khung Quản Trị Phê Duyệt Tinh Gọn (Giải pháp chuyên sâu)
• 4.1. Thiết lập Ma trận Trách nhiệm (RACI Model) Cải tiến
• 4.2. Xây dựng Ngưỡng Quyết Định Tự Chủ (Delegation of Authority – DoA)
• 4.3. Phân biệt giữa Quyết Định Chiến Lược và Phê Duyệt Vận Hành
• 4.4. Tối ưu hóa Quy trình bằng Công nghệ (Automation & Cloud Adoption)
• Phần V: Góc Nhìn Chuyên Sâu: Tiêu Chuẩn Kiểm Soát và Quản Trị Rủi Ro (E-E-A-T Technical Depth)
• 5.1. Liên kết Quy trình Phê duyệt với Khung Kiểm soát Nội bộ (COSO)
• 5.2. Vai trò của Chứng nhận SOC (Service Organization Control) trong môi trường Cloud
• 5.3. Đo lường Hiệu quả Phê duyệt bằng KPIs Kế toán Vận hành
• Phần VI: Kinh Nghiệm Thực Chiến và Ví dụ Điển Hình (Case Studies)
• 6.1. Case Study 1: Tối ưu hóa Chi tiêu Mua hàng tại Doanh nghiệp Bán lẻ Đa chi nhánh
• 6.2. Case Study 2: Tái cấu trúc Phòng Công nghệ và Phê duyệt SaaS tại Công ty Dịch vụ Kỹ thuật số
• Phần VII: Điểm Hành Động Cốt Lõi và Kết Luận

Phần I: Bối Cảnh Chiến Lược Về Tái Cấu Trúc Vận Hành và Quy Trình (Kinh nghiệm thực chiến)

1.1. Tái Cấu Trúc: Định nghĩa lại từ góc độ Tối ưu hóa Dòng chảy Giá trị

Thuật ngữ “Tái cấu trúc doanh nghiệp” thường bị hiểu sai là hành động cắt giảm nhân sự hoặc thu hẹp quy mô trong thời kỳ khó khăn. Trong kinh nghiệm thực tiễn của chúng tôi, tái cấu trúc ở cấp độ vận hành là quá trình khoa học nhằm tái thiết kế Dòng chảy Giá trị (Value Stream Mapping) của tổ chức để loại bỏ các hoạt động không gia tăng giá trị (Non-Value Add Activities). Mục tiêu cuối cùng là tăng tốc độ phản hồi thị trường, giảm chi phí ẩn và giải phóng năng lực của đội ngũ quản lý cấp cao khỏi các công việc tiểu tiết.

Điều này đặc biệt quan trọng khi doanh nghiệp đã trải qua giai đoạn tăng trưởng nóng. Khi công ty phát triển từ 50 lên 500 nhân sự, các quy trình tạm thời (Ad-hoc processes) được thiết lập ban đầu để đảm bảo kiểm soát nhanh chóng sẽ trở nên xơ cứng, chậm chạp và chồng chéo. Tái cấu trúc vận hành chính là việc tháo gỡ những “băng bó” cũ kỹ đó.

1.2. Phân tích Dòng chảy Quy trình Liên phòng: Tại sao đây là điểm khởi đầu?

Hầu hết các vấn đề về hiệu suất (Efficiency) và hiệu quả (Effectiveness) không nằm trong phạm vi một phòng ban đơn lẻ, mà nằm ở các giao điểm (Hand-offs) giữa các phòng ban. Hãy hình dung một yêu cầu mua sắm. Nó bắt đầu từ Kinh doanh, chuyển sang Mua hàng, qua Tài chính (Kiểm soát ngân sách), trở lại Mua hàng (Đàm phán), quay lại Tài chính (Phê duyệt chi tiêu cuối cùng), và cuối cùng là Kế toán (Hạch toán).

Mỗi giao điểm này là một cơ hội để quy trình bị chậm lại, bị hiểu sai, hoặc bị “kiểm tra lại” bởi một người quản lý khác với mục đích tương tự nhưng góc nhìn khác. Phân tích quy trình liên phòng giúp chúng ta vẽ nên bản đồ tổng thể (End-to-End Map) của mọi hoạt động quan trọng, từ Order-to-Cash (O2C) đến Procure-to-Pay (P2P), và đặc biệt là các quy trình liên quan đến phê duyệt tài nguyên.

1.3. Ánh xạ các điểm ma sát (Friction Points)

Trong quá trình ánh xạ, chuyên gia tái cấu trúc cần tìm kiếm các dấu hiệu sau, đây là những chỉ số rõ ràng nhất về sự kém hiệu quả:

• Thứ nhất, Work in Progress (WIP) cao: Có quá nhiều yêu cầu đang chờ xử lý tại một thời điểm nào đó, thường là ở bàn làm việc của Quản lý cấp trung hoặc Giám đốc Tài chính.
• Thứ hai, Cycle Time biến động lớn: Thời gian xử lý một yêu cầu (ví dụ: yêu cầu mua laptop mới) thay đổi từ 2 ngày đến 2 tuần mà không có lý do rõ ràng.
• Thứ ba, Re-work Loop (Vòng lặp làm lại): Yêu cầu bị từ chối không phải vì thiếu ngân sách, mà vì thiếu thông tin hoặc cấu trúc không đúng, buộc người khởi tạo phải quay lại bước đầu tiên, gây lãng phí công sức của ít nhất ba người khác.

Phần II: Phân Tích Điểm Nghẽn Cốt Lõi: Quy Trình Phê Duyệt và Ra Quyết Định

2.1. Quy trình Phê duyệt: Khái niệm, Mục đích và Rủi ro Kiểm soát

Về bản chất, phê duyệt là một cơ chế kiểm soát nội bộ (Internal Control) được thiết kế để đảm bảo: a) Việc phân bổ tài nguyên phù hợp với chiến lược đã được hoạch định. b) Ngăn chặn gian lận, lãng phí và lạm dụng. c) Đảm bảo tính tuân thủ pháp luật và quy định của công ty.

Tuy nhiên, khi cơ chế kiểm soát này được triển khai quá thận trọng hoặc không được cập nhật theo tốc độ tăng trưởng, nó sẽ chuyển từ cơ chế bảo vệ sang rào cản vận hành. Rủi ro lớn nhất không phải là mất mát tài chính (mặc dù điều này xảy ra), mà là chi phí cơ hội do tốc độ ra quyết định chậm trễ và sự mất niềm tin vào hệ thống quản lý.

2.2. Nền móng của sự Phức tạp: Sự phát triển phi tuyến tính của tổ chức

Sự phức tạp của quy trình phê duyệt thường bắt nguồn từ ba giai đoạn phát triển của doanh nghiệp:

• Giai đoạn 1: Khởi nghiệp (Startup) – Phê duyệt tập trung. CEO hoặc Founder phê duyệt mọi thứ. Quyết định nhanh, nhưng thiếu kiểm soát có hệ thống.
• Giai đoạn 2: Tăng trưởng (Growth) – Phân quyền cục bộ. Khi không thể tự phê duyệt mọi thứ, quyền lực được phân bổ xuống Quản lý cấp trung. Tuy nhiên, thay vì phân quyền rõ ràng, hệ thống mới được “chắp vá” thêm vào hệ thống cũ. Ví dụ: Quản lý phòng ban phê duyệt, nhưng CEO vẫn yêu cầu xem xét lại mọi chi tiêu trên ngưỡng 10 triệu đồng.
• Giai đoạn 3: Trưởng thành (Maturity) hoặc Tái cấu trúc – Xuất hiện điểm nghẽn. Khi quy mô lớn, các phòng ban lại bắt đầu đặt ra các lớp kiểm soát riêng (Siloed Controls) mà không phối hợp với nhau. Tài chính kiểm soát ngân sách, Vận hành kiểm soát chất lượng, và Pháp lý kiểm soát hợp đồng. Kết quả: một yêu cầu đi qua ba phòng ban, và mỗi phòng ban lại có ít nhất một cấp quản lý ký duyệt.

Phần III: Mổ Xẻ Vấn Đề Trùng Lặp Phê Duyệt Giữa 2–3 Cấp Quản Lý (Vấn đề cốt lõi)

Vấn đề Trùng lặp phê duyệt giữa 2–3 cấp quản lý là triệu chứng phổ biến của sự thiếu rõ ràng trong Ma trận Trách nhiệm (RACI) và sự yếu kém trong việc xây dựng Ngưỡng Quyết Định Tự Chủ (Delegation of Authority – DoA).

3.1. Các Dạng Trùng Lặp Phê Duyệt Thường Gặp

Chúng ta cần phân biệt rõ ba loại hình phê duyệt chồng chéo điển hình, đi kèm với các bên liên quan:

• a) Trùng lặp về Phạm vi Giá trị (Monetary Overlap):

Đây là lỗi kinh điển nhất. Một yêu cầu mua hàng 50 triệu đồng.

• Cấp 1: Trưởng phòng ban (Phê duyệt vì nằm trong Ngân sách phòng ban).
• Cấp 2: Giám đốc Tài chính (Phê duyệt vì vượt ngưỡng 30 triệu đồng theo quy tắc kiểm soát chung).
• Cấp 3: Phó Tổng Giám đốc Vận hành (Phê duyệt vì đây là chi phí vốn Opex/Capex).

Vấn đề: Nếu Trưởng phòng đã xác nhận nằm trong ngân sách được duyệt hàng năm, tại sao Giám đốc Tài chính lại phải phê duyệt lại? Nếu Trưởng phòng có quyền chi tiêu 50 triệu, thì GĐ Tài chính chỉ nên phê duyệt các khoản ngoài ngân sách, hoặc các khoản vượt ngưỡng giới hạn của Trưởng phòng.

• b) Trùng lặp về Chức năng (Functional Overlap):

Xảy ra khi các bộ phận khác nhau cùng kiểm tra một khía cạnh.

Ví dụ: Hợp đồng nhà cung cấp dịch vụ công nghệ.

• Phê duyệt 1: Trưởng phòng IT (Kiểm tra kỹ thuật và tính khả thi).
• Phê duyệt 2: Trưởng phòng Pháp chế (Kiểm tra điều khoản pháp lý).
• Phê duyệt 3: Giám đốc IT (Kiểm tra chiến lược và ngân sách).
• Phê duyệt 4: Giám đốc Pháp chế (Xem xét lại điều khoản của cấp dưới).

Vấn đề: Việc Giám đốc Pháp chế xem lại công việc của Trưởng phòng Pháp chế cho một hợp đồng tiêu chuẩn là sự lãng phí. Nếu Trưởng phòng được ủy quyền và đào tạo để xử lý các hợp đồng mẫu, thì Giám đốc chỉ nên tập trung vào các hợp đồng có rủi ro cao hoặc giá trị lớn bất thường.

• c) Trùng lặp về Cấp bậc (Hierarchical Overlap – Thiếu niềm tin):

Đây là vấn đề văn hóa quản trị.

Một yêu cầu tuyển dụng nhân sự cấp chuyên viên.

• Phê duyệt 1: Quản lý trực tiếp (Nhu cầu thực tế).
• Phê duyệt 2: Giám đốc Bộ phận (Kiểm soát nhu cầu phòng ban).
• Phê duyệt 3: Tổng Giám đốc (Duyệt số lượng Headcount tổng thể).

Vấn đề: Nếu Tổng Giám đốc đã duyệt ngân sách nhân sự (Headcount Budget) hàng năm, việc ông/bà ấy phải ký vào từng hồ sơ tuyển dụng nhân viên cấp thấp là hành động vi mô hóa (Micromanagement). Nó thể hiện sự thiếu tin tưởng vào năng lực kiểm soát của các cấp dưới.

3.2. Hậu quả Định Lượng và Định Tính của việc phê duyệt chồng chéo

Hậu quả của sự trùng lặp phê duyệt không chỉ dừng lại ở sự bực bội của nhân viên. Nó ảnh hưởng trực tiếp đến các chỉ số hoạt động then chốt (KPIs) của doanh nghiệp:

• a) Tăng Chi phí Vận hành (Operational Costs):
  Mỗi lần phê duyệt thừa thãi là một lần lãng phí thời gian của các nhà quản lý cấp cao. Nếu một Giám đốc Tài chính (với mức lương cao) phải dành 3 giờ/ngày để ký duyệt các hóa đơn dưới 50 triệu đồng, chi phí lương cho thời gian đó có thể dễ dàng được tính toán và đó là chi phí không gia tăng giá trị.
• b) Kéo dài Chu kỳ Thanh toán (Days Payable Outstanding – DPO):
  DPO là chỉ số tài chính quan trọng đo lường thời gian trung bình công ty phải trả tiền cho nhà cung cấp. Quy trình phê duyệt dài dòng làm chậm việc xử lý hóa đơn, kéo dài DPO. Điều này không chỉ gây căng thẳng với nhà cung cấp mà còn làm mất khả năng tận dụng các chiết khấu thanh toán sớm (Early Payment Discounts), trực tiếp làm tăng giá vốn hàng bán (COGS).
• c) Giảm Sự hài lòng của Nhân viên (Employee Satisfaction) và Tăng Burnout:
  Khi nhân viên cấp dưới phải chờ đợi quá lâu để có được quyết định đơn giản, họ mất động lực. Việc phải theo dõi ba người quản lý khác nhau để xin ba chữ ký cho một việc duy nhất tạo ra sự chán nản và cảm giác tổ chức trì trệ.
• d) Khó khăn trong Chuyển đổi Số (Digital Transformation):
  Các quy trình phức tạp, chồng chéo rất khó để số hóa. Khi hệ thống phải mô phỏng một quy trình 4 bước phê duyệt trùng lặp, việc triển khai phần mềm quản lý quy trình (BPM) hoặc ERP sẽ trở nên tốn kém, mất thời gian và dễ phát sinh lỗi.

3.3. Nguồn gốc Sâu xa của sự Chồng chéo: Văn hóa, Cơ chế Kiểm soát và Hệ thống ERP

Để giải quyết tận gốc, chúng ta cần tìm hiểu cội rễ của vấn đề, thường là sự kết hợp của ba yếu tố:

• Thứ nhất, Văn hóa Thiếu Niềm Tin và Sợ Rủi ro:
  Trong nhiều tổ chức (đặc biệt là các công ty gia đình hoặc các công ty đã từng gặp khủng hoảng kiểm soát), nhà quản lý cấp cao không muốn buông bỏ quyền lực vì sợ thất thoát. Họ yêu cầu “kiểm tra lần hai” như một mạng lưới an toàn. Hành động này, dù xuất phát từ ý định tốt, lại bóp nghẹt sự tự chủ của các cấp quản lý thấp hơn và biến hệ thống kiểm soát thành hệ thống trì hoãn.
• Thứ hai, Cơ chế Kiểm soát Nội bộ Lỗi thời (Outdated Internal Control):
  Các ngưỡng phê duyệt (Approval Thresholds) được thiết lập cách đây 5 năm khi quy mô công ty chỉ bằng 1/10 hiện tại. Dù công ty đã lớn mạnh, ngưỡng 5 triệu đồng vẫn yêu cầu Giám đốc cấp cao ký duyệt. Thiếu quy trình định kỳ rà soát và điều chỉnh DoA (Delegation of Authority).
• Thứ ba, Hạn chế của Hệ thống ERP và Workflow Management (Quản lý Dòng công việc):
  Nhiều doanh nghiệp sử dụng các hệ thống ERP cũ kỹ, không linh hoạt trong việc cấu hình các quy tắc phê duyệt phức tạp dựa trên logic (ví dụ: IF Transaction Value > X AND Department = Y, THEN Approval goes to Z). Do đó, để đảm bảo không bỏ sót kiểm soát, IT buộc phải cấu hình quy trình theo hướng an toàn nhất: gửi yêu cầu đến tất cả các cấp liên quan, dẫn đến tình trạng ký duyệt dư thừa.

3.4. Rủi ro về Kiểm toán và Tính tuân thủ (Compliance)

Sự trùng lặp phê duyệt, trớ trêu thay, không làm tăng tính bảo mật hay tuân thủ một cách hiệu quả. Ngược lại, nó tạo ra sự phức tạp có thể che giấu các lỗ hổng thực sự.

Khi một yêu cầu phải đi qua ba cấp quản lý, cả ba người này đều có xu hướng ký nhanh chóng, giả định rằng người trước đó đã kiểm tra đầy đủ. Điều này được gọi là “Diffusion of Responsibility” (Phân tán Trách nhiệm). Nếu có gian lận hoặc sai sót xảy ra, rất khó để xác định ai là người chịu trách nhiệm cuối cùng, gây ra rủi ro nghiêm trọng khi các kiểm toán viên độc lập tiến hành đánh giá. Kiểm soát hiệu quả không phải là kiểm soát nhiều lớp, mà là kiểm soát đúng điểm và đúng người.

Phần IV: Xây Dựng Khung Quản Trị Phê Duyệt Tinh Gọn (Giải pháp chuyên sâu)

Việc tái cấu trúc quy trình phê duyệt yêu cầu một sự can thiệp chiến lược, không phải chỉ là điều chỉnh vài con số.

4.1. Thiết lập Ma trận Trách nhiệm (RACI Model) Cải tiến

Mô hình RACI (Responsible, Accountable, Consulted, Informed) là công cụ cơ bản, nhưng cần được áp dụng một cách nghiêm ngặt cho từng bước trong quy trình phê duyệt. Sai lầm lớn nhất là nhầm lẫn giữa A (Accountable – Người chịu trách nhiệm cuối cùng) và R (Responsible – Người thực hiện).

Trong bối cảnh phê duyệt, chỉ có MỘT người được gán là A (Accountable) cho một quyết định cụ thể. Người này là người ký duyệt cuối cùng, người chịu trách nhiệm về kết quả nếu quyết định sai.

Cải tiến RACI: Xác định ngưỡng A.

Ví dụ: Đối với chi tiêu IT.

• Dưới 50 triệu: Trưởng phòng IT là A. Tài chính là I (Informed – được thông báo) nếu nằm trong ngân sách.
• 50 triệu – 200 triệu: Giám đốc IT là A. Giám đốc Tài chính là C (Consulted – được tư vấn về tác động dòng tiền).
• Trên 200 triệu: Tổng Giám đốc Vận hành là A. Giám đốc IT, Giám đốc Tài chính là C.

Việc xác định rõ ràng ai là A sẽ ngay lập tức loại bỏ việc hai hoặc ba cấp quản lý cùng ký vào ô “Accountable”, vốn là nguyên nhân chính gây ra sự trùng lặp.

4.2. Xây dựng Ngưỡng Quyết Định Tự Chủ (Delegation of Authority – DoA)

DoA là văn bản nền tảng xác định rõ giới hạn quyền lực và trách nhiệm ra quyết định tại mỗi cấp bậc và chức danh. Đây là giải pháp hữu hiệu nhất để chống lại sự trùng lặp. DoA cần phải được thiết lập dựa trên:

• a) Giá trị Giao dịch (Transaction Value): Như đã đề cập ở trên, xác định ngưỡng tiền cụ thể cho từng cấp.
• b) Loại Giao dịch (Transaction Type): Phân biệt rõ ràng giữa chi phí vận hành (Opex) và chi phí vốn (Capex). Một Giám đốc có thể có quyền phê duyệt 1 tỷ Opex, nhưng chỉ được phê duyệt 100 triệu Capex.
• c) Tác động Chiến lược (Strategic Impact): Ngay cả các giao dịch giá trị nhỏ, nếu có tác động lớn đến chiến lược (ví dụ: ký kết hợp đồng độc quyền với đối tác mới), vẫn cần phải được phê duyệt ở cấp cao nhất.

Quy trình xây dựng DoA không chỉ là thiết lập ngưỡng, mà còn là Đào tạo và Ủy quyền chính thức. Cấp trên cần ủy quyền và chấp nhận rủi ro nằm trong giới hạn đã phân quyền. Nếu cấp dưới đưa ra quyết định sai trong phạm vi thẩm quyền của họ, vấn đề là đào tạo và giám sát, không phải thu hồi quyền hạn.

4.3. Phân biệt giữa Quyết Định Chiến Lược và Phê Duyệt Vận Hành

Nhà quản lý cấp cao (C-Suite) nên tập trung vào Quyết Định Chiến Lược (Strategic Decisions) – những quyết định định hình tương lai của công ty (ví dụ: Ngân sách tổng thể, M&A, Đầu tư công nghệ lớn).

Ngược lại, Phê Duyệt Vận Hành (Operational Approvals) – những quyết định đảm bảo hoạt động hàng ngày diễn ra suôn sẻ (ví dụ: Chi tiêu ngân sách đã duyệt, tuyển dụng thay thế) – phải được phân quyền xuống các cấp quản lý vận hành.

Khi Tái cấu trúc, cần loại bỏ mọi phê duyệt vận hành của C-Suite, trừ khi nó vượt quá giới hạn DoA hoặc nằm ngoài ngân sách đã được HĐQT phê duyệt. Điều này giải phóng thời gian của lãnh đạo, cho phép họ tập trung vào những việc thực sự tạo ra giá trị chiến lược.

4.4. Tối ưu hóa Quy trình bằng Công nghệ (Automation & Cloud Adoption)

Việc số hóa quy trình phê duyệt là bước bắt buộc để duy trì tính nhất quán của DoA. Các hệ thống Quản lý Quy trình Kinh doanh (BPM) hoặc các module Workflow trong các giải pháp ERP hiện đại (nhất là các hệ thống Cloud adoption) cho phép mã hóa logic phê duyệt phức tạp (Approval Logic).

Ví dụ, hệ thống có thể tự động kiểm tra:

1. Số tiền có nằm trong ngân sách phòng ban không? (Kiểm tra ngân sách).
2. Người yêu cầu có thẩm quyền khởi tạo không? (Kiểm tra vai trò).
3. Người phê duyệt tiếp theo có phải là cấp trên trực tiếp (theo cơ cấu tổ chức) hay là người có DoA tài chính? (Định tuyến thông minh).

Khi logic được mã hóa, khả năng xảy ra lỗi do yếu tố con người (quên xin chữ ký hoặc ký duyệt thừa) sẽ giảm đáng kể. Hơn nữa, các hệ thống Cloud hiện đại cung cấp dấu vết kiểm toán (Audit Trail) hoàn hảo, ghi lại chi tiết thời gian phê duyệt, người phê duyệt và lý do, làm tăng tính minh bạch và tuân thủ.

Phần V: Góc Nhìn Chuyên Sâu: Tiêu Chuẩn Kiểm Soát và Quản Trị Rủi Ro (E-E-A-T Technical Depth)

Để làm rõ hơn về tầm quan trọng của việc kiểm soát phê duyệt tinh gọn, chúng ta cần liên kết nó với các chuẩn mực quản trị quốc tế.

5.1. Liên kết Quy trình Phê duyệt với Khung Kiểm soát Nội bộ (COSO)

Khung COSO (Committee of Sponsoring Organizations of the Treadway Commission) là tiêu chuẩn vàng cho kiểm soát nội bộ. Quy trình phê duyệt nằm trong Thành phần Kiểm soát Hoạt động (Control Activities).

Theo COSO, kiểm soát phải “phù hợp” (Appropriate) và “hiệu quả” (Effective). Quá nhiều lớp phê duyệt (trùng lặp) vi phạm nguyên tắc về tính hiệu quả, vì nó không mang lại thêm sự đảm bảo mà chỉ tăng chi phí và thời gian.

Các chuyên gia tái cấu trúc cần đánh giá các điểm kiểm soát phê duyệt bằng cách sử dụng nguyên tắc “Ba Phân Tách Nhiệm Vụ” (Segregation of Duties – SoD). SoD yêu cầu không có cá nhân nào kiểm soát toàn bộ vòng đời của một giao dịch (ví dụ: Người khởi tạo yêu cầu mua hàng không được là người phê duyệt chi trả).

Vấn đề trùng lặp phê duyệt không phải là vấn đề SoD, mà là vấn đề “Phân tán Kiểm soát” (Diffusion of Control). Khi SoD được đảm bảo, chúng ta có thể tối giản hóa số lượng người ký duyệt cho mỗi bước, miễn là DoA được tuân thủ.

5.2. Vai trò của Chứng nhận SOC (Service Organization Control) trong môi trường Cloud

Với xu hướng Cloud adoption (áp dụng công nghệ đám mây) ngày càng tăng, nhiều quy trình phê duyệt quan trọng (như quản lý truy cập hệ thống, thay đổi cấu hình) được thực hiện trên các nền tảng Cloud bên thứ ba.

Chứng nhận SOC là báo cáo kiểm toán quan trọng, đặc biệt là SOC 1 Type 2 và SOC 2 Type 2. SOC 1 tập trung vào kiểm soát ảnh hưởng đến báo cáo tài chính. Nếu một quy trình phê duyệt chi tiêu được thực hiện trên một hệ thống SaaS (Software as a Service) và nhà cung cấp có SOC 1 Type 2, điều này chứng minh rằng các kiểm soát của họ (bao gồm cả kiểm soát phê duyệt) đã được kiểm toán và vận hành hiệu quả trong một khoảng thời gian nhất định.

Khi doanh nghiệp tái cấu trúc, việc chuyển giao quy trình phê duyệt lên các hệ thống Cloud phải đi kèm với việc kiểm tra chứng nhận SOC của nhà cung cấp. Điều này cho phép chúng ta tự tin giảm thiểu kiểm soát nội bộ thủ công, vì một phần kiểm soát đã được đảm bảo bởi hệ thống bên ngoài, loại bỏ nhu cầu phê duyệt thủ công trùng lặp.

5.3. Đo lường Hiệu quả Phê duyệt bằng KPIs Kế toán Vận hành

Để đánh giá thành công của việc tái cấu trúc phê duyệt, cần sử dụng các KPIs định lượng, không chỉ dựa vào cảm tính:

• a) Cycle Time Phê duyệt (Approval Cycle Time – ACT): Thời gian trung bình từ khi yêu cầu được gửi đến khi nhận được quyết định cuối cùng. Mục tiêu là giảm ACT xuống mức tối thiểu, thường đo bằng giờ hoặc ngày, thay vì tuần.
• b) Tỷ lệ Phê duyệt Chuyển tiếp (Pass-Through Rate): Tỷ lệ yêu cầu được phê duyệt ở cấp quản lý thấp nhất mà không cần leo lên cấp cao hơn. Tỷ lệ này càng cao, DoA càng hiệu quả.
• c) Chi phí Xử lý Giao dịch (Cost Per Transaction): Tổng chi phí nhân sự và hệ thống để xử lý một yêu cầu (ví dụ: một hóa đơn mua hàng). Khi loại bỏ các bước phê duyệt dư thừa, chi phí này phải giảm.
• d) Days Payable Outstanding (DPO): Như đã nói, DPO giảm là dấu hiệu rõ ràng của việc quy trình P2P (Procure-to-Pay) đã được tinh gọn và tăng tốc.

Phần VI: Kinh Nghiệm Thực Chiến và Ví dụ Điển Hình (Case Studies)

Chúng tôi đã triển khai các dự án tái cấu trúc vận hành với trọng tâm là tối ưu hóa DoA và loại bỏ phê duyệt trùng lặp. Dưới đây là hai ví dụ điển hình về bối cảnh, thách thức, giải pháp và kết quả định lượng.

6.1. Case Study 1: Tối ưu hóa Chi tiêu Mua hàng tại Doanh nghiệp Bán lẻ Đa chi nhánh

Bối cảnh và Thách thức:

Công ty TNHH X (Tên giả định) là chuỗi bán lẻ có 80 cửa hàng, đang trong giai đoạn mở rộng nhanh chóng.

Thách thức: Quy trình mua hàng (P2P) hoàn toàn thủ công, sử dụng giấy tờ và email. DoA được thiết lập từ 5 năm trước, theo đó bất kỳ khoản chi tiêu nào trên 20 triệu đồng đều yêu cầu sự phê duyệt của Giám đốc Vận hành và Giám đốc Tài chính (CFO).

Hệ quả: Các yêu cầu mua sắm nhỏ nhưng cần gấp (ví dụ: sửa chữa thiết bị cửa hàng, mua vật tư marketing) bị tắc nghẽn. ACT trung bình là 7 ngày làm việc. CFO phải xử lý khoảng 150 yêu cầu phê duyệt/tuần, trong đó 80% là dưới 50 triệu đồng và đã nằm trong ngân sách phòng ban.

Giải pháp Reboostlab (Tái cấu trúc DoA và Số hóa):

1. Phân tích Dòng chảy Giá trị P2P: Xác định chính xác 18 bước trong quy trình, với 5 điểm phê duyệt trùng lặp.
2. Tái thiết lập DoA theo Nguy cơ và Giá trị: Tăng ngưỡng phê duyệt của Trưởng phòng Vận hành từ 20 triệu lên 100 triệu cho Opex (chi phí vận hành) đã được duyệt ngân sách. CFO chỉ phê duyệt các khoản trên 100 triệu hoặc các khoản ngoài ngân sách (ví dụ: cần chi thêm 50 triệu cho sửa chữa khẩn cấp không có trong kế hoạch).
3. Triển khai Hệ thống Workflow Automation: Sử dụng nền tảng Cloud tích hợp với hệ thống kế toán hiện tại. Mã hóa logic phê duyệt mới. Hệ thống tự động kiểm tra ngân sách trước khi định tuyến. Nếu nằm trong ngân sách và dưới 100 triệu, yêu cầu chỉ chuyển đến Trưởng phòng Vận hành (Accountable).
4. Phân tách chức năng: Đảm bảo Kế toán chỉ hạch toán và Chi trả (Payables), không tham gia phê duyệt ngân sách.

Kết quả Định lượng:

• a) Giảm ACT: Thời gian phê duyệt trung bình giảm từ 7 ngày xuống còn 1.5 ngày làm việc.
• b) Tỷ lệ Phê duyệt Chuyển tiếp: Tăng 65% số yêu cầu được phê duyệt hoàn toàn ở cấp quản lý phòng ban.
• c) Tiết kiệm thời gian Quản lý cấp cao: Giải phóng khoảng 70% thời gian của CFO dành cho các công việc phê duyệt hành chính, chuyển sang tập trung vào Phân tích Hiệu suất Tài chính Chiến lược.
• d) Cải thiện DPO: Khả năng tận dụng chiết khấu thanh toán sớm tăng 15% do tốc độ xử lý hóa đơn nhanh hơn.

6.2. Case Study 2: Tái cấu trúc Phòng Công nghệ và Phê duyệt SaaS tại Công ty Dịch vụ Kỹ thuật số

Bối cảnh và Thách thức:

Công ty Y (Tên giả định) là công ty cung cấp dịch vụ kỹ thuật số quy mô trung bình. Họ sử dụng hơn 50 công cụ SaaS khác nhau.

Thách thức: Mua sắm và gia hạn hợp đồng SaaS bị trùng lặp phê duyệt nghiêm trọng. Mỗi yêu cầu gia hạn (dù chỉ là 500 USD/tháng) phải được: 1) Trưởng nhóm kỹ thuật (yêu cầu kỹ thuật), 2) Giám đốc Vận hành (ngân sách), 3) Trưởng phòng Bảo mật Thông tin (CISO) (kiểm soát rủi ro dữ liệu), và 4) Giám đốc Tài chính (chi tiêu) phê duyệt.

Lý do cho sự trùng lặp này là sự thiếu tin tưởng vào khả năng kiểm soát rủi ro bảo mật của CISO cấp dưới, buộc Giám đốc Vận hành phải xem xét lại.

Giải pháp Reboostlab (Tối ưu hóa SoD và Kiểm soát Rủi ro):

1. Phân tích Rủi ro theo Cấp độ SaaS: Phân loại các công cụ SaaS thành 3 cấp: Cấp A (rủi ro cao, xử lý dữ liệu khách hàng), Cấp B (rủi ro trung bình, dữ liệu nội bộ), Cấp C (rủi ro thấp, công cụ văn phòng).
2. Tái cấu trúc Quy trình Phê duyệt CISO: Chỉ yêu cầu CISO cấp cao phê duyệt các công cụ Cấp A. Đối với Cấp B và C, giao toàn bộ quyền phê duyệt rủi ro cho Trưởng nhóm Bảo mật, miễn là họ đã hoàn thành danh sách kiểm tra bảo mật (Security Checklist) đã được xác định trước.
3. Liên kết Phê duyệt SaaS với Chứng nhận SOC: Bắt buộc nhà cung cấp SaaS Cấp A phải có SOC 2 Type 2 hoặc tương đương. Khi nhà cung cấp có chứng nhận này, CISO cấp cao không cần thực hiện đánh giá sâu rộng về kiểm soát nội bộ của bên thứ ba nữa, chỉ cần phê duyệt chiến lược.
4. Điều chỉnh DoA Tài chính: Cho phép Giám đốc Vận hành tự động phê duyệt gia hạn SaaS Cấp B và C miễn là nằm trong ngân sách đã duyệt, loại bỏ bước phê duyệt của GĐ Tài chính cho các giao dịch dưới 10,000 USD/năm.

Kết quả Định lượng:

• a) Giảm Thời gian Cấp phép SaaS: Thời gian mua sắm/gia hạn công cụ SaaS Cấp B và C giảm từ 4 ngày xuống 8 giờ.
• b) Giảm Rủi ro Tuân thủ: Tỷ lệ công cụ SaaS Cấp A có chứng nhận SOC tăng từ 40% lên 95%.
• c) Tăng Tốc độ Phát triển: Giảm sự trì hoãn trong việc cung cấp công cụ cần thiết cho đội ngũ kỹ thuật, giúp tăng tốc độ triển khai dự án (Deployment Velocity) thêm 12%.
• d) Tinh gọn phê duyệt: Loại bỏ thành công 2 lớp phê duyệt trùng lặp (GĐ Vận hành và GĐ Tài chính) cho các công cụ SaaS rủi ro thấp.

Phần VII: Điểm Hành Động Cốt Lõi và Kết Luận

Tái cấu trúc quy trình phê duyệt không phải là công việc một sớm một chiều. Nó đòi hỏi sự cam kết từ cấp lãnh đạo cao nhất để thay đổi văn hóa từ kiểm soát tập trung sang ủy quyền chiến lược.

5 Điểm Hành Động Cốt Lõi (Actionable Takeaways)

1. Kiểm toán Ngưỡng Quyết Định (DoA Audit): Ngay lập tức rà soát lại văn bản DoA hiện tại (nếu có). Hỏi: Ngưỡng giá trị này được thiết lập khi nào? Nó có còn phù hợp với quy mô doanh nghiệp hiện tại không? Thiết lập lịch trình rà soát DoA hàng năm.
2. Lập Bản đồ Quy trình (Process Mapping) theo Góc nhìn ‘A’: Vẽ lại các quy trình phê duyệt quan trọng (P2P, Tuyển dụng, Hợp đồng) và dán nhãn duy nhất cho người Accountable (A) cho mỗi bước quyết định. Nếu có hai người là A, đó là điểm nghẽn cần loại bỏ.
3. Phân biệt Rõ ràng giữa C, I và A: Đào tạo lại đội ngũ quản lý về mô hình RACI. Nhấn mạnh rằng “Consulted” (Tư vấn) nghĩa là cung cấp ý kiến, không phải phê duyệt. “Informed” (Thông báo) nghĩa là nhận thông báo, không có quyền phủ quyết. Chỉ người “Accountable” (Chịu trách nhiệm) mới có quyền ký duyệt.
4. Số hóa với Logic (Automate with Logic): Nếu đang sử dụng hệ thống số, đảm bảo rằng logic phê duyệt được mã hóa chặt chẽ theo DoA mới. Hệ thống phải tự động định tuyến yêu cầu chỉ đến đúng người A, loại bỏ các bước C và I khỏi chuỗi phê duyệt chính.
5. Kiểm soát Rủi ro bằng Nền tảng: Thay vì kiểm soát bằng cách ký duyệt nhiều lần, hãy kiểm soát bằng cách yêu cầu các tiêu chuẩn cơ bản (ví dụ: Security Checklist đã hoàn thành, Vendor SOC Report đã được xác nhận). Điều này chuyển từ kiểm soát thủ công, chậm chạp sang kiểm soát dựa trên tuân thủ nền tảng nhanh hơn.

Sự trùng lặp phê duyệt giữa các cấp quản lý là một căn bệnh mạn tính trong nhiều tổ chức đang phát triển. Nó là biểu hiện của một hệ thống quản trị bị kéo căng, nơi các cơ chế kiểm soát không còn phù hợp với tốc độ kinh doanh. Bằng cách áp dụng các khung chiến lược như DoA, RACI tinh gọn, và tận dụng công nghệ để mã hóa logic kiểm soát, doanh nghiệp không chỉ tăng tốc độ ra quyết định mà còn thực sự củng cố sự kiểm soát nội bộ, giảm rủi ro và giải phóng năng lực chiến lược của đội ngũ lãnh đạo.

Nếu doanh nghiệp của bạn đang phải đối mặt với sự trì trệ trong việc phê duyệt, đội ngũ quản lý cấp cao đang bị chôn vùi trong các công việc hành chính, hoặc các chỉ số DPO và ACT đang gây áp lực lên lợi nhuận, đây chính là thời điểm cần một góc nhìn chuyên sâu và độc lập để mổ xẻ và tái thiết kế lại dòng chảy giá trị cốt lõi.

Hãy liên hệ để chúng ta cùng nhau phân tích chi tiết bản đồ quy trình vận hành hiện tại của tổ chức bạn, xác định các điểm chồng chéo và xây dựng một lộ trình tái cấu trúc vận hành tinh gọn, hiệu quả và bền vững.