Как девелопер сократил ИТ-расходы на 1С на 30%

Застройщик в Москве снизил ИТ-расходы на 1С на 30% за три шага: обновил платформу до актуального релиза, вычистил самописные доработки, которые копились пять лет, и перевёл склад со снабжением в единый контур на 1С:ERP. Скорость базы при этом выросла, а не упала — сводные отчёты формируются быстрее, чем до оптимизации.

из-за чего ит-расходы на 1С у застройщика вышли из-под контроля

Тридцатого числа каждого месяца бухгалтерия застройщика собирает сводный отчёт по десяти жилым комплексам для банка — так устроено проектное финансирование: банк ждёт данные к фиксированной дате, иначе транш на следующий этап стройки задерживается. Именно в эти дни база 1С, которую компания дорабатывала своими силами шесть лет, начинала виснуть. Отчёт, собиравшийся в начале месяца за 15 минут, к тридцатому числу растягивался на два часа, а иногда падал с ошибкой нехватки памяти.

Первой реакцией была покупка более мощного сервера. Но это не помогло: скорость выросла на день-два, а затем база снова начала тормозить. Дело было не в железе, а в самой конфигурации. За шесть лет в базу добавили порядка сорока доработок под разные задачи — под каждого нового снабженца, под каждый новый банк-партнёр, под каждую налоговую проверку. Часть модулей дублировала друг друга, часть перегружала одни и те же таблицы разными обработчиками. Разобраться, что можно снести, а что критично для работы, было некому: программисты, которые это писали, давно уволились.

Ставка в этой ситуации понятная. Сорванный отчёт для банка — не просто неудобство: это риск задержки транша по эскроу-счёту и, соответственно, риск остановки финансирования на объекте, где уже работают подрядчики. Для застройщика это прямые потери в виде простоя и неустоек по договорам подряда.

Похожая картина встречается не только в этой компании. У застройщиков ИТ-контур обычно растёт вместе с числом проектов, а не по заранее продуманному плану: на старте хватает базовой конфигурации и пары доработок под конкретную сделку. Через несколько лет объектов становится десять, доработок — сорок, а разобраться в них некому, потому что каждую заказывали со словами «сделайте побыстрее», а не «сделайте по правилам».

как сократили ит-расходы на 30% без потери скорости 1С

Оптимизацию начали не с закупок, а с диагностики. Прежде чем менять что-либо в рабочей базе, важно понять, где именно теряется производительность — в платформе, в коде доработок или в железе, и только потом принимать решения. Все изменения сначала проверили на копии базы, чтобы не рисковать данными, от которых зависит отчётность перед банком. Работу разделили на три направления.

обновление платформы вместо покупки нового сервера

Производительность конфигурации проверили тестом Гилёва — он показывает, где узкое место: в платформе, в оборудовании или в прикладном коде. Тест показал, что дело в устаревшем релизе платформы и в неоптимальных запросах внутри доработок, а не в мощности сервера. Обновление 1С до текущего релиза дало ощутимый прирост скорости без единого рубля на новое железо: новые релизы платформы регулярно оптимизируют работу с большими объёмами данных, а старый релиз эти оптимизации попросту не получал. Обновление сначала прогнали на тестовом контуре и только потом перенесли на рабочую базу, чтобы 30-е число не совпало с внеплановым простоем.

рефакторинг доработок, которые никто не помнил зачем писал

Провели инвентаризацию всех доработок в базе: для каждой подняли историю изменений и опросили руководителей отделов, кто и зачем ей пользуется. Из сорока с лишним модулей двадцать пять дублировали функционал друг друга или обслуживали бизнес-процессы, которые компания уже не использует. Их отключили поэтапно, с возможностью откатить конкретный модуль, если выяснится, что он всё же был нужен. Ни одного отката не понадобилось. Оставшиеся пятнадцать доработали и задокументировали: для каждой зафиксировали, кто её использует, зачем она нужна и какие таблицы затрагивает, чтобы через год не пришлось снова гадать.

консолидация склада и снабжения в контуре 1С:ERP

Склад, снабжение и стройконтроль велись в отдельной подсистеме на устаревшей платформе — с отдельной лицензией и отдельным администратором под неё, а данные в основную базу попадали через ночную синхронизацию, из-за которой отчёты по остаткам всегда были неактуальны на сутки. После внедрения 1С:ERP эти процессы перенесли в общий контур: одна лицензия вместо нескольких, один администратор вместо двух, единая база вместо ночной синхронизации между системами. Переход провели параллельно со старой системой в течение месяца, чтобы снабженцы успели привыкнуть к новому интерфейсу, не теряя доступ к привычным отчётам.

Вот как изменились ключевые показатели после трёх шагов:

Заметно, что экономия в этом кейсе — не про урезание функциональности, а про устранение дублей: одна и та же задача до оптимизации решалась двумя-тремя способами одновременно, а после — одним.

почему сэкономленное на 1С часто возвращается в расходы через полгода

