Xây dựng văn hóa DevOps trong nhà máy: vấn đề con người mà không ai nhắc tới

70% các sáng kiến chuyển đổi số không đạt được mục tiêu đề ra. Nghiên cứu của McKinsey liên tục chỉ ra cùng một nguyên nhân: rào cản lớn nhất là văn hóa, không phải công nghệ.

Trong một công ty phần mềm, xây dựng văn hóa DevOps là một thách thức về con người. Trong một nhà máy, đó là thách thức về con người với thêm một lớp phức tạp: hai nhóm người có ưu tiên khác nhau, mức độ chấp nhận rủi ro khác nhau, và định nghĩa khác nhau về thế nào là tốt, cùng làm việc trên cùng một sàn sản xuất.

Đội OT, những kỹ sư vận hành PLC, hệ thống SCADA và dây chuyền sản xuất, được tuyển dụng để giữ máy móc hoạt động liên tục. Chỉ số hiệu suất của họ là thời gian hoạt động. Đội IT được tuyển dụng để xây dựng và triển khai hệ thống. Chỉ số hiệu suất của họ là tốc độ. DevOps yêu cầu cả hai nhóm chia sẻ một pipeline, chia sẻ trách nhiệm và chia sẻ một định nghĩa chung về hoàn thành. Đó không phải là vấn đề công nghệ. Đó là vấn đề tổ chức mà công nghệ không thể tự giải quyết.

Đây chính là vấn đề con người mà hầu hết các dự án triển khai DevOps trong sản xuất không giải quyết được, và là lý do khiến nhiều dự án dừng lại sau giai đoạn thí điểm.

Vì sao văn hóa DevOps thất bại trong ngành sản xuất?

Chỉ 26% doanh nghiệp coi quản lý thay đổi là một phần quan trọng trong quá trình chuyển đổi Công nghiệp 4.0, theo các nghiên cứu ngành. Phần lớn coi đây là việc phụ, hoặc bỏ qua hoàn toàn. Họ triển khai công nghệ trước và mặc định rằng việc áp dụng sẽ tự diễn ra.

Không phải vậy.

Bốn nỗi lo cụ thể thúc đẩy sự phản kháng trên sàn nhà máy:

• Mất việc do tự động hóa: người lao động coi hệ thống mới là sự thay thế cho vai trò của họ, chứ không phải công cụ giúp thay đổi công việc đó
• Không thể thích nghi: các kỹ năng được xây dựng qua nhiều năm trên thiết bị cũ không tự động chuyển đổi sang môi trường mới
• Nghi ngờ độ tin cậy của công nghệ mới: đội OT đã từng chứng kiến hệ thống IT gặp sự cố. Một PLC gặp sự cố sẽ dừng cả dây chuyền. Sự hoài nghi này không phải vô lý, nó đến từ kinh nghiệm thực tế
• Mất quyền kiểm soát cách làm việc quen thuộc: những người hiểu rõ sàn nhà máy nhất lại là những người được yêu cầu thay đổi nhiều nhất

Không nỗi lo nào trong số này được giải quyết chỉ bằng cách triển khai công cụ tốt hơn. Mỗi nỗi lo đòi hỏi một phản ứng có chủ đích: giao tiếp, đào tạo, sự tham gia và thời gian.

Văn hóa DevOps thực sự đòi hỏi điều gì trong bối cảnh sản xuất?

Báo cáo DORA 2024 State of DevOps, nghiên cứu theo chiều dọc lớn nhất về DevOps với hơn 39.000 người tham gia, cho thấy văn hóa tổ chức và chất lượng lãnh đạo là yếu tố dự báo hiệu suất triển khai mạnh không kém bất kỳ thực hành kỹ thuật nào. Văn hóa không phải là yếu tố phụ trợ mềm cho việc triển khai kỹ thuật. Nó là yếu tố quyết định kết quả ngang hàng với công nghệ.

Trong ngành sản xuất, phát hiện này có một hàm ý cụ thể. Báo cáo DORA xác định rằng ưu tiên tổ chức không ổn định gây ra sự sụt giảm năng suất đáng kể và tình trạng kiệt sức nghiêm trọng, những tác động vẫn tồn tại ngay cả khi có sự lãnh đạo mạnh mẽ và tài liệu tốt, khiến chúng đặc biệt khó khắc phục bằng biện pháp kỹ thuật. Trong bối cảnh nhà máy, ưu tiên tổ chức không ổn định chính là trạng thái mặc định của một quá trình tích hợp OT/IT chưa xác định rõ ai sở hữu pipeline.

Quyền sở hữu là câu hỏi văn hóa đầu tiên. Không phải công cụ, không phải quy trình, không phải hạ tầng. Ai chịu trách nhiệm cho kết quả?

Khảo sát Smart Manufacturing 2025 của Deloitte cho thấy 51% các sáng kiến sản xuất thông minh do lãnh đạo vận hành sở hữu, và 38% do lãnh đạo công nghệ sở hữu. Sự chia sẻ quyền sở hữu này là nguyên nhân trực tiếp dẫn đến thất bại triển khai. Một pipeline có hai chủ sở hữu và không có cơ chế phân xử sẽ mặc định theo người ra quyết định chậm nhất, và trong ngành sản xuất, đó luôn là đội OT, vì rủi ro về thời gian hoạt động thuộc về họ.

