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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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