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

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

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

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

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

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

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

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

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

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

Карты потоков создания ценности помогали выявлять потери, не добавляющие ценности, и измерять производительность сотрудников. В группах разработки программного обеспечения показатель потерь обычно невысок из-за сложности взаимодействий – 25 % считаются нормой.

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

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

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

В конечном итоге измерения показали, что производительность составляет 2–4 %. Иными словами, ежемесячно около 20 млн евро исчезали в никуда.

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

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

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

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

• Описания процедур проверки качества, принятых в организации, были вывешены на всеобщее обозрение. Ранее сотрудники не имели понятия, каким образом отдел контроля качества проверяет их работу.

• Были установлены стандарты качества работы сотрудников, предусматривающие участие в кайдзен-мероприятиях. Ранее такие стандарты отсутствовали, и люди автоматически получали высокие оценки.

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