Об оптимизации закупочной деятельности мы впервые задумались ещё в 2019 году. Создавать облачный сервис для некоммерческих закупок (закупок для нужд компаний) B2B Altis мы решили в нестандартном для российского рынка партнерстве, когда ритейлер выступает не просто заказчиком решения, но и его соразработчиком. В качестве партнера была выбрана крупнейшая коммерческая площадка электронных торгов B2B-Center. Партнерство открывало доступ к проверенной базе российских поставщиков - 574,6 тысячам контрагентов.

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

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

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

До трансформации мы использовали процессы логистики в SAP ERP и закупочные процедуры SAP SRM. Теперь же мы создали единую технологическую платформу, которая включает необходимый инструментарий, процессы и экспертизу, а также: 

  • уменьшать сроки (не более 38 дней на весь закупочный цикл), 

  • повышать эффективность (сокращать издержки за счет сквозных процессов), 

  • связывать все модули в едином окне, 

  • вводить статусную схему и матрицу согласований, 

  • убирать комплаенс-барьеры и налаживать сотрудничество с поставщиками

  • настраивать репликацию из/в ERP-систему, 

  • создавать конструктор договоров 

  • централизовать функции до  85%.

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

Пилотирование системы началось в 2020 году с внедрения отдельных модулей (сбор заявок, управление поставщиками, поиск поставщика, закупки из каталога, управление нормативно-справочной информацией, контрактный модуль и управление поставками) в корпоративный портал закупок М.Видео-Эльдорадо. 

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

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

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

При этом на разработку новых функций на базе SAP ушло бы несколько лет. Ограничения ERP-системы, с которыми столкнулись: например, в ERP не было конструктора договоров, а “заявка” не использовалась из-за ограничений в стандарте. 

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

Разработка  

Разработка B2B Altis построена как сквозной процесс (от проверки гипотез до постановки на поддержку) - в едином инфополе для 10-15 продуктовых команд. Прозрачность продуктовых планов (стратегии, OKR, фич и инициатив) обеспечивается с помощью сочетания Jira + Confluence + Miro + Telegram. 

Организационно мы приняли решение, что М.Видео-Эльдорадо и B2B-Center работают в формате партнёрского взаимодействия вместо распространённой парадигмы исполнитель-заказчик. Мы объединили ритмы проектных и продуктовых групп, создали единое пространство для координации и взаимодействия. Правильно организованные командные события и встречи при создании совершенного нового продукта позволяют связать текущие цели с заявленной стратегией. Мы ориентировались на SCRUM и часть вещей позаимствовали из LESS и KANBAN. Команда выбрала эволюционный путь и взяла из разных практик, подходов и фреймворков те, что соответствовали жизненному циклу продукта и зрелости объединённой команды.

Заказчиком продукта выступают бизнес-подразделения, которые выдвигают гипотезы и осуществляют синхронизацию разработок с потребностями внутри компании на уровне директоров по продуктам. Мы видим свою задачу в том, чтобы максимально автоматизировать рутинные функции и избавить программистов от того, что по силам бизнес-аналитикам (проектирование бизнес-процесса, моделей данных, экранных форм). С помощью дизайн-системы CDS на фреймворке Vue.js бизнес-пользователь получает возможность формулировать требования и самостоятельно корректировать результат. Дизайн-система помогает сократить сроки разработки и расходы на поддержку - позволяет показать потребителю перспективный интерфейс на ранних стадиях, а также получить обратную связь по ожиданиям от бизнес-коллег. Дизайнеры могут сосредоточиться на сценариях и качестве, а разработчики - использовать готовые компоненты и не тратить время на фронтенд-дизайн. 

Погружать сотрудников в специфику работы с тендерами помогает цифровое рабочее место - внутренний портал, в который встроена база знаний и чат-бот на базе ML. Это решение помогает улучшить пользовательский опыт взаимодействия с базами знаний. Таким образом, сотрудники могут быстро узнать, как запустить закупку, осуществить сервисное обслуживание товара, а также получить ответы на операционные вопросы. База знаний, на которую опирается чат-бот с ML-движком, распознаёт естественный язык и способна с заданной вероятностью выдать подходящий ответ либо соединить с оператором. 

Вернёмся к специфике основного периметра нашего продукта и продуктовому процессу разработки. Особенность B2B-продуктов состоит в сильном влиянии бизнес-процессов компаний-клиентов и стейкхолдеров на разработку и конфигурацию бэклога продукта. Это, в свою очередь, оставляет значительный отпечаток в модели приоритизации. Многие менеджеры продуктов из B2B-сферы могут позавидовать коллегам из B2C обладающим, как правило, большим объемом данных о пользователях и пространством для экспериментов.  

В нашем случае, если компания готова платить за функционал деньгами, то на раннем этапе этот факт значительно повышает confidence level в модели RICE, которую мы выбрали для приоритизации. В такой парадигме цикл discovery протяжённей, и мы стараемся удержать баланс между предиктивными методами проектирования и дизайн-мышлением.

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

