Статьи
2021-04-01 08:00

Как Platformeco помогает компаниям реагировать на быстро меняющиеся потребности клиентов

Изменение потребительского поведения может обернуться для#nbsp;традиционных розничных компаний потерей доходов. Главным фактором получения прибыли в#nbsp;условиях неопределенности становится способность компании быстро реагировать на#nbsp;изменения, предлагая продукты с#nbsp;учетом индивидуальных запросов клиентов.
Региональная экспансия, изменения в#nbsp;поведении потребителей и#nbsp;глобальные вызовы, подобные локдауну, оказывают сильное воздействие на#nbsp;бизнес компаний розничной торговли, включая и#nbsp;предприятия сегмента «Сделай сам» (Do#nbsp;It#nbsp;Yourself, DIY), в#nbsp;котором работает компания «Леруа Мерлен». В#nbsp;ситуации, когда за#nbsp;один день могут закрыться три четверти магазинов от#nbsp;Владивостока до#nbsp;Калининграда, сложно говорить о#nbsp;долгосрочном планировании. Работа в#nbsp;условиях неопределенности в#nbsp;обществе, на#nbsp;потребительском рынке и#nbsp;в#nbsp;сфере регулирования предпринимательской деятельности требует новых подходов и#nbsp;инструментов, позволяющих оперативно и#nbsp;эффективно решать бизнес-задачи.
Рис.1 Бизнес-модель «Платформа и#nbsp;экосистема»
Некоторое время назад в#nbsp;компании «Леруа Мерлен» было принято решение об#nbsp;отказе от#nbsp;бизнес-модели классического ретейлера#nbsp;— развития сети физических магазинов и#nbsp;широкого, но#nbsp;все#nbsp;же ограниченного торговой площадью ассортимента. Компания инициировала движение сначала в#nbsp;сторону омниканальности, а#nbsp;затем и#nbsp;к#nbsp;бизнес-модели «Платформа и#nbsp;экосистема» (рис. 1), исключающей барьеры между компанией и#nbsp;ее#nbsp;партнерами за#nbsp;счет создания единой экосистемы вокруг «бесшовного клиентского пути». В#nbsp;рамках этой модели посетителю магазина в#nbsp;одной точке должно быть доступно все необходимое для#nbsp;строительства и#nbsp;обустройства дома#nbsp;— от#nbsp;услуг планирования и#nbsp;расчетов до#nbsp;закупки материалов и#nbsp;выполнения работ.

Для#nbsp;реализации такой бизнес-модели была инициирована серия проектов: маркетплейс с#nbsp;расширенным товарным предложением, не#nbsp;ограниченным полкой в#nbsp;физическом магазине; предоставление услуг по#nbsp;установке оборудования и#nbsp;ремонту; расширение сотрудничества с#nbsp;B2B-клиентами; предоставление услуг по#nbsp;проектированию жилых помещений и#nbsp;инженерных систем и#nbsp;пр.#nbsp;Продукты были объединены в#nbsp;одну экосистему, а#nbsp;их#nbsp;оркестрация осуществляется в#nbsp;соответствии с#nbsp;принципом бесшовного пути клиента магазина.

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

Все это стимулировало проведение кардинальных изменений в#nbsp;организационной структуре компании. Существовавшее ранее обособленное ИТ-подразделение было реорганизовано: его сотрудников распределили по#nbsp;продуктовым командам, объединенным с#nbsp;операционными командами, которые отвечают за#nbsp;определенные части клиентского пути (омниканальные продажи, платежи и#nbsp;другие) или стратегические процессы компании. Команды автономно работают над своими целями, имеют свой план действий и#nbsp;руководствуются собственными метриками оценки эффективности работы. В#nbsp;состав каждой команды входят специалисты по#nbsp;бизнес-процессам и#nbsp;ИТ, что, с#nbsp;одной стороны, исключает посредников между постановщиками операционной задачи и#nbsp;разработчиками решения, а#nbsp;с#nbsp;другой#nbsp;— погружает ИТ-специалистов в#nbsp;специфику ведения бизнеса, благодаря чему контекст работы становится прозрачен и#nbsp;понятен всем членам команды.

Для#nbsp;поддержки продуктовых команд, ускорения и#nbsp;улучшения ИТ-процессов были созданы три базисных департамента:

—#nbsp;департамент ИТ-платформы (инфраструктура, облако, контейнеры, мониторинг, CI/CD);

—#nbsp;департамент платформы данных (корпоративное озеро данных и#nbsp;аналитика);

—#nbsp;департамент интеграции и#nbsp;поддержки микросервисного ландшафта.

