"TÁI CƠ CẤU TỔ CHỨC" HAY "CHUYỂN ĐỔI TỔ CHỨC" và NHỮNG CÂU CHUYỆN HOANG ĐƯỜNG
(Dành cho người đọc chậm)
Tôi đã nói nhiều lần về những ngôn từ đao to búa lớn dân ta sính dùng mà không mấy ai hiểu ý nghĩa nội hàm của nó, hết CMCN 4.0 đến digital transformation. "Các doanh nhân vô đạo đức' và "các nhà khoa học nửa mùa" tha hồ đi khắp nơi chém gió, làm tiền trên sự thiếu hiểu biết của các tổ chức, doanh nghiệp nào bập vào làm thật thì đa số là fail đau (lý do tôi đã nói trong mấy bài trước). Có một món word-salads nữa mà dân tình cũng sính nói đến và nhiều nơi đã làm, đã đau đớn bầm dập là: "Tái cơ cấu tổ chức" và "Chuyển đổi tổ chức".
Hôm nọ tôi liên hệ với Dr Cherry Vũ, chuyên gia quốc tế về doanh nghiệp linh hoạt về vụ này, ẻm bảo: Nhiều doanh nghiệp lớn ở Việt Nam chi rất nhiều tiền vào tái cấu trúc và chuyển đổi doanh nghiệp nhưng chẳng đi tới đâu. Có doanh nghiệp rất lớn thuê công ty tư vấn để giúp. Họ dàn hàng ngang cùng lúc nhiều dự án chuyển đổi từ leadership mindset, hệ thống tiền lương, KPIs, Balanced-scorecard, OKRs… sau vài năm chả đâu vào đâu bèn lẳng lặng gói ghém mớ bòng bong lại.
Có doanh nghiệp thì một ngày đẹp trời sếp tuyên bố xanh rờn: Từ hôm nay chúng ta làm OKRs, dự án lập ra, tiền tiêu vô số, 3 năm sau cũng dừng, nhân viên đến giờ còn chưa hết ngơ ngác. Có rất nhiều câu chuyện tương tự như vậy xảy ra ở khắp nơi.
Tôi hỏi lý do vì sao họ thất bại thì ẻm bảo đơn giản là họ cố gắng thay đổi tổ chức bằng những vụ nổ lớn từ trên xuống dưới trong khi cách quản lý và tư duy của người lãnh đạo không thay đổi. Tôi vẫn thắc mắc thì cổ gửi cho tôi hẳn một bài dài ngoằng để giải thích.
Trong cuốn sách phát hành trên Amazon: Failures in DevSecOps, Volume 2", Cherry và Rob đã viết một chương có tên: Kill the restructure. Ai quan tâm có thể tìm đọc để hiểu cách tiếp cận linh hoạt để cải tiến tổ chức của mình. Đây là đoạn tóm tắt:
Có những cách làm việc và quản lý mới giúp chúng ta làm việc tốt hơn, nhanh hơn, rẻ hơn, an toàn hơn và hạnh phúc hơn. Tuy nhiên, thế giới đã tiếp cận với điều này chưa đủ nhanh. Có nhiều sai lầm kinh điển lặp đi lặp lại khi các tổ chức lớn cố gắng "thực hiện Agile/DevOps như một phương pháp mới thần kỳ", hoặc – "rùng mình" - "chuyển đổi/transform".
Ví dụ
Lấy DevOps (Tư duy làm việc và quản lý mới trong ngành CNTT) làm ví dụ. Quan điểm của DevOps là mở rộng, kết nối các bộ phận riêng rẽ, không phải thay đổi một hệ thống các bộ phận riêng rẽ này thành hệ thống các bộ phận riêng rẽ khác. Thay đổi từ lát cắt Bắc/Nam thành lát cắt Đông/Tây vẫn là lát cắt. Chúng tôi thấy quá nhiều doanh nghiệp cho rằng một trong những bước đầu tiên của DevOps là tổ chức lại. DevOps không phải là về tái cấu trúc. Bạn có thể tổ chức thành các bộ phận công nghệ theo chức năng với các nhóm sản phẩm ảo hoặc thành các nhóm sản phẩm có chức năng ảo và hội cùng nghề ảo. Dù bằng cách nào thì nó cũng là một ma trận.
Hầu hết các doanh nghiệp được tổ chức thành các nhóm chức năng. Mặc dù ưu tiên hiện tại dành cho nhóm sản phẩm và ý tưởng là các nhóm nên gắn với nhau trong thời gian dài, nhưng thực tế quy mô của nhóm sẽ tăng lên hoặc thu nhỏ mỗi khi khối lượng sản phẩm thay đổi. Do đó, chỉ có một nhóm cốt lõi sẽ không đổi - các nhóm cần phải linh hoạt. Vì vậy, chẳng có vấn đề gì là bất lợi khi các nhóm ảo được lấy từ các nhóm chức năng.
Hơn nữa, trong tương lai các nhóm sản phẩm được tập hợp từ nhiều bộ phận, không chỉ có nguồn gốc từ CNTT: tiếp thị, thiết kế sản phẩm, thiết kế kỹ thuật số, nhóm CNTT trong các bộ phận, nhà cung cấp, bên thứ ba... Do đó càng có thêm lý do để các đội là đội ảo.
Các nhóm kỹ thuật CNTT nội bộ của bạn có thể muốn tập hợp lại thành người cung cấp nền tảng, tự động hóa, công cụ, bảo mật… nhưng không cần phải vội vã cho đến khi bạn hiểu chính xác nó sẽ hoạt động như thế nào trong doanh nghiệp của mình.
Hãy để DevOps tạo ra hiệu quả trước, sau đó sắp xếp lại cấu trúc có thể giúp tối ưu hóa. Khi DevOps làm cho người của bạn nhận ra họ cần tái cấu trúc, thì đó là đúng lúc. Hãy để họ kéo đừng đẩy họ.
Hãy nói về "Tiến bộ" chứ không phải "Chuyển đổi".
Chúng ta nên tránh từ "chuyển đổi", mặc dù những thói quen cũ rất khó bỏ và bản thân chúng tôi vẫn đôi khi bắt gặp mình sử dụng nó. Sự chuyển đổi được thực hiện bởi các "bà tiên" hoặc loài sâu bướm. Các thực thể lớn không biến đổi như vậy, càng không thay đổi nhanh như thế và đó cũng không phải một bước hữu hạn. Chúng tôi dùng cụm từ "tiến bộ".
Dưới đây là một số cách tiếp cận sai lầm:
• Thay đổi lớn một lần (big bang).
• Thay đổi được thực hiện cho mọi người thay vì cải tiến được thực hiện bởi mọi người.
• "Chuyển đổi" như một dự án hữu hạn.
• Kỳ vọng rằng văn hóa có thể thay đổi nhanh chóng.
• Đối xử với văn hóa như một hệ thống đơn giản không phải là một hệ thống phức tạp.
• Niềm tin rằng quản lý biết câu trả lời.
• Bắt đầu với việc tái cấu trúc.
• CHỈ thực hiện tái cấu trúc.
Sự thất bại của hầu hết mọi trường hợp do 2 vấn đề chính: thất bại trong việc thay đổi quản lý và quản trị. Đây có lẽ là vấn đề lớn nhất. Quản lý là chiếc khóa khoá sự tiến bộ. Chức năng chính của nhiều nhà quản lý cấp trung là kiểm soát rủi ro. Họ chống lại sự thay đổi một cách tự nhiên. Thêm vào đó là quản lý cấp cao, những người, một cách vô tư lự, không biết về nhu cầu thay đổi của chính họ và sự tiến bộ cũng sẽ không đi đến đâu.
Thế còn tái cấu trúc thì sao?
Điều tệ hại là mục tiêu tái cấu trúc đặt ra rõ ràng để "trở nên linh hoạt hơn" nhưng lại được thực hiện như một vụ nổ lớn. Thật trớ trêu. Các bước chuyển đổi lớn, hữu hạn là một sự đánh cược lớn. Linh hoạt là về đặt cược nhỏ với bán kính nổ tối thiểu trong khi tái cấu trúc tổ chức không bao giờ làm như vậy. Nếu bạn thực sự linh hoạt, bạn sẽ không bao giờ (hoặc hiếm khi) phải thực hiện tái cấu trúc một lần nữa.
Trong tất cả sự rối loạn của việc chuyển đổi, tái cấu trúc là một trong những việc gây tác hại nhất. Chúng ta cần suy nghĩ lại về việc sử dụng cách tái cấu trúc tổ chức để theo đuổi sự chuyển đổi. Đừng làm điều đó, bởi vì:
• Nó không có tác dụng
• Nó phá vỡ các đội hiện có.
• Nó làm hỏng tinh thần.
• Tái cấu trúc chỉ có tác dụng khuấy động. Nó phá hủy sự kết nối của mọi người và phá vỡ các quy trình.
• Nó gieo rắc sự nhầm lẫn.
• và nó biến một hệ thống của những bộ phận cục bộ này thành một hệ thống của những bộ phận cục bộ khác.
Chắc chắn, đôi khi việc tái cấu trúc cũng có hiệu quả. Nếu tái cấu trúc thành công, đó là sự may mắn và cực kỳ nhọc nhằn. Các công ty tư vấn sẽ chỉ cho bạn biết về những thành công của họ (nhưng thực tế thì ngay cả một con sóc mù cũng có thể tìm thấy một vài hạt). Bạn có thể nhìn thấy một số tổ chức đã thực hiện khá thành công theo cách truyền thống nhưng cần nhiều người giỏi ở nhiều cấp độ để làm được điều này.
Trong thực tế, chúng tôi nghi ngờ về việc có những ngoại lệ thực sự "thành công". Nếu có, chắc chắn đó là thành công theo một nghĩa rất hẹp. Tái cấu trúc là bạo lực: dùng vũ lực để buộc mọi người làm theo và hậu quả để lại là văn hóa độc hại. Đây là điều chúng tôi phản đối mạnh mẽ nhất đối với việc tái cấu trúc. Ngoài ra, tái cấu trúc quy trình và tổ chức được thiết kế sau cánh cửa đóng kín, sau đó được áp đặt bởi sắc lệnh thì những hậu quả lâu dài đối với vấn đề an toàn tâm lý, với niềm tin vào quản lý và với sự thay đổi bền vững thực sự sẽ là gì?
Thôi, ai muốn phản biện gì thì vào nhà chuyên gia mà cãi, tôi chả liên quan: https://www.facebook.com/DrCherryVu
Nếu muốn tìm hiểu về tư duy quản lý linh hoạt thì có cả một câu lạc bộ để học: https://www.facebook.com/groups/caulacbocacnhaquanlylinhhoat
Hoặc các vị có thể đọc để hiểu tường tận, cuốn The agile Manager bản tiếng Anh thì tôi được tặng cách đây 2 năm cơ, giờ mới ra tiếng Việt:
Vụ này mới hãi, em ý vừa ra một cuốn sách áp dụng tư duy linh hoạt để làm cha mẹ tốt hơn có cái tên thật như đếm "Con mình chẳng lẽ lại 'vứt'?" nổi tiếng vừa ra lò đã tái bản, top 7 trên 1000 cuốn sách viết về giáo dục và làm cha mẹ. Ai thích tự google đi. Tôi không biết họ bán ở đâu.
Những ai đang định tái cơ cấu hay chuyển đổi tổ chức đọc xong bài này không cần cảm ơn tôi đâu. Nếu đủ 666 like tôi sẽ post bản full không che cả tiếng Anh lẫn tiếng Việt bài "Kill the restructure".
No comments:
Post a Comment