Масааки Имаи - Гемба кайдзен. Путь к снижению затрат и повышению качества
Кайдзен определяет наше будущее
Кайдзен дает надежду сегодняшней экономике. В наши дни становится все важнее сокращать потери, выполнять работу правильно с первого раза и добиваться максимальной эффективности. Работая в условиях острой конкуренции, особенно со странами Дальнего Востока, мы должны оставаться конкурентоспособными. Если бы мы в Португалии не взяли на вооружение кайдзен, наши клиенты давно нашли бы себе поставщиков подешевле.
Главную роль в компании играют люди. Я часто читаю книги, где говорится, что люди – это самый ценный актив. Это прекрасная фраза, но жить в соответствии с этим принципом очень непросто. Инструменты и методы кайдзен позволяют создать у людей ощущение, что все они – часть единой организации. Кайдзен сближает разные уровни организации. Я убежден, что компании, которые применяют кайдзен, ведут больше открытых дискуссий, они более прозрачны и в них почти нет табу. Работники могут задавать любые вопросы, и это создает свободную атмосферу, которая способствует совершенствованию. Об этом говорят показатели нашего завода в Португалии.
Жоао-Паулу Оливейра, старший вице-президент Bosch Termotecnologia Portugal SAИзменение ИТ-культуры в Achmea
Эксперты по качеству любят говорить: невозможно управлять тем, что нельзя измерить. Однако, как показывает данный кейс, важнее помнить: невозможно управлять тем, чего ты не понимаешь. Achmea, крупная европейская страховая компания, где работает 20 000 человек, располагала всеми необходимыми инструментами, чтобы преобразовать свой ИТ-отдел, численность персонала которого составляет 7000 человек, но поначалу не понимала культурных проблем, которые мешали ей двигаться вперед.
В прошлом эта компания преуспевала и почти не обращала внимания на затраты, а потери и отсутствие личной ответственности были частью корпоративной культуры. Когда в 2008 году финансовый сектор столкнулся с серьезными проблемами, одной из первоочередных задач стала эффективность. Руководители компании, обеспокоенные ее будущим, пригласили представителей крупной консалтинговой фирмы, чтобы с их помощью внедрить систему бережливого производства.
В целом преобразования шли успешно, но отдел ИТ оставался камнем преткновения. Вскоре стало ясно, что консультанты по бережливому производству не знакомы с особенностями работы в ИТ и не понимают трудностей отдела. Чтобы решить проблему, компания обратилась за помощью к Kaizen Institute в Нидерландах – его специалисты имели опыт внедрения бережливого производства в ИТ.
Сотрудники Kaizen Institute начали преобразования с одной из групп отдела разработки программного обеспечения, где работали 600 человек. Эта группа отвечала за проектирование, построение и тестирование программных продуктов, обеспечивающих основную деятельность компании. В составе группы были инженеры, разработчики, администраторы приложений, тестировщики, бизнес-аналитики и другие специалисты. Поскольку все они получали высокую зарплату, а результаты их работы имели стратегическое значение для организации, оптимизация работы подразделения сулила высокую отдачу.
Как и в большинстве ИТ-организаций, в этом подразделении были сотрудники, владеющие разными методологиями управления ИТ. Самая известная из них – это процессный подход, который называется библиотека инфраструктуры информационных технологий (information technology infrastructure library, ITIL). Эта библиотека описывает критерии стандартизации и передовые методы работы ИТ-структур, представляя их в систематизированном виде как набор услуг для бизнеса. Последнее сближает ее с картами потока создания ценности.
Проблема заключалась в том, что люди не применяли доступные инструменты и не испытывали потребности делать это. Планирование проектов осуществлялось бессистемно, результаты работы людей практически не оценивались, а участники проектов плохо представляли затраты и временные рамки работ. Рабочий процесс был раздроблен: нередко инженеры и разработчики, выполнив одну задачу, ждали полгода, чтобы выполнить следующую.
«Нежелание применять доступные инструменты зачастую вызвано тем, что они не стыкуются с выполняемой работой, – говорит Вейбранд Медендорп, управляющий партнер Kaizen Institute в Нидерландах, который консультировал участников проекта. – Чтобы решить эту проблему, руководство должно выслушать замечания и предложения рядовых сотрудников, признать недостатки и промахи и возглавить пошаговое усовершенствование».
Даже когда руководству ясно, что проблемы есть, выявить нарушения процессов в группе разработки программного обеспечения чрезвычайно трудно, поскольку бóльшая часть работы представляет собой невидимый код, понятный очень немногим. Даже внутри группы разработки используется много технических «языков», которые не универсальны.
Поэтому обучение методам бережливого производства нужно было дополнить высокоуровневыми инструкциями по различным аспектам ИТ. К примеру, люди, которые составляли блок-схемы, должны были больше узнать о том, как пишется программный код, а бизнес-аналитики – изучить недостатки существующей системы SAP. Такую информацию люди получали на собраниях, где представители разных функциональных групп рассказывали о своих задачах и проблемах.
Впечатляющие результаты дал процесс под названием арена потребителей. Он представлял собой собрание, во время которого заинтересованные лица, сидя вокруг стола, рассказывали о своих основных проблемах, а члены команды исполнителей слушали их разговор со стороны. Таким образом многие впервые услышали, как их действия или бездействие отражаются на других участниках цепочки добавления ценности.
Чтобы люди уяснили роли других членов команды и поняли преимущества и динамику межфункциональных команд, использовались игры. При этом игры, которые традиционно применяются для освоения методов бережливого производства, в частности игра «Самолет», были адаптированы для ИТ.
Получив общее представление о происходящем, межфункциональные команды начали составлять карты потоков создания ценности. При реализации типового проекта по разработке программного обеспечения невидимый продукт проходит следующие этапы: формулировка бизнес-требований, составление блок-схем, написание кода, поиск неисправностей, тестирование пользователями. Примером в Achmea стала доработка программного обеспечения для работы накопительными пенсионными программами в связи с появлением новых правил налогообложения.
Увидев свою работу в виде карт потока создания ценности, люди смогли выявить крупные организационные проблемы. Члены команды, создающей продукт, не подчинялись менеджеру проекта, который отвечал за то, чтобы работа была выполнена в срок и уложилась в бюджет. Они подчинялись линейным менеджерам по функциональному принципу: инженеры отчитывались перед руководителем инженеров, тестировщики – перед руководителем тестировщиков и т. д. В совещаниях, на которых обсуждались проблемы, участвовали только сотрудники отдельных функциональных групп.
