Гемба кайдзен. Путь к снижению затрат и повышению качества

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

Сотрудники Kaizen Institute начали преобразования с одной из групп отдела разработки программного обеспечения, где работали 600 человек. Эта группа отвечала за проектирование, построение и тестирование программных продуктов, обеспечивающих основную деятельность компании. В составе группы были инженеры, разработчики, администраторы приложений, тестировщики, бизнес-аналитики и другие специалисты. Поскольку все они получали высокую зарплату, а результаты их работы имели стратегическое значение для организации, оптимизация работы подразделения сулила высокую отдачу.

Как и в большинстве ИТ-организаций, в этом подразделении были сотрудники, владеющие разными методологиями управления ИТ. Самая известная из них – это процессный подход, который называется библиотека инфраструктуры информационных технологий (information technology infrastructure library, ITIL). Эта библиотека описывает критерии стандартизации и передовые методы работы ИТ-структур, представляя их в систематизированном виде как набор услуг для бизнеса. Последнее сближает ее с картами потока создания ценности.

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

«Нежелание применять доступные инструменты зачастую вызвано тем, что они не стыкуются с выполняемой работой, – говорит Вейбранд Медендорп, управляющий партнер Kaizen Institute в Нидерландах, который консультировал участников проекта. – Чтобы решить эту проблему, руководство должно выслушать замечания и предложения рядовых сотрудников, признать недостатки и промахи и возглавить пошаговое усовершенствование».

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

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

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

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

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

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