Меня зовут Евгения Суржко. В этой статье я расскажу про проект, который мы делали для сети АЗС «Газпромнефть» и про то, с какими сложностями столкнулись во время его выполнения.
Особенности клиента и предпосылки проекта
Современная АЗС «Газпромнефть» давно перестала быть просто заправкой. Сегодня это полноценный розничный комплекс с широким ассортиментом товаров и услуг. Масштаб впечатляет: более 1500 точек по всей стране, свыше 11 000 активных товарных позиций и семь различных партнерских моделей управления станциями.
К 2020 году назрела необходимость в создании собственного программного решения. Существующее зарубежное ПО не только противоречило стратегии цифрового развития компании, но и ограничивало возможности оперативного развития функциональности. Бизнесу требовалась система, которая позволила бы централизованно управлять ассортиментом и ценами, была бы достаточно гибкой для быстрого внедрения изменений и при этом экономически эффективной с точки зрения стоимости владения.
Видение результата и уровни системы
Новая система, получившая название СТИУМ (Сопутствующие товары и управление магазином), должна была органично встроиться в существующие бизнес-процессы компании. При проектировании архитектуры учитывались три уровня управления: головной офис (HOS), бэк-офис на станциях (BOS) и кассовое ПО (POS). СТИУМ взял на себя два первых уровня - централизованное управление из офиса и процессы на уровне станций.
В качестве технологической платформы была выбрана «1С:Управление торговлей» - это решение наилучшим образом соответствовало требованиям проекта. Партнером по разработке стала компания «КОРУС Консалтинг», обладающая необходимыми компетенциями в создании масштабных розничных систем.
Сложности и вызовы проекта
Сложность проекта определялась несколькими ключевыми факторами. Прежде всего, это необходимость интеграции с действующей ИТ-инфраструктурой компании. Нужно было не просто создать новую систему, а встроить ее в работающий механизм, не нарушив его функционирование. Это означало создание множества интеграционных связей как с существующими системами, так и с теми, что внедрялись или развивались параллельно.
Географическая распределенность сети создавала дополнительные сложности. АЗС работают во всех часовых поясах России, от Калининграда до Владивостока, и в каждом регионе есть своя специфика: разный уровень подготовки персонала, особенности местного менталитета, различия в организации процессов.
Технические требования также были весьма серьезными. ИТ-ландшафт компании включает как внутренний защищенный контур для собственных станций, так и внешний - для партнерских АЗС. При этом система должна была обеспечивать бесперебойную работу в режиме 24/7, ведь даже короткий простой на АЗС приводит к существенным потерям для бизнеса.
Таймлайн проекта
История проекта началась в сентябре 2020 года и продолжается до сих пор. Первый значимый результат был получен в апреле 2021 года, когда заработала базовая версия системы с функционалом управления станциями из центрального офиса. В течение следующих двух лет шло планомерное наращивание возможностей системы.
Важной вехой стал август 2023 года, когда был запущен функционал управления товародвижением на уровне станций. Сначала его запустили на двух АЗС, через месяц расширили пилот еще на три точки, а затем стали подключать к системе по 40-50 новых станций в неделю. Сейчас продолжается как развитие функциональности системы, так и ее тиражирование на новые станции сети.
Метрики проекта
За три с половиной года работы над проектом команда достигла впечатляющих результатов. Масштаб выполненных работ лучше всего иллюстрируют цифры: команда подрядчика посвятила проекту 60 тысяч часов, еще 25 тысяч часов вложили специалисты со стороны заказчика. За это время было реализовано около 1700 доработок функционала и выпущено 24 релиза системы.
Сегодня к системе подключено 431 АЗС, с ней работает более полутора тысяч пользователей, и эти цифры продолжают расти. Для обеспечения бесперебойной работы было создано 18 интеграций с различными системами компании, и это тоже не окончательное число – развитие продолжается.
Проектные решения
Одним из важнейших факторов успеха стал отказ от классического каскадного подхода в пользу гибкой методологии разработки. Вместо того чтобы пытаться сразу создать финальную версию продукта, команда начала с минимально жизнеспособного решения (MVP) и постепенно наращивала его функциональность. Этот подход применялся дважды: сначала при разработке модуля для головного офиса, затем – при создании функционала для работы на станциях.
Такое решение позволило избежать типичной для долгих проектов проблемы, когда к моменту завершения разработки требования успевают существенно измениться. Однако гибкий подход принес и свои сложности: пришлось продумывать промежуточные архитектурные решения и временные схемы интеграции.
Еще одним важным решением стал отказ от одномоментного запуска системы на всех станциях в пользу постепенного развертывания. Это потребовало дополнительных усилий по проектированию промежуточных состояний, когда часть сети работает в новой системе, а часть – в старой, но зато позволило сделать процесс внедрения более контролируемым и значительно снизить риски для бизнеса.
Важной особенностью проекта стало параллельное наращивание функциональности системы и ее тиражирование на новые станции. Такой подход позволил начать внедрение сразу после создания MVP, не дожидаясь разработки полного функционала. Однако это требовало постоянного обновления обучающих материалов, поскольку с каждым релизом появлялись новые функции и менялся интерфейс.
Для разработки и поддержки внедрения использовалась одна команда. Это обеспечило высокое качество поддержки: разработчики могли быстро решать возникающие проблемы и оперативно вносить корректировки. Однако планирование работ осложнялось непредсказуемостью процесса тиража – несмотря на резервирование времени на решение внезапных проблем внедрения, периодически приходилось оперативно перестраивать планы и менять приоритеты задач.
Организация и опыт тиражирования
Процесс тиражирования системы был организован по принципу нарастающей волны. Начали с двух станций в Санкт-Петербурге, где команда проекта могла лично присутствовать и оперативно решать возникающие проблемы. После анализа первого опыта и необходимых корректировок запустили еще три станции в разных регионах – Москве, Екатеринбурге и Новосибирске.
Постепенно наращивая темп, команда довела количество одновременно подключаемых станций до 41. Это позволило за четыре месяца – с февраля по май – запустить систему на 420 АЗС. Такой результат стал возможен благодаря тщательно проработанной системе подготовки персонала и поддержки пользователей.
Каждый сотрудник перед началом работы проходит обучение с использованием видеоматериалов и тестовой базы данных. После этого проводится проверка знаний и онлайн-консультация для ответов на возникшие вопросы. Особенно эффективным оказалось решение о создании института наставников – опытных сотрудников АЗС, которые первыми освоили систему и теперь помогают своим коллегам.
Ответ на главный вопрос и выводы
Отвечая на вопрос, который был вынесен в заголовок статьи — получили ли мы G-drive от проекта — можно с уверенностью сказать, что получили и получаем до сих пор. Об этом говорит как стабильность команды (за все время сменился только технический архитектор), так и качество созданного решения. Особенно ценно то, что удалось выстроить эффективное взаимодействие между командами заказчика и исполнителя, найти общий язык и создать атмосферу, где все участники готовы к конструктивному диалогу и поиску оптимальных решений.
Сегодня, проезжая мимо заправок «Газпромнефть», команда проекта испытывает особую гордость – ведь каждая из этих станций работает на созданном ими программном обеспечении. Но главное – проект продолжает развиваться, появляются новые идеи и задачи, что говорит о его востребованности и перспективности.
Опыт этого проекта показал, что даже в условиях жестких ограничений и высоких требований к надежности возможно создать современное, гибкое решение, которое не только решает текущие задачи бизнеса, но и создает задел для будущего развития.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.
