Самая частая ошибка в споре "коробка 1С или самописная система" - сравнивать неподобное с неподобным.
Бизнесу кажется, что он выбирает между:
- «готовым решением»
- и «велосипедом с нуля»
Но в реальности выбор другой.
Выбирают не между 1С и чем-то ещё. Выбирают между:
- чужой логикой (в коробке)
- и своей логикой (в системе, написанной на той же платформе)
И это две принципиально разные модели.
Отсюда и разница в ожиданиях
Коробка - это не просто набор форм и документов, а еще и режим сопровождения: вендор обновляет функциональность, следит за совместимостью, закрывает часть регуляторных изменений.
Механизм расширений как раз создан для того, чтобы адаптировать типовое решение под конкретное внедрение и при этом сохранять поддержку от вендора. Платформа буквально описывает расширения как способ упростить адаптацию типовой конфигурации под нужды конкретного заказчика, а официальные материалы 1С отдельно подчеркивают, что при таком подходе стандартная конфигурация может сохранять исходную поддержку.
Иными словами, в 2026 году вопрос архитектуры - это уже не разговор про «старую добрую 1С», а про выбор стратегии внутри активно меняющейся платформы.
Почему коробка почти идеальное решение
Когда компания берёт типовую конфигурацию на 1С:Предприятие, она получает очень сильный старт
Внутри уже все есть и это не только документы и отчёты, а ещё и огромный слой «невидимой» работы:
- постоянный мониторинг законодательства
- обновления форм отчётности
- поддержка новых требований ФНС
- изменения по НДС, ККТ, маркировке
Все типовые конфигурации уже поддерживают:
- новые правила НДС (включая переходные изменения)
- обновления по маркировке товарных категорий
- изменения в алгоритмах обмена с контролирующими органами
Это снимает с бизнеса огромный объём операционных рисков.
И в этот момент кажется, что архитектурный вопрос вообще закрыт.
Зачем что-то изобретать, если всё уже работает?
Где начинаются сложности и коробка уже не помогает
Проблема появляется не в си стеме - а в несовпадении процессов.
Типовая конфигурация всегда строится на усреднённой модели: стандартная логика закупок, стандартная логика товародвижения, стандартные сценарии согласования.
И пока бизнес живёт в этой логике, всё работает быстро и стабильно.
Но как только появляются отклонения, начинается наращивание сложности:
расширения → доработки → обходные сценарии → ручные операции
И здесь важно понимать технический момент
Расширения в 1С действительно позволяют не ломать типовую конфигурацию и сохранять возможность обновлений, но они не меняют архитектуру базового решения.
То есть:
логика системы остаётся прежней, а бизнес начинает обрастать надстройками.
И со временем это превращается в сложную конструкцию, где:
- поведение системы трудно предсказать
- влияние изменений сложно оценить
- обновления требуют всё больше времени
Таким образом бизнес постепенно теряет скорость, любое изменение проходит через цепочку ограничений:
- как это впишется в типовую логику,
- не сломает ли обновления,
- как обойти существующие расширения.
В итоге решения принимаются не из позиции «как правильно для бизнеса»,
а из позиции «как это вообще можно реализовать в системе».
Система начинает влиять на бизнес сильнее, чем бизнес на систему.
Почему компании уходят в "кастом"
Кастомная система на базе той же 1С:Предприятие появляется в одном случае:
когда процессы бизнеса важнее, чем система.
Это почти всегда сложные контуры:
- закупки с длинным горизонтом планирования
- производство и разработка продукта
- PLM (жизненный цикл товара)
- сложная логика согласований
- нестандартное товародвижение
В таких сценариях коробка не ломается - она просто не подходит.
И бизнес начинает строить систему вокруг своих процессов, а не наоборот.
Как на самом деле растёт кастомная 1С-система
С инженерной точки зрения это не переписка системы с нуля, это постепенная эволюция:
сначала - MVP под конкретную задачу
потом - расширение функциональности
потом - добавление новых блоков
Через несколько лет получается монолитная система, которая:
- хранит большой объём данных
- обслуживает сотни пользователей
- объединяет несколько бизнес-контуров
Здесь появляется следующий архитектурный этап- монолит начинает делиться. Не из-за ошибок, а из-за нагрузки: разные процессы требуют разной скорости изменений, растёт количество разработчиков, увеличивается количество интеграций ...
В результате появляются отдельные системы:
- закупки
- согласования
- документооборот
- логистика
Таким образом строится полноценный корпоративный ландшафт.
Что важно понимать про архитектуру 1С
Платформа изначально рассчитана на работу в крупных компаниях и под серьёзную нагрузку:
- кластер серверов 1С
- поддержка полноценных баз данных, которые используют в крупных компаниях
- распределение нагрузки
- управление сеансами и ресурсами
- настройка прав и ограничений для безопасной работы
Учитывайте и отдельный момент - метаданные.
В 1С система описывается не только кодом, но и структурой:
- объекты данных
- права доступа
- интерфейсы
- поведение системы
Это делает кастомную систему полноценным продуктом, а не набором скриптов.
Также существует множество мифов против кастома, один из самых популярных - «это небезопасно».
На практике это не совсем так, платформа уже умеет:
- ограничивать доступ к файловой системе
- контролировать внешние соединения
- управлять правами на уровне кластера
Где главный риск кастома
Здесь ключевая точка.
Кастом - это не про технологии.
Это про ответственность.
В коробке часть задач закрывает вендор
А в кастоме всё происходит внутри команды:
- разработка
- тестирование
- релизы
- безопасность
- поддержка
И конечно же это требует зрелой команды, процессов и дисциплины.
Без этого кастом превращается в хаос быстрее, чем коробка.
Итог
В 2026 году спор «коробка или самописка» потерял смысл.
Правильный вопрос звучит иначе:
- где у вас стандарт
- а где уникальность
Коробка - там, где достаточна регуляторика и стабильность.
Своя система - там, где важна скорость и гибкость.
И если это разделение сделано правильно, система перестаёт быть проблемой - и начинает работать на бизнес.