Все предоставляемые департаментами сервисы доступны продуктовым командам в#nbsp;режиме самообслуживания либо по#nbsp;запросу.

Переход к#nbsp;бизнес-модели «Платформа и#nbsp;экосистема» подразумевает, что покупателю доступны как товары, так и#nbsp;услуги, которые он#nbsp;заказывает и#nbsp;приобретает любым удобным для#nbsp;него способом. По#nbsp;сути, речь идет о#nbsp;переходе от#nbsp;разовых контактов клиента с#nbsp;магазином для#nbsp;покупки отдельных материалов к#nbsp;его непрерывному сопровождению на#nbsp;всех этапах ремонта или строительства. С#nbsp;точки зрения ИТ-систем это означает запуск множества сервисов, оркестрацию процессов, построение композитных сервисов и#nbsp;большой объем работ по#nbsp;интеграции с#nbsp;различными внутренними сущностями: мастер-данными, микросервисами, системами оркестрации бизнес-процессов, а#nbsp;также с#nbsp;окружающей компанию экосистемой. При этом у#nbsp;бизнеса имеются определенные требования к#nbsp;скорости изменений бизнес-процессов и#nbsp;систем, расходам и#nbsp;качеству внутренних продуктов, выражаемых через метрики (время вывода продукта на#nbsp;рынок; надежность, доступность и#nbsp;простота сервисов; совокупная стоимость внесения изменений в#nbsp;бизнес-процессы; прозрачность и#nbsp;прогнозируемость).

Ясно, что без архитектуры, позволяющей быстро и#nbsp;гибко менять ИТ-ландшафт, оперативно реагировать на#nbsp;неопределенности, обеспечивать требуемую скорость изменений и#nbsp;надежность решений и#nbsp;сервисов в#nbsp;условиях ограничений по#nbsp;стоимости, невозможно воплотить в#nbsp;жизнь бизнес-модель «Платформа и#nbsp;экосистема».
Рис.2 Грануляризация сервисов, переход от#nbsp;IaaS к#nbsp;FaaS
Современная ИТ-инфраструктура «Леруа Мерлен» основана на#nbsp;грануляризации сервисов (рис. 2), предполагающей смену акцентов от#nbsp;виртуализации к#nbsp;контейнеризации и#nbsp;FaaS (Function as#nbsp;a#nbsp;Service) [1]. Виртуализация остается, но#nbsp;появляется новый уровень абстракции, доступный командам. Сервисы становятся более специализированными, и#nbsp;появляется возможность независимо проводить изменения, масштабируя их#nbsp;разработку и#nbsp;развитие. Однако грануляризация усложняет управление и#nbsp;оркестрацию множества различных сервисов. Кроме того, поскольку невозможно сразу перейти к#nbsp;микросервисному ландшафту, неизбежно, на#nbsp;протяжении некоторого времени, параллельное существование унаследованных монолитных приложений.

На#nbsp;уровне глобальной группы компаний ADEO, в#nbsp;которую входит сеть «Леруа Мерлен», были сформулированы основные принципы архитектуры поддержки бизнес-модели «Платформа и#nbsp;экосистема»:

—#nbsp;рациональность (Rationality)#nbsp;— оптимизация использования ресурсов, устранение дублирования и#nbsp;размывания усилий за#nbsp;счет максимального повторного использования уже готовых программных компонентов, оптимизация команд и#nbsp;их#nbsp;максимальная эффективность при использовании имеющихся ресурсов;

—#nbsp;модульность (Modularity)#nbsp;— разделение любой системы или процесса на#nbsp;множество независимых модулей с#nbsp;возможностью их#nbsp;рекомбинации для#nbsp;изменения бизнес-процессов и#nbsp;создания новых бизнес-моделей;

—#nbsp;связность (Connectivity)#nbsp;— возможность быстрой интеграции компонентов и#nbsp;обеспечения прозрачности обмена между ними.

Такая архитектура исключает любую централизацию и#nbsp;предусматривает максимальную автономность продуктовых команд для#nbsp;исключения образования «бутылочных горлышек», способных замедлить или даже блокировать любые изменения.

