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

Определение и контроль объема незавершенного производства на каждой операции позволили снизить диапазон колебаний времени производственного цикла, а дальнейшее сокращение этого объема будет способствовать снижению общей продолжительности цикла. Результаты представлены на рис. 4-9. Хорошо видно, что общее время производственного цикла процесса теперь устойчиво приближается к 15 дням, и в этом отношении процесс «стабилен». Поскольку базовый уровень стабильности обеспечен, данный поток создания ценности готов к дальнейшим преобразованиям в рамках цикла непрерывного совершенствования.

ВЫРАВНИВАНИЕ ОБЪЕМА РАБОТ — ФУНДАМЕНТ ДЛЯ ПОТОКА И СТАНДАРТИЗАЦИИ

Как мы уже видели в примере, приведенном выше, группировка продукции для изолирования вариации — важнейший этап обеспечения стабильности и фундамент создания потока и стандартизации. В сущности, такое изолирование — простейший пример применения метода хейдзунка или выравнивания. Группируя похожие продукты, мы сумели выровнять объем работ для большей части процесса. Данную работу с высокой вариабельностью по-прежнему трудно стандартизировать, однако теперь это возможно в 80% случаев. Это важный аспект обеспечения стабильности. На этапе стабилизации возможно применение простейших принципов выравнивания, наряду с этим существуют более продвинутые методы хейдзунка, которые постепенно ужесточают режим и интенсивность работы системы на более поздних этапах. (Подробнее мы поговорим об этом в главе 7.)

Одна из распространенных ошибок — попытка слишком поспешно приступить к созданию потока и стандартизации. Как будет показано в

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

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

Вопросы для самопроверки

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

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

Б. Если вам не удалось выявить 50 примеров потерь, пройдите процесс вновь, не спеша наблюдая за происходящим (при необходимости повторите обход еще раз).

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

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

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

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

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

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

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