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

«Но если стандартизированная работа — основа непрерывного совершенствования, почему не начать прямо с нее?» — спросите вы. Это хороший вопрос. В Toyota подчеркивают, что, для того чтобы приступить к стандартизации, необходим ряд предпосылок. Обычно они создаются на этапе стабилизации, но если вы из тех, кто норовит отставить в сторону закуску и немедленно приступить к основному блюду, и возьметесь за стандартизацию работы, не обеспечив стабильности, вы уподобитесь собаке, которая пытается поймать собственный хвост, — вы будете крутиться на одном месте и никогда не добьетесь желаемого результата.

Предпосылки стандартизированной работы

Прежде чем приступать к стандартизации, необходимо обеспечить определенный уровень стабильности. К сожалению, не существует однозначных критериев, которые позволяют сказать: «Теперь вы готовы к стандартизации работы». Можем лишь заметить, что, если вы ощущаете себя собакой, которая пытается поймать собственный хвост, уровень стабилизации процесса недостаточен, для того чтобы браться за стандартизацию. Итак, что нужно для обеспечения базовой стабильности?

1. Рабочая операция должна повторяться. Если при описании работы используются выражения «если... то», стандартизация невозможна. Например, если формулировка рабочего задания содержит оговорки вроде: «Если случится А, делай В, а если произойдет С, делай D», стандартизации не получится, пока такое описание не сменят несколько простых, четких правил.

2. Линия и оборудование должны быть надежными, а время простоев — минимальным. Если процесс постоянно прерывается, а работник вынужден отвлекаться, стандартизация невозможна.

3. Не должно быть значительных проблем с качеством. Продукт должен иметь минимум дефектов, а его основные характеристики должны быть единообразными. Если работник постоянно занят исправлением дефектов или то и дело сталкивается с проблемами, вызванными недостаточным единообразием продукта, например вариацией размера, которая заставляет заниматься подгонкой детали, а следовательно, порождает вариацию времени выполнения операции, увидеть подлинную картину работы невозможно.

ЛОВУШКА

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

ДОКУМЕНТАЦИЯ НА СТАНДАРТИЗИРОВАННУЮ РАБОТУ

В процессе стандартизации работы используются три основных и вспомогательных документа. В задачи этой книги 'не входит подробный рассказ об использовании каждого из этих документов, однако мы считаем нужным остановиться на трех основных:

1. Карта стандартизированной работы.

2. Таблица совмещения стандартизированных работ9.

3. Ведомость производительности процесса.

Карта стандартизированной работы

Изначально этот документ представлял собой схему рабочей зоны и перемещений работника. Вербальное описание метода работы и время выпол-

нения отдельных операций отсутствовали. Время выполнения отдельных операций фиксировалось в отдельном документе — таблице совмещения стандартизированных работ. По ходу дела на многих операциях карта стандартизированной работы и таблица совмещения стандартизированных работ объединялись в один упрощенный документ, который часто называют

Рис. б-б. Таблица совмещения стандартизированных работ при наличии одного автомата

(по крайней мере, за пределами Toyota) «ведомостью стандартизированной работы» или «картой стандартизированной работы».

Первоначально ведомость стандартизированной работы использовалась как инструмент выявления и устранения потерь. После внесения изменений базой для дальнейшего совершенствования становится новый метод. Ведомость стандартизированной работы вывешивается на рабочем месте и служит средством визуального контроля, обращаясь к которому менеджмент проверяет соблюдение стандарта.

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

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

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

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

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

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