Короткий ответ: до примерно 29 % требований, которые нельзя закрыть настройкой, коробка с доработкой дешевле на горизонте трёх лет. После — дороже, и разрыв растёт быстрее, чем кажется, потому что дорожает не сама доработка, а её сопровождение. А за долей примерно в 40 % коробка перестаёт быть коробкой: вы платите вендору за продукт, которым больше не пользуетесь в исходном виде.
Модельная задача дальше по тексту: отраслевая система на 40 рабочих мест для сервисной компании. Коробка стоит 620 000 ₽ лицензий, 480 000 ₽ внедрения и настройки и 35 000 ₽/мес поддержки вендора; разработка с нуля — 2 600 000 ₽ и 55 000 ₽/мес сопровождения. Все суммы — порядок величин на сентябрь 2026 года, вилка по рынку широкая: коробка с кастомизацией начинается примерно от 500 000 ₽ при 15 000–80 000 ₽/мес, комплексная разработка — примерно от 1 500 000 ₽.
Два порога, которые постоянно смешивают
Когда говорят «после какой-то доли доработок коробку проще выкинуть», обычно имеют в виду сразу две разные величины, измеряемые в разных знаменателях. Разделять их полезно, потому что они срабатывают в разные моменты и лечатся по-разному.
| Порог | Что измеряется | Где срабатывает | Что происходит при превышении |
|---|---|---|---|
| Около трети | Доля переделанной типовой функциональности продукта | На обновлениях вендора | Каждое обновление превращается в отдельный проект с повторной приёмкой, а не в штатную процедуру |
| Около 29 % | Доля требований, закрываемых кодом, а не настройкой | В деньгах на трёхлетнем горизонте | Коробка перестаёт быть дешевле разработки: платите и за неиспользуемое типовое, и за свой код |
| Около 40 % | Та же доля требований, но как признак продукта | В организации работы | Документация вендора перестаёт описывать вашу систему, опыт новых сотрудников не переносится, поддержка вендора отвечает «это ваша доработка» |
Первый порог мы разбирали со стороны обновлений в материале обновление 1С после доработок: там счёт растёт не от сложности правок, а от числа изменённых типовых объектов. Второй и третий — предмет этой статьи. Отдельный разбор двух смет рядом с матрицей выбора по четырём признакам есть в материале коробка с доработкой или разработка с нуля: что дешевле; здесь мы смотрим на ту же развилку со стороны жизненного цикла продукта, а не разовой сметы.
Разложить требования до старта: три корзины
Долю доработок можно оценить до подписания договора и без подрядчика — за один рабочий день с руководителями подразделений. Метод простой: берётся список требований к системе и каждое кладётся в одну из трёх корзин.
- 1Штатное
Работает из коробки без настройки. Проверяется на демонстрации: попросите показать это требование на живом стенде, а не в списке возможностей. Если показывают на слайде — это не первая корзина.
- 2Настраиваемое
Закрывается штатными средствами конфигурирования: справочники, роли, статусы, шаблоны, поля, отчёты в конструкторе. Ключевой признак — правку переживает обновление вендора, потому что она лежит в данных, а не в коде.
- 3Требующее кода
Всё остальное: своя логика расчёта, свои документы, свои проверки, интеграция, которой нет в готовом виде. Именно эта корзина считается в процентах, и именно она определяет и деньги, и обновляемость. Считать надо по числу требований, а не по их субъективной важности — иначе доля всегда выходит маленькой.
Просите подрядчика разложить ваш же список по тем же трём корзинам независимо и сравните результаты. Расхождение больше чем на 10 процентных пунктов означает, что одна из сторон не поняла требования, — и это дешевле выяснить сейчас, чем на приёмке. Как читать получившуюся смету дальше, разобрано в материале как читать смету на автоматизацию.
Схема: слева блок «список требований к системе», от него три стрелки к трём подписанным корзинам — «штатное», «настраиваемое», «требующее кода». Под каждой корзиной пояснение в одну строку: «работает из коробки», «лежит в данных, переживает обновление», «лежит в коде, переносится руками». Под третьей корзиной шкала с тремя отметками «15 %», «29 %», «40 %» и подписями «коробка дешевле», «паритет», «коробка перестаёт быть коробкой». Чертёжный стиль, приглушённая палитра, подписи по-русски.
Что происходит при обновлении вендора
Это главная строка, которой нет в коммерческих предложениях. Вендор выпускает релизы — обычно два-четыре в год, — и часть ваших правок при этом надо переносить заново. Переживают обновление не «простые» правки, а те, что лежат вне изменённого вендором кода.
| Тип правки | Переживает обновление | Почему |
|---|---|---|
| Справочники, роли, статусы, шаблоны документов | Да | Лежит в данных, вендор их не трогает |
| Отчёты, собранные в штатном конструкторе | Обычно да | Опирается на типовые объекты, ломается только при их переименовании |
| Логика в расширении, не меняющем типовой объект | Чаще да | Вендорский код остаётся нетронутым, расширение подключается сверху |
| Изменённый типовой объект | Нет | Вендор выпускает свою версию того же объекта, ваши правки надо накладывать заново |
| Своя логика внутри типового процесса | Нет | При изменении процесса вендором правка теряет смысл и переписывается |
| Интеграция через внешний слой | Да | Живёт вне продукта и зависит только от неизменности контракта обмена |
Практический вывод: стоимость владения определяется не объёмом доработок, а тем, в какой строке этой таблицы они лежат. Одна и та же функция, сделанная расширением и сделанная правкой типового объекта, стоит одинаково при внедрении и в разы по-разному в сопровождении. Спрашивать подрядчика надо не «сколько будет доработок», а «сколько типовых объектов вы измените» — это единственный вопрос, ответ на который предсказывает счёт за обновления.
Три года: 4 010 000, 4 878 000 и 5 560 000 ₽
Считаем коробку при трёх долях доработок и разработку с нуля на том же горизонте. Перенос доработок считаем по три релиза в год: 15 часов на релиз при 15 % доработок, 29 часов при 29 % и 40 часов при 40 % — по ставке инженера 3 000 ₽/час. Число часов на релиз здесь почти совпадает с долей доработок в процентах, и это не подгонка, а следствие того, что и то, и другое растёт от одного и того же — количества изменённых типовых объектов.
| Доля требований, требующих кода | Вход: лицензии, внедрение, доработки | Перенос доработок за 3 года | Всего за 3 года | Против разработки |
|---|---|---|---|---|
| 15 % | 1 625 000 ₽ | 405 000 ₽ | 4 010 000 ₽ | Коробка дешевле на 894 000 ₽ |
| 29 % | 2 115 000 ₽ | 783 000 ₽ | 4 878 000 ₽ | Паритет |
| 40 % | 2 500 000 ₽ | 1 080 000 ₽ | 5 560 000 ₽ | Коробка дороже на 656 000 ₽ |
В строках коробки во всех трёх вариантах одинаково сидят поддержка вендора 35 000 ₽/мес и развитие 20 000 ₽/мес — вместе 1 980 000 ₽ за три года, ровно столько же, сколько сопровождение своей системы. Это не совпадение: сопровождать надо и то, и другое, и экономии здесь не возникает ни в одном варианте.
График: горизонтальная ось — доля требований, требующих кода, от 0 до 50 %; вертикальная — стоимость владения за три года в рублях. Наклонная линия «коробка с доработкой» проходит через точки 15 % → 4 010 000 ₽, 29 % → 4 878 000 ₽, 40 % → 5 560 000 ₽. Горизонтальная линия «разработка с нуля» на уровне 4 904 000 ₽. Точка пересечения на 29 % подписана «денежный паритет». Вертикальная штриховая линия на 40 % подписана «коробка перестаёт быть коробкой». Чертёжный стиль, подписи по-русски.
И ещё одна деталь, которая ломает расчёты чаще всего: доля доработок не остаётся постоянной. По нашим проектам она растёт на 5–10 процентных пунктов за первые полтора года эксплуатации — просто потому, что после запуска становятся видны требования, о которых до старта не думали. Значит, планировать надо не от той доли, которую вы насчитали сегодня, а от неё же плюс десять пунктов: расклад в 25 % через полтора года превращается в 35 %, а это уже другая сторона от точки паритета.
Что теряется при разработке и в чём оба пути одинаково слабы
Разработка с нуля покупается не деньгами, а сроком и отсутствием чужого опыта. Четыре вещи, которые в коробке есть по умолчанию и которые придётся делать самим.
- Готовые роли, права и типовые сценарии. В коробке кто-то уже придумал, что видит кладовщик и что бухгалтер. В своей системе это проектируется с нуля, и первый год уходит на отладку случаев, которые в готовом продукте давно прошли другие компании.
- Обновления под изменения законодательства. Печатные формы, форматы обмена, требования маркировки меняются, и в коробке это приходит с релизом. В своей системе каждое такое изменение — задача с оценкой и сроком.
- Доступные специалисты. Человека, знающего распространённую коробку, можно нанять; человека, знающего вашу систему, нельзя — его можно только вырастить. Это удлиняет замену подрядчика и повышает цену выхода.
- Сообщество и чужие ответы. Типовая проблема в популярном продукте уже кем-то описана. В своей системе любой вопрос решается с нуля, и это ощутимо на второй год эксплуатации, когда первоначальная команда меняется.
И три вещи, в которых оба пути одинаково беспомощны, — их часто приписывают выбору, хотя они от него не зависят вовсе. Первое: неописанный процесс. Система любой природы автоматизирует то, что есть; если правила меняются каждый месяц, переделываться будут и настройки, и код. Второе: качество данных. Дубли номенклатуры и контрагентов переезжают в обе стороны и одинаково портят отчёты. Третье: люди, которые не хотят пользоваться. Ни коробка, ни своя разработка не решают вопрос принятия — он решается регламентом и участием руководителя, и подробнее это разобрано в материале коробка под несуществующий процесс.
Цена ошибки и когда не надо ни того, ни другого
Ошибка в сторону коробки обнаруживается на второй год: доля доработок выросла с обещанных 20 % до 45 %, обновления встали, вендор отвечает «это ваша доработка». Переход на свою систему в этот момент стоит полной цены разработки — 2 600 000 ₽, — и деньги, вложенные в лицензии и доработки, не возвращаются. Итого путь через ошибку обходится в 2 500 000 ₽ входа плюс 2 600 000 ₽ разработки, то есть 5 100 000 ₽ вместо 2 600 000 ₽ сразу.
Ошибка в обратную сторону дешевле, но обиднее: заказали своё там, где хватило бы настройки коробки. Здесь теряется разница входа — 2 600 000 ₽ против 1 625 000 ₽, то есть 975 000 ₽, — и три-четыре месяца срока. Именно поэтому расклад требований по трём корзинам делается до договора, а не после: он стоит один день работы и страхует от суммы, которая в тысячу раз больше.
Две горизонтальные полосы разной длины. Верхняя «выбрали коробку, доля доработок выросла до 45 %»: два сегмента — «вход в коробку 2 500 000 ₽» и «разработка заново 2 600 000 ₽», итог «5 100 000 ₽ вместо 2 600 000 ₽». Нижняя «выбрали разработку там, где хватило бы настройки»: один сегмент «переплата входа 975 000 ₽» и подпись «плюс три-четыре месяца срока». Между полосами подпись «расклад требований по трём корзинам стоит один день». Чертёжный стиль, приглушённая палитра, подписи по-русски.
Если процесс не описан и правила меняются от месяца к месяцу, любые вложения будут переделываться вместе с ними, и переделка кода стоит одинаково дорого в обоих вариантах. Признак простой: задайте вопрос «кто принимает решение на этом шаге и по какому правилу» по пяти ключевым шагам процесса. Если по двум и больше ответа нет или он у разных людей разный, сначала описывается процесс, и только потом сравниваются сметы. Это единственная работа в списке, которая стоит ноль рублей и почти всегда пропускается.
И третий путь, который на практике выигрывает чаще двух чистых: типовое ядро на массовые задачи плюс собственный тонкий слой на тот участок, который есть только у вас. Он позволяет держать долю переделок типового кода около нуля — а значит, сохранить штатные обновления — и при этом закрыть требования, ради которых затевалась вся история. Разбор такой схемы с числами есть в соседних материалах о выборе между готовым SaaS и заказной разработкой и об отраслевой коробке против разработки.
Спрашивайте подрядчика не «сколько будет доработок», а «сколько типовых объектов вы измените». Первый ответ говорит о цене внедрения, второй — о цене владения.
