Переход с 1С:ERP 2.4 на 2.5 за 43 дня: реальный кейс
Коротко: Машиностроительный завод (420 сотрудников, 180 рабочих мест в 1С) обновил 1С:ERP с релиза 2.4.13 на 2.5.15 за 43 календарных дня вместо изначально запланированных 6 месяцев (≈659 часов работ по первой оценке подрядчика). Секрет — отказ от «переписывания всех доработок сразу», перенос кастомизаций в расширения и параллельное тестирование на копии базы. Прямые затраты составили 1,3 млн рублей.
Главное из кейса
- 43 дня против 6 месяцев — за счёт замораживания доработок и переноса логики в расширения конфигурации, а не в основную.
- 1,3 млн рублей прямых затрат вместо первичной оценки в 3,8 млн — экономия 66%.
- 112 доработок в 2.4 после аудита сократили до 47 реально используемых — остальное признали «цифровым мусором».
- 0 дней простоя производства: переход провели в новогодние праздники, реальный переход занял 1 рабочий день.
- Окупаемость обновления — 9 месяцев за счёт нового блока адресного склада и производственного планирования 2.5.
Почему завод вообще решился на переход с 2.4 на 2.5?
Формальная причина банальна: фирма «1С» объявила о прекращении активной поддержки релизов ветки 2.4 — новые формы регламентированной отчётности, изменения в маркировке и прослеживаемости выходили уже только для 2.5. Бухгалтерия столкнулась с тем, что квартальную отчётность приходилось «докручивать» вручную, а специалист по маркировке жаловался, что обмен с «Честным ЗНАКом» периодически отваливается.
Но настоящая мотивация была глубже. За четыре года эксплуатации 2.4 конфигурация обросла 112 доработками разного качества. Часть из них делали три разных подрядчика, документация отсутствовала, а любое обновление типовой превращалось в двухнедельный марафон с ручным сравнением объектов. Финансовый директор посчитал, что поддержка «замороженной» устаревшей версии обходится дороже, чем контролируемый переход на актуальный релиз.
«Мы не обновлялись полтора года, потому что каждое обновление ломало то отгрузку, то расчёт себестоимости. В итоге сидели на релизе, который уже никто не сопровождал», — главный бухгалтер завода.
Что показал аудит: 659 часов из воздуха
Первый подрядчик, к которому обратился завод, оценил проект в 659 человеко-часов и 3,8 млн рублей со сроком 6 месяцев. Логика была прямолинейной: перенести все 112 доработок в новую конфигурацию 2.5 «один в один», протестировать каждую и запустить.
Второй подрядчик начал не с оценки, а с аудита реального использования доработок. Через журнал регистрации и анализ статистики за 12 месяцев выяснилось шокирующее:
- 47 доработок использовались регулярно и были критичны для процессов;
- 28 доработок дублировали функционал, который в 2.5 появился в типовой (адресное хранение, расширенное планирование производства, новые механизмы взаиморасчётов);
- 21 доработка не вызывалась ни разу за год — их писали «на всякий случай» или под сотрудников, которые давно уволились;
- 16 доработок были простыми печатными формами и отчётами, которые проще пересобрать на СКД, чем переносить.
Вывод оказался неожиданным: переносить нужно не 112, а 47 доработок. А значит, и объём работ падал в разы. Это классическая ситуация — подробнее о том, как правильно спланировать смену релиза, мы разбирали в материале про переход на новую версию 1С без остановки бизнеса.
Таблица: первичная оценка против фактической
| Параметр | Первичная оценка | Факт после аудита |
|---|---|---|
| Срок | 6 месяцев | 43 дня |
| Трудозатраты | 659 часов | 218 часов |
| Стоимость | 3,8 млн ₽ | 1,3 млн ₽ |
| Доработок к переносу | 112 | 47 |
| Простой производства | 2-3 дня | 0 дней |
Как разбили проект на этапы?
Ключевым решением стал отказ от подхода «большого взрыва». Вместо того чтобы 6 месяцев готовить всё и запускать разом, команда разбила проект на короткие итерации с ежедневными планёрками. Общая структура выглядела так.
Этап 1. Аудит и заморозка доработок (дни 1–7)
Помимо анализа использования доработок, ввели жёсткое правило: с момента старта проекта в базе 2.4 запрещены любые новые доработки. Все запросы бизнеса складывались в бэклог для реализации уже на 2.5. Это остановило «стрельбу по движущейся мишени» — главную причину срыва сроков в подобных проектах.
Этап 2. Развёртывание тестового контура (дни 8–12)
Создали полную копию рабочей базы и развернули на отдельном сервере чистую типовую 2.5.15. Все дальнейшие работы велись только на копии — рабочая база продолжала жить своей жизнью, производство не останавливалось ни на минуту.
Этап 3. Перенос доработок в расширения (дни 13–30)
Это сердце всего кейса. Из 47 доработок 39 удалось реализовать через расширения конфигурации, не трогая типовые объекты. Только 8 сложных механизмов (специфический расчёт себестоимости полуфабрикатов и интеграция со станочным оборудованием) потребовали изменений в основной конфигурации.
Этап 4. Тестирование и обучение (дни 31–40)
Ключевые пользователи от каждого подразделения прогоняли сквозные сценарии: от закупки материалов до отгрузки готовой продукции. Параллельно проводили обучение по новым возможностям 2.5.
Этап 5. Боевой переход (дни 41–43)
Переход назначили на новогодние праздники, когда производство стояло. Фактический перенос данных из рабочей 2.4 в подготовленную 2.5 занял один рабочий день.
Почему расширения оказались главным ускорителем?
Многие годы кастомизацию 1С делали через прямое изменение типовой конфигурации — «снимали с поддержки» объекты и правили их код. Это удобно в моменте, но превращает каждое будущее обновление в ад: конфигуратор при сравнении показывает сотни изменённых объектов, и разработчик вручную решает, какие изменения оставить.
Расширения работают иначе. Доработка живёт в отдельном файле-надстройке и не меняет типовую конфигурацию. Когда выходит новый релиз, основная конфигурация обновляется штатно в один клик, а расширение просто «прикладывается» сверху. Именно это позволило заводу в будущем обновляться внутри ветки 2.5 без привлечения подрядчика — своими силами.
Для критичных механизмов, которые невозможно вынести в расширение, использовали принцип минимального вмешательства: меняли не сами процедуры, а точки расширения (программные интерфейсы), которые фирма «1С» специально предусматривает для интеграций.
ВЫБРАТЬ
Номенклатура.Наименование КАК Наименование,
ЕСТЬNULL(ОстаткиНаСкладе.КоличествоОстаток, 0) КАК Остаток
ИЗ
Справочник.Номенклатура КАК Номенклатура
ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.ЗапасыНаСкладах.Остатки КАК ОстаткиНаСкладе
ПО Номенклатура.Ссылка = ОстаткиНаСкладе.Номенклатура
ГДЕ
Номенклатура.ЭтоГруппа = ЛОЖЬТакой отчёт остатков собирается на СКД за пару часов и не требует изменений в конфигурации — именно так пересобрали 16 «печатных» доработок из списка.
Сколько стоил переход и на чём сэкономили?
Финальный бюджет проекта распределился так:
| Статья затрат | Сумма, ₽ |
|---|---|
| Аудит и планирование | 140 000 |
| Перенос доработок в расширения | 620 000 |
| Тестирование и исправление | 310 000 |
| Обучение пользователей | 90 000 |
| Сопровождение первого месяца | 140 000 |
| Итого | 1 300 000 |
Главная экономия — 66% от первичной оценки — сложилась из трёх факторов: отказ от переноса ненужных доработок (минус 65 объектов), использование готового функционала 2.5 вместо кастомных механизмов и работа через расширения вместо ручного объединения конфигураций.
Отдельно стоит отметить: завод сознательно заложил бюджет на месяц сопровождения после запуска. Это дешевле, чем гасить пожары в авральном режиме. Похожую логику окупаемости мы разбирали в кейсе консолидации учёта в 1С:ERP для холдинга из 7 юрлиц.
Какие новые возможности 2.5 дали быструю отдачу?
Обновление окупилось за 9 месяцев не за счёт «галочки актуальности», а благодаря реальным улучшениям функционала.
- Адресное хранение на складе. В 2.4 кладовщики держали расположение в голове и в Excel. В 2.5 встроенный механизм ячеистого склада сократил время комплектации заказов на 22%.
- Расширенное планирование производства. Новые сценарии планирования позволили точнее рассчитывать потребность в материалах и снизить неликвиды на складе.
- Улучшенное казначейство. Обновлённый блок платёжного календаря помог финансовому отделу лучше управлять ликвидностью — тема, близкая к нашему разбору сокращения кассовых разрывов через БДДС в 1С:ERP.
- Стабильная маркировка. Обмен с системами прослеживаемости и «Честным ЗНАКом» в 2.5 работает надёжнее, что сняло головную боль с отдела логистики.
Какие ошибки чуть не сорвали сроки?
Кейс не был идеально гладким. Несколько моментов стоит знать заранее.
- Недооценили объём тестовых данных. На первом переносе выяснилось, что часть регистров содержит «мусорные» движения за 2019 год, которые тормозили конвертацию. Пришлось делать свёртку остатков.
- Сопротивление пользователей. Кладовщики привыкли к старому интерфейсу и первые дни саботировали адресное хранение. Помогли только личные наставники из числа ключевых пользователей.
- Забыли про внешние интеграции. Обмен с сайтом и системой СКУД тестировали в последнюю очередь и чуть не запустились без проверки. Урок: интеграции проверяют в первую очередь, а не в последнюю.
Опыт синхронной работы бизнеса и ИТ на подобных проектах хорошо описан в кейсе про ускорение согласования договоров в 1С:Документооборот — там тоже ключом к успеху стало вовлечение конечных пользователей.
Что можно повторить на своём предприятии?
Главный вывод кейса: срок и стоимость перехода определяются не сложностью новой версии, а качеством подготовки. Вот чек-лист, который сработал на заводе:
- Проведите аудит реального использования доработок — большинство окажется ненужными.
- Заморозьте новые доработки на время проекта.
- Максимум логики переносите в расширения, а не в типовую.
- Работайте только на копии базы, рабочую не трогайте до последнего дня.
- Планируйте боевой переход на выходные или праздники.
- Заложите бюджет на месяц сопровождения после запуска.
Если вы всё ещё сидите на 1С:УПП или совсем старом релизе, логика будет похожей, но объём работ больше — об этом отдельный разбор про переход с 1С:УПП на 1С:ERP в 2026 году.
Найдите специалиста для решения этой задачи на koderion.ru