Интеграция Bitrix и LogON в компании «EASTEX»
Разработка ETL-связки и двусторонней синхронизации данных
Проект был нацелен на то, чтобы связать CRM-контур продаж и основную корпоративную систему заказчика. Команда РАУ ИТ спроектировала и реализовала интеграцию, которая обеспечивает корректный обмен данными между системами, снижает долю ручных операций и создаёт бесшовную связь между коммерческим и операционным контуром.
О компании
EASTEX — логистический оператор, работающий преимущественно на азиатском направлении. В компании работает около 120 сотрудников, клиентская база насчитывает порядка 300 компаний. Компания обрабатывает до 700 заявок в месяц. Пик нагрузки приходится на период с ноября до китайского Нового года.
Исходная ситуация и бизнес-задача
У заказчика одновременно использовались две системы: LogON — как основной операционный контур, и Битрикс 24 — как рабочий инструмент отдела продаж. Такая архитектура возникла не как заранее спроектированная модель, а как практический ответ на разные задачи подразделений.
В LogON велись учётные данные. Но для отдела продаж эта система оказалась неудобной: менеджерам требовалась не столько операционная детализация, сколько CRM-логика — история обращений, задачи, стадии работы с клиентом, источники лидов.
В результате коммерческий блок фактически перешёл в Битрик24. Менеджеры начали вести лиды, коммуникации и воронки, а также использовать систему как корпоративный портал — с новостями, карточками сотрудников, чатами, календарями и встречами.
Так появилось разделение: одна часть компании работала в 1С-Битрикс, другая — в LogON. Без интеграции данные приходилось переносить вручную. Когда клиент переходил из стадии продажи в расчёт или операционную работу, сотрудникам приходилось дополнительно вносить информацию во вторую систему.
Со временем это привело не просто к дополнительной нагрузке, а к системному расхождению данных. В итоге часто приходилось подтверждать актуальность данных.
Отдельной проблемой была аналитика. Поскольку информация находилась в разных системах, компании приходилось регулярно сопоставлять данные. Это создавало и прямые трудозатраты, и риск ошибок из-за человеческого фактора.
Бизнес-задача проекта заключалась в том, чтобы обеспечить сквозной, управляемый обмен данными между системами: сотрудники должны были продолжить работать в привычных интерфейсах, но без двойного ввода, дублирования сущностей и постоянной ручной сверки.
В LogON велись учётные данные. Но для отдела продаж эта система оказалась неудобной: менеджерам требовалась не столько операционная детализация, сколько CRM-логика — история обращений, задачи, стадии работы с клиентом, источники лидов.
В результате коммерческий блок фактически перешёл в Битрик24. Менеджеры начали вести лиды, коммуникации и воронки, а также использовать систему как корпоративный портал — с новостями, карточками сотрудников, чатами, календарями и встречами.
Так появилось разделение: одна часть компании работала в 1С-Битрикс, другая — в LogON. Без интеграции данные приходилось переносить вручную. Когда клиент переходил из стадии продажи в расчёт или операционную работу, сотрудникам приходилось дополнительно вносить информацию во вторую систему.
Со временем это привело не просто к дополнительной нагрузке, а к системному расхождению данных. В итоге часто приходилось подтверждать актуальность данных.
Отдельной проблемой была аналитика. Поскольку информация находилась в разных системах, компании приходилось регулярно сопоставлять данные. Это создавало и прямые трудозатраты, и риск ошибок из-за человеческого фактора.
Бизнес-задача проекта заключалась в том, чтобы обеспечить сквозной, управляемый обмен данными между системами: сотрудники должны были продолжить работать в привычных интерфейсах, но без двойного ввода, дублирования сущностей и постоянной ручной сверки.
Ключевые риски, которые требовали проработки
Проект с самого начала был связан с рядом рисков и ограничений:
- расхождение данных между системами и «двойной ввод»;
- работа на «живых» данных: пользователи уже вели деятельность в обеих системах;
- большое количество нестандартных пользовательских сценариев;
- ограничения по тестированию и информационной безопасности;
- необходимость выбрать режим обмена, который даст актуальность данных, но не создаст лишнюю нагрузку на инфраструктуру.
“
Этот проект — очень кропотливая, муторная работа. Было тяжело найти подрядчика для работы с двумя уже модернизированными системами. Здесь нужно долго разбираться, что и как устроено, чем непосредственно настраивать. Поэтому сам по себе факт, что РАУ ИТ захотела этим заниматься, уже был важным аргументом.
К тому же задачу по Битрикс 24 логичнее было отдать команде, у которой есть сильная экспертиза. В этом смысле РАУ ИТ выглядела более подходящим вариантом. Ну и, конечно, сыграли роль условия. Насколько я помню, у РАУ ИТ были либо более быстрые, либо более выгодные условия — возможно, и то и другое в совокупности.
В итоге сочетание факторов получилось довольно понятное: РАУ ИТ была готова взяться за сложную и трудоёмкую задачу, у команды была нужная экспертиза именно в 1С-Битрикс, а стоимость проекта оставалась для нас разумной.
К тому же задачу по Битрикс 24 логичнее было отдать команде, у которой есть сильная экспертиза. В этом смысле РАУ ИТ выглядела более подходящим вариантом. Ну и, конечно, сыграли роль условия. Насколько я помню, у РАУ ИТ были либо более быстрые, либо более выгодные условия — возможно, и то и другое в совокупности.
В итоге сочетание факторов получилось довольно понятное: РАУ ИТ была готова взяться за сложную и трудоёмкую задачу, у команды была нужная экспертиза именно в 1С-Битрикс, а стоимость проекта оставалась для нас разумной.
Решение РАУ ИТ
РАУ ИТ предложила и реализовала интеграционную ETL-прослойку, которая обеспечивает извлечение данных из одной системы, преобразование под правила другой и загрузку в целевой контур. В результате обмен стал управляемым: с понятными сценариями, правилами маппинга и контролем того, какие изменения считаются «истинными» для каждой сущности.
При этом интеграция строилась с учётом бизнес-логики заказчика. Важно было не просто «соединить две базы», а сохранить разделение ролей между системами. В Битрикс 24 находился весь «верх» воронки продаж, включая лиды из разных источников, обращения и первичную работу менеджеров.
В LogON должны были попадать только те сущности, которые уже перешли в реальную работу: клиенты, по которым начался расчёт, или действующие заказчики. Поэтому холодные лиды, спам и неподтверждённые обращения в основной контур не переносились. Как только лид в Битрикс 24 достигал нужного статуса, в LogON автоматически создавались карточка компании, карточка контакта и запрос на расчёт. После этого ключевые данные начинали синхронизироваться в обе стороны.
При этом интеграция строилась с учётом бизнес-логики заказчика. Важно было не просто «соединить две базы», а сохранить разделение ролей между системами. В Битрикс 24 находился весь «верх» воронки продаж, включая лиды из разных источников, обращения и первичную работу менеджеров.
В LogON должны были попадать только те сущности, которые уже перешли в реальную работу: клиенты, по которым начался расчёт, или действующие заказчики. Поэтому холодные лиды, спам и неподтверждённые обращения в основной контур не переносились. Как только лид в Битрикс 24 достигал нужного статуса, в LogON автоматически создавались карточка компании, карточка контакта и запрос на расчёт. После этого ключевые данные начинали синхронизироваться в обе стороны.
Что именно синхронизировали
Работы выполнялись поэтапно, чтобы снизить риски и проверить корректность обмена на ключевых сущностях до расширения контура.
Этап 1. Контрагенты, контакты и компании
На первом этапе был выстроен базовый фундамент синхронизации: автоматическое создание и обновление карточек компаний и контактных лиц между системами. Именно эта часть была критична для устранения дублей и расхождений по клиентской базе. После запуска стало возможно менять данные и в одной, и в другой системе без опасения, что базы снова разойдутся.
Этап 2. Заказы и запросы
На втором этапе контур расширили на операционные сущности — запросы и заказы. Кроме того, в Битрикс 24 были перенесены действующие заказы и запросы, которые раньше велись только в LogON и не отражались в CRM. Это позволило собирать аналитику по клиентам в одном контуре и видеть не только верх воронки, но и дальнейшую операционную работу.
Ход работ
Прояснение требований и перевод бизнес-ТЗ в техническое
На старте команда собрала ожидания бизнеса и уточнила, какие данные нужны, кому и в какой момент. Далее РАУ ИТ перевела бизнесовые формулировки в технические требования: определили состав сущностей, правила сопоставления полей, сценарии обновления и согласовали границы ответственности систем. При этом задача была не в абстрактной «синхронизации всего со всем», а в точной настройке жизненного цикла данных: что создаётся в 1С-Битрикс, в какой момент передаётся в LogON и какие изменения должны идти обратно.
Техническое обследование и подготовка ТЗ на интеграцию
Команда провела техническое исследование систем: доступные интерфейсы, ограничения API, особенности структуры данных и требования по безопасности. По итогам подготовили техническое задание, на основе которого строилась реализация.
Разработка, тестирование и поэтапный запуск
Интеграция внедрялась на работающих системах с уже заполненными данными. Поэтому запуск делали поэтапно: сначала реализовали и обкатали обмен по базовым справочникам, затем расширили контур на заказы и запросы. После каждого этапа устраняли выявленные ошибки и подтверждали корректность работы вместе с заказчиком.
Именно на этом этапе проявилась реальная сложность проекта. Даже если базовые сценарии были предусмотрены, в живой эксплуатации всегда возникали дополнительные варианты поведения пользователей: удаление карточек, создание дублей, объединение записей, нестандартные изменения в карточках, сценарии, которые не были очевидны на старте. Поэтому проект потребовал большого объёма совместного тестирования и нескольких итераций доработки. Со стороны заказчика на тестирование тоже ушло заметное время.
Именно на этом этапе проявилась реальная сложность проекта. Даже если базовые сценарии были предусмотрены, в живой эксплуатации всегда возникали дополнительные варианты поведения пользователей: удаление карточек, создание дублей, объединение записей, нестандартные изменения в карточках, сценарии, которые не были очевидны на старте. Поэтому проект потребовал большого объёма совместного тестирования и нескольких итераций доработки. Со стороны заказчика на тестирование тоже ушло заметное время.
Настройка периодичности обмена
РАУ ИТ проработала режимы обмена с учётом того, когда и как пользователи обращаются к данным. Это позволило избежать лишней нагрузки: например, не выполнять тяжёлые выгрузки в неподходящие периоды и обеспечивать более высокую актуальность информации тогда, когда она действительно влияет на оперативные решения.
Сложности проекта и как их решили
Работа с «живыми» данными и ограничениями безопасности
Поскольку пользователи уже работали в обеих системах, нельзя было «включить всё сразу». Часть данных была чувствительной, тестирование — ограниченным, а включение обмена в неподходящее время могло затронуть другие контуры. Поэтому РАУ ИТ заранее проработала ограничения, выбрала безопасный сценарий запуска и шла через поэтапное расширение функционала.
Большое число пользовательских сценариев
Отдельная сложность заключалась в том, что реальные действия сотрудников оказались шире исходно согласованных сценариев. В рабочем контуре пользователи создавали дубли, меняли и удаляли карточки, по-разному вели контакты и компании. Это требовало постоянной проверки сценариев, выявления ошибок и доработки логики обмена. За счёт поэтапного запуска и плотной совместной проверки РАУ ИТ удалось довести интеграцию до рабочего состояния на реальных данных.
Результат
Компания «EASTEX» получила устойчивую интеграцию между LogON и Битрикс 24 с двусторонним обменом по согласованным правилам.
- Сокращение переноса данных между системамиМенеджерам больше не нужно тратить время на актуализацию информации. Это снимает лишнюю нагрузку и убирает дублирование функций.
- Меньше ошибок и расхожденийДанные о клиентах, контактах, запросах и заказах становятся согласованными между коммерческим и операционным контуром.
- Единая аналитикаСущественная часть ценности проекта для заказчика заключалась в том, что аналитика перестала собираться из двух разрозненных источников. После переноса действующих заказов и запросов в Битрикс 24 данные по клиентам стало возможно видеть в одном контуре.
- Более быстрая обработка обращений и заказовЗа счёт актуальной информации в CRM и устранения ручных промежуточных шагов работа коммерческого блока и передача клиента в операционный контур стали быстрее и прозрачнее.
- Понятная управляемость интеграцииПравила обмена и обновления формализованы, а сама связка остаётся расширяемой: при необходимости её можно развивать и на новые сущности.
- Снижение рисков при эксплуатацииПоэтапное внедрение, совместное тестирование и учёт ограничений безопасности позволили снизить риск ошибок при запуске. Дополнительным плюсом стала готовность команды РАУ ИТ оперативно подключаться, если из-за обновлений Битрикс 24 или LogON возникают сбои в работе интеграционного моста. Заказчик отдельно отмечал этот фактор как важный для спокойной эксплуатации решения.
“
Для нас здесь также важно, что в такой ситуации не возникает ощущения, будто нас оставили один на один с этой связкой. Нет опасения, что проект закончился — и дальше уже никто не поможет. Когда у нас возникают вопросы, специалист РАУ ИТ оперативно включается, смотрит, в чём проблема, и помогает разобраться. Главное, что ваши сотрудники не отвечают в духе: «Проект завершён, разбирайтесь сами». И вот это, на мой взгляд, большой плюс: интеграция используется, она рабочая, а если что-то происходит из-за внешних факторов, есть понимание, к кому идти и что вопрос не останется без реакции.
Итоги проекта
В рамках проекта команда:
Итогом проекта стала рабочая связка CRM и основного операционного контура, которая поддерживает продажи и исполнение без двойного ввода, снижает расхождения в данных и делает клиентскую аналитику более полной и управляемой. Для EASTEX это означало не просто техническую интеграцию двух систем, а выстраивание более устойчивого процесса на стыке продаж и операций.
- декомпозировала бизнес-запрос и формализовала требования к обмену данными;
- провела техническое обследование систем, проанализировала ограничения и подготовила ТЗ;
- спроектировала ETL-логику: правила преобразования данных, маппинг сущностей, сценарии обновления;
- реализовала двусторонний обмен и поэтапное расширение контура синхронизации;
- провела тестирование на реальных сценариях, устранила ошибки и сопровождала запуск;
- сохранила доступность команды после завершения проекта для решения вопросов, возникающих из-за изменений во внешних системах.
Итогом проекта стала рабочая связка CRM и основного операционного контура, которая поддерживает продажи и исполнение без двойного ввода, снижает расхождения в данных и делает клиентскую аналитику более полной и управляемой. Для EASTEX это означало не просто техническую интеграцию двух систем, а выстраивание более устойчивого процесса на стыке продаж и операций.