Khi doanh nghiệp bước đến giai đoạn muốn áp dụng hệ thống mục tiêu và kết quả then chốt (OKR) một cách nghiêm túc, câu hỏi quan trọng nhất không còn là viết mục tiêu thế nào hay họp rà soát ra sao. Câu hỏi cốt lõi chuyển thành một tầng khó hơn rất nhiều: làm thế nào để thiết kế được một hệ thống OKR thực sự phù hợp với doanh nghiệp. Đây là chỗ nhiều tổ chức thất bại dù có đủ tài liệu, đủ khóa học và đủ quyết tâm. Họ học được phương pháp, nhưng không chuyển phương pháp đó thành một kiến trúc quản trị tương thích với thực tế của mình. Kết quả là OKR bị áp vào doanh nghiệp như một lớp công cụ rời rạc, thay vì được xây thành một hệ thống sống.
Bản chất của vấn đề nằm ở chỗ OKR không phải một biểu mẫu và cũng không phải một kỹ thuật đơn lẻ. Nó là một hệ thống quản trị. Mà bất kỳ hệ thống quản trị nào muốn tạo ra giá trị đều phải được thiết kế đồng bộ. Đồng bộ về tầng chiến lược, tầng vận hành, tầng con người và tầng đo lường. Nếu một doanh nghiệp chỉ học cách viết Objective và Key Results mà không quan tâm đến cách hệ thống này nối với chiến lược, nối với cấu trúc phòng ban, nối với nhịp vận hành hiện tại, nối với văn hóa quản lý và nối với dữ liệu thực tế, thì toàn bộ việc triển khai sớm muộn cũng sẽ rơi vào hình thức.
Điều làm cho bài toán thiết kế hệ thống OKR trở nên đặc biệt quan trọng là nó quyết định khả năng sống còn của phương pháp trong doanh nghiệp. Một hệ thống được thiết kế tốt sẽ giúp OKR có chỗ đứng trong điều hành, có vai trò trong quyết định, có nhịp trong vận hành và có khả năng trưởng thành theo thời gian. Ngược lại, một hệ thống thiết kế kém sẽ làm OKR hoặc trở nên quá nặng, hoặc quá rỗng, hoặc bị kéo tụt về thành một phiên bản đổi tên của những thứ doanh nghiệp đã từng có. Đây là lý do bài viết này không đi theo hướng ôn lại lý thuyết. Trọng tâm hoàn toàn nằm ở tư duy thiết kế hệ thống.
Bài này vì thế là một bài rất quan trọng trong toàn bộ chuỗi. Nó không chỉ trả lời câu hỏi làm OKR như thế nào, mà trả lời câu hỏi sâu hơn: doanh nghiệp phải xây hệ thống OKR ra sao để phương pháp này không chết yểu, không bị bóp méo và không chỉ tồn tại như một lớp quản trị trang trí. Từ tầng chiến lược, tầng vận hành, tầng con người, tầng đo lường, đến lộ trình triển khai theo giai đoạn và cách nâng cấp hệ thống theo thời gian, tất cả sẽ được đặt trong một logic duy nhất: OKR là bài toán thiết kế hệ thống, và chỉ khi giải được bài toán ấy, doanh nghiệp mới thật sự có cơ hội biến mục tiêu thành năng lực quản trị bền vững.
1. OKR là bài toán thiết kế hệ thống
1.1. OKR không phải công cụ
Sai lầm đầu tiên khiến nhiều doanh nghiệp triển khai OKR thất bại là nhìn nó như một công cụ. Khi đã xem OKR là công cụ, tổ chức sẽ vô thức tiếp cận theo lối rất quen thuộc: tìm mẫu biểu, học vài nguyên tắc viết, chọn phần mềm theo dõi, rồi kỳ vọng rằng sau khi “cài” công cụ vào, hệ thống quản trị sẽ tự tốt lên. Đây là một cách nhìn vừa đơn giản vừa nguy hiểm. Nó làm doanh nghiệp đánh giá thấp bản chất của OKR và bỏ qua tầng quyết định hiệu quả thực sự, đó là kiến trúc hệ thống đứng phía sau.
Một công cụ thường giải quyết một điểm việc tương đối cụ thể. Nó có thể giúp ghi chép, đo lường, trình bày hoặc theo dõi. Nhưng OKR không dừng ở bất kỳ vai trò nào như vậy. Nó tác động lên cách doanh nghiệp chọn ưu tiên, cách các bộ phận liên kết với nhau, cách lãnh đạo điều hành, cách quản lý trung gian tổ chức công việc, cách con người nhận phản hồi và cách tổ chức học qua từng chu kỳ. Một phương pháp chạm đến từng ấy tầng không thể bị xem như một công cụ đơn thuần.
Khi doanh nghiệp tiếp cận OKR như công cụ, một hiện tượng rất thường thấy sẽ xuất hiện. Họ triển khai rất nhanh ở bề mặt nhưng không thay đổi được gì trong chiều sâu. Các cuộc họp vẫn cũ, cách giao việc vẫn cũ, cách đo lường vẫn cũ, văn hóa trách nhiệm vẫn cũ. Chỉ có thêm một bộ ngôn ngữ mới và thêm một vài tài liệu mới. Trong bối cảnh đó, việc OKR không tạo ra giá trị là điều gần như chắc chắn.
Vì vậy, điểm khởi đầu đúng không phải là hỏi “chúng ta dùng công cụ gì cho OKR”, mà phải là “OKR sẽ nằm ở đâu trong hệ điều hành quản trị của doanh nghiệp”. Chỉ khi câu hỏi đó được trả lời, OKR mới thoát khỏi số phận của một phương pháp bị làm cho có và bắt đầu có cơ hội trở thành một năng lực thật.
1.2. Cần thiết kế đồng bộ
Một hệ thống quản trị không thể mạnh nếu nó chỉ được làm tốt ở một vài điểm riêng lẻ. Đây là nguyên tắc rất cơ bản nhưng nhiều doanh nghiệp lại bỏ qua khi triển khai OKR. Họ chăm vào việc thiết kế câu chữ cho mục tiêu, nhưng không thiết kế cơ chế vận hành. Họ nói về sự minh bạch, nhưng không thiết kế cách dữ liệu được chia sẻ. Họ muốn các bộ phận liên kết, nhưng không thiết kế quan hệ giữa mục tiêu cấp công ty, mục tiêu bộ phận và mục tiêu cá nhân. Kết quả là từng phần có vẻ hợp lý, nhưng tổng thể không tạo thành một hệ thống đủ mạnh.
Thiết kế đồng bộ nghĩa là doanh nghiệp phải nhìn OKR như một cấu trúc có nhiều lớp ăn vào nhau. Tầng chiến lược phải rõ thì tầng mục tiêu mới đúng hướng. Tầng vận hành phải đủ nhịp thì mục tiêu mới không bị treo trên giấy. Tầng con người phải đủ mạnh thì đội ngũ mới không cảm thấy OKR là áp lực khô cứng. Tầng đo lường phải đủ tin cậy thì việc ra quyết định mới không quay về cảm tính. Nếu một trong các lớp đó yếu, toàn bộ hệ thống sẽ bị kéo tụt theo.
Điều đáng nói là sự thiếu đồng bộ thường không làm hệ thống đổ ngay. Nó tạo ra loại thất bại chậm. Ban đầu mọi thứ vẫn có vẻ chạy được. Nhưng càng đi sâu, càng nhiều mâu thuẫn xuất hiện. Mục tiêu đúng nhưng vận hành không theo. Dữ liệu có nhưng không ai dùng. Con người hiểu hệ thống nhưng không có động lực bám hệ thống. Những trục trặc này dồn lại và cuối cùng tạo ra cảm giác rằng OKR “không hợp với doanh nghiệp”. Trong khi thực chất, thứ không phù hợp không phải phương pháp, mà là chất lượng thiết kế hệ thống.
Do đó, khi nói đến thiết kế OKR, doanh nghiệp phải chấp nhận một sự thật: không có đường tắt. Muốn OKR mạnh, phải xây đồng bộ. Và xây đồng bộ luôn khó hơn nhiều so với chỉ học kỹ thuật viết mục tiêu.
1.3. Vai trò của hệ thống
Nếu coi OKR là một hệ thống, thì vai trò của chính hệ thống đó là gì. Đây là câu hỏi rất quan trọng, bởi doanh nghiệp chỉ có thể thiết kế đúng khi hiểu rõ hệ thống này cần tạo ra tác dụng gì trong tổ chức. Về bản chất, vai trò của hệ thống OKR không phải chỉ để tạo ra mục tiêu, mà để tạo ra một cơ chế điều hành giúp doanh nghiệp chọn đúng trọng tâm, nối các phần của tổ chức lại với nhau, đo được tiến triển thật và học được từ quá trình thực thi.
Nói cụ thể hơn, hệ thống OKR phải làm được ít nhất bốn việc. Thứ nhất, nó phải giúp doanh nghiệp chuyển chiến lược thành ưu tiên cụ thể. Nếu không làm được điều đó, chiến lược vẫn ở tầng khẩu hiệu. Thứ hai, nó phải giúp tổ chức liên kết giữa các cấp và các bộ phận, để tránh mỗi nơi theo đuổi một logic riêng. Thứ ba, nó phải tạo ra khả năng nhìn thấy tiến triển và lệch pha đủ sớm để điều chỉnh. Thứ tư, nó phải góp phần nâng cấp năng lực tổ chức qua từng chu kỳ, chứ không chỉ tạo ra vài báo cáo mục tiêu đẹp mắt.
Khi hiểu hệ thống theo cách này, doanh nghiệp sẽ thấy ngay một điều: OKR không thể chỉ là chuyện của phòng nhân sự, cũng không thể chỉ là chuyện của lãnh đạo. Nó chạm vào toàn bộ kiến trúc quản trị. Chính vì vai trò rộng như vậy, việc thiết kế hệ thống OKR không thể làm theo kiểu cắt từng mảnh rồi ghép lại sau. Nó phải bắt đầu từ một cái nhìn tổng thể.
Vai trò của hệ thống càng được hiểu rõ, thiết kế càng đúng. Và ngược lại, khi doanh nghiệp không làm rõ vai trò này, họ sẽ rất dễ xây một hệ thống có vẻ chỉn chu nhưng không giải quyết được vấn đề quản trị nào thật sự.
1.4. Tư duy hệ thống
Thiết kế OKR đòi hỏi tư duy hệ thống nhiều hơn bất kỳ thứ gì khác. Tư duy hệ thống nghĩa là gì trong bối cảnh này. Nghĩa là doanh nghiệp không nhìn từng phần của OKR như những khối độc lập, mà nhìn thấy mối quan hệ giữa chúng. Mục tiêu gắn với chiến lược thế nào. Kết quả gắn với hành vi ra sao. Vận hành ảnh hưởng đến dữ liệu thế nào. Văn hóa tác động lên chất lượng phản hồi ra sao. Khi các mối liên hệ này được nhìn thấy, doanh nghiệp mới có cơ hội thiết kế một cấu trúc đủ mạnh.
Thiếu tư duy hệ thống là lý do rất nhiều OKR bị phân mảnh. Có nơi thiết kế mục tiêu rất tốt nhưng không có nhịp vận hành. Có nơi họp rất đều nhưng mục tiêu lại không nối với chiến lược. Có nơi dữ liệu rất nhiều nhưng không giúp ra quyết định. Tất cả những lệch pha đó đều xuất phát từ việc doanh nghiệp chỉ làm từng phần cho đúng, chứ không xây được logic cho toàn bộ hệ thống.
Một người có tư duy hệ thống khi nhìn vào OKR sẽ không hỏi “mục này viết đúng chưa” đầu tiên. Họ sẽ hỏi “mục này đang nằm ở đâu trong toàn bộ kiến trúc”. Đây là một khác biệt rất lớn. Nó chuyển việc thiết kế OKR từ thao tác kỹ thuật sang năng lực kiến trúc quản trị. Và đó cũng là lý do vì sao cùng một phương pháp, có tổ chức làm ra giá trị rất lớn, có tổ chức lại chỉ tạo thêm thủ tục.
Nếu doanh nghiệp muốn đi đến mức trưởng thành với OKR, tư duy hệ thống là năng lực bắt buộc phải có. Không có nó, mọi cố gắng thường chỉ dừng ở cải tiến cục bộ. Có nó, doanh nghiệp bắt đầu biết cách làm cho các lớp chiến lược, vận hành, con người và dữ liệu thật sự ăn vào nhau.
2. Kiến trúc hệ thống OKR
2.1. Tầng chiến lược
Tầng chiến lược là nền cao nhất trong kiến trúc hệ thống OKR. Nếu tầng này mờ, toàn bộ các tầng bên dưới sẽ rất dễ vận hành trong trạng thái đúng về kỹ thuật nhưng sai về hướng. Đây là lý do nhiều doanh nghiệp học cách viết OKR rất nhanh, nhưng khi áp vào thực tế lại thấy mục tiêu rời rạc, thiếu trọng tâm hoặc không tạo được tác động chiến lược. Vấn đề không nằm ở phần viết. Vấn đề nằm ở chỗ tầng chiến lược chưa được làm rõ đủ để dẫn dắt hệ thống.
Trong thiết kế hệ thống, tầng chiến lược có một vai trò rất cụ thể: xác định điều gì thật sự quan trọng với doanh nghiệp trong giai đoạn hiện tại. Không phải tất cả điều tốt đều trở thành trọng tâm của OKR. Chỉ những điều tạo ra đòn bẩy lớn cho định hướng phát triển mới nên đi xuống các tầng mục tiêu. Nếu chiến lược chưa rõ, doanh nghiệp sẽ rất dễ biến OKR thành nơi chứa mọi mong muốn, mọi vấn đề và mọi sáng kiến. Khi đó, hệ thống vừa nặng vừa loãng.
Điều đáng lưu ý là tầng chiến lược không có nghĩa chỉ là vài câu khẩu hiệu từ cấp cao nhất. Nó phải đủ rõ để trả lời được ba câu hỏi: doanh nghiệp đang muốn đi đâu, vấn đề lớn nhất đang cản đường là gì, và điều gì cần thay đổi để bức tranh dịch chuyển thật. Nếu tầng chiến lược chưa trả lời được ba câu đó, bất kỳ bộ OKR nào bên dưới cũng chỉ là cố gắng điền khoảng trống.
Một hệ thống OKR trưởng thành luôn bắt đầu từ tầng chiến lược đủ rõ, đủ cô đọng và đủ có sức dẫn. Vì chỉ khi tầng chiến lược vững, các tầng sau mới có thể xây đúng và giữ đúng logic trong quá trình vận hành.
2.2. Tầng vận hành
Nếu tầng chiến lược là nơi trả lời “đi đâu”, thì tầng vận hành là nơi trả lời “làm cho hướng đi đó sống trong doanh nghiệp bằng cách nào”. Rất nhiều hệ thống OKR thất bại vì có chiến lược và mục tiêu khá tốt, nhưng không thiết kế được tầng vận hành. Kết quả là mục tiêu vẫn tồn tại, nhưng không có nhịp để đi vào công việc hằng ngày, không có cơ chế để được nhắc lại, không có không gian để được soi chiếu bằng thực tế.
Tầng vận hành trong kiến trúc OKR bao gồm cách doanh nghiệp tổ chức chu kỳ, cách tạo nhịp, cách đưa mục tiêu vào các cuộc họp quản trị, cách gắn nó với phân bổ nguồn lực và cách duy trì sự chú ý của cả hệ thống. Điều này rất quan trọng, vì một mục tiêu dù đúng đến đâu cũng sẽ nhanh chóng bị công việc phát sinh nuốt chửng nếu không được đặt trong nhịp vận hành rõ ràng.
Một sai lầm thường gặp là doanh nghiệp nghĩ tầng vận hành chỉ là “thực hiện theo kế hoạch”. Thực ra, tầng vận hành rộng hơn rất nhiều. Nó là môi trường sống của OKR. Nếu thiết kế tốt, mục tiêu sẽ hiện diện đều trong tổ chức. Nếu thiết kế kém, mục tiêu sẽ chỉ sống mạnh trong vài ngày đầu rồi mất hút.
Do đó, khi thiết kế hệ thống OKR, doanh nghiệp phải coi tầng vận hành như phần không thể tách rời. Không thể có chuyện xây chiến lược và mục tiêu trước, rồi đến vận hành tính sau. Bởi lẽ, trong quản trị, cái gì không có chỗ trong vận hành thì sớm muộn cũng sẽ bị đẩy ra ngoài.
2.3. Tầng con người
Một trong những sai lầm lớn nhất khi thiết kế OKR là coi hệ thống này như một cấu trúc thuần logic. Trong thực tế, bất kỳ hệ thống mục tiêu nào cũng đi qua con người, vận hành qua con người và thành công hoặc thất bại chủ yếu do con người. Vì vậy, tầng con người phải được xem như một lớp kiến trúc độc lập, không phải phần phụ.
Tầng con người trả lời những câu hỏi rất thực tế: đội ngũ có hiểu mục tiêu không, có nhìn thấy vai trò của mình trong hệ thống không, có được đối thoại, phản hồi và ghi nhận đủ để duy trì động lực không, các quản lý trung gian có đủ năng lực dẫn dắt bằng OKR không. Nếu không thiết kế lớp này, doanh nghiệp sẽ luôn rơi vào trạng thái “mục tiêu đúng nhưng con người không chạy theo”.
Điều đáng lưu ý là tầng con người không thể được xử lý bằng vài buổi truyền thông nội bộ. Nó phải đi vào cơ chế thực sự. Từ cách lãnh đạo nói về mục tiêu, cách quản lý trao đổi với đội ngũ, cách phản hồi diễn ra, đến cách doanh nghiệp công nhận nỗ lực và tiến bộ. Đây là toàn bộ không gian mà con người trải nghiệm hệ thống OKR.
Một kiến trúc OKR tốt không chỉ tạo mục tiêu rõ mà còn tạo môi trường tâm lý và quan hệ đủ khỏe để con người bám vào mục tiêu đó trong thời gian dài. Nếu bỏ qua tầng con người, hệ thống sẽ luôn có nguy cơ trở thành đúng về mặt cấu trúc nhưng thất bại về mặt hành vi.
2.4. Tầng đo lường
Tầng đo lường là nơi chuyển hệ thống OKR từ trạng thái định hướng sang trạng thái kiểm chứng. Không có tầng này, mục tiêu sẽ rất dễ bị biến thành khẩu hiệu. Nhưng nếu chỉ có tầng đo lường mà thiếu các tầng còn lại, hệ thống sẽ bị kéo về kiểu quản trị thuần số liệu. Vì vậy, tầng đo lường phải được thiết kế như một phần của kiến trúc, không phải như đích cuối cùng của hệ thống.
Tầng đo lường trong OKR không chỉ là chuyện chọn chỉ số. Nó là chuyện tạo ra một hệ quy chiếu giúp doanh nghiệp biết mình đang dịch chuyển thật hay chỉ đang bận rộn hơn. Điều đó có nghĩa dữ liệu phải đủ đúng, đủ liên quan, đủ sớm và đủ dễ dùng trong ra quyết định. Nếu số liệu có nhưng không phản ánh giá trị thật, hoặc phản ánh quá muộn, hoặc quá rời rạc để kết nối với mục tiêu, thì tầng đo lường vẫn bị xem là yếu.
Nhiều doanh nghiệp sai ở chỗ họ thiết kế đo lường như một bài toán kỹ thuật độc lập. Trong khi thực ra, tầng đo lường phải nối với chiến lược, vận hành và con người. Đo cái gì phải quay về câu hỏi chiến lược. Đo như thế nào phải hợp với nhịp vận hành. Đo ra sao để không tạo tâm lý phòng thủ lại là câu hỏi của tầng con người. Chỉ khi nhìn như vậy, doanh nghiệp mới tránh được việc xây một hệ thống rất nhiều số nhưng rất ít giá trị quản trị.
3. Thiết kế OKR trong doanh nghiệp
3.1. Thiết kế từ trên xuống
Một hệ thống OKR muốn mạnh phải có trục từ trên xuống đủ rõ. Điều này không có nghĩa mọi thứ đều phải áp đặt cơ học từ lãnh đạo, mà có nghĩa doanh nghiệp cần một định hướng đủ rõ ở cấp công ty để toàn bộ phần bên dưới có điểm tựa thiết kế. Nếu bỏ qua nguyên tắc này, rất dễ xảy ra tình trạng các bộ phận tự thiết kế mục tiêu theo vấn đề riêng của mình và kết quả là không tạo thành một hệ thống thống nhất.
Thiết kế từ trên xuống bắt đầu từ việc lãnh đạo làm rõ những ưu tiên chiến lược thật sự của doanh nghiệp. Đây là lớp mục tiêu mang tính dẫn dắt. Nó không chỉ nói doanh nghiệp muốn gì, mà còn nói doanh nghiệp sẵn sàng ưu tiên điều gì hơn trong giai đoạn hiện tại. Chính lớp này tạo ra trục định hướng để các phòng ban và đội nhóm không bị trôi vào việc tối ưu cục bộ.
Điểm hay của thiết kế từ trên xuống là nó giúp doanh nghiệp giảm rất nhiều hỗn loạn trong giai đoạn đầu. Mọi người biết bức tranh lớn hơn là gì. Các bộ phận hiểu đâu là trọng tâm cấp công ty. Từ đó, việc thiết kế mục tiêu ở tầng dưới không bắt đầu từ khoảng trống, mà bắt đầu từ một logic đã rõ. Đây là điều cực kỳ quan trọng nếu doanh nghiệp muốn tránh việc mỗi nơi một bộ OKR không ăn vào nhau.
Tuy nhiên, thiết kế từ trên xuống chỉ tạo ra sức mạnh khi cấp trên thật sự làm rõ chiến lược, chứ không dừng ở khẩu hiệu. Nếu tầng trên mơ hồ, thì việc đi xuống càng sâu càng sinh thêm nhiễu. Vì vậy, cách làm này đòi hỏi chất lượng tư duy rất cao từ cấp lãnh đạo.
3.2. Kết hợp từ dưới lên
Nếu chỉ có thiết kế từ trên xuống, hệ thống OKR sẽ dễ đúng về định hướng nhưng thiếu sức sống thực tế. Đây là lý do doanh nghiệp cần bổ sung chiều từ dưới lên. Bởi vì đội ngũ ở các tầng thực thi là nơi hiểu rõ nhất công việc, ma sát vận hành, giới hạn nguồn lực và các điều kiện thực tế. Nếu tiếng nói này không được đưa vào quá trình thiết kế, OKR sẽ rất dễ trở thành một cấu trúc đẹp nhưng xa mặt đất.
Kết hợp từ dưới lên không phải là để mỗi bộ phận tự đặt mục tiêu theo ý mình. Nó là để phản hồi thực tế đi ngược lên hệ thống, giúp tinh chỉnh chất lượng mục tiêu, chỉ số và cách phân vai. Trong nhiều doanh nghiệp, khoảng cách giữa lý thuyết chiến lược và vận hành thực tế rất lớn. Chính dòng thông tin từ dưới lên sẽ giúp lấp khoảng cách đó.
Điều này còn đặc biệt quan trọng ở cấp độ cam kết. Khi đội ngũ được tham gia vào quá trình thiết kế hoặc ít nhất được góp tiếng nói vào cách chuyển mục tiêu chiến lược thành mục tiêu bộ phận và cá nhân, họ sẽ có cảm giác sở hữu cao hơn nhiều. Một hệ thống mà con người thấy mình có tiếng nói luôn bền hơn một hệ thống chỉ được ban hành xuống.
Vì vậy, thiết kế hệ thống OKR tốt luôn là sự kết hợp giữa hai lực. Trên xuống để tạo trục. Dưới lên để tạo tính thật. Chỉ khi hai lực này gặp nhau đúng cách, hệ thống mới vừa có định hướng chiến lược vừa đủ khả năng vận hành.
3.3. Đồng bộ hệ thống
Thiết kế hệ thống OKR không phải là gom mục tiêu của các cấp lại với nhau. Nó là làm cho các tầng, các bộ phận và các cơ chế vận hành thật sự đồng bộ. Đồng bộ ở đây không có nghĩa là giống nhau, mà là ăn khớp với nhau trong cùng một logic. Đây là điểm khác biệt rất lớn giữa một tập hợp các OKR riêng lẻ và một hệ thống OKR đúng nghĩa.
Muốn đồng bộ, doanh nghiệp phải làm rõ quan hệ giữa mục tiêu công ty, mục tiêu bộ phận, mục tiêu cá nhân và cả các cơ chế theo dõi, phản hồi, phân bổ nguồn lực. Nếu chỉ mục tiêu ăn khớp mà vận hành không ăn khớp, hệ thống vẫn lệch. Nếu mục tiêu và vận hành ăn khớp nhưng dữ liệu không ăn khớp, hệ thống vẫn mù. Nếu tất cả đó ăn khớp nhưng con người không thấy liên quan đến mình, hệ thống vẫn yếu.
Điểm khó của đồng bộ hệ thống là nó đòi hỏi doanh nghiệp nhìn OKR như kiến trúc tổng thể, không phải tập hợp các phần đúng riêng lẻ. Nhiều nơi thất bại vì từng phần nhìn đâu cũng hợp lý. Nhưng khi ghép vào nhau thì không tạo được dòng chảy chung. Và khi dòng chảy không có, mọi cố gắng lại trở thành lực kéo ngược lẫn nhau.
Đồng bộ tốt là khi doanh nghiệp thấy rõ: chiến lược nói gì, mục tiêu phản ánh gì, vận hành bám gì, dữ liệu đo gì, con người được dẫn dắt ra sao. Khi đó, hệ thống bắt đầu mạnh lên như một chỉnh thể.
3.4. Tránh cát cứ phòng ban
Một trong những nguy cơ lớn nhất khi thiết kế hệ thống OKR là để các phòng ban vận hành như những “lãnh địa riêng”, tức tình trạng cát cứ phòng ban. Khi đó, mỗi nơi có thể đều có mục tiêu, đều có chỉ số, đều có nỗ lực, nhưng tổng thể doanh nghiệp không mạnh lên tương ứng vì các bộ phận không thực sự được thiết kế để kéo cùng một hướng.
Tránh cát cứ phòng ban không chỉ là chuyện “phối hợp tốt hơn”. Nó là một quyết định thiết kế. Doanh nghiệp phải tạo ra những liên kết ngang giữa các mục tiêu, chỉ ra chỗ nào cần phụ thuộc lẫn nhau, chỗ nào có nguy cơ xung đột ưu tiên, chỗ nào phải cùng chịu trách nhiệm cho một kết quả chung. Nếu thiếu lớp thiết kế đó, các bộ phận sẽ tự động quay về tối ưu cục bộ, vì đó là cách tự nhiên nhất.
Điều đáng nói là cát cứ phòng ban thường không bộc lộ bằng xung đột lớn ngay lập tức. Nó bộc lộ qua những ma sát nhỏ, những lệch pha trong ưu tiên, những vùng trách nhiệm mờ và những cuộc họp phải điều phối quá nhiều. Khi các biểu hiện đó lặp lại, chi phí điều hành tăng lên rất mạnh. Đây là cái giá của thiết kế hệ thống kém.
Vì vậy, tránh cát cứ phòng ban không phải là chuyện mềm về văn hóa. Nó là chuyện cứng về kiến trúc OKR. Một hệ thống thiết kế tốt phải làm cho các bộ phận không có lựa chọn nào khác ngoài việc nhìn thấy nhau trong cùng một logic mục tiêu.
4. Xây dựng hệ thống vận hành
4.1. Chu kỳ
Một hệ thống OKR không thể sống nếu không có chu kỳ vận hành rõ. Chu kỳ ở đây không phải chỉ là khoảng thời gian ba tháng hay sáu tháng theo lịch, mà là cấu trúc thời gian giúp mục tiêu có nhịp sống. Chính nhịp này mới biến mục tiêu từ thứ được viết ra một lần thành thứ được theo đuổi, được nhìn lại và được chuyển hóa thành bài học cho vòng tiếp theo.
Doanh nghiệp thường thất bại với OKR không phải vì không có mục tiêu, mà vì không tạo được chu kỳ đủ rõ để mục tiêu đi hết một vòng đời. Có nơi thiết lập rất tốt nhưng không bước được sang vận hành. Có nơi vận hành khá quyết liệt nhưng lại bỏ qua giai đoạn đánh giá và học. Có nơi cứ thay mục tiêu giữa chừng vì thiếu ranh giới thời gian. Tất cả đều là dấu hiệu của một chu kỳ yếu.
Thiết kế chu kỳ đúng giúp doanh nghiệp biết khi nào cần tập trung xác định ưu tiên, khi nào dồn lực thực thi, khi nào nhìn lại tiến độ và khi nào kết thúc để học. Không có chu kỳ, mọi thứ rất dễ bị hòa tan trong công việc hằng ngày. Có chu kỳ, mục tiêu mới có cơ hội trở thành một phần của quản trị chứ không chỉ là một ý định tốt.
4.2. Kỷ luật
Nếu chu kỳ tạo ra khung thời gian, thì kỷ luật tạo ra sức nặng cho khung đó. Rất nhiều doanh nghiệp có chu kỳ trên giấy nhưng không có kỷ luật trong vận hành, nên OKR nhanh chóng mất nhiệt sau giai đoạn đầu. Kỷ luật ở đây không phải sự cứng nhắc máy móc. Nó là khả năng bảo vệ mục tiêu trước sức ép của những việc cấp bách nhưng ít quan trọng hơn.
Một hệ thống không có kỷ luật sẽ luôn bị kéo về phản ứng tình huống. Cuộc họp bị dời vì bận. Dữ liệu cập nhật chậm vì chưa kịp tổng hợp. Mục tiêu không được nhắc lại vì có quá nhiều việc phát sinh. Từng chuyện riêng lẻ có vẻ hợp lý, nhưng cộng dồn lại sẽ làm cho OKR mất chỗ đứng trong vận hành. Và khi hệ thống không còn chỗ đứng, toàn bộ giá trị của nó biến mất.
Thiết kế kỷ luật không có nghĩa là ép tổ chức bằng sự nghiêm khắc đơn thuần. Nó là thiết kế những nhịp, chuẩn và kỳ vọng đủ rõ để mục tiêu không bị trôi. Khi làm tốt, kỷ luật không làm hệ thống nặng hơn. Nó làm hệ thống bớt phụ thuộc vào cảm hứng và bớt lệ thuộc vào việc phải nhắc nhau liên tục.
4.3. Minh bạch
Minh bạch là một cấu phần vận hành rất quan trọng của hệ thống OKR. Nếu mục tiêu không được công khai đủ, tiến độ không được nhìn đủ thật và dữ liệu không được chia sẻ đủ rõ, hệ thống sẽ rơi vào trạng thái nửa kín nửa hở. Khi đó, các bộ phận không hiểu nhau, lãnh đạo không thấy toàn cảnh, đội ngũ không biết vai trò của mình đang tác động tới đâu. Đây là môi trường mà OKR rất khó sống khỏe.
Minh bạch trong vận hành không có nghĩa là công khai mọi thứ một cách tràn lan. Điều cần là công khai đủ để các mối liên kết trong hệ thống có thể hoạt động. Mọi người cần biết mục tiêu cấp trên, hiểu các phụ thuộc chéo, nhìn thấy tiến độ theo logic chung và có cùng một cơ sở dữ liệu để đối thoại. Nếu thiếu lớp này, hệ thống sẽ luôn phải bù bằng rất nhiều cuộc họp giải thích và điều phối.
Điều đặc biệt của minh bạch là nó không chỉ hỗ trợ quản trị. Nó còn tạo niềm tin. Khi mọi thứ đủ rõ, đội ngũ bớt suy diễn, quản lý bớt phòng thủ và tổ chức dễ hơn trong việc nói thật về tiến độ. Đây là nền rất quan trọng nếu doanh nghiệp muốn dùng OKR để tạo thay đổi thật, chứ không chỉ tạo ra một phiên bản quản trị đẹp trên giấy.
4.4. Trách nhiệm
Một hệ thống vận hành tốt phải làm rõ trách nhiệm. Đây là điều rất cơ bản nhưng thường bị doanh nghiệp xử lý không tới nơi khi làm OKR. Có nơi ai cũng “liên quan”, nhưng không ai thật sự chịu trách nhiệm giữ nhịp. Có nơi người phụ trách mục tiêu được chỉ định, nhưng quyền hạn và kỳ vọng lại không rõ. Có nơi trách nhiệm chỉ dừng ở việc cập nhật số liệu, không đi xa tới việc giải quyết điểm nghẽn.
Thiết kế trách nhiệm trong OKR phải làm rõ ít nhất ba lớp. Ai sở hữu mục tiêu. Ai có trách nhiệm hỗ trợ. Ai có trách nhiệm can thiệp khi có lệch pha lớn. Nếu ba lớp này không rõ, hệ thống sẽ rất dễ trôi vào vùng mờ, nơi mọi người đều nghĩ ai đó khác sẽ xử lý. Đây là một dạng lãng phí rất phổ biến và rất khó chịu trong thực tế triển khai.
Trách nhiệm càng rõ, hệ thống càng ít phải dựa vào thúc ép tình huống. Khi ai cũng biết mình đang giữ phần nào của cấu trúc, nhịp vận hành sẽ bền hơn rất nhiều. Vì vậy, trong thiết kế hệ thống OKR, trách nhiệm không phải phụ lục. Nó là phần khớp nối giữa kiến trúc và hành động.
5. Triển khai OKR theo giai đoạn
5.1. Giai đoạn thử nghiệm
Rất ít doanh nghiệp có thể triển khai OKR thành công trên diện rộng ngay từ ngày đầu. Đây là lý do giai đoạn thử nghiệm cực kỳ quan trọng trong thiết kế hệ thống. Thử nghiệm không phải để làm hời hợt, mà để tạo một không gian đủ nhỏ, đủ an toàn và đủ thực tế để tổ chức học cách vận hành phương pháp trong bối cảnh của chính mình.
Trong giai đoạn này, điều cần nhất không phải là phủ toàn hệ thống, mà là kiểm tra những giả định thiết kế cốt lõi. Mục tiêu có được hiểu đúng không. Nhịp vận hành có phù hợp không. Dữ liệu có đủ dùng không. Đội ngũ quản lý có giữ được hệ thống không. Nếu doanh nghiệp nhảy thẳng vào toàn bộ tổ chức khi chưa trả lời được những câu hỏi này, nguy cơ rất lớn là họ sẽ nhân rộng cả lỗi thiết kế chứ không chỉ nhân rộng phương pháp.
Thử nghiệm tốt còn giúp giảm kháng cự tâm lý. Khi tổ chức thấy một phạm vi nhỏ làm được, niềm tin vào hệ thống tăng lên. Điều này quan trọng hơn rất nhiều so với việc công bố thật lớn nhưng không tạo được kết quả thực. Nói cách khác, thử nghiệm là giai đoạn doanh nghiệp xây năng lực thực sự, không phải giai đoạn làm thương hiệu nội bộ cho OKR.
5.2. Giai đoạn mở rộng
Sau khi thử nghiệm tạo ra những tín hiệu đủ tốt, doanh nghiệp mới nên bước sang giai đoạn mở rộng. Mở rộng không chỉ là thêm nhiều phòng ban vào hệ thống. Nó là quá trình đưa kiến trúc OKR đi qua nhiều lớp phức tạp hơn của tổ chức mà vẫn giữ được logic cốt lõi. Đây là giai đoạn rất dễ tạo cảm giác thành công giả, vì chỉ cần số lượng người tham gia tăng lên là doanh nghiệp đã thấy mình “triển khai mạnh”. Nhưng nếu chất lượng hệ thống không theo kịp, việc mở rộng sẽ chỉ phóng to những vấn đề sẵn có.
Điều cần nhất ở giai đoạn này là khả năng chuẩn hóa đủ để nhân rộng nhưng vẫn linh hoạt đủ để thích nghi. Nếu chuẩn hóa quá yếu, mỗi nơi sẽ hiểu OKR theo một kiểu. Nếu chuẩn hóa quá cứng, tổ chức sẽ tạo ra phản ứng chống lại hệ thống. Vì vậy, mở rộng là bài toán cân bằng giữa khung chung và đặc thù của từng đơn vị.
Đây cũng là giai đoạn mà vai trò của quản lý trung gian tăng lên rất mạnh. Bởi vì khi phạm vi lớn hơn, lãnh đạo cấp cao không thể giữ toàn bộ hệ thống bằng sự hiện diện trực tiếp nữa. Nếu doanh nghiệp không chuẩn bị đủ năng lực ở tầng này, mở rộng sẽ rất dễ dẫn đến loãng, gãy nhịp và mất chất lượng vận hành.
5.3. Giai đoạn tối ưu
Khi OKR đã được mở rộng tới một mức nhất định, doanh nghiệp sẽ bước sang giai đoạn tối ưu. Đây là lúc trọng tâm không còn là “có mặt ở bao nhiêu nơi”, mà là “chất lượng hệ thống đang ở mức nào”. Nhiều tổ chức sai ở chỗ sau khi mở rộng xong thì nghĩ rằng công việc lớn nhất đã hoàn thành. Thực ra, giai đoạn tối ưu mới là lúc hệ thống bắt đầu được mài sắc.
Tối ưu trong bối cảnh OKR có thể xảy ra ở nhiều lớp. Tối ưu cách phân tầng mục tiêu. Tối ưu nhịp vận hành. Tối ưu cách sử dụng dữ liệu. Tối ưu vai trò của quản lý. Tối ưu mức độ minh bạch. Và rất quan trọng, tối ưu trải nghiệm của con người với hệ thống để giảm cảm giác nặng nề mà vẫn giữ được kỷ luật.
Đây là giai đoạn đòi hỏi doanh nghiệp phải bớt hưng phấn với hình thức và quay về với chất lượng. Không phải thêm nhiều hơn, mà là làm sắc hơn. Không phải họp nhiều hơn, mà là họp đúng hơn. Không phải lấy nhiều dữ liệu hơn, mà là lấy đúng dữ liệu hơn. Một tổ chức biết tối ưu hệ thống sẽ dần biến OKR từ một phương pháp triển khai thành một năng lực quản trị ổn định.
5.4. Giai đoạn trưởng thành
Giai đoạn trưởng thành là lúc OKR không còn được cảm nhận như một chương trình riêng, mà đã hòa vào cách doanh nghiệp vận hành. Đây là trạng thái mà nhiều tổ chức muốn đạt tới nhưng rất ít nơi kiên trì đủ lâu để có được. Trưởng thành không có nghĩa là hệ thống không còn vấn đề. Nó có nghĩa là doanh nghiệp đã có đủ năng lực để nhìn ra vấn đề, chỉnh lại hệ thống và tiếp tục tiến lên mà không cần quay về trạng thái làm lại từ đầu.
Ở giai đoạn này, OKR thường không còn cần được “truyền thông rầm rộ” nữa. Nó sống trong cách người ta nói về mục tiêu, cách các bộ phận liên kết, cách dữ liệu được dùng để ra quyết định và cách đội ngũ nhìn mối quan hệ giữa công việc hằng ngày với định hướng chiến lược. Nói cách khác, hệ thống đã đi từ mức phương pháp sang mức văn hóa vận hành.
Điều làm cho giai đoạn trưởng thành trở nên đáng giá không chỉ là hiệu suất hiện tại, mà là khả năng mở rộng tiếp trong tương lai. Một doanh nghiệp có hệ thống OKR trưởng thành sẽ dễ dàng hơn nhiều khi đối mặt với tăng trưởng quy mô, thay đổi cấu trúc hoặc thay đổi chiến lược, vì họ đã có một “bộ xương” quản trị đủ chắc để tái cấu trúc mà không mất phương hướng.
6. Nâng cấp và phát triển hệ thống
6.1. Cải tiến liên tục
Không có hệ thống OKR nào được thiết kế hoàn hảo ngay từ đầu. Đây là một thực tế doanh nghiệp phải chấp nhận nếu muốn đi đường dài với phương pháp này. Chính vì vậy, cải tiến liên tục không phải là lựa chọn, mà là bản chất của việc phát triển hệ thống. Hệ thống mạnh không phải là hệ thống không có lỗi. Nó là hệ thống có khả năng phát hiện lỗi và nâng cấp qua từng chu kỳ.
Cải tiến liên tục trong OKR đòi hỏi doanh nghiệp có thái độ rất đúng với hệ thống. Không thần thánh hóa những gì đã thiết kế. Không xem cấu trúc hiện tại là bất biến. Đồng thời cũng không thay đổi tùy hứng theo cảm giác. Cải tiến phải dựa trên quan sát thực, dữ liệu thực và những bài học thật đã lộ ra trong vận hành. Chỉ như vậy, mỗi thay đổi mới làm hệ thống mạnh hơn thay vì làm hệ thống rối hơn.
Một tổ chức có tinh thần cải tiến liên tục sẽ coi mỗi chu kỳ như một lần học. Họ nhìn vào chất lượng mục tiêu, chất lượng phối hợp, chất lượng dữ liệu và chất lượng của vai trò quản lý. Nhờ vậy, hệ thống không bị đóng băng. Nó tiến hóa cùng doanh nghiệp, thay vì bị doanh nghiệp bỏ lại như nhiều phương pháp quản trị khác từng bị.
6.2. Học từ dữ liệu
Muốn cải tiến liên tục có chất lượng, doanh nghiệp phải học từ dữ liệu. Dữ liệu ở đây không chỉ là số đạt hay chưa đạt. Nó là toàn bộ các tín hiệu cho thấy hệ thống đang khỏe hay yếu ở đâu. Ví dụ mục tiêu này luôn bị hiểu sai, bộ phận kia luôn cập nhật chậm, chỉ số nọ không thật sự phản ánh giá trị, hay chu kỳ hiện tại khiến một tầng quản lý bị quá tải. Tất cả những điều đó đều là dữ liệu, nếu doanh nghiệp biết nhìn đúng.
Vấn đề của nhiều tổ chức là họ có dữ liệu nhưng không học được từ dữ liệu. Họ xem dữ liệu như công cụ báo cáo, không phải công cụ chẩn đoán hệ thống. Vì vậy, lỗi lặp đi lặp lại qua nhiều chu kỳ mà không ai thật sự sửa. Trong thiết kế hệ thống OKR, học từ dữ liệu là năng lực rất quan trọng vì nó biến trải nghiệm vận hành thành tri thức nâng cấp.
Doanh nghiệp càng trưởng thành với OKR thì càng không chỉ nhìn dữ liệu để biết kết quả, mà còn dùng dữ liệu để hiểu cấu trúc nào đang mạnh, cấu trúc nào đang yếu. Chính cách nhìn này mới giúp hệ thống không ngừng tiến hóa.
6.3. Nâng cấp quản trị
Giá trị sâu nhất của thiết kế hệ thống OKR không nằm ở chỗ doanh nghiệp có thêm một phương pháp mục tiêu. Nó nằm ở chỗ toàn bộ năng lực quản trị được nâng lên qua quá trình xây và vận hành hệ thống đó. Đây là điểm rất quan trọng. Một doanh nghiệp đi đúng với OKR qua đủ nhiều chu kỳ sẽ không chỉ có mục tiêu rõ hơn. Họ sẽ ra quyết định tốt hơn, phối hợp tốt hơn, nhìn dữ liệu tốt hơn và phát triển quản lý trung gian tốt hơn.
Nói cách khác, OKR là con đường nâng cấp quản trị nếu doanh nghiệp nhìn nó đúng như một hệ thống. Mỗi lần tổ chức sửa được một lỗi trong alignment, họ mạnh hơn về cấu trúc. Mỗi lần cải thiện được chất lượng phản hồi, họ mạnh hơn về quản trị con người. Mỗi lần dùng dữ liệu đúng hơn, họ mạnh hơn về điều hành. Đây là hiệu ứng tích lũy rất lớn mà những doanh nghiệp chỉ nhìn OKR như công cụ sẽ không bao giờ chạm tới.
Vì vậy, nâng cấp hệ thống OKR thực chất cũng chính là nâng cấp năng lực quản trị tổng thể của doanh nghiệp. Và đó mới là phần giá trị lớn nhất nếu đi đường dài.
6.4. Mở rộng quy mô
Cuối cùng, một hệ thống OKR tốt phải có khả năng mở rộng quy mô. Mở rộng ở đây không chỉ là thêm nhiều phòng ban hay nhiều người tham gia. Nó là khả năng đem cùng một logic quản trị đi qua các giai đoạn phát triển lớn hơn mà không bị gãy. Đây là bài kiểm tra rất thật của chất lượng thiết kế hệ thống.
Một hệ thống thiết kế yếu thường chỉ chạy được khi còn nhỏ và còn dựa nhiều vào vài cá nhân chủ chốt. Khi doanh nghiệp lớn hơn, hệ thống bắt đầu lộ điểm yếu: thông tin không lên đủ nhanh, mục tiêu không xuống đủ rõ, quản lý trung gian không giữ được nhịp, các bộ phận trở lại cát cứ. Ngược lại, hệ thống thiết kế tốt sẽ có khả năng mở rộng dần mà vẫn giữ được trục chiến lược, nhịp vận hành và tính liên kết.
Điều đó chỉ có được nếu ngay từ đầu doanh nghiệp đã thiết kế OKR như một kiến trúc có thể lớn lên cùng mình, chứ không phải như một giải pháp tình huống cho hiện tại. Đây là chỗ bài toán system design thể hiện giá trị rõ nhất. Thiết kế tốt không chỉ để giải vấn đề hôm nay. Nó để bảo đảm doanh nghiệp vẫn có nền quản trị đủ khỏe cho ngày mai.
7. Kết luận
Thiết kế hệ thống OKR trong doanh nghiệp là một bài toán kiến trúc quản trị, không phải một bài toán công cụ. Điều này cần được nói thật rõ, bởi rất nhiều thất bại khi triển khai OKR không đến từ việc doanh nghiệp không đủ quyết tâm, mà đến từ việc họ tiếp cận phương pháp này quá hẹp. Họ học cách viết, học cách họp, học cách theo dõi, nhưng không xây được một hệ thống đủ đồng bộ để mọi phần thật sự ăn vào nhau. Khi đó, OKR rất dễ trở thành một lớp hình thức mới chồng lên hệ thống cũ.
Một hệ thống OKR mạnh phải được thiết kế từ tầng chiến lược, đi qua tầng vận hành, tầng con người và tầng đo lường. Nó phải biết cách kết hợp lực từ trên xuống và từ dưới lên. Nó phải tránh được tình trạng cát cứ phòng ban, phải xây được nhịp chu kỳ, kỷ luật, minh bạch và trách nhiệm. Quan trọng hơn, nó phải được triển khai theo giai đoạn, biết thử nghiệm trước khi mở rộng, biết tối ưu trước khi trưởng thành, và biết học từ dữ liệu để tự nâng cấp liên tục.
Nếu phải chốt bài này bằng một câu duy nhất, tôi sẽ nói thế này: OKR không thành công vì doanh nghiệp có mục tiêu hay hơn, mà thành công vì doanh nghiệp thiết kế được một hệ thống đủ mạnh để mục tiêu có thể sống, có thể vận hành, có thể lớn lên và có thể mở rộng theo cùng nhịp phát triển của tổ chức. Và đó mới là đích đến thật sự của system design trong OKR.