Спрос на автоматизацию распределён по году неровно, и распределён он не случайно: он повторяет календарь отчётности и отпусков. Две выраженные волны — весенняя, март–апрель, и осенняя, сентябрь–октябрь. Между ними и после них — спад, в который у подрядчиков освобождаются люди, а у заказчика появляется шанс получить больше внимания за те же деньги.
Сразу о статусе этих утверждений. Публичного индекса загрузки подрядчиков в России не существует, и мы его не выдумываем. Всё, что ниже, — наблюдение, собранное из двух проверяемых вещей: календаря бухгалтерской и управленческой отчётности и обычного графика отпусков. Считайте это рабочей рамкой для планирования, а не отраслевой статистикой; датировано сентябрём 2026 года.
Практическая польза здесь одна и вполне денежная. Цена проекта в договоре от месяца старта почти не зависит, а срок запуска — зависит сильно. Дальше — из чего складываются волны, во что обходится попадание в пик и как считать обратный отсчёт от даты, к которой всё должно работать.
Две волны и что происходит с очередью
Весенняя волна поднимается тогда, когда у компании одновременно случаются две вещи: закрыт предыдущий год и утверждён бюджет на текущий. До этого момента разговор о проекте упирается в «дождёмся цифр», после — цифры есть, и становится видно, где именно процесс дорого стоит. Отсюда же берётся типичный весенний запрос — управленческая отчётность, которую собирали руками весь январь и февраль.
Осенняя волна другая по мотиву: она про «успеть». Люди вернулись из отпусков, до конца года остаётся квартал, неизрасходованный бюджет надо использовать. Запросы в этой волне короче и жёстче по срокам, и именно здесь чаще всего происходит подмена — трёхмесячный проект пытаются уложить в два месяца, потому что так удобнее календарю, а не процессу.
| Период | Что происходит у заказчика | Очередь у подрядчиков | Что разумно запускать |
|---|---|---|---|
| Январь–февраль | Закрытие прошлого года, бюджеты ещё не разморожены | Низкая | Обследование, наведение порядка в данных |
| Март–апрель | Год закрыт, бюджет утверждён, видно, где потери | Первая волна, пик | Проекты с длинным циклом — стартуют вовремя |
| Май–июнь | Праздники, начало отпусков, решения буксуют | Спад | Описание процессов, регламенты, пилот на узком куске |
| Июль–август | Отпуска и у заказчика, и у подрядчика | Самая низкая | Подготовка данных, обучение сотрудников, доработки |
| Сентябрь–октябрь | Все вернулись, хотят успеть к декабрю | Вторая волна, пик | Короткие проекты, укладывающиеся в один квартал |
| Ноябрь–декабрь | Закрытие года, во многих компаниях заморозка изменений | Падает к концу периода | Приёмка, документация, план на следующий год |
График по месяцам с января по декабрь. Ось X — месяцы, ось Y подписана «относительная загрузка команд, качественная шкала». Кривая имеет два подъёма: март–апрель и сентябрь–октябрь, провалы в январе-феврале и июле-августе, снижение в декабре. Пики подписаны «бюджет утверждён» и «успеть к концу года», провал июль–август — «отпуска». Под графиком обязательная пометка: «наблюдение по календарю отчётности, не измерение: публичной статистики загрузки нет». Чертёжный стиль, всё по-русски.
Что меняется в пик практически. Во-первых, сдвигается дата начала работ: команда занята, и старт назначают на первое свободное окно. Во-вторых — и это важнее — внимание команды делится между проектами. Формально у вас те же люди и тот же состав работ, но ответ на вопрос приходит не за час, а за день, а этап согласования регламента растягивается с двух недель до четырёх. В договоре это не отражается никак, в календаре — заметно.
Во что обходится попадание в пик
Считаем на модельном проекте: связка приёма заявок и учёта, 640 000 ₽ по договору, ожидаемый эффект после запуска — 120 000 ₽ в месяц. Цена в договоре одинаковая в марте и в июне. Разница только в двух строках календаря.
Отсюда неочевидный вывод для компании на 30–100 человек: выбор месяца старта — это финансовое решение того же порядка, что и выбор подрядчика. Если проект не привязан к внешней дате — требованию контрагента, сроку в законе, началу сезона продаж, — сдвиг старта на низкий сезон обычно выгоднее скидки, которую удастся выторговать в пик.
Обратный отсчёт от даты, к которой должно работать
Планировать от «когда начнём» — самая частая ошибка осенней волны. Планировать надо от «когда должно работать», и считать назад. Возьмём типовую цель: система работает с 1 января. Отсчитываем этапы в обратном порядке, порядок и содержание которых разобраны в материале про сроки проекта автоматизации.
- 1Опытная эксплуатация — 4–8 недель. Работа на реальных данных, разбор ошибок, правка инструкций. Отнимаем от 1 января: получаем начало ноября или начало декабря.
- 2Разработка и подготовка данных — 8–12 недель. Сборка, обмены, чистка справочников. Отнимаем ещё: середина августа или начало октября.
- 3Обследование, выбор подрядчика и договор — 3–5 недель. Описание процесса, оценка, согласование. Отнимаем последний кусок.
- 4Итого 15–25 недель работы. Старт должен приходиться на промежуток с начала июля до середины сентября — то есть решение принимается ещё в низкий сезон, до осенней волны.
Проверка обратной стороной даёт тот же ответ. Проект длительностью 3–5 месяцев, запущенный в октябре, заканчивается в январе-марте. К Новому году он не закрывается ни при каком усердии команды, и обещание обратного — повод насторожиться, а не обрадоваться. Честный ответ подрядчика в конце октября звучит так: до Нового года мы успеем обследование и часть разработки, запуск — в первом квартале.
Горизонтальная лента времени, читаемая справа налево. Крайняя правая отметка — «1 января: система работает». Влево три отрезка с подписями: «опытная эксплуатация 4–8 недель», «разработка и данные 8–12 недель», «обследование и договор 3–5 недель». Под ними скобка «15–25 недель». Слева заштрихованное окно с подписью «окно старта: начало июля — середина сентября». Отдельная пунктирная отметка «старт в октябре» со стрелкой, уходящей вправо за 1 января, и подписью «запуск в январе-марте». Чертёжный стиль, подписи по-русски.
У кого календарь свой
Общая картина ломается там, где у отрасли есть собственный высокий сезон. Правило здесь простое: изменения не вносят в систему, от которой в этот момент зависит выручка.
- Розница и интернет-магазины уходят в заморозку изменений примерно с середины октября и до конца января: перед пиковыми продажами и в них никто не трогает учёт, кассы и обмены. Их окно — февраль–июнь. Работы вроде прогнозирования запасов логично запускать сразу после закрытия сезона, когда есть свежие данные и нет риска.
- Транспорт и склады повторяют календарь розницы с небольшим опережением: у них пик приходит раньше, потому что товар едет заранее.
- Образование живёт учебным годом: окно для изменений — июнь–июль, а сентябрь для них не волна спроса, а самый занятой месяц.
- Общепит и услуги с записью зависят от локального сезона: у летних веранд и у горнолыжных сервисов затишье приходится на противоположные месяцы, и общее правило про июль тут не работает.
- Производство и оптовая торговля ближе всего к общей картине: у них календарь задаёт отчётность, а не сезон продаж.
Что имеет смысл делать в низкий сезон
Низкий сезон ценен не скидкой — скидки в инженерных проектах невелики. Он ценен тем, что именно в это время дёшево и быстро делаются этапы, которые в пик растягиваются больше всего, потому что упираются в людей заказчика, а не в подрядчика.
- Обследование и описание процесса. Требует времени сотрудников, а летом их проще собрать. Часть работы можно сделать своими силами — порядок описан в материале про аудит процессов своими силами.
- Наведение порядка в данных. Дубли контрагентов, разные написания номенклатуры, справочники в трёх версиях. Это самый недооценённый этап: он не требует подрядчика вовсе и при этом сокращает будущий проект на недели — подробности в материале о подготовке данных перед внедрением.
- Пилот на узком куске. Один процесс, один отдел, ограниченный объём. В спад под пилот легче получить внимание команды, а результат становится основанием для бюджета следующего года.
- Обучение и регламенты. То, что в пик всегда делается последним и наспех, летом делается спокойно и остаётся в компании.
Что из этого устареет первым и как это заметить
Первой сгладится осенняя волна, и причина будет не в моде, а в длине проектов. Чем короче типовой проект, тем слабее привязка к «успеть до декабря»: задачу на шесть недель можно запустить и в ноябре. Если типовые сборки продолжат повторяться и дешеветь, осенний пик будет размазываться на ноябрь и декабрь.
- Как заметить, что волна сгладилась: спросите у двух-трёх подрядчиков дату ближайшего свободного окна в конце сентября и повторите тот же вопрос в конце ноября. Если разница меньше двух недель — сезонность у них уже не выражена.
- Что устареет медленнее: весенняя волна. Она привязана к закрытию года и утверждению бюджета, а этот календарь не двигается вместе с технологиями.
- Что не изменится вовсе: обратный отсчёт от даты запуска и заморозка изменений перед сезоном продаж. Это свойства планирования и риска, а не рынка автоматизации.
- Признак, что рамка перестала работать у вас: если за последние два года ваши собственные проекты стартовали в случайные месяцы и это не мешало срокам — значит, ваш процесс не привязан к отчётности, и сезонность вам можно игнорировать.
Когда ждать низкого сезона не надо
Сезонность — аргумент для планирования, а не оправдание для откладывания. Четыре ситуации, в которых ждать июля прямо вредно.
- Процесс теряет деньги прямо сейчас. Если потеря измерена и составляет 100 000 ₽ в месяц, четыре месяца ожидания стоят 400 000 ₽ — больше, чем любой выигрыш от спокойного сезона. Считайте потерю, а не удобство календаря.
- Есть внешняя дата. Требование контрагента, изменение в правилах площадки, срок в договоре. Внешняя дата всегда сильнее внутреннего календаря, и подстраиваться приходится под неё.
- Задача укладывается в 4–6 недель. Короткий проект проходит и в пик: он занимает одно окно и не страдает от делённого внимания так, как трёхмесячный.
- Вы делаете подготовительную часть сами. Обследование и чистка данных не занимают ресурс подрядчика, поэтому их сезон не касается вовсе — начинать можно в любой месяц, а к разработке подойти уже подготовленным.
Считайте не месяц старта, а дату, к которой должно работать. Всё остальное — арифметика назад.
