Управление данными в CRM компании уровня Enterprise: что важно знать?
Внедрение CRM — важный этап для любой компании, однако по его завершении начинается не менее ответственный процесс, без которого само наличие системы теряет смысл. Это управление данными. И чем крупнее компания, тем труднее такая задача. Как выстроить взаимодействие с данными корректно? На что обратить внимание на каждом из этапов — от попадания в систему до коррекции? Обо всех нюансах управления данными в CRM компаний уровня Enterprise рассказывает Максим Ничипорович, руководитель направления по развитию бизнеса с заказчиками OCS.
Последнее время я периодически слышу высказывания в СМИ, что данные — это новая нефть. С моей точки зрения, подобное мнение верно лишь частично. Если мы говорим об оперативных данных, которые появились, были использованы и затем отправлены в лучшем случае в архив или просто исчезли — да, это нефть. Как и нефть, такие данные сначала ректифицируются, а затем сгорают в двигателях внутренней аналитики. К такому типу относятся многие проекты Industrial IoT (IIoT), например. Но если мы посмотрим на данные CRM, то они не сгорают, а появляются в системе и используются постоянно. Лично у меня возникает ассоциация с кровью в организме.
Раскроем подробнее тему появления и актуализации данных в CRM-системе крупного дистрибьютора.
Появление данных
Данные в системе CRM появляются в результате автоматического или ручного ввода с помощью штатного функционала и вносятся в систему либо единичными записями, либо пакетно.
Если же для разового нестандартного ввода данных не хватает штатных средств, то вручную или автоматическим порядком следуем процедуре ETL.
-
Extract: сбор данных в одном месте для последующей обработки и загрузки. В простейшем случае — тот же Excel.
-
Transform: разбиение по столбцам, очистка и приведение к нужному формату.
-
Load: загружаем в систему либо с помощью разовых процедур, либо с помощью разработки и использования соответствующего шаблона.
Первичная информация и сопоставление данных
В CRM есть своя базовая информация по разным направлениям. На нее накладываются дополнительные сведения, на которых строится вся дальнейшая аналитика. Информация по участию в мероприятиях и контактные данные — это базовая информация маркетинга, в то время как для продаж одним из важнейших базовых элементов являются запросы и последующие коммерческие предложения.
Маркетинг. В двух компаниях, в которых я работал, много времени и сил заняла подготовка механизма сопоставления регистраций на мероприятия с контактной информацией в базе. То есть:
-
полуавтоматическая проверка по существующим записям;
-
ручная верификация по автоматически предложенным вариантам;
-
актуализация информации.
Если это и делалось, то лишь вручную, долго и трудоемко, в результате информации в системе было немного, и часто она была не актуальной. Сейчас же эта информация живая, оперативная, постоянно дополняется, актуализируется и активно используется. Но главное — это дало возможность сегментации по интересам и ведения истории маркетинговых отношений.
Очень полезная полуавтоматическая тема — отработка логов по недоставкам почтовых сообщений после рассылок. Актуализация контактной информации нужна еще и для того, чтобы уменьшить количество недоставленных рассылок, увидеть реальный объем приглашений на мероприятия и снизить свой спам-рейтинг. А вот актуализация контрагентов по информации из официальных баз может быть автоматизирована. Но это лишь часть необходимой информации.
Продажи. Что касается продаж, то у дистрибьютора, как правило, основной вал запросов приходит через почту. При этом вносить сотни запросов в день вручную в систему означает значительное снижение производительности труда и мотивации сотрудников. Чтобы упростить ввод информации по сделанным коммерческим предложениям, можно попробовать стандартизировать форму исходящего предложения и загружать ее «по кнопке». Для фокусных дистрибьюторов это реальный вариант, но для крупного широкопрофильного дистрибьютора — нет. Тем более сложно говорить о стандартизации входящих запросов.
Рабочий вариант решения проблемы — машинное обучение и автоматическое распознавание входящих запросов и исходящих предложений. Как показывает практика, для общей аналитики подобные распознанные данные подходят, но для дальнейшей работы по конкретным запросам, например для выставления счета, требуется ручная верификация. Впоследствии можно использовать эти инструменты и для оцифровки входящей информации по другим каналам (мультимодальность).
Слияние дублей. С введением первичной информации тесно связана тема слияния дублей, которая сложна из-за множества зависимостей между данными. В маркетинге сложности возникают, когда в контактных лицах имеется не только контактная информация, но и информация по интересам, карьерной истории, приглашениям и участиям в маркетинговых мероприятиях. В продажах — когда запросы, либо приходят по разным каналам, либо дублируются уже внутри компании из-за нечетких бизнес-процессов. Необходимо выработать правила — как в автоматическом/полуавтоматическом режиме разруливать возникающие конфликтные данные в сливаемых сущностях.
Коррекция данных
Важно учесть и то, что ошибки в данных будут всегда. Другой вопрос — каков для компании приемлемый процент ошибочных и незаполненных данных. Ошибки неизбежны как при автоматизированных процедурах ETL, так и при ручном вводе, даже с автоматическими проверками. Это же живые данные! Поэтому ручные проверки и корректировки тоже будут нужны всегда. Это касается как правок некорректно внесенной информации, так и ее актуализации. Поэтому надо упростить процедуры самостоятельной корректировки информации для пользователей, чтобы они тратили как можно меньше времени на внесение коррективов. Либо можно устраивать периодические чистки по заранее выработанным правилам.
В связи с этим важно проанализировать бизнес-процессы и продумать регламенты проверок данных. В том числе для того, чтобы понимать, как эту процедуру могут осуществлять сами пользователи (зачастую в обход самого очевидного способа) и чем это может обернуться. Потому что «некорректная» коррекция информации может решить частную проблему, но привести к проблемам в отчетности и аналитике.
Приведу пример из жизни. В текущей CRM компании, где я сейчас работаю, нет сущности «Поставщики» — это просто не нужно, поскольку относится к сфере ERP. Однако некоторые сотрудники все же заводили поставщиков в систему под видом новых вендоров, чтобы добавить в новогоднюю рассылку.
При этом полностью полагаться на ручную актуализацию информации для большой компании невозможно. На масштабах крупного дистрибьютора без автоматизации не обойтись.
Доступ к информации
Отдельная тема — доступ к информации. Как для чтения, так и для коррекции. Если второе будет закрыто из-за опасений, что пользователи «накосячат», весьма вероятно, что в конечном счете возникнет так много накопленных ошибок, что система перестанет приносить пользу. Здесь очень важно логгирование изменений, чтобы в случае ошибки можно было узнать, кто был его автором, откатить изменения и научить автора корректной процедуре. Причем зачастую откат изменений должен быть пакетным.
В этом контексте невозможно не упомянуть ФЗ-152 «О персональных данных». Такие инструменты, как ролевой доступ, маскирование данных, логгирование действий, могут использоваться и для соблюдения требований ФЗ.
С коррекциями тесно связана и тема заполнения новых обязательных полей в уже имеющихся формах. Один из вариантов ее решения — не позволять сохранять объекты при их редактировании, если поле не заполнено. Но этот способ тоже несет определенные сложности, ведь редактирующий форму сотрудник не всегда в курсе, что именно было пропущено. Также может сработать автозаполнение: например, контактному лицу можно проставить город на основании его мобильного телефона, либо на основании города контрагента, к которому относится это контактное лицо. Но при таком варианте вероятны ошибки, что возвращает нас к вопросу о цене ошибки в сравнении с пользой от заполненных данных.
Работа со справочниками
Большая и больная тема — сопоставление данных в похожих справочниках в разных информационных системах, особенно если информация в них заводилась раздельно. И даже если эти справочники синхронизируются, в силу разных причин могут накапливаться различия. Если же полная синхронизация невозможна, то проще добавить актуальные данные в один справочник, разбираться и развивать его дальше, позволив второму умереть своей смертью. В таком случае первый становится мастер-справочником. Пример: контактные лица в CRM и ERP, со своими наборами полей, частично пересекающимися и используемыми для разных нужд и ИС.
А если эти справочники активно используются, являются категорийными, и их невозможно соотнести 1:1, то это отдельный разговор. Оставлять все как есть, означает либо отсутствие нужной аналитики и интеграции информационных систем, либо обретение головной боли в виде создания и поддержки кучи «костылей». Либо необходимо модифицировать эти справочники, чистить и только после этого сливать их воедино.
Причем содержание категорийных справочников в принципе может меняться, ведь мы живем в динамичном мире. Таким образом, эту вероятность надо закладывать в архитектуру информационной системы заранее и сразу планировать, где и как отзовутся изменения и какие следует создать процедуры для упрощения обновления справочников.
Жизненный цикл данных
Другая важная тема — обеспечение полного жизненного цикла данных. Чистка данных является обязательной процедурой, которую необходимо автоматизировать. А ведь часто принцип EOL (End Of Life) в данные не закладывается, они бесконтрольно накапливаются и постепенно начинают искажать общую картину или мешать выделению реально нужных и полезных данных. Как пример — неактуальные контактные лица, незакрытые запросы. Понятно, что вручную все не актуализировать, поэтому в какой-то момент приходит осознание, что необходимо создать определенные правила, по которым нужно будет проводить архивирование данных. При автоматизации также могут случаться ошибки, и тут опять надо соблюдать баланс между затратами ресурсов на актуализацию, выгодами от очищенных данных и потенциальными проблемами от проскочивших ошибок.
Данные — это кровь
В заключение хотел бы полнее раскрыть тему того, что данные — это кровь информационных систем. Не претендую на полное и стопроцентно четкое соответствие потока данных и кровеносной системы, но, как мне представляется, в значительной мере ассоциации валидны:
-
Данные должны актуализироваться — как кровь насыщается кислородом.
-
Данные должны прирастать — как новая кровь появляется из костного мозга.
-
Бизнес-логика — это сердце CRM, без активной логики (биения сердца) нет жизни.
-
Некорректные данные приводят к сбою бизнес-логики — как тромбы приводят к инфаркту.
-
Неактуальные данные равносильны застою крови и некрозу окружающих тканей.
-
Старые данные должны удаляться — как старые клетки крови расщепляются в печени.
-
Похищение данных — сродни злонамеренному кровопусканию.
-
Отсутствующие данные — малокровие и гипотония.
Заботьтесь о данных в организме CRM столь же тщательно, как и о собственном организме — и система будет функционировать долго, корректно и радовать вас качественной аналитикой.
Опубликовано 03.04.2023
