Cách chuẩn hóa quy trình, vai trò và trách nhiệm

Khi doanh nghiệp còn nhỏ, mọi người thường giải quyết công việc bằng trao đổi trực tiếp. Cách này nhanh và linh hoạt. Nhưng khi số nhân viên, khách hàng và giao dịch tăng lên, những câu hỏi sau bắt đầu xuất hiện:

• việc này ai chịu trách nhiệm;
• ai có quyền phê duyệt;
• bước trước phải bàn giao gì;
• hồ sơ lưu ở đâu;
• trường hợp ngoại lệ xử lý thế nào;
• tại sao hai nhân viên làm cùng một việc nhưng theo hai cách khác nhau.

Đó là thời điểm doanh nghiệp cần chuẩn hóa.

Chuẩn hóa không có nghĩa là viết một bộ quy trình dày. Mục tiêu là làm cho luồng công việc dễ hiểu, có người chịu trách nhiệm và có điểm kiểm soát phù hợp.

Bước 1: Xác định quá trình, không bắt đầu bằng tên phòng ban

Phòng ban là cơ cấu tổ chức. Quá trình là cách doanh nghiệp tạo ra kết quả.

Ví dụ:

Yêu cầu khách hàng → Báo giá → Hợp đồng → Thực hiện dịch vụ → Bàn giao → Thu tiền → Chăm sóc

Luồng này có thể đi qua Sales, Operations, Finance và Management.

Nếu chỉ viết quy trình riêng theo từng phòng ban, doanh nghiệp dễ bỏ sót điểm bàn giao giữa các đơn vị.

Bước 2: Với mỗi quá trình, xác định 6 thành phần

Một mô hình đơn giản:

1. Purpose – quá trình tồn tại để làm gì?
2. Input – đầu vào là gì?
3. Activities – các bước chính?
4. Owner – ai chịu trách nhiệm cuối cùng?
5. Output – đầu ra?
6. Control/Evidence – kiểm soát và bằng chứng?

Ví dụ quá trình mua hàng:

• Mục đích: đảm bảo hàng hóa/dịch vụ đáp ứng yêu cầu.
• Đầu vào: yêu cầu mua hàng.
• Hoạt động: xác nhận nhu cầu → chọn nhà cung cấp → phê duyệt → đặt hàng → nhận → đánh giá.
• Owner: Purchasing/Operations.
• Đầu ra: hàng hóa/dịch vụ được chấp nhận.
• Bằng chứng: yêu cầu mua, báo giá, PO, nghiệm thu.

Chỉ với khung này, doanh nghiệp đã có thể nhìn thấy nhiều khoảng trống.

Bước 3: Phân biệt “thực hiện” và “chịu trách nhiệm”

Một lỗi phổ biến là ghi nhiều người cùng “chịu trách nhiệm”.

Có thể dùng tư duy RACI:

• R – Responsible: người thực hiện;
• A – Accountable: người chịu trách nhiệm cuối cùng;
• C – Consulted: người cần được tham vấn;
• I – Informed: người cần được thông báo.

Không nhất thiết mọi quy trình phải có một bảng RACI phức tạp. Nhưng với bước quan trọng như phê duyệt hợp đồng, thay đổi hệ thống hoặc xử lý sự cố, việc phân vai rõ rất hữu ích.

Bước 4: Xác định điểm bàn giao

Nhiều lỗi không phát sinh trong một phòng ban mà phát sinh khi chuyển việc.

Ví dụ Sales bàn giao cho Operations.

Cần rõ:

• khi nào được xem là “đủ điều kiện bàn giao”;
• hồ sơ tối thiểu;
• ai xác nhận;
• nếu thiếu thông tin thì trả lại thế nào;
• trạng thái được cập nhật ở đâu.

Đây là lý do workflow thường hữu ích hơn một đoạn mô tả dài.

Bước 5: Xác định các điểm cần phê duyệt

Không phải việc nào cũng cần lãnh đạo ký.

Một hệ thống hiệu quả nên phân loại:

• công việc bình thường;
• ngoại lệ;
• giao dịch vượt ngưỡng;
• thay đổi có rủi ro;
• vấn đề cần escalation.

Ví dụ:

• báo giá dưới một ngưỡng có thể do Sales Manager phê duyệt;
• hợp đồng có điều khoản pháp lý đặc biệt cần Legal/Director;
• nhà cung cấp cloud mới cần IT/Security review.