Основа реализации стратегии грануляризации приложений#nbsp;— это API и#nbsp;интеграция. Для#nbsp;обеспечения независимости изменений с#nbsp;учетом сложности системы, различий в#nbsp;технологиях и#nbsp;циклах выпуска релизов, ИТ-системы инкапсулируются с#nbsp;помощью стандартизированных интерфейсов, становясь изолированными объектами. Интерфейсы подробно документируются, размещаются в#nbsp;едином каталоге, доступ к#nbsp;ним контролируется, выполняется мониторинг их#nbsp;соглашений об#nbsp;уровне обслуживания (SLA), а#nbsp;также собирается аналитика по#nbsp;их#nbsp;использованию. Это позволяет минимизировать возможный хаос и#nbsp;обеспечить порядок на#nbsp;уровне архитектуры предприятия.
Рис.3 Трехслойная модель API
Все API разделены на#nbsp;три слоя (рис. 3), что в#nbsp;конечном счете определяет топологию всех сервисов.

—#nbsp;Слой объектных интерфейсов (Object API) —#nbsp;набор небольших, линейно независимых функций доступа к#nbsp;данным. На#nbsp;этом слое находятся репозитории CRUD (create, read, update, delete) мастер-данных, унаследованные приложения, лицензионное коммерческое коробочное#nbsp;ПО и#nbsp;части глобальных ИТ-продуктов группы ADEO.

—#nbsp;Слой бизнес-процессов и#nbsp;оркестрации (Process API) —#nbsp;функционал единых бизнес-правил компании.

—#nbsp;Слой адаптации (Experience API) —#nbsp;средства адаптации к#nbsp;конкретным прикладным задачам: сервисы класса Back-End-for-Front-End; ПО#nbsp;для мобильных и#nbsp;десктоп-приложений; функционал композитных сервисов (mash-up); средства интеграции с#nbsp;партнерами, клиентами и#nbsp;окружающей компанию экосистемой; бизнес-логика приложений, специфичных для#nbsp;конкретных видов бизнеса.

К#nbsp;разным уровням применяются разные требования и#nbsp;процессы контроля. Например, за#nbsp;ПО мобильного приложения для#nbsp;клиентов из#nbsp;слоя Experience API отвечает команда мобильного приложения, в#nbsp;то#nbsp;время как к#nbsp;приложениям учета запасов товара на#nbsp;складе слоя Object API предъявляются достаточно высокие требования к#nbsp;качеству и#nbsp;предусмотрен жесткий контроль со#nbsp;стороны корпоративных архитекторов.

Таким образом, в#nbsp;компании появился набор линейно независимых сервисов, доступных из#nbsp;единого каталога, на#nbsp;базе которых команды сами могут строить свои процессы, используя облачные технологии, инструменты медиации (работа с#nbsp;ПО разного уровня, «прослойками») и#nbsp;управления API, в#nbsp;полной мере применяя подход low-code, ускоряющий путь от#nbsp;формулировки бизнес-задачи до#nbsp;готового решения. Не#nbsp;требуется ждать, пока разработчик реализует соответствующий сервис,#nbsp;— бизнес-пользователь может самостоятельно создавать требуемое приложение.

Для#nbsp;управления интеграцией используется инструментарий API Management для#nbsp;работы с#nbsp;распределенными интерфейсами. В «Леруа Мерлен» имеется свой единый хаб, позволяющий интегрировать различные медиаторы (посредники#nbsp;— шаблоны для#nbsp;обеспечения взаимодействия объектов, избавляющие их#nbsp;от#nbsp;необходимости явно ссылаться друг на#nbsp;друга): шлюзы, сервисную сеть (Service mesh, уровень поддержки межсетевого взаимодействия сервисов) и#nbsp;брокеры сообщений (рис. 4).
Рис.4 API Management
В#nbsp;отличие от#nbsp;классических подходов, инструменты API Management в#nbsp;«Леруа Мерлен» используются не#nbsp;только как внешний фасад, но#nbsp;и#nbsp;как платформа поддержки внутренних коммуникаций между командами.

В#nbsp;ИТ-ландшафте «Леруа Мерлен» не#nbsp;предполагается имплементация какой-либо логики в#nbsp;интеграционных медиаторах: вся логика строится самими командами, а#nbsp;остатки унаследованной корпоративной шины данных плавно выводятся из#nbsp;эксплуатации. Все публикации и#nbsp;подписки на#nbsp;интеграционные потоки выполняются командами самостоятельно.

На#nbsp;портале публикуются не#nbsp;только интерфейсы на#nbsp;базе HTTP-протоколов, но#nbsp;также gRPC, топики (классификаторы событий брокера Kafka) и#nbsp;очереди на#nbsp;брокерах сообщений.

Архитектура портала дает возможность одновременно использовать различные медиаторы: Istio, API Gateway, Kafkа, RabbitMQ и#nbsp;брокеры NATS. Для#nbsp;оркестрации, разработки API и#nbsp;микросервисов используется подход low-code (рис. 5).

Большой объем бизнес-задач в#nbsp;«Леруа Мерлен» до#nbsp;недавнего времени не#nbsp;удавалось оперативно решать в#nbsp;рамках имеющихся ресурсов, поэтому возникла необходимость в#nbsp;поиске новых подходов. Однако ни#nbsp;одно из#nbsp;доступных на#nbsp;рынке интеграционных решений (Mule, Software AG, WSO2 и#nbsp;пр.) не#nbsp;позволяло в#nbsp;полном объеме решать все задачи компании, поэтому было принято решение создать свою корпоративную облачную платформу Platformeco, доступную продуктовым командам в#nbsp;режиме PaaS и#nbsp;позволяющую разрабатывать микросервисы, формировать интеграционные потоки и#nbsp;API в#nbsp;графическом интерфейсе, а#nbsp;затем разворачивать их#nbsp;в#nbsp;облаке, получая функциональность непрерывной интеграции и#nbsp;непрерывной доставки (CI/CD), автомасштабирования, транспорта между средами, мониторинга и#nbsp;пр.
Рис.5 Platformeco: имплементация low-code
С#nbsp;точки зрения команд, Platformeco#nbsp;— это облачный сервис. Проекты разворачивают изолированно друг от#nbsp;друга для#nbsp;исключения сильной связности между ними и#nbsp;обеспечения автономности продуктовых команд. Это позволяет увеличить производительность работы команд за#nbsp;счет демократизации технологий, привлечения аналитиков и#nbsp;разработчиков пользовательских интерфейсов к#nbsp;оркестрации сервисов и#nbsp;разработке функционала бизнес-логики, что сокращает цепочки коммуникаций. Квалифицированные разработчики бизнес-функционала, в#nbsp;свою очередь, фокусируются на#nbsp;архитектуре, сложных задачах (кейсах), создании плагинов и#nbsp;коннекторов для#nbsp;системы. Например, в#nbsp;команде разработки и#nbsp;поддержки мобильных приложений нет выделенных инженеров и#nbsp;разработчиков функционала#nbsp;— все конфигурируется либо аналитиками, либо разработчиками пользовательских интерфейсов. Такая оптимизация команд позволила в#nbsp;целом по#nbsp;компании вдвое сократить фонд оплаты труда.

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

В#nbsp;целом для#nbsp;платформы было разработано более 120 единиц потоков бизнес-логики и#nbsp;API#nbsp;— сегодня Platformeco ежедневно обеспечивает выполнение более 5 млн операций; с#nbsp;ней работают более 30 тыс. пользователей из#nbsp;более сотни магазинов торговой сети. Время запуска нового функционала и#nbsp;внесения изменения сократилось более чем в#nbsp;15 раз по#nbsp;сравнению с#nbsp;предыдущими подходами, и#nbsp;более чем в#nbsp;20 раз уменьшилось время на#nbsp;локализацию инцидентов за#nbsp;счет встроенного сквозного мониторинга. В#nbsp;конечном счете втрое сократилось время вывода на#nbsp;рынок новых бизнес-проектов. Кроме того, за#nbsp;счет стандартизации существенно упростилось проведение организационных изменений: передача функций между командами, перераспределение сотрудников по#nbsp;командам, подрядчикам и#nbsp;т.#nbsp;д.

Полный инструментарий Platformeco используется более чем 30 продуктовыми командами «Леруа Мерлен». Сегодня платформа обрабатывает более 8 млрд бизнес-транзакций в#nbsp;месяц.

Интеграционная и композиционная платформа Platformeco активно развивается: к#nbsp;ней подключаются новые бизнес-подразделения компании по#nbsp;всему миру, а#nbsp;функционал расширяется в#nbsp;том числе за#nbsp;счет открытых плагинов, созданных сообществом пользователей Platformeco. Кроме того, платформа интеграции и#nbsp;соответствующие методики предлагаются внешним заказчикам из#nbsp;других областей: финансов, страхования, телекома и#nbsp;пр.

Литература

  1. Симон Айсманн, Максимилиан Швингер, Йоханнес Громанн, Николас Хербст, Джоэл Шойнер, Эрвин Ван Эйк, Александру Йосуп, Кристина Абад. Бессерверные приложения: почему, когда, как? // Открытые системы.СУБД. —#nbsp;2021. —#nbsp;№ 1. —#nbsp;С. 14−16. URL: www.osp.ru/os/2021/01/13 055 828 (дата обращения: 21.04.2021).
  2. Александр Бондарик (Aleksandr.Bondarik@platformeco.ru)#nbsp;— CPO Platformeco (Москва).