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

Короткий ответ: пилотный запуск — это проверка новой системы на одном отделе, филиале или группе в реальной работе, обычно 2–6 недель. До старта вы выбираете участок и людей, записываете измеримые критерии успеха и правила работы со старой системой, а в конце принимаете одно из трёх решений: запускаем на всех, дорабатываем или останавливаем. Пилот не заменяет приёмку по договору и проверяет другое — приживётся ли система в компании.

Статья для руководителя, который заказал CRM, личный кабинет клиентов, учётный сервис или внутренний портал и не хочет в понедельник перевести на него всю компанию разом. Как внедрять CRM целиком, разобрано в статье «Внедрение CRM: этапы и почему не приживается»; здесь — только о том, как устроить проверку на малом участке и не обмануть себя её итогами.

Что такое пилотный запуск и зачем он нужен?

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

На тестовом сервере систему проверяют разработчик и пара сотрудников заказчика на придуманных примерах. В пилоте выясняется другое:

• менеджер получает 40 заявок в день, а не три тестовые, и форма, удобная на одном примере, начинает раздражать;
• появляются случаи, о которых никто не вспомнил при постановке задачи: возврат, клиент с двумя юрлицами, заявка от партнёра;
• обмен с 1С или телефонией работает, но с задержкой, которая в отчёте не видна, а в работе мешает;
• часть людей тихо продолжает вести старую таблицу «на всякий случай».

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

Какой участок и каких пользователей выбрать?

Берите участок, где система нужнее всего и где есть типичная, а не исключительная работа. Группа — 3–10 человек, с руководителем, который сам пользуется системой. Не берите самых лояльных и не берите самых сложных: итог должен быть применим к остальной компании.

Проверьте участок по четырём вопросам:

• Типичность. Работа отдела похожа на работу остальных? Пилот в отделе крупных клиентов мало скажет о рознице.
• Полный цикл. За срок пилота участок пройдёт процесс от начала до конца: от заявки до оплаты, от заказа до отгрузки.
• Зависимости. Сколько других отделов задето? Если бухгалтерия должна работать в двух системах сразу, это нагрузка на людей вне пилота — договоритесь с ними заранее.
• Сезон. Не запускайте пилот в пиковый месяц: у людей не будет времени разбираться, и вы проверите усталость, а не систему.

Внутри группы назначьте одного ответственного со стороны компании: он собирает замечания, решает спорные вопросы и говорит от имени пользователей. Подробнее об этой роли — в статье «Владелец продукта со стороны заказчика».

Сколько должен длиться пилот?

Срок задаётся рабочим циклом, а не круглой цифрой: участок должен пройти его хотя бы дважды. Для отдела продаж с короткими сделками это 3–4 недели, для учёта и отчётности — до закрытия месяца, для сервиса с записью клиентов — 2–3 недели.

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

Дату окончания назначьте до старта и запишите. Пилот без даты окончания незаметно превращается в «мы уже работаем так», только без решения и без доработок.

Что меряем	Как считаем	Порог «запускаем»	Где берём цифру
Доля заявок, попавших в систему	Заявки в системе / все входящие заявки за неделю	Не меньше 95 %	Сверка с телефонией, почтой и формой сайта
Работа без старой таблицы	Сколько дней пилотная группа не открывала Excel для текущих сделок	Последние 2 недели — ни одного	Опрос группы и история файла
Время на типовую операцию	Минуты на оформление заявки «было / стало», замер секундомером на 10 примерах	Не дольше, чем было	Замер до старта и на 3-й неделе
Блокирующие ошибки	Ошибки, из-за которых нельзя закончить операцию	0 открытых к концу пилота	Журнал замечаний
Отчёт руководителя	Собирается ли недельный отчёт из системы без ручной правки	Да, 2 недели подряд	Руководитель отдела
Отношение пользователей	Ответ на вопрос «вернуться к старому способу?»	Большинство — «нет»	Короткий опрос в конце

Как задать критерии успеха до старта?

