Хорошо, когда в рознице ценообразование ведётся размеренно, все акции продуманы, подготовлены с организационной точки зрения, настроены в ИТ-системах, поддержаны логистикой и реализуются по плану в автоматическом или полуавтоматическом режиме. Но на практике можно столкнуться с ситуацией ручного управления. И не просто ручного, а с оперативным реагированием на ситуацию в продажах, то есть с изменением цен и акций на лету. Да не просто в одном магазине, а в масштабной сети. Такие кейсы исключительны, в нашей практике он единичен, но даёт возможность рассказать о стандартных и нестандартных решениях. Это поможет вам разобраться с тем, как устроена история с розничными ценами с точки зрения ИТ.
Бизнес-ситуация. Клиент в этом кейсе – крупнейшая сеть DIY-гипермаркетов, которая в одночасье осталась без корпоративной ИТ-системы, включая почту, ERP, приёмку и учёт товаров, кассовое ПО и т.д. Требовалось реанимировать бизнес хотя бы в урезанном виде за месяц, что и было сделано. Мы в данной публикации остановимся на решении одной задачи, потому что она стояла особняком от остальных и занимался ею отдельный специалист Odyssey Consulting Group.
Потребность в гипергибкости. Запуск урезанной ИТ-системы происходил в высокий сезон, когда постоянно шли маркетинговые активности. Если в идеальном мире акции имеют фиксированное начало и конец и заданы для всего ассортимента, то в данном кейсе продолжительность могла меняться произвольно, причём для разных номенклатур. Это не было пренебрежением к здравому смыслу, а исключительно следствием вынужденного старта в условиях, когда бизнес не готов к ведению деятельности на все 100%, но последствия простоя ведут к еще большим потерям, чем ручной менеджмент.
Подзадачи. Запрос клиента был разделён на две подзадачи:
Первая подзадача решалась достаточно просто в рамках стандартной функциональности, зато вторая потребовала глубокого погружения в проблему в процессе поиска решения.
В идеальной ситуации вся ИТ-экосистема ритейлера (ну, почти вся) работает на одной платформе, а разные её части бесшовно интегрированы. В центральном офисе работает одна система, которая умеет рассчитывать цены. Когда на кассе в магазине формируется чек, она каждый раз обращается к центральной системе, отправляет ей так называемый «мягкий чек» – список номенклатуры и количество, которое хочешь купить покупатель. Система отвечает по каждой номенклатуре, какую цену нужно подставить, какую акцию применить. В этом случае цены рассчитываются в едином месте, и все кассы обращаются к этой системе. Любой другой подход ограничивает количество и вариативность доступных акций.
Идеальный вариант не мог быть реализован из-за использования различных систем и заказчику была представлена альтернатива, когда цены считаются в одной из двух систем, потом данные трансформируются и загружаются в другую систему.
Сделать центральной системой, к которой обращаются другие, кассовый SetRetail не удалось. Интерфейс не был приспособлен к вводу данных. Это скорее фронтенд для кассира, который подключается к внешней системе.
Конечный вариант, на котором мы остановились, состоит в том, что акции настраиваются в 1С, потом преобразуются в систему данных SetRetail, загружаются в кассы и там они должны отработать тем же способом. Преимущество в том, что можно считать скидки в обеих системах, то есть это хорошо с точки зрения омникальности: можно продать через 1С, через интернет-магазин, через офлайн-магазин. Минус в том, что эта интеграция сильно ограничивает нас в видах акций, которые можно использовать.
Как мы знаем, возможно различные варианты акций, например:
Мы настроили интеграцию по одному типу акций (скидку суммой), и он работает. Если завтра появится идея протестировать другой тип акции, например, процент от чека, нужно будет делать новую большую интеграцию. А каждая интеграция – это затраты на разработку.
Базовое внедрение решения, в рамках которого акции настраиваются в 1С, потом преобразуются в систему данных SetRetail, заняло меньше месяца. Потом потребовался этап доработок, который занял еще два месяца, не считая пауз в работе. Разработка велась на встроенном языке 1С.
Учитывая разницу в структуре данных и принципах хранения скидок нужно было, чтобы информация выгружалась и загружалась корректно, причём так, чтобы не сломать стандартную функциональность. За это отвечал сложный алгоритм
Первые сложности начались уже после стартового этапа, когда менеджеры начали менять скидки и акции. При определенном сочетании параметров, например, при одновременном изменении сроков и цены, сложный алгоритм выдавал ошибки. Потребовалось дополнительное проведение автоматизированных тестов, которые перебирали множество возможных вариантов. Автоматизированное тестирование позволяет имитировать работу пользователей, в частности, позволяет проверить очень много комбинаций действий, но делает это в сотни раз быстрее живого тестировщика. По мере нахождения ошибок, они устранялись вплоть до того момента, когда всё заработало стабильно.
Мы уже упоминали, что первая подзадача решалась стандартными способами. То же верно и для управления ценниками, которое осуществлялось в 1С. После настройки акции автоматически формировались ценники с зачёркнутой старой ценой, после чего они отправлялись на печать.
В рамках разговора об управлении ценообразованием и смежными процессами полезно сделать примечание об управлении лояльностью. Бонусы лояльности обычно рассчитываются в третьей системе. Это связано с тем, что программа должна работать в режиме 24/7, потому что в любой момент покупатель может прийти в офлайн- или интернет-магазин и списать баллы. Мы должны иметь возможность соединиться с сервером и оперативно запросить баланс баллов и оперативно их списать. ERP-система зачастую не работает в таком режиме, постоянно происходит обновление данных и справочников. ERP не может работать в режиме 24/7, а вот отдельная сторонняя система может.
Результаты. Самым главным результатом стало то, что несмотря на технические сложности, ИТ-инструменты были интегрированы в работающую систему, которая позволила клиенту управлять акциями в сети магазинов. В дальнейшем, когда развитие платформы продолжилось и были добавлены новые каналы, решение еще раз доказало свою работоспособность.
По итогам реализации проекта мы можем утверждать, что команда Odyssey Consulting Group умеет решать сложные кастомные задачи, хотя более правильным, безусловно является внедрение оптимального варианта управления ценообразованием на единой платформе или в рамках готового решение, например Odyssey4Retail.
