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

Этот дисбаланс является основной причиной, по которой операторы отклоняются от правила «никаких партий». Если операторы отклоняются от изначального плана, это явно свидетельствует о несостоятельности плана. К сожалению, обычно в таких случаях менеджмент пытается заставить подчиненных следовать правилам и поддерживать поток, вместо того чтобы остановиться и осмыслить недостатки процесса. Учитесь воспринимать отклонения, допущенные оператором, как позитивное явление! Остановитесь, понаблюдайте и выявите подлинную причину проблемы. Ее устранение пойдет процессу на пользу.

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

секунду в течение рабочего цикла — полсекунды, чтобы взять деталь, полсекунды, чтобы положить ее. Получаем секунду лишних движений в течение цикла. Если продолжительность рабочего цикла пять секунд, одна секунда, потраченная на перемещение материала, составляет 20% общего времени цикла! Если операция осуществляется за 3 секунды, этот показатель превысит 30%. Это огромный процент потерь. Однако такие потери часто упускаются из виду, поскольку считается, что раз материал перемещается потоком, а операторы непрерывно движутся, перед нами бережливое производство. Как видите, это совсем не так.

Данную операцию можно усовершенствовать, не разбивая работу на множество разных операций в попытках создать поток, а поставив на нее двух операторов, которые будут брать деталь и обрабатывать ее от начала и до конца. За счет этого время сократится на две секунды, и в результате работа будет выполнена за 11 секунд (рис. 5-3). Чистое время, затраченное на обработку одного изделия, составляет 5,5 секунды (два человека, работая одновременно, производят два изделия каждые 11 секунды, 11 разделить на 2 = 5,5 секунды на единицу продукции), что превышает время такта на 0,5 секунды. Следующим шагом будет сокращение прочих потерь и упрощение операции, что позволит выполнять ее за 10 секунд или быстрее и обрабатывать единицу продукции за 5 или менее секунд.

В данном примере создание потока привело к снижению производительности на 33% (три операции вместо двух). К тому же в масштабах всего потока создания ценности данная операция была малой толикой общего материального потока. Существовали куда более широкие возможности создания потока и снижения общего времени производственного цикла за счет связывания операций на других участках с использованием методов вытягивания, описанных ниже.

ВЫТЯГИВАНИЕ

Термины «вытягивание» или «система вытягивания» часто путают с «потоком». Следует уяснить, что вытягивание, как и поток, представляет собой концепцию. Эти две концепции связаны между собой, но означают не одно и то же. Поток — это состояние материала при перемещении с одной операции на другую. Вытягивание определяет, когда происходит перемещение материала и кто (потребитель) диктует необходимость этого перемещения.

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

1. Определенность. Наличие четкой договоренности между поставщиком и потребителем, которое задает предельные значения объема выпуска, ассортимент и последовательность выпуска.

2. Закрепление. Объекты, которыми совместно пользуются две названные стороны, должны быть закреплены за ними. Это касается ресурсов, местоположения, хранилищ, контейнеров и т.д., а также общей отметки времени (время такта).

3. Контроль. Простые методы контроля с помощью визуального оповещения и физических ограничений в соответствии с договоренностью.

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

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

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

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

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

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

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