Điểm phê duyệt nên gắn với rủi ro, không phải thói quen.

Bước 6: Chọn đúng hình thức tài liệu

Không phải nội dung nào cũng cần Procedure.

Có thể sử dụng:

• workflow;
• checklist;
• SOP;
• guideline;
• form;
• template;
• matrix;
• system configuration;
• ticket workflow;
• dashboard.

Ví dụ, checklist onboarding nhân viên có thể hiệu quả hơn một quy trình dài 10 trang.

Bước 7: Gắn quy trình với bằng chứng

Một quy trình chỉ có giá trị nếu doanh nghiệp chứng minh được nó đã được thực hiện.

Ví dụ:

Quy trình yêu cầu đánh giá nhà cung cấp hàng năm

Bằng chứng có thể là:

• scorecard;
• biên bản review;
• dữ liệu KPI;
• ticket;
• email quyết định;
• danh sách approved supplier.

Nếu quy trình nói một việc nhưng hệ thống thực tế không tạo được bằng chứng, cần xem lại cách thiết kế.

Bước 8: Dùng hệ thống số nếu có thể

Nhiều kiểm soát không cần thêm biểu mẫu.

Ví dụ:

• approval trong ERP;
• ticket trong Jira;
• permission trong Microsoft 365;
• version history;
• CRM stage;
• automated notification.

Một workflow điện tử được cấu hình đúng có thể vừa thực hiện kiểm soát vừa lưu bằng chứng.

Bước 9: Kiểm tra bằng cách trace một case thật

Sau khi chuẩn hóa, chọn một giao dịch thật và đi từ đầu đến cuối.

Hỏi:

• có bước nào bị bỏ;
• người thực hiện có hiểu;
• thời gian có hợp lý;
• dữ liệu có bị nhập lại;
• có bước phê duyệt không cần thiết;
• hồ sơ có truy xuất được.

Đây là cách rất nhanh để phát hiện quy trình “đẹp trên giấy nhưng khó dùng”.

Bước 10: Chỉ số phải phản ánh đầu ra của quá trình

Một vài ví dụ:

• Sales: conversion, thời gian phản hồi.
• Delivery: đúng hạn, lỗi, rework.
• Purchasing: lead time, supplier performance.
• IT: uptime, incident response.
• HR: time-to-fill, training completion.

Đừng chọn KPI chỉ vì dễ đếm.

Khi nào doanh nghiệp nên chuẩn hóa lại?

Một số tín hiệu:

• nhân viên hỏi cùng một câu nhiều lần;
• nhiều phiên bản biểu mẫu;
• trách nhiệm không rõ;
• giao việc chủ yếu qua chat;
• lỗi lặp lại;
• audit phát hiện sai lệch;
• onboarding lâu;
• lãnh đạo phải phê duyệt quá nhiều việc nhỏ;
• thay nhân sự là quá trình bị gián đoạn.

Liên kết với ISO

Các tiêu chuẩn hệ thống quản lý thường yêu cầu tổ chức xác định, vận hành, đánh giá và cải tiến các quá trình cần thiết.

Nhưng ISO không yêu cầu doanh nghiệp biến tất cả thành tài liệu phức tạp.

Điều cần chứng minh là quá trình được kiểm soát và tạo ra kết quả.

Xem thêm [Làm sao biến hệ thống tài liệu thành hệ thống vận hành thực tế?](/tai-nguyen/bien-he-thong-tai-lieu-thanh-he-thong-van-hanh).

HQC có thể hỗ trợ

• [ISO & Management Systems](/dich-vu/iso-management-systems)
• [Process & Document Kit](/goi-sme/process-document-kit)
• [SME nên bắt đầu ISO từ đâu?](/tai-nguyen/doanh-nghiep-sme-bat-dau-iso-tu-dau)

Mục tiêu của chuẩn hóa không phải biến mọi hoạt động thành thủ tục. Mục tiêu là tạo ra một cách làm mà đội ngũ hiểu, thực hiện được và kiểm soát được.

[Liên hệ HQC](/lien-he) nếu doanh nghiệp muốn rà soát một số quá trình cốt lõi trước khi quyết định có cần xây lại toàn bộ hệ thống hay không.