ТЗ на внедрение Битрикс24 и подготовка корпоративного контура

Коротко: качественное ТЗ начинается с аудита текущих процессов и проектирования целевых, а не с перечня функций.

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

В проектах с производственными или сервисными компаниями мы часто видим разрыв между ожиданиями руководства и реальностью процессов. Собственник хочет видеть «полную прозрачность», но его менеджеры привыкли договариваться о скидках устно, а сроки согласования держатся в голове начальника цеха. Если просто перенести это в Битрикс24, система зафиксирует хаос, а не упорядочит его.

Поэтому наше техническое задание всегда начинается не с функций, а с аудита текущих операций. Мы рисуем схему «как есть», находим узкие места (где теряются данные, где возникают задержки) и предлагаем схему «как должно быть». Только после этого фиксируем требования к полям, ролям, интеграциям и отчетам. Для крупных компаний этот этап критичен: без единой модели данных разные отделы начнут использовать портал по-разному, и объединить их потом будет невозможно.

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

Почему ТЗ важнее выбора тарифа

Многие начинают выбор системы с вопроса «Облако или Коробка?». Это ошибка. Сначала нужно понять, какие задачи должна решать система. Только тогда станет ясно, нужны ли глубокие доработки (Коробка) или хватит стандартных функций (Облако).

Хорошее ТЗ отвечает на три главных вопроса:

Что именно мы автоматизируем? Не «продажи вообще», а конкретный путь клиента от заявки до отгрузки.
Кто будет работать в системе? Роли, права доступа, зоны ответственности.
Как мы поймем, что успех достигнут? Метрики: скорость обработки, конверсия, отсутствие потерь данных.

Если хотя бы один из этих пунктов размыт, проект рискует превратиться в бесконечную настройку «под настроение».

Структура эффективного технического задания

1. Описание бизнес-процессов «As Is» и «To Be»

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

Важно выявить расхождения. Например, сейчас менеджер звонит клиенту, если нет ответа на почту. В новой системе это должно быть правилом: «если нет ответа 24 часа — создать задачу на звонок». Такие детали делают ТЗ рабочим документом, а не формальностью.

2. Модель данных и справочники

Определите ключевые сущности: Лиды, Сделки, Контакты, Компании, Товары, Документы. Для каждой укажите обязательные поля и их типы.

Отдельное внимание уделите справочникам. Регионы, источники заявок, причины отказов, статусы договоров — все они должны быть унифицированы. Если каждый менеджер пишет источник «Авито» по-своему («авито», «Avito», «площадка объявлений»), аналитика будет недостоверной.

3. Роли и права доступа

Опишите матрицу ролей. Кто видит чужие сделки? Кто может удалять записи? Кто имеет доступ к финансовым данным? Для производственных компаний критично скрыть себестоимость от отдела продаж, а контакты клиентов — от логистики.

Укажите исключения: например, руководитель филиала видит только свой регион, но может эскалировать проблему головным специалистам.

4. Интеграции и обмен данными

Зафиксируйте, какие системы должны общаться с CRM. Обычно это 1С (товары, цены, заказы), телефония (записи звонков), почта (входящие письма) и сайт (формы заявок).

Для каждой интеграции определите направление потока данных и частоту обновления. Например: «Цены обновляются из 1С в CRM каждые 15 минут», «Статус оплаты возвращается из 1С в CRM сразу после проведения документа».

5. Отчетность и KPI

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

Каждый отчет должен иметь владельца и периодичность просмотра. Иначе он станет еще одним неиспользуемым файлом.

Специфика корпоративного контура для крупных компаний

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

Единая модель данных против локальных настроек

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

Решение — жесткая централизация базовых объектов (Контакты, Компании, Товары) при гибкости операционных процессов (воронки сделок). Все пользователи должны ссылаться на одни и те же карточки клиентов, даже если ведут разные виды деятельности.

Иерархия прав и безопасность

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

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

Масштабируемость и поддержка

Выбирая коробочную версию для крупной компании, заложите бюджет на выделенного администратора или команду поддержки. Облако проще в обслуживании, но ограничивает возможности кастомизации. Коробка дает свободу, но требует ресурсов.

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

Типичные ошибки в ТЗ

«Сделайте нам как у Amazon». Попытка скопировать сложные процессы без понимания своих ресурсов. Лучше начать с MVP (минимально жизнеспособного продукта) и развивать его поэтапно.
Игнорирование человеческого фактора. ТЗ описывает функции, но не объясняет, зачем они нужны сотрудникам. Без мотивации и обучения даже лучшая система останется невостребованной.
Отсутствие критериев приемки. Нельзя принять проект, пока не понятно, что считать успешным результатом. Зафиксируйте метрики до начала работ.
Слишком детализированные требования к интерфейсу. Описывайте логику работы, а не расположение кнопок. Дизайнеры и разработчики сами найдут оптимальное решение.

Чек-лист готовности к внедрению

Описаны основные бизнес-процессы «как есть» и «как должно быть»?
Определены роли пользователей и границы их видимости?
Составлен список необходимых интеграций и источников данных?
Утверждены справочники и стандарты заполнения полей?
Сформулированы KPI проекта и методы их измерения?
Назначен владелец проекта со стороны бизнеса?
Выделен бюджет на обучение и сопровождение после запуска?

Частые вопросы

Можно ли составить ТЗ самостоятельно?

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

Нужно ли менять ТЗ в ходе проекта?

Да, изменения неизбежны. Главное — фиксировать их официально и оценивать влияние на сроки и бюджет. Стихийные правки «на лету» приводят к потере контроля над проектом.

Что делать, если процессы еще не описаны?

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