Одна кнопка ценой всей системы
С 2026 года ERP-системы отнесены к объектам критической информационной инфраструктуры распоряжением Правительства № 360-р. Если ваша 1С обслуживает финансы, закупки, производство или логистику — она больше не «внутреннее дело компании». Категорирование, требования ФСТЭК, непрерывный мониторинг, штрафы до 1,5 млн рублей.
Но главная проблема — не в регуляторе. Она внутри компании. И звучит так: «А можно одну кнопку?» В 1С уже есть всё. Типовые конфигурации содержат готовые процессы для производства, логистики, розницы, финансов. Они протестированы и обновляются вендором. Но вместо того чтобы изучить, как это работает в системе, менеджеры требуют переписать под привычный процесс. По данным исследований, 80–90% так называемых «требований» — легаси-привычки, замаскированные под необходимость. «Хочу одной кнопкой», «уберите лишние поля», «а можно как раньше» — за этим стоит не бизнес-задача, а удобство конкретного человека, который не хочет менять способ работы.
Дальше — инженерия. Каждая такая доработка — прямое вмешательство в код типовых объектов: правка стандартных документов, регистров, форм без использования расширений. Конфигурация снимается с поддержки. При первом же обновлении такие правки либо теряются, либо ломают конфигурацию. Почему? Механизм обновления 1С заменяет типовые объекты новой версией. Если правка сделана прямо в типовом модуле, обновление пытается слить старую и новую версию построчно. Там, где изменения пересекаются, конфигуратор либо оставляет старый код — и теряются улучшения новой версии, либо подставляет типовой код поверх правок — и доработка исчезает. Это не баг. Это архитектурное следствие прямых модификаций. Отдельно — производительность. Самописные отчёты без оптимизации, запросы без индексов, обращение к большим таблицам «в лоб» ведут к зависаниям базы. RLS при неаккуратной настройке увеличивает время проведения документа с секунды до десятков секунд. Это не «тормоза». Это архитектурная ошибка под видом доработки.
Каждое следующее обновление — операция «на открытом сердце»: дни ручного сравнения конфигураций, риски нарушить бизнес-логику, зависимость от разработчиков, которые помнят историю правок. Обновление перестаёт быть рутиной и становится проектом со стоимостью, сопоставимой с внедрением. Результат: компании перестают обновляться.
И здесь — замкнутый круг. Требования КИИ и ФСТЭК предполагают, что система обновляется: патчи, компоненты, средства защиты. Но как это сделать, если база критически переписана? Чтобы соответствовать КИИ — нужно обновляться. Чтобы обновляться — снять доработки. Чтобы снять доработки — перестроить бизнес-процессы. Чтобы перестроить — признать, что «одна кнопка» не требование, а каприз.
Альтернатива — работа на неподдерживаемом ПО, без критических патчей, с прямым путём к киберугрозам. При этом регулятор хочет видеть живой процесс контроля, а не папку с документами годовой давности. Решается это не уговорами, а инженерной дисциплиной. Механизм расширений 1С:Предприятие 8.3 — архитектурный контракт: ядро конфигурации неприкосновенно, обновляется как единое целое, а кастомизация выносится в слой расширений.
Экономически: при прямых модификациях ключевая статья расходов — проект обновления, анализ и перенос правок. При расширениях центр затрат смещается на предварительную инженерную проработку: не допустить изменений в ядре. Это требует более высокой квалификации архитекторов, но окупается при каждом обновлении. Сначала — обучение, потом — доработка. Если функционал есть — используйте. Если кажется, что нет — разберитесь: возможно, он есть, но не там, где искали. И только если процесса действительно нет — обсуждать доработку через расширения, а не через правку типовых модулей. Тогда ядро обновляется как единое целое, технический долг не накапливается, требования КИИ выполнимы. И «одна кнопка» не становится ценой всей системы.
Коллеги, а как у вас? Сталкивались с тем, что «требование» оказывалось привычкой, а система уже умела это делать?
