Zapier и Albato не спасут, если модель данных разная

Миф о волшебной интеграции

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

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

Отсюда простое правило, которое я повторяю на каждом первом созвоне: интеграция — это транспорт, а не смысл. Транспорт не решает, что везти. Если на складе лежит мусор, грузовик привезёт мусор быстрее и в большем объёме.

Единая модель данных простыми словами

Это общая договорённость: что считается клиентом, что — заявкой, что — сделкой, как они называются и где живёт эталон (единственная запись, которой верят). Один клиент — одна карточка, а не три в трёх сервисах. Один статус сделки понимается всеми одинаково.

Без этой договорённости начинается классика:

• В CRM клиент «Иванов», в почте «ИП Иванов», в табличке «Иванов А.» — и для систем это три разных человека. Дубли плодятся сами.
• Менеджер закрыл сделку в одном месте, в другом она висит открытой. Какой статус настоящий — непонятно, и отчёт врёт.
• Цифры из разных систем не сходятся: у одной «клиент» — это заявка, у другой — оплата.

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

Как это выглядит на живом примере

Когда мы собирали единый инбокс, в него приехали три канала: 488 диалогов из MAX, 144 из Telegram и 122 из WhatsApp — 754 диалога и порядка 38 тысяч сообщений. И первый же вопрос оказался не техническим, а модельным: что здесь считать одним клиентом.

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

Вторая история из того же проекта — про то, что модель данных касается не только сущностей, но и того, что именно вы считаете «записью». В карточку диалога грузились первые 500 сообщений вместо последних. Формально интеграция работала: сообщения переносились, счётчик показывал число. Фактически менеджер открывал переписку и видел позапрошлый год, а не вчерашний разговор. Ошибка была не в связке систем, а в том, что никто не проговорил, какая часть истории здесь считается актуальной.

Оба случая — из одного класса. Ни один из них не чинится настройкой коннектора.

Что выстроить раньше интеграций

Порядок обратный привычному: сначала модель, потом связи.

1. Опишите сущности. Что вообще есть в вашем бизнесе: клиент, заявка, сделка, договор, оплата. Как каждая называется и чем отличается от соседней. Отдельно проговорите спорные пары — заявка и сделка, клиент и контактное лицо, компания и филиал.
2. Договоритесь о ключевых полях и статусах. Один список статусов сделки на всех. Один справочник источников. Одни правила, что такое дубль и как его склеивать.
3. Назначьте источник правды. Одна система — эталон по каждой сущности (например, CRM — по клиентам и сделкам). Остальные подтягиваются к ней, а не спорят с ней.
4. И только теперь связывайте. Интеграция переносит согласованные данные из эталона в подчинённые системы — в одну сторону, без встречных правок.

Из чего состоит договорённость: чек-лист по каждой сущности

Пункт «опишите сущности» звучит абстрактно, пока не превратится в таблицу. По каждой сущности нужны ответы на шесть вопросов:

• Определение одной фразой. «Заявка — это факт обращения, ещё не проверенный на адекватность». Если фразу не получается написать, значит сущность в голове ещё не отделилась от соседней.
• Ключ. По какому полю запись опознаётся как та же самая. У клиента это обычно телефон или ИНН, у сделки — внутренний номер.
• Правило дубля. Что делать, когда ключи совпали частично. Совпал телефон, но разные имена — это один человек или два? Ответ должен быть записан до первой склейки, а не после сотой.
• Обязательные поля. Без чего запись не имеет смысла. Тут важно не переборщить: каждое обязательное поле — это шаг, который менеджер будет обходить.
• Список статусов. Закрытый, с определением каждого. «В работе» — это как? Позвонили? Отправили предложение? Разные люди ответят по-разному, и отчёт развалится ровно на этом.
• Владелец справочника. Кто имеет право добавить новый статус или новый источник. Если право есть у всех, через полгода в справочнике источников будет полсотни строк с опечатками.

Это самая скучная часть проекта и одновременно самая дешёвая в исправлении. Переписать определение в документе стоит десять минут. Переписать его в трёх работающих системах через год — отдельный проект.

Как выбрать источник правды

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

• По клиентам и сделкам эталон почти всегда CRM — там сидят менеджеры.
• По деньгам эталон обычно бухгалтерская система, а не CRM: сумма в сделке — это ожидание, сумма в бухгалтерии — факт.
• По товарам и остаткам — учётная система, а не сайт.

Дальше действует принцип одной стрелки: из эталона данные идут вниз, к подчинённым системам. Обратно — только заявки на изменение, которые обрабатывает человек, а не автоматическая перезапись. Как только стрелок стало две, у вас появилась гонка, и рано или поздно она сотрёт чью-то правку.

Возражения и пограничные случаи

«У нас всего две системы, зачем нам модель». Модель нужна не из-за количества систем, а из-за количества людей, которые их заполняют. Две системы и пять менеджеров дают пять трактовок статуса «в работе». Правда, объём работы тут маленький: одна страница текста закрывает вопрос.

«У нас всё в одной CRM, источник правды очевиден». Внутри одной системы модель тоже расползается: три поля под телефон, два справочника источников, сделки, заведённые «на компанию», и сделки «на человека». Одна система защищает от расхождений между системами, но не от расхождений между привычками.

«Мы работаем на чужой системе клиента, менять её нельзя». Тогда модель описывается всё равно, но эталоном назначается чужая система, а у себя вы держите только проекцию. Главное — не заводить у себя вторую точку правки тех же записей.

«Дубли уже накопились, поздно». Не поздно, но порядок работ другой: сначала правило дубля, потом разовая чистка, и только потом интеграции. Чистить до того, как правило записано, — значит через месяц чистить снова.

Подводные камни

• Двусторонняя синхронизация без источника правды. Если две системы правят одну и ту же запись навстречу друг другу, вы получаете не порядок, а гонку, кто записал последним. Поток данных должен идти из эталона в подчинённые, а не по кругу.
• Модель «в голове», а не на бумаге. Пока определения клиента и сделки живут в голове у собственника, каждый менеджер и каждый интегратор понимает их по-своему. Договорённость работает, только когда записана.
• Склейка дублей задним числом. Развязать три карточки одного клиента после года работы дороже, чем один раз задать правило дубля. Чем позже беретесь за модель, тем толще слой мусора.
• Интеграция без журнала. Связка, которая молча пропускает ошибочные записи, страшнее упавшей: она создаёт ощущение, что всё перенеслось. У каждой связки должен быть видимый след — что перенесено, что отвергнуто и почему.
• Тишина как признак здоровья. Если интеграция никогда ни на что не жалуется, это не значит, что она работает. Это значит, что вы не узнаете, когда она сломается. Отсутствие ошибок надо уметь отличать от отсутствия проверок.

Что меняется в итоге

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

Именно поэтому единую базу строят до, а не после связок — это несущая стена, а не украшение.

Разобраться, где у вас живёт правда о данных, поможем — опишите задачу через форму или напишите в Telegram.