Риски бизнеса на пути внедрения автоматизации процессов взаимодействия с клиентами

Дмитрий Белоус, эксперт агентства целевого маркетинга «ИЮЛЬ»

В ходе реализации проектов по автоматизации CRM-процессов или по запуску программы лояльности может обнаружиться множество подводных камней, о наличии которых руководство компании и не подозревало. Что это могут быть за камни и каких возможных исходов следует опасаться, рассказывает Дмитрий Белоус, эксперт агентства целевого маркетинга «ИЮЛЬ».

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

Очевидно, что среди вполне успешных существует доля неудачных проектов, которые не оправдали возлагаемых на них надежд, и причина таких провалов, как правило, заключается не в недостатках самой системы, а в просчетах при ее внедрении.

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

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

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

Внедрение CRM – это очень важный и сложный этап в развитии любой компании

Ищем «тонкие места» проекта

В большинстве случаев запуск программы лояльности представляется вполне технологической задачей. И действительно, если немного поразмыслить, то базовый план реализации будет приблизительно такой:
1. Выбираем несколько информационных систем, которые автоматизируют процессы бонусной программы лояльности (в идеале – те, что уже используются в отрасли);
2. Проводим для них тендер, чтобы получить лучшие коммерческие условия;
3. Интегрируем выбранную систему в текущую информационно-техническую архитектуру компании;
4. Определяемся с принципом идентификации покупок клиентов в информационной системе;
5. Определяемся с каналами коммуникаций с клиентами и проводим их интеграцию с выбранной системой;
6. Формируем правила начисления бонусов или предоставления преференций участнику программы лояльности;
7. Настраиваем правила взаимодействия с участниками программы в информационной системе;
8. Запускаем программу.

Итого, чтобы все это реализовать, достаточно трех-четырех месяцев.

Какие «тонкие места» присутствуют в этом плане? К реализации каких рисков нужно быть готовыми в случае осуществления проекта по вышеуказанному плану?

Первое и основное: в плане нет формирования основного продукта для бизнеса – программы лояльности. Да, в пункте 6 плана прописаны работы по формированию правил программы, но этого недостаточно, и вот почему.

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

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

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

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

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

Действительно, на этапе разработки концепции в рамках определения потребностей программы необходимо получить ответы на множество вопросов, в том числе и на такие, как:
• какая механика поощрения участника должна быть реализована и каким образом осуществляется дистрибуция этого поощрения?
• как устроены автоматизированные коммуникации с участниками программы?
• по каким каналам коммуникаций программа может и будет разговаривать и в каких случаях, есть ли ограничения и какие они?
• какова степень вовлеченности персонала в управление программой?
• какие процессы должны быть автоматизированы с целью упрощения управления, а какие нет? И т. д.

Основная задача этапа разработки концепции – определить и принять базовые рамки программы лояльности для бизнеса в целом. Эти ограничения лежат одновременно в нескольких плоскостях:
• маркетинг: программа должна быть привлекательна для ее участника, что подразумевает затраты на поощрения и коммуникацию;
• экономика: затраты программы должны находиться в принимаемых компанией экономических рамках и окупаться, при этом необходимо сохранять баланс интересов с маркетингом программы;
• организационная система программы: сотрудники компании должны четко выполнять свои обязанности, чтобы на этапе эксплуатации программы их работа, начиная от формирования потребительских идей, согласования их внутри компании и до реализации/дистрибуции преференций участнику, была согласованной и не отражалась негативно на участниках программы.

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

Разрабатываем функциональные требования

Теперь обсудим, какого же уровня проработки следует ожидать от функциональных требований? Надо понимать, что этот документ, скорее всего, будет написан самим руководителем программы. По степени технической детализации он будет аналогичен подробному брифу, которые обычно пишутся для поиска подрядчиков на небольшие задачи, но не более того.

Исходя из собственной практики, срок, к которому будут сформулированы функциональные требования в результате согласования концепции программы внутри компании, займет порядка двух-трех месяцев.

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

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

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

