Вопрос «строить своё решение или покупать готовое» рано или поздно встаёт перед любой компанией, которая всерьёз занимается программой лояльности. Особенно это актуально сейчас, когда рынок ИТ-решений переполнен предложениями, а разговоры про ИИ-агентов и «напишем сами за вечер» создают иллюзию, что собственная разработка — это всегда быстро и дёшево.
Мы поговорили с Марией Сафроновой, директором по продукту Loymax, о том, почему это решение сложнее, чем кажется на первый взгляд, какие риски скрываются за каждым вариантом и как вообще подступиться к этому выбору.
Мария, расскажите немного о себе и о компании — почему вы разбираетесь в этой теме?
Мой опыт — 13 лет в сфере программ лояльности, я пришла из ИТ-команды, поэтому хорошо знаю все сложности и подводные камни, с которыми приходится сталкиваться при работе с заказчиками.
Сейчас работаю в продуктовой компании Loymax — это не заказная разработка, а именно продукт, которым мы занимаемся уже больше 16 лет. Это полностью российская разработка. Наши заказчики — очень разные сети: продуктовый ритейл, фэшн, косметика, нефтепродукты, много аптек. То есть у нас большой опыт работы с самыми разными отраслями.
Почему выбор между собственной разработкой и готовой платформой стал таким актуальным именно для программ лояльности?
Потому что программа лояльности — это уже базовый минимум и для малых, и для крупных сетей. Все думают об экономии, а программа лояльности — как раз инструмент для управления промоинвестициями и клиентской экономикой. Мы больше не можем позволить себе раздавать скидки и бонусы всем подряд, нужно тонко чувствовать своего клиента, работать с предиктивными моделями, чётко понимать, что стоит предлагать, а что нет.
И для всего этого программа лояльности становится каналом для сбора данных, коммуникации и доставки предложений. Это замкнутый цикл, который либо строится с нуля самостоятельно, либо берётся готовым у вендора.
Если компания разрабатывает собственное решение
Какие у этого варианта преимущества?
Собственная разработка — это полная свобода действий: архитектура, код, данные — всё в ваших руках. Не нужно адаптироваться к чужим решениям, можно выбирать любые стартовые технологии или вообще ни на что не опираться.
На выходе получается уникальный продукт, который можно очень глубоко интегрировать в свою экосистему — адаптировать шины данных, протоколы, API-контракты под себя, а не под чужие процессы. Нет ограничений лицензий и зависимости от чужого плана развития продукта. Вы сами отвечаете за SLA — и если что-то пошло не так, ответственность, как правило, будет на вас.
В перспективе это может дать экономию: меньше платежей вовне, зарплата своей команде. Плюс часто есть имиджевый эффект — приятно рассказывать рынку, что вы сделали собственный продукт.
А какие риски чаще всего недооценивают компании, которые идут в собственную разработку?
Подводных камней здесь много. Первое — очень высокая стоимость входа: команда, инфраструктура, поддержка. Когда считают ресурсы, часто не учитывают, где всё это будет разворачиваться, тестироваться, как гарантировать регулярные обновления и релизы, как всё это мониторить.
А если мы говорим про программу лояльности, уровень доступности должен быть как у банковских систем: если клиент не получил свою скидку или бонусы задержались — это уже репутационный риск и потенциальный фрод.
Второе — кадровый вопрос. Вам придётся держать ключевых специалистов почти в «золотой клетке» — уход людей, которые всё это придумали, будет крайне болезненным. Это, как правило, ещё и сильно удлиняет сроки будущих релизов: ИТ-команда физически не может параллельно заниматься всем. Мы часто видим ситуацию, когда предлагаем клиенту доработку в мобильном приложении, а его собственная команда отвечает: «Извините, у нас приложение расписано до конца года».
Отдельная проблема — экспертиза. Нужен дорогой специалист, который заранее просчитает, как система будет масштабироваться: вы запустились на 10 магазинах, а в планах — тысяча. Получится ли расти без боли? Не появятся ли дыры в безопасности? Это постоянные доработки, риски и выбор между «сделать хорошо и архитектурно верно» и «сделать быстро, чтобы просто работало». А поскольку технологии быстро устаревают, компании приходится организовать непрерывную эволюцию системы: проводить архитектурную модернизацию, делать рефакторинг, менять устаревшие компоненты и выделять новые сервисы по мере роста.
Хороший пример того, куда это приводит на практике, — сеть «Бегемаг». У них было собственное самописное решение, которое на старте закрывало задачи, но со временем себя изжило: запуск одной акции занимал больше 50 часов и требовал привлечения IT-команды, поддержка усложнялась с каждым релизом, а отчёты и аналитику собирали вручную — через выгрузки из базы данных, потому что готового интерфейса для этого просто не было.
Программа физически не могла расти дальше в таких условиях. После перехода на Loymax отчёты автоматизировались, а ИТ-команда наконец освободилась от непрофильных задач и смогла заняться, например, развитием мобильного приложения — тем, на что раньше просто не было ресурсов.
Ещё одна проблема — инфраструктура. Сейчас она в принципе недёшевая. Мы, например, специально размещаем несколько дата-центров, чтобы обеспечить устойчивость и возможность масштабирования, и закупаем оборудование с запасом под будущий рост — то есть стартовые расходы очень значительные.
И ещё один момент, скорее не риск, а вызов: бизнес постоянно передумывает. Сегодня в тренде одно, завтра другое, и приходится пересматривать требования чаще, чем ИТ-система физически готова меняться.
К этому добавляется безопасность — сейчас много законов, регулирующих работу с персональными данными, и это тоже отдельная экспертиза: нужен специалист по информационной безопасности, который будет говорить, какие ограничения нужно соблюдать, чтобы не попасть на штрафы.
И всё это нужно параллельно документировать — причём не только технически, но и с пользовательской точки зрения, чтобы, например, маркетолог мог разобраться в системе без разработчика.
Если компания выбирает готовое решение
Хорошо, а что с готовыми платформами? В чём здесь подвох?
Я бы не доверяла вендору, который обещает закрыть вообще всё и сразу — на моей практике так почти не бывает. Вендор обычно готов, но не ко всему и не сразу.
При этом плюсы у готового решения реальные: на примере нашей платформы мы можем запустить проект за 2–3 месяца. Решение уже готово, и по сути весь процесс сводится к адаптации бизнес-сценария клиента под существующую систему. Альтернатива в виде собственной разработки почти всегда обходится дороже и требует больше времени на выход в рынок.
Показательный пример скорости — сеть «Ашан», которой нужно было максимально оперативно перейти с иностранного решения на российское. После предварительной подготовки и миграции данных мы развернули систему буквально за одну ночь. Но это не значит, что скорость даётся бесплатно: такой темп потребовал предельно плотной синхронизации команд с обеих сторон и готовности клиента оперативно принимать решения по адаптации сценариев прямо по ходу миграции — это и есть реальная цена высокой скорости, а не только заслуга платформы.
На рынке можно найти решения под очень разные задачи: кому-то важнее коммуникация, кому-то — стабильность процессинга, кому-то — гибкость настройки правил. Дальше всё упирается в экспертизу команды — и на стороне вендора, и на стороне заказчика, потому что решение в итоге выбирают конечные пользователи. Бывает так, что IT-отдел выбрал систему, принёс маркетологам, а те говорят: «Здесь всё гибко, но неудобно» — или, наоборот, часть нужных сценариев вообще не покрывается.
На что обращать внимание при выборе вендора?
На этапе тендера важно, чтобы обе команды — и техническая, и бизнес — вместе оценивали, насколько предложение соответствует ожиданиям. Лучше заранее посмотреть, сколько готовых интеграций есть «из коробки», есть ли SDK или интерфейсы для того, что не покрыто напрямую.
Обязательно спрашивайте про частоту обновлений: если решение не обновлялось 5 лет, это тревожный звонок — рано или поздно придётся снова переезжать. Смотрите на совокупную стоимость владения, SLA, риски и гарантии, а на уровне договора — на юридическую зрелость вендора, чтобы на выходе не было рисков ни для одной из сторон.
Если вы планируете расти, не стоит брать точечные решения — например, что-то заточенное узко под кассы. На моей практике масштабироваться на таком вендоре потом бывает очень больно.
Минусы у готового решения тоже есть: вы зависите от дорожной карты поставщика — у него своя дорожная карта, свои приоритеты, и не факт, что ваши пожелания в них попадут. Если у вас действительно нестандартные, суперкастомные сценарии, перенести их в готовое решение может быть тяжело и дорого. А переход с одного вендора на другого или из самописного решения на вендорское — это всегда болезненный процесс миграции.
Отдельно хочу сказать: клиентская база — невероятно ценный актив. Если всё-таки пришлось переходить на новую систему, стоит по максимуму загружать историю — покупки, работу акций, рассылок. Это всё потом используется в предиктивных моделях и позволяет быстро запустить персонализацию, а не выдавать клиентам «размазанные» и нерелевантные предложения.
С чего начинать выбор
А как вообще подступиться к этому выбору?
Сначала бизнесу нужно ответить на вопрос: что мы хотим получить хотя бы на горизонте полугода, а лучше — 2 лет. Мы всегда в своих анкетах спрашиваем о перспективе: сколько торговых точек планируется, потому что от этого зависит и прогноз по инфраструктуре, и по лицензиям.
Проблема в том, что бизнес часто сам до конца не может сформулировать, чего хочет — аппетит приходит во время еды. Часто всплывают вещи, о которых никто не подумал заранее: например, работа без интернета — клиент должен получить своё предложение даже при сбоях связи. Или синхронизация систем между собой: купили несколько решений, а в одном клиента зовут Паша, в другом — Оля — как к нему обращаться?
Миф о простоте: почему «хочу всё просто» — это иллюзия
Правда ли, что заказчики часто просят «сделать просто», а потом всё равно приходят к сложным сценариям?
По моему опыту — да, обычно так и происходит. Заказчик почти всегда говорит: «Не хочу никакой геймификации, хочу всё простое». Но я бы не спешила в это верить — на практике чаще получается иначе. Когда мы стартовали 16 лет назад, у нас тоже всё было просто, но бизнес диктует свои правила.
Сначала говорят: «Хотим начислять бонусы от суммы чека, больше ничего не нужно». А потом оказывается — нужны фишки, электронные фишки, партнёрские акции с производителями, клубные бонусы только для определённой категории товаров, разные комбинации сгорания баллов: одни быстрые, другие живут полгода, третьи должны сгорать строго к 8 марта.
Или говорят: «Нужна только скидка» — а потом появляется фиксированная скидка по шагам, по весу, только для определённого клиента, определённой цены, статуса, магазина.
На нашей платформе это видно в цифрах: на старте проекта у нас была простая логика «бонус от суммы чека», а сегодня в системе есть конструктор, который покрывает весь накопленный за годы список сценариев и позволяет реализовать больше 4 000 акционных механик. Это не усложнение ради усложнения, а прямое отражение того, как реально эволюционируют требования бизнеса — просто раньше это не было видно, потому что в самописных системах такие сценарии либо не реализуются вовсе, либо каждый добавляется отдельной дорогой доработкой.
Бизнес редко заранее вникает в детали настолько, насколько это потребуется на практике: купоны становятся персональными, статусы нужно пересчитывать то раз в месяц, то раз в квартал, то от суммы чека — и под каждое такое изменение либо переписывается код, либо архитектура должна быть заранее к этому готова.
Есть ли у компаний ещё какие-то альтернативные варианты, кроме собственной разработки и выбора готового решения?
Да — покупка исходного кода у вендора. Некоторые на это идут: дальше совместно с командой вендора выпускают новые релизы. Здесь важно, чтобы совместная работа велась в рамках одной версии продукта. Если появляются 2 разные версии под конкретного заказчика, это уже по сути отдельный продукт. Этот путь самый дорогой, с серьёзными рисками потери лицензии — если заказчик внесёт изменения, которые вендор не сможет поддерживать.
У нас были случаи, когда это получалось выстроить как гибрид — с общими пулл-реквестами и обучением команд с обеих сторон. Тогда ИТ-команда клиента расширяется, но экспертиза не теряется. Но и стоит это, как правило, кратно дороже, чем обычная лицензия: вендор не отдаёт права на интеллектуальную собственность бесплатно.
Если коротко — как выбрать: готовое решение или собственная разработка?
У каждого варианта свой профиль рисков:
Готовое решение обычно даёт более быстрый старт и ниже стартовые затраты по сравнению с собственной разработкой. При этом гибкость под нестандартные, суперкастомные сценарии здесь, как правило, ниже, а сама компания оказывается зависима от дорожной карты вендора. Важный нюанс: уровень поддержки, SLA и масштабируемости у разных вендоров сильно различается — у бюджетных решений это часто более слабая инфраструктура, ниже SLA и ограниченная техническая поддержка. Тогда как у зрелых платформенных решений можно получить SLA вплоть до 99,99% доступности — как у Loymax — и полноценную экспертизу команды вендора. Крупной федеральной сети имеет смысл внимательнее сверять эти параметры на этапе тендера, а не полагаться на общие обещания.
Собственная разработка даёт более полный контроль над архитектурой, уникальность продукта и определённый имиджевый эффект. Но, как правило, требует более высоких вложений на старте, несёт больше кадровых рисков и предполагает более долгий выход на рынок по сравнению с готовым решением. Но при должном подходе и достаточных ресурсах она может окупиться на длинной дистанции.
Чего в итоге ждать от готового решения
Что происходит с командой, если компания решает всё-таки не строить сама, а перейти на готовую платформу?
Хорошая иллюстрация — сеть «Ароматный мир». У них были сильно ограничены механики старой программы, а бизнесу хотелось глубокой персонализации и своевременных предложений для участников — того самого сценария, который своими силами почти невозможно поддерживать: для этого нужна отдельная команда дата-сайентистов, которая постоянно дообучает модели и следит за их точностью.
У нас этим на регулярной основе занимается отдельная продуктовая команда, которая развивает модуль персонализации на основе моделей с тысячами параметров, — то есть для клиента это уже готовая, постоянно совершенствующаяся экспертиза, а не то, что нужно нанимать и растить внутри штата.
Внедрение у «Ароматного мира» заняло около 6 месяцев — сроки здесь всегда зависят от ресурсов заказчика, включая то, сколько людей он может выделить на проект со своей стороны.
Если резюмировать — самое важное на старте, вне зависимости от выбранного пути, это честный и глубокий разговор: понимание того, какие ресурсы бизнес реально готов выделить. На мой взгляд, именно это чаще всего определяет, какое решение в итоге окажется верным.
