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