Cùng là lương 3P, vì sao Startup & Legacy phải xây dựng & triển khai theo 2 cách khác nhau?

Nếu hai doanh nghiệp Startup và Legacy đều muốn xây dựng hệ thống lương 3P, liệu có thể sử dụng cùng một phương pháp để xây dựng và triển khai hay không? Câu trả lời của tôi là: Không.

Có cần 2 cách xây dựng, triển khai lương 3P cho Legacy & Startup?

Một câu hỏi tưởng như rất đơn giản và thông thường không ai để ý khi xây dựng hệ thống lương 3P.
Khác biệt không chỉ nằm ở cách triển khai, mà bắt đầu ngay từ dữ liệu đầu vào, Benchmark và thuật toán xây dựng hệ thống. Không phải vì một doanh nghiệp lớn, một doanh nghiệp nhỏ, cũng không phải vì doanh nghiệp này có nhiều nhân viên hơn doanh nghiệp kia. Và cũng không đơn thuần chỉ vì một doanh nghiệp đã hoạt động lâu năm còn doanh nghiệp kia mới thành lập.

Điểm khác biệt căn bản nằm ở trạng thái xuất phát của doanh nghiệp. Một Startup gần như bắt đầu từ trạng thái “chưa có lịch sử tiền lương”. Trong khi đó, một doanh nghiệp đã tồn tại nhiều năm bước vào hệ thống 3P với một “di sản” đã hình thành: vị trí công việc, con người, mức lương, thâm niên, những lần tăng lương, những thỏa thuận cá nhân, những người có đóng góp đặc biệt, những bất hợp lý tích lũy qua nhiều năm...
Vì vậy, nếu chỉ nhìn vào đích đến là P1 – P2 – P3 rồi áp dụng một công thức chung cho tất cả doanh nghiệp, chúng ta đang bỏ qua một vấn đề rất quan trọng: Cùng một đích đến không có nghĩa là cùng một con đường.
Và sâu hơn nữa: Khác biệt giữa Startup và doanh nghiệp có lịch sử (Legacy) không bắt đầu ở khâu triển khai. Nó bắt đầu ngay từ cách xây dựng hệ thống.

1. Sai lầm phổ biến: coi 3P là một “bộ khung” có thể áp dụng giống nhau cho mọi doanh nghiệp

Khi nói đến lương 3P, chúng ta thường nghe một trình tự khá quen thuộc:

P1 – Pay for Position: trả lương theo giá trị công việc;
P2 – Pay for Person: trả lương theo năng lực;
P3 – Pay for Performance: trả lương theo kết quả.

Sau đó là hàng loạt công việc quen thuộc: Đánh giá giá trị VTCV → xây dựng khung năng lực → xây dựng ngạch/bậc → xác định mức lương → xây dựng KPI → triển khai. Về mặt lý thuyết, trình tự này không sai.
Nhưng vấn đề nằm ở chỗ: Doanh nghiệp đang bắt đầu từ đâu?

Nếu doanh nghiệp chưa có một hệ thống tiền lương lịch sử thì cách tiếp cận sẽ khác hoàn toàn với doanh nghiệp đang có hàng trăm con người, hàng trăm mức lương và hàng trăm “lịch sử tiền lương” khác nhau. Một hệ thống mới được thiết kế trên một tờ giấy trắng. Một hệ thống khác phải được xây dựng trên một “tờ giấy” đã có rất nhiều thứ được viết lên đó.
Không thể xử lý hai trạng thái ấy bằng cùng một logic.

2. Startup: xây dựng hệ thống trước, sau đó đưa con người vào hệ thống

Hãy hình dung một Startup đang thành lập. Doanh nghiệp bắt đầu xây dựng cơ cấu tổ chức, xác định các vị trí công việc, xây dựng mô tả công việc, xác định giá trị của từng VTCV, tham chiếu thị trường và thiết kế hệ thống tiền lương. Ở trạng thái này, doanh nghiệp tương đối tự do.
Có thể đặt câu hỏi:

