Mở đầu — vì sao bài này quan trọng
Có một sự thật mà hầu hết các founder và trưởng nhóm đều học được một cách đau đớn: quy trình (process) không phải là thứ bạn thiết kế một lần rồi dùng mãi mãi. Quy trình là một sinh vật sống, nó phải lớn lên và thay đổi hình dạng theo đúng nhịp mà đội ngũ của bạn lớn lên.
Điều nguy hiểm nhất là quy trình thường "vỡ" một cách âm thầm. Không có tiếng chuông báo động. Hôm nay mọi thứ vẫn chạy, chỉ là chậm hơn một chút. Tuần sau chậm hơn nữa. Ba tháng sau, bạn nhận ra một quyết định lẽ ra mất 10 phút giờ cần ba cuộc họp và một tuần chờ đợi. Đội ngũ vẫn tài năng như cũ, thậm chí đông hơn, nhưng tốc độ giao hàng lại chậm đi. Đó chính là dấu hiệu quy trình đã không theo kịp quy mô.
Trong bài này, chúng ta sẽ tập trung vào một câu hỏi rất cụ thể: Khi nào một quy trình bắt đầu vỡ, tại sao nó vỡ, và làm sao để nâng cấp nó đúng lúc mà không rơi vào bẫy quan liêu hóa? Đây là kỹ năng nền tảng của người làm Operations — bởi vì trước khi bạn nói đến OKR, RACI, hay RFC (những công cụ chuyên biệt sẽ có bài riêng), bạn cần hiểu nguyên lý gốc: quy trình phù hợp với quy mô nào.
Khái niệm cốt lõi
Quy trình là gì và vì sao nó tồn tại
Hãy định nghĩa cho rõ. Quy trình là cách một nhóm người phối hợp để hoàn thành công việc lặp lại một cách nhất quán. Nó có thể là cách bạn duyệt một khoản chi, cách bạn ra quyết định tuyển dụng, cách một tính năng đi từ ý tưởng đến sản phẩm, hay đơn giản là cách các thành viên biết ai đang làm gì.
Điểm mấu chốt cần nhớ: quy trình sinh ra để giải quyết vấn đề của sự phối hợp (coordination), không phải vấn đề của công việc (work). Khi chỉ có 3 người, sự phối hợp gần như miễn phí — bạn quay sang bàn bên cạnh và hỏi một câu là xong. Khi có 50 người, chi phí phối hợp bùng nổ. Quy trình chính là công cụ để giữ chi phí phối hợp trong tầm kiểm soát.
Toán học của sự phối hợp: vì sao "cái gì đó phải thay đổi"
Có một con số giải thích tất cả. Số kênh giao tiếp giữa n người được tính bằng công thức n × (n − 1) / 2.
- 5 người → 10 kênh giao tiếp
- 20 người → 190 kênh
- 50 người → 1.225 kênh
- 100 người → 4.950 kênh
Vì thế có một quy luật thực tiễn mà tôi muốn bạn khắc cốt ghi tâm:
> Cái gì hiệu quả với 5 người sẽ vỡ ở 20 người. Cái gì hiệu quả với 20 người sẽ vỡ ở 50 người. Cái gì hiệu quả với 50 người sẽ vỡ ở 150 người.
Mỗi ngưỡng này (thường gọi là các "điểm gãy" — breakpoints) buộc bạn phải nâng cấp quy trình lên một bậc trừu tượng cao hơn: từ giao tiếp trực tiếp → sang quy ước ngầm → sang quy trình được viết ra → sang hệ thống có công cụ hỗ trợ.
Những dấu hiệu quy trình đang vỡ
Vì quy trình vỡ âm thầm, bạn cần biết cách "nghe" tiếng kêu cứu của nó. Dưới đây là những dấu hiệu kinh điển:
- Họp quá đông và quá nhiều. Khi một cuộc họp có 12 người mà chỉ 3 người thực sự nói, đó là dấu hiệu quy trình ra quyết định đang cố gồng gánh quá nhiều người. Lịch làm việc của mọi người kín đặc họp nhưng công việc thực chất lại không nhúc nhích.
- Quyết định bị tắc nghẽn. Một quyết định đơn giản phải leo qua nhiều tầng, không ai dám tự quyết, mọi thứ đổ dồn lên một người (thường là founder hoặc trưởng nhóm). Đây là dấu hiệu bạn thiếu cơ chế phân quyền quyết định.
- Thông tin bị thất lạc. "Tôi tưởng anh làm rồi", "Không ai báo tôi việc này", "Cái này quyết ở đâu vậy?" — những câu này xuất hiện càng nhiều nghĩa là kênh truyền thông tin không còn chịu nổi tải.
- Người mới mất quá lâu để làm được việc. Khi mọi tri thức nằm trong đầu vài người cũ, người mới phải đi hỏi từng người. Onboarding chậm là triệu chứng của quy trình không được ghi lại (những chủ đề chuyên sâu về onboarding sẽ có bài riêng, ở đây ta chỉ coi nó là dấu hiệu).
- Việc gấp luôn thắng việc quan trọng. Không có quy trình ưu tiên rõ ràng, nên ai la to nhất thì được làm trước. Đội ngũ lúc nào cũng "chữa cháy".
- Chất lượng dao động thất thường. Cùng một loại công việc nhưng kết quả lúc tốt lúc tệ, tùy vào việc ai làm. Đó là dấu hiệu thiếu quy trình chuẩn hóa.
Nguyên tắc vàng: quy trình phải theo sau nỗi đau, không đi trước nó
Đây là phần quan trọng nhất của bài, và cũng là nơi nhiều người làm sai. Có hai thái cực đều nguy hiểm:
- Quá ít quy trình (chaos): đội ngũ hỗn loạn, phụ thuộc vào anh hùng cá nhân, không thể mở rộng.
- Quá nhiều quy trình (bureaucracy): đội ngũ ngộp trong thủ tục, mất tốc độ, mất tinh thần, những người giỏi bỏ đi.
Tình huống thực tế
Ví dụ 1 — Startup fintech tại TP.HCM: khi duyệt chi từ "nhắn Zalo" thành nút thắt cổ chai
Một startup fintech ở TP.HCM (tạm gọi là PayNhanh) khi có 8 người thì quy trình duyệt chi cực kỳ đơn giản: ai cần mua gì thì nhắn Zalo cho anh CEO, anh trả lời "ok em" là xong. Nhanh, gọn, không ai phàn nàn.
Đến khi công ty lên 45 người, CEO nhận ra mỗi ngày anh phải trả lời 20–30 tin nhắn duyệt chi lặt vặt, từ mua giấy in đến ký hợp đồng vài trăm triệu. Anh trở thành nút thắt cổ chai (bottleneck): đi công tác một tuần là cả công ty đình trệ vì "chờ sếp duyệt". Có lần một khoản thanh toán nhà cung cấp bị trễ hạn chỉ vì CEO đang trên máy bay.
Diễn giải: Quy trình "hỏi CEO" hoàn hảo ở quy mô 8 người vì chi phí phối hợp gần bằng 0. Nhưng ở 45 người, cùng một quy trình biến CEO thành điểm nghẽn duy nhất của toàn bộ dòng tiền. Họ đã giải quyết bằng cách phân tầng theo hạn mức: dưới 2 triệu — trưởng nhóm tự duyệt; 2–20 triệu — cần quản lý cấp trên; trên 20 triệu — cần CFO. Đồng thời chuyển từ Zalo sang một form đơn giản trên Google Sheet có lưu vết.
Bài học: Khi một cá nhân trở thành điểm nghẽn cho một quyết định lặp lại, đó là tín hiệu rõ nhất rằng quy trình cần được phân quyền và ghi lại. Giải pháp không phải là "làm việc chăm hơn" mà là "thiết kế lại luồng quyết định".
Ví dụ 2 — Đội sản phẩm tại một công ty thương mại điện tử: cuộc họp planning 25 người
Một công ty thương mại điện tử ở Đông Nam Á có đội sản phẩm — kỹ thuật ban đầu 12 người. Mỗi thứ Hai họ họp planning chung: cả đội ngồi lại 1 tiếng, ai cũng nắm được mọi thứ. Rất gắn kết.
Khi đội lớn lên 25 người, cuộc họp planning thứ Hai kéo dài tới 2 tiếng rưỡi. Một nửa số người ngồi nghe những thứ chẳng liên quan đến mình, mở laptop làm việc riêng. Quyết định thì loãng vì quá nhiều ý kiến. Chi phí thật của cuộc họp: 25 người × 2,5 giờ = hơn 62 giờ-người mỗi tuần bị đốt cho một cuộc họp mà phần lớn là "nghe cho biết".
Diễn giải: Đây là cùng một triệu chứng "n bình phương" mà ta nói ở trên. Cuộc họp toàn thể là một quy trình giao tiếp tuyến tính đang bị ép chạy trên một mạng lưới phối hợp cấp số nhân. Họ đã tách thành các nhóm nhỏ tự chạy planning riêng (khoảng 5–7 người mỗi nhóm), và chỉ giữ một buổi đồng bộ ngắn 20 phút giữa các trưởng nhóm để xử lý những điểm giao thoa.
Bài học: Khi cuộc họp phình to đến mức người tham dự chỉ đóng vai khán giả, đừng cố "điều hành họp giỏi hơn" — hãy chia nhỏ đơn vị phối hợp. Quy trình đúng ở quy mô này là "nhiều cuộc họp nhỏ có mục tiêu rõ" thay vì "một cuộc họp lớn cho tất cả".
Ví dụ 3 — Netflix và triết lý "context, not control"
Một ví dụ ở tầm vóc lớn hơn để bạn thấy nguyên lý này áp dụng đến quy mô nào cũng đúng. Netflix nổi tiếng với triết lý vận hành "context, not control" — cung cấp bối cảnh chứ không kiểm soát bằng thủ tục. Thay vì viết ra hàng trăm quy trình chi tiết cho từng tình huống chi tiêu và ra quyết định, họ đưa ra một nguyên tắc ngắn gọn kiểu "hãy hành động vì lợi ích tốt nhất của Netflix" và trao quyền cho nhân viên tự quyết trong bối cảnh của mình.
Diễn giải: Netflix cố tình chống lại xu hướng tự nhiên của việc mở rộng — đó là chất thêm quy trình cho đến khi ngộp thở. Họ chấp nhận một vài sai sót do trao quyền, để đổi lấy tốc độ và khả năng giữ chân người tài. Đây không phải là "không có quy trình", mà là chọn loại quy trình rẻ nhất: đầu tư vào việc truyền đạt bối cảnh và tiêu chí quyết định, thay vì luật lệ cứng.
Bài học: Quy trình không nhất thiết phải là thủ tục nhiều bước. Đôi khi quy trình mạnh nhất chính là một nguyên tắc rõ ràng cộng với việc phân quyền. Ở quy mô lớn, việc dạy người ta cách nghĩ thường mở rộng tốt hơn việc quy định phải làm gì.
Hướng dẫn từng bước
Đây là khung 6 bước để bạn nâng cấp một quy trình đang vỡ mà không tạo ra bộ máy quan liêu:
Bước 1 — Phát hiện điểm đau thật. Đừng bắt đầu từ "chúng ta nên có quy trình cho X". Bắt đầu từ câu hỏi: "Điều gì đang lặp đi lặp lại gây ra tắc nghẽn, sai sót, hoặc chậm trễ?" Viết ra 3–5 nỗi đau cụ thể. Nếu không gọi tên được nỗi đau, đừng tạo quy trình.
Bước 2 — Định lượng chi phí của nỗi đau. Ước lượng bằng con số: nỗi đau này tốn bao nhiêu giờ-người mỗi tuần? Gây ra bao nhiêu lỗi mỗi tháng? Làm chậm giao hàng bao lâu? Việc định lượng giúp bạn ưu tiên đúng và biết được liệu quy trình mới có "đáng đồng tiền" không.
Bước 3 — Thiết kế phiên bản rẻ nhất có thể. Với mỗi nỗi đau, hỏi: giải pháp đơn giản nhất là gì? Ưu tiên theo thứ tự tăng dần độ nặng: (a) một quy ước/nguyên tắc chung; (b) một checklist hoặc template; (c) một form/quy trình ghi lại; (d) một công cụ tự động. Đừng bao giờ nhảy thẳng lên (d) khi (a) đã đủ.
Bước 4 — Ghi lại và làm cho nó dễ tìm. Một quy trình chỉ tồn tại trong đầu vài người không phải là quy trình — đó là kiến thức bộ lạc. Viết nó ra ở nơi mọi người tìm được. Ngắn gọn: ai làm, khi nào, các bước, và ai được quyền quyết định.
Bước 5 — Chỉ định người sở hữu (process owner). Mỗi quy trình cần một người chịu trách nhiệm duy trì và cải tiến nó. Không có chủ, quy trình sẽ mục nát: bối cảnh thay đổi mà quy trình đứng yên, biến thành nghi thức vô nghĩa.
Bước 6 — Đặt lịch rà soát và loại bỏ. Đây là bước hầu như ai cũng quên. Hãy đánh giá lại quy trình định kỳ (ví dụ mỗi quý): nó còn giải quyết đúng nỗi đau không? Có bước nào thừa để cắt không? Quy trình cần được cắt tỉa cũng như được thêm vào. Một tổ chức khỏe mạnh xóa quy trình cũ đều đặn như thêm quy trình mới.
Lỗi thường gặp & mẹo
Lỗi 1 — Sao chép quy trình của công ty lớn. Bạn đọc thấy Google hay Amazon làm thế này thế kia và bê nguyên về đội 20 người. Sai lầm chết người. Quy trình của họ được thiết kế cho vấn đề phối hợp ở quy mô hàng nghìn người. Áp vào đội nhỏ, nó chỉ là gánh nặng vô ích. Mẹo: hãy hỏi "quy trình này giải quyết nỗi đau nào của công ty đó, và mình có nỗi đau đó chưa?"
Lỗi 2 — Thêm quy trình sau mỗi sự cố. Một lỗi xảy ra, phản ứng bản năng là "từ giờ mọi người phải làm thêm bước kiểm tra này". Sau 30 sự cố, bạn có 30 bước thừa và một quy trình không ai theo nổi. Mẹo: chỉ thêm quy trình khi sự cố tái diễn và tốn kém. Với sự cố hiếm, chi phí phòng ngừa thường lớn hơn chi phí sự cố.
Lỗi 3 — Quy trình không có người chủ. Ai cũng dùng, không ai sửa. Mẹo: mỗi quy trình phải có tên một người chịu trách nhiệm ghi ngay trên tài liệu.
Lỗi 4 — Nhầm "quy trình chi tiết hơn" với "quy trình tốt hơn". Càng nhiều bước không có nghĩa là càng chặt chẽ. Thường thì ngược lại: quy trình dài khiến người ta lách hoặc bỏ qua. Mẹo: mục tiêu là quy trình rẻ nhất mà vẫn hiệu quả, không phải quy trình đầy đủ nhất.
Lỗi 5 — Không truyền đạt lý do (the why). Người ta tuân theo quy trình họ hiểu, và phá vỡ quy trình họ thấy vô lý. Mẹo: mỗi khi giới thiệu quy trình mới, luôn nói rõ nó ra đời để trị nỗi đau nào.
Mẹo tổng quát — Nghĩ về quy trình theo "tầng trưởng thành": giao tiếp trực tiếp (dưới ~10 người) → quy ước chung ngầm (~10–30) → tài liệu hóa (~30–80) → công cụ hóa và tự động (~80+). Luôn ở tầng thấp nhất mà quy mô hiện tại cho phép, và chỉ leo lên tầng cao hơn khi đã thực sự chạm trần.
Bài tập thực hành
Bài tập 1 — Kiểm tra sức khỏe quy trình (30 phút). Liệt kê 5 quy trình quan trọng nhất trong đội của bạn hiện nay (ví dụ: cách duyệt chi, cách ra quyết định sản phẩm, cách xử lý sự cố). Với mỗi cái, chấm điểm từ 1–5 theo hai tiêu chí: (a) nó có đang gây tắc nghẽn không? (b) nó có được ghi lại rõ ràng không? Khoanh tròn quy trình có điểm tắc nghẽn cao nhất — đó là ứng viên cần nâng cấp trước.
Bài tập 2 — Chẩn đoán điểm gãy (20 phút). Nhìn lại quy mô đội bạn 12 tháng trước và hiện tại. Chọn một quy trình mà bạn cảm thấy "trước đây chạy tốt mà giờ ì ạch". Áp dụng công thức n×(n−1)/2 để tính số kênh giao tiếp ở hai thời điểm. Viết một đoạn ngắn giải thích vì sao quy trình đó vỡ dưới góc nhìn chi phí phối hợp.
Bài tập 3 — Thiết kế phiên bản rẻ nhất (30 phút). Lấy quy trình tệ nhất từ Bài tập 1. Áp dụng 6 bước trong phần Hướng dẫn để phác thảo một phiên bản nâng cấp. Yêu cầu: giải pháp phải là tầng thấp nhất có thể (ưu tiên nguyên tắc/checklist hơn là công cụ), phải chỉ định người sở hữu, và phải có lịch rà soát. Trình bày trong tối đa một trang.
Bài tập 4 (nâng cao) — Săn quy trình chết. Tìm trong đội bạn một quy trình mà mọi người vẫn làm theo thói quen nhưng không ai nhớ nó ra đời để giải quyết vấn đề gì. Đề xuất: giữ, sửa, hay xóa? Bảo vệ quyết định của bạn bằng chi phí và lợi ích cụ thể.
Tóm tắt
- Quy trình tồn tại để kiểm soát chi phí phối hợp, không phải để quản lý bản thân công việc. Chi phí này tăng theo cấp số nhân (n×(n−1)/2) khi đội lớn lên, nên quy trình bắt buộc phải tiến hóa.
- Có những điểm gãy dự đoán được: cái gì hiệu quả ở 5 người vỡ ở 20, ở 20 vỡ ở 50, ở 50 vỡ ở 150. Đừng ngạc nhiên khi nó xảy ra — hãy chuẩn bị.
- Học cách nghe dấu hiệu vỡ: họp quá đông, quyết định tắc nghẽn, thông tin thất lạc, chất lượng dao động, việc gấp luôn thắng việc quan trọng.
- Đi giữa hai thái cực hỗn loạn và quan liêu bằng nguyên tắc vàng: thêm quy trình để trị nỗi đau đã thực sự tái diễn, và luôn chọn phiên bản rẻ nhất có thể.
- Quy trình cần người sở hữu và lịch cắt tỉa. Tổ chức khỏe mạnh xóa quy trình cũ đều đặn như thêm quy trình mới.
- Ở quy mô lớn, đôi khi quy trình mạnh nhất là một nguyên tắc rõ ràng cộng phân quyền (như triết lý "context, not control" của Netflix), chứ không phải một chuỗi thủ tục dài.