Как мы сделали программу лояльности для 300 магазинов «У Палыча» на open source iDempiere ERP-CRM

Что такое iDempiere?

iDempiere ERP/CRM - это бесплатное ПО с открытым исходным кодом. Имеет функционал Tier II ERP, CRM, SCM, POS, Promotion, Campaign management и, в принципе, много чего ещё.

Важно понимать, это не просто бизнес-приложение - это Java платформа/конструктор для low-code разработки разных, ориентированных на работу с базой данных, бизнес-приложений c web интерфейсом. Во времена, когда многие пытаются построить бизнес-приложение с нуля, хорошо помнить о том, что существуют подобные фреймворки, основанные на принципах ООП, с миллионами строк проверенного кода, "активным словарём данных", который позволяет управлять сущностями, правилами проверки, окнами, таблицами, форматами и другими настройками приложения, не прибегая к кодированию вообще или же применяя небольшие, в несколько строк, инъекции кода.

Входит в широко известное за рубежом семейство "...piere" - Compiere, Adempiere, Open Bravo, Metafresh. Отличается от одних из них полным отсутствием pay wall, от других - модульной (плагинной) архитектурой (менять функциональность системы можно на лету, обновляя тот или иной плагин OSGi).

Каждый год на Хэллоуин сообщество проекта выпускает обновлённую версию. Осенью 2020 года вышла версия 8.2.

"Кривая обучения команды по iDempiere ERP/CRM была пройдена ранее, на предыдущих проектах. За нашими плечами есть проект на промышленном предприятии: 500 активных пользователей в день, база около 500 Гб, 100-400 млн. запросов к базе в сутки."

Если верить официальным сайтам этих близкородственных систем, а также зарубежных фирм-внедренцев, данное семейство ПО используется в Ив Роше (Франция), Декатлоне (Индия), Цирке дю Солей и в тысячах безвестных фирм, от Канады до Индонезии, в разных секторах, от производства молока до банковского сектора.

iDempiere работает с PostgresSQL >=9.6 или Oracle 11G/12C. Даёт кластеризацию серверов приложений и балансировку нагрузки с помощью HAProxy и Hazelcast. Имеет write to Master & report from hot replicas, два движка автоматизации бизнес-процессов ("строгий" бизнес-процесс и бизнес-процесс для кейс-менеджмента) и мн. др. фичи, делающие её вполне пригодной для большой индустрии.

Данный "панегирик" не что иное, как благодарность данной системе в режиме word of mouth за её возможности, которыми уже не раз приходилось пользоваться, в полном соответствии с философией open source и sharing.

"300 магазинов разбросаны на площади 450 тысяч км. кв., что примерно равно площади Испании. Объезжать их все, даже на моноколесе, - дороговато."

В чем состояла задача в данном проекте?

В 300 магазинах, которые работают по франшизе бренда и в которых сложился разношёрстный ИТ-ландшафт различных POS-систем и зачастую нет постоянного айтишника, развернуть программу лояльности, которая максимально соответствует пользовательской истории Заказчика (бренда), работает мгновенно и готова к omnichannel. Часть этой пользовательской истории мы написали и переписали вместе с Заказчиком.

Вот чем в процессе этой дискуссии мы озаботились.

Почему программы лояльности вызывают скепсис у покупателя?

Еcли верить большим дядям типа Forrester, этот скепсис есть во всем развитом мире, а не только у нас. 60-70% всех покупателей являются членами хотя бы одной программы лояльности. Но быть членом это одно, а реально пользоваться - это другое. Как минимум 50% "участников" среднестатистической программы лояльности ею не пользуются. Если коротко и только о главном, то вот почему:

• Проблемы бренда:

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

  • Если customer experience в физическом магазине бренда сильно хромает: нужного товара нет, продавец о товаре ничего рассказать не может, в магазине плохо пахнет, за разменом посылают в соседнюю лавку и т.д. Другими словами, если базовые запросы покупателя при общении с брендом не удовлетворены, то программа лояльности будет уместна, как на корове седло. Лучше уж сфокусироваться на улучшениях в торговой точке.