Vị trí này đáng giá bao nhiêu?
Thị trường đang trả bao nhiêu cho vị trí tương đương?
Người đảm nhiệm vị trí này cần những năng lực gì?
Nếu đạt năng lực ở mức nào thì hưởng P2 ở mức nào?
Kết quả công việc sẽ tạo ra P3 như thế nào?

Tất cả đều có thể được thiết kế trước khi tuyển người hoặc trước khi bố trí người vào vị trí. Nói một cách hình tượng: Startup có thể làm ra “chiếc giày” trước, rồi tìm người có thể đi vừa chiếc giày đó.
Trình tự tư duy vì thế tương đối rõ: VTCV → Giá trị công việc → Benchmark P1 → P1 → Năng lực/P2 → Kết quả/P3 → Con người. Đây chính là lợi thế rất lớn của Startup.
Không có quá nhiều lịch sử cần xử lý. Không có hàng loạt mức lương đã hình thành từ những quyết định của quá khứ. Không có câu hỏi: “Vì sao người này đang hưởng 25 triệu trong khi người kia chỉ hưởng 18 triệu?”
Bởi hệ thống đang được thiết kế ngay từ đầu.

3. Nhưng doanh nghiệp có lịch sử lại bắt đầu từ một điểm hoàn toàn khác

Hãy đặt trường hợp một doanh nghiệp đã hoạt động 10, 15 hoặc 20 năm.
Doanh nghiệp đã có: cơ cấu tổ chức; các VTCV đang tồn tại; nhân viên đang làm việc; mức lương hiện tại; thâm niên; các lần tăng lương; phụ cấp; các khoản thu nhập khác; những thỏa thuận riêng; những người có đóng góp đặc biệt; những vị trí khó tuyển; những bất hợp lý tích lũy qua nhiều năm…

Và quan trọng nhất: Những con người này đang sống bằng hệ thống tiền lương hiện tại.
Khi doanh nghiệp quyết định chuyển sang 3P, chúng ta không thể giả định rằng mọi thứ đang là con số 0.
Hệ thống mới có thể nói: VTCV này thuộc nhóm này; Giá trị công việc của vị trí này là như thế; Khung năng lực của vị trí này là như thế; P2 của người đạt mức năng lực này là như thế. Nhưng người lao động có thể đang nhận một mức thu nhập hoàn toàn khác. Đó chính là độ vênh giữa hệ thống được thiết kế và lịch sử đã tồn tại.
Nếu không xử lý độ vênh này, hệ thống 3P rất dễ trở thành một hệ thống đúng về mặt lý thuyết nhưng khó tồn tại trong thực tế.

4. Một hình ảnh rất dễ hiểu: cùng chiều cao, cân nặng nhưng chưa chắc cùng cỡ giày

Có thể hình dung vấn đề này bằng một ví dụ đơn giản.
Giả sử một doanh nghiệp có 100 người. Ta đo chiều cao và cân nặng của họ rồi kết luận: “Những người có cùng chiều cao và cân nặng thì sẽ đi cùng một cỡ giày.”
Sau đó sản xuất hàng loạt giày theo kết quả đó, về mặt thống kê có thể có vẻ hợp lý. Nhưng khi đưa giày cho từng người, chúng ta sẽ gặp vấn đề: Có người chân dài; Có người chân bè; Có người mu bàn chân cao; Có người chân nhỏ; Có người chân lớn; Có người có đặc điểm bàn chân khác biệt. Như vậy: Chiều cao và cân nặng không đủ để xác định một đôi giày phù hợp.

Tiền lương trong doanh nghiệp có lịch sử cũng tương tự. Không thể chỉ lấy “thiết kế hệ thống mới” rồi áp lên toàn bộ con người đang tồn tại, phải đo lại trạng thái thực tế trước khi quyết định cách chuyển sang trạng thái mới.

Nếu Startup là: Thiết kế chiếc giày → tìm người đi giày.
Thì doanh nghiệp có lịch sử phải là: Đo chân → thiết kế chiếc giày mới → xác định cách chuyển từ đôi giày cũ sang đôi giày mới.
Đó là khác biệt về phương pháp, chứ không chỉ là khác biệt về triển khai.

