Theo quan điểm từ các chuyên gia phát triển sản phẩm, thất bại trong việc quản lý các giao diện giữa các bộ phận chức năng có thể là nguồn gốc lớn nhất của lãng phí, sự thất vọng và thất bại trong quá trình phát triển sản phẩm. Một phần giải pháp cho vấn đề này là hệ thống quản lý obeya. Dưới đây là mười gợi ý thực tiễn để triển khai quản lý obeya hiệu quả, dựa trên kinh nghiệm từ hàng trăm dự án trên nhiều ngành công nghiệp khác nhau.
Như trong các thiết kế hệ thống phức tạp, hầu hết các chương trình phát triển gặp khó khăn tại các giao diện. Nói cách khác, quản lý các mối phụ thuộc giữa các bộ phận chức năng cần thiết như thiết kế, phần mềm, kỹ thuật, sản xuất và các lĩnh vực khác là thách thức lớn nhất trong quá trình phát triển. Điều này đặc biệt đúng khi các công ty cố gắng làm việc đồng thời mà không hiểu rõ các mối phụ thuộc này. Kinh nghiệm cho thấy đây có thể là nguyên nhân hàng đầu dẫn đến việc làm lại, trì hoãn, vượt ngân sách và các vấn đề chất lượng, thường tạo ra môi trường làm việc chia rẽ, đối đầu và gây thất vọng cho tất cả những người liên quan.
Lean Product and Process Development (LPPD) là một tập hợp các nguyên tắc, thực hành và công cụ được thiết kế để giúp các cá nhân từ nhiều bộ phận khác nhau làm việc cùng nhau, tạo ra các luồng giá trị mới thành công. Một trong những công cụ đó là hệ thống quản lý obeya. Obeya, như hầu hết mọi người đều biết, là một từ tiếng Nhật có nghĩa là “phòng lớn”. Tuy nhiên, nó còn vượt xa điều đó. Obeya là nơi chương trình được kết nối theo nhịp độ để cải thiện sự hợp tác, giao tiếp và phối hợp thông qua việc quản lý minh bạch, chủ động các giao diện. Khi được thực hiện đúng cách, đây là một hệ thống quản lý mạnh mẽ giúp mọi người làm việc hiệu quả hơn, không chỉ đơn thuần là nơi treo các tài liệu trên tường.
Hiện tại, có một số tranh luận (không quan trọng) về nguồn gốc của obeya, nhưng lần đầu tiên obeya được áp dụng như một hệ thống quản lý là vào năm 2003, khi các cuộc họp với Takeshi Uchiyamada, kỹ sư trưởng dẫn dắt phát triển mẫu Toyota Prius ban đầu, đã chỉ ra vai trò của nó. Sản phẩm đột phá này đòi hỏi quản lý nghiêm ngặt và hiệu quả các mối phụ thuộc xuyên suốt nhiều bộ phận cần thiết để tích hợp các công nghệ tạo ra sản phẩm làm thay đổi ngành công nghiệp. Obeya đã cung cấp chính xác những gì đội ngũ Prius cần để đạt được thành công.
10 Bài Học Thực Tiễn Từ Kinh Nghiệm
Từ đó, hàng trăm obeya đã được tham gia, xây dựng hoặc quan sát trong các ngành ô tô, hàng không, y tế, điện tử, công nghệ năng lượng, thiết bị gia dụng và nhiều lĩnh vực khác. Dưới đây là một số bài học quan trọng về obeya thành công:
- Obeya không phải là hình thức giải trí cho ban quản lý cấp cao. Đây là công cụ cho đội ngũ phát triển quản lý dự án và nên được thiết kế phù hợp. Cách tiếp cận cố định nhưng linh hoạt trong thiết kế obeya thường là tốt nhất. Cung cấp hướng dẫn và các phương pháp hay nhất cho đội ngũ, có thể bao gồm một số yêu cầu tối thiểu, nhưng để đội ngũ có đủ không gian tùy chỉnh không gian theo nhu cầu cụ thể của họ.
- Được phép ở trạng thái “đỏ” nhưng không được duy trì trạng thái đó. Trong quá trình phát triển, nhiều vấn đề có thể xảy ra. Obeya yêu cầu sự minh bạch. Mọi người sẽ không cởi mở nếu bị chỉ trích mỗi khi nêu vấn đề. Do đó, việc đưa ra vấn đề phải được coi là an toàn và bình thường. Tuy nhiên, không thể dừng lại ở đó. Obeya không phải nơi chỉ để trút bỏ vấn đề. Nếu báo cáo trạng thái dự án là “đỏ”, cần có câu trả lời cho các câu hỏi sau: Kế hoạch để đạt trạng thái “xanh” là gì? Ngày dự kiến đạt “xanh” là khi nào? Cần hỗ trợ gì? Ảnh hưởng đối với phần còn lại của chương trình là gì?
- Làm rõ kế hoạch và mục tiêu, bao gồm tất cả các lộ trình quan trọng. Khách hàng là ai? Chúng ta đang cố gắng làm gì? Đề xuất làm như thế nào? Các thuộc tính quan trọng của sản phẩm hoặc dịch vụ này là gì? Kế hoạch để cung cấp là gì? Ai chịu trách nhiệm cho từng phần của kế hoạch? Hãy nhớ rằng obeya không chỉ là lịch trình.
- Tập trung vào các chỉ số dẫn đầu, không phải chỉ số trì hoãn. Đội ngũ cần thời gian để phản ứng và khắc phục vấn đề. Việc biết một thứ sẽ chậm năm tuần vào ngày đến hạn không giúp ích gì. Làm việc ngược từ sự kiện quan trọng – bước nào có khả năng quyết định kết quả của sản phẩm đó?
- Sử dụng các điểm tích hợp hiệu quả được định nghĩa bởi tiêu chí chất lượng sự kiện, không chỉ hoạt động. Nhiều chương trình định nghĩa các điểm tích hợp hoặc cột mốc chỉ dựa trên hoạt động. Chẳng hạn, lấy ví dụ về lần xây dựng ảo đầu tiên. Trong hệ thống đó, bạn hoàn thành hoạt động – vậy cột mốc được đáp ứng. Điều này có thể rất gây hiểu lầm. Bao nhiêu thiết kế đạt mức độ trưởng thành phù hợp? Có bao nhiêu vấn đề chưa giải quyết? Mức độ sẵn sàng của nhà cung cấp hoặc sản xuất là gì (tức là, chúng ta có thể cung cấp những thiết kế đó không)? Đặt ngưỡng chất lượng tối thiểu.
- Minh bạch + Nhịp độ = Trách nhiệm – Kịch tính. Trong những ngày đầu, các cuộc họp chương trình từng chứng kiến nhiều tình huống căng thẳng, đe dọa và thậm chí ném ghế. Đó là kịch tính nói lên nhiều điều về nhà lãnh đạo hơn là đội ngũ chương trình. Điều này tạo ra môi trường mà mục tiêu khi báo cáo trạng thái là thoát khỏi sân khấu và không phải con linh dương chậm nhất.
So sánh với cách Alan Mulally nói “Không sao đâu, chúng ta sẽ quay lại vào tuần sau, và tôi biết bạn sẽ có kế hoạch tốt hơn” trong các buổi xem xét Kế hoạch Kinh doanh nổi tiếng của ông. Đó là sức mạnh của minh bạch và nhịp độ. Không la mắng, không đe dọa, nhưng cũng không có chỗ để trốn tránh vì mọi người sẽ tiếp tục gặp nhau.
Một lưu ý nhanh về nhịp độ và địa điểm của obeya: Cả hai có thể thay đổi tùy thuộc vào nhu cầu của dự án/chương trình. Ở giai đoạn đầu, đội ngũ có thể chỉ cần gặp nhau hai tuần một lần. Nhưng trong thời gian thử nghiệm, xây dựng hoặc ra mắt căng thẳng, đội ngũ có thể cần họp hàng ngày. Tương tự, obeya có thể được đặt tại khu vực thiết kế ở đầu chương trình, xưởng mẫu ở giữa, và nhà máy sản xuất trong giai đoạn ra mắt. - Sự tham gia không phải là tùy chọn. Mọi người đều được bao gồm. Mọi người hiểu kế hoạch và trách nhiệm của họ. Mọi người tham gia. Điều này bao gồm các nhà cung cấp hoặc lãnh đạo chuỗi cung ứng quan trọng khi cần thiết.
- Các lãnh đạo nhóm công việc nói chuyện với thành viên nhóm của họ. Họ hiểu rõ nhất và là những người chịu trách nhiệm.
- Xây dựng/sử dụng chuỗi hỗ trợ hiệu quả. Thỉnh thoảng, các vấn đề sẽ vượt quá khả năng của một đội ngũ cá nhân. Phải có phương pháp được xác định trước và hiệu quả để nêu vấn đề và hỗ trợ đội ngũ kịp thời. Gợi ý: Không phải là thêm nhiều báo cáo cho ban quản lý cấp cao.
- Xem xét chương trình ở mức độ phù hợp. Đừng lãng phí thời gian của mọi người để giải quyết một vấn đề cá nhân trong chi tiết. Hãy làm điều đó sau. Trọng tâm nên là quản lý các giao diện. Tuy nhiên, đồng thời cần tránh “duy trì hy vọng” với các khoảng thời gian lớn không được định nghĩa rõ ràng. Như nhiều thứ khác, đây là sự cân bằng phải được duy trì bởi lãnh đạo có kỹ năng.
Tận Dụng Tốc Độ và Độ Chính Xác
Sự hợp tác đồng thời của nhiều bộ phận là chìa khóa để tăng tốc độ đưa sản phẩm ra thị trường. Điều này không nhất thiết dẫn đến lượng lớn công việc làm lại và lãng phí. Chìa khóa thành công là hiểu rõ công việc cần thực hiện và các mối phụ thuộc giữa các nhóm công việc. Thiết kế quy trình phát triển để tận dụng các phụ thuộc này là bước đầu tiên để thực hiện tốt.
Tuy nhiên, quy trình phát triển không thể dự đoán mọi chế độ thất bại tiềm ẩn và thiết kế các biện pháp đối phó. Cũng không nên làm vậy. Điều này sẽ tạo ra một quy trình quan liêu, tốt nhất là mất nhiều thời gian hơn quy trình tuần tự, và tệ nhất là hoàn toàn không thể thực hiện. Obeya cho phép quản lý các phụ thuộc theo thời gian thực. Bạn sẽ thấy xung đột tiềm tàng ở phía trước và có một diễn đàn sẵn sàng để phản ứng, điều chỉnh lộ trình và giữ mọi người trên cùng một trang.
Khi kết hợp, thiết kế quy trình phát triển hiệu quả và hệ thống quản lý obeya sẽ giúp các đội ngũ phát triển thực hiện với mức độ tốc độ và độ chính xác, trở thành lợi thế cạnh tranh.
Bài viết này đã được chuyển ngữ sang tiếng Việt, và được đăng trên website của Lean Global Network.
Kim Đăng Consulting là đối tác chính thức và duy nhất của Lean Global Network tại Việt Nam.
