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

Компании, которые обращаются к нам за внедрением CRM, нередко приходят с одной из двух проблем: либо требования к системе не сформулированы вообще («нам нужна CRM, как у конкурентов»), либо оформлены в виде технического задания на 100 страниц, где прописаны цвета кнопок, но не указаны цели внедрения. Оба варианта одинаково плохо заканчиваются: проект затягивается, бюджет выходит за рамки, а после запуска CRM оказывается, что «всё не так».

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

Что такое функциональные требования и чем они отличаются от технического задания

Функциональные требования (ФТ) — это систематизированное описание того, что должна делать CRM-система и зачем. Это не технический документ для разработчиков, а управленческий документ для принятия решений о внедрении.

Техническое задание (ТЗ) — это другой документ. Его готовит интегратор на основе ваших функциональных требований. ТЗ описывает, как именно будет реализована та или иная функция: какие методы использовать, как устроить базу данных, как написать интеграцию. ТЗ создаётся для разработчиков и тестировщиков — вам его читать не нужно.

Распространённая ошибка — пытаться написать ТЗ самостоятельно вместо ФТ. Это не только избыточная работа, но и прямой путь к конфликту с интегратором: вы прописываете конкретные технические решения, не зная, есть ли более простые и дешёвые альтернативы. Сосредоточьтесь на целях и процессах — выбор инструментов реализации оставьте профессионалам.

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

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

• Длинный цикл сделки — от первого обращения клиента до закрытия могут проходить месяцы, и на каждом этапе задействованы разные подразделения
• Индивидуальное ценообразование — расчёт цены по формулам с множеством переменных: объём, логистика, курс валюты, состав номенклатуры
• Зависимость продаж от производства — менеджер не может называть сроки, не зная реальной загрузки цехов
• Сложные маршруты согласований — коммерческое предложение, договор, скидка, отгрузка — каждый процесс требует участия нескольких уровней руководства
• Интеграции с несколькими системами — ERP, производственная система, складской учёт, логистика, BI
• Большое количество пользователей с разными ролями и уровнями доступа

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

Что должно быть в функциональных требованиях к CRM

Вот структура документа, которую мы рекомендуем использовать как шаблон:

1. Цели внедрения CRM. Конкретные и измеримые — не «улучшить продажи», а «сократить цикл сделки с 45 до 30 дней» или «уменьшить время подготовки КП с 3 дней до 4 часов».
2. Задачи проекта. Декомпозиция целей на конкретные задачи: автоматизация приёма заявок, централизованная клиентская база, электронное согласование договоров, интеграция с 1С.
3. Объекты системы. Перечень сущностей, которые будут в CRM: лид, сделка, контакт, компания, коммерческое предложение, договор, заявка на производство, рекламация — зависит от специфики бизнеса.
4. Роли пользователей и права доступа. Кто работает в системе, что видит и что может делать: менеджер по продажам, руководитель отдела, директор по производству, снабженец, логист, финансовый директор.
5. Описание автоматизируемых процессов. На среднем уровне детализации — не «нужен процесс согласования», а кто инициирует, какие данные вводит, по каким маршрутам идёт согласование, что происходит при отклонении.
6. Требования к аналитике и отчётности. Какие отчёты нужны, для кого, с какой периодичностью, какие метрики ключевые.
7. Интеграции с внешними системами. Какие системы интегрируются, в каком направлении передаются данные, какой объём данных и с какой частотой.
8. Импорт данных. Нужно ли переносить данные из существующих систем, какой объём, в каком формате.
9. Нефункциональные требования. Количество одновременных пользователей, допустимое время простоя, требования к безопасности и резервному копированию.

Как правильно описывать процессы: техника User Story

Самая частая проблема в функциональных требованиях — неправильный уровень детализации процессов. Слишком общее описание («нужен процесс согласования КП») создаёт разночтения. Слишком детальное («поле «Дата КП» должно быть расположено в левом верхнем углу карточки в шрифте Arial 12pt») тратит ваше время и не оставляет интегратору возможности предложить лучшее решение.

Оптимальный инструмент для описания процессов — пользовательская история (User Story). Формат такой: «Я как [роль] хочу [действие], чтобы [цель/результат]».

Несколько примеров из реальных проектов:

