2023/03/06 09:10:21

Миграция на российскую CRM-платформу: Как подготовиться к бесшовному переходу

В 2022 году российский бизнес вступил в период трансформации. Компании экстренно пытаются решить проблемы, связанные с уходом западных ИТ-вендоров, при этом подстраиваются под изменения партнерских сетей и новые потребности клиентов. Предприниматели осваивают открывшиеся ниши и реформируют существующие. О том, как актуальные запросы бизнеса меняют CRM-системы, о плюсах российских решений и способах быстрой миграции на них, TAdviser рассказал Тимур Порошин, владелец продукта Т1 CRM.

Тимур
Порошин
Мы предложили клиентам low-code инструменты разработки, которые позволяют быстро создавать и настраивать CRM под задачи бизнеса

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

Тимур Порошин: Многие российские компании, внедрившие CRM-решения на основе продуктов западных вендоров, в 2022 году оказались перед лицом различных рисков. Группа Т1 еще в 2021 году сделала ставку на разработку собственной CRM-платформы T1 CRM, которая способна закрыть задачи крупнейших компаний по взаимодействию с клиентами и автоматизировать ключевые бизнес-процессы. Поэтому в нашем случае процесс миграции проходил достаточно плавно, но такая возможность, конечно, была не у всех.

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

Если бизнес работал с решениями, развернутыми на собственных серверных мощностях, то проблем было немного меньше: системы продолжали функционировать, но лишились вендорской поддержки. Жить с этим можно (даже достаточно продолжительное время), но не очень комфортно. Громоздкие legacy-системы уже в период пандемии показали свою «неповоротливость»: на создание и внедрение новых модулей могли уходить месяцы, что не соответствует сегодняшнему запросу к скорости вывода новых продуктов и сервисов на рынок (time2market - T2M). Российский рынок облачных ИБ-сервисов только формируется 2.6 т

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

Рабочий стол

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

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

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

Своим заказчикам мы также обязательно проводим аудит. Например, один из них обратился с просьбой перенести CRM-функциональность «как есть», представив первоначальное ТЗ на 200 страниц. Итоговый объем работ по миграции был снижен в несколько раз после «очистки» плана: от ряда сервисов отказались как от избыточных, так как их использовал один человек раз в полгода, что-то решили внедрять позже как не самое актуальное. В итоге была достигнута существенная экономия по времени и затратам.

Следующий этап – формирование MVP по каждому сервису. Для этого бизнесу предстоит самостоятельно или с помощью специалистов (со стороны интегратора или консалтингового агентства) критически посмотреть на операционные процессы, на их реализацию в ИТ-ландшафте, на программно-аппаратные комплексы, которые непосредственно реализуют эту функциональность. Только после этого есть смысл приступать к составлению карты миграции на новые рельсы.

Может ли быть такое, что компании нет надобности одномоментно переносить все процессы из старой CRM-системы в новую?

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

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

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

Карточка обращения

Есть ли среди российских CRM-систем универсальные решения?

Тимур Порошин: Подчеркну, что даже для крупного бизнеса не может быть универсального CRM-решения, потому что при всей схожести процессов (везде есть карточка клиента, карточка сделки и типовая задача), оркестрация сущностей в разных отраслях сильно варьируется. Какой-то компании достаточно ограниченной карточки клиента, а другой необходима максимально расширенная, например, в случае с банками и любым бизнесом, где есть процессы комплаенса. Именно поэтому при создании T1 CRM мы сделали ставку не на универсальность, а на гибкость решения, возможность его кастомизации под запросы компаний из разных отраслей, что позволяет сделать микросервисная архитектура.

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

На какие технологические аспекты стоит обращать внимание при выборе решения для миграции?

Тимур Порошин: Серебряной пули нет. Сегодня приоритетным технологическим решением для CRM-систем выступают микросервисы. Преимущества такой архитектуры в том, что она позволяет организовать сочетание разных сервисов, которые команды могут самостоятельно дорабатывать. Причем инкременты могут поставляться ежедневно, что не затрагивает другие модули. Начиная работать над платформой T1 CRM в 2021 году, мы решили использовать самый современный стек и микросервисы, и первые миграции показали, что выбор был сделан верный.

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

Процесс миграции во многом опирается на современные технологии для оркестрации, контейнеризации и автоматизации развертывания, такие как Docker и Kubernetes. Самая распространённая практика сегодня – использование Open source решений. Как основной язык программирования команды разработчиков предпочитают Java, а при работе с базами данных выбирают стек PostgreSQL. Все эти технологические решения используются в T1 CRM.

Как выбрать наилучшее CRM-решения для миграции? На что обратить внимание?

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

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

Когда на рынок была выведена T1 CRM, мы увидели, что даже минимальный набор разработанных нами сервисов вызывал интерес компаний. Одновременно мы поняли, что чистого кода недостаточно: нужно снижать порог вхождения в стек. Поэтому было принято решение – время доказало его правильность – предложить клиентам средства разработки нашей платформы, так называемые low-code и no-code инструменты, что позволяло быстро создавать и настраивать CRM под задачи бизнеса без найма большого числа программистов. За разработчиков уже решено 80% задач – приложение создается автоматически, от специалиста требуется лишь провести простую кастомизацию. Такой подход бизнесу может быть интереснее, так как если ранее для развития системы был нужен дорогой специалист категории Senior или Expert, то сегодня достаточно Middle или Junior+.

А что может быть интереснее: платформа или иная архитектура?

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

Именно такая концепция заложена в основу T1 CRM. С одной стороны, мы предлагаем типовые, «классические» модули для автоматизации маркетинга, продаж и клиентского сервиса. С другой, понимаем, что платформа становится прекрасной базой для специализированных модулей: поскольку информация о клиентах уже есть в ядре системы, можно укреплять взаимодействие с ними. Например, автоматизировать программы лояльности для крупных ритейлеров или создать эффективную стратегию взыскания задолженности для финансовых организаций.

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

Аналитика

Как выбрать между облачной CRM и решением on-premise?

Тимур Порошин: Традиционно топ-менеджмент российских компаний исходит из критерия сохранности данных. Именно по этой причине иностранные лидеры рынка облачных CRM-систем не котировались у наших крупнейших корпораций. Бизнес опасается, что данные хранятся где-то далеко, зачастую за рубежом, что увеличивает риски в связи с ужесточением законодательства в отношении чувствительной информации – 152-й ФЗ жестко регламентирует эту сферу. Кроме того, при работе с облачными решениями возможность кастомизации для enterprise-формата резко сокращается.

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

Как расставить «веса» технологических особенностей на старте миграции?

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

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

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