Cách xây dựng văn hóa DevOps trong nhà máy: một khung thực hành

Thay đổi văn hóa trong ngành sản xuất không diễn ra nhanh chóng. LNS Research ước tính hầu hết các doanh nghiệp công nghiệp cần 3 đến 5 năm để hoàn thành một quá trình chuyển đổi ở quy mô lớn. Triển khai công nghệ mất vài tháng. Việc áp dụng văn hóa mất nhiều năm. Bất kỳ kế hoạch triển khai nào không tính đến khoảng cách này không phải là một kế hoạch, mà chỉ là một hy vọng.

Khung phù hợp nhất với môi trường sản xuất dựa theo mô hình thay đổi 8 bước của Kotter, với hai bước gần như luôn bị bỏ qua: tạo cảm giác cấp bách và neo giữ sự thay đổi trong văn hóa.

Bước 1 - Tạo cảm giác cấp bách rõ ràng trước khi động đến công nghệ

Khảo sát Bitkom 2025 với các doanh nghiệp Đức cho thấy 82% tin rằng nước Đức đang trong khủng hoảng số hóa, và 73% cho rằng Đức đã mất thị phần do áp dụng chậm. Dữ liệu đó tồn tại ở cấp quốc gia. Các giám đốc vận hành cần dữ liệu tương tự ở cấp công ty: cụ thể, đo lường được, tức thời. Nếu không có chi phí rõ ràng của việc không hành động, lựa chọn mặc định trên sàn nhà máy luôn là giữ nguyên hiện trạng.

Bước 2 - Xây dựng liên minh liên chức năng với OT làm trung tâm

Sai lầm phổ biến nhất là giao quyền sở hữu DevOps cho IT và yêu cầu OT hợp tác. Cấu trúc đó tái lập mối quan hệ kiểu nhà cung cấp vốn giết chết các đội nhóm phân tán: một bên định nghĩa, bên còn lại thực thi. Liên minh này phải được đồng lãnh đạo. Kỹ sư OT nắm giữ kiến thức quy trình không thể thay thế. Khi được tham gia sớm, họ trở thành người ủng hộ. Khi chỉ được thông báo muộn, họ trở thành người cản trở.

Bước 3 - Bắt đầu với một dây chuyền và biến đội OT thành chuyên gia

Đừng cố gắng thay đổi văn hóa của toàn bộ nhà máy. Hãy chọn một dây chuyền sản xuất, triển khai thí điểm, và tổ chức sao cho đội OT của dây chuyền đó là người hướng dẫn đội IT cách quy trình vận hành, chứ không phải ngược lại. Động lực quyền lực rất quan trọng. Đội OT cảm thấy mình là đối tượng của chương trình thay đổi sẽ phản kháng. Đội OT cảm thấy mình là đồng thiết kế chương trình đó sẽ dẫn dắt nó.

Bước 4 - Xác định chỉ số chung trước khi triển khai công cụ chung

Công cụ chung mà không có chỉ số chung sẽ khiến hai đội đo lường những thứ khác nhau bằng cùng một bộ công cụ. Hãy xác định bốn chỉ số DORA, tần suất triển khai, thời gian dẫn cho thay đổi, tỷ lệ thất bại của thay đổi, thời gian trung bình để khôi phục, làm bảng điểm chung trước khi đưa ra bất kỳ quyết định hạ tầng nào. Khi cả hai đội được đánh giá theo cùng một bộ số liệu, cơ cấu động lực sẽ thay đổi.

Bước 5 - Đầu tư vào đào tạo lại như hạ tầng, không phải như một đặc quyền

Nhu cầu về năng lực mô phỏng và phần mềm trong ngành sản xuất tăng 75% từ năm 2021 đến 2024, theo Nghiên cứu Lực lượng Lao động 2024 của Deloitte và Manufacturing Institute. Các kỹ sư OT được yêu cầu làm việc trong một pipeline DevOps vốn không được tuyển dụng cho những kỹ năng đó. Đào tạo lại không phải là lựa chọn, mà là yếu tố cho phép quyền sở hữu chung trở nên khả thi trên thực tế. Hãy coi đó là một khoản đầu tư vốn, không phải một dòng ngân sách đào tạo.

Bước 6 - Neo giữ sự thay đổi bằng ngôn ngữ vận hành, không phải ngôn ngữ IT

Tần suất triển khai không có ý nghĩa gì với một quản đốc nhà máy. Câu hỏi có thể thay đổi bao nhiêu cấu hình mỗi tuần mà không phải dừng dây chuyền lại mang cùng một ý nghĩa. Mỗi khái niệm DevOps đều có một khái niệm tương đương trong sản xuất. Hãy dùng phiên bản sản xuất. Thuật ngữ báo hiệu quyền sở hữu của IT đối với quy trình sẽ bị sàn nhà máy từ chối, không phải vì bướng bỉnh, mà vì nó cho thấy sự thay đổi đang xảy ra với họ, chứ không phải cùng họ.

