1. Контекст интеграционного контура
Интеграция проектируется как управляемый бизнес-процесс
ПроектИнтеграция личного кабинета, CRM, ERP и складской системы
ЦельОбеспечить сквозной процесс от заявки клиента до статуса заказа, документов и уведомлений в личном кабинете
Ключевая задачаИсключить ручной перенос данных, дублирование сущностей, потерю заявок и расхождение статусов между системами
Граница документасистемы, владельцы, потоки данных, события обмена, статусы, мастер-источники, обработка ошибок, мониторинг, риски и план пилота
Бизнес-гипотеза: если заявка из личного кабинета автоматически проходит CRM и ERP и возвращает клиенту понятный статус, снижаются ручные операции, ошибки, нагрузка на менеджеров и обращения в поддержку.
2-3. Системы и целевая логика
Системы интеграционного контура
| Система | Роль в контуре | Тип | Владелец | Критичность |
|---|---|---|---|---|
| Личный кабинет | Точка входа клиента, отображение заявок, статусов и документов | Frontend + backend | Product / IT | High |
| CRM | Управление клиентами, сделками и менеджерской обработкой | SaaS / internal CRM | Sales Ops | High |
| ERP | Заказы, оплаты, документы, учет исполнения | Учетная система | Finance / Operations | High |
| WMS | Складские остатки, комплектация, отгрузка | Складская система | Logistics | Medium |
| Notification Gateway | Email/SMS-уведомления | Внешний сервис | IT | Medium |
| DWH | Аналитика и отчетность | Data platform | Analytics | Medium |
| SSO/Auth | Авторизация, роли, токены доступа | Identity provider | IT Security | High |
| Monitoring | Логи, алерты, технические метрики | Observability platform | IT Operations | High |
Целевая логика интеграции
| Принцип | Как применяется |
|---|---|
| Одна бизнес-сущность — один внешний ID | Заявка, сделка и заказ связываются через external_request_id |
| Мастер-система определена для каждой сущности | Компания — CRM, заказ — ERP, документы — ERP, заявка — ЛК |
| Ошибка API не должна приводить к потере данных | Используются retry-очереди, статусы синхронизации и журнал ошибок |
| Статусы клиента отделены от внутренних статусов | ERP-статусы маппятся в понятные клиентские статусы |
| Интеграция должна быть наблюдаемой | Для каждого обмена есть лог, correlation ID и алерт по ошибкам |
| Запуск должен быть поэтапным | Dry-run, shadow mode, ограниченный пилот, расширенный пилот, rollout |
4. Организационная модель интеграций
Владельцы систем, данных и ключевых решений
| Область | Владелец | Зона ответственности |
|---|---|---|
| Личный кабинет | Product owner | Пользовательские сценарии, статусы для клиента, adoption |
| CRM | Sales Ops | Сделки, менеджеры, воронка, правила обработки |
| ERP | Finance / Operations | Заказы, оплаты, документы, учетные статусы |
| WMS | Logistics | Складские статусы, отгрузка, наличие |
| Интеграционная архитектура | IT Architect | Контур обменов, API, очереди, error handling |
| Информационная безопасность | IT Security | Доступы, токены, персональные данные, аудит |
| Поддержка | Support lead | Обработка инцидентов, обращения клиентов, эскалация |
| Аналитика | Analytics lead | DWH, витрины данных, KPI процесса |
RACI по ключевым решениям
| Решение / Процесс | Product | Sales Ops | Operations | Finance | IT | Security | Support |
|---|---|---|---|---|---|---|---|
| Правила создания заявки | A/R | C | C | I | C | I | I |
| Маппинг заявки в CRM | C | A/R | I | I | R | I | I |
| Создание заказа в ERP | I | C | A/R | C | R | I | I |
| Маппинг статусов для клиента | A/R | C | C | C | R | I | C |
| Правила доступа к документам | C | I | I | A/R | R | A/R | I |
| Error handling интеграций | C | C | C | C | A/R | C | I |
| Мониторинг и алерты | I | I | I | I | A/R | C | R |
| Решение Go / No-Go пилота | A | C | C | C | A | C | C |
R - Responsible, A - Accountable, C - Consulted, I - Informed.
5. Master data
Master data и правила владения данными
| Сущность | Master system | Где можно редактировать | Где только читать | Ключ связи |
|---|---|---|---|---|
| Компания | CRM | CRM | ЛК, ERP, DWH | company_external_id |
| Контакт клиента | CRM | CRM, ЛК с подтверждением | ERP, DWH | contact_external_id |
| Пользователь | SSO/Auth | SSO/Auth | ЛК, CRM | user_id |
| Заявка | Личный кабинет | ЛК до передачи в CRM | CRM, DWH | external_request_id |
| Сделка | CRM | CRM | ЛК, ERP, DWH | crm_deal_id |
| Заказ | ERP | ERP | ЛК, CRM, DWH | erp_order_id |
| Статус заказа | ERP | ERP | ЛК, CRM | erp_order_id |
| Документ | ERP | ERP | ЛК | document_id |
| Отгрузка | WMS | WMS | ERP, ЛК | shipment_id |
| Уведомление | ЛК / Gateway | ЛК | Gateway, DWH | notification_id |
6-8. Карта потоков данных
Карта потоков данных и end-to-end сценарий
| ID | Источник | Получатель | Событие | Данные | Частота | Критичность |
|---|---|---|---|---|---|---|
| DF-01 | Личный кабинет | CRM | Создана заявка | Компания, контакт, состав заявки, файлы, комментарий | Real-time | High |
| DF-02 | CRM | ERP | Сделка подтверждена | Сделка, клиент, условия, сумма, ответственный | Real-time / batch | High |
| DF-03 | ERP | Личный кабинет | Обновлен статус заказа | Номер заказа, внутренний статус, дата изменения | Каждые 15 минут | High |
| DF-04 | ERP | Личный кабинет | Сформированы документы | Счет, акт, УПД, ссылка на файл, права доступа | По событию | High |
| DF-05 | WMS | ERP | Обновлен статус отгрузки | Заказ, склад, статус отгрузки, дата | Каждые 30 минут | Medium |
| DF-06 | Личный кабинет | Notification Gateway | Нужно уведомить клиента | Email, телефон, шаблон, событие, ссылка | По событию | Medium |
| DF-07 | CRM | DWH | Обновлена сделка | Сделка, менеджер, стадия, сумма, источник | Ежедневно | Medium |
| DF-08 | Личный кабинет | Monitoring | Ошибка интеграции | Correlation ID, payload ID, код ошибки, время | Real-time | High |
| DF-09 | ERP | DWH | Финальный статус заказа | Заказ, сумма, оплата, документы | Ежедневно | Medium |
Логическая схема обменов
[Клиент]
|
v
[Личный кабинет] -- DF-01: заявка + external_request_id --> [CRM]
| |
| v
| [ERP] <------ DF-05 ------ [WMS]
| |
+<--------------- DF-03: статус / DF-04: документы ------+
|
+-- DF-06 --> [Email/SMS Gateway]
[ЛК / CRM / ERP] ---- DF-08 ----> [Monitoring]
[CRM / ERP] --------- DF-07/09 --> [DWH]Пример end-to-end потока
| Шаг | Система | Действие | Контрольная точка |
|---|---|---|---|
| 1 | ЛК | Клиент создает заявку | Создан external_request_id |
| 2 | ЛК | Заявка получает статус new | Статус виден клиенту |
| 3 | ЛК → CRM | Заявка передается в CRM | CRM возвращает crm_deal_id |
| 4 | CRM | Менеджер проверяет заявку | Фиксируется первая реакция |
| 5 | CRM → ERP | Подтвержденная сделка передается в ERP | ERP возвращает erp_order_id |
| 6 | ERP | Заказ получает учетный статус | Статус маппится в клиентский |
| 7 | ERP → ЛК | Статус заказа обновляется в ЛК | Клиент видит понятный статус |
| 8 | ERP → ЛК | Документы становятся доступны | Проверяются права доступа |
| 9 | ЛК → Gateway | Клиент получает уведомление | Отправка залогирована |
| 10 | Все системы | Данные попадают в мониторинг и аналитику | Есть correlation ID |
9. Контракт данных: ЛК → CRM
Контракт данных: ЛК → CRM
| Поле | Источник | Получатель | Обязательность | Правило |
|---|---|---|---|---|
| external_request_id | ЛК | CRM | Required | Уникальный ID заявки, используется для идемпотентности |
| company_external_id | ЛК / CRM | CRM | Required | Компания должна существовать в CRM |
| contact_external_id | ЛК / CRM | CRM | Required | Контакт должен быть привязан к компании |
| request_type | ЛК | CRM | Required | Значение из справочника типов заявок |
| priority | ЛК | CRM | Optional | Рассчитывается по правилам приоритизации |
| comment_raw | ЛК | CRM | Optional | Передается без редактирования |
| attachments | ЛК | CRM | Optional | Передаются ссылки на файлы с правами доступа |
| created_at | ЛК | CRM | Required | Дата и время создания заявки |
| source | ЛК | CRM | Required | Всегда client_portal |
| sync_status | ЛК | CRM | Required | pending, sent, failed, retrying |
Правила валидации
| Правило | Описание | Ошибка |
|---|---|---|
| Уникальность заявки | external_request_id не должен создавать вторую сделку | Duplicate request |
| Компания обязательна | Нельзя передать заявку без компании | Company missing |
| Контакт принадлежит компании | Контакт не может быть связан с другой компанией | Contact-company mismatch |
| Тип заявки из справочника | Нельзя передать произвольное значение | Invalid request type |
| Файл доступен только владельцу | Ссылка на вложение должна учитывать права доступа | Access violation |
10-12. Статусы, ошибки и надежность
Статусы заказа и правила синхронизации
| Статус ERP | Клиентский статус в ЛК | Показывать клиенту | Правило |
|---|---|---|---|
| created | Заявка создана | Да | Начальный статус после создания заказа |
| in_review | Проверяется менеджером | Да | Используется до подтверждения условий |
| confirmed | Заказ подтвержден | Да | Можно отправлять уведомление клиенту |
| payment_pending | Ожидает оплаты | Да | Отдельный финансовый статус |
| paid | Оплата получена | Да | Не должен заменять статус исполнения |
| in_production | В работе | Да | Используется для заказных позиций |
| ready_to_ship | Готов к отгрузке | Да | Может запускать уведомление |
| shipped | Отгружен | Да | Требуется дата отгрузки |
| closed | Завершен | Да | Документы должны быть доступны |
| cancelled | Отменен | Да | Требуется причина отмены |
| error | Требует проверки | Нет | Внутренний технический статус |
Правила обработки ошибок
| Ситуация | Что делает система | Что видит пользователь | Что видит поддержка |
|---|---|---|---|
| CRM API недоступен | Заявка сохраняется, ставится в retry-очередь | Заявка создана, обработка займет больше времени | Ошибка с correlation ID |
| CRM вернула duplicate | ЛК связывает заявку с существующей сделкой | Статус заявки не меняется | Запись о дубле и CRM ID |
| ERP не вернула статус | ЛК сохраняет последний успешный статус | Статус обновляется | Алерт, если задержка больше SLA |
| Документ недоступен | Ссылка скрыта, создается инцидент | Документ готовится | Ошибка доступа или генерации |
| Gateway не отправил уведомление | Повторная отправка по retry-политике | Ничего или сообщение в ЛК | Статус доставки уведомления |
| Ошибка прав доступа | Доступ блокируется | Ошибка доступа | Security-событие и алерт |
Idempotency, retry и correlation ID
| Механизм | Где применяется | Зачем нужен |
|---|---|---|
| Idempotency key | Создание заявки, передача в CRM | Чтобы повторная отправка не создавала дубль |
| Retry-очередь | CRM, ERP, Gateway | Чтобы временный сбой API не приводил к потере данных |
| Dead-letter queue | Все критичные обмены | Чтобы ошибки не терялись после исчерпания повторов |
| Correlation ID | Все системы | Чтобы восстановить цепочку событий по заявке |
| Sync status | ЛК, CRM | Чтобы видеть, отправлена ли сущность во внешнюю систему |
| Audit log | ЛК, ERP, CRM | Чтобы понять, кто и когда изменил данные |
13-17. Риски, контроль и сверка
Риски расхождения данных
| Риск | Где возникает | Последствие | Вероятность | Влияние | Митигирующее действие |
|---|---|---|---|---|---|
| Дубли заявок | ЛК → CRM | Несколько сделок по одному запросу | Medium | High | Idempotency key, проверка external ID |
| Потеря заявки при сбое CRM API | ЛК → CRM | Клиент думает, что заявка создана, менеджер ее не видит | Medium | High | Retry-очередь, dead-letter queue, алерты |
| Разные статусы в ERP и ЛК | ERP → ЛК | Клиент видит устаревшую или неверную информацию | High | Medium | Маппинг статусов, журнал обновлений, SLA синхронизации |
| Несовпадение справочников компаний | CRM ↔ ERP | Ошибки в документах и заказах | Medium | High | Master data owner, единый внешний ID |
| Ошибка доступа к документам | ERP → ЛК | Клиент видит чужой документ | Low | Critical | Проверка владельца, access control, security audit |
| Невозможность сверки | Все системы | Нельзя доказать, где потерялась сущность | Medium | High | Correlation ID, reconciliation report |
Контрольные точки интеграции
| ID | Контрольная точка | Успешный результат |
|---|---|---|
| CP-01 | Создание заявки в ЛК | Заявка создана, имеет уникальный external_request_id |
| CP-02 | Передача заявки в CRM | Сделка создана, crm_deal_id сохранен в ЛК |
| CP-03 | Ошибка CRM API | Заявка поставлена в очередь и не потеряна |
| CP-04 | Повторная отправка заявки | Дубль сделки не создается |
| CP-05 | Передача сделки в ERP | Заказ создан с корректной компанией и суммой |
| CP-06 | Обновление статуса из ERP | ЛК показывает актуальный клиентский статус |
| CP-07 | Передача документов | Документы доступны только владельцу |
| CP-08 | Уведомление клиента | Email/SMS отправлены и залогированы |
| CP-09 | Сверка данных | Нет дублей, потерь и конфликтующих статусов |
| CP-10 | Мониторинг | Ошибка интеграции создает алерт |
Мониторинг и SLA интеграций
| Метрика | Целевое значение | Источник | Алерт |
|---|---|---|---|
| Успешность передачи ЛК → CRM | ≥ 99% | Логи интеграции | Ниже 98% за 30 минут |
| Среднее время передачи заявки в CRM | До 30 секунд | ЛК / CRM | Больше 2 минут |
| Количество заявок в retry | 0–5 в норме | Retry queue | Больше 10 или старше 15 минут |
| Количество сообщений в dead-letter queue | 0 | DLQ | Любое сообщение |
| Задержка обновления статуса ERP → ЛК | До 15 минут | ЛК / ERP | Больше 30 минут |
| Ошибки доступа к документам | 0 | Security log | Любое событие |
| Дубли по external ID | 0 | CRM / ЛК | Любой дубль |
| Доставка уведомлений | ≥ 98% | Gateway | Ниже 95% за 1 час |
| Время восстановления после сбоя | До 2 часов | IT Operations | Нарушение MTTR |
Reconciliation report
| Проверка | Ожидаемое значение | Допустимое расхождение | Действие при расхождении |
|---|---|---|---|
| Количество заявок в ЛК и сделок в CRM | 1:1 | 0 | Проверить idempotency и retry |
| Количество CRM-сделок и ERP-заказов | По подтвержденным сделкам | 0–1 объясненное расхождение | Проверить статус подтверждения |
| Наличие external_request_id | 100% | 0 | Заблокировать пилотный rollout |
| Наличие crm_deal_id в ЛК | 100% отправленных заявок | 0 | Проверить CRM response handling |
| Наличие erp_order_id для подтвержденных заказов | 100% | 0 | Проверить CRM → ERP обмен |
| Корректность клиентских статусов | 100% выборки | 0 | Проверить маппинг статусов |
| Доступность документов | 100% опубликованных документов | 0 | Проверить ERP → ЛК и права доступа |
| Отсутствие чужих документов | 100% | 0 | Security incident |
Вывод по экономике интеграционных рисков: интеграционный контур должен проектироваться не только как набор API, а как механизм защиты данных, денег, SLA и доверия клиента.
18-19. План пилота
Пилот запускается поэтапно и только после контрольных проверок
Тестовые клиенты и заявки
1. Технический dry-run
Проверить связность систем
- Критерий успеха
- Все обмены проходят без ручного вмешательства
Реальные данные без влияния на клиента
2. Shadow mode
Сравнить результаты интеграции с текущим ручным процессом
- Критерий успеха
- Расхождения объяснены и не критичны
3–5 клиентов или один сегмент
3. Ограниченный пилот
Проверить end-to-end процесс на реальных пользователях
- Критерий успеха
- Нет потерь заявок, дублей и критичных дефектов
20–30 клиентов
4. Расширенный пилот
Проверить нагрузку, поддержку, мониторинг
- Критерий успеха
- SLA соблюдается, поддержка понимает процесс
Все клиенты
5. Production rollout
Запустить целевой процесс
- Критерий успеха
- Метрики стабильны, инциденты контролируемы
Go / No-Go критерии пилота
| Критерий | Go | No-Go |
|---|---|---|
| Передача заявок | 100% заявок доходят до CRM | Есть потерянные заявки |
| Дубли | Нет дублей по external_request_id | Есть повторяющиеся сделки |
| Статусы | Статусы корректно маппятся | Клиент видит неверный статус |
| Документы | Документы доступны только владельцу | Есть ошибка доступа или документ не открывается |
| Ошибки API | Ошибки логируются и переотправляются | Ошибки теряются |
| Retry / DLQ | Очереди работают, DLQ пустая | Сообщения зависают без обработки |
| Мониторинг | Алерты настроены и проверены | Ошибки можно увидеть только вручную |
| Поддержка | Есть инструкция и владельцы | Непонятно, кто решает инциденты |
| Откат | Есть план rollback | Откат не описан |
| Сверка данных | Расхождений нет или они объяснены | Есть необъясненные расхождения |
20-21. Roadmap согласования интеграционного решения
От инвентаризации систем к controlled rollout
Карта систем
1. Инвентаризация систем
Понятен состав контура
- Участники
- IT, Product, владельцы систем
- Артефакт
- Карта систем
Master data matrix
2. Определение master data
Назначены владельцы сущностей
- Участники
- CRM, ERP, Finance, Product
- Артефакт
- Master data matrix
Data flow map
3. Описание потоков данных
Зафиксированы события и обмены
- Участники
- IT Architect, аналитик, подрядчики
- Артефакт
- Data flow map
Status mapping table
4. Маппинг статусов
Внутренние статусы переведены в клиентские
- Участники
- Product, Operations, Finance
- Артефакт
- Status mapping table
Retry / DLQ rules
5. Проектирование error handling
Ошибки не приводят к потере данных
- Участники
- IT, разработка, поддержка
- Артефакт
- Retry / DLQ rules
Monitoring checklist
6. Требования к мониторингу
Инциденты обнаруживаются автоматически
- Участники
- IT Operations, Support
- Артефакт
- Monitoring checklist
Security checklist
7. Security review
Проверены доступы, токены, документы
- Участники
- Security, IT, Product
- Артефакт
- Security checklist
Pilot plan
8. План пилота
Запуск разбит на управляемые этапы
- Участники
- Business, IT, Support
- Артефакт
- Pilot plan
Launch decision protocol
9. Go / No-Go решение
Решение о запуске зафиксировано
- Участники
- Product, IT, Business
- Артефакт
- Launch decision protocol
Rollout report
10. Production rollout
Контур запущен и контролируется
- Участники
- Все владельцы
- Артефакт
- Rollout report
Итоговая рекомендация по архитектуре запуска
- Использовать единый external_request_id для связи ЛК, CRM и ERP.
- Реализовать idempotency для создания заявок и сделок.
- Настроить retry-очереди и dead-letter queue для критичных обменов.
- Разделить внутренние ERP-статусы и клиентские статусы.
- Назначить master-систему для каждой бизнес-сущности.
- Настроить мониторинг, correlation ID и алерты по ошибкам.
- Провести shadow mode до реального пилота.
- Запускать production только после сверки данных и Go / No-Go решения.
Финальная подпись для сайта: на выходе клиент получает не «список API», а карту управляемой интеграции: какие системы участвуют, какие данные ходят между ними, кто владеет сущностями, где возможны расхождения, как обрабатываются ошибки и по каким критериям запускать пилот.