Типовой проект автоматизации одного участка занимает 8–14 недель календарного времени, и собственно разработка в нём — меньше половины. В модельном проекте на 10 недель, то есть 50 рабочих дней, написание и настройка занимают 19 дней. Остальные 31 день уходят на доступы, данные, согласования, тестирование и обучение людей.
Именно поэтому вопрос «а почему так долго» почти всегда задают не к тому. Ускорить разработку вдвое нельзя — можно только добавить людей и получить те же сроки при большем бюджете. Зато можно убрать половину ожидания, и это делается не подрядчиком, а заказчиком, причём до подписания договора.
Ниже — разложение календаря по составляющим, таблица типовых сроков по классам задач, шесть факторов, которые удлиняют проект вдвое, расчёт цены одной недели сдвига и три действия, сокращающие срок на три недели. Модельный проект — связка CRM с 1С:УТ и автозаполнение карточек из входящих каналов в компании на 60 человек.
Из чего состоит календарь: разработка — меньше половины
Под разработкой здесь понимается только написание и настройка кода. Тестирование, подготовка данных, обучение и согласования — отдельные строки, хотя формально это тоже работа по проекту. Такое разделение важно: когда подрядчик говорит «работы на три недели», он обычно называет именно первую строку, а заказчик слышит срок всего проекта.
| Составляющая | Рабочих дней | Доля календаря | Кто определяет длительность |
|---|---|---|---|
| Разработка и настройка | 19 | 38 % | Подрядчик |
| Согласования и ответы на вопросы | 8 | 16 % | Заказчик |
| Ожидание доступов и тестовых сред | 7 | 14 % | Заказчик и третьи стороны |
| Тестирование и приёмка | 7 | 14 % | Обе стороны |
| Подготовка и чистка данных | 6 | 12 % | Заказчик |
| Обучение и запуск | 3 | 6 % | Обе стороны |
| Итого | 50 | 100 % | — |
Третья колонка объясняет главное недоразумение сроков: 31 день из 50 зависит не от подрядчика. Заказчик влияет на 21 день напрямую и ещё на 10 — совместно. Это не перекладывание ответственности, а инженерный факт, из которого следует практический вывод: договариваться о сроке имеет смысл вместе с обязательствами обеих сторон, а не только с обязательствами исполнителя.
Отсюда же следует, почему давление на подрядчика по срокам почти не работает. Даже если разработка ускорится на треть — с 19 дней до 13, — общий календарь сократится с 50 дней до 44, то есть чуть больше чем на неделю. А вот сокращение ожидания доступов и подготовки данных с 13 дней до 4 даёт те же девять дней, но без потери качества и без переработок. Первый рычаг короткий и дорогой, второй длинный и почти бесплатный, и находится он у заказчика.
Горизонтальная составная полоса на 50 рабочих дней, разбитая на шесть сегментов с подписями и долями: «Разработка и настройка — 19 дней, 38 %», «Согласования — 8 дней, 16 %», «Доступы и среды — 7 дней, 14 %», «Тестирование и приёмка — 7 дней, 14 %», «Подготовка данных — 6 дней, 12 %», «Обучение и запуск — 3 дня, 6 %». Под полосой две скобки: короткая под первым сегментом с подписью «зона подрядчика — 19 дней» и длинная под остальными с подписью «зона заказчика и третьих сторон — 31 день». Чертёжный стиль, подписи по-русски.
Типовые сроки по классам задач
Сроки ниже — для одного участка в компании на 20–300 человек, при наличии владельца процесса и без параллельного внедрения ещё чего-нибудь. Первая колонка — календарь целиком, вторая — только разработка. Разница между ними и есть то, о чём договариваются заранее.
| Класс задачи | Календарь | Из них разработка | Что чаще всего сдвигает срок |
|---|---|---|---|
| Обмен между двумя системами по готовым API (CRM ↔ 1С:УТ) | 4–7 недель | 2–3 недели | Доступ к базе учётной системы и состояние справочников |
| Автозаполнение карточек из почты, форм и мессенджеров | 5–8 недель | 2–3 недели | Число каналов и разнобой в форматах входящих сообщений |
| Обработка входящих документов с распознаванием | 8–14 недель | 3–5 недель | Сбор выборки документов и ручная разметка эталона |
| Голосовой сценарий на входящих звонках | 6–10 недель | 2–4 недели | Согласование текстов, запись и перевыпуск номеров у оператора |
| Управленческая отчётность и дашборды | 6–12 недель | 2–4 недели | Согласование методики расчёта показателей между отделами |
| Чат-бот с базой знаний по продукту | 5–9 недель | 2–3 недели | Подготовка и вычитка самой базы знаний силами заказчика |
Верхняя граница каждой вилки — не пессимизм, а ситуация, когда сработал хотя бы один из шести факторов ниже. Нижняя достижима, но только при выполненной домашней работе: доступы собраны, данные посмотрены, владелец процесса назначен. Как устроен сам проект по этапам и что принимается на каждом, разобрано отдельно — восемь этапов проекта внедрения.
Отдельно стоит сказать про сложение задач. Календари не складываются арифметически, но и не поглощают друг друга: два участка, которые делает одна команда для одного заказчика, занимают примерно в полтора раза больше времени, чем один. Причина не в разработке — её действительно можно вести параллельно, — а в том, что владелец процесса, ИТ-контакт и ключевые пользователи у вас в единственном экземпляре, и все согласования выстраиваются в очередь. Поэтому проект на три участка разумнее вести не одним куском на 20 недель, а тремя волнами по 7–9 недель: первая волна начинает давать эффект, пока идут остальные.
Шесть факторов, которые удлиняют проект
Эти шесть пунктов объясняют почти весь разброс между нижней и верхней границей вилки. Они складываются: два сработавших фактора спокойно превращают семинедельный проект в четырнадцатинедельный.
| Фактор | Добавляет | Как выглядит на практике | Чем снимается |
|---|---|---|---|
| Занятость владельца процесса | +5–15 дней | Вопрос висит по 3–4 дня, решения принимаются на общих совещаниях раз в неделю | Выделенные 3–4 часа в неделю и право решать без эскалации |
| Доступы к чужим системам | +5–20 дней | База 1С у стороннего подрядчика, оператор связи выдаёт доступ по заявке за 10 дней | Список доступов и ответственных собран до старта |
| Состояние данных | +5–25 дней | Дубли контрагентов, пустые обязательные поля, три написания одной номенклатуры | Выгрузить десять срезов и посмотреть их до подписания договора |
| Число согласующих | +3–5 дней на каждого сверх двух | Формы и формулировки ходят по кругу между отделами | Названный список согласующих и срок ответа в договоре |
| Изменения требований по ходу | +10–15 % к сроку этапа | После демонстрации появляется «а давайте ещё», и этап переоценивается | Процедура запроса на изменение и резерв времени в плане |
| Отпуска, сезонный пик, закрытие года | +5–10 дней | Ключевой пользователь в отпуске две недели, бухгалтерия недоступна в конце квартала | Календарь недоступности участников составлен на старте |
Самый недооценённый пункт — третий. Состояние данных выясняется обычно на четвёртой неделе, когда уже подписан договор и назван срок, и добавляет до пяти недель на чистку и сопоставление. При этом проверить его можно за один день до старта: выгрузить десять типовых срезов и посмотреть глазами. Что именно смотреть и на каких срезах — в статье данные перед внедрением.
Второй по коварности — четвёртый пункт, число согласующих. Он опасен тем, что растёт незаметно: сначала формулировку смотрит владелец процесса, потом «надо показать бухгалтерии», потом «юрист должен глянуть формулировку в письме клиенту», потом «а коммерческий директор в курсе?». Каждый новый участник добавляет 3–5 дней не потому, что он долго думает, а потому что круг согласования запускается заново после любой правки. Практическое лекарство — назвать список согласующих на старте, зафиксировать срок ответа в три рабочих дня и договориться, что молчание в этот срок считается согласием.
Горизонтальная диаграмма диапазонов: шесть строк, у каждой полоса от минимума до максимума добавляемых рабочих дней. Строки сверху вниз по максимуму: «Состояние данных — 5–25 дней», «Доступы к чужим системам — 5–20», «Занятость владельца процесса — 5–15», «Отпуска и сезонные пики — 5–10», «Число согласующих — 3–5 на каждого сверх двух», «Изменения требований — 10–15 % к сроку этапа». Слева от полос вертикальная опорная линия «базовый календарь 50 рабочих дней». Чертёжный стиль, подписи по-русски.
Что стоит одна неделя сдвига
Срок — это не про удобство, а про деньги, и считается он так же, как всё остальное. Модельный проект должен дать 210 000 ₽ экономии в месяц. Пока он не запущен, эта экономия не идёт, а команда заказчика продолжает тратить время на удержание проекта в живом состоянии.
Считать так стоит до старта, потому что этот расчёт меняет поведение. Когда сдвиг измеряется словами «ну, задержались на пару недель», выделить сотруднику четыре часа в неделю кажется дорогим. Когда он измеряется в 162 000 ₽, приоритеты выстраиваются сами.
Расчёт выше работает при одном условии: у проекта есть измеренная экономия, а не ожидание «станет удобнее». Если 210 000 ₽ в месяц взяты с потолка, то и 54 000 ₽ за неделю сдвига — цифра с потолка, и торопиться незачем. Поэтому замер процесса «до» и срок — связанные вещи: сначала считается эффект, потом становится понятно, сколько стоит промедление. Методика замера и перевода часов в рубли разобрана в статье о том, как посчитать окупаемость автоматизации.
Почему «за неделю» — это всегда одно из трёх
Обещание сделать автоматизацию процесса за неделю не является ложью — оно является умолчанием. Почти всегда за ним стоит один из трёх вариантов, и все три легко проверяются одним вопросом: «что именно будет работать в конце недели и с какими системами связано».
- 1Это демонстрация, а не внедрение. Настроенная коробка на демонстрационных данных действительно собирается за день. Ваши данные, ваши форматы и ваши интеграции в неё не входят, и именно они занимают недели.
- 2Это решение без интеграций. Бот отвечает клиентам, но не пишет в CRM; форма собирает заявки, но не создаёт сделку; отчёт красивый, но данные в него заносят руками. Такое действительно делается быстро и почти всегда требует переделки через месяц.
- 3Это работа, которую потом переделают. Разработка без обследования и без описания форматов идёт быстро ровно до первого столкновения с реальностью. Доля переделок в таких проектах — 25–40 % бюджета, и они возвращают календарь к тем же 8–14 неделям, но уже с испорченными отношениями.
Спросите: «Какие три вещи должны быть готовы с нашей стороны, чтобы этот срок был реальным?». Исполнитель, который действительно посчитал календарь, назовёт доступы, состояние данных и человека для согласований. Исполнитель, который назвал срок наугад, ответит, что «от вас ничего не потребуется» — и это самый надёжный признак будущего срыва.
Сравнение в две колонки. Левая, с пометкой «обычно это значит»: «Демонстрация на чужих данных», «Решение без интеграций — бот отвечает, но никуда не пишет», «Работа, которую переделают: 25–40 % бюджета». Правая, с пометкой «а вот это правда быстро»: «Уведомление о новой заявке — 1–3 дня», «Форма сайта в CRM по готовому коннектору — 2–5 дней», «Выгрузка отчёта по расписанию — 2–4 дня», «Телефония к CRM готовым модулем — 3–5 дней». Внизу общая подпись: «Признак быстрой задачи — одна система, одно событие, готовый коннектор, никакой чистки данных». Чертёжный стиль, подписи по-русски.
Что действительно можно сделать быстро
Быстрый старт — не миф, у него просто есть узнаваемые признаки: одна система, одно событие, готовый коннектор и отсутствие миграции данных. Вот задачи, которые честно укладываются в неделю и меньше.
- Уведомление о новой заявке в мессенджер, почту или чат отдела — 1–3 дня. Ловит самую массовую потерю: заявку, которую не увидели вовремя.
- Форма сайта → CRM через готовый коннектор, с записью источника и UTM-меток — 2–5 дней.
- Регулярная выгрузка отчёта по расписанию из учётной системы в таблицу или на почту руководителю — 2–4 дня.
- Подключение телефонии к CRM готовым модулем: карточка звонка, запись разговора, пропущенные в задачи — 3–5 дней.
- Автоответ и маршрутизация писем по правилам в одном почтовом ящике — 3–5 дней.
Такие задачи имеет смысл делать первыми и отдельно от большого проекта: они закрывают часть потерь уже на второй неделе и дают команде опыт совместной работы до того, как начнётся дорогая часть. Обратная сторона — они не решают проблему целиком, и продавать их как «автоматизацию отдела» нечестно. Список готовых связок и то, что за ними стоит, собран на странице интеграций.
Три действия заказчика, которые сокращают срок на три недели
Всё это делается до подписания договора и не требует ни денег, ни технических знаний. Суммарный эффект в модельном проекте — от 15 до 50 рабочих дней.
- 1Собрать шесть доступов заранее — экономит 5–10 рабочих дней
Минимальный список: учётная система (кто владелец базы и кто её поддерживает), CRM с правами администратора, почтовый домен, телефония, хостинг сайта, аккаунты внешних сервисов. По каждой позиции нужно имя человека, а не название отдела. Половина недельных простоев в проектах — это ожидание ответа от того, кто «где-то есть».
- 2Назначить владельца процесса — экономит 5–15 рабочих дней
Один человек, у которого есть 3–4 часа в неделю, знание процесса и право принимать спорные решения без вынесения на общее совещание. Не руководитель компании и не ИТ-специалист, а тот, кто отвечает за результат процесса. Без такого человека каждый вопрос подрядчика превращается в трёхдневную паузу.
- 3Выгрузить и посмотреть десять срезов данных — экономит 5–25 рабочих дней
Контрагенты, номенклатура, сделки за квартал, документы за месяц, справочник сотрудников, склады, цены, статусы, каналы обращений, история оплат. Смотреть надо на дубли, пустые обязательные поля и разные написания одного и того же. Это единственный способ узнать про пять недель чистки заранее, а не на четвёртой неделе проекта.
Верхняя граница сокращения — 50 рабочих дней — в реальности недостижима: она означала бы, что все три фактора сработали по максимуму одновременно, а это бывает только у компаний, где всё и так в порядке. Поэтому в планировании мы берём консервативные 15 дней и обсуждаем остальное как приятную неожиданность. Обратная логика тоже верна: если заказчик к моменту старта не сделал ни одного из трёх пунктов, календарь надо сразу называть по верхней границе вилки, а не по нижней — иначе через месяц разговор пойдёт про срыв срока, хотя срывать было нечего.
Две параллельные горизонтальные ленты. Верхняя подписана «Без подготовки — 10 недель, 50 рабочих дней», в ней видны светлые вставки-простои с подписями «ждём доступ», «ждём решение», «чистим данные». Нижняя подписана «С подготовкой — 7 недель», вставок-простоев в ней нет. На обеих лентах четыре одинаковые вертикальные отметки точек оплаты с подписями «20 % старт», «30 % прототип принят», «30 % внедрение принято», «20 % запуск». Справа скобка между концами лент с подписью «3 недели = 162 000 ₽». Чертёжный стиль, подписи по-русски.
Когда торопиться не надо
Сокращение срока — не всегда благо. Есть четыре ситуации, где попытка ускориться обходится дороже, чем спокойный календарь.
- Сезонный пик. Запускать систему в неделю максимальной нагрузки — значит гарантированно получить и сбой процесса, и отношение команды «нам это мешает работать». Разумнее сдвинуть запуск на две недели после пика, даже если всё готово.
- Неготовые данные. Ускорение за счёт пропуска чистки переносит проблему в эксплуатацию, где она стоит дороже: расхождения всплывают через месяц, доверие к системе теряется, и её начинают обходить.
- Нет времени на приёмку. Если у ключевых пользователей нет пяти дней на проверку по сценариям, срок сокращать нельзя — можно только перенести приёмку на боевой поток, а это уже не ускорение, а перенос риска на клиентов.
- Параллельно идёт другой проект. Два внедрения одновременно на одних и тех же людях не идут вдвое быстрее. Они идут втрое дольше каждый, потому что владелец процесса физически один.
И общее правило: срок, который нельзя объяснить составом работ, — это не срок, а обещание. Если исполнитель называет календарь, но не может разложить его хотя бы на шесть строк из таблицы выше, это значит, что он не считал, а угадывал. Проверять такой срок придётся вам, и проверка обойдётся в те самые 54 000 ₽ за неделю.
