ИТ для европейских окон: тенденции изменчивой среды

Глобальная компания, глобальная ERP-система, глобальный ИТ-аутсорсинг, гибкие методологии и продуктовые команды, машинное обучение в интернет-маркетинге — о жизни бизнес-приложений и взаимодействии бизнеса с ИТ-подразделением рассказывает Юрий Лиц, директор IT Digital Delivery (компания VELUX A/S), выпускник Школы IT-менеджмента РАНХиГС.

Каков ИТ-ландшафт VELUX и за какую его часть отвечает вы?

VELUX — глобальная компания, лидер по производству мансардных окон. У нас 27 заводов в 11 странах и офисы продаж в 40 странах, а значит, глобальная сеть логистики. Годовой оборот около 3 млрд долларов, почти 15 тысяч сотрудников по всему миру. Мой департамент отвечает за весь блок бизнес-приложений: их внедрение, развитие, поддержку.

Закупки материалов, производство, складская и транспортная логистика, продажи, маркетинг, финансы, управление персоналом — список бизнес-процессов длинный. Основное бизнес-приложение — SAP ERP, версия ECC. Это приложение единое, глобальное, шаблоны во всех странах одинаковые. В нем настроена глобальная логистическая цепочка поставок, закупки материалов (внедрена SAP Ariba), процесс от заказа до оплаты, консолидирована финансовая отчетность. Внедрение было закончено в 2010 году, сейчас все работает как часы, очень стабильно и хорошо, большую роль в поддержке играет наш стратегический ИТ-партнер Accenture.

В других областях бизнеса все более динамично. Например, цифровая трансформация в маркетинге. Мы внедряли различные решения от SalesForce, Informatica, HubSpot, Sitecore и другие решения для того, чтобы персонализировать опыт клиентов от момента, когда они впервые видят нашу рекламу в Интернете, до оформления покупки, чтобы вся информация для клиента была бы персонализирована с учетом того, что нам о нем известно. На этом фронте приложения появляются и исчезают за несколько лет. Это процесс бесконечный, законодательство и технологии меняются очень быстро. Нужно постоянно адаптироваться.

Кроме того, у нас идет большое внедрение в HR. Это Workday, внедряем много модулей сразу. Это приложение сейчас очень востребовано, специалистов находить очень сложно, спрос велик по всей Европе. Наш партнер в этом внедрении Deloitte, и особенность в том, что мы делаем одновременное внедрение нескольких продуктов по scrum-методологии. Потребовалась определенная готовность бизнеса к этому, что непросто. Мы постепенно отходим от того, что у нас есть отдельно внедрения и отдельно поддержка, и движемся в сторону продуктовых команд.

Бизнес и скрам: в чем проблема?

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

Такова общая проблема, и она касается трансформации ИТ-департамента. Я много общаюсь с европейскими коллегами и вижу, что в большинстве компаний идет такое же движение: от проектов к продуктовым командам, где бизнес и ИТ-специалисты действуют вместе, причем руководители проектов фактически отсутствуют. Есть даже крупные скандинавские компании, где уже запрещено само слово «проект», зато появился термин value streem — «поток ценностей». Есть владельцы этих потоков, есть владельцы продуктов. В командах работают и сотрудники ИТ-департамента, и сотрудники бизнес-подразделений, и сотрудники внешних подрядчиков. Все они большую часть времени находятся именно в продуктовых командах. При этом заметно меняется роль руководителей подразделений. Раньше они очень сильно были вовлечены в отдельные проекты, а теперь остаются скорее коучами своих сотрудников, занимаются только управлением людьми и распределением их по продуктовым командам, по сути дела. Они даже и не знают обычно, что конкретно происходит в этих продуктовых командах.

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

