Как подготовить требования к CRM для крупного бизнеса

В малом и среднем бизнесе CRM действительно может быть коробочным инструментом для отдела продаж. CRM в enterprise-среде работает в условиях высокой сложности бизнес-процессов:

• длинного цикла B2B-сделок, который может занимать месяцы;

• участия нескольких подразделений в одной сделке;

• зависимости продаж от производства, логистики и финансов;

• многоуровневых согласований;

• высокой нагрузки на систему и пользователей;

• обязательных интеграций с 1С, ERP, WMS, BI и другими системами.

В такой среде CRM становится не просто системой учёта, а центром управления процессами взаимодействия с клиентом.

В крупном бизнесе невозможно внедрить CRM «как есть». Любое решение требует адаптации под бизнес-процессы и интеграции в существующую ИТ-архитектуру. Более того, попытка внедрить CRM без учета этой архитектуры почти всегда приводит к проблемам: дублированию данных, конфликтам между системами и росту нагрузки на сотрудников.

Функциональные требования - это документ, который описывает, как работает бизнес и какую роль в нём должна играть CRM-система. Именно здесь формируется логика будущего решения. Важно различать:

• функциональные требования отвечают на вопрос «что нужно бизнесу и зачем»

• техническое задание отвечает на вопрос «как это будет реализовано»

Распространённая ошибка пытаться сразу описывать систему на уровне кнопок, полей и интерфейсов. В этом случае теряется главное - бизнес-логика.
 
Чтобы наглядно показать разницу между ФТ и ТЗ, мы подготовили таблицу, которая станет вашим шпаргалкой при подготовке документации.

Параметр	Функциональные требования (ФТ)	Техническое задание (ТЗ)
Назначение	Описывают бизнес-логику CRM: какие задачи решает система и какие процессы должны быть автоматизированы	Описывает техническую реализацию: как именно система будет разработана
Уровень детализации	Средний уровень: процессы, роли, бизнес-сценарии и ожидаемые результаты	Детальный уровень: поля, алгоритмы, API, правила обработки данных
Фокус	«Что и зачем нужно бизнесу»	«Как это реализуется технически»
Кто готовит	Заказчик и бизнес-стейкхолдеры (руководители отделов, ключевые пользователи)	Интегратор: аналитики, архитекторы, разработчики
Для кого	Для интегратора — чтобы понять бизнес и спроектировать решение	Для команды разработки и тестирования
Гибкость	Может корректироваться до старта разработки	Фиксируется и влияет на сроки/стоимость при изменениях
Пример формулировки	«Согласование коммерческого предложения зависит от суммы сделки и роли участников процесса»	«При сумме > 2 млн руб. запускается цепочка согласования: РОП → финдиректор → директор»
Этап использования	До выбора решения и старта внедрения	После утверждения ФТ, на этапе разработки

Правильный подход: заказчик готовит функциональные требования → интегратор на их основе разрабатывает ТЗ и предлагает оптимальные технические. Качественные функциональные требования позволяют:

• синхронизировать ожидания бизнеса и ИТ;

• корректно оценить сроки и бюджет;

• избежать доработок в процессе внедрения;

• снизить риски конфликта с подрядчиком;

• заложить основу для масштабирования системы.

На практике именно отсутствие или слабая проработка требований становится причиной того, что CRM-проекты в крупном бизнесе затягиваются или не дают ожидаемого эффекта.

В enterprise-сегменте требования описывают не интерфейс системы, а логику работы компании.

• Цели внедрения. На уровне целей описываются бизнес-результаты: повышение управляемости продаж, сокращение времени обработки заявок, рост прозрачности процессов и улучшение прогнозируемости выручки.
• Бизнес-объекты системы. В CRM фиксируются ключевые сущности, с которыми работает компания: лиды, сделки, заказы, контрагенты, договоры и рекламации. Важно учитывать полный цикл взаимодействия с клиентом, а не только этап продаж.
• Роли пользователей. CRM в крупной компании всегда мультиуровневая. В процессах участвуют менеджеры по продажам, руководители отделов, финансовый блок, логистика и производственные подразделения. В требованиях фиксируется не только список ролей, но и их зона ответственности в процессе.
• Бизнес-процессы. Описываются сквозные сценарии работы: обработка заявки, подготовка коммерческого предложения, согласование условий, передача заказа в производство и контроль исполнения. Именно этот блок определяет логику взаимодействия подразделений внутри системы.
• Интеграции. Enterprise-CRM всегда работает в связке с другими системами. Чаще всего это 1С, ERP-платформы, WMS-системы и BI-аналитика. В требованиях фиксируются направления обмена данными и их бизнес-смысл.
• Отчетность и аналитика. Отдельно описываются управленческие показатели: воронка продаж, конверсия по этапам, маржинальность сделок, загрузка ресурсов и прогнозирование выручки.
• Нефункциональные требования. К ним относятся параметры устойчивости системы: количество пользователей, нагрузка, скорость работы, требования к безопасности и отказоустойчивости. Эти параметры напрямую влияют на архитектуру решения.