5. Và đây là nơi xuất hiện một khác biệt rất quan trọng: Benchmark

Đây cũng là điểm mà tôi cho rằng nhiều cách tiếp cận 3P hiện nay chưa phân biệt đủ rõ.

Với Startup: Benchmark P1 là điểm xuất phát, Startup chưa có một hệ thống thu nhập lịch sử đáng kể. Do đó câu hỏi tự nhiên là vị trí công việc này có giá trị như thế nào trên thị trường? Benchmark được thực hiện ở cấp độ P1.
Có thể hình dung: Benchmark P1 → Xác định P1 → Xây dựng P2 → Xây dựng P3 → Hệ thống 3P.
Đây là logic khá tự nhiên.

Nhưng với doanh nghiệp có lịch sử: vấn đề không còn đơn giản là Benchmark P1
Bởi người lao động hiện tại đã có thu nhập, và tổng thu nhập đó, xét về bản chất, đã bao gồm nhiều thành phần khác nhau: P1 + P2 + P3 + các yếu tố lịch sử/khác.
Vậy nếu chúng ta chỉ hỏi “Benchmark P1 của vị trí này là bao nhiêu?” thì câu hỏi ấy là không đúng.
Câu hỏi đúng phải là: Mức thu nhập hiện tại của người đang giữ vị trí này đang nằm ở đâu so với thị trường và so với cấu trúc 3P mà doanh nghiệp muốn xây dựng?

Từ đó, Benchmark không chỉ được nhìn ở góc độ P1, mà phải được nhìn ở góc độ mức thu nhập. Có thể gọi đó là: Benchmark mức THU NHẬP.
Sau đó mới phân tích: Thu nhập hiện tại là bao nhiêu; Thành phần P1 hiện tại là gì; Thành phần P2 hiện tại là gì; Thành phần P3 hiện tại là gì; Có khoản nào không thuộc cấu trúc 3P hay không; Mức thu nhập hiện tại đang cao hay thấp so với thị trường; Cao/thấp vì nguyên nhân gì; Độ vênh nằm ở đâu; Và khi chuyển sang hệ thống mới thì xử lý độ vênh đó như thế nào?
Đây là một bài toán hoàn toàn khác.

6. Từ đây, thuật toán phải rẽ nhánh

Nếu đã thừa nhận rằng hai trạng thái đầu vào khác nhau, thì không thể tiếp tục giả định rằng chỉ cần một thuật toán chung. Phải có hai hướng xử lý.

Điều đáng chú ý là: Hai nhánh cuối cùng vẫn hội tụ về cùng một hệ thống P1 – P2 – P3, nhưng con đường để đi đến đó không giống nhau. Đây chính là điều thường bị bỏ qua khi người ta nói rằng: “3P là một phương pháp chung cho mọi doanh nghiệp.”
Không! 3P có thể là một đích đến chung, nhưng thuật toán để đi đến đích có thể khác nhau tùy trạng thái xuất phát.
Hiểu sâu bản chất vấn đề thì chúng ta mới xây dựng và triển khai hệ thống lương 3P sau này thành công.

7. Nhánh Startup: xây dựng tương lai

Ở Startup, tư duy cơ bản là: Doanh nghiệp muốn trở thành gì → cần những VTCV nào → mỗi VTCV có giá trị gì → thị trường trả bao nhiêu → cần năng lực gì → kết quả công việc được trả như thế nào.
Do đó hệ thống có thể được thiết kế theo hướng: VTCV → Giá trị công việc → Benchmark P1 → P1 → Khung năng lực → P2 → Hiệu quả/Kết quả → P3.

Con người được tuyển dụng hoặc bố trí vào hệ thống đã được thiết kế. Đây là bài toán: Thiết kế một hệ thống phù hợp với tương lai của doanh nghiệp.

8. Nhánh Legacy: vừa xây dựng tương lai, vừa xử lý quá khứ

