Атлас
Клиентский портал производственной компании — заказы, спецификации, документы и статусы отгрузок вместо почты и звонков.
Сайты и веб-платформы · Интеграции и данные
Сроки3–5 месяцев до запуска пилота — ориентир, уточняется после обследования
05 / 06
Системы обмениваются данными сами, без ручного переноса
Для компаний, где учёт, CRM, склад и сайт росли независимо, а сотрудники стали переносить данные между ними руками. Отчёты разных систем показывают разные цифры, на каждом стыке заказа что-то теряется, новый канал продаж упирается в обмен со старым учётом. Строим интеграционный слой, аналитическое хранилище и конвейеры данных — набор разрозненных продуктов становится связанным цифровым контуром.
С какими ситуациями приходят
- Данные переносят между CRM, учётом и складом вручную
- Отчёты разных систем показывают разные цифры по одним операциям
- Новый канал продаж упирается в обмен со старой учётной системой
- Заказ идёт через несколько систем, и на каждом стыке что-то теряется
- Аналитика собирается из выгрузок и устаревает раньше, чем дойдёт до руководства
- Переход на новую платформу заблокирован: неясно, как перенести историю
- Подключение партнёра или маркетплейса каждый раз превращается в проект
Что создаём
- Интеграционный слой и API
- Шины данных и брокеры событий
- Аналитические хранилища и витрины
- Конвейеры сбора и обработки данных
- Сервисы единых справочников
- Платёжные, логистические и государственные подключения
- Переносы данных между системами
Что входит в работы
- Обмен событиями в реальном времени
- Гарантированная доставка и повторные попытки
- Единые справочники клиентов и номенклатуры
- Версионирование API и обратная совместимость
- Проверка и преобразование данных на лету
- Наблюдение за обменами и сигналы о сбоях
- Оркестрация сквозных процессов между системами
- Перенос данных со сверкой полноты
- Историческая отчётность и витрины для BI
Как устроено решение
Системы не связываются напрямую каждая с каждой — обмен идёт через общий слой: шину событий и API-шлюз, где описаны правила и формат каждого сообщения. Такой контур переживает замену любой системы: меняется один переходник, а не десятки связей, и стоимость следующего подключения не растёт вместе с числом систем. Для отчётности данные складываются в отдельное хранилище, поэтому тяжёлые выгрузки не тормозят работу склада и продаж. Внешние сервисы — платёжные, логистические, государственные — подключаются через изолированные адаптеры с контролем ошибок и повторными попытками.
Слои решения
data и хранилища
PostgreSQL · ClickHouse · Kafka · RabbitMQ · Apache Airflow · Debezium · dbt
integrations
REST · GraphQL
infrastructure и devops
Kubernetes · Prometheus · Grafana
Интеграции
1С
- 1С:Предприятие
- обмен справочниками
- обмен документами и остатками
crm
- CRM по API
erp и учётные системы
- ERP заказчика
- складской учёт
платежи и банки
- платёжные сервисы
- банковские выписки
документооборот
- операторы ЭДО
логистика
- логистические сервисы
api и обмен данными
- REST API
- GraphQL API
- вебхуки и обратные вызовы
- шины данных и брокеры событий
- госсервисы
Как работаем
Обследование
Разбираем контур: какие системы есть, какими данными обмениваются, где ручные операции и дубли. Фиксируем владельца каждой сущности и ограничения систем — что можно дорабатывать, а что нет.
Проектирование
Описываем контракты обмена, форматы событий и модель хранилища, согласуем источник истины для клиентов, номенклатуры, цен и остатков. Составляем очередь стыков по величине потерь.
Разработка
Строим слой, переходники и конвейеры итерациями, начиная с самого болезненного стыка. Каждый обмен закрываем автоматическими проверками и сверкой.
Проверка на реальных объёмах
Прогоняем обмены на боевых объёмах и граничных случаях: дубли, частичные сбои, недоступность одной из систем. Данные на входе и выходе сверяем по количеству записей и суммам.
Внедрение и обучение
Запускаем обмены параллельно с текущим процессом и отключаем ручной перенос только после того, как данные сходятся. Показываем ответственным, как читать наблюдение, разбирать сбой и подключать новую систему по регламенту.
Эксплуатация и развитие
Следим за обменами, разбираем сбои, подключаем новые системы к готовому контуру. Хранилище расширяем под новые вопросы руководства.
Что получает компания
- Работающий интеграционный контур с наблюдением и сигналами о сбоях
- Описанные контракты API и схемы данных
- Исходный код переходников и конвейеров в вашем репозитории
- Аналитическое хранилище с настроенными витринами
- Регламент подключения новой системы к контуру
- Инструкции по эксплуатации и разбору сбоев
- Протоколы сверки данных после переноса
Качество и безопасность
Каждый обмен закрыт автоматическими проверками и сверкой: количество записей и суммы на входе должны сойтись с выходом, иначе обмен останавливается и ответственные получают сигнал. Доступ к данным разграничен по ролям, чувствительные поля шифруются при передаче и хранении, а операции слоя пишутся в журнал — расхождение разбирается по записям, а не по памяти сотрудников. Недоступность одной из систем не рвёт процесс: сообщения ждут в очереди и доставляются после восстановления.
Команда проекта
- Архитектор интеграций
- Инженер по данным
- Backend-разработчики
- Аналитик данных
- Инженер по инфраструктуре
- Руководитель проекта
Как это работает у нас
Говорим на языке бизнеса
Цену разрозненности считаем в понятных величинах: сколько часов уходит на ручной перенос, во что обходится расхождение остатков, сколько руководство ждёт свою сводку. Очередь стыков выстраивается по этим потерям, а не по технической стройности контура.
Проект ведёт основатель
Главное решение проекта — какая система считается источником истины по каждой сущности — основатель согласует с вами лично и отвечает за порядок подключений. Спорные места разбираются на встрече, а не в переписке между отделами.
Внедряем, обучаем, поддерживаем
Ручной обмен отключаем только после сверки на боевых объёмах, а ответственных за данные учим читать наблюдение и разбирать сбой. Регламент подключения новой системы остаётся у вас, поэтому следующий партнёр или маркетплейс подключается без нового проекта.
Проектные сценарии
Единый контур розничной сети
Розничная сеть работает в кассовой системе, учёте и интернет-магазине, которые не обмениваются данными. Остатки на сайте не совпадают с реальными, цены обновляются вручную, а отмены заказов бьют по репутации.
Строим шину: кассы и учёт публикуют события о продажах и приходах, магазин получает актуальные остатки и цены. Справочник номенклатуры ведётся в одном месте и расходится во все системы. Ручное обновление отключается после сверки, и расхождения уходят вместе с ним.
Хранилище вместо сводных таблиц
Дистрибьютор собирает управленческую отчётность из выгрузок нескольких систем. Подготовка занимает дни, цифры из разных источников спорят друг с другом, а решения принимаются по устаревшей картине.
Разворачиваем хранилище, куда конвейеры ежедневно складывают продажи, закупки, остатки и взаиморасчёты. Поверх строим согласованные витрины: у каждого показателя один источник и одно правило расчёта. Руководство смотрит актуальные цифры вместо ожидания сводки.
Переезд с учётной системы без остановки
Производственная компания меняет устаревшую учётную систему, но в ней накоплена история заказов, спецификаций и взаиморасчётов. Остановить работу на время переезда нельзя.
Планируем перенос очередями: сначала справочники и открытые документы, затем история. Старую и новую системы связываем временной синхронизацией, чтобы переходный период они работали параллельно. Каждый этап заканчивается сверкой, и только после неё старый контур отключается.
Типовые решения
Вопросы и ответы
У одной системы нет API, другую нельзя дорабатывать. Что делать?
Прямой API — удобный, но не единственный способ обмена. Работаем через выгрузки файлов, доступ к базе на чтение, механизмы захвата изменений или встроенные средства обмена самой системы. Для закрытых продуктов пишем внешний переходник, который не требует их доработки. Способ выбираем на обследовании, исходя из ограничений каждой стороны.
Как не сломать работающие процессы, пока идёт интеграция?
Обмен запускается параллельно с текущим процессом, а не вместо него: какое-то время данные идут двумя путями и сверяются. Каждый выпуск обратно совместим и может быть откачен. Ручной перенос отключается только после того, как цифры сходятся на боевых объёмах.
Где живут данные и кто ими владеет?
Данные остаются вашими и живут в вашей инфраструктуре или вашем облачном аккаунте, доступ к которому у нас есть на время работ. В архитектуре для каждой сущности зафиксированы источник истины и правила доступа. Исходный код и документацию передаём, поэтому сопровождать контур может и ваша команда.
От чего зависит стоимость интеграционного проекта?
От числа систем и направлений обмена, состояния данных в источниках и требований к скорости: обмен в реальном времени дороже ежедневной синхронизации. Сильно влияет состояние самих систем — документация и готовый API сокращают работу, закрытые продукты требуют обходных путей. Поэтому оценке предшествует обследование.
Что будет, если одна из систем окажется недоступна?
Слой рассчитан на сбои: сообщения копятся в очереди и доставляются после восстановления, а не пропадают. Повторные попытки и защита от дублей встроены в каждый переходник. О сбое ответственные узнают из наблюдения, а не от клиентов.
Сможем ли мы подключать новые системы сами?
Да, контур для этого и строится: подключение — это один переходник по описанному регламенту, а не переделка обмена. Передаём исходный код, схемы данных и инструкции. Если своей команды разработки нет, подключаем новые системы в рамках сопровождения.
Обсудить задачу
Опишите задачу и текущий контур — вернёмся с разбором: что входит в работу, в каком порядке и от чего зависит срок.
Первая встреча и разбор задачи — с основателем компании.