Что такое архитектура CRM-системы простыми словами
Архитектура CRM — это устройство системы, которое определяет, как связаны между собой пользователи, модули, клиентские данные, бизнес-процессы, интеграции, аналитика, права доступа и инфраструктура. Она описывает логику работы: где хранится карточка клиента, по каким правилам создается сделка, кто видит сумму контракта и откуда отчет берет цифры. Продуманная архитектура CRM-системы держит компанию в одном контуре: сделки идут по понятным этапам, данные лежат в связанных карточках, роли ограничивают доступ, интеграции передают информацию между системами, отчеты показывают фактическую работу.
Ниже разобраны слои архитектуры, модули, модель данных, интеграции и API, роли и безопасность, масштабирование, варианты размещения, ошибки проектирования и сценарий BPMSoft.
Зачем бизнесу разбираться в архитектуре CRM
От архитектуры зависит, придется ли переделывать поля, роли и интеграции через полгода после запуска. Компания редко сталкивается с ней напрямую: она видит долгие доработки, отчеты, которым не верит руководитель, и менеджеров, которые ведут часть сделок в мессенджерах.
Слабая архитектура проявляется одинаково у компаний любого размера: дубли появляются там, где не задано правило уникальности карточки; ручные обходные процессы — там, где маршрут согласования не описан в системе; отчеты собираются в выгрузках, потому что модули считают показатели по разным справочникам.
Сильная архитектура работает иначе: новый филиал подключается настройкой ролей, новый источник заявок — по существующей карте полей, новый отчет — из описанной модели данных. Разница видна на второй-третий год эксплуатации.
Практический вывод: перед стартом проверяют три вещи — есть ли у архитектуры владелец, описана ли модель данных до настройки модулей и зафиксировано ли единое правило обмена с внешними системами. Назначение и устройство систем этого класса разобраны в материале про что такое CRM-система.
Основные слои архитектуры CRM
Архитектуру CRM удобно раскладывать на восемь слоев. Каждый опирается на соседние: интерфейс показывает описанное в модулях, модули работают по правилам процессов, процессы читают и пишут данные, аналитика считает по ним же, безопасность ограничивает доступ, инфраструктура держит нагрузку.
Пользовательский слой
Рабочие места, формы, карточки, списки, мобильный доступ. Слой определяет, сколько кликов делает менеджер, чтобы завести сделку, и видит ли руководитель нагрузку команды без выгрузки.
Модульный слой
Функциональные блоки: клиенты, лиды, сделки, задачи, коммуникации, документы, сервис, маркетинг, аналитика. Проблемы начинаются при независимой настройке: сервис заводит свой справочник клиентов, маркетинг — свои сегменты, и одна компания живет в системе в трех карточках.
Процессный слой
Маршруты, статусы, задачи, сроки, согласования, SLA — соглашение об уровне сервиса со сроками реакции и решения. Слой превращает регламент в исполняемую последовательность: заявка получает ответственного, задача уходит исполнителю, переход на следующий этап открывается при заполненных полях. Маршруты закрывает BPM-система для управления процессами.
Слой данных
Модель данных, поля, справочники, правила качества, дедупликация. Слой задает, какие поля обязательны, как связаны карточки и как чистятся дубли. Он же определяет, соберется ли отчет по источникам лидов.
Интеграционный слой
API — программный интерфейс обмена данными между системами, вебхуки, коннекторы, файловые выгрузки, журнал ошибок. Слой отвечает за то, чтобы заявка с сайта, звонок из телефонии и счет из учетной системы попадали в CRM без ручного переноса.
Аналитический слой
Отчеты, дашборды, витрины, выгрузки в BI — системы бизнес-аналитики, и DWH — корпоративное хранилище. Требование к слою — единый источник цифры: показатель считается по одной формуле во всех отчетах.
Слой безопасности
Роли, права на объекты и поля, ограничения по подразделениям и филиалам, журнал действий, правила работы с персональными данными. Слой определяет, кто видит сумму сделки и остается ли след от изменения статуса задним числом.
Инфраструктурный слой
Размещение, СУБД, резервное копирование, мониторинг, производительность, отказоустойчивость. Слой закрывает вопросы, которые бизнес задает редко, но остро: выдержит ли система массовую загрузку базы и как быстро восстанавливаются данные.
Таблица: слои архитектуры CRM-системы
| Слой архитектуры | Что включает | Какие данные обрабатывает | Риск слабой настройки | Что проверить |
|---|---|---|---|---|
| Пользовательский | Интерфейсы, формы, рабочие места, мобильный | Действия пользователей, задачи, карточки | Сотрудники ведут работу вне CRM | Удобство сценариев для каждой роли |
| Модульный | Клиенты, лиды, сделки, сервис, маркетинг | Карточки клиентов, сделки, обращения, документы | Модули работают разрозненно | Связи между сущностями и процессами |
| Процессный | Маршруты, статусы, задачи, SLA, согласования | Этапы, сроки, ответственные, статусы | Процессы уходят в ручной режим | Наличие маршрутов и владельцев процессов |
| Данных | Модель данных, поля, справочники, правила качества | Клиенты, контакты, сделки, источники, активности | Дубли, пустые поля, неполные отчеты | Карта данных и правила заполнения |
| Интеграционный | API, вебхуки, коннекторы, файловый обмен | Заявки, заказы, счета, звонки, письма, статусы | Данные расходятся между системами | Карта интеграций и мониторинг ошибок |
| Аналитический | Отчеты, дашборды, BI, сквозная аналитика | KPI, воронки, источники, SLA, активность | Руководитель не доверяет отчетам | Источники, формулы и права на отчеты |
| Безопасности | Роли, права, аудит, ограничения доступа | Персональные и коммерческие данные | Лишний доступ и слабый контроль действий | Матрица ролей и журнал действий |
| Инфраструктурный | Облако, локальное размещение, резервирование | Системные данные, логи, нагрузка | Сбои и ограничения роста | Требования к нагрузке и доступности |
Вывод по таблице: ошибка нижнего слоя всплывает на верхнем. Пустой источник лида превращается в бесполезный отчет по каналам, отсутствие матрицы ролей — в ситуацию, когда менеджер филиала выгружает базу соседнего региона. Проверяют архитектуру снизу вверх.
Какие модули входят в CRM-систему
Состав модулей различается по платформам, но набор задач повторяется.
Клиенты и контакты
Карточка компании и карточка человека, реквизиты, сегмент, отрасль, связи между юрлицами группы. Здесь задается правило уникальности: по ИНН, по домену почты, по комбинации названия и телефона.
Лиды и сделки
Лид фиксирует новое обращение и хранит источник, канал и срок первой реакции. Сделка ведет продажу: этап, сумма, продукты, ответственный, вероятность, причина отказа. Без такого разделения конверсия теряет смысл.
Воронки и этапы продаж
Набор этапов, условия перехода и обязательные поля на каждом шаге. Для B2B часто нужны несколько воронок: новые продажи, тендеры, повторные закупки, продления.
Задачи и активности
Звонки, встречи, письма, напоминания, поручения по сделке. Модуль связывает действие с клиентом и сделкой, поэтому история сохраняется при смене ответственного.
Коммуникации: звонки, письма, чаты
Единая лента общения по клиенту: запись разговора, цепочка писем, переписка в мессенджере. Здесь же хранятся согласия на обработку данных.
Документы и согласования
Шаблоны коммерческих предложений и договоров, версии, маршруты согласования, статусы подписания. Документ связан со сделкой и с ответственными на каждом шаге.
Клиентский сервис и обращения
Регистрация обращения, категория, приоритет, срок реакции и решения, эскалация при просрочке. Сервис опирается на ту же карточку клиента, что и продажи, поэтому специалист поддержки видит договоренности по сделке.
Маркетинг и сегменты
Сегментация базы, кампании, рассылки, обработка откликов, передача качественных лидов в продажи. Сегмент собирается по атрибутам клиента из CRM.
Аналитика и отчеты
Воронка, прогноз, активность команды, источники лидов, SLA, качество данных. Модуль читает те же объекты, с которыми работают пользователи, поэтому цифра в отчете совпадает с цифрой в карточке.
Практический вывод: модули настраивают после описания связей между ними. Если сервис и продажи используют разные карточки клиента, объединить историю позже получится только через миграцию данных.
Как устроена модель данных CRM
Модель данных CRM определяет, какие объекты хранит система и как они связаны: клиент, контакт, компания, лид, сделка, продукт, заказ, документ, активность, задача, обращение. От модели зависит, соберется ли отчет и появятся ли дубли при загрузке базы.
Связи строятся вокруг клиента: к компании привязаны контакты, к контакту — коммуникации, к клиенту — сделки, к сделке — продукты, документы и задачи, к обращению — SLA и ответственный. Лид стоит отдельно до квалификации: после нее источник и UTM-метки — параметры рекламной ссылки, по которым определяется канал, — переносятся в карточку.
Справочники задают словарь системы: отрасли, продукты, причины отказа, категории обращений, источники лидов. Справочник закрывает поле от свободного ввода, поэтому отчет по причинам отказа собирается автоматически.
Таблица: какие сущности входят в модель данных CRM
| Сущность | Для чего нужна | С чем связана | Что важно настроить |
|---|---|---|---|
| Клиент, компания | Хранит информацию о покупателе | Контакты, сделки, документы, обращения | Правило уникальности, реквизиты, сегмент |
| Контакт | Фиксирует человека со стороны клиента | Клиент, сделки, коммуникации | Должность, телефон, email, согласия |
| Лид | Отражает новое обращение или интерес | Источник, канал, сделка, ответственный | Источник, UTM, статус, срок обработки |
| Сделка | Управляет продажей и прогнозом | Клиент, контакт, продукт, задача, счет | Этап, сумма, вероятность, причина отказа |
| Задача | Управляет действиями команды | Сделка, клиент, ответственный, срок | Тип задачи, дедлайн, статус |
| Коммуникация | Хранит историю взаимодействия | Клиент, контакт, сделка, канал | Звонок, письмо, чат, результат |
| Документ | Фиксирует коммерческие материалы | Клиент, сделка, согласование | Шаблон, статус, версия, маршрут |
| Обращение | Ведет сервисные процессы | Клиент, SLA, ответственный, статус | Категория, приоритет, срок реакции |
Вывод по таблице: сущности образуют один граф вокруг клиента, поэтому разрыв связи ломает сразу несколько сценариев. Коммуникация без привязки к сделке лишает нового менеджера истории переговоров.
Интеграционная архитектура CRM
Интеграционная архитектура описывает, какими способами CRM обменивается данными с внешними системами и кто отвечает за каждый канал. Правило простое: один тип данных — один основной источник. Способы подключения разобраны в материале про интеграцию CRM.
API и вебхуки
API дает внешней системе возможность запрашивать и записывать данные по регламенту: создать лид, обновить статус сделки, получить список обращений. Вебхук работает в обратную сторону — CRM сама отправляет уведомление о событии. Для архитектуры важны версионирование методов, лимиты запросов и журнал ошибок.
Коннекторы и iPaaS
Коннектор — готовый модуль обмена с конкретным сервисом. iPaaS — платформа интеграции как сервис, где обмен собирается сценариями без разработки. Оба варианта требуют владельца сценария.
Интеграция с сайтом и формами
Заявка передает имя, контакты, текст запроса, страницу обращения, источник и UTM-метки, согласие на обработку данных. В CRM она сразу получает ответственного и срок первой реакции.
Телефония, почта и мессенджеры
Звонок связывается с карточкой по номеру и создает задачу при пропуске. Почта подтягивается в ленту клиента, мессенджеры дают историю переписки и время ответа. Главный вопрос — правило привязки: по какому атрибуту сообщение находит клиента.
1C, ERP, склад и биллинг
Обмен ведется по контрагентам, заказам, счетам, оплатам, отгрузкам и документам. Направление фиксируется по каждому объекту: клиент создается в CRM и передается в учет, счет создается в учете и возвращается в сделку.
BI, DWH и сквозная аналитика
CRM отдает в хранилище факты по лидам, сделкам и обращениям, маркетинговые системы — расходы по каналам. Сквозная аналитика соединяет их и показывает путь от рекламного клика до оплаты.
Практический вывод: перед подключением любой системы записывают четыре параметра — какие объекты обмениваются, в какую сторону, с какой частотой и кто разбирает ошибки. Иначе через год в системе появляется несколько источников одних и тех же данных.
Роли, права доступа и безопасность в CRM
Ролевая модель описывает, какие объекты и поля видит сотрудник и что он может с ними сделать. В B2B она редко сводится к делению на менеджера и руководителя: доступ ограничивают по подразделению, филиалу и типу данных.
Отдельный уровень — права на поля и действия. Сумма контракта, персональные данные контакта, себестоимость и скидка часто закрываются от рядовых пользователей. Выгрузка базы, удаление карточек и изменение справочников выносятся в отдельные полномочия.
Безопасность проектируют до запуска: после старта в системе накоплены реальные сделки и персональные данные, и переразделение прав лишает часть пользователей доступа к своим объектам. Требования по обработке персональных данных согласуют с юристами и службой безопасности.
Практический вывод: матрица ролей существует в виде документа до настройки: роль, подразделение, видимые объекты, закрытые поля, разрешенные действия, право на выгрузку.
Масштабирование CRM-архитектуры
При росте компании нагрузка меняется сразу по нескольким направлениям: прибавляются пользователи и филиалы, растет число каналов, увеличивается объем базы, добавляются интеграции и отчеты.
Число пользователей и филиалов проверяет ролевую модель и скорость списков. Рост каналов проверяет правила привязки обращений. Объем данных проверяет индексы, архивные политики и время построения отчетов.
Технический долг накапливается там, где решение принимали под одну задачу: пять похожих полей вместо справочника, три отчета с разными формулами одного показателя, две интеграции с одной системой под разные отделы. Возможность менять поля, формы и маршруты без разработки снижает риск — принципы работы таких инструментов разобраны в статье про low-code-платформы.
Практический вывод: план масштабирования держится на четырех опорах — единая модель данных, стандарт интеграций, управление справочниками и регламент изменений.
Облачная, локальная и гибридная CRM-архитектура
Вариант размещения влияет на скорость запуска, контроль над инфраструктурой и требования к ИТ-команде. Облако снимает обслуживание серверов и сокращает подготовку к старту, оставляя вопросы о месте хранения данных. Локальное размещение дает контроль над инфраструктурой и требует своей команды эксплуатации.
Гибридная схема сочетает подходы: часть контура работает в облаке, критичные данные и интеграции остаются внутри периметра.
Практический вывод: размещение выбирают по трем вопросам — какие требования к хранению данных предъявляет служба безопасности, какая команда будет обслуживать систему и какие интеграции нужны на старте. Методика сравнения платформ разобрана в материале про выбор CRM-системы.
Частые ошибки в архитектуре CRM
Ошибки проектирования повторяются от проекта к проекту и обнаруживаются после запуска.
- У архитектуры нет владельца: решения принимают разные команды, общая логика не складывается.
- Модули настраивают до описания модели данных: связи достраивают задним числом.
- Поля создают по запросу: через год в карточке двадцать атрибутов, половина из которых пустая.
- Интеграции делают точечно: каждая система подключается по своим правилам, общего журнала ошибок нет.
- Дедупликация и контроль качества данных не настроены: база растет за счет дублей.
- Права доступа проектируют после запуска: переразделение прав ломает доступ пользователей.
- Отчеты строят на неполных данных: обязательные поля не привязаны к этапам сделки.
- Масштабирование не заложено: рост команд и каналов упирается в ручные обходные процессы.
Практический вывод: первые две ошибки порождают остальные. Владелец архитектуры и описанная модель данных закрывают большую часть рисков еще до настройки системы.
Как BPMSoft поддерживает CRM-архитектуру для B2B-процессов
BPMSoft — российская low-code платформа, на которой собраны прикладные решения класса CRM и BPM. Для архитектуры это означает, что модули работы с клиентами, маршруты процессов, роли, интеграции и отчеты настраиваются в одном контуре и опираются на общую модель данных.
Клиенты, контакты, лиды, сделки, задачи и коммуникации ведутся в CRM-модулях: «Управление продажами» закрывает цикл сделки, «Управление сервисом» — обращения, «Управление маркетингом» — сегменты и кампании, портальные решения и омниканальные коммуникации добавляют каналы взаимодействия. Процессный слой описывает маршруты, условия перехода, сроки и согласования.
Настройка форм, полей, правил и сценариев ведется в low-code-режиме, без глубоких навыков программирования. Роли и права доступа разделяют данные между командами, подразделениями и филиалами.
Интеграционный слой подключает сайт, телефонию, почту, учетные и корпоративные системы: коннекторы и расширения собраны в магазине приложений market.bpmsoft.ru, платформа поддерживает российский стек операционных систем, СУБД и облаков. Отчеты и дашборды показывают воронку, нагрузку, сроки и качество данных на тех же объектах, с которыми работают пользователи.
Чек-лист архитектуры CRM перед внедрением
Список закрывается ответами «да» или «нет». Отрицательный ответ — задача команды до старта настройки.
- Назначен ли владелец архитектуры CRM со стороны бизнеса?
- Описана ли модель данных: объекты, связи, обязательные поля, справочники?
- Задано ли правило уникальности карточки и настроена ли дедупликация?
- Описаны ли воронки продаж и маршруты обращений со статусами и сроками?
- Готова ли матрица ролей с правами на объекты, поля и выгрузку?
- Составлена ли карта интеграций: система, объекты, направление, владелец?
- Определен ли основной источник для каждого типа данных?
- Согласован ли перечень обязательных отчетов и формулы их показателей?
- Зафиксированы ли требования безопасности к хранению и доступу?
- Описан ли регламент изменений: кто заводит поля и справочники?
- Проверены ли требования к нагрузке и резервному копированию?
- Заложен ли контроль сроков по сервисным обращениям в соответствии с SLA?