Сбор требований к CRM - это не разовая встреча, а последовательный процесс, который в крупной компании обычно занимает от двух до шести недель. Его задача зафиксировать реальную модель работы бизнеса и перевести её в понятную структуру для проектирования системы.

1. Определить цели внедрения

Работа всегда начинается с ответа на вопрос: зачем компании CRM сейчас. Причины могут быть разными: потеря лидов между подразделениями, отсутствие прозрачности по сделкам, высокая доля ручных операций или необходимость стандартизировать процессы при масштабировании.

Зафиксированные цели становятся базовым фильтром: всё, что не помогает их достигать, либо откладывается, либо исключается из первого этапа внедрения.

2. Формируется рабочая группа

Далее важно собрать не только управленческий уровень, но и тех, кто реально работает в системе каждый день - руководителей подразделений и ключевых пользователей.

Без этого требования почти всегда получаются «идеальными на бумаге», но неприменимыми в реальной работе. На этом же этапе определяется владелец проекта - человек, который принимает финальные решения и снимает конфликтные вопросы между подразделениями.

3. Описывается текущая модель работы

Перед проектированием будущей CRM важно зафиксировать, как процессы устроены сейчас. Рассматривается полный цикл работы с клиентом: от поступления лида до закрытия сделки и постобслуживания. Здесь почти всегда выявляются расхождения между регламентами и реальной практикой, а также ручные операции и дублирование данных между системами.

4. Фиксируются ключевые сценарии использования

Далее описываются конкретные ситуации взаимодействия пользователя с системой. Например: создание карточки клиента при входящем звонке, автоматическое назначение задач при отсутствии ответа или уведомление руководителя при «зависании» сделки. Чем больше таких сценариев зафиксировано, тем точнее будет будущая логика системы и техническое задание.

5. Формируются функциональные требования

На основе сценариев описывается, что именно должна уметь CRM. Обычно требования группируются по блокам: работа с клиентами, воронка продаж, задачи и уведомления, документооборот, отчётность и интеграции. Ключевой принцип - каждое требование должно быть конкретным и проверяемым.

6. Учитываются нефункциональные требования

Отдельно фиксируются параметры, которые влияют на устойчивость системы: производительность, безопасность, нагрузка, требования к инфраструктуре и защите данных. На этом этапе часто подключается ИТ-отдел, чтобы учесть корпоративные и отраслевые стандарты.

7. Определяются приоритеты

Финальный шаг - разделение требований по значимости. Обычно выделяют обязательный минимум для запуска, требования второго этапа и функциональность, которую можно отложить. Это позволяет сформировать реалистичный объём первой версии CRM и избежать перегрузки внедрения.

Большинство проблем CRM-проектов возникает ещё до начала разработки.

• Отсутствие целей. Если нет чёткой цели, CRM невозможно оценить с точки зрения эффективности.

• Слишком общие формулировки. Например: «нужно автоматизировать продажи» — это не описание системы.

• Избыточная детализация. Когда описываются кнопки, поля и интерфейс вместо бизнес-логики.

• Игнорирование интеграций. Особенно 1С, ERP, складских и финансовых систем.

• Отсутствие приоритетов. Все требования считаются одинаково важными, что блокирует поэтапное внедрение.

На практике требования к CRM почти никогда не получаются качественными, если их делать только внутри компании. Бизнес хорошо понимает свои процессы, но часто не видит архитектурных ограничений и рисков внедрения.

Обратная ситуация тоже не работает: если требования полностью формирует интегратор, есть риск получить систему, удобную с точки зрения разработки, но не отражающую реальную логику бизнеса.

Поэтому наиболее рабочий сценарий — совместная проработка. Бизнес задаёт контекст и цели, интегратор — структурирует, уточняет и сразу закладывает реалистичную модель реализации.

При этом важно держать фокус на нескольких принципах:

• требования начинаются с бизнес-целей, а не списка функций;

• описываются реальные процессы и взаимодействие подразделений;

• технические детали не уходят в требования раньше времени;

• документ проходит согласование со всеми участниками процесса, а не только с ИТ.

Такой подход позволяет избежать ситуации, когда CRM формально внедрена, но не используется или требует постоянных доработок уже после запуска.

Перед передачей требований интегратору важно убедиться, что документ действительно готов к работе. В нем должны быть:

• четко сформулированные цели внедрения;

• описание ключевых бизнес-процессов;

• список ролей и их участия в процессах;

• перечень интеграций и логика обмена данными;

• требования к аналитике;

• нефункциональные параметры (нагрузка, безопасность);

• приоритизация и выделенный MVP.

CRM для крупного бизнеса - это не выбор программного продукта, а проектирование системы управления процессами и данными. Ошибки на этапе формирования требований приводят к росту бюджета, срывам сроков и низкому уровню использования системы внутри компании. Правильный подход - начинать с анализа бизнеса, формировать требования и только после этого переходить к выбору платформы и внедрению.