Поддержка 1С в 2026 году: что изменится в бюджетах и на кого делать ставку

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

Мы в K2 Cloud ежегодно  работаем с десятками таких кейсов, от небольших компаний до крупных холдингов. В этой статье обсудим, что стоит знать перед согласованием бюджета на поддержку 1С в 2026 году: куда движется рынок, как выбрать модель без переплаты и какие вопросы задать подрядчику на старте, чтобы не расплачиваться за ошибки первые два месяца сотрудничества.

По нашим данным рынок облачного 1С в 2025 году вырос на 10-30%, а спрос на специалистов по 1С —  в полтора-два раза. Годом ранее мы делали такой прогноз, и он подтвердился полностью. Драйверы прежние: санкции и импортозамещение никуда не денутся и в 2026 году. 1С давно не просто учетная система, а целая экосистема с отраслевыми решениями и огромной базой обученных пользователей. Поэтому реальной альтернативы на горизонте нескольких лет у большинства компаний просто нет.

К этому добавился новый фактор – подорожало железо. Intel сокращает производство процессоров для части линеек серверов и ПК, из-за чего усиливается дефицит и растут цены. SSD-накопители подорожали настолько, что сейчас стоят в 16 раз больше жестких дисков, и цена продолжает увеличиваться. Стоимость оперативной памяти с декабря выросла в два-четыре раза, в январе-феврале рост ускорился. Даже разовые поставки серверных компонентов идут с ощутимой наценкой и без гарантии сроков.

Для бизнеса это значит простую вещь: вложения в собственную инфраструктуру под 1С в 2026 году становятся более дорогими и менее предсказуемыми, чем год назад. Именно поэтому размещение 1С в облаке все чаще выигрывает у собственных серверов не за счет технологического превосходства, а потому что капитальные затраты превращаются в операционные, что легче для бизнеса в условиях нестабильной экономической ситуации.

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

Если коротко сформулировать основные тенденции рынка, получится три дефицита, из-за которых решение о поддержке 1С давно вышло за рамки чисто технического вопроса:

• дефицит бюджета —  резкого роста ИТ-бюджетов никто не ждет, значит вся стратегия строится вокруг эффективности, а не расширения штата;

• дефицит экспертизы —  специалист должен одновременно понимать отраслевую специфику (металлургия, ритейл, банки) и работать с несколькими по-разному настроенными конфигурациями, не раздувая при этом расходы;

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

Самая частая управленческая ошибка кроется не в самой модели поддержки, а в том, что ожидания не совпадают с ее условиями. Компания выбирает почасовую оплату (Time & Material) ради экономии, но при этом рассчитывает на фиксированный SLA и выделенную команду, как при контракте с фиксированной стоимостью. Такое несовпадение почти гарантированно приводит к недовольству с обеих сторон, а в итоге к расторжению договора и поиску нового поставщика услуг, то есть к двойным издержкам.

1. Фиксированная поддержка с гарантированным SLA подходит зрелому бизнесу, где ИТ-функция уже оформлена в самостоятельный блок, а зоны ответственности по системам и инфраструктуре четко разграничены. Это понятный бюджет, прогнозируемое количество часов и предсказуемый порядок обработки заявок, включая обновления, которые чаще всего идут в нерабочее время.

2. Почасовая оплата (T&M) закрывает ситуации, когда нагрузка неравномерна и внутри компании некому передать пиковые задачи, например, разовую помощь бухгалтерии в поиске ошибки при закрытии периода. Для небольшого и среднего бизнеса это способ не раздувать ИТ-бюджет, при этом можно негласно договориться  о скорости реакции на заявку, даже если формального SLA в договоре нет.

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

По нашему опыту, объем поддержки чаще всего укладывается в один из четырех пакетов, от 30 до 300 часов в месяц в зависимости от нагрузки, хотя перечень открыт и всегда кастомизируется под конкретный бизнес.

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

Вот пять пунктов, которые стоит закрыть до подписания договора.

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

2. Описание процессов поддержки. Без формализованных процессов новый подрядчик в первые недели работает вслепую, а значит риск ошибок и простоев в этот период выше.

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

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

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

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

Опрашивая ИТ-руководителей, мы задавали прямой вопрос: что болит сильнее всего при передаче поддержки на аутсорсинг. Голоса разделились практически поровну между четырьмя вариантами: невыполнение SLA, сложность коммуникации, непрогнозируемые расходы на техподдержку и недостаток компетенций в текущей команде.

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

Отдельно стоит отметить интересную динамику спроса. Еще недавно фокус заявок был смещен в сторону консультаций по работе с 1С и рутинного администрирования. Сейчас заметно растет доля заявок на доработку функциональности. Это косвенный индикатор того, что бизнес не стоит на месте, а внутренняя ИТ-служба наладила диалог с бизнес-подразделениями и получает от них запрос на развитие, а не только на устранение сбоев.

• Крупный оператор при банке. Задача —  усилить внутреннюю команду в пиковые периоды нагрузки по модели почасовой оплаты, где объем и условия заранее понятны. Внешняя команда сработала как дополнительный ресурс, который не дал перегрузке перерасти в инцидент.

• Крупная транспортная компания. Формально почасовая оплата не предполагает SLA, но заказчик рассчитывал на подхват заявки в течение четырех часов. Вместо формального отказа стороны пересмотрели условия сервиса без дополнительных издержек для заказчика. Результат: рост удовлетворенности и числа заявок. Гибкость в переговорах на старте обходится дешевле, чем потеря клиента и повторный тендер.

• Благотворительная организация. Фиксированный пакет поддержки с понятным объемом часов оказался золотой серединой между полноценным сервисом и почасовой оплатой. Приоритетные задачи закрывались в рамках купленного пакета, а бюджет оставался предсказуемым.

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

Универсального рецепта нет. Распределение всегда строится от доступного внутреннего ресурса. На практике работают три сценария.

• Сильная внутренняя команда. Если инженеры в штате уверенно держат инфраструктуру, отдавать поддержку на сторону не нужно, это скорее усложнит процесс. Внешний подрядчик подключается точечно, по почасовой оплате, на пиковые периоды.

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

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

• Соответствует ли выбранная модель (T&M, фикс, гибрид) реальной предсказуемости нагрузки, или бизнес платит за одни условия, а рассчитывает на другие?

• Знает ли подрядчик календарь релизов и периоды заморозки изменений до подписания договора?

• Какая цель передачи системы на поддержку? На чем должен фокусироваться подрядчик: поддержка системы в стабилизированном состоянии или тушение пожаров?

• Заложено ли в SLA время восстановления на уровне приложения, а не только время подъема инфраструктуры хостинг-провайдера?

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

• Готовы ли обе стороны пересматривать условия договора на основе  накопленного опыта, а не держаться первоначальных договоренностей любой ценой?

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