Стандартизированная работа и визуальный менеджмент

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

Философия стандартов и постоянного совершенствования

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

Генри Форд был великим учителем, у которого они много переняли. К сожалению, сама Ford Motor Company последние десятилетия не использовала идеи Генри Форда. Одно из важных наблюдений Генри Форда касалось стандартизации, которая, как вы знаете, может привести к формализму, бюрократии, нескончаемым томам процедур, которые на деле никем не соблюдаются, а если соблюдаются, то часто скорее тормозят работу, чем способствуют ей.

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

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

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

Безусловно, мы можем развивать как хорошие, так и плохие привычки. Стандартизированная работа направлена на формирование правильных привычек. Она включает в себя постоянство направления, когда при выполнении любой задачи у человека есть четкое понимание цели. Мы хотим добиться стабильной результативности. Кто бы ни выполнял конкретную задачу, он должен обеспечивать высочайшее качество и с ожидаемой производительностью, чтобы мы могли выполнять требования клиента с высокой степенью предсказуемости.

Генри Форд сказал: «В конце пути, когда у нас есть стандарт и люди его выполняют, но мы видим, что есть идея лучше, мы меняем стандарт. Так мы добиваемся постоянного поиска лучшего решения, и именно это ведет к постоянному совершенствованию».

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

Стандартизированная работа в повторяющихся задачах и процессах

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

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

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

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

Есть другой документ, о котором я расскажу чуть позже, в шестой главе — разбивка рабочего процесса на элементы (или список элементов работы), в котором мы разбиваем шаги на микроскопические подшаги и в каждом подшаге описываем, как можно наилучшим из известных нам способом выполнить этот шаг. Например, если мы тянемся за инструментом, должны ли мы тянуться левой или правой рукой? Должны ли мы держать инструмент определенным образом, чтобы не повредить запястье? Эти ответы станут ключевыми моментами для оператора и будут использоваться во время обучения. Эти более детальные шаги, по сути рабочие движения, а также их обоснование, станут основой для обучения рабочих. Коротко об этом вы можете прочесть в нашей книге «Корпоративная культура Toyota», а более детальное объяснение есть в книге «Талантливые сотрудники: Воспитание и обучение людей в духе дао Toyota».

Стандартизированный рабочий документ для нецикличной работы

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

В таком случае используется стандартизированный рабочий документ для нецикличной работы (рис. 3.3), который не описывает повторяющуюся схему операций и не требует четкого описания последовательности шагов. Порядок выполнения операций не имеет значения, но я должен выполнить все шаги правильно или по крайней мере проверить все критичные параметры заданий. В этом смысле документ может выполнять роль чек-листа. Может также случиться, что какая-либо операция не относится к выполняемому мной заданию, и тогда я поставлю отметку «Не относится к делу». Ключевые моменты служат своеобразным напоминанием «убедись, что ты обратил на это внимание». Например, когда вы используете степлер, держите его левой рукой у основания, а правой рукой надавливайте.

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

Два вида бюрократии: принуждающая и разрешающая

В дополнение к стандартизированной работе есть и другие виды стандартов. Например, металлическая деталь после машинной обработки должна соответствовать стандарту, в котором указан допуск по диаметру отверстия: плюс или минус один миллиметр. У нас может быть стандарт результативности, который обязывает каждого торгового представителя совершить минимум 15 холодных звонков в день. Другим стандартом может быть цель для отдела закупок по сокращению затрат на 1% в квартал.

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

Профессор Университета Южной Калифорнии Пол Адлер изучал NUMMI, совместное предприятие Toyota и General Motors. Он ожидал плоскую организационную структуру с минимальной бюрократией, но увидел обратное. Он с удивлением обнаружил, что там были стандарты для всего. Подходишь ли ты к оператору, идешь ли по офису, заходишь ли в отдел проектирования — везде на стенах висят разные типы стандартов. Стандарт мог, например, показывать, как выглядит деталь хорошего качества и пять видов повреждений детали, которые говорят о браке. Это могло быть описание стандартизированной работы, стандарт периодичности и последовательности операций предупредительного технического обслуживания определенного станка.