Традиционная проблема взаимодействия ИТ и бизнеса обычно заключается в том, что бизнес постоянно хочет все больше изменений и новых систем, а ИТ-отдел пытается догнать запросы бизнеса, постоянно стремясь обосновать увеличение бюджетов перед топ-менеджментом. Причем чем больше работ выполняют айтишники, тем больше хочет бизнес. У нас именно так и было. Однако теперь, с появлением value stream и проектных команд, мы от этой проблемы уходим. Владелец «потока ценности» или продукта получает определенное количество внутренних и внешних ресурсов от Цифровых комитетов. И теперь это уже его задача: как расставить приоритеты и с помощью этих ресурсов реализовывать то, что бизнесу нужно на данном направлении в первую очередь. Иногда владелец продукта приходит к мысли, что ресурсов недостаточно. Тогда он обращается к нам с предложением увеличить ресурсы, взять новых людей, расширить инфраструктуру. «Не возражаем, — отвечаем мы, — готовы расширяться». Теперь не мы чего-то не успеваем и просим все больше, а бизнес приходит к нам и обосновывает необходимость расширения. Диалог изменился в лучшую для нас сторону.

Насколько тотален ваш аджайл?

Мы стараемся ограничить количество людей в одной продуктовой команде — максимум 10 человек, обычно меньше. Если продукт требует большего количества ресурсов — делим его на несколько. У нас был опыт, когда была программа с общим числом занятых 150 человек, было много скрам-команд. Но результат был далек от идеального: слишком много времени уходит на координацию, что лишает скрам его основного преимущества. Так что децентрализация — это ключ. Архитекторы обсуждают между собой модели данных, например. Но число совещаний стараемся минимизировать, чтобы команды двигались вперед быстрей.

Есть области бизнеса, где мы по-прежнему работаем по традиционному «водопаду» и не планируем это менять. Так что «всё ИТ» в продуктовых командах не окажется, какая-то часть останется в прежнем виде. Нет цели быть Agile-организацией на сто процентов, но баланс продолжает меняться в сторону Agile.

Много команд, много продуктов, все динамично меняется: это путь к хаосу?

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

Более того, ресурсы любого стрима или продукта нельзя перенаправлять произвольно. Определенная квота обязательно должна идти на стратегические задачи. Эту квоту определяет CEO и топ-менеджмент компании. Глобальные приоритеты расставлены централизовано.

Я полагаю, что смещение в сторону продуктовых команд неизбежно приведет нас к большему, чем сейчас, хаосу. У нас есть команда архитекторов, мы стараемся контролировать развитие, но своим руководителям отделов я честно говорю: «Привыкайте: я могу вас успокаивать и обещать, что мы потом везде наведем порядок, но на самом деле завтра будут новые приоритеты». То, как мы раньше могли следовать единому шаблону, как в ERP-системе, уже невозможно. Дело в том, что есть стабильные части бизнеса, как производство, а есть очень быстро меняющиеся, как маркетинг. Да даже и производство уже не остров стабильности с учетом роботизации и диджитализации. Нет смысла в этом море изменений наводить какую-то стерильную чистоту, детально описывать процессы и прочее подобное. Пока мы это делаем, уже все переделывать пора.

Да, некоторый хаос неизбежен. Ведь, кроме прочего, бизнес хочет, чтобы мы постоянно делали какие-то эксперименты. После них остаются некие «хвосты», которые желательно подчищать. Мы делаем это, но подчистить все невозможно, и остаются «лоскуты». Надо смириться и принять новую реальность. Сегодня руководителю в ИТ пора становиться chaos pilot — «пилотом в хаосе».

Тем не менее по каждой используемой технологии у нас есть ответственный архитектор. Есть подразделение Enterprise Architecture, которое следит за архитектурой на всех уровнях, начиная с инфраструктурного, есть архитекторы данных, которые обеспечивают возможность интегрировать данные из нескольких систем. А у меня есть архитекторы в каждой функциональной области. Архитектор участвует в выборе новых систем, в проектировании новых продуктов, но они не пытаются ставить совсем жесткие рамки, это буквально живой, постоянно меняющийся организм.

Какова судьба и задача SAP ERP в этом изменчивом мире?

Самый главный наш приоритет для ERP-системы — это ее стабильность. Простой на час — это были бы огромные убытки для нас. От планирования закупок до продаж — встанет все, включая производство. ERP-система доходит до уровня цехового управления, на ней все закупки материалов, логистика, планирование: у нас на 100% реализовано то самое «корпоративное планирование», для которого и были созданы ERP-системы.

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

У нас гибридное развертывание SAP ERP: часть на наших серверах, часть в облаке SAP, часть у других провайдеров. Часть продуктов SAP, непосредственно подключенных к ERP, например Ariba или Concur, полностью облачные. Много потребностей в интеграции. Мы используем Microsoft Azure Data Lake и технологию Kafka, по сути, предоставляющую интеграцию в реальном времени.