• «Я как менеджер по продажам хочу видеть актуальную загрузку производства прямо в карточке сделки, чтобы называть клиенту реалистичные сроки без звонков в производственный отдел»
• «Я как руководитель отдела продаж хочу получать автоматическое уведомление, если сделка не переходит на следующую стадию более 10 дней, чтобы вовремя вмешаться и помочь менеджеру»
• «Я как финансовый директор хочу видеть сводный отчёт план/факт по отгрузкам за период с разбивкой по клиентам и продуктам, чтобы анализировать отклонения и корректировать прогнозы»
• «Я как снабженец хочу автоматически получать задачу в CRM при поступлении предоплаты от клиента, чтобы немедленно начать закупку сырья без ожидания письма от менеджера»

Для каждой роли пользователя — отдельная пользовательская история. Это кажется трудоёмким, но именно такой уровень описания устраняет большинство разночтений на этапе разработки.

Кто должен участвовать в подготовке требований

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

• Ключевого бизнес-заказчика — человека, который видит целостную картину бизнеса и может сбалансировать запросы разных подразделений. Это может быть директор по развитию, заместитель генерального или CEO
• Руководителей всех подразделений, которые будут работать в CRM или данные которых будут в ней отображаться: коммерческий директор, руководитель производства, начальник снабжения, логист, финансовый директор
• Ключевых исполнителей — менеджеров, которые будут работать в системе ежедневно. Именно они знают реальные боли процессов, а не только то, что отражено в регламентах

Важно: нередко регламенты компании расходятся с реальной практикой работы. Изучайте оба источника. Автоматизировать нужно реальный процесс, а не идеальный из инструкции, которую никто не соблюдает.

Как расставить приоритеты и правильно управлять бюджетом

Одна из самых частых причин провала CRM-проектов — попытка внедрить всё и сразу. Компания хочет получить полнофункциональную систему через 3 месяца, но в реальности такой проект занимает 8-12 месяцев — и за это время требования успевают измениться, а команда теряет мотивацию.

Итерационный подход работает лучше. Сначала запускается MVP (минимально жизнеспособный продукт) с ключевым функционалом, затем последовательно добавляются остальные возможности. Первый результат компания видит через 2-4 месяца, может работать в системе и давать обратную связь до того, как проект полностью завершён.

Для приоритизации требований используйте методику MoSCoW:

Функции из категории «Must have» входят в MVP. Остальные реализуются в последующих итерациях. Это позволяет существенно снизить первоначальные инвестиции и получить работающую систему значительно быстрее.

Практический лайфхак для оценки бюджета до написания полных требований: подготовьте краткое описание MVP на 1-2 страницы с ключевыми функциями, нужными интеграциями и количеством пользователей. Запросите у 2-3 интеграторов примерную стоимость. Полученные цифры умножьте на два — это ориентировочный бюджет первой итерации внедрения. Если сумма вписывается в возможности компании, можно переходить к полноценным функциональным требованиям.

Пять шагов к качественным функциональным требованиям

1. Сформулируйте цели внедрения. Конкретные, измеримые, с привязкой к бизнес-результатам. Всё остальное в документе должно быть направлено на достижение этих целей.
2. Изучите текущие процессы. Соберите регламенты и поговорите с руководителями и исполнителями. Найдите расхождения между тем, как процессы описаны, и тем, как они работают на самом деле.
3. Определите объекты системы и роли пользователей. Составьте полный список того, кто будет работать в CRM и с какими сущностями.
4. Опишите процессы с оптимальным уровнем детализации. Используйте User Story. Каждый процесс должен быть понятен интегратору без лишних вопросов, но не должен диктовать технические решения.
5. Приоритизируйте требования по MoSCoW. Выделите MVP и последующие итерации. Согласуйте документ со всеми заинтересованными сторонами внутри компании до отправки интегратору.

Типичные ошибки и их последствия

На основе практики разберём наиболее частые ошибки при составлении функциональных требований к CRM.