Кто-то может подумать, что там сидит кучка бюрократов, которые все это регулируют. Однако численность офисного персонала была относительно небольшой, а стандарты входили в зону ответственности рабочих групп на линиях во главе с лидерами двух уровней — лидерами команд и лидерами групп. Лидеры групп находятся на уровне линейных менеджеров. Лидеры команд — это работники с почасовой оплатой, но выполняющие руководящую работу. Работая с инженерами, они совершенствовали стандарты, как и предлагал поступать Генри Форд. Стандарты часто изначально разрабатывались инженерами или работниками других подразделений и были только черновиками, которые потом дорабатывались рабочими группами, утверждались лидером группы и потом проходили проверку на деле, то есть действительно ли они улучшают процесс.

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

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

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

Стандарты и постоянное совершенствование

Итак, стандарт (будь это конкретная цель, например количество звонков в день или процент удовлетворенных клиентов) или описание стандартизированной работы дает вам новую отправную точку, исходную позицию, и, когда мы сможем регулярно достигать этого стандарта, мы должны поставить новую, более сложную цель. У нас было 80% удовлетворенных клиентов. Теперь мы хотим добиться 95%. Это наш новый стандарт. Планка теперь выше (рис. 3.4).

Для достижения этого нового стандарта нам нужно стать лучше, и мы не будем сразу совершать гигантский скачок от 80 к 95%, а поставим небольшие промежуточные цели, например первым шагом запланируем улучшить показатель с 80 до 81%. Делаем, проверяем. Допустим, мы достигли 81%. Чему мы научились? Что мы будем делать для достижения 82%? Такими шагами, достигая цель за целью, мы движемся к главной цели в 95%.

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

Мы иногда видим в компаниях такую проблему. Задается стандарт, скажем, президент говорит руководителям: «Мы хотим достичь 95%, а сейчас наш результат — 80%». Руководители говорят линейным менеджерам: «Вот наша цель. Вот чего мы должны добиться». Они уходят, и рабочие группы начинают борьбу. Даже если они достигнут 90%, они будут разочарованы, ведь цель — 95%. В разрешающей бюрократии мы хотим активного лидерства. Лидер всегда рядом с людьми, он говорит: «Нам нужно к концу года добиться 95%. Мы не должны прийти этой цели одним движением. Нам даже сейчас не надо думать о 95%. Сейчас нам нужно думать о первом шаге. Давайте посмотрим на данные, давайте поймем, почему возникают отклонения от стандарта. Давайте выберем самое большое из них, разберёмся, почему эта проблема происходит, и выработаем идеи по улучшению. Затем выберем одну из них и попробуем реализовать на практике». В этом суть ката совершенствования (см. вторую главу).

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

Задавая правильные вопросы и мотивируя команду, вы увидите, как люди делают первые шаги и движутся вперед. Неудачные эксперименты так же полезны, как и успешные. Что именно не сработало? Как сказал Томас Эдисон, работая над лампой накаливания: «Я не терпел поражений, я просто нашел 10 000 способов, которые не работают». Именно такая философия обучения и должна быть в вашей команде.

Поиск отклонений

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

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

Развитие людей

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

Благодаря стандартизированной работе мы можем вместе улучшать процесс и в то же время совершенствовать свои качества как бережливых лидеров. Мы улучшаем свои навыки решения проблем и развиваем других людей, которые тоже становятся лучше. Кроме этого, у нас есть обязательство делиться с другими сотрудниками компании тем, что, по нашему мнению, может быть для них полезно. У нас нет права приказывать людям из других рабочих групп следовать нашей практике, потому что это решение может подходить только нам, а они, глядя на свою ситуацию, найдут решение лучше. Но у нас есть обязательство по меньшей мере делиться потенциально полезной для других информацией. Возможно, руководители предложат другим выполнить похожую работу, чтобы проверить наш стандарт и предложить свои идеи по усовершенствованию.

