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