Финансовых вариантов поставок систем на рынке сейчас, пожалуй, так же много, как и самих систем

Выбираем поставщика ИТ-систем с точки зрения бюджетирования

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

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

Финансовых вариантов поставок систем на рынке сейчас, пожалуй, так же много, как и самих систем. Главное – определиться с тем вариантом, который будет максимально соответствовать финансовым интересам компании. В своей практике мы встречались со многими, некоторые из них обсудим ниже.

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

Первый тип компаний – разработчики, которые создают информационную систему под заказ. Тут все просто. По сути, вы будете оплачивать нормо-часы всей рабочей команды, которая требуется для реализации функционала, описанного в функциональных требованиях. Какие в этом случае могут быть риски? Если функциональные требования сложные и указано много специфических процессов, то разработка информационной системы «под заказ» и «с нуля» может оказаться задачей, решаемой по принципу знаменитого треугольника: «быстро-дешево-качественно». Но так как срок на реализацию программы лояльности все же ограничен, то выбор остается или:
• за выделением бюджета, оценить который можно только после проработки всех технических деталей и особенностей реализации, зафиксировав их в техническом задании. Это является долгим и дорогостоящим процессом; или
• за потерей соответствия функциональным требованиям. А значит, для бизнеса есть риск, что программа лояльности будет запущена не в том виде, как было запланировано на этапе концепции, и, возможно, последствия этих ограничений окажут влияние на вовлечение в программу покупателей. Как результат – на коммерческие показатели программы лояльности в целом. Этот риск оценить до запуска программы, к сожалению, не получится.

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

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

Второй тип компаний – разработчики, которые поставляют на рынок готовую систему или сервис. Здесь необходимо дополнительно выделить несколько вариантов коммерческих условий, которые важно понимать:
• Тарификация работ по интеграции и кастомизации функционала поставляемой системы. Под интеграцией, как правило, понимается подключение готовой стандартной системы или стандартного функционала к существующей информационно-технической архитектуре компании с последующей настройкой. Под кастомизацией – дополнительная работа по разработке функционала поставляемой системы или сервиса под потребности программы лояльности, если они отличны от стандартного функционала. Причем понятие стандартного функционала для всех компаний разработчиков различается.

Можно найти различные коммерческие условия, но, как правило, переменной является стоимость интеграции. Из плюсов: можно реализовать программу любой степени кастомизации, при этом есть возможность немного сэкономить бюджет на этапе запуска, т. к. зарабатывают компании-разработчики при такой форме тарификации на кастомизации функционала. При этом стоимость кастомизации может быть высокой у компаний, работающих с большим числом клиентов из-за ограниченности ресурсов.
• Тарификация интеграции с последующей оплатой пользования. В данном случае оплата пользования тарифицируется, основываясь на масштабе программы. Для оценки масштабов разработчики обычно выбирают: транзакции, участников, торговые точки. Из плюсов необходимо отметить возможную невысокую стоимость владения системой при малых объемах бизнеса. Из минусов – плохую мотивацию компании-разработчика на развитие собственного продукта под ваш запрос. И, как следствие, риск недостаточной кастомизации информационной системы под концепцию программы лояльности.
• Подписка на сервис. Вы платите только за право пользования системой. Плюсы: пожалуй, самый бюджетный вариант владения. Если концепция полностью ложится на уже имеющийся в сервисе функционал – лучше не придумать. Здесь нужно понимать, что качество реализации и развитие программы целиком и полностью зависят от функционала, реализованного на стороне компании-разработчика. Отсюда основной минус: если в концепции предполагаются уникальные, по мнению разработчика, процессы, которые не реализованы в системе, то и реализовать их вряд ли удастся на удобных вам условиях. Если же процессы программы будут признаны компанией-разработчиком невостребованными на рынке, то эти процессы рискуют быть никогда не реализованными в таком сервисе.

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