Короткий ответ
Интуиция подсказывает: часть работы уже сделана, значит доделать дешевле, чем строить с нуля.
На практике часто дороже. Потому что перед тем, как строить правильно, нужно понять, что уже построено неправильно и почему, — а это отдельная работа, которой при внедрении с нуля просто не существует.
Формула та же, что при входе в чужой портал: сначала разбор, потом правка. Только здесь разбор оплачивает клиент, ожидавший, что готовое сэкономит ему деньги.
Откуда берётся разница в цене
При внедрении с нуля логика строится один раз, сразу правильно. Стадии продуманы, автоматизация выстроена под реальный процесс, документация ведётся по ходу.
При повторном внедрении к этой же работе добавляются три слоя, которых не было бы иначе:
- Разбор существующего. Прежде чем менять, нужно понять текущую логику — иначе правка ломает то, что работало.
- Решение, что наследовать, а что нет. Часть настроек логично оставить, часть — искажена и требует переделки. Это решение принимается по каждому элементу отдельно, не пакетом.
- Риск не увидеть скрытую связь. Даже тщательный разбор не гарантирует, что все зависимости найдены — часть проявляется только на правке.
Каждый из трёх слоёв — это время, а время в проекте — это цена.
Почему нельзя просто «использовать готовое»
Соблазн понятный: зачем строить заново то, что частично уже есть.
Работает это только если готовое сделано правильно. Если в основе искажения — 270 незакрытых бизнес-процессов, стадии без логики, права, розданные всем подряд, — унаследовать это без разбора значит унаследовать и ошибки. Тогда новый проект строится не на фундаменте, а поверх трещин.
Разбор перед использованием стоит времени ровно потому, что отличить рабочую настройку от искажённой на глаз нельзя — нужно проверять каждую.
Когда чинить дешевле, а когда — строить рядом
Однозначного правила нет, но есть ориентир.
Чинить дешевле, если искажения точечные, а логика существующего понятна: два-три неправильно настроенных элемента на фоне работающей системы.
Строить рядом дешевле, если искажения системные, а логику восстановить невозможно — настройки противоречат друг другу, никто не помнит зачем, документации никогда не было. В этом случае время на попытку разобраться превышает время на сборку заново, а результат разбора ненадёжен.
Оценить это можно только тем же разбором, который потом либо используется для правки, либо подтверждает, что правка нецелесообразна.
Кто платит за эту разницу
Клиент — и это стоит проговаривать до начала проекта, а не обнаруживать в процессе.
Разбор чужих ошибок — не накладные расходы подрядчика и не то, что должно быть «бесплатным, потому что мы же не с нуля начинаем». Это реальная работа с реальным временем, и она прибавляется к стоимости самой задачи.
Честная позиция здесь простая: сказать клиенту заранее, что повторное внедрение стоит дороже точечной доработки — не потому что подрядчик завышает цену, а потому что объём работы объективно больше.
Как снизить будущую цену переделки
Единственный способ, который реально работает, — не допустить ситуацию, а не чинить её постфактум.
Документация по ходу первого внедрения сняла бы весь первый слой затрат: следующему подрядчику не пришлось бы разбирать логику — он бы её читал. На практике её почти никогда не делают — не по умолчанию, а по отдельному запросу, обычно только на крупных внедрениях. Это осознанный выбор экономии на старте, который стоит понимать заранее: он означает, что цена возможной переделки в будущем выше.
Это не гарантия, что переделки не будет никогда. Но это гарантия, что переделка, если понадобится, обойдётся в разы дешевле — потому что самая дорогая часть работы, разбор чужого без карты, окажется уже проделанной.
Что проверить, если планируете смену подрядчика
- Есть ли документация от текущего внедрения. Если нет — заложите время и бюджет на её восстановление отдельной строкой.
- Спросите нового подрядчика, как он оценивает объём разбора, а не только объём самой задачи.
- Не сравнивайте цену повторного внедрения с ценой внедрения с нуля напрямую — это разные объёмы работы, даже если конечный результат похож.
- Требуйте документацию от нового подрядчика — чтобы следующая смена, если случится, не повторила ту же историю.
Если оцениваете, дешевле ли вам чинить существующий портал или строить рядом заново — разберём и посчитаем оба варианта.
Чтобы понять, что у вас на портале, — закажите аудит Битрикс24.