Costdown Cho Kỹ Sư
Một kỹ sư mất nhiều tuần thử và sai để rút ngắn thời gian chu kỳ của một công đoạn — đo, phân tích, thử vật liệu, chỉnh đồ gá, xác nhận chất lượng, tính lại saving. Việc đó đòi hỏi hiểu đúng máy, đúng vật liệu, đúng điều kiện vận hành thực tế, không phải thứ làm xong trong một buổi chiều. Kết quả được trình bày trong một buổi họp, ghi vào một báo cáo nội bộ, rồi nằm trong ổ đĩa chung của phòng kỹ thuật. Sáu tháng sau, khi được hỏi lại chi tiết đã làm gì, ngay cả người viết báo cáo đó cũng phải lục lại file mới nhớ chính xác. Đừng để những gì bạn đã giải quyết chỉ nằm lại trong một file Excel — đó là toàn bộ lý do trang này tồn tại.
Một báo cáo hoàn thành không có nghĩa là kinh nghiệm đã được lưu giữ
Một báo cáo thường ghi rất rõ con số: trước 55 giây, sau 41 giây, tiết kiệm bao nhiêu một sản phẩm. Với người viết ra nó, thông tin đó đủ rõ. Nhưng một kỹ sư khác đọc lại vài năm sau thường không biết phần quan trọng hơn con số: vì sao cách làm cũ lại chậm, phần nào của đồ gá được đổi, điều kiện sản xuất lúc đó ra sao, giải pháp vì sao hoạt động, có vấn đề chất lượng nào phát sinh trong lúc thử không, và nó có áp dụng được cho sản phẩm khác không. Một báo cáo lưu đúng con số cuối cùng, nhưng thường không lưu phần lý giải phía sau nó — và phần đó mới là thứ giúp người khác biết có nên thử cách tương tự hay không.
Costdown không cần kỹ sư trở thành người viết nội dung
Đây là ranh giới cần nói rõ, vì dễ bị hiểu nhầm. Costdown không yêu cầu kỹ sư viết bài dài, không cần biết cách trình bày cho hấp dẫn, không cần kể một câu chuyện hoàn chỉnh. Việc cần làm hẹp hơn nhiều và gần với công việc họ vốn đã làm: ghi lại vấn đề là gì, đã thay đổi điều gì, điều kiện trước và sau ra sao, kết quả đo được là bao nhiêu, và giới hạn áp dụng của nó — tức đúng những gì một báo cáo kỹ thuật tốt vẫn cần có, chỉ khác ở chỗ được ghi theo một cấu trúc để người khác tìm lại được.
Không cần tự làm hết việc trình bày và phân loại
Một rào cản thật của việc ghi lại kinh nghiệm là kỹ sư không có thời gian cho việc định dạng, đặt tên, phân loại một dự án sau khi đã dồn hết thời gian cho phần kỹ thuật. Costdown không đặt thêm gánh nặng đó lên kỹ sư: công đoạn, máy, vật liệu đã có mã chuẩn để chọn thay vì phải tự nghĩ cách mô tả và đặt tên cho đúng; phần kỹ sư cần bỏ công thật sự chỉ là nội dung cốt lõi — vấn đề, thay đổi, kết quả. Việc còn lại là cấu trúc đã có sẵn để điền vào, không phải một trang giấy trắng mỗi lần cần ghi lại.
Một cải tiến, khi có cấu trúc, không còn chỉ thuộc về một buổi họp
Giả sử một kỹ sư giảm được thời gian gia công một chi tiết bằng cách đổi lại thứ tự các bước cắt. Nếu chỉ ghi trong báo cáo nội bộ, giá trị của việc đó dừng lại ở đúng công đoạn, đúng nhà máy, đúng thời điểm nó được làm. Nếu ghi theo cấu trúc, nó trở thành thứ:
- Tìm được — một kỹ sư khác, ở một nhà máy khác, gặp đúng bài toán về công đoạn hoặc vật liệu này có thể tìm ra nó thay vì tự mày mò lại từ đầu.
- Học được — cấu trúc của cách giải quyết được nhìn thấy rõ, không chỉ có kết luận cuối cùng mà không rõ nó đi từ đâu ra.
- Áp dụng biến thể được — người tìm thấy nó không sao chép nguyên bản, họ điều chỉnh theo điều kiện máy, vật liệu và quy mô sản xuất thật của mình, rồi đo lại kết quả của riêng họ.
- Quay lại hệ thống — kết quả mới đó trở thành một case khác, tiếp tục ở đó cho người tiếp theo, và người kỹ sư ban đầu vẫn đứng tên là người tạo ra điểm khởi đầu của nó.
Kỹ sư không chỉ cho đi — còn nhận lại
Ghi lại kinh nghiệm trên Costdown không phải một con đường một chiều, nơi kỹ sư chỉ đóng góp mà không nhận gì. Cùng lúc một kỹ sư ghi lại cách mình từng giảm chi phí ở một công đoạn, họ cũng đang đứng trước cơ hội tìm thấy cách người khác từng giải quyết một bài toán khác mà chính họ đang gặp. Người vừa đóng góp một case về cải tiến đồ gá hôm nay có thể là người tìm thấy một case về giảm hao phí vật liệu vào tuần sau, cho đúng vấn đề họ đang cần giải. Không ai chỉ ở một phía của vòng lặp này.
Không cần chia sẻ bí mật mới chia sẻ được kinh nghiệm
Một kỹ sư có thể chia sẻ nguyên lý và kết quả của một cải tiến mà không cần tiết lộ bản vẽ chi tiết, định mức đầy đủ, đơn giá thoả thuận với nhà cung cấp hay thông tin khách hàng. Ghi "giảm được lượng vật liệu hao phí nhờ đổi cách xếp phôi" là đủ để người khác học được nguyên lý, mà không cần đính kèm toàn bộ bản vẽ hay hợp đồng mua vật liệu. Điều cần chia sẻ là phần tri thức đủ để người khác hiểu và đánh giá — không phải toàn bộ dữ liệu nội bộ đứng sau nó.
Một case không cần hoàn hảo mới có giá trị
Không phải phương án nào cũng thành công, và điều đó không làm nó vô giá trị. Một phương án từng thử nhưng không đạt kết quả như kỳ vọng — không hiệu quả ở một mức sản lượng nhất định, hoặc đầu tư không bù lại được — vẫn là một thông tin đáng ghi lại. Nó giúp một kỹ sư khác, đang cân nhắc đúng hướng đó cho điều kiện tương tự, đặt câu hỏi đúng trước khi bỏ công thử lại từ đầu. Kinh nghiệm không chỉ là "điều gì đã thành công" — nó cũng có thể là "điều gì đã được thử, và không hiệu quả trong điều kiện nào".
Một hồ sơ năng lực dựa trên việc thật đã làm
Sau nhiều năm làm việc, một kỹ sư có thể đã đi qua hàng chục dự án giảm chi phí thuộc nhiều dạng khác nhau — nhưng nếu chúng chỉ nằm rải rác trong các báo cáo riêng lẻ, không có cách nào nhìn thấy toàn bộ những gì mình thực sự đã làm. Khi mỗi dự án được ghi lại theo cấu trúc, chúng cộng lại thành một thứ khác một tấm bằng hay một dòng "nhiều năm kinh nghiệm sản xuất" trong hồ sơ — một tập hợp cụ thể những vấn đề đã giải quyết và những kết quả đã đo được, đứng tên đúng người đã làm ra nó.
Một cải tiến, không chỉ một lần tiết kiệm
Khi một cải tiến chỉ nằm trong báo cáo nội bộ, nó tạo ra đúng một lần giá trị — lần nó được làm, cho đúng một nhà máy. Khi nó được ghi lại thành một case có cấu trúc, nó tiếp tục tạo giá trị mỗi lần có người khác tìm thấy và dùng lại nó theo cách phù hợp với điều kiện của họ. Với người kỹ sư đã bỏ công làm ra nó, đó là khác biệt giữa một việc đã xong và một thứ vẫn tiếp tục là của mình — vẫn được ghi nhận là điểm khởi đầu — mỗi khi có người khác dùng lại nó để tạo ra một kết quả mới.