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

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

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

На большинстве производственных предприятий, использующих поток единичных изделий, между рабочими^ местами помещается одно изделие, и, таким образом, незначительная вариация времени цикла отдельного рабочего не порождает ожидания. Однако даже на таком уровне сбалансированность времени цикла отдельных операций должна быть чрезвычайно высока. Наличие между операциями дополнительных изделий позволяет работать и с более высокой вариацией времени цикла на разных операциях, однако такой подход ведет к росту перепроизводства, представляющего собой потери. Это настоящая головоломка. Уменьшение буферных запасов между операциями снижает перепроизводство, но повышает потери из-за несбалансированности рабочих циклов.

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

ПОДСКАЗКА

Когда проблема — не проблема?

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

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

ВАЖНЕЙШИЕ КРИТЕРИИ НАЛИЧИЯ ПОТОКА

Как мы уже говорили в предыдущей главе, для создания бесперебойного потока необходим ряд условий. Обычно соответствие этим критериям обеспечивается на этапе стабилизации, и все же мы повторим их еще раз.

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

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

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

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

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

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

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