Большинство неудачных проектов внедрения выглядят одинаково: подрядчик получил доступ к порталу и сразу начал настраивать. Через две недели система готова, ещё через месяц менеджеры возвращаются в блокноты, а через полгода компания ищет другого исполнителя, чтобы всё переделать.
Причина почти всегда в нарушенной последовательности. Настройка — это четвёртый этап, а не первый. Ему предшествует работа, которая не видна в интерфейсе, но определяет, будет ли система жить: диагностика процессов и проектирование архитектуры.
Ниже разбираем шесть этапов внедрения Битрикс24: что происходит на каждом, сколько он занимает, кто в нём участвует со стороны компании и какой результат должен появиться на выходе. И отдельно — что обязано быть зафиксировано в техзадании, чтобы проект можно было принять, а не обсуждать.
Почему порядок важнее скорости
Каждый этап производит артефакт, который становится входными данными для следующего. Пропуск любого из них не ускоряет проект, а переносит работу на более поздний срок, когда её стоимость выше.
Пример из практики. Компания просит «настроить воронку как у всех» и пропустить диагностику, чтобы сэкономить. Настройка занимает неделю вместо трёх. Через два месяца выясняется, что реальный процесс продаж включает согласование сметы и выезд замерщика, а в системе этих стадий нет. Менеджеры ведут эти этапы в чате, отчёты не отражают реальность, и приходится перепроектировать воронку — теперь уже с миграцией сделок между стадиями и переобучением команды.
Итог: сэкономленные две недели превратились в месяц переделки. Мы разбирали экономику этого явления в материале о том, из чего складывается цена внедрения Битрикс24 — экономия на диагностике оказывается самой дорогой.
Этап 1. Диагностика процессов
Что происходит. Изучается, как компания работает сейчас: откуда приходят обращения, что происходит с заявкой по шагам, кто за что отвечает, где данные передаются вручную, на каких шагах теряются клиенты. Инструменты — интервью с руководителем, руководителем отдела продаж и линейными менеджерами, разбор реальных сделок, просмотр текущих отчётов.
Важно опрашивать не только руководство. Официальный процесс и фактический расходятся почти всегда, а автоматизировать нужно фактический — или сознательно менять его, но с пониманием, что меняется.
Кто участвует со стороны компании. Собственник или директор, руководитель отдела продаж, два-три менеджера, при наличии — специалист по учётной системе.
Сколько занимает. От нескольких дней до двух недель в зависимости от числа процессов.
Результат этапа. Описание процессов «как есть», перечень точек потерь и приоритизированный список задач, которые система должна решить. Без этого документа обсуждать настройку нечего.
Этап 2. Проектирование архитектуры
Что происходит. На основе диагностики проектируется, как процессы будут выглядеть в системе: сколько воронок и какие у них стадии, какие сущности нужны помимо сделок, какие поля обязательны, кто что видит, что автоматизируется, какие интеграции критичны.
Здесь же принимаются решения о том, чего в системе не будет. Отказ от лишнего —半 работы этого этапа: каждое необязательное поле снижает вероятность, что менеджеры будут заполнять обязательные.
На этом этапе часто появляется несколько вариантов решения — от радикальной перестройки процессов с максимальным эффектом до точечного усиления слабых мест с быстрым внедрением. Выбор темпа остаётся за компанией.
Кто участвует. Руководитель, принимающий решения по процессам. Согласование архитектуры — управленческое действие, а не техническое.
Сколько занимает. Одна-три недели с учётом согласования.
Результат этапа. Техническое задание: схемы воронок, перечень полей и сущностей, матрица прав доступа, список автоматизаций и интеграций, критерии приёмки.
Этап 3. Настройка системы
Что происходит. Реализация согласованного проекта: воронки и стадии, поля и карточки, права доступа, роботы и триггеры, шаблоны документов, подключение телефонии и каналов связи, интеграции.
Работа ведётся по ТЗ и почти без участия компании — это ключевое отличие этого этапа. Если на нём требуется постоянное вовлечение сотрудников заказчика, значит, предыдущий этап не доделан.
Кто участвует. Со стороны компании — один человек для уточнений, обычно будущий суперпользователь. При наличии интеграций подключается специалист по учётной системе.
Сколько занимает. От двух недель до нескольких месяцев в зависимости от объёма интеграций.
Результат этапа. Настроенная система, соответствующая ТЗ, и заполненная миграцией база, если предусмотрен перенос данных. Порядок миграции и типовые риски мы разбирали отдельно — на примере переноса клиентской базы из Excel.
Этап 4. Пилот и тестирование
Что происходит. Проверка системы на реальных сделках ограниченной группой сотрудников. Не демонстрация, а работа: два-три менеджера ведут настоящих клиентов в новой системе, а не тестовые записи с названием «Проверка 1».
Тестируются сквозные сценарии целиком: заявка пришла — распределилась — задача поставилась — документ сформировался — данные ушли в учётную систему — отчёт показал корректные цифры. Отдельно проверяются исключения: возврат, отказ, повторное обращение того же клиента.
Этот этап пропускают чаще всего, и именно он отделяет работающее внедрение от формально сданного. Найденные здесь недочёты стоят часы, найденные после запуска — дни и репутацию проекта внутри компании.
Кто участвует. Два-три менеджера и руководитель отдела. Важно выбрать не самых лояльных, а тех, кто задаёт неудобные вопросы.
Сколько занимает. Одна-две недели, включая доработки по итогам.
Результат этапа. Перечень замечаний и внесённых исправлений, подтверждение работоспособности сквозных сценариев.
Этап 5. Обучение и регламенты
Что происходит. Обучение проводится по рабочим сценариям, а не по интерфейсу. Менеджеру нужно не знать, где какая кнопка, а понимать, что делать при поступлении заявки, как фиксировать договорённости и куда смотреть в начале дня.
Форматы различаются по ролям: менеджеры учатся вести сделки, руководитель — читать отчёты и контролировать, суперпользователь получает расширенную подготовку по администрированию. Отдельно фиксируются регламенты и инструкции, которые остаются в системе, а не в записи созвона.
Кто участвует. Все, кто будет работать в системе.
Сколько занимает. От нескольких дней до двух недель.
Результат этапа. Обученная команда, база знаний с инструкциями, назначенный суперпользователь внутри компании.
Этап 6. Запуск и сопровождение
Что происходит. Перевод всей работы в систему. В первые недели ведётся контроль: корректно ли заполняются данные, срабатывают ли автоматизации, где команда испытывает трудности. По итогам вносятся корректировки — они всегда нужны, и их стоит закладывать в план заранее.
Дальше система переходит в режим эксплуатации, и возникает вопрос, кто её поддерживает: штатный сотрудник, подрядчик или гибридная схема. Мы разбирали варианты в материале о техподдержке Битрикс24.
Сколько занимает. Активное сопровождение — две-четыре недели после запуска.
Результат этапа. Система работает, данные заполняются, отчёты отражают реальность.
Сводка по этапам
| Этап | Длительность | Вовлечение компании | Результат |
|---|---|---|---|
| 1. Диагностика | 3 дня — 2 недели | Высокое: интервью | Описание процессов, точки потерь |
| 2. Проектирование | 1–3 недели | Среднее: согласование | Техническое задание |
| 3. Настройка | 2 недели — несколько месяцев | Низкое | Настроенная система |
| 4. Пилот | 1–2 недели | Среднее: 2–3 сотрудника | Замечания и исправления |
| 5. Обучение | 3 дня — 2 недели | Высокое: вся команда | Обученная команда, регламенты |
| 6. Запуск | 2–4 недели сопровождения | Высокое, затем снижается | Работающая система |
Обратите внимание на распределение вовлечённости: пики приходятся на начало и конец, а самый долгий этап проходит почти без участия команды. Это опровергает распространённое опасение, что внедрение отвлечёт отдел продаж на месяцы.
Кто что делает: распределение ответственности
| Зона | Подрядчик | Компания |
|---|---|---|
| Описание процессов | Проводит интервью, формализует | Предоставляет информацию, подтверждает корректность |
| Решения по процессам | Предлагает варианты | Выбирает и утверждает |
| Техническое задание | Разрабатывает | Согласовывает |
| Настройка | Выполняет | Отвечает на уточнения |
| Доступы и лицензии | Консультирует по выбору | Приобретает, предоставляет доступы |
| Подготовка данных к миграции | Нормализует, переносит | Определяет, что переносить; чистит спорное |
| Работы на стороне 1С | Проектирует обмен | Обеспечивает участие своего специалиста |
| Пилот | Организует, исправляет | Выделяет сотрудников, даёт обратную связь |
| Обучение | Проводит | Обеспечивает явку и время сотрудников |
| Соблюдение регламентов | Формализует | Обеспечивает исполнение |
Последняя строка — самая частая причина провала при технически корректном внедрении. Подрядчик не может заставить менеджеров работать в системе; это управленческая функция. Механику сопротивления мы разбирали в статье «Почему менеджеры не работают в CRM».
Чек-лист техзадания
ТЗ — это не формальность для договора, а документ, по которому проект принимается. Проверьте, что в нём есть все пункты.
- Цели проекта в измеримых формулировках. Не «внедрить CRM», а «фиксировать все обращения из четырёх каналов», «сократить время подготовки КП», «получать отчёт по конверсии без ручной сборки».
- Перечень процессов в объёме проекта — и явное указание того, что в него не входит.
- Схемы воронок со стадиями, условиями перехода и ответственными.
- Перечень полей с типами данных и признаком обязательности.
- Список сущностей и смарт-процессов помимо стандартных.
- Матрица прав доступа по ролям: кто что видит, изменяет, выгружает.
- Перечень автоматизаций. Каждый робот и триггер: событие, условие, действие.
- Интеграции по названиям с указанием направления обмена, состава данных и частоты синхронизации. Для обмена с учётной системой — отдельный раздел, детали в материале об интеграции Битрикс24 с 1С.
- Шаблоны документов списком с указанием источников автозаполнения.
- Состав отчётов и дашбордов с перечнем показателей.
- Объём и правила миграции: что переносится, за какой период, как обрабатываются дубли.
- План обучения по ролям и форматам.
- Критерии приёмки. Проверяемые условия, при которых работа считается выполненной.
- Порядок изменений. Как оформляются и оцениваются дополнительные требования.
- Гарантийный период и условия сопровождения после сдачи.
Пункты 13 и 14 отсутствуют чаще всего, и именно они предотвращают конфликты. Без критериев приёмки спор о готовности проекта не имеет решения: одна сторона считает, что настроено по договорённости, другая — что работает не так, как ожидалось.
Пять признаков шаблонного внедрения
- Настройку начинают в первые дни. Диагностики нет, воронка берётся из типового решения. Самый надёжный признак.
- Не задают вопросов о процессах. Если подрядчик не спрашивает, что происходит после закрытия сделки, кто согласовывает скидки и откуда берутся цены, — он настраивает демо-версию, а не вашу систему.
- Смета одной строкой. «Внедрение CRM — сумма» без расшифровки по блокам означает, что объём работ не проектировался.
- Нет этапа пилота. Сдача проекта через демонстрацию вместо проверки на реальных сделках.
- Обучение в формате записи экрана. Видеозапись вместо работы с сотрудниками по их сценариям — гарантия того, что систему не примут.
Дополнительный признак, который стоит проверять: остаётся ли у вас документация по настройкам. Система, устройство которой известно только исполнителю, создаёт зависимость от подрядчика вне зависимости от качества работы.
Два главных возражения
«Это займёт слишком много времени»
Базовый проект — от двух до четырёх недель. Комплексное внедрение с интеграциями — полтора-три месяца. Проекты уровня всей компании идут этапами.
При этом сравнивать нужно не со «сделать быстро», а с продолжением текущей ситуации. Если компания ежемесячно теряет часть заявок и собирает отчёты вручную, месяц внедрения сопоставим с месяцем этих потерь. Разница в том, что после внедрения потери прекращаются, а без него продолжаются.
«Внедрение отвлечёт команду от продаж»
Посмотрите на колонку вовлечённости в сводной таблице. Реальные затраты времени сотрудников: несколько часов на интервью в начале, работа двух-трёх человек в пилоте, обучение в конце. Самый длинный этап — настройка — проходит без участия команды.
Продажи не останавливаются: тестирование идёт на реальных сделках параллельно текущей работе, а переключение происходит в один день. Этапный подход позволяет начать с одного отдела и не переводить всю компанию одновременно.
Как принимать работу
Приёмка по демонстрации ненадёжна: показать можно любой сценарий. Проверять стоит самостоятельно и по критериям из ТЗ.
- Сквозной прогон. Проведите реальную сделку от заявки до закрытия и документов — своими руками, а не глядя на экран подрядчика.
- Проверка автоматизаций. Каждый робот из ТЗ: создайте условие и убедитесь, что действие произошло.
- Проверка прав. Зайдите под учётной записью менеджера и посмотрите, что доступно.
- Проверка обмена. Создайте запись с одной стороны и найдите её с другой.
- Проверка отчётов. Сверьте цифры в дашборде с тем, что вы знаете о своих продажах.
- Проверка исключений. Отказ, возврат, повторное обращение — сценарии, которые обычно не показывают на демонстрации.
Частые вопросы
Можно ли пропустить диагностику, если процессы уже описаны?
Сократить — да, пропустить — нет. Даже при наличии описаний нужна проверка того, что фактическая работа им соответствует. Расхождение между регламентом и практикой обнаруживается почти всегда, и автоматизировать нужно то, что происходит в реальности.
Кто должен писать техзадание — мы или подрядчик?
Разрабатывает подрядчик по итогам диагностики, согласовывает компания. ТЗ, написанное заказчиком самостоятельно, обычно описывает желаемый интерфейс вместо задач, а подрядчик реализует его буквально — с предсказуемым результатом.
Что делать, если требования изменились в процессе?
Это нормально, и порядок обработки изменений должен быть в договоре: оценка в часах, согласование, включение в объём. Проблема не в самих изменениях, а в их неоформленном накоплении — тогда сроки уезжают, а причина остаётся непрозрачной.
Обязателен ли пилот?
Практически да. Это единственный способ проверить систему в реальных условиях до того, как в неё перейдёт вся команда. Пропуск пилота экономит одну-две недели и создаёт риск того, что первое впечатление команды от системы будет негативным — переломить его сложнее, чем исправить настройки.
Можно ли внедрять поэтапно?
Да, и для крупных проектов это предпочтительный вариант: сначала отдел продаж, затем сервис или производство, потом аналитика. Каждый этап даёт результат сам по себе, а после первого видно и реальную трудоёмкость, и качество подрядчика.
Что должно остаться у нас после проекта?
Техзадание, документация по настройкам и интеграциям, регламенты и инструкции в базе знаний, обученный суперпользователь, все доступы. Этот набор определяет, сможете ли вы развивать систему дальше — своими силами или с любым подрядчиком.
Что делать дальше
Внедрение Битрикс24 — управляемый процесс с понятной последовательностью, и почти все проблемы в нём возникают из-за пропуска этапов, а не из-за сложности платформы. Проверить подход подрядчика можно ещё до подписания договора: спросите, что будет происходить в первую неделю. Если ответ начинается с настройки, а не с разбора процессов, стоит задать дополнительные вопросы.
Мы начинаем с диагностики: разбираем, как идут продажи, где теряются деньги, какие процессы живут вне системы. Показываем механику результата, предлагаем варианты решения с разным темпом трансформации и только затем проектируем архитектуру — чтобы система работала через год, а не только в день запуска.
Посмотрите, как устроено комплексное внедрение Битрикс24, изучите наши кейсы или запишитесь на консультацию — разберём ваши процессы и составим план проекта.
