Основано на реальных событиях.
Компания, в которой я — бизнес-консультант по CRM, поступил запрос на переезд со старой CRM-системы на новую с переносом клиентской базы.
Не буду называть ни клиента, ни названий CRM-систем. Клиент нашей компании в этой статье будет просто «клиентом», старая CRM-система, с которой раньше работал клиент, будет CRM-old, а новая CRM-система, на которую клиент решил перейти по разным причинам — CRM-new.
История такая: к нам обратился клиент с задачей перехода с CRM-old на CRM-new по таким-то и таким-то причинам. Надо настроить CRM-new под рабочий процесс клиента, интегрировать её с теми каналами связи, которые у него есть и перенести клиентскую базу клиента, накопленную за много лет работы, из CRM-old в CRM-new.
Для нас такая задача — это по большому счёту такое же внедрение, что и обычное внедрение CRM-системы, но дополнительно нужно было сделать экспорт данных из CRM-old и затем их импорт в CRM-new.
Между экспортом данных из старой системы и их импортом в новую на самом деле есть ещё промежуточная отдельная задача по анализу экспортированных данных и их преобразованию при необходимости непосредственно в файлах, то есть работа с таблицами.
Это статья посвящена проблемам и важным моментам, которые могут возникнуть в задаче переноса клиентской базы из одной среды в другую. А точнее, одной проблеме — формату хранения данных в клиентской базе.
Если понимать эту особенность заранее (до начала бизнеса или хотя бы на ранних этапах развития компании), то можно избежать серьёзных проблем в будущем и успешно использовать клиентскую базу, как актив, для дополнительной выгоды — повторные продажи, возврат ушедших клиентов, повышение лояльности активных клиентов, повышения уровня качества обслуживания.
Если же об особенностях формата хранения данных клиентской базы не знать, то может оказаться, что что-либо из перечисленного либо невозможно, либо предполагает незапланированные дополнительные задачи разной сложности (по ручному исправлению данных о контактных телефонах, например).
С чем мы столкнулись, когда приступили к задаче импорта:
1. Ненастраиваемый импорт данных.
В интерфейсе CRM-old вполне можно работать, заполнять нужные данные по клиентской базе. Но импорт данных из этой среды оказался ненастраиваемым. Из всех настроек управления, что относится к импорту — оказалась только одна кнопка «Сделать импорт». То есть выглядит это так, что мы заходим в раздел Клиенты или в раздел Сделки и над списком элементов этих сущностей — кнопка «Импорт в Excel» и больше никаких настроек.
Пользователь не может выбрать какие колонки нужны в таблице импортированного файла — может мне надо только название компании, имя контактного лица и его email, чтобы сделать рассылку. А может мне надо название компании, сумма сделок с ним, признаки номенклатурных групп по состоявшимся сделкам и дата последнего контакта, чтобы отдать маркетологу для сегментации и аналитических отчётов.
В обоих случаях формат выгружаемой таблицы будет такой, как решил разработчик среды и у клиента нет никакой возможности на это повлиять.
2. Одна сущность для хранения данных о клиентах, а не две.
Оказалось так, что в интерфейсе CRM-old видим одно, а после импорта данных в таблицах файлов — другое. Сами-то данные, которые заполнял менеджер, конечно же сохраняются, но вот структура представления данных в интерфейсе и в выгруженном файле в CRM-old, как оказалось, отличаются.
В интерфейсе мы работаем в сущности клиента как с компанией клиента, но можно заполнять эту сущность и данными физического лица — человека, если он работает в этой компании, или индивидуальный предприниматель, или выступает в роли агента. В компании клиента мы можем заводить контакты этого клиента, с которыми мы фактически контактируем, директор, бухгалтер, менеджер и так далее. по каждому созданному контакту внутри Компании мы можем заполнять набор признаков — телефоны, почта, должность и так далее. Выглядит всё это так, как будто мы заполняем отдельную сущность контакт, но мир жесток и правда жизни бьёт наотмашь при встрече с конкретикой задачи по импорту данных.
В CRM-old, заполняя контактные данные по какому-нибудь лицу, например ЛПРа вносим в компании клиента, на самом деле мы не заполняем данные в новом элементе отдельной сущности Контакт. На самом деле мы заполняем одно из свойств всё той же единственной сущности Клиент.
А что мы видим в файле импорта? Может быть CRM-old нам выгружает все контакты по компании отдельными строками и помечает, что это именно контакты, а у самих компаний клиента этот признак имеет другое значение — и мы тогда хотя бы путём ручной обработки выгруженного файла сможем разделить этот файл на два — отдельно на компании и отдельно на контакты? А если ещё и привязка к компании у каждого контакта будет по какому-то признаку, из какой именно компании этот контакт, то мы тогда и адекватно связать их сможем.
Но нет. В файле выгрузки мы получаем один файл, в котором одна строка — это один клиент (одна компания), по которому в одну кучу (в одну ячейку) свалены данные по всем контактам, в одну кучу все их телефоны. Есть отдельная колонка таблицы «Email контактов», куда свалены все email-адреса всех контактов этого клиента. Есть также замечательные колонки Должности контактов, Адреса контактов. Смотрим на какую-нибудь строчку такого файла и видим, что данных по клиенту много-много, в ячейке Должности контактов у нас и директор, и бухгалтер, и юристы, и менеджер по закупу, а в соседней ячейке, которая называется Телефоны контактов у нас много-много разных номеров телефонов. И телефоны компании у нас есть, и рабочие с добавочными и даже сотовые номера. Но вот вопрос, какой именно из телефонов кому соответствует. А рядом ещё ячейки с именами — и Василий Петрович, и Анна Петровна и Евгений — кто из них кто по должности — кто теперь вспомнит, когда была последняя сделка по этому клиенту? Никто не знает, в файле импорта таких данных нет. В интерфейсе системы — да, всё видно и понятно, молодец разработчик CRM-old. Но в файле импорта этого нет. Дальше почта, адреса — смысл, думаю, ясен: данные есть, но использовать мы их не можем.
Чтобы такого не было — надо две сущности, а не одна. Компания и клиент. У каждой — свой набор свойств. И признак для сопоставления, чтобы понимать, какой Контакт из какой компании.
Вот что, должен делать интегратор с такими исходными данными, как в описанном примере из жизни? Это при том, что практически в 100% задач на экспорт/импорт всплывает ещё и такая проблема:
3. Ненормализованные данные.
Данные для импорта должны быть нормализованы (соответствовать формату той среды, в которую загружаем данные). Нормализовать — значит привести в требуемый формат. Рассмотрим на примере номеров телефонов: если в файле импорта в ячейке Телефон компании записано:
+7 (ХХХ) ХХХ-ХХ-ХХ, 8(ХХХХХ)ХХ-Х-ХХ добавочный (ХХХХ), +7ХХХ ХХХ-ХХХХ Игорь
то согласно формату в CRM-new, в этой ячейке данные нужно преобразовать в:
8ХХХХХХХХХХ,8ХХХХХХХХХХ,8ХХХХХХХХХХ
Все +7 заменены на 8, убраны все посторонние символы типа пробелов, тире и дефисов, скобок, разные номера отделены друг от друга запятыми, добавочные номера и имена — убраны как данные, которые должны храниться в других ячейках Контактов.
После нормализации данные будут сохранены в CRM-new корректно. Там, где телефонов несколько — они будут отображаться все в одном специально отведённом для телефонов свойстве и будут кликабельны. Для каждого из этих номеров будет работать функция «Click-to-call», когда нажимаешь в CRM на номер телефона клиента, то после этого срабатывает автоматика телефонного вызова на этот номер и ваша телефония соединяет вас с клиентом, ничего нигде дополнительно нажимать не нужно.
Если данные не нормализовать, то в CRM-new свойство телефон будет забито некликабельной текстовой информацией. «Click-to-call» не будет работать, потому что телефония обычно не понимает, на какой именно номер нужно позвонить, если набирается не «8ХХХХХХХХХХ», а «8(ХХХХХ)ХХ-Х-ХХ добавочный (ХХХХ), +7ХХХ ХХХ-ХХХХ Игорь». Телефония обычно понимает только цифры и не понимает пробелы, скобки, другие символы.
Таким образом, в реальном случае из жизни нашей компании была сформирована задача на нормализацию данных в файлах для импорта, которую мы передали клиенту. Задача минимум — привести в порядок номера телефонов и адреса почты. Задача максимум — навести порядок в дополнительных данных, относящихся к контактам, чтобы хотя бы понимать, к какому контакту что относится.
Если этого не делать, то данные в ячейке можно перенести «как есть» в новую CRM, предварительно создав в ней новые текстовые поля. Но тогда они будут не функциональные, а просто информационные, для того, кто будет с ними работать в новой CRM. Но нужно, чтобы хотя бы было понятно, какой Иван Петрович какой должности и какому номеру телефона соответствует, то есть хотя бы пронумеровать в ячейках все данные, какие данные к какому контакту относится. Как вы уже догадываетесь — это очень долго.
Обработка дублей (разных клиентов у которых по разным причинам один в один совпало название) — это вообще отдельный вопрос. Особенно, если помимо клиентской базы, как таковой, надо перенести и историю сделок, каждую из которых нужно привязать к конкретному клиенту.
Вот что нам делать, если клиентов в базе с одинаковым названием несколько? В таких случаях выручает уникальный ключ — идентификатор клиента, который должен содержаться и файле клиентов — у какого клиента какой идентификатор, и в файле сделок — какая сделка соответствуют какому идентификатору клиента. В нашем примере уникального id в файлах не было.
Своими силами наша компания обычно за такую задачу (приведение файлов для импорта в нужный вид) не берётся. Наша задача — это внедрение CRM, задача импорта — это лишь частная задача внедрения, и это низкоуровневая задача, для которой, как правило, нужны общая компьютерная грамотность и навыки работы в excel. Компетенций эта задача требует простых, а времени — очень много. Соответственно сколько бы мы ни взяли денег за такую задачу — для нас это будет убыточно, потому что все наши специалисты имеют гораздо более высокие компетенции и мы должны рационально использовать их время.
Поэтому обычно мы консультируем клиента по вопросам экспорта/импорта данных и даём либо шаблон для загрузки данных из новой CRM, либо чёткие указания, какие данные и как именно нужно нормализовать.
Из-за таких ситуаций клиент может ожидать выполнения его общей задачи по внедрению новой CRM, но, при этом, никак не ожидать, что ему самому придётся задействовать какой-то свой ресурс для выполнения частной задачи по подготовке файлов импорта.
Чтобы избежать подобного, стараемся заранее узнать, нужен будет импорт клиентской базы или нет, и если да, то предупреждаем о возможных последствиях. Иногда просим образцы файлов импорта.
Статья о том, что нужно предусмотреть для качественного ведения своей клиентской базы, доступна по этой ссылке.
А для каких целей бизнесу может быть полезна грамотно ведущаяся клиентская база, читайте здесь.