Наш главный стандарт — «Полярная звезда»

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

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

Базовая модель бережливого лидерства

Стандартизированная работа и стандарты являются неотъемлемой частью бережливого лидерства. Мы пытаемся визуализировать работу завода или какой-либо процесс так, чтобы было понятно, какова текущая ситуация по сравнению со стандартом (рис. 3.5). В этом суть генти генбуцу.

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

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

Поступая именно так, мы сможем перевести наш процесс на новый уровень стабильности. Раньше у нас было 80% удовлетворенных клиентов. Это означает, что в 20% случаев люди были недовольны. Мы достигли результата в 95%, что означает, что еще есть 5% недовольных клиентов. Пришло время задавать новый стандарт, может, 99% удовлетворенности клиентов. А новый стандарт потребует запуска нового цикла PDCA. Правильно управлять этим процессом поможет модель бережливого лидерства.

Что мы узнали о стандартах?

В начале главы мы вспоминали Генри Форда и его мудрую мысль, что стандарты — это закрепление лучшего, что мы знаем сегодня, чтобы усовершенствовать это завтра. Стандарты не должны быть жесткими. Мы не создаем роботов. Мы пытаемся создать думающих людей и даем им отправную точку и базу для сравнения. Существует много типов стандартов: политики, процедуры, технические спецификации и другие.

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

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

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

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

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

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

Стандарты могут быть ограничением или формальностью, приводить к неэффективной работе и делать работу неприятной. В то же время стандарты могут быть полезны, стимулировать улучшения и повышать удовольствие от работы. Далее мы обсудим пример компании Menlo Innovations, которая разрабатывает программное обеспечение. Их миссия заключается в создании радости — в мире и на рабочем месте. Реализуют эту миссию они во многом благодаря разрешающей бюрократии. У них четкие и наглядные процессы фиксации требований и разработки программного обеспечения.

Визуализация отклонений: факт относительно стандарта

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

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

Визуальный менеджмент является частью вашей работы. Хороший пример визуального инструмента — это светофор (рис. 3.6). Когда мы его видим на дороге, мы не берем инструкцию, чтобы понять значение зеленого, желтого или красного, — мы заранее знаем, что должны делать. Соблюдаем правила или нет, но мы знаем, что красный свет велит нам остановиться, зеленый разрешает ехать, а желтый советует поторапливаться, пока не загорится красный (шучу!). Одного взгляда достаточно, чтобы понять, что нужно делать.

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

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

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

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

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

А что можно сказать про то же самое рабочее место теперь (рис. 3.8)? Было проведено обучение по 5S, и теперь для всего есть свое место и все на своем месте. Когда мы говорим, что есть место для всего, это означает, что у нас есть стандарты. Мы знаем, где должен быть телефон и папки. У нас могут быть отдельные места для папок с входящей информацией и для папок с исходящей, и мы можем сразу понять, что, допустим, если у нас больше пяти входящих папок, мы не успеем обработать эти данные сами и нам нужна помощь. Это своего рода система визуального контроля, которая ограничивает количество материалов, находящихся в работе.

Майкл Балле в книге «Бережливый руководитель» (The Lean Manager) дает хорошее определение: «Визуальный менеджмент позволяет вместе видеть, чтобы вместе знать, чтобы вместе действовать, от оператора до президента компании». Хотя выделены слова «видеть», «знать» и «действовать», главное слово — «вместе».

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

Необычный пример бережливого производства: Menlo Innovations

