• 526

    Заявлено проектов

  • 443

    Опубликовано проектов

  • 164

    Оставлено комментариев

  • 1485

    Количество голосов

  • 22

    Дней до окончания голосования

← Вернуться к списку

Giperplace - E-COM система для автоматизации работы с маркетплейсами

  • Руководитель проекта со стороны заказчика

  • Категория

  • Номинация

  • Цели

    Цель проекта – автоматизировать внутренние процессы нашей компании (ООО «Гипер») по работе с маркетплейсами (Ozon, Wildberries, Yandex, МегаМаркет и др) с большим объемом данных (магазины, склады, SKU) таким образом, чтобы все процессы (от создания карточки, до продаж и финансового учета) были автоматизированы, в том числе и процессы складской обработки. 

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

  • Сроки выполнения

    декабрь, 2023 — август, 2024
  • Год завершения проекта

    2024

  • Масштаб проекта

    6400 человеко-часов
  • Результаты

    Система внедрена и запущена для внутреннего заказчика (ООО «Гипер»). 

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

    Также автоматизированы рабочие места склада, где формирование отгрузочных этикеток, документов и актов приема-передачи так же происходит автоматизировано. 

    Реализована автоматизация работы с динамическим ценообразованием, работа с акциями и продвижением, работа с отзывами и вопросами клиентов. 

    Настроена система логирования, система аларм-тикетов и уведомлений, несколько уровней защиты как хранения данных, так и анализа получаемых данных (например, защита от некорректных цен продажи – «карантин цен»)

  • Уникальность проекта

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

    Наша система  GiperPlace заточена под работу с большим объемом данных и обеспечивает высокоскоростной обмен с учетными системами. 

    На сегодняшний день система обеспечивает обмен для каждого подключенного клиента с более чем 100 магазинами (более 3 000 000 SKU) на маркетплейсах, и способна обрабатывать до 10 000 заказов в минуту. При этом скорость полного цикла обмена (от получения заказа с одной площадки, до попадания его в систему и изменению остатка на всех остальных площадках) менее 1 минуты.

  • Использованное ПО

    Виртуальные сервера на Ubuntu, OpenVPN, phpShtorm, GitHub

  • Решение из каталога Global CIO

    В проекте не используются решения из каталога Global CIO

  • Сложность реализации

    На протяжении проекта основная сложность заключалась в том, что все внутренние процессы работы с маркетплейсами меняются стремительно. Аналогичные изменения вносятся и в API площадок. Подстраиваться приходилось «на ходу» и на протяжении проекта многие модули могли переделываться по несколько раз, либо вообще терять свою актуальность в ходе работы. А после запуска системы и полной автоматизации рабочих мест – важно было полностью исключить «простой» системы. Цена простоя могла стоить до 2 млн рублей в час

  • Описание

    Наша компания (ООО «Гипер») на протяжении многих лет занимается продажей и дистрибуцией бытовой техники и электроники во всех онлайн-каналах России и Странах СНГ. Не имея полной автоматизации всех процессов обработки заказа, мы бы не смогли добиться таких результатов продаж. Именно поэтому мы и начали разрабатывать и внедрять у себя данный проект по автоматизации. Система GiperPlace поддерживает все возможные схемы работы с маркетплейсами – FBS, FBO, RealFBS/DBS, Ex[ress и позволяет в кратчайшие сроки запустить и автоматизировать продажи на всех маркетплейсах РФ и стран СНГ – Wildberries, Ozon, Яндекс.Маркет, МегаМаркет, М.Видео и многих других. Автоматизация подразумевает под собой все процессы работы с площадками: от создания карточек товара на витринах, передачи остатков и цен, обработки заказа, до самого финального шага – автоматизация процессов обработки на складе и отправка заказа получателю

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

  • География проекта

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

  • Дополнительные презентации

Комментировать 11

Комментировать могут только авторизованные пользователи.
Предлагаем Вам в систему или зарегистрироваться.

  • Александр Сырнов

    Александр Сырнов

    ООО "КЦ "ЭДИСОН"

    Руководитель ИТ

    Подскажите, а как Вы обошли проблему с многосоставными заказами, когда его нужно "разбить" на отправления кратно коробам, учитывая габариты товара и вес отправления?У меня склад уже 2 года такие заказы в ручном режиме обрабатывает, подгоняя отправления под фактически сформированные короба отправлений.Вопрос актуален, если у Вас это эксплуатируется.Спасибо.
    Ответить
    • Алексей Смирнов

      Алексей Смирнов

      ООО "Гипер"

      Директор по ИТ

      Добрый день. Это и правда очень "узкое" место, ведь изменить состав отправлений после разбивки уже невозможно (т.е. нет права на ошибку при разбивке). При этом, площадки могут штрафовать за полу-пустые короба. Деление заказа на отправления должно работать без ошибок и учитывать все факторы, в т.ч. габариты товаров сложных форм (например сковородки с ручкой), ограничения площадок по максимальному весу отправления (например у Озона это 25 кг), учитывать возможные вариации стандартизированных на складе размеров короба и т.д.Мы разработали алгоритм, который учитывает все эти факторы и формирует разбивку заказа кратно нашим стандартным коробам на складе, учитывая в том числе дополнительную упаковку товара (например стрейч пленка или пупырчатая пленка, которые добавляют объем товару). Учитываем как внешние габариты короба, так и внутренние. Создаем виртуальную сетку короба, которую наполняем товаром "поворачивая" его в разные стороны и ищем оптимальный короб(а) для каждого заказа. На протяжении нескольких месяцев алгоритм тестировался и дорабатывался, благодаря чему на сегодняшний день мы имеем алгоритм, работающий без ошибок.Единственный важный фактор - это иметь корректно заполненные габариты для каждого товара. Это монотонная и рутинная работа, которую пришлось проделать нашему складу, что бы перемерить все габариты и внести их в базу.
      Ответить
      • Александр Сырнов

        Александр Сырнов

        ООО "КЦ "ЭДИСОН"

        Руководитель ИТ

        Алексей, благодарю за ответ.Есть еще небольшое уточнение - вы говорите что разработали алгоритм для Ваших стандартным коробам.А если у Вас появляются новые стандарты размеров, при чём оперативно и сразу, допустим, плюс 10 вариантов дополнительно. Эти характеристики как оперативно попадают в Вашу автоматизированную систему - несколько кликов в вашей системе или это также дополнительные трудозатраты Ваших разработчиков?Спасибо.
        Ответить
        • Алексей Смирнов

          Алексей Смирнов

          ООО "Гипер"

          Директор по ИТ

          Александр, спасибо за вопрос.Мы такие ситуации предусматривали заранее, поэтому заложили в реализованную систему возможность такого функционала.Здесь не требуется дополнительная разработка, поскольку в интерфейсной части администратора системы есть функция, которая позволяет вносить дополнительные размеры. При этом всё равно проводится дополнительная аналитика поступивших вводных согласно внутреннему регламенту при работе с системой, чтобы не было "опрометчивых" данных.
          Ответить
  • Эдуард Дамм

    Эдуард Дамм

    ГК Энерго

    Руководитель Управления ИТ

    Добрый день.А ценами на товары Ваша система тоже управляет? Учитываются ли все комиссии и прочие расходы площадок в цене, что бы "не торговать в минус"?
    Ответить
    • Алексей Смирнов

      Алексей Смирнов

      ООО "Гипер"

      Директор по ИТ

      Здравствуйте!На протяжении всего внедрения проекта в нашу инфраструктуру, логика ценообразования пересматривалась несколько раз. В итоге мы исторически имеем несколько возможных схем работы с ценами:1. Цена формируется в нашей учётной системе и передается на площадку без каких либо доп.проверок и изменений,2. Учётная система передает в систему вводные данные (например - закупочная цена, РРЦ и тд). Система по заданным правилам формирует цену продажи, учитывая желаемую маржинальность на выходе при всех комиссиях и доп.расходах площадок,3. Берем цены из внешних источников (например, правила ценообразования диктует держатель бренда). 4. Гибрид пункта 2 и 3 - когда есть вводные данные из внешнего источника и дополнительные правила ценообразования,5. Репрайсер для динамического ценообразования. Мы парсим площадки и конкурентов, собираем информацию о ценах, соинвестах и иную информацию с витрин. Задаем стратегии ценообразования (например преследование конкурента) и динамически меняем цену на товар в зависимости от текущей ситуации. При этом так же есть проверка на "минимальную" цену, ниже которой продажа будет не рентабельнаПри этом, все схемы можно гибко настраивать - в зависимости от потребностей менеджеров, ту или иную логику ценообразования можно задать для разных площадок, разных магазинов внутри площадки или разных брендов внутри магазина. А так же задавать индивидуальную логику для каких то точечных товаровТак же, мы внедрили собственный "карантин цен", что бы избежать нежелательных ошибок с ценами. Человеческий фактор или иные ошибки неизбежны и мы такие ситуации отлавливаем и блокируем изменение цен для таких товаров, оповещая менеджеров.
      Ответить
      • Эдуард Дамм

        Эдуард Дамм

        ГК Энерго

        Руководитель Управления ИТ

        Спасибо!
        Ответить
  • Эдуард Дамм

    Эдуард Дамм

    ГК Энерго

    Руководитель Управления ИТ

    Подскажите, а работа с вопросами/отзывами как то автоматизирована у вас? Если да - то как?
    Ответить
    • Алексей Смирнов

      Алексей Смирнов

      ООО "Гипер"

      Директор по ИТ

      Добрый день. И да и нет)Сам процесс внутри компании частично автоматизирован, но не данным продуктом. Используем сторонние решения.Но реализовали у себя интересные фичи на базе данных блоков.Например, на базе "чатов с клиентом" мы реализовали рассылки сообщений. Сценарии могут быть разные:-например, по смене статуса заказа - клиент может получить уведомление от нас с промокодом на следующую покупку,-сегментированные тематические рассылки,-и т.д.Так же в ответах на отзывы внедрили нативные рекомендации, которые органично добавляются в ответ и ссылаются на связанные артикулы с товаров.Поле для творчества безгранично!
      Ответить
  • Максим Каранкевич

    Максим Каранкевич

    Ультрамар

    Директор по цифровой трансформации

    Алексей, расскажите, пожалуйста, подробнее о технологическом стеке проекта и технологии управления проектом. Что использовали водопад или гибкие методологии?
    Ответить
    • Алексей Смирнов

      Алексей Смирнов

      ООО "Гипер"

      Директор по ИТ

      Максим, добрый день!Стек в процессе реализации проекта несколько раз пересматривался. Изначально, весь проект писали на php фрэймворк Symphony. Но в перспективе, мы приняли решение разделять стек в зависимости от функционала сервиса. В итоге, часть микро-сервисов так и остались на php, частично ушли на Node JS, на Go и TypeScript. БД postgree, а фронт (пользовательская админка) на React.Технологии управления проектом так же претерпели несколько итераций.Стартовали мы, придерживались Waterfall, последовательно двигаясь от этапа к этапу. И на тот момент это было логично, учитывая, что команда на старте была не большая, а четкого понимания архитектуры не было. Также не было сформулированного ФЗ от бизнеса. Старт был крайне хаотичный.В процессе разработки и внедрения первых MVP версий продукта начало формироваться и у нас и у бизнеса четкое понимание того, какой продукт мы ожидаем увидеть на выходе. После этого мы пересмотрели архитектуру, усилили команду разработки и в больше степени стали придерживаться технологий Scrum, деля проекты на задачи и спринты, налаживая коммуникацию между командами и внутри команд.
      Ответить
  • Заказчик

    ООО "Гипер"

    ООО "Гипер"

  • ИТ-поставщик

    ООО "Гипер"

    ООО "Гипер"

Мы используем файлы cookie в аналитических целях и для того, чтобы обеспечить вам наилучшие впечатления от работы с нашим сайтом. Заходя на сайт, вы соглашаетесь с Политикой использования файлов cookie.