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

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

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

• Решения требуют участия внешних поставщиков или клиентов.

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

• Нельзя решить все проблемы одним махом. Необходимо приготовиться к множественным (пошаговым) изменениям, которые придется осуществлять параллельно. При этом следует избегать «быстрых» решений, которые не дадут желаемых результатов.

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

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

ПРИМЕР № 6. ВЗЯТЬ ПОД КОНТРОЛЬ СЛОЖНОСТЬ ПРОЦЕССА (ПРОЕКТ КАЙДЗЕН В СФЕРЕ УСЛУГ)

ПОЧЕМУ ИМЕННО ЭТОТ ПРОЕКТ?

В феврале 2002 года Bank One провел стратегическое совещание, на котором менеджеры важнейших подразделений говорили о конкретных возможностях совершенствования и обсуждали их приоритетность. Вопрос о «срочной курьерской доставке» в подразделении Wholesale Lockbox возглавлял список. Он затрагивал взаимные расчеты компаний через Bank One: клиентам требовалось, чтобы поступление платежей на счет осуществлялось как можно скорее после момента платежа.

Как рассказывалось в начале главы 5, услуга, которая прежде оказывалась в весьма скромных объемах — для нескольких счетов ежедневно, вскоре превратилась в весьма сложную операцию по обработке огромного объема поступлений, значительная часть которых требовала «особой обработки» (персонал должен был следовать нестандартной процедуре из-за различных потребностей клиентов). Помимо явных затрат, связанных с избыточной сложностью, Bank One упускал возможность получения дохода — конкуренты взимали за подобные услуги плату, но Bank One считал, что он не вправе это делать, будучи не в состоянии гарантировать определенный уровень качества услуг. Поскольку Bank One был одним из крупнейших поставщиков услуг Wholesale Lockbox в масштабах страны, упущенная выгода исчислялась миллионами долларов в год, которые можно было бы получить при более совершенном процессе.

МЕРОПРИЯТИЕ

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

День 1. Обучение и определение. Члены команды получают базовую подготовку в области концепций метода «бережливое производство + шесть сигм», в частности представление о семи видах потерь.

День 2. Измерение и анализ. Члены команды обходят все стадии процесса, следуя траектории обрабатываемого объекта. Они собирают данные по времени цикла, очередям, преодолеваемым расстояниям и т. д., чтобы составить карту потока создания ценности.

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

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

День 5. Оценка и отчет. Команда анализирует результаты вместе со спонсорами и отмечает свои достижения.

Фрагмент карты потока создания ценности, составленной командой, показан на рис. 13.1.

Рис. 13.1. Данные карты потока создания ценности услуг Lockbox

На схеме представлены собранные командой отдела Lockbox данные, которые показывают количество времени, не добавляющего ценности, на различных операциях в ходе процесса.

Предложенные решения

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

• Выработка более четких принципов, определяющих, что такое гарантированное четырехчасовое время цикла.

• Четкое представление о производительности. Данный вопрос имел несколько аспектов. Во-первых, команда рассчитала, какое количество персонала понадобится после перестройки процесса для обеспечения 4-часового времени цикла. Во-вторых, было определено предельное число нажатий клавиш, после которого считалось, что обработка заявки занимает слишком много времени, что позволило команде сформулировать принципы, когда можно обещать 4-часовое время цикла.