Запишите 4–6 измеримых критериев с порогом «запускаем» и источником цифры. Первые замеры «как сейчас» сделайте до старта, иначе сравнивать будет не с чем. Без порогов итог пилота сведётся к спору мнений «мне удобно» и «мне неудобно».

Пример для CRM отдела продаж — в таблице ниже. Для личного кабинета клиентов критерии другие: доля клиентов, которые вошли и сделали целевое действие, число обращений «не могу войти», доля заказов через кабинет вместо телефона. Для учётной системы — совпадение итогов с прежним учётом до рубля и время закрытия периода.

Два правила для критериев:

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

Как работать параллельно со старой системой?

Заранее решите, какая система главная для пилотной группы. Надёжный вариант: новая система — рабочая, старая — только для чтения и сверки. Двойной ввод одних и тех же данных допустим лишь на 1–2 недели и только там, где ошибка стоит денег.

Три типовые схемы:

• Новая главная, старая для справки. Группа работает только в новой системе, в старой смотрит историю. Подходит для CRM и кабинетов.
• Параллельный учёт с ежедневной сверкой. Операции идут в обеих системах, итоги сравнивают каждый день. Нужно для денег, складских остатков и отчётности, но выматывает людей — держите такой режим коротким.
• Разделение потока. Новые клиенты или новые заказы — в новой системе, текущие доводятся в старой. Удобно, когда перенос истории сложен.

Если для пилота переносили данные, заранее сверьте их по количеству и выборочно по содержимому — как это делать, разобрано в статье «Миграция данных в новую систему». И запишите план отката: что делает группа, если система недоступна полдня.

Как собирать замечания во время пилота?

Заведите один журнал замечаний — таблицу или доску задач — и одного человека, который его ведёт. Каждое замечание: что делали, что ожидали, что получили, скриншот, кто и когда. Раз в неделю — короткая встреча с разработчиком по журналу.

Замечания сразу делите на три группы, иначе всё смешается в «система плохая»:

• Ошибка. Система делает не то, что записано в задании. Это исправляет исполнитель.
• Новое требование. Система делает, как договаривались, но в работе нужно иначе. Это доработка: её оценивают и ставят в план.
• Вопрос привычки или обучения. Функция есть, но её не нашли или не поняли. Это решает инструкция, подсказка в интерфейсе или короткое обучение.

Как описывать ошибку, чтобы её исправили с первого раза, — в статье «Как сообщить разработчику об ошибке». Не ждите конца пилота, чтобы передать замечания: блокирующие ошибки исправляют сразу, остальное — пакетом раз в неделю.

Как принять решение по итогам пилота?

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

• Запускаем. Пороги выполнены, блокирующих ошибок нет. Дальше — план тиражирования: порядок отделов, обучение, дата отключения старой системы. Сотрудники пилотной группы становятся помощниками для остальных.
• Дорабатываем. Часть порогов не выполнена по понятной причине: не хватает поля, неудобный шаг, медленный обмен. Составьте короткий список доработок с оценкой и проверьте их на той же группе 1–2 недели.
• Останавливаем. Система не решает задачу участка или издержки на неё больше пользы. Это тоже результат: вы потратили деньги на проверку, а не на запуск в масштабе всей компании.

Запишите решение и причины на одной странице. Через полгода, когда кто-то спросит, почему выбрали именно так, ответ будет на бумаге, а не в памяти участников.

	Пилотный запуск	Приёмка по договору	Опытная эксплуатация (ГОСТ Р 59792-2021)
Вопрос	Приживётся ли система в работе компании	Сделано ли то, что записано в ТЗ	Соответствует ли система требованиям в реальной работе
Кто участвует	Один отдел, филиал или группа	Заказчик и исполнитель	Пользователи по программе испытаний, затем приёмочная комиссия
Срок	Обычно 2–6 недель, договариваются сами	В нашем договоре — 5 рабочих дней	По программе опытной эксплуатации
Документы	План пилота, журнал замечаний, итоговое решение	Акт или мотивированный отказ	Журнал, акт о завершении, затем приёмочные испытания
Итог	Запускаем / дорабатываем / останавливаем	Работы приняты или есть перечень замечаний	Готовность к приёмочным испытаниям

