В рамках второй статьи цикла по теме лояльности мы хотим разобраться, с чего стоит начать подготовку к запуску новой программы. Как и в любом проекте, основа — это анализ и подготовка.
В прошлый раз мы разбирали эволюцию программ лояльности, сделали обзор рынка и успешных кейсов с опорой на статистику, выяснили отличия между программами лояльности для B2B и B2C и подсчитали бизнес-выгоды после внедрения. Если пропустили, то первая статья здесь.
Перед тем как углубляться в детали будущего продукта по лояльности, необходимо ответить себе и вовлеченной в процесс команде на ряд вопросов. Для чего мы создаем продукт? Кто будет в нем заинтересован? Какие варианты сценариев жизни продукта после внедрения потенциально существуют? В конце концов, достаточно ли у вас людей и экспертизы в будущей проектной команде?
Чтобы не столкнуться с массой препятствий из несоответствия желаний
и возможностей, не сорвать проектные сроки и быть максимально готовыми к непредвиденным обстоятельствам, особое внимание нужно уделить предпроектной подготовке.
Предпроектная подготовка к созданию программы лояльности
Неизбежно приходит время, когда бизнес начинает регламентировать процессы, а далее, оптимизировать их. В эти моменты процессы начинают обрастать тяжелыми для восприятия сотрудников особенностями, которые затратно менять. В любую коробочную систему — формат поставки ПО — заложены модели базовых процессов. Отталкиваясь от целевого бизнес-сегмента такой системы, определяется её склонность
к кастомизации, глубине таких изменений.
Когда вы определились, «проекту быть», — настает время для более глубокой проработки. Вне зависимости от того, будет ли это выбор внешнего вендора или собственная in-house разработка, начинать нужно
с требований.
Как правило, если у внутренний команды нет актуальных знаний
о продуктах на рынке, следует запускать процедуру RFI (Request for Information). Она предназначена для сбора верхнеуровневого среза данных о решениях (функциональность, модель лицензирования, сроки внедрения, стоимость и др.), закрывающих поставленные задачи.
После того, как базовая вводная информация для оценки рынка получена, инициируется более детальный сбор требований в рамках RFP (Request for Proposal).
Что нужно описывать в коммерческом предложении в рамках RFP?
1/ Цели и задачи внедрения
Без формализованного отображения целей и задач бизнес потратит время впустую.
При постановке цели нужно учитывать возможности программы лояльности, которая способна:
– Создавать конкурентные преимущества
– Влиять на рост выручки и другие ключевые метрики
– Предоставить ценность, за счет которой клиент будет готов поделиться своими данными
Совет 1:
Проведите анализ рынка, узнайте ключевые предложения локальных конкурентов и международных лидеров. Сопоставьте результаты анализа с миссией вашей компании и выберите оптимальный вариант возможностей программы лояльности.
2/ Определение ответственных лиц
У проекта обязательно должен быть спонсор — человек, располагающий бюджетом. Он же является первым заинтересованным в успехе проекта лицом. У спонсора достаточно времени, чтобы следить за проектом и вовремя принимать ключевые решения. При идеальном стечении обстоятельств, спонсору поставлен KPI на данный проект.
Такой человек собирает проектную команду, в которой предусмотрены следующие роли:
3/ Описание сценариев и подсчет бизнес-кейса
Важно помнить, что ИТ-решение — это всего лишь инструмент.
Только грамотно подготовленный бизнес-сценарий и просчитанный кейс помогут успешно реализовать проект.
Каждому из сценариев присваивается метрика, на которую он влияет.
Совет 2:
Применяйте индустриальные бенчмарки. Так вы поймете, является ли подход оптимальным. В случае, если в команде не хватает компетенций, можно пригласить бизнес-консалтинг. Они помогут поставить цели и описать способ их достижения.
4/ Подготовка запроса предложений (RFP)
Когда определены цели и задачи, способы их достижения, ответственные лица, проектная команда приступает к подготовке запроса предложений. В результате определяется наиболее подходящие вендор и интегратор, это заключительный этап.
Мы рекомендуем включить в состав запроса на предложение следующие пункты:
* На сегодняшний день существует три основных формата поставки ПО:
Box — исторически самый первый формат, где пользователь приобретает носитель с ПО. Нужна мощная инфраструктура, привязка к физическим серверам. Плюсы: автономия, вечная лицензия, отсутствие у поставщика ПО доступа к данным.
Cloud — облачное ПО с практически безграничным масштабом применения, можно быстро нарастить мощности, купив дополнительные услуги, не нужно держать дорогие серверы для хранения данных. Минусы: зависимость от интернета и потенциальная опасность утечки данных.
On-premise (on-prem) — комбинированный формат, при котором у пользователя есть свои серверы/серверы арендуются для хранения данных, а ПО используется по подписке. Самый высокий уровень защиты корпоративных данных и автономия от поставщика ПО.
Последовательное исполнение этих этапов поможет грамотно реализовать проект, распределить бюджет и спрогнозировать эффективность бизнес-кейса. Ниже рассмотрим ключевые ошибки
на этапе подготовки проекта.
Ключевые ошибки в предпроектной подготовке
1/ Отсутствие заинтересованных лиц
За проектом обязательно должно стоять лицо, которое несет конечную ответственность по итогам работы. Иначе проект отправляется
на «второй план»: не соблюдаются сроки, снижается качество выполнения работ, превышается бюджет или проект вовсе рискует быть запущен.
2/ Нечеткие цели
Некоторые инициативы на рынке могут стартовать как «проект ради проекта», потому что конкуренты запустили нечто подобное.
Бывает так, что цели являются невыполнимыми или неопределёнными.
Мы рекомендуем ставить цель в соответствии с общей бизнес-стратегией. Интенсивный рост выручки редко может идти бок о бок с сокращением затрат на маркетинг. Цели должны быть конкретными, измеримыми, достижимыми и привязаны ко времени.
3/ Не описаны сценарии — способы достижения цели
Как мы обсуждали выше, именно сценарии определяют то, за счет чего цели будут достигнуты. Не нужно концентрироваться на отдельных фичах. Описание сценария процесса в разрезе клиентского пути даст четкое понимание как достичь цели.
4/ Продавливание поставщика услуг по цене
Зачастую, жесткая стратегия продавливания поставщика услуг
по цене может сыграть не в вашу пользу. При торгах с поставщиком
обе стороны должны осознавать, за счет чего этот дисконт будет достигнут. Часто может оказаться так, что за меньшую стоимость заказчик получит исполнителей ниже квалификацией или недостаточную лицензию, чтобы достичь результата.
Аналогичные комментарии применимы и к торгам по срокам проекта. Конечно, вы можете запустить программу лояльности за месяц,
но успеете ли вы реализовать все требуемые интеграции в должном качестве?
5/ Неукомплектованная внутренняя команда
Не стоит забывать, что внедрение любого проекта — это совместное усилие все участвующих сторон. Участие подрядчика не освобождает заказчика от ответственности за проект. Подрядчик является экспертом той системы, которую он предлагает. Но вряд ли он разбирается в процессах на уровне ваших сотрудников и понимает,
как работают все другие корпоративные системы. Именно поэтому
на этапе подготовки проекта нужно определить структуру команды, чтобы все узлы проекта были готовы к запуску.
Два варианта развертывания MLM: cloud и on-premise
Вернемся к перечню запросов на предложение и остановимся подробнее на бизнес-требованиях. Когда мы создавали MLM, наша команда учла условия развертывания решения как в облаке, так и на серверах заказчика в зависимости от индустрии и политики информационной безопасности компаний. Разберем преимущества и особенности двух вариантов.
Облачный вариант позволяет обеспечить:
- Крайне быстрое развертывание решения;
- Простоту масштабирования;
- Отсутствие необходимости поддержки и обновления оборудования;
- Подписочную модель.
Тогда как при om-premise размещении:
- Данные хранятся исключительно на ваших серверах;
- Большая гибкость при выборе поставщика ПО;
- Единоразовые затраты, что может оказаться дешевле на длинном горизонте.
***
На этом мы завершаем вторую статью из цикла по лояльности.
В следующий раз будет более технический материал, в котором мы расскажем об устройстве функциональных блоков нашей собственной программы лояльности Masterdata Loyalty Managenment и ее основных объектах.
С какими ошибками при реализации проектов вы сталкивались в своей работе? Поделитесь опытом в комментариях 🙂
Мы доступны в Facebook, LinkedIn и Instagram.
Пишите!
Автор статьи: Дмитрий Рекунов, Product Manager MLM в Masterdata