Визуальный менеджмент работает наиболее эффективно, когда мы разбиваем работу, например офисный процесс, на маленькие части и затем создаем поток, даже если это неповторяющаяся работа за пределами завода. Компания Menlo Innovations разрабатывает программное обеспечение на заказ — тяжелый труд, который, кажется, невозможно четко отслеживать (как описано в книге «Работа мечты» (Joy, Inc.) президентом Menlo Ричардом Шериданом). Процесс разработки носит творческий характер, но там нашли способ использовать сотрудничество и командную работу, чтобы программисты каждый час, или каждые два, или каждые три-четыре часа знали, отстают они от графика или опережают его. Вы, наверное, подумали, что получился полностью регламентированный процесс, в котором программисты выполняют роль рабов времени. Но целью компании было достичь как раз противоположного эффекта: сделать процесс разработки ПО увлекательным для всех членов команды и даже клиентов, что было закреплено в миссии. Для достижения этого лидеры компании фундаментально изменили процесс разработки программного обеспечения.

Menlo Innovations — маленькая компания в городе, где я живу, в Анн-Арбор, штат Мичиган. Она была создана в 2001 году, ее миссия была сформулирована как «вернуть удовольствие в одну из самых уникальных областей деятельности — в создание программного обеспечения». Ее создатели также обозначили желание избежать «человеческих страданий, вызванных технологиями». Вы видите, что они оценивают обычную практику разработки программного обеспечения как нечто ужасное.

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

Его всегда вдохновляла Фабрика изобретений Томаса Эдисона, которая изначально находилась в городе Менло, штат Нью-Джерси. Так появилось название компании Menlo Innovations. В книге «Экстремальное программирование» (Extreme Programming) приводится манифест радикального подхода в разработке программного обеспечения, совпадающий со многими принципами бережливого производства. Ричард многому научился у автора этой книги, а также у Питера Сенге, чья книга «Пятая дисциплина» посвящена системному мышлению. Системное мышление позволило ему взглянуть на картину шире, увидеть детали и дало возможности всей организации учиться вместе.

В компании Menlo они учатся вместе со своими клиентами. У них примерно 40 сотрудников и подрядчиков, которых они выбирают с большой осторожностью. Они хотят нанимать людей, которые подходят культуре компании, способны совместно работать и без ума от обучения. Конечно, от клиентов требуется весьма высокий уровень вовлечения в процесс разработки. При всем этом они растут с каждым годом.

Совместная работа в Menlo

Приглашаю вас в небольшое путешествие по Menlo. Для начала вы увидите рабочее пространство в здании, в котором они начали свою работу (рис. 3.9). Что вы видите, когда смотрите на эту фотографию? Оно выглядит так, как вы себе представляли фабрику по разработке программного обеспечения? Вы видите отдельных сотрудников, представляете, как они общаются?

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

Сотрудничество выглядит как хаос или как структурированная командная работа? Если вы ничего не знаете о компании Menlo и ее процессах, ее офис вам может показаться хаосом. Люди стоят кругом. Двое смотрят в монитор. Почему двое? Почему не один? Они кажутся задумчивыми. Означает ли это, что они думают о своей программе или о каких-то своих домашних проблемах? Рабочее пространство кажется беспорядочным, потому что нет перегородок, люди работают группами. На самом же деле вы смотрите на двух сотрудников, занятых созданием компьютерного кода на основании очень четкой инструкции. В инструкции сказано, что требуется клиенту, и происходит постоянная самопроверка качества кода в процессе его разработки. Ричард объясняет:

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

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

Организация процесса в Menlo

Давайте посмотрим на упрощенную схему процесса, который применяется в Menlo (рис. 3.10), после чего я расскажу о каждом шаге этого процесса. Процесс начинается с клиента, как и должен начинаться любой бережливый процесс. Что хочет клиент? Что нужно клиенту? То, что они хотят, не всегда то же самое, что им нужно. Как однажды заметил Генри Форд: «Если бы я спросил клиента, что ему нужно, он бы сказал: “Лошадь побыстрее”». Menlo Innovations создали новую позицию, которую назвали «технический антрополог».

