Privacy statement: Your privacy is very important to Us. Our company promises not to disclose your personal information to any external company with out your explicit permission.
Hầu hết thời gian ngừng hoạt động trong sản xuất đều bắt đầu từ phản hồi của máy không rõ ràng chứ không phải lỗi nghiêm trọng và đó chính xác là lý do tại sao việc hiện đại hóa HMI lại quan trọng. Khi người vận hành có thể hiểu lỗi ngay lập tức, xác định sự cố nhanh hơn và tin tưởng vào những gì máy đang thông báo, họ có thể ngăn các lỗi mã hóa hoặc giao diện nhỏ biến thành sự gián đoạn sản xuất tốn kém, sai sót về chất lượng hoặc thậm chí là rủi ro thu hồi lớn. HMI thông minh hơn sẽ cải thiện tốc độ khắc phục sự cố, độ tin cậy của người vận hành và thời gian hoạt động tổng thể mà không buộc phải thay thế toàn bộ máy. Trong môi trường sản xuất áp lực cao ngày nay, tầm nhìn rõ ràng hơn và phản ứng nhanh hơn là sự khác biệt giữa việc duy trì đúng tiến độ và đối mặt với sự hỗn loạn tốn kém.
Tôi đã thấy một lỗi mã hóa nhỏ biến thành một hóa đơn lớn. Một điều kiện sai, một bài kiểm tra bị bỏ lỡ hoặc một dòng được sao chép với biến sai có thể khiến sản phẩm xấu được đưa vào thị trường. Sau đó, vấn đề phát triển nhanh chóng. Khách hàng gọi. Đội dịch vụ được kéo đến. Các bộ phận thay thế được chuyển đi. Chi phí thu hồi không thuộc về nhóm mã. Nó lan rộng khắp toàn bộ doanh nghiệp. Tôi nghĩ đây là lý do tại sao chất lượng phần mềm cần được quan tâm giống như thiết kế sản phẩm. Mã không chỉ là văn bản trên màn hình. Nó có thể thay đổi cách máy di chuyển, cách thiết bị đọc dữ liệu hoặc cách hệ thống phản ứng khi bị căng thẳng. Tôi đặt một ý tưởng làm trọng tâm trong công việc của mình: nếu một lỗi có thể ảnh hưởng đến sự an toàn, tiền bạc hoặc lòng tin, tôi coi nó như một rủi ro thực địa. Tôi bắt đầu bằng việc tìm những đường dẫn mã quan trọng nhất. Không phải mọi dòng đều có rủi ro như nhau. Một số dòng chỉ thay đổi nhãn màn hình. Một số dòng điều khiển phanh, cảm biến, thanh toán, nguồn điện hoặc cảnh báo. Tôi vạch ra những con đường đó sớm. Tôi hỏi đi hỏi lại một câu: điều gì xảy ra nếu dòng này không thành công trong cài đặt khách hàng? Câu hỏi đó nắm bắt được các vấn đề mà bài kiểm tra đơn vị bỏ sót. Một chức năng có thể trông ổn trên máy kiểm tra sạch nhưng vẫn bị lỗi khi dữ liệu đến muộn, khi cảm biến phát ra tiếng ồn hoặc khi thiết bị khởi động lại sau khi mất điện. Tôi xây dựng các bài kiểm tra xung quanh các trường hợp xấu, không chỉ là con đường hạnh phúc. Tôi kiểm tra đầu vào trống. Tôi kiểm tra giá trị tối đa. Tôi kiểm tra các gói bị hỏng. Tôi kiểm tra một mạng chậm. Tôi kiểm tra khởi động lại ở giữa một nhiệm vụ. Những trường hợp này cảm thấy nhàm chán trong quá trình phát triển. Chúng trông đắt tiền sau khi phát hành. Tôi nhớ một dự án trong đó cài đặt thời gian chờ đơn giản khiến thiết bị phải đặt lại nhiều lần tại hiện trường. Hệ thống phòng thí nghiệm không bao giờ cho thấy điều đó. Việc thiết lập khách hàng đã làm. Mã không lớn. Hiệu quả là. Khoảng trống đó là nơi bắt đầu thu hồi. Tôi sử dụng đánh giá mã để kiểm tra rủi ro chứ không phải kiểm tra kiểu. Một nhận xét đánh giá rõ ràng về khoảng cách sẽ giúp ích nhưng nó không lưu được sản phẩm. Tôi muốn người đánh giá đặt những câu hỏi khó hơn: - Điều gì xảy ra nếu thiếu giá trị này? - Điều gì xảy ra nếu cảm biến gửi sai phạm vi? - Điều gì xảy ra nếu bản cập nhật này đáp ứng được phần cứng cũ? - Điều gì xảy ra nếu cờ này được đặt nhầm? Tôi thích ít nhất một người đánh giá biết hoạt động của sản phẩm chứ không chỉ cú pháp mã. Kỹ sư QA, kỹ sư hiện trường hoặc trưởng nhóm hỗ trợ có thể phát hiện sự cố nhanh chóng. Họ biết khách hàng sử dụng sản phẩm như thế nào trong thế giới thực chứ không chỉ trong kế hoạch thử nghiệm. Tôi cũng giữ một nhật ký thay đổi mạnh mẽ. Khi bắt đầu thu hồi, các nhóm sẽ lãng phí hàng giờ để đặt những câu hỏi cơ bản. Phiên bản nào được vận chuyển? Lô nào đã sử dụng bản dựng này? Mẫu thiết bị nào có vấn đề? Bản sửa lỗi nào được đưa vào bản phát hành nào? Nếu tôi theo dõi phiên bản, thời gian xây dựng, nhóm thiết bị và kết quả kiểm tra ngay từ đầu, tôi có thể trả lời nhanh những câu hỏi đó. Tốc độ đó quan trọng. Nó có thể cắt giảm quy mô thu hồi và giảm số lượng đơn vị được chạm vào. Một kế hoạch khôi phục rõ ràng cũng quan trọng. Tôi không chờ đợi vấn đề xảy ra rồi mới nghĩ đến việc đảo chiều. Tôi muốn biết cách dừng phát hành, cách khôi phục phiên bản cũ và cách cảnh báo các nhóm hiện trường. Nếu bản dựng mới bắt đầu bị lỗi, tôi muốn có một đường dẫn đơn giản quay lại. Khôi phục chậm biến một lỗi phần mềm nhỏ thành một vấn đề kinh doanh rộng hơn. Tôi cũng thích bản phát hành thử nghiệm nhỏ trước khi triển khai đầy đủ. Nếu một thay đổi có thể ảnh hưởng đến nhiều thiết bị, trước tiên tôi sẽ gửi nó đến một nhóm giới hạn. Tôi xem nhật ký lỗi, phiếu hỗ trợ và hoạt động của thiết bị. Nếu phi công cho kết quả lạ, tôi dừng lại và kiểm tra. Việc tạm dừng đó có thể lưu toàn bộ lô. Các trường hợp công khai cho thấy tại sao điều này lại quan trọng. Các nhà sản xuất ô tô, công ty thiết bị y tế và các thương hiệu điện tử tiêu dùng đều phải đối mặt với việc thu hồi hoặc sửa lỗi liên quan đến phần mềm. Một số trường hợp xuất phát từ lỗi logic. Một số đến từ việc xử lý cảm biến. Một số đến từ lỗi cập nhật. Mô hình vẫn giữ nguyên. Mã trông ổn trong căn phòng nơi nó được viết. Cánh đồng đã kể một câu chuyện khác. Đó là lý do tại sao tôi không tin tưởng vào bảng điều khiển thử nghiệm màu xanh lá cây. Tôi muốn bằng chứng từ các trường hợp đặc biệt, theo dõi phát hành, ghi chú đánh giá và nhật ký hiện trường. Tôi muốn một nhóm xử lý các lỗi nhỏ như những rủi ro kinh doanh có thể xảy ra. Tôi muốn mọi người biết rằng một đường dây sai có thể trở thành một cuộc gọi của khách hàng, một lần ghé thăm dịch vụ hoặc một thông báo thu hồi. Khi tôi làm việc theo cách này, tôi nắm bắt được nhiều vấn đề hơn trước khi khách hàng nhìn thấy chúng. Mã trở nên an toàn hơn. Việc phát hành trở nên bình tĩnh hơn. Việc kinh doanh sẽ ít bất ngờ hơn.
Tôi đã thấy một lỗi mã nhỏ biến thành một tuần dài đối với một nhà máy. Một ngày đã hết một ngày. Số lô không khớp với bản ghi. Một dòng mực mờ và máy quét bỏ sót nó. Sản phẩm vẫn tiếp tục di chuyển nhưng lỗi vẫn được giấu kín cho đến khi đóng gói, vận chuyển hoặc khiếu nại của khách hàng mang sản phẩm trở lại. Đó là lý do tại sao tôi coi mọi máy mã hóa không chỉ là một chiếc máy in. Nó là một phần của việc kiểm soát sản phẩm. Nó giúp tôi duy trì khả năng truy xuất nguồn gốc rõ ràng, bảo vệ thương hiệu và giảm nguy cơ thu hồi liên quan đến dữ liệu mã xấu. Khi đi trên một dây chuyền, tôi chú ý đến những điểm khó khăn giống nhau nhiều lần: - Sai ngày hoặc mã lô - Bản in bị nhòe hoặc mờ - Mã đặt sai vị trí - Bản in bị thiếu trong quá trình sản xuất nhanh - Chỉnh sửa thủ công không khớp với bản ghi hệ thống - Không kiểm tra nhanh sau khi thay cuộn hoặc nạp mực. Tôi không coi những điều này là những vấn đề nhỏ. Các vấn đề nhỏ trên dây chuyền đóng gói có thể lan truyền nhanh chóng. Tôi từng chứng kiến một nhà máy sản xuất đồ ăn nhẹ dừng toàn bộ hoạt động vì mã trên một thùng carton không khớp với hồ sơ vụ án. Bản thân sản phẩm đã ổn. Mã là vấn đề. Nhóm phải phân loại hàng tồn kho, kiểm tra hồ sơ và xem xét từng ghi chú ca làm việc. Loại công việc đó cần có tiền bạc, thời gian và năng lượng. Nó cũng làm lung lay niềm tin trong đội. Cách tiếp cận của tôi rất đơn giản. Tôi xây dựng một quy trình kiểm soát ngắn gọn xung quanh máy và tuân thủ nghiêm ngặt. Tôi kiểm tra những điểm này hàng ngày: - Nội dung mã phù hợp với yêu cầu công việc - Bản in sắc nét và dễ đọc - Vị trí ổn định trên bao bì - Máy quét hoặc kiểm tra trực quan cho kết quả đọc rõ ràng - Mức mực, ribbon hoặc hộp mực vẫn nằm trong phạm vi - Cài đặt máy luôn bị khóa sau khi thiết lập - Người vận hành biết phải làm gì khi mã bị lỗi Tôi cũng muốn duy trì một quy tắc: nếu mã trông kỳ lạ, hãy dừng lại và kiểm tra ngay. Thói quen đó sẽ giúp bạn tránh được rất nhiều rắc rối. Mình cũng quan sát độ ăn khớp giữa máy và sản phẩm. Một máy mã hóa hoạt động tốt trên một gói có thể hoạt động kém trên một gói khác. Màng bóng, chai cong, thùng giấy đầy bụi và đường dây tốc độ cao đều tạo ra những kết quả khác nhau. Tôi không cho rằng cùng một thiết lập sẽ hoạt động ở mọi nơi. Tôi kiểm tra nó trên gói chính xác, tốc độ đường truyền chính xác và điểm đặt chính xác. Đối với các nhóm muốn kiểm soát tốt hơn, tôi thường đề xuất một quy trình đơn giản: - Đặt định dạng mã trước khi bắt đầu ca - In mẫu và so sánh với bản ghi - Kiểm tra các gói đầu tiên ở tốc độ dây chuyền - Kiểm tra lại sau bất kỳ lần tạm dừng, nạp lại hoặc thay đổi cuộn nào - Giữ nhật ký rõ ràng về các lỗi và cách sửa chữa - Đào tạo một người dự phòng theo các bước tương tự. Loại quy trình này có vẻ cơ bản và đó chính là điểm mấu chốt. Kiểm tra cơ bản phát hiện nhiều lỗi có thể phòng ngừa được. Tôi cũng tin rằng việc truy xuất nguồn gốc không nên phụ thuộc vào trí nhớ. Nếu một người vận hành thay đổi cài đặt và không ghi lại cài đặt đó thì người tiếp theo có thể kế thừa vấn đề. Nếu máy có công cụ xác minh thì mình dùng. Nếu đường dây cần kiểm tra camera, tôi sẽ giữ nó hoạt động. Nếu mã là một phần của gói được quản lý, tôi coi mọi lỗi đều là rủi ro thực sự chứ không phải là phiền toái nhỏ. Thiết lập mã hóa mạnh mẽ không chỉ in văn bản. Nó hỗ trợ hồ sơ sạch sẽ, gói hàng rõ ràng và quá trình kiểm tra suôn sẻ hơn. Nó giúp tôi bớt lo lắng hơn khi hàng hóa rời khỏi dây chuyền. Tôi không chờ đợi cơn sợ hãi thu hồi để cải thiện phần sản xuất này. Tôi khắc phục những điểm yếu trong khi đường dây vẫn chạy tốt. Đó là thói quen tôi tin tưởng nhất.
Tôi đã chứng kiến một lỗi mã hóa nhỏ trở thành vấn đề đau đầu trong quá trình sản xuất. Mã lô được in sai vị trí. Mã ngày bị mờ sau khi đóng gói. Một nhãn bỏ qua một dòng và không ai phát hiện ra nó cho đến khi các thùng carton đã được đặt trên pallet. Đó là nơi rủi ro thu hồi bắt đầu đối với tôi. Không phải với một sự kiện kịch tính. Nó bắt đầu với sự hỗn loạn nhỏ trên máy mã hóa, sau đó dòng tiếp tục di chuyển và lỗi lan rộng. Khi nhìn vào một nhà máy bận rộn, tôi thường thấy mô hình tương tự: Máy mã hóa đang chạy nhưng bản in không ổn định. Người vận hành thay đổi cài đặt theo cảm nhận. Những ca làm việc khác nhau sử dụng những thói quen khác nhau. Việc bảo trì chỉ được tiến hành sau khi xuất hiện lỗi. Hồ sơ nằm rải rác nên việc truy xuất nguồn gốc trở nên chậm chạp. Tôi không thấy một vấn đề lớn. Tôi thấy nhiều khoảng trống nhỏ có thể tăng lên nhanh chóng. Điều tôi tập trung đầu tiên chính là mã. Tôi kiểm tra xem bản in có rõ ràng, đúng chỗ và dễ đọc hay không. Tôi kiểm tra xem máy có sử dụng cùng định dạng trên toàn dòng hay không. Tôi kiểm tra xem số lô, dữ liệu lô và mã ngày có khớp với hồ sơ sản phẩm hay không. Nếu mã khó đọc thì rủi ro đã cao hơn. Nếu mã sai, sản phẩm có thể được chuyển qua khâu đóng gói, lưu kho và vận chuyển trước khi có người nhận ra. Một nhà máy sản xuất đồ ăn nhẹ mà tôi đến thăm cũng gặp phải vấn đề này. Bộ mã hóa máy in phun nhìn thoáng qua có vẻ ổn, nhưng bản in bị trôi khi chạy tốc độ cao. Một ca đã điều chỉnh nó. Ca tiếp theo lại điều chỉnh lại. Đến cuối tuần, cùng một dòng sản phẩm có ba vị trí mã và hai cỡ chữ. Nhà máy không thất bại chỉ vì một chiếc máy. Nó thất bại vì không ai sở hữu tiêu chuẩn đó. Đó là lý do tại sao tôi thích một cách tiếp cận đơn giản. Tôi bắt đầu với cài đặt máy. Tôi khóa ở một định dạng mã. Tôi lưu một bố cục đã được phê duyệt. Tôi loại bỏ phỏng đoán khỏi những thay đổi thường ngày. Sau đó tôi nhìn vào dòng đó. Nếu tốc độ băng tải thay đổi nhiều thì người lập trình cần theo kịp. Nếu đầu in bị bẩn, đầu ra sẽ giảm. Nếu giá đỡ rung chuyển, mã sẽ dịch chuyển. Nếu cuộn nhãn nạp không đều, bản in có thể trượt mục tiêu. Đây không phải là những vấn đề hiếm gặp. Tôi đã nhìn thấy chúng trong các nhà máy thực phẩm, bao bì dược phẩm và các dòng hàng hóa thông thường. Sản phẩm thì khác, nhưng rủi ro thì giống nhau. Bước tiếp theo của tôi là kiểm tra. Tôi không dựa vào một cái nhìn từ một nhà điều hành. Tôi xây dựng một kiểm tra dễ lặp lại. Việc kiểm tra tốt có thể rất đơn giản: - đọc mã khi khởi động - kiểm tra lại sau khi chuyển đổi - kiểm tra trong quá trình bàn giao ca - so sánh mã với lệnh sản xuất - giữ lại bất kỳ mặt hàng nào có bản in xấu. Loại công việc này không tốn nhiều công sức. Nó mang lại cho nhóm một thói quen rõ ràng và giúp phát hiện lỗi trước khi thùng carton rời khỏi dây chuyền. Vấn đề đào tạo cũng vậy. Tôi đã gặp những người điều hành có tay nghề cao, cẩn thận nhưng vẫn mắc kẹt với những thói quen cũ. Họ làm việc rất nhanh. Họ quan tâm đến đầu ra. Không phải lúc nào họ cũng biết sự thay đổi nhỏ nào có thể gây ra vấn đề về truy xuất nguồn gốc. Vì vậy tôi tiếp tục đào tạo thực tế. Tôi cho thấy một mã tốt trông như thế nào. Tôi cho thấy một bản in yếu trông như thế nào. Tôi giải thích cách một chữ số bị thiếu có thể làm chậm quá trình kiểm tra kho hàng, yêu cầu của khách hàng hoặc việc giữ sản phẩm. Tôi giữ bài học gắn liền với công việc hàng ngày chứ không phải lý thuyết. Bảo trì cần loại kỷ luật tương tự. Tôi thích làm sạch theo kế hoạch, kiểm tra theo kế hoạch và thay thế bộ phận theo kế hoạch. Không phải vì tôi muốn có thêm giấy tờ. Bởi vì một cỗ máy mã hóa thường bị lỗi một cách thầm lặng trước khi nó dừng hẳn. Đầu in bị mòn, mực thấp, cảm biến lỏng, vòi phun bị tắc hoặc đường dẫn nạp yếu có thể bị ẩn cho đến khi đường dây chịu áp lực. Đó là lúc sai lầm lan rộng. Nếu tôi đang sửa một dòng ngay bây giờ, tôi sẽ sử dụng thứ tự này: - xem lại định dạng mã hiện tại - kiểm tra chất lượng in ở tốc độ chạy tối đa - làm sạch và hiệu chỉnh bộ mã hóa - xác minh dữ liệu sản phẩm và lô trước khi phát hành - đặt quy tắc lưu giữ rõ ràng đối với các bản in xấu - ghi nhật ký ngắn gọn cho mọi lỗi và sửa chữa Đây không phải là công việc hào nhoáng. Đó là công việc ổn định. Tôi thích như vậy, vì công việc ổn định sẽ bảo vệ sản phẩm và bảo vệ nhóm. Những dòng tốt nhất mà tôi từng thấy làm tốt một điều: chúng làm cho mã phù hợp trở nên dễ sản xuất và dễ kiểm tra. Đó là điểm quan trọng đối với tôi. Khi sự hỗn loạn của máy mã hóa vẫn tiếp diễn, rủi ro thu hồi sẽ nhỏ hơn. Khi dây chuyền có cài đặt rõ ràng, thiết bị sạch sẽ và quy trình kiểm tra đơn giản, nhóm sẽ di chuyển tự tin hơn. Và sự tự tin đó thể hiện ở gói cuối cùng, nơi nó quan trọng nhất.
Tôi đã thấy vấn đề tương tự nhiều lần ở các sàn sản xuất. Một lỗi máy mã hóa nhỏ bắt đầu bằng một vết nhòe nhẹ, thiếu mã lô hoặc ngày in sai vị trí. Dòng tiếp tục di chuyển. Vấn đề có vẻ nhỏ. Sau đó, chi phí xuất hiện trong việc làm lại, phế liệu, khiếu nại của khách hàng, giữ lại và mất lòng tin. Đó là phần mà nhiều đội bỏ lỡ. Máy móc không cần phải hỏng hóc nghiêm trọng mới tạo ra tổn thất lớn. Một lỗi thầm lặng có thể lan rộng ra toàn bộ lô trước khi có người nhận ra. Tôi viết từ quan điểm đó bởi vì tôi đã chứng kiến những người vận hành làm đúng mọi thứ nhưng vẫn xử lý được một bản in lỗi. Máy đã bật. Sản phẩm đang di chuyển. Mã trông “đủ gần” từ xa. Thế là đủ để tạo ra một vấn đề. Điều tôi tập trung vào rất đơn giản: phát hiện lỗi sớm, giữ cho đường dây dễ kiểm tra và làm cho máy dễ tin cậy hơn. Máy mã hóa có thể bị lỗi theo một số cách phổ biến. Đầu in có thể bị bẩn. Mực có thể sắp hết. Cài đặt có thể không khớp với sản phẩm. Cảm biến có thể bỏ sót gói hàng. Định dạng ngày tháng có thể sai. Mã có thể được in nhưng không đặt đúng chỗ. Mỗi vấn đề có thể trông nhỏ khi bắt đầu. Mỗi người có thể biến thành một hóa đơn lớn hơn nếu không ai kiểm tra nhanh. Tôi luôn bắt đầu với cùng một thói quen: làm cho mã dễ xác minh. Nếu người vận hành phải đoán xem mã có đúng hay không thì đường dây đó đã có điểm yếu. Tôi thích đặt một bước kiểm tra rõ ràng gần máy. Một công nhân kiểm tra chất lượng in khi bắt đầu chạy. Một lần kiểm tra khác diễn ra sau khi chuyển đổi. Một bản đánh giá mẫu ngắn trong ca làm việc cũng có ích. Một dây chuyền làm bánh mà tôi làm việc xung quanh cũng gặp phải vấn đề này. Mã ngày in trên túi nhưng vị trí bị lệch sau khi thay cuộn. Bản in vẫn có thể đọc được nên vấn đề này đã bị bỏ sót trong một thời gian. Bản sửa lỗi không phải là một sự thay đổi lớn về hệ thống. Nhóm đã thêm một dấu hiệu trực quan đơn giản và kiểm tra 30 giây sau mỗi lần đổi lượt. Số lần bỏ lỡ giảm nhanh. Cách khắc phục đó có tác dụng vì nó mang lại cho người vận hành một mục tiêu rõ ràng. Tôi cũng giữ cho việc bảo trì đơn giản và thường xuyên. Một cỗ máy mã hóa cần được chăm sóc trước khi nó trông mệt mỏi. Tôi kiểm tra: làm sạch đầu in các kết nối cáp chắc chắn, mức mực hoặc ruy băng chính xác cài đặt áp suất hoặc nhiệt ổn định làm sạch cảm biến hướng dẫn sản phẩm chặt chẽ Khi các đội bỏ qua những bước kiểm tra này, họ thường đổ lỗi cho máy sau khi hư hỏng xảy ra. Tôi thích coi việc bảo trì như một phần của quá trình chạy chứ không phải là một công việc riêng biệt. Một danh sách kiểm tra ngắn gần dòng sẽ hiệu quả hơn một bản hướng dẫn dài mà không ai đọc. Vấn đề đào tạo cũng vậy. Tôi đã chứng kiến các đội thua lỗ vì một người vận hành mới không biết mã xấu trông như thế nào trên chính chiếc máy đó. Bản in mỏng nhưng vẫn nhìn thấy được. Trưởng ca nghĩ rằng nó ổn. Khách hàng thì không. Tôi tiếp tục tập luyện đơn giản. Tôi chỉ cho nhóm biết thế nào là “tốt”, thế nào là “xấu” và phải làm gì khi bản in thay đổi. Tôi cũng yêu cầu họ dừng xếp hàng khi cảm thấy không chắc chắn. Bước đó có thể cảm thấy nhỏ nhưng nó bảo vệ cả lô. Một trường hợp thực sự từ một nhà đóng gói thực phẩm đã ở lại với tôi. Nhóm đã thay đổi kích thước sản phẩm trong ngày. Một máy giữ nguyên vị trí nhãn cũ sau khi thay đổi. Người điều hành nhìn thấy một sự thay đổi nhỏ và tạm dừng dây chuyền. Việc tạm dừng đó đã cứu toàn bộ các gói bị dán nhãn sai. Cách khắc phục là kiểm tra cài đặt được thêm vào bảng chuyển đổi. Không có kịch. Không có phỏng đoán. Tôi cũng nghĩ rằng việc xem xét dữ liệu nên là một phần của quá trình. Nếu máy cứ mắc lỗi tương tự, tôi không muốn đợi đến một lỗi lớn hơn. Tôi nhìn vào mẫu: Lỗi có xuất hiện sau khi khởi động không? Nó có xảy ra ở ca này nhiều hơn ca khác không? Nó có xuất hiện sau khi làm sạch không? Nó có tuân theo một kích thước sản phẩm không? Nó có xảy ra ở gần cuối chu kỳ mực không? Các mẫu nhỏ có thể chỉ ra nguyên nhân thực sự. Điều đó tiết kiệm cả thời gian và lãng phí. Bố trí tốt xung quanh máy cũng giúp ích. Nếu vùng mã khó tiếp cận, mọi người sẽ bỏ qua việc kiểm tra. Nếu màn hình khó đọc, mọi người sẽ bỏ lỡ cảnh báo. Nếu các công cụ được lưu trữ ở xa, phản hồi sẽ chậm lại. Tôi thích một trạm sạch sẽ, nhãn rõ ràng và cách thiết lập cho phép người vận hành hành động không chậm trễ. Quan điểm của tôi rất đơn giản: máy móc phải giúp công nhân nắm bắt được vấn đề chứ không phải che giấu nó. Đó là lý do tại sao tôi thích những tiêu chuẩn có thể nhìn thấy được. Một mẫu mã đúng gần máy. Một danh sách kiểm tra ngắn ngang tầm mắt. Một bức ảnh rõ ràng của một bản in bị từ chối. Một quy tắc đơn giản cho những khoảnh khắc dừng lại và kiểm tra. Những công cụ nhỏ này trông không có gì lạ mắt. Họ làm việc vì họ phù hợp với công việc. Tôi cũng nghĩ các nhóm nên xem xét lại chi phí của một lần chạy mã bị thiếu ở dạng số đơn giản. Phế liệu tốn tiền. Làm lại tốn nhân công. Khách hàng trả lại có giá cao hơn. Việc giữ lại lô hàng có thể ảnh hưởng đến toàn bộ lịch trình. Một khoản lỗ lớn thường bắt đầu bằng một tấm séc nhỏ bị bỏ sót. Khi một nhóm nhìn thấy mối liên kết đó, thói quen sẽ thay đổi. Nếu tôi phải giảm điều này thành một cách tiếp cận thực tế, tôi sẽ sử dụng cách này: Kiểm tra máy trước khi chạy. Kiểm tra mã khi khởi động. Kiểm tra lại sau khi thay đổi. Giữ khu vực in sạch sẽ. Đào tạo nhóm về tiêu chuẩn mã chính xác. Theo dõi các lỗi lặp lại và sửa lỗi theo khuôn mẫu chứ không chỉ là triệu chứng. Đó là cách tôi giữ cho một vấn đề mã hóa nhỏ không phát triển thành một vấn đề lớn. Tôi đã học được rằng cách bảo vệ tốt nhất không phải là sự sợ hãi. Đó là thói quen. Khi dây chuyền có các bước kiểm tra rõ ràng, dụng cụ sạch sẽ và một nhóm biết rõ những gì cần xem, máy sẽ trở nên dễ quản lý hơn. Rủi ro không biến mất nhưng vẫn nằm trong tầm kiểm soát. Liên hệ với chúng tôi trên wzsanying: 780877550@qq.com/WhatsApp 13858841904.
Tổ chức Tiêu chuẩn hóa Quốc tế 2015 Yêu cầu về Hệ thống Quản lý Chất lượng ISO 9001 Cục Quản lý Thực phẩm và Dược phẩm Hoa Kỳ 2022 Điều tra và Ngăn chặn Thu hồi Thiết bị Y tế W Edwards Deming 1986 Thoát khỏi Khủng hoảng James R Evans và William M Lindsay 2020 Quản lý Chất lượng và Hiệu suất Xuất sắc Paul R Crosby 1979 Chất lượng là miễn phí
Gửi email cho nhà cung cấp này