1. Нет целей внедрения. Команда интегратора не понимает, зачем нужна та или иная функция, выбирает не те инструменты. После запуска выясняется, что система не решает реальных задач бизнеса. Исправление стоит дополнительных денег и времени.
2. Слишком поверхностное описание процессов. «Нужно автоматизировать согласование КП» — это не описание процесса. Аналитик будет задавать уточняющие вопросы месяцами, старт проекта затянется. В итоге решение может быть реализовано неверно.
3. Избыточная детализация и диктовка технических решений. Когда заказчик прописывает конкретные технические решения («использовать инструмент X для построения отчётов»), он берёт на себя ответственность за их работоспособность. Если инструмент не справится с задачей, переделка ляжет на бюджет заказчика.
4. Нет приоритизации. Без неё невозможно запустить MVP в разумные сроки. Проект превращается в монолитную разработку длиной 10-12 месяцев. За это время требования устаревают, команда теряет интерес, а система к моменту запуска уже не соответствует реальности.
5. Требования неполные. Классический случай: компания не указала в требованиях необходимость интеграции с конкретной системой, считая это «очевидным». После запуска выясняется, что интеграция не реализована — нужен дополнительный бюджет и срок.
6. Нет контекста о долгосрочных планах. Если компания планирует через год выйти в новые регионы или добавить новое направление бизнеса, CRM должна быть спроектирована с учётом масштабирования. Интегратор, не знающий об этих планах, создаст систему, которую через год придётся переделывать.

Что должно быть в требованиях по интеграциям

Интеграции — самая технически сложная часть проекта, и именно здесь чаще всего возникают неожиданные трудности при разработке. Чем точнее вы опишете интеграции в требованиях, тем точнее будет оценка сроков и бюджета.

Для каждой интеграции укажите:

• Системы, которые интегрируются с CRM (1С, SAP, складская система, телефония, сайт)
• Направление передачи данных — из системы в CRM, из CRM в систему или двусторонний обмен
• Какие именно данные передаются — не «данные о заказах», а конкретный перечень полей
• Частота передачи — в реальном времени при каждом событии или пакетная загрузка раз в сутки
• Объём данных — количество записей за единицу времени, это влияет на производительность
• Версия интегрируемой системы и наличие доработок — чем больше кастомизаций в 1С, тем сложнее интеграция

Отдельно укажите требования к импорту исторических данных: нужно ли переносить в новую CRM историю сделок, контакты клиентов, переписку. Если да — какой объём данных и за какой период. Миграция данных — это отдельный этап проекта с собственным бюджетом и сроками.

Нефункциональные требования: о чём часто забывают

Функциональные требования описывают, что делает система. Нефункциональные — как она работает. Для крупного бизнеса нефункциональные требования критичны, и их отсутствие в документе может привести к неприятным сюрпризам после запуска.

Что нужно указать в нефункциональных требованиях:

• Количество одновременно работающих пользователей — от этого зависит производительность и выбор тарифного плана
• Допустимое время загрузки страниц — критично для систем с большим объёмом данных
• Допустимое время простоя (downtime) — для критичных бизнес-процессов это может быть ноль
• Требования к резервному копированию — как часто, где хранятся резервные копии, за какой период
• Требования к безопасности — двухфакторная аутентификация, ограничение доступа по IP, журналирование действий пользователей
• Требования к географическому размещению данных — актуально с учётом требований 152-ФЗ о персональных данных

Чек-лист перед отправкой требований интегратору

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

• Цели внедрения сформулированы конкретно и измеримо
• Задачи декомпозированы из целей
• Все объекты системы перечислены
• Роли пользователей и уровни доступа описаны
• Каждый процесс описан на среднем уровне детализации, а не просто назван
• Указаны все необходимые интеграции с внешними системами
• Для каждой интеграции указаны направление, состав данных и частота передачи
• Указан объём данных, которые будут поступать из внешних систем
• Описаны требования к аналитике и отчётности
• Нефункциональные требования сформулированы
• Требования приоритизированы по MoSCoW
• Документ согласован со всеми заинтересованными руководителями внутри компании
• Указаны долгосрочные планы развития бизнеса, которые могут влиять на архитектуру CRM

Если по каждому пункту можно поставить «да» — документ готов к отправке. Если по нескольким пунктам нет — уточните их до того, как начнёте переговоры с интеграторами. Неполные требования приводят к тому, что оценки от разных подрядчиков будут несопоставимы: каждый додумывает по-своему, и цифры могут отличаться в несколько раз.

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

Часто задаваемые вопросы