Читаем Практика дао Toyota полностью

Проверить подобным образом собственную работу может каждый. Это можно сделать, снимая деталь со станка или передавая ее на следующую операцию, поскольку заранее известно, на что обращать особое внимание. Для важных операций или для операций, на которых часто возникают проблемы, используется прием, который называется ёси. (Так во время предполетной проверки пилот произносит слово «готово».) Стандарт требует, чтобы по завершении задачи оператор указал на деталь пальцем (да-да, в буквальном смысле слова!) и произнес «ёси», что означает: «Я проверил эту деталь». Для лидера это служит визуальным сигналом о том, что проверка выполнена (что помогает ему следить за выполнением стандартизированной работы). Если бы оператор просто осматривал деталь, понять, следует ли он инструкциям по проверке, было бы невозможно. К тому же, указывая на деталь, оператор совершает сознательное действие, тем самым подключая к работе интеллект. Ёси снижает вероятность того, что проверка будет пропущена. Подобным образом, если на деталь можно наносить цветовую маркировку, все важные участки при проверке помечаются цветным маркером. Процесс, предусматривающий физическое действие, помогает не пропустить важных вещей.

Разумеется, одна из главных задач остановки линии — предупредить передачу дефектного изделия на следующие операции. Даже при наличии развитой системы поддержки приучить людей придерживаться этого принципа очень и очень непросто. Люди неохотно признают свою несостоятельность и ошибки. Одно из важных преимуществ работы небольшими партиями заключается в том, что, если дефект остался незамеченным на одном рабочем месте, а операторы на следующих этапах проверяют поступающую работу, цикл обратной связи, т. е. отрезок времени от момента возникновения проблемы до ее обнаружения на одной из последующих операций, будет коротким. При традиционном производстве крупными партиями продолжительность цикла обратной связи может составлять неделю и более.

ПОДСКАЗКА

Не вводите правила, которые невозможно соблюдать

Этот совет полезен во многих ситуациях, но в данном случае речь идет о принципе никогда не передавать заведомо дефектную продукцию на следующий процесс. Мало просто сказать людям, что этого делать нельзя. Что делать, если дефект обнаружен? Кого нужно позвать? Куда положить дефектное изделие? Если эти вопросы не решены, неизбежна неразбериха и конфликты. Если люди хотят поступить правильно и выполнить инструкцию, но соблюсти правило и выполнить работу надлежащим образом невозможно, они предпочтут выполнить работу, нарушив правило. Понаблюдайте, что происходит. Выполните данную операцию самостоятельно, чтобы получить о ней исчерпывающее представление. Не следует думать, что люди нарушают правила, потому что им не важен результат. Не исключено, что система, которая помогает соблюдать эти правила, отсутствует.

ПОКА-ЁКЭ

Предупредить ошибки оператору помогает использование методов и устройств пока-ёкэ. Обычно этот термин переводится как «предупреждение ошибок» или «предупреждение отклонений». Предупреждение ошибок представляет собой не только и не столько инструмент бережливого производства, сколько образ мышления и отношение к проблемам. Такой подход основан на утверждении, что, хотя люди не совершают ошибки и не отклоняются от стандарта нарочно, они тем не менее могут возникать.

Люди на Toyota совершенно иначе смотрят на причины возникновения ошибок, чем в других компаниях. В компаниях, с которыми мы работали, все единодушно соглашались с утверждением «люди совершают ошибки», но при этом были столь же единодушно убеждены в том, что «если бы люди были внимательнее, они не совершали бы так много ошибок». Принято считать, что «человеку свойственно ошибаться». В Toyota исходят из того, что ошибка свидетельствует о несостоятельности систем и методов, применяемых для выполнения работы. Ошибки случаются потому, что существующий метод допускает их возникновение!

Перейти на страницу:

Похожие книги

Философия DevOps
Философия DevOps

IT-принцип «agile» стал мантрой цифровой эпохи. С ростом проектов, переходом от монолитных приложений к системе микросервисов, увеличением и накоплением продуктов возникают вопросы, которые требуют совершенно иного подхода. Теперь наибольший интерес вызывает находящаяся на стыке разработки и операционного управления методология DevOps.DevOps – это не просто набор техник, это философия. Разработчики, зацикленные на пользователях, должны уделять внимание поддержке и ее запросам. Сисадмины должны сообщать о проблемах продукта и вносить свой вклад в улучшение процесса работы. Но налаживание связей внутри компании – это лишь первый шаг. Чтобы продукт стал простым и удобным, придется вложить время и ресурсы в его доработку. Конфигурация через центральную службу, внедрение простым копированием, отсутствие внешних зависимостей, обдуманные метрики вместо мусора в логах – вот лишь часть задач, которые придется решать на этом пути.Книга «Философия DevOps» познакомит вас с техническими, культурными и управленческими аспектами devops-культуры и позволит организовать работу так, чтобы вы получали удовольствие от разработки, поддержки и использования программного обеспечения.

Дженнифер Энн Дэвис , Кэтрин Дэниелс

Деловая литература