Технический антрополог «живет» с клиентом и фиксирует, что, по его мнению, последнему нужно, чтобы получать удовольствие от программы, и после этого делает наброски интерфейсов, которые были бы удобны клиенту. Характеристики различных интерфейсов часто описываются в формате пользовательских историй. Применяются обычные карточки, на каждой есть одна характеристика, которая может быть описана картинкой или словом. Эти карточки потом передают команде разработчиков и менеджеру проекта. Рассматривая каждую карточку, они командой решают, сколько потребуется времени для программирования каждой характеристики. Оценка выполняется не с точностью до минуты, а может оцениваться в 1 час, 2 часа, 4 часа, 8 часов, 16 часов или 32 часа.

Что должен понять клиент

Ричард описывает, что должно происходить дальше.

«Мы называем то, что мы делаем, проектным оригами. Я беру листочек бумаги, соответствующий, например, 16 часам работы. Если мы разделим 16 часов пополам, сколько часов мы получим? Восемь. Если я сложу этот листок еще раз пополам, сколько я получу? Четыре. И так далее и так далее… Некоторые спросят: “А что вы делаете для 32-часовой карточки?” Мы склеиваем две 16-часовых карточки вместе, и такая двойная карточка равна 32 часам.

Вам, наверное, интересно, почему мы доходим только до 32. Мы можем устанавливать и больший срок, но 32 часа — это то, что покупает наш клиент. Наш клиент покупает лист бумаги. Этот лист бумаги стоит 40 часов работы двух человек (32 часа программирования и 8 часов обычной работы). В самом начале каждой недели мы обсуждаем статус проекта, оцениваем, что надо сделать, и работаем!

Это действительно простой инструмент проектного управления. У меня двое 9-летних сыновей, и они оба могут прийти сюда и сделать эту работу, потому что им не нужно будет считать больше, чем до 40. Если ты можешь считать до 40 и разместить на схеме 32 часа работы, ты понял принцип нашей системы, можешь начинать хоть завтра. Вы должны лишь выбрать 32-часовую задачу, над которой будете работать».

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

Визуальный менеджмент и командная работа в Menlo

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

Антропологи должны уметь поставить себя на место клиента и понимать, с чем им приходится сталкиваться. Клиенты принимают некоторые вещи как само собой разумеющееся, поэтому недостаточно сказать «Мы даем клиентам то, что они хотят». Как заметил Генри Форд, клиенты не всегда хотят то, что им нужно. Клиенты привыкают и считают нормальным делать лишние три шага в программе для выполнения задачи, но хорошее программное обеспечение не заставит пользователя проходить лишние три шага, если задачу можно решить нажатием одной кнопки.

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

Простое создание карточки не означает, что кому-либо поручено выполнение какой-либо работы, но, когда карточки собраны вместе, вы видите потенциальный объем работы по проекту. Заметьте, что работа ведется на бумаге. Я много раз посещал Menlo, и кто-нибудь всегда спрашивал «Почему вы делаете это на бумаге? Разве на компьютере не удобнее? В конце концов, вы же софтверная компания». А все дело в том, что работу надо сделать видимой, разместив карточки на доске, которые укажут недельный объем работы на каждый день. Гораздо сложнее сотрудничать, видя перед собой только экран монитора и тратить время, открывая разные документы. И потом, есть что-то магическое в том, чтобы взять листок бумаги, посмотреть на него и сказать: «Нет, я думаю, это должно быть вот так» — и тут же сделать новый набросок. Когда-нибудь, может быть, компьютеры станут настолько дружелюбными к пользователю, что рисовать с их помощью будет так же легко, как с помощью карандаша и бумаги. Но пока это не так.

Итак, у нас есть все карточки, пока еще не утвержденные, и нам нужно оценить, сколько времени потребуется для программирования каждой характеристики. Мы видим группу людей, которые оценивают время на каждую карточку, и, кажется, получают от этого удовольствие (рис. 3.11). Шлемы викингов — это символ, который появился случайно, когда Ричард с женой привезли их как сувениры из Норвегии. В этом конкретном случае они носят их, просто чтобы процесс обсуждения выглядел веселее.

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

