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

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

ПРОБЛЕМЫ РАЗРАБОТКИ ПРОЦЕДУРЫ СТАНДАРТИЗИРОВАННОЙ РАБОТЫ

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

К примеру, задачей оператора может быть сборка какого-либо изделия. При этом он сам подбирает и доставляет необходимые материалы и подает готовые изделия на следующую операцию. Сборка изделия является относительно единообразной работой, которую несложно задокументировать, но как быть с остальными видами работ? Они осуществляются непоследовательно, иногда однократно в течение нескольких циклов. Как соединить эти два абсолютно разных вида работ в ведомости стандартизированной работы? Обычно это попросту невозможно. Элементы работы, необходимые для сборки продукта, добавляют ценность и подлежат стандартизации. Как правило, операторы в Toyota не занимаются ни подбором материала, ни транспортировкой готовой продукции, поскольку эти виды деятельности отвлекают от работы по добавлению ценности. Транспортировкой материалов и деталей занимается другой работник, например транспортный рабочий, и его работу стандархизуют отдельно.

В главах 4 и 5 мы рассказывали о необходимости изолировать вариацию, чтобы обеспечить возможность стандартизации. Следующий пример иллюстрирует сложности при стандартизации работы, которой присуща высокая вариация. Общее правило: сначала изолировать вариацию и лишь потом приступать к стандартизации.

Конкретная ситуация: три задачи на одном рабочем месте

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

Первая операция состоит в проверке качества и обслуживании станка (удаление металлической стружки и перемещение готовой продукции). Оператору приходится регулярно осматривать некоторое количество деталей. Такие проверки представляют собой повторяемую операцию, которая выполняется каждый час (стандартное время цикла).

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

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

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

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

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

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

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

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

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