• Проблемы самой программы лояльности:

  • Правила участия и получения бенефитов замороченные

  • А награда находит покупателя не сразу, а только потом - отсутствует instant gratification.

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

"Тут и объяснять ничего не надо - каждой программе лояльности нужен BI и всё тут. Для нашего проекта мы опять решили использовать open source - Metabase. Заказчику понравилось"

Какие принципы программы лояльности мы с заказчиком в итоге сформулировали?

Возможно, вам это всё покажется прописными истинами, но всё же.

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

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

В центре программы лояльности - покупатель

Строить отношения в итоге нужно не картой и даже не сегментом, а с индивидом. Карты это всего лишь идентификатор, они со временем теряются, заменяются и т.д. Удивительно, но общение с знакомыми маркетологами показывает, что не всегда и не всем это очевидно. В итоге твой offer engine должен уметь работать с точностью до индивидуального покупателя.

Вознаграждение покупателя должно быть практически мгновенным

Баллы покупателя, заработанные им при покупке, должны быть доступны для списания не на следующий день, а сразу, при следующей покупке, не важно, в этом же твоём магазине или уже в онлайне (если у тебя есть онлайн). То есть все твои сервисы, и оффлайновые и онлайновые, должны работать с одними данными покупателя и при этом работать почти мгновенно.

Регистрация в программе лояльности за секунды. И никаких ФИО, пожалуйста!

Понятно, что бумажные анкеты, которые "завтра обработают в офисе" это безнадёжный олдскул. Зарегистрироваться твоему покупателю в твоей программе лояльности должно быть не сложнее, чем послать 1 СМС. Ещё лучше, если это в два клика сделает продавец прямо в магазине. И, боже мой, конечно, не надо спрашивать Имя-Фамилию-Отчество! Спроси "Как к Вам можно обращаться?". Если хочет покупатель быть Василисой Прекрасной, Darth Vader или Zaya, пусть будет, мы не на пограничном контроле. Твоя задача - максимально снизить боль покупателя при регистрации, и дать возможность покупателю быть тем, кем он хочет, это лояльно по отношению к нему. Удивительно, но сколько же людей из сферы маркетинга порываются мыслить терминами "ФИО"!

Максимальная прозрачность для покупателя условий программы лояльности и его статуса в ней

Легче сказать, чем сделать. В идеале должны быть говорящие ценники, а также информативные чеки: на чеках, помимо начислений и списаний баллов, нужно печатать покупателю его/ее статус в программе плюс оставшийся путь до следующего уровня бенефитов. Ещё лучше, если монитор покупателя может отражать всё это прямо при покупке (с уважением к privacy, конечно).

Заранее планируй multichannel и работу множества разных акций одновременно

Даже если онлайн-магазина у тебя ещё нет, всё равно архитектуру и логику своего offer engine закладывай под

• многоканальность (физический магазин, онлайн-магазин, приложение, бот в Телеграме и т.д.)

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

• сосуществование множества акций одновременно (в т.ч. "противоречащих" друг другу)

Акции должны быть настраиваемы для одного отдельного канала (отдельная торговая точка, интернет магазин, приложение, телеграм-бот и т.д.), либо для набора из нескольких каналов, либо для всех каналов. Что там маркетологу будет угодно.

Скорость и надёжность, само собой

Прикинь сразу максимально возможное количество транзакций в твоей программе лояльности, в пиковый день, в пиковый час. Новые торговые точки, сезонность, праздники, все дела. В нашем случае мы с заказчиком заложились на 900'000 транзакций в день.

Подарочные карты

Надо, Федя, надо. Это профессионально, поэтому, рано или поздно неизбежно. По крайней мере, заложи в архитектуру заранее.

FIFO для баллов программы лояльности

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

Анализируй это!

Тут и объяснять ничего не надо - каждой программе лояльности нужен BI и всё тут. Для нашего проекта мы опять решили использовать open source - Metabase. Заказчик остался доволен.

Итак, проблемы проекта

1. 300 магазинов разбросаны на площади 450 тысяч км. кв., что примерно равно площади Испании. Объезжать их все, даже на моноколесе, - дороговато.

