Заказ снаружи, десятки систем внутри. Как менялся IT-ландшафт «Петровича»

Привет! Это Дима Левин, я работаю системным аналитиком в «Петрович-Тех». В прошлой раз я рассказывал о процессе обезличивания персональных данных. В этой статье я попытаюсь рассказать историю роста и развития IT-ландшафта компании «Петрович».

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

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

Это история о том, как IT-ландшафт «Петровича» вырос из одной системы в десятки специализированных и теперь движется к единой платформе. А заодно разберемся, чем занимается «Петрович-Тех» и почему его работу можно сравнить со строительством.

IT-ландшафт: не картинка, а система систем с четкими целями

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

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

У этой стройки есть практическая цель. Для бизнеса IT важен не своими красивыми названиями систем, а тем, что именно на нем держится:

• прием заказа из удобного клиенту канала - офлайн или онлайн;

• показ корректного товара, цены и доступности;

• сборка заказа на нужном складе;

• выбор способа доставки и построение маршрута;

• проведение оплаты, оформление документов и, если нужно, возврата;

• сохранение данных для анализа и улучшения сервиса.

Этот набор задач в «Петровиче» поддерживает целая цифровая экосистема, которую развивает «Петрович-Тех». В инструментарии команды - 1С, Java, PHP, JavaScript, React, Python, Kubernetes, Kafka, S3, ClickHouse, PostgreSQL, ML и десятки других технологий. Но дело не в списке, а в том, что рядом уживаются старое и новое: монолитные учетные системы соседствуют с микросервисами, мобильные приложения - с облаком, а данные держат в порядке десятки специализированных сервисов.

Именно так выглядит IT крупного бизнеса: не единая система на все, а связанный набор продуктов. Как на стройке - одним краном можно поднять многое, но для полноценного объекта понадобятся еще бетономешалка, уровень, рулетка и бригадир, который знает, зачем все это нужно.

Когда-то все помещалось в одну ERP

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

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

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

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

Рост нагрузки, зрелость бизнеса и усложнение операционных процессов потребовали разделения функций. Для отдельных задач и контуров появились централизованная финансовая система (ЦФС), единый справочник номенклатуры (ЕСН), система зарплаты и управления персоналом (ЗУП), система складского управления (WMS) и отдельные базы для региональных дивизионов и исторических данных.

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

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

Новые каналы заказов

Следующий этап эволюции начался с изменения поведения клиентов и каналов продаж. К рознице и доставке добавились массовый e-com, цифровизация B2B, профессиональные покупатели, мобильные приложения, личные кабинеты и другие клиентские сервисы.

Раньше заказ создавался в привычном канале и дальше двигался по понятному операционному процессу. Теперь оформить покупку можно было через сайт, мобильное приложение, продавца в магазине или B2B-личный кабинет на том же сайте. Для поставщиков появились отдельные веб-платформы, для прорабов - специализированные сервисы «Петрович.BRO» и «ПроПетрович».

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

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

На практике эта экосистема выглядела так - системы все больше специализировались на конкретных бизнес-задачах:

• сайт и мобильные приложения отвечают за клиентский интерфейс;

• CRM поддерживает работу с оптовыми клиентами и транзитными заказами;

• CCS (система контакт-центра) обеспечивает омниканальную работу с клиентами;

• TMS (система управления транспортом и маршрутизацией) поддерживает расчет доставки, маршрутов и показателей рейса;

• CDP (платформа клиентских коммуникаций) отвечает за рассылки через SMS, e-mail, push и мессенджеры;

• Promo Engine - высоконагруженная система процессинга лояльности - обрабатывает программы «Клуб друзей» и «Союз отважных», а также персональные предложения;

• ESB (корпоративная сервисная шина) распределяет электронные документы и данные между системами;

• EDM (система электронного документооборота и архивирования) закрывает задачи по договорам и хранению документов, а внешний EDI-контур обеспечивает юридически значимый обмен документами с контрагентами.

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

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

Эпоха данных