Чем пилот отличается от приёмки и опытной эксплуатации?

Приёмка отвечает на вопрос «сделано ли по договору», пилот — «приживётся ли в компании». Опытная эксплуатация — формальный вид испытаний автоматизированных систем по ГОСТ Р 59792-2021 с журналом и актом. Это три разные проверки, и их полезно не смешивать.

По нашему типовому договору заказчик в течение 5 рабочих дней подписывает акт или направляет мотивированный отказ с перечнем замечаний; если не сделать ни того ни другого, работы считаются принятыми. Пилот на 3–4 недели в эти дни не помещается. Поэтому порядок нужно продумать заранее:

• пилот можно сделать отдельным этапом до финального акта — тогда это прописывают в плане работ;
• если пилот идёт после акта, ошибки, возникшие по вине исполнителя, он устраняет бесплатно в течение 30 календарных дней гарантии с даты акта, а новые требования — уже доработка.

Что проверять при самой приёмке, разобрано в статье «Как принять сайт у разработчика». Если же пилот нужен, чтобы проверить самого подрядчика на небольшой задаче, читайте статью о пилотном проекте с разработчиком.

ГОСТ Р 59792-2021 (действует с 30 апреля 2022 года) называет три вида испытаний: предварительные, опытная эксплуатация и приёмочные. Во время опытной эксплуатации ведут журнал отказов и корректировок, по итогам оформляют акт о завершении, затем проводят приёмочные испытания. Национальные стандарты по закону «О стандартизации» применяются добровольно: для небольшой компании эта процедура обязательна, только если на неё сослались в договоре или этого требует заказчик, например государственный. Но идея журнала и акта о завершении полезна и для простого пилота.

Когда пилот не нужен и какие ошибки встречаются?

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

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

Частые ошибки:

• Критерии придумали после. Итог подгоняют под желаемое решение — в любую сторону.
• Пилотная группа из энтузиастов. У них всё получилось, а остальные отделы систему не приняли.
• Нет даты окончания. Пилот идёт полгода, две системы живут параллельно, решения нет.
• Старая таблица осталась рабочей. Люди ведут дела там, где привыкли, и новая система пустеет.
• Все замечания — «ошибки». Новые требования смешаны с дефектами, споры с исполнителем вместо доработок.
• Руководитель не пользуется сам. Если отчёт по-прежнему собирают вручную, сотрудники быстро понимают, что система необязательна.

Как мы помогаем с пилотом и сколько это стоит?

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

Что важно знать по срокам и деньгам:

• веб-приложение или кабинет — от 160 000 ₽ и от 10 дней, интеграции и автоматизация — от 32 000 ₽, по прайсу; точную смету считаем после брифа и фиксируем в договоре до старта;
• после запуска веб-приложения — 14 дней бесплатной поддержки на мелкие правки, отдельно от гарантии по договору; дальнейшее развитие — по абонентке от 7 900 ₽ в месяц или по задачам;
• на прототипе и на готовой сборке веб-приложения — до 2 раундов правок; крупные изменения по итогам пилота оцениваем как доработку.

Подробнее о том, как устроена заказная работа от брифа до запуска, — на странице заказной разработки.

Короткие ответы на частые вопросы

Что такое пилотный запуск простыми словами?

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

Сколько должен длиться пилот?

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

Пилот — это то же самое, что опытная эксплуатация?

Похоже, но не одно и то же. Опытная эксплуатация — вид испытаний по ГОСТ Р 59792-2021 с программой, журналом и актом. Пилот в небольшой компании — управленческая проверка без обязательных формальностей. Если в договоре сослались на ГОСТ, действуют его правила.

Нужно ли платить за пилот отдельно?

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

Что делать, если пилот провалился?

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

Услуги и кейсы по теме: заказная разработка · типовые договоры · цены и сроки