2. Да, магазины работают по франшизе, но исторически сложилось, что каждый предприниматель использует POS систему, выбранную по своему усмотрению (уже была; брат/сват уже использует и хвалит и т.д.) 99.9% всех рассматриваемых предпринимателей используют 1С разных версий и конфигураций. Затевать проект по переводу всех на один единственно правильный вариант POS, перестройке работы и переобучению всех сотрудников этой многоликой Испании, да еще в условиях пандемии, заказчик посчитал слишком дорогим по времени, а значит, по деньгам.

3. ИТ-экспертиза в этих магазинах имеет преходящий характер. Или приходящий.

4. НСИ только частично синхронизирована.

5. Период полного развёртывания программы лояльности во всех магазинах был определён как 6-9 месяцев от начала до конца.

"Штатные возможности iDempiere ERP/CRM для предметной области retail & promotion были полностью в нашем распоряжении..."

Сильные стороны, или почему всё получилось

1. Практически все магазины имели на начало проекта стабильный интернет, достаточный для работы веб-сервисов. А те, что не имели, могли легко и дёшево его получить.

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

3. Кривая обучения команды по iDempiere ERP/CRM была пройдена ранее, на предыдущих проектах. За нашими плечами есть проект на промышленном предприятии: 500 активных пользователей в день, база около 500 Гб, 100-400 млн. запросов к базе в сутки.

4. Штатные возможности iDempiere ERP/CRM для предметной области retail & promotion были полностью в нашем распоряжении:

   1. Вкладка Контрагент и её разные подчиненные вкладки (Контакты, Адреса, Сферы интересов, и ещё пара десятков других) и их готовая логика;

   2. Вкладка Промоакция и её подчиненные вкладки (Условия срабатывания, Распределение количества, Вознаграждение для покупателя, Строка промоакции и др.) и их готовая логика;

   3. Вкладка Группы Промоакций;

   4. Вкладка Рекламные кампании;

5. Плюс штатные фичи iDempiere из смежных областей, которые тоже пригодились:

   1. Сильный буржуйско-бухгалтерский функционал по GL (General ledger - Главная книга) и учёту дебиторки/кредиторки;

   2. Работа со множеством валют в учёте (баллы - это просто ещё одна валюта, пока что с курсом 1:1 к рублю);

   3. Встроенный Report Cube и таблица Fact_Acct_Summary, хранящая балансы финансовых транзакций (отличная от таблиц, содержащих движения);

   4. Кластеризация серверов приложений и балансировка нагрузки с помощью HAProxy;

   5. Поддержка REST web services для обмена через JSON формат;

   6. Schedulers - Планировщики. Штатный функционал iDempiere, RPA процессы, которые запускаются по расписанию или, с небольшой модификацией, по событию, на отдельном служебном сервере приложений и делают своё дело. У вас могут быть сотни планировщиков, если это надо. В нашем случае планировщики проводят начисления бонусов по всем необходимым таблицам движения, еженощно сжигают “устаревшие” бонусы по методу FIFO, отслеживают и исправляют экзотические, проблемные транзакции (возврат приходит раньше продажи, например, из-за того, что “моргнул” интернет в магазине).

   7. Workflow engine - один из 2х встроенных движков автоматизации бизнес-процессов, может настраиваться на работу по событию, может пронизывать все ситуации, департаменты, сущности (читай - таблицы).

   8. ‘Write to master database, report from hot replicas’ стандартная настройка, позволяющая отправлять все отчёты, включая автоматические, на одну или множество горячих реплик вашей базы данных;

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

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

Как в итоге всё работает?

1. В программе лояльности активировано уже 800'000 покупателей.

2. 99.9% из 300 магазинов имеют ту POS, которую имели до проекта.

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

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

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

6. В зависимости от сценария поведения покупателя (только начислять баллы или начислять-списывать) на одну продажу приходится до 3х транзакций обмена данными. Они занимают в среднем 50, 200 и 200 миллисекунд соответственно.

7. Бонусы, начисленные на только что состоявшуюся покупку, доступны для списания во время следующей покупки не позднее 1 минуты.

Автор: ERP-pass

Источник