Счёт за обновление доработанной 1С определяется одной величиной — числом изменённых типовых объектов. Не сложностью бизнес-логики, не количеством пользователей и не объёмом базы. Платформа при обновлении сравнивает вашу конфигурацию с новой типовой, и каждый объект, который вы трогали, попадает в список ручного разбора. В модельном примере ниже таких объектов 34, и одно плановое обновление стоит 40 часов работы — 140 000 ₽ по ставке 3 500 ₽/час.
Неприятная особенность этого счёта в том, что он растёт сам, без вашего участия. Каждая новая доработка добавляет объектов в список сравнения, и одновременно вендор в очередном релизе меняет ровно те же самые популярные документы и справочники, которые правили вы. Через три года обновление стоит вдвое дороже, чем в первый год, хотя система работает так же.
Хорошая новость: счёт управляемый, и уменьшают его четыре решения, каждое из которых принимается до разработки, а не после. Ниже — механика счёта, регламент безопасного обновления и то, что происходит с обменами в окне простоя, потому что именно там чаще всего теряются данные.
Из чего складывается счёт за обновление
Модельная компания: 1С:УТ 11, 40 пользователей, конфигурация развивается три года силами разных исполнителей. Накопилось 34 изменённых типовых объекта — документы, справочники, несколько общих модулей и три отчёта. Конфигурация снята с поддержки. Вендор выпускает три релиза в год; компания обновляется на каждый, потому что в них приходят изменения по отчётности, маркировке и ЭДО.
Обратите внимание на вторую строку. Разбор конфликтов — это не ошибки исполнителя, а неизбежность: вендор развивает свою конфигурацию и правит те же самые популярные объекты, что и вы. Чем больше пересечение, тем больше часов. Именно поэтому доработка документа реализации обходится дороже, чем доработка редкого справочника, хотя по объёму кода они сопоставимы.
Почему счёт растёт с каждым годом
Компания редко замечает рост, потому что счета приходят раз в несколько месяцев и от разных подрядчиков. Собранные вместе, они выглядят так.
| Год жизни системы | Изменённых типовых объектов | Часов на одно обновление | Цена одного обновления |
|---|---|---|---|
| Первый | 12 | 18 часов | 63 000 ₽ |
| Второй | 22 | 28 часов | 98 000 ₽ |
| Третий | 34 | 40 часов | 140 000 ₽ |
Три причины роста складываются друг с другом. Первая — количественная: объектов становится больше, а сравнение линейно зависит от их числа. Вторая — пересечение с планами вендора: чем дольше живёт конфигурация, тем выше вероятность, что очередной релиз затронет именно ваш объект. Третья — потеря знания: исполнителей сменилось двое, комментариев в коде нет, и часть часов уходит не на работу, а на выяснение, зачем эта правка вообще была сделана.
Режим, в котором конфигурация перестаёт автоматически сравниваться с типовой конфигурацией вендора. До снятия обновление полуавтоматическое: платформа показывает, что изменилось у вендора, и предлагает объединить. После — сравнение и объединение делаются вручную, а объём регрессионного тестирования вырастает, потому что затронуть может что угодно. Обратный путь формально существует, фактически стоит как повторная разработка, поэтому строка «снимаем с поддержки» в смете обсуждается отдельно, а не проходит технической деталью.
Столбиковая диаграмма из трёх столбцов по годам, ось Y в рублях от 0 до 150 000. Столбцы: «Первый год — 12 объектов, 18 часов, 63 000 ₽», «Второй год — 22 объекта, 28 часов, 98 000 ₽», «Третий год — 34 объекта, 40 часов, 140 000 ₽». Поверх столбцов пунктирная восходящая линия с подписью «рост без единого нового требования». Справа выноска: «при трёх релизах в год — 420 000 ₽ в третьем году». Чертёжный стиль, подписи по-русски.
Пропуск релизов даёт видимую экономию и невидимый долг. Вы перестаёте получать изменения по отчётности, маркировке и форматам ЭДО, а накопленный разрыв версий делает следующее обновление дороже, чем все пропущенные вместе взятые: сравнивать придётся не с соседним релизом, а с версией годичной давности, где вендор успел переписать целые подсистемы. Практический предел, после которого обновление превращается в отдельный проект, — примерно год без обновлений.
Четыре решения, которые режут счёт вдвое
Все четыре принимаются на этапе постановки задачи и стоят почти ничего. После того как доработка сделана внутри типовых объектов, вернуть эти деньги можно только переписыванием.
- 1Расширения вместо правки типовой
Каждая доработка, переехавшая в расширение, уходит из списка ручного сравнения. Что через расширение делается, а что нет, мы разобрали в материале о расширениях 1С и БСП простыми словами. Требовать расширение стоит везде, где это технически возможно, даже с наценкой на разработку в 10–15 %.
- 2Вынос логики во внешний контур
Расчёты, уведомления, аналитика и всё, что связано с внешними каналами, не должны жить внутри учётной базы вообще. Обновление их не касается — проверяется только контракт данных. Полный расчёт этой развилки на три года — в статье о том, что выбрать: доработку 1С или внешнюю интеграцию.
- 3Постоянная тестовая база, а не разовая копия
Копия базы, развёрнутая из вчерашнего бэкапа и живущая всегда, превращает тестовый прогон из исследования в процедуру. Она же нужна для приёмки доработок и для разбора инцидентов. Стоимость — место на диске и полчаса на автоматическое обновление копии по расписанию.
- 4Реестр доработок и чек-лист проверок
Один документ: какой объект изменён, зачем, кем, что проверить после обновления. Он превращает шестичасовой прогон «на глазок» в пятичасовой прогон по списку и, что важнее, позволяет сменить подрядчика без потери знания. Отсутствие реестра — главная причина, по которой третий год дороже первого.
Двадцать часов — не идеал, а реалистичный результат: восемь изменённых типовых объектов остаются, потому что часть учётной логики выносить наружу неправильно. Ноль часов не бывает даже на чистой типовой конфигурации: проверять работу критичных участков после обновления надо в любом случае, и это те самые 3–5 часов, которые входят в нормальное сопровождение.
Сравнение двух вертикальных столбиков, разбитых на подписанные сегменты, ось в часах от 0 до 40. Левый столбик «Как есть — 40 часов, 140 000 ₽»: сравнение 17 ч, конфликты 9 ч, тестовый прогон 6 ч, окно 4 ч, первые сутки 4 ч. Правый столбик «После четырёх решений — 20 часов, 70 000 ₽»: сравнение 4 ч, конфликты 4 ч, тестовый прогон 5 ч, окно 3 ч, первые сутки 4 ч. Под столбиками подпись «изменённых типовых объектов: 34 против 8». Справа выноска «210 000 ₽ экономии в год при трёх релизах». Чертёжный стиль, подписи по-русски.
Регламент обновления: окно, чек-лист и план отката
Дорого стоит не само обновление, а неудачное обновление. Регламент ниже занимает один лист и снимает большую часть таких случаев; его стоит согласовать с подрядчиком письменно до первого релиза, а не после инцидента.
| Этап | Когда | Что делается | Результат для заказчика |
|---|---|---|---|
| Уведомление о релизе | За 7–10 дней | Подрядчик сообщает дату и состав изменений вендора, вы согласуете окно | Дата в календаре, а не звонок в пятницу вечером |
| Прогон на копии | За 2–5 дней | Обновление на постоянной тестовой базе, проверка по чек-листу критичных операций | Список найденных расхождений до того, как они стали вашими |
| Полный бэкап и стоп-флаг обменов | За 30–60 минут до окна | Резервная копия рабочей базы, остановка обменов флагом, а не выключением задания | Точка возврата и накопление данных вместо их потери |
| Боевое обновление | В согласованном окне | Объединение конфигураций, запуск обработчиков обновления, контрольные операции | Обновлённая база и отметка о времени окончания |
| Догон обменов и сверка | Сразу после окна | Обмены включаются, очередь разбирается, сверяется число документов за окно | Подтверждение, что за время простоя ничего не потерялось |
| Сопровождение первых суток | 24 часа | Повышенное внимание к обращениям пользователей, быстрый разбор мелочей | Проблемы всплывают на второй день, а не на закрытии месяца |
Восстановление из резервной копии означает потерю всей работы, сделанной после начала окна, и в рабочее время это неприемлемо. Рабочий план отката отвечает на три вопроса письменно: до какого момента времени мы ещё можем откатиться без потерь, кто принимает решение об откате и по какому признаку, и что делает бухгалтерия и склад те два часа, пока откат идёт. Если ответов нет, обновление в рабочее время делать нельзя — только в нерабочее окно, где цена ошибки измеряется часами, а не деньгами.
Что происходит с интеграциями в окне обновления
Это место, где чаще всего теряются данные, и теряются тихо. Внешние системы про ваше окно не знают: сайт продолжает принимать заказы, маркетплейс — присылать отправления, банк — выгружать выписку. Что с ними будет, зависит от механизма обмена: способы обмена с 1С ведут себя в этой ситуации по-разному, и знать это надо до окна, а не после.
- 1Останавливайте обмен флагом, а не выключением регламентного задания. Выключенное задание после обновления забывают включить, и обмен стоит неделю. Флаг «обмен приостановлен» виден в интерфейсе и попадает в мониторинг.
- 2Проверьте, что данные копятся, а не теряются. Планы обмена держат изменения зарегистрированными до подтверждения приёма. Обмен через OData или HTTP-сервисы без собственной очереди в момент недоступности базы просто получает ошибку — и если очередь повторов не заложена в проект, порция уходит в никуда.
- 3Договоритесь с внешней стороной об окне заранее там, где это возможно. С сайтом и своим сервисом — можно; с площадками и банком — нет, поэтому у них порция обязана догоняться после включения.
- 4Сверяйте после окна не «зелёный статус», а числа. Сколько заказов пришло на сайт за окно и сколько документов создалось в 1С; сколько строк в выписке и сколько разнесено. Совпадение чисел — единственное доказательство, что порция не потерялась.
- 5Отдельно проверьте обмены, которые идут раз в сутки. Ночная выгрузка, попавшая в окно, не повторится сама до следующей ночи. Если окно ночное, эти обмены запускаются вручную сразу после обновления.
Отдельная категория риска — дубли и пересорт, которые появляются именно при догоне: часть документов успела создаться до остановки, часть приезжает повторно после включения. Механику этого и способы защиты мы разбирали в материале о семи ошибках обмена с 1С; ключевое требование к обмену здесь одно — идемпотентность, то есть повторный приём той же записи должен обновлять существующий документ, а не создавать второй.
Горизонтальная схема-лента с окном в середине. Слева три источника: «Сайт», «Маркетплейс», «Банк», от них стрелки в общий блок «Очередь». Центральная вертикальная полоса — «Окно обновления», внутри неё подписи «бэкап», «стоп-флаг обмена», «объединение конфигураций», «контрольные операции». Справа от полосы блок «Догон очереди» и под ним блок сверки с тремя строками: «заказов на сайте за окно = документов в 1С», «строк в выписке = разнесено», «ночные выгрузки запущены вручную». Под схемой предупреждающая подпись «повторный приём записи обновляет документ, а не создаёт второй». Чертёжный стиль, подписи по-русски.
Когда обновление можно отложить, а когда нельзя
Не каждый релиз обязателен, и осмысленный отказ от части обновлений — законный способ сократить годовой счёт. Правило простое: обновление обязательно, если оно приносит изменения, за отсутствие которых наказывают или которые ломают работу с контрагентами.
- Обновляемся обязательно: изменения форм регламентированной отчётности, форматов ЭДО, требований по маркировке и работы с госсистемами, а также релизы с исправлениями безопасности. Здесь цена задержки — штраф или непринятый документ, и она выше любого счёта за часы.
- Можно отложить до следующего окна: релизы с новым функционалом, которым вы не пользуетесь, и косметические изменения интерфейса. Разумный ритм в этом случае — одно обновление в квартал вместо трёх в год по факту выхода.
- Нельзя откладывать дольше года. Разрыв версий превращает следующее обновление в проект: платформа сравнивает вашу конфигурацию не с соседним релизом, а с накопленными изменениями за весь период, и часы растут нелинейно.
И последнее. Если счёт за обновления уже стал заметной строкой бюджета, честный разговор — не про скидку на часы, а про то, что именно живёт внутри конфигурации. В большинстве случаев половина доработок там оказалась по инерции: их писали внутри, потому что так было привычнее исполнителю. Как выглядит альтернатива и во сколько она обходится, разобрано в материале о том, как автоматизироваться без замены 1С.
Цена обновления закладывается не в момент обновления, а в момент, когда решают, где будет жить код.