Экономия на 30% держится ровно до тех пор, пока в базу не начинают точечно добавлять новые доработки в обход общего процесса. Классическая история: один отдел заказывает у знакомого программиста «быструю правку» в обход общего бэклога, второй подключает отдельный сервис для отчётности, третий продлевает лицензию на систему, которую формально уже заменили ERP-контуром. Каждое решение по отдельности выглядит мелким, а вместе они за год-полтора возвращают расходы к исходному уровню — и снова размывают ответственность за то, кто и зачем изменил базу.

Работает та же логика, что и в диагностике исходной проблемы: прежде чем добавлять новую доработку, стоит понять, не решает ли эту задачу уже существующий функционал 1С:ERP или 1С:Управление торговлей. Если решение всё же нужно, его проводят через единый бэклог и считают в общем ИТ-бюджете, а не в бюджете конкретного отдела — тогда рост расходов виден сразу, а не через год на сверке счетов. На практике полезно отслеживать три показателя раз в квартал: число активных доработок, число отдельных лицензий на смежные системы и время формирования ключевых отчётов. Если хотя бы один из них начинает расти без объяснимой причины, это сигнал вернуться к аудиту, не дожидаясь, пока база снова начнёт виснуть к отчётной дате.

что удерживает ит-расходы на 1С от повторного разрастания

Три шага, которые сработали в этом кейсе, дают разовый эффект. Чтобы он не растворился за полтора года, нужны правила, по которым дальше живёт база:

• ✓завести единый бэклог доработок с ответственным за каждую — без него точечные правки снова расползаются по отделам;
• ✓обновлять платформу по графику, а не откладывать годами — чем старше релиз, тем больше расхождение между тем, что умеет платформа «из коробки», и тем, что дописано руками;
• ✓раз в квартал проверять, какие модули и лицензии реально используются, а какие оплачиваются по инерции;
• ✓при расширении функционала сначала смотреть, закрывает ли задачу типовой функционал 1С:Управления торговлей или ERP, и только потом заказывать доработку.

Для застройщика, который работает с проектным финансированием, это не абстрактная гигиена, а прямая защита от сорванной отчётности перед банком: стабильная база не зависит от того, кто из программистов ещё работает в компании и помнит, как всё устроено. Правила, зафиксированные один раз, работают и тогда, когда меняется команда.

сколько стоит такая оптимизация 1С в москве

Диагностика и обновление платформы обычно обходятся дешевле, чем кажется на старте, — особенно в сравнении с закупкой нового сервера, которая часто не решает проблему вообще, как показал этот случай. Сначала проверяют, где реально теряется производительность, и только после этого предлагают конкретный план: что обновить, какие доработки отключить, а какие переписать. Дальнейшее сопровождение и доработки — от 3 800 руб/час, без привязки к ставке штатного программиста и без простоя базы, пока штатного специалиста нет на месте или он в отпуске.

Если расходы выросли из-за разрозненных систем, как в этом кейсе, разумно начать с аудита: понять, что из имеющегося функционала дублируется, а что можно закрыть внедрением 1С нужного контура. Это дешевле, чем содержать несколько лицензий и администраторов под системы, которые решают одну и ту же задачу. Итоговая стоимость зависит от количества доработок и объёма базы — точную цифру называют после диагностики, а не по телефону в первом разговоре.

❓ Частые вопросы

Сколько времени занимает такая оптимизация 1С у застройщика?

В среднем аудит, обновление платформы и вычистка доработок занимают от трёх до шести недель — зависит от количества модулей и того, сколько документации по доработкам сохранилось в компании. Консолидация склада и снабжения в единый ERP-контур — отдельный этап, его считают и планируют уже после диагностики.

Обязательно ли переходить на 1С:ERP, чтобы сократить ИТ-расходы?

Нет. В этом кейсе консолидация в ERP понадобилась из-за раздробленности складского и снабженческого учёта на разных системах. Если у компании один учётный контур без дублирующих систем, ощутимую экономию часто дают обновление платформы и рефакторинг доработок — без перехода на новую конфигурацию вообще.

Не упадёт ли скорость 1С после отключения старых доработок?

Наоборот: часть доработок замедляла базу, дублируя запросы к одним и тем же таблицам в разное время. Перед отключением каждую проверяют — кто использует, зачем она нужна, есть ли зависимости — и только потом убирают. В кейсе застройщика скорость выросла именно после такой чистки.

Сколько стоит сопровождение 1С после оптимизации расходов?

Сопровождение и доработки 1С стоят от 3 800 руб/час, без привязки к ставке штатного программиста и без простоя, пока он в отпуске. Стоимость самой оптимизации зависит от объёма базы и числа доработок — точную оценку называют после диагностики конкретной конфигурации.

Как понять, что расходы на 1С раздуты из-за доработок, а не из-за железа?

Показательный способ — тест Гилёва: он отделяет проблемы платформы и прикладного кода от проблем оборудования. Если тест показывает нормальную производительность железа при медленной работе базы, дело в конфигурации и доработках, а не в сервере, и новый сервер расходы не сократит.