Если нам нужно что-то попробовать, мы берем данные из ERP-системы, экспериментируем в этот слой интеграции, другие системы «подписываются» на эти данные и получают их. Переход на версию S4 мы решили отложить еще на пару лет после детального анализа. В новой версии упрощается структура данных, продукт развивается так, чтобы было проще брать данные из него, проще интегрировать, для нас это важно. Однако и затраты на проект перехода на S4 огромные, даже если делать внедрение brown field (не переделывать все с нуля).

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

Кто развивает и поддерживает приложения SAP?

В 2005 году VELUX перевел несколько сотен внутренних сотрудников ИТ-подразделения, в том числе занятых поддержкой SAP, в Accenture. С тех пор наша «аутсорсинговая сага» испытала много поворотов сюжета. На максимуме 95% ИТ-функций у нас было на аутсорсинге. Затем стало ясно, что это слишком много, и мы постепенно стали возвращать часть функций. За последние десять лет Accenture перенес часть поддержки из Дании в Индию для оптимизации стоимости. В целом на сегодня примерно на 40 человек в моем департаменте приходится около 200 сотрудников Accenture. Вместе мы занимаемся как поддержкой, так и внедрением.

Хотим ли мы отказаться от аутсорсинга вовсе? Конечно нет. У нас есть свои архитекторы, программисты, бизнес-аналитики, но есть и много из Accenture, Deloitte и от других партнеров. И мы не хотим забирать их назад. Это могут быть гуру по каким-то технологиям, и нам нравится гибкость в их занятости у нас. Может быть так, что сами они предпочитаю работать в консалтинговой фирме, потому что там возможно продвижение, даже если делаешь практически одно и то же.

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

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

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

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

Маркетинг, соцсети, ИИ: что делаете вы в этих областях?

Современные технологии MarTech (маркетинговые технологии), такие как CDP (Customer Data Platform), позволяют практически бесконечно делить аудиторию, выделяя все более мелкие сегменты с похожим откликом, персонализируя путь клиента до покупки. Отслеживание реакции идет на всех каналах: на какой баннер человек кликнул, какую страницу посмотрел на сайте, как заполнил форму, что сказал во время звонка нам. Алгоритмы анализируют поведение и данные от потенциальных клиентов, «отдавая» им также через все каналы персонализированный контент и постоянно делая A/B-тесты, определяя, что лучше работает на каждую микроаудиторию. Упрощенно говоря, алгоритм постоянно делить аудиторию на все более мелкие сегменты, максимизируя конвертацию каждого потенциального клиента на пути продаж.

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

Предположим, что есть 12–15 аргументов, которые вообще могут убедить человека установить мансардные окна в своем доме. Все эти аргументы нет смысла показывать — будет перегруз информацией: больше трех никто не прочитает. Поэтому пакет выбирает по три аргумента и демонстрирует их аудитории, определяя группы, которые реагируют максимально на определенные аргументы. С помощью машинного обучения алгоритм учится все лучше подбирать работающие аргументы. Бесконечное число повторений позволяет выбрать наиболее эффективные для каждого пользователя варианты контента. Кроме действий клиента, используется и привязка к географии. Сейчас существует возможность понять с точностью до дома, где живет потенциальный клиент. Есть данные, что обычно покупают люди из этого района и какие аргументы для них наиболее действенны. Проводя аналогию для России, система очень быстро придет к тому, что нужно показывать разный контент и предлагать разные категории продуктов, если потенциальный клиент открывает сайт, находясь на Рублевском шоссе или же в селе в регионах.

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

Некоторые российские компании начали мотивировать сотрудников ИТ и бизнес-подразделений одними и теми же показателями. Как это делается в Velux?

У директоров бонус на 80% привязан к финансовым результатам компании и только 20% к собственным целям — так в любом подразделении, не только в ИТ.

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

KPI разработчиков мобильного приложения, например, связан с числом скачиваний этого приложения. Люди из отдела маркетинга, которые работают над этим же продуктом, тоже имеют такой же KPI — число скачиваний. Так что все члены продуктовой команды действительно имеют не единые, но связанные KPI.