Doanh nghiệp có lịch sử lại phải làm thêm một việc mà Startup gần như không phải làm đó là: Xử lý trạng thái đang tồn tại. Không thể chỉ nói: Đây là hệ thống mới; Đây là P1 mới; Đây là P2 mới; Đây là P3 mới…Bây giờ mọi người áp dụng. Bởi ngay lập tức sẽ xuất hiện hàng loạt câu hỏi:

Người đang hưởng cao hơn khung mới thì sao?
Người đang hưởng thấp hơn khung mới thì sao?
Người có thâm niên lâu năm thì sao?
Người được doanh nghiệp trả cao vì khan hiếm nhân lực thì sao?
Người có đóng góp đặc biệt thì sao?
Người đã được hứa tăng lương thì sao?
Những khoản thu nhập cũ sẽ được xử lý thế nào?
Nếu chuyển ngay sang hệ thống mới, ai tăng, ai giảm?

Đây không còn là bài toán “xây dựng hệ thống”, đây là bài toán chuyển trạng thái.

9. “Phiên lương” vì thế không phải là một bước phụ

Một hệ thống 3P cho doanh nghiệp có lịch sử cần một cầu nối giữa: Trạng thái tiền lương hiện tại và trạng thái tiền lương theo hệ thống mới. Tôi gọi quá trình này là “phiên lương”.

Có thể hình dung: Thu nhập hiện tại → xác định VTCV thực tế → Benchmark mức thu nhập → phân tích thành phần thu nhập hiện tại → đối chiếu P1/P2/P3 → xác định độ vênh → thử chuyển sang cấu trúc mới → xác lập trạng thái chuyển tiếp → đánh giá năng lực chính thức → điều chỉnh P2 → vận hành hệ thống mới.

Điểm quan trọng là không nhất thiết mọi người phải có ngay một P2 hoàn chỉnh ngay trong ngày đầu tiên chuyển sang 3P. Bởi P2 phụ thuộc vào năng lực thực tế.

Nếu chưa tổ chức đánh giá năng lực chính thức, doanh nghiệp có thể cần một trạng thái tạm thời để hệ thống có thể vận hành, sau đó mới chính thức xác định và điều chỉnh P2.
Đây chính là lý do tại sao “phiên lương” không thể bị xem như một thủ tục hành chính. Nó là một phần của thuật toán chuyển đổi hệ thống.

10. Và đừng vội kết luận: lương khác hệ thống mới = lương sai

Đây là một điểm rất nhạy cảm trong các dự án chuyển đổi 3P. Giả sử hệ thống mới tính ra: Vị trí A nên có mức P1 là X. Nhưng nhân viên đang nhận mức thu nhập cao hơn X rất nhiều, có nên kết luận ngay rằng: “Doanh nghiệp đang trả sai”?

Tôi cho rằng không. Một mức thu nhập cao hơn cấu trúc mới có thể đến từ rất nhiều nguyên nhân: đóng góp lịch sử; thâm niên; năng lực khan hiếm; thị trường lao động; quyết định quản lý trong quá khứ; cam kết với người lao động; vai trò thực tế lớn hơn mô tả hiện tại; hoặc đơn giản là một bất hợp lý đã tích lũy. Những nguyên nhân này phải được phân tích. Bởi vì khác biệt với hệ thống mới chưa đồng nghĩa với sai. Nếu không phân biệt được hai khái niệm này, dự án 3P rất dễ biến thành một cuộc “đồng hóa tiền lương”. Và khi đó, doanh nghiệp có thể có một hệ thống rất đẹp trên giấy nhưng lại tạo ra sự phản ứng rất mạnh từ người lao động.

11. Startup cũng không phải không có “độ vênh”

Điều này cũng cần nói rõ. Startup có lợi thế vì không mang theo quá nhiều lịch sử tiền lương, nhưng Startup có một loại độ vênh khác:

