Интеграция вроде бы работает. Сделка из «Битрикс24» ушла в 1С, там появился заказ. Значит, можно закрывать задачу?
Я бы не торопился.
Через неделю выясняется, что часть контрагентов задублировалась. Через две менеджеры замечают, что в CRM старые остатки. Потом бухгалтерия снова просит присылать номера счетов в чат, потому что оплаченные документы не всегда меняют статус сделки.
Технически связь между системами есть. Для бизнеса ее почти нет.
Мы регулярно видим одну и ту же ошибку: интеграцию «Битрикс24» и 1С начинают с установки модуля. Хотя начинать нужно с другого вопроса: как именно должен измениться процесс после подключения?
Если менеджер по-прежнему звонит бухгалтеру, чтобы уточнить оплату, интеграция не закончена. Если бухгалтер повторно заводит заказ, она не закончена. Если данные приходится периодически выгружать в Excel и сравнивать, модуль может работать сколько угодно — задачу он не решил.
«Битрикс24» и 1С обычно отвечают за разные части работы.
В CRM живет клиентский процесс. Обращение, сделка, переписка, звонки, коммерческое предложение, задачи менеджера.
В 1С находится учет. Контрагенты, номенклатура, цены, остатки, счета, поступление денег, резервирование, отгрузка.
Идея интеграции простая: сотрудник делает действие там, где ему удобно и логично работать, а нужные данные автоматически появляются во второй системе.
Например, менеджер формирует сделку в «Битрикс24». Заказ создается в 1С без повторного ввода. Когда деньги поступают, статус оплаты возвращается в CRM. Менеджер видит результат в карточке сделки и не дергает бухгалтерию.
Вот ради этого и стоит делать интеграцию.
Не ради самого факта обмена данными.
Один из первых споров на проекте обычно звучит так:
— А можно, чтобы клиента редактировали и в 1С, и в «Битрикс24»?
Можно. Вопрос в том, что будет дальше.
Менеджер поменяет номер телефона в CRM. Бухгалтер в это же время обновит карточку контрагента в 1С. При очередном обмене одна система перезапишет другую. Иногда победит более свежее изменение. Иногда — то, которое первым попало в очередь. Для пользователей результат будет выглядеть случайным.
Поэтому у каждого типа данных должен быть основной владелец.
Обычно мы предлагаем начинать с такой модели:
| Данные | Где ведем |
| Лиды, сделки, коммуникации | «Битрикс24» |
| Номенклатура и цены | 1С |
| Остатки и резервы | 1С |
| Учетные документы | 1С |
| Оплаты и отгрузки | 1С |
| Статусы оплаты и отгрузки в сделке | Передаем из 1С в CRM |
Это не универсальная таблица. У конкретного бизнеса могут быть другие правила.
Важно не то, какую систему мы выбрали. Важно, что выбор сделан.
Если товар ведется в 1С, менеджер не должен менять его цену вручную в CRM. Если сделка создается в «Битрикс24», не нужно параллельно заводить ее второй раз в учетной системе «на всякий случай».
Двусторонний обмен не означает, что все данные разрешено свободно редактировать с обеих сторон.
Штатный коннектор умеет многое. Он передает клиентов, товары, заказы и документы. Может работать по расписанию или реагировать на изменения. Через него можно получать печатные формы и запускать операции в 1С из роботов «Битрикс24».
Но коннектор не знает, как устроена конкретная компания.
Он не решит:
Это уже не настройка модуля. Это проектирование процесса.
Покажу на простом примере.
Менеджер отправляет заказ из CRM в 1С. Документ успешно создается, но в этот момент пропадает соединение. «Битрикс24» не получает ответ и считает операцию неуспешной.
Через минуту запрос уходит повторно.
Что произойдет?
В слабой интеграции появится второй заказ. В нормальной система найдет документ по внешнему идентификатору и вернет уже созданный результат.
Пользователь этой логики не видит. Но именно из таких деталей складывается разница между рабочим процессом и постоянным ручным разбором.
Не каждой компании нужен сложный обмен между CRM и 1С.
Если заказов немного, а данные передаются один раз в неделю, стоимость автоматизации может оказаться выше стоимости ручной работы.
Интеграция становится оправданной, когда одни и те же действия повторяются постоянно.
Менеджеры заново вводят реквизиты. Бухгалтерия вручную создает заказы. Оплата передается сообщением. Склад отдельно подтверждает наличие. Руководитель собирает общую картину из нескольких отчетов.
Здесь автоматизация дает понятный эффект: информация перестает ходить между отделами через людей.
Но начинать все равно лучше с одного маршрута.
Не надо сразу пытаться синхронизировать клиентов, сделки, товары, остатки, оплаты, отгрузки и все пользовательские поля.
Первый рабочий сценарий может быть таким:
Сделка создается в «Битрикс24». После согласования из нее формируется заказ в 1С. Когда поступает оплата, CRM получает новый статус и переводит сделку на следующий этап.
Если этот маршрут работает стабильно, добавляем резервирование, отгрузку и остатки.
Так проще понять, где именно возникла ошибка. И намного проще вернуть процесс в рабочее состояние.
До установки модуля нужно пройти весь путь заказа.
Кто создает сделку? В какой момент она считается согласованной? Какие данные обязательны для 1С? Может ли менеджер изменить состав заказа после передачи? Что должно вернуться в CRM после оплаты?
Обычно уже на этом этапе выясняется, что у разных подразделений разные представления об одном процессе.
Продажи считают, что заказ можно менять до самой отгрузки. Бухгалтерия — что после создания документа его никто не должен трогать. Склад резервирует товар по своим правилам.
Интеграция просто вытащит эти противоречия наружу.
Поэтому сначала договариваемся о процессе. Потом автоматизируем.
Фраза «у нас обычная 1С» почти ничего не означает.
Это может быть «Бухгалтерия», «Управление торговлей», ERP, УНФ или конфигурация, которую дорабатывали много лет. Иногда внутри компании несколько баз, а между ними уже настроен собственный обмен.
До оценки работ нужно знать:
Бывает, что стандартный коннектор закрывает почти весь процесс. Бывает и наоборот: формально конфигурация подходит, но половина нужной логики живет в собственных документах и обработках.
Тогда потребуется доработка.
Интеграция редко запускается на пустых системах.
В CRM уже есть компании. В 1С — контрагенты. Названия отличаются, телефоны записаны в разных форматах, у одной организации несколько карточек.
Если просто включить обмен, старый беспорядок начнет размножаться.
Для компаний обычно используют ИНН и КПП. Для контактов — телефон и электронную почту. Для товаров — артикул, код или внутренний идентификатор.
Название — плохой ключ.
ООО «Ромашка», «Ромашка» и «Ромашка, ООО» для человека выглядят одинаково. Для системы это могут быть три разных контрагента.
Перед запуском часть записей придется сопоставить, часть объединить, часть удалить. Это не самая интересная стадия проекта, но без нее дальше будет хуже.
Я бы не начинал с собственной интеграции, пока не проверены возможности штатного решения.
Если используется типовая конфигурация, а процесс построен вокруг стандартных клиентов, товаров, заказов и оплат, коннектора часто достаточно.
Это быстрее, дешевле и проще в дальнейшем сопровождении.
Собственная разработка нужна, когда появляются реальные ограничения:
Иногда лучший вариант — смешанный.
Стандартные объекты передаем через коннектор. Специфические сценарии выносим в отдельный сервис.
Не нужно переписывать то, что уже работает штатно. Но и пытаться втиснуть весь бизнес в возможности готового модуля тоже не стоит.
Первый запуск лучше ограничить.
Одна база. Одно юридическое лицо. Один тип заказа. Несколько пользователей. Небольшая группа товаров.
И обязательно пройти несколько сценариев.
Создать новый заказ. Изменить существующий. Отправить один и тот же запрос повторно. Отключить 1С и проверить, что произойдет с очередью. Вернуть систему в работу и убедиться, что данные дошли.
Тест «нажал кнопку — заказ появился» ничего не доказывает.
Надежность проявляется в ошибочных ситуациях.
Что произойдет, если у клиента не заполнен ИНН? Если товар архивирован? Если документ уже существует? Если 1С ответила через минуту вместо нескольких секунд? Если соединение пропало после создания заказа?
Именно эти проверки показывают, можно ли отдавать интеграцию в промышленную эксплуатацию.
Дубли — самая заметная проблема, но причина у них бывает разной.
Иногда система не смогла сопоставить существующего клиента. Иногда запрос ушел повторно. Иногда пользователь сам создал нового контрагента, хотя тот уже был в другой системе.
Поэтому одной проверки по названию недостаточно.
У каждого переданного объекта должен сохраняться внешний идентификатор. «Битрикс24» должна знать, какому документу в 1С соответствует конкретная сделка или заказ. 1С — какой карточке CRM соответствует контрагент.
Тогда повторная передача обновляет существующую запись, а не создает новую.
Особенно важно это для заказов, счетов, оплат и отгрузок. Здесь дубли уже влияют не только на удобство, но и на учет.
Сбой будет. Вопрос только в том, когда.
Недоступна 1С. Истек пароль служебной учетной записи. Изменилась структура поля. После обновления перестал проходить один тип документа.
Нормальная интеграция не должна молча терять данные.
Неуспешная операция остается в очереди. Система делает несколько повторных попыток. Если проблема не решилась, ответственный получает уведомление.
При этом запрос можно отправить повторно без риска создать еще один документ.
Вот четыре вещи, которые нужно видеть постоянно:
Журнал, который никто не открывает, не является мониторингом.
Если об остановке обмена компания узнает от менеджера, значит контроль не настроен.
Иногда обмен настраивают от учетной записи разработчика, администратора или руководителя отдела.
Пока человек работает и его права не меняются, проблем нет.
Потом сотрудник увольняется, учетную запись блокируют, и вместе с ней останавливается интеграция.
Для обмена нужна отдельная служебная учетная запись. С минимально необходимыми правами. Ее пароль хранится централизованно, а не в личных заметках.
То же касается вебхуков, ключей и доступов к HTTP-сервисам.
Критичный бизнес-процесс не должен зависеть от конкретного человека.
Складской учет лучше подключать после базового обмена клиентами и заказами.
Здесь резко возрастает количество связей. Нужно сопоставить номенклатуру, единицы измерения, ставки НДС, типы цен, склады, остатки, резервы и услуги доставки.
Сначала определяется основной каталог.
Если товары ведутся в 1С, менять их названия и цены в CRM не нужно. «Битрикс24» получает данные из учетной системы и использует их в сделках.
Отдельно согласовывается логика остатков.
Что именно показываем менеджеру: физический остаток, доступное количество или остаток за вычетом резерва? По всем складам или только по выбранным? Как быстро информация должна обновляться?
Без этих ответов цифра в CRM будет выглядеть точной, но может не иметь отношения к реально доступному товару.
Интеграция не может оставаться «за разработчиками».
Техническая команда отвечает за передачу данных, ошибки, доступы и восстановление.
Но только бизнес может определить, правильно ли меняется заказ, когда его разрешено редактировать и какой статус должен видеть менеджер.
Нужен владелец процесса. Человек, который понимает, как работают продажи, бухгалтерия и склад, и может принять решение при конфликте.
Без него любая проблема превращается в переписку:
Технически такая интеграция может быть исправна. Организационно — нет.
Не по факту установки модуля.
И не по первому успешно переданному заказу.
Интеграция закончена, когда сотрудники перестали выполнять лишнюю работу.
Менеджер не заводит заказ второй раз. Бухгалтер не пишет об оплате в чат. Данные не дублируются после повторного запроса. Ошибки видны сразу. Неуспешную операцию можно безопасно запустить заново.
После обновления 1С или CRM проводится контрольная проверка, а не ожидание первого инцидента.
Если данные по-прежнему периодически сверяют вручную, проект еще не завершен.
Штатно соединить «Битрикс24» и 1С обычно несложно.
Сложно другое: договориться, какая система за что отвечает, привести в порядок старые данные и продумать поведение обмена при ошибках.
Сам по себе коннектор не устраняет ручную работу. Он только передает информацию.
Рабочим бизнес-процессом интеграция становится тогда, когда каждый объект имеет владельца, каждый запрос можно повторить без дублей, а каждая ошибка попадает не в забытый журнал, а к ответственному человеку.
В «Энсайн» такие проекты мы начинаем с разбора процесса. Смотрим, где сотрудники повторно вводят информацию, как сейчас передаются оплаты и заказы, какие данные расходятся.
И только после этого выбираем способ подключения.
Иногда хватает штатного коннектора. Иногда нужен отдельный интеграционный слой. Но цель в обоих случаях одна: сотрудники должны работать с клиентами и документами, а не обслуживать обмен между системами.