Kết quả tốt trông như thế nào?

Mức độ gắn kết của lực lượng lao động sản xuất toàn cầu chỉ vào khoảng 15%, theo dữ liệu đa ngành của Gallup. Đó là điểm khởi đầu: không phải một lực lượng lao động đầy động lực đang chờ công cụ tốt hơn, mà là một lực lượng lao động mà phần lớn không thực sự đầu tư vào công việc hay việc cải thiện nó. Những công ty tiên phong về số hóa, những công ty xây dựng văn hóa song song với hạ tầng, đạt được biên lợi nhuận tốt hơn tới 50% so với các công ty đi sau trong cùng ngành, theo nghiên cứu của McKinsey về số hóa trong sản xuất.

Khoảng cách giữa mức gắn kết 15% và biên lợi nhuận tốt hơn 50% không phải là khoảng cách công nghệ. Đó là khoảng cách về lãnh đạo và văn hóa. Các công ty thu hẹp được khoảng cách này không làm vậy bằng cách triển khai thêm hệ thống. Họ làm vậy bằng cách thay đổi ý nghĩa của các hệ thống đó đối với những người vận hành chúng.

FAQ

Làm thế nào để xây dựng văn hóa DevOps trong một doanh nghiệp sản xuất?

Xây dựng văn hóa DevOps trong ngành sản xuất đòi hỏi phải xem khoảng cách OT/IT là một vấn đề tổ chức, không phải vấn đề kỹ thuật. Các bước thực tế gồm: tạo cảm giác cấp bách ở cấp công ty, xây dựng liên minh liên chức năng với sự lãnh đạo của OT làm trung tâm, bắt đầu bằng thí điểm trên một dây chuyền nơi đội OT cùng thiết kế quy trình, xác định các chỉ số DORA chung trước khi triển khai công cụ chung, và đầu tư vào đào tạo lại như một phần hạ tầng. Việc áp dụng văn hóa mất 3 đến 5 năm ở quy mô đầy đủ, hãy lập kế hoạch cho điều đó.

Vì sao các dự án chuyển đổi DevOps thất bại trong ngành sản xuất?

70% các sáng kiến chuyển đổi số không đạt được mục tiêu, theo nghiên cứu của McKinsey, trong đó văn hóa liên tục được xác định là rào cản lớn nhất. Trong ngành sản xuất nói riêng, nguyên nhân thất bại mang tính cấu trúc: đội OT và IT có mức độ chấp nhận rủi ro khác nhau, chỉ số hiệu suất khác nhau, và định nghĩa thành công khác nhau. Chỉ 26% doanh nghiệp coi quản lý thay đổi là một phần quan trọng trong quá trình chuyển đổi Công nghiệp 4.0, nghĩa là phần lớn triển khai công nghệ mà không giải quyết các điều kiện về con người quyết định liệu nó có thành công hay không.

Sự khác biệt giữa văn hóa DevOps trong ngành phần mềm và ngành sản xuất là gì?

Trong ngành phần mềm, văn hóa DevOps đòi hỏi phải liên kết đội phát triển và đội vận hành xung quanh một pipeline triển khai chung. Trong ngành sản xuất, sự liên kết tương tự cũng cần thiết, nhưng đội OT vận hành thiết bị sản xuất có thêm một ràng buộc: thời gian hoạt động là trách nhiệm chính của họ, và một lần triển khai thất bại không thể quay lui, nó sẽ làm dừng cả dây chuyền. Điều này thay đổi mức độ chấp nhận rủi ro, yêu cầu về quản lý thay đổi, và thời gian cần thiết để áp dụng văn hóa.

Cần bao lâu để xây dựng văn hóa DevOps trong một nhà máy?

Triển khai công nghệ trong ngành sản xuất mất vài tháng. Áp dụng văn hóa mất nhiều năm. LNS Research ước tính hầu hết các doanh nghiệp công nghiệp cần 3 đến 5 năm để hoàn thành một quá trình chuyển đổi ở quy mô lớn. Các dự án triển khai chỉ lập kế hoạch cho chương trình thay đổi văn hóa trong 12 tháng sẽ bị đình trệ, không phải vì công nghệ thất bại, mà vì tổ chức chưa có đủ thời gian để thay đổi cách vận hành.

Khoảng cách OT/IT là gì và vì sao nó quan trọng đối với DevOps trong ngành sản xuất?

Khoảng cách OT/IT là khoảng cách tổ chức và văn hóa giữa các đội công nghệ vận hành, những người vận hành thiết bị nhà máy bao gồm PLC, SCADA và cảm biến, và các đội công nghệ thông tin xây dựng và quản lý hệ thống phần mềm. Đội OT ưu tiên thời gian hoạt động và sự ổn định. Đội IT ưu tiên tốc độ và sự thay đổi. DevOps đòi hỏi cả hai đội chia sẻ một pipeline và trách nhiệm chung. Thu hẹp khoảng cách đó là thách thức trung tâm của DevOps trong ngành sản xuất, và đó là vấn đề văn hóa, không phải vấn đề công nghệ.