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