Độ vênh giữa thiết kế và thực tế như: Doanh nghiệp xây dựng VTCV quá lý tưởng: Khung năng lực quá đẹp; Mô tả công việc quá chuẩn; Benchmark thị trường quá cao so với khả năng tài chính; Một người thực tế phải làm nhiều vai trò nhưng hệ thống lại thiết kế mỗi VTCV quá “sạch”; Chiến lược của Startup thay đổi rất nhanh, trong khi hệ thống lương được thiết kế quá cứng.

Vì vậy: Startup không có độ vênh lịch sử, nhưng hoàn toàn có thể có độ vênh giữa thiết kế và thực tế.
Điều này cho thấy một hệ thống 3P tốt không phải là một hệ thống càng chi tiết càng tốt, nó phải phù hợp với trạng thái và mức độ trưởng thành của doanh nghiệp.

Như vậy câu hỏi cần quan tâm là: thiết kế hệ thống lương 3P của bạn có khả năng điều chỉnh linh hoạt cho mức độ trưởng thành trong tương lai của doanh nghiệp không?

12. Vậy doanh nghiệp có lịch sử khó hơn Startup?

Không nên nói đơn giản như vậy, hai bài toán khó theo hai cách khác nhau.

Startup: Thiết kế một hệ thống phù hợp với hiện tại và cả sự trưởng thành ở thì tương lai.

Doanh nghiệp có lịch sử: Thiết kế một hệ thống phù hợp với tương lai, đồng thời xử lý quá khứ đang tồn tại.
Một bên chủ yếu là bài toán thiết kế, một bên là bài toán thiết kế + chuyển đổi trạng thái.
Và chính phần “chuyển đổi trạng thái” làm cho các dự án 3P ở doanh nghiệp có lịch sử phức tạp hơn rất nhiều.

13. Khi phương pháp đã rẽ nhánh, phần mềm cũng không thể chỉ có một workflow

Đây là điểm có ý nghĩa rất lớn đối với việc số hóa hệ thống 3P.
Nếu Startup và Legacy có: dữ liệu đầu vào khác nhau; Benchmark khác nhau; trình tự xử lý khác nhau; cách phân tích khác nhau; cách xác định độ vênh khác nhau; cách chuyển đổi khác nhau…thì phần mềm không thể chỉ đơn giản là “Chọn Startup hay doanh nghiệp cũ” rồi thay đổi vài giao diện.
Sự khác biệt phải đi xuống tận logic bên trong: Input → Rule → Calculation → Validation → Workflow → Output.

Startup đi theo một thuật toán; Legacy đi theo một thuật toán khác. Sau đó hai thuật toán cùng hội tụ về một hệ thống 3P có thể vận hành. Đây mới là nơi tri thức quản trị được mã hóa thành công nghệ.
Một phần mềm 3P thực sự không chỉ là nơi nhập dữ liệu rồi xuất ra bảng lương.
Nó phải “hiểu” được: doanh nghiệp đang ở trạng thái nào; dữ liệu nào là dữ liệu đầu vào; Benchmark nào cần sử dụng; quy tắc nào cần áp dụng; bước nào được thực hiện trước; bước nào phụ thuộc vào bước nào; điều kiện nào cần kiểm tra; và trạng thái hiện tại phải được chuyển sang trạng thái nào.

Nói cách khác: Phần mềm chỉ thực sự có giá trị khi phương pháp quản trị đã được chuyển hóa thành logic có thể tính toán, kiểm tra và vận hành.

14. Từ một vấn đề của lương 3P đến một cách nhìn rộng hơn về quản trị

Có lẽ điều đáng suy nghĩ nhất không nằm ở Startup hay Legacy, nó nằm ở cách chúng ta nhìn một hệ thống quản trị. Rất nhiều phương pháp quản trị thường được trình bày như một “mô hình chuẩn”:
Có các bước A → B → C → D. Doanh nghiệp chỉ cần áp dụng theo.
Nhưng doanh nghiệp thực tế không phải những chiếc hộp giống nhau, mỗi doanh nghiệp bước vào một hệ thống quản trị với một trạng thái ban đầu khác nhau. Vì vậy, câu hỏi đúng không chỉ là: “Mô hình đúng là gì?”
Mà còn phải là: “Với trạng thái hiện tại của doanh nghiệp, phải đi từ đâu, qua những bước nào và bằng logic nào để đến được trạng thái mong muốn?”. Đó là một cách nhìn hoàn toàn khác.