Компания существует, чтобы обслуживать клиентов, но они должны согласиться с процессом работы, принятом в компании. На первых встречах сотрудники вместе определяют объем работы по проекту, что не так просто. Они смотрят на листы, которые обозначают восьмичасовые рабочие дни, и задают вопросы о содержании карточек, в которых описываются характеристики. Они дают обратную связь и спрашивают себя: «Стоит ли эта характеристика того, чтобы платить за нее сейчас?» В ходе этой сессии с клиентом они просматривают карточки и определяют первоначальный объем работы. Далее каждую неделю клиент анализирует, что сделано за прошедшую неделю, и они вместе решают, что сделать на следующей. Это динамичный процесс, и объем работы, определенный на первом этапе, может измениться в ходе реализации проекта. Это пример работы цикла PDCA на еженедельной основе.

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

Доска утвержденных работ

Ричард:

«Артефакты, которые мы размещаем на стене, сообщают самое важное, над чем мы работаем в настоящее время. Каковы наши цели? Слишком часто технические компании склонны к размещению такой информации в корпоративной интрасети, где ее может увидеть каждый. Мы верим, что самое важное, что мы можем сделать, это разместить информацию на стене, где все всё видят в течение дня».

Доска утвержденных работ (рис. 3.12) — это визуализированный график ежедневных работ. Собственно, именно данная доска используется программистами и менеджерами проектов для управления работой ежедневно, ежечасно. Вы видите карточки работы на каждый день, в верхней части каждой карточки указаны имена пары программистов. Менеджер проектов пересматривает доску каждую неделю. В понедельник утром программисты находят информацию, с кем они работают в паре и по какому проекту. Они подходят к доске и берут карточки, по которым могут программировать характеристики.

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

Программисты встраивают в каждую строку проверку, выполняет ли код то, что должен. Это называется «модульное тестирование». Они ведь должны убедиться, что новый код корректно работает с остальной программой. Кроме этого, они засекают, сколько времени фактически понадобилось для выполнения задачи, на основании чего клиенту будет выставлен счет. Карта пользовательских историй становится зеленой, только когда «адвокаты качества» скажут: «Да, мы провели проверку. Мы понимаем описание технических антропологов, что нужно клиенту, и считаем, что это соответствует его потребности. Функционал готов к использованию». Интересно, что «адвокаты качества» необязательно должны знать программирование.

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

Что вы как менеджер проекта делаете, если видите несоответствие? В традиционной системе вы ищете виновную сторону, а в бережливой системе — привлекаете внимание к тому, что есть отклонение. Это означает, что я — лидер и я должен понимать, что происходит, я должен понимать причину отклонения. Менеджер проекта сразу видит, процесс под контролем или нет, соответствует он стандарту или нет, чтобы потом проработать этот вопрос с командой. Команда, возможно, уже предприняла корректирующие действия. Это может быть маленькой локальной проблемой, например отключился компьютер. В противном случае несоответствие может потребовать реализовать цикл PDCA.

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

Визуальный менеджмент поддерживает культуру сотрудничества

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

Мы видим, у одного человека в руке мышка, он программирует, а второй человек показывает на что-то на экране (рис. 3.13) и, возможно, говорит: «Вот, смотри, здесь проблема». Увидев проблему, они могут ее поправить прямо сейчас, в то время как некоторые компании доводят такие ошибки до клиента. А ведь переделки на стадии показа кода клиенту стоят дорого, к тому же придется что-то делать с недовольным клиентом, — такие потери внизу потока стоят компании гораздо больше, чем оплата работы двух специалистов. И это тоже внутренняя убежденность компании Menlo. Это необязательно должно быть частью вашей культуры, но стоит держать в голове, что работа в парах может быть более продуктивной, чем индивидуальная работа.

