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

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

Сводный план действий (для описанной в главе 15 ситуации с уборками на участке распиловки древесины) представлен на рис. 17-1. Заметьте, что план не слишком подробен и содержит только данные о распределении обязанностей между членами команды. Такой уровень детализации достаточен для анализа данной работы. Ведь если желаемые результаты достигнуты, значит, план хорогй и вдаваться в подробности просто нет нужды. (Так же, как не нужно проверять ход рассуждений, который позволил достичь желаемых результатов.)

ДействияКраткосрочные/ДолгосрочныеОтветственныйГрафик
Неделя 1Неделя 2Неделя 3Неделя 4
Временная уборка во время перерывов и в обедКСМ.Скарпеллод
Прикрепить к станкам липкой лентой коробки для сбора мусораКСД.Дэнисд
Сократить время ходьбы — изменить местоположение запаса материала и зоны проверкиДСД. Шписсо—д
Перенести пусковую кнопку в другое местоДСМ. Киссело—д
Создать вокруг столов защитное ограждение, что сократит трудоемкость уборкиДСМ. НиколсонО—д
Оснастить станок коробом для сбора пылиДСП.Кенрико—к-----Д
Оснастить 4 станка пылеуловителями (по 1 станку в неделю)ДСБ. КонстантинеО X.
Условные обозначения: Начало О Окончание Д Проверка X

Рис. 17-1. Сводный план действий

ДЕЛАЙ: ВНЕДРЕНИЕ РЕШЕНИЙ

Наконец можно что-то сделать! Вы почти у финишной черты. И все же вы рискуете так и не добраться до финала, так как после реализации решения вы можете увидеть новые возможности совершенствования. Этот феномен связан с тем, что пока не сделаны первые шаги, дальнейшие возможности не всегда очевидны. Представьте, что перед вами лестница. Если вы смотрите вперед (прямо), вы видите лишь ступеньки. Поднявшись повыше, вы можете увидеть площадку. Это постоянное восхождение, в ходе которого перед вами постепенно открываются новые перспективы, и есть процесс непрерывного совершенствования (см. рис. 20-8).

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

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

ПРОВЕРЯЙ: КОНТРОЛЬ РЕЗУЛЬТАТОВ

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

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

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

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

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

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

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