У такой экосистемы есть своя цена. Чем больше в ней доменов, тем больше данных рассеивалось по разным источникам: о заказе, товаре, клиенте, маршруте, доставке, возврате и коммуникациях. Каждая система хорошо справлялась со своей задачей, но данные о заказе, клиенте и операции оставались «лоскутными» - единой картины не было, хотя каждый источник был бизнесу нужен.

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

Ответом на эту потребность стала платформа данных - Data Platform. Она собирает, хранит, обрабатывает и предоставляет данные для аналитики и прикладных сервисов. В ее составе - Data Fabric: слой, связывающий распределенные данные, метаданные, правила доступа и способы предоставления данных пользователям и системам, а также облачное хранилище, ClickHouse, S3-хранилище и BI-система аналитики Data Lens.

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

Данные и их анализ перестали быть побочным эффектом операционной работы - теперь от них напрямую зависит развитие бизнеса.

OMS: система управления заказами

Все описанные этапы проходили постепенно, а не одномоментно - и часть работы над Data Platform продолжается прямо сейчас. Следующий шаг той же трансформации - проект, в основе которого система управления заказами OMS (Order Management System). Его цель - более гибкое распределение функций по целевым системам и более быстрая реакция ландшафта на изменения бизнеса. OMS связывает домены и оркестрирует движение заказа на всех этапах его жизни.

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

• Оформление. Заказ приходит из клиентского канала: сайта, мобильного приложения, контакт-центра или B2B-канала для юрлиц.

• Оркестрация. OMS принимает заказ и определяет следующий шаг: сборку, доставку или коммуникацию с клиентом.

• Учет и товар. Оперативная ERP, ЕСН и ЦФС предоставляют сведения о товаре, цене, контрагенте и условиях заказа.

• Склад и доставка. OMS передает задание в WMS, а затем - в логистический контур для расчета маршрута и выполнения рейса.

• Данные и коммуникации. События заказа поступают в Data Platform для аналитики; на их основе работают программы лояльности и персональные коммуникации.

Учетное ядро знает, как провести заказ по учету. WMS знает, как собрать товар. Логистический контур умеет строить рейсы. Канал продаж общается с клиентом. OMS не заменяет учет, склад или доставку - она связывает их в единый процесс, чтобы заказ не превращался в эстафету с потерянной палочкой между системами.

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

Преимущества такого подхода видны в нескольких местах

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

Петрович-Тех: строить системы, которые выдерживают бизнес

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

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

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

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

- Владислав Бердичевский, руководитель «Петрович-Тех»

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

Будущее уже наступает

Будущее «Петровича» связано не с отдельными технологиями, а с тем, как весь IT-ландшафт постепенно превращается в единую управляемую платформу, а не остается суммой разрозненных систем.

ML уже интегрирован в процессы «Петровича»: модели участвуют в прогнозировании спроса, оценке сроков, выявлении аномалий, оптимизации маршрутов и персонализации коммуникаций. AI встраивается в каналы продаж и операционные процессы. В перспективе трех-пяти лет - более глубокая интеграция: данные, аналитика и новые продукты должны расти вместе с Data Platform.

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

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

- Павел Галямичев, корпоративный архитектор «Петрович-Тех»

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

Уже полным ходом идет внедрение Data Governance: правил владения данными, требований к их качеству и доступу. Это особенно важно сейчас, когда генеративный ИИ уже работает с реальными клиентами - например, в «Нейрон Петрович».

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

«Петрович-Тех» в этом смысле тоже занимается строительством. Только его материалы - не цемент и арматура, а доменные модели, API, сервисы, данные и архитектурные решения. А хороший цифровой дом, как и обычный, начинается с проекта, выдерживает нагрузку и не должен шататься, когда в него одновременно заходят десятки тысяч клиентов.

Большое спасибо всем коллегам «Петрович-Тех» принявшим участие в подготовке материала! Отдельная благодарность корпоративному архитектору Павлу Галямичеву и руководителю отдела системного и бизнес-анализа Владимиру Смирнову.