Теперь узнаем от Ричарда одну из самых больших историй успеха — совместную работу с Accuri над цитометром, который был изобретен, когда Menlo получили долю в компании за разработку программного обеспечения. Клиенты были чрезвычайно удовлетворены продуктом. Ричард с гордостью объясняет, что это, наверное, самая высокая плата за программирование (хотя цена была ниже, чем у конкурентов). Общая стоимость для клиента, учитывая простоту использования и отсутствие необходимости переделки, была гораздо ниже:

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

Он позвонил клиенту и сказал: «Отправка осуществляется FedEx. Будет на месте завтра. Вы сможете позвонить мне, когда распакуете, скажем около девяти?». Они согласились.

Он был очень взволнован, на следующее утро проверил сайт FedEx: «Они получили посылку в 8:45».

Он уселся у телефона. Девять часов — звонка нет. Полдень — звонка нет. Зашла президент Accuri Джен Бэрд: «Лео, они звонили?»

«Нет, не звонили».

Прошел день, а звонка так и не было. Прошел второй день, звонка не поступило. Лео с ума сходил. Он отчаялся, был близок к самоубийству. В конце концов он снял трубку и позвонил им сам: «Добрый день. Это Лео из Accuri».

Они говорят: «Привет, Лео. Как дела?»

Он говорит: «Нормально, а у вас?»

Они отвечают: «Отлично».

Он говорит: «Вы же получили посылку, верно?»

«Да, два дня назад, утром, в 8:45».

Он говорит: «Вы собирались мне позвонить. Помните? Все ли вам понравилось, удовлетворил ли вас результат?»

Он, к своему удивлению, услышал такой ответ: «Ах, да. Слушай, Лео, как только мы распаковали, мы сразу начали использовать. Мы два дня с ним возились. Прибор отличный. Спасибо».

Ричард воодушевленно комментирует: «Потратили меньше, а заработали больше. Это очень круто».

Что мы узнали о визуальном менеджменте?

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

В компаниях типа Menlo Innovations всегда есть место для большого объема совместной работы с клиентом. Сотрудничество начинается на этапах определения нужд клиентов техническими антропологами с менеджерами проекта и программистами и продолжается на этапе парной работы по программированию. Далее начинается сотрудничество с «адвокатами качества». Когда люди работают вместе и когда мы можем подойти к экрану и увидеть статус проекта — опережаем или отстаем от графика, прошли ли мы контроль качества или нет, что необходимо делать в течение следующего часа, сколько на это потребуется времени, тогда у всех будет одна и та же картинка реальной ситуации в сравнении с планом.

Разница между тем, что запланировано, и тем, что происходит, становится проблемой, а слово «проблема» используется совершенно объективно. Другими словами, расхождение, например, между плановыми 60 минутами, необходимыми для выполнения задачи, и фактическими 70 минутами является проблемой. Проблема не означает, что надо винить конкретного человека или моментально реагировать. Просто у нас есть отклонение, с которым надо разобраться. Мы должны спросить себя, почему оно возникло. Нам, возможно, потребуется улучшить процесс оценки. Или понять, что произошло что-то особенное, неподвластное участникам процесса. Или осознать, что нужно кого-то лучше обучить. Или можем просто зафиксировать проблему для себя и ничего не делать. Для отклонений могут быть совершенно разные причины. Нам нужно принять решение, для какой проблемы необходимо запустить процесс PDCA.

Страх убивает культуру постоянного совершенствования, ведь все становится таким наглядным, а человек — существо ранимое. Доктор Деминг десятилетия назад учил изгонять страх, потому что в атмосфере страха люди готовы делать то, что нужно, лишь бы быть вдали от проблем. Оставаться вдали от проблем можно, лишь спрятав проблемы, именно поэтому в Toyota говорят: «Отсутствие проблем — это проблема!» Если вы регулярно не выявляете проблемы, это и есть проблема, потому что проблемы на предприятии есть всегда. Мы редко делаем все идеально и по плану, а спрятав проблемы, мы блокируем совершенствование.

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

Отправить