15. 3P không chỉ là một hệ thống tiền lương. Nó còn là một bài toán chuyển trạng thái

Nếu chỉ nhìn 3P như ba chữ P: Position – Person – Performance, thì chúng ta dễ tập trung vào việc xây dựng từng cấu phần. Nhưng nếu nhìn sâu hơn, 3P là một quá trình đưa doanh nghiệp từ: Trạng thái tiền lương hiện tại sang Trạng thái tiền lương mong muốn.

Với Startup, khoảng cách giữa hai trạng thái tương đối nhỏ vì doanh nghiệp gần như bắt đầu từ đầu. Với Legacy, khoảng cách đó có thể rất lớn. Và giữa hai trạng thái ấy tồn tại rất nhiều thứ phải được xử lý. Do đó, một hệ thống lương 3P tốt không chỉ trả lời được câu hỏi: Mức lương nào là hợp lý?, mà còn phải trả lời được một câu hỏi khó hơn: Làm thế nào để đưa doanh nghiệp từ trạng thái đang có đến trạng thái hợp lý đó?. Đây mới là câu hỏi của triển khai thực tế.

KẾT LUẬN

Cùng là lương 3P, cùng có P1, cùng có P2, cùng có P3, cùng hướng đến sự công bằng, minh bạch và gắn tiền lương với giá trị công việc, năng lực và kết quả. Nhưng Startup và doanh nghiệp có lịch sử không bắt đầu từ cùng một trạng thái.

Startup có thể bắt đầu bằng: Benchmark P1 → P1 → P2 → P3.

Doanh nghiệp có lịch sử cần bắt đầu bằng: Benchmark mức thu nhập → phân tích thu nhập hiện tại → phân tích độ vênh → thiết kế lại P1/P2/P3 → chuyển đổi.
Hai con đường cuối cùng đều dẫn đến: HỆ THỐNG 3P.

Nhưng không có lý do gì để bắt chúng phải đi cùng một con đường. Và đó cũng là lý do tôi cho rằng khi xây dựng một hệ thống 3P thực sự có khả năng triển khai trên doanh nghiệp, câu hỏi đầu tiên không nên là: “Chúng ta sẽ xây dựng P1, P2, P3 như thế nào?” Mà phải là: “Doanh nghiệp đang ở trạng thái nào?” Bởi khi trạng thái xuất phát khác nhau, dữ liệu khác nhau, Benchmark khác nhau, thuật toán khác nhau và cách chuyển đổi cũng khác nhau.

Một hệ thống quản trị tốt không chỉ biết doanh nghiệp nên đi đến đâu, nó phải biết doanh nghiệp đang đứng ở đâu và phải đi bằng con đường nào để đến đó.
Đó chính là khác biệt giữa một “bộ khung 3P” và một hệ thống 3P có khả năng vận hành trong thực tế.

💡 #luong3p #P1 #quantrinhansu #hethongluong3p #C3P

Liên hệ "Đăng ký Demo/dùng thử" nền tảng The Platform C3P
Đăng ký các khóa học Lương 3P; Xây dựng BSC-KPI; Định mức-Đơn giá

Tác giả
Phạm Quang Phước
Chuyên gia kinh tế, Tư vấn viên độc lập, Giảng viên các khóa Lương 3P, Định mức, BSC-KPI...; kiến trúc sư hệ thống, nhà sáng tạo và chủ sở hữu The Platform C3P.

Chú dẫn: Bài viết đã được chia sẻ rộng rãi tại các cộng đồng facebook.

Cộng đồng: HrShare - Cộng đồng Quản trị Nhân sự Việt Nam
HR Nhân Sự Hồ Chí Minh
Tuyển dụng GIÁM ĐỐC - TRƯỞNG PHÒNG KINH DOANH
TINH HOA QUẢN TRỊ
HR talks