Пример приоритизации бэклога верхнего уровня: ключевые сценарии распределены по соответствию целям (ось y) сложности реализации (ось X) и размеру круга (масштабируемость на рынке - какое число клиентов желают аналогичные возможности). Это позволяет спланировать релизы с учётом ключевых факторов успеха продукта на рынке.

На более детальном уровне бэклог структурируется в эпики (группы тикетов) по командам и субпродуктам. Задачи в Jira вместе с командой заносит тимлид, который проговаривает детали и получает фидбэк, что команда согласна с поставленными задачами. Так, например, производственный процесс команды (бэклог продукта) включает решение таких тасков, как: создание FSD, HLD, LLD и их размещение в Confluence, составление плана найма сотрудников для покрытия задач (например, если команде не хватает DevOps-инженера), покрытие unit-тестами более 80% функционала, разработка регламента проведения кросс-ревью кода у разработчиков, реализация шага демонстрации разработанной функциональности, разработка регламента валидации тестовых сценариев аналитиками, внедрение EasyBI (подсчёт метрик на операционном уровне и выгрузка отчётов в .json промежуточную базу ClickHouse), занесение всех инцидентов в Assyst и создание дашбордов для мониторинга доступности продукта. Закрывая задачи, все команды в обязательном порядке оставляют комментарии к задачам, ведь дьявол кроется в деталях. 

Product manager, который является связующим звеном между бизнесом, разработчиками и дизайнерами, не просто перекидывает мяч между частями команды, а понимает, как работает продукт, что делает его востребованным, как он встраивается в бизнес-модель клиента и компании-разработчика. В его задачи входит помощь с проверкой гипотез без привлечения дополнительных ресурсов. Для быстрого выхода продукта PM и аналитики регулярно проходят обучение, в том числе по использованию CDS. 

В разработке команды опираются на обширный технологический стек, а для быстрого разворачивания инфраструктуры задействуют уже зарекомендовавшую себя контейнерную виртуализацию Kubernetes в связке с Ansible, а также проверенные временем гипервизоры - HyperV и KVM.  

B2B Altis - платформа с универсальными моделями данных и пользовательским интерфейсом, реализованная в виде модулей для закупок (Управление НСИ, Тендеры, Закупки из каталога, Заявки , Оценка поставщиков, Контракты), которые могут работать и развиваться по отдельности. 

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

В рамках интеграции SAP ERP и B2B Altis осуществляется обмен мастер-данными (контрагенты, материалы, структура компании, аналитика бизнес-объектов) и бизнес-объектами (заявка, контракт, заказ на поставку). На верхнем уровне B2B Altis выступает в роли пользовательской системы, в которой заложена бизнес-логика, а в SAP ERP –  бэкофис-процессы, где ведутся финансовый и управленческий учёты. Например, управление договорами осуществляется в B2B Altis в  модуле управление договорами, а уже далее бюджетный контроль остается в ERP-системе. 

Обмен данными выполняется в обе стороны (в основном мастер-данные передаются из ERP в B2B Altis, бизнес-объекты -  из B2B Altis в ERP), как синхронно, так и асинхронно с возможностью отправки подтверждений. В связи с тем, что B2B-Center находится вне контура М.Видео-Эльдорадо, все запросы к SAP ERP (во внутренний контур) проходят через единый шлюз API Gateway (nginx + WSO2 API Manager). Также в качестве системы централизованного управления интеграцией используется корпоративная интеграционная шина – SAP Process Integration (SAP PI). SAP PI выполняет задачи получения/отправки сообщений, обработки дополнительной логикой, маршрутизации и преобразования сообщений. 

При передаче сообщений с бизнес-объектами используется структура сообщения аналогичная IDoc бизнес-объекта.  Для аутентификации в B2B Altis используется Single sign-on (SSO) на базе Keycloak. Из-за ограничений технологического стека Keycloak (необходима поддержка OAuth 2.0, OIDC, а также JSON Web Token) мы решили сделать доработки на своей стороне. 

Итоги

Внедрение B2B Altis позволило М.Видео-Эльдорадо создать аналог “интернет-магазина” некоммерческих закупок внутри компании. Средний срок проведения тендерных процедур и сроки согласования договоров уже сократились на 20%, а среднее количество участников конкурентных процедур выросло в 2 раза по сравнению с использованием решения на базе SAP SRM. 

В ситуации санкционного давления и дефицита товаров с помощью сквозного сервиса закупок мы можем мониторить рынок, находить новых поставщиков, отслеживать актуальную информацию по наличию продукции у контрагентов, в онлайне получать лучшие цены. Дальнейшее развитие системы мы видим в последовательной автоматизации b2b-процессов закупок, и на сегодня фокус сосредоточен, в том числе на масштабировании решения SAP xDE (ЭДО) в некоммерческие закупки.

Комментарии (0)