«1С-Рарус» ускорила расчёт зарплаты вдвое на шинном заводе BRZ в Узбекистане

На шинном заводе BRZ в Узбекистане расчёт зарплаты для нескольких сотен рабочих растягивался на дни из-за сменного графика и сдельно-премиальных начислений. Специалисты «1С-Рарус» пересобрали регламентированный расчёт и распараллелили обработку по цехам — время расчёта сократилось вдвое, без перехода на новую конфигурацию 1С.

с чем шинный завод BRZ пришёл к автоматизации зарплаты

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

сдельная схема, которая утяжеляет любой расчёт

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

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

где расчёт зарплаты упирался в потолок

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

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

во что это обходилось заводу без пересмотра методики

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

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

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

что изменила команда «1С-Рарус» в расчёте

Специалисты начали не с замены конфигурации, а с диагностики: где именно теряется время — в методике расчёта, в структуре справочников или в производительности сервера. Часть ответа дал профильный тест производительности 1С (методика описана у Гилёва): нагрузка на процессор во время расчёта укладывалась в норму, значит, тормозила не инфраструктура, а логика обработки документов.

что именно пересобрали

По итогам аудита команда:

• ✓перевела расчёт по подразделениям с последовательной обработки на параллельные регламентные задания, чтобы цеха считались одновременно, а не по очереди;
• ✓нормализовала справочники видов начислений и надбавок — часть коэффициентов хранилась дублирующими записями и пересчитывалась впустую при каждом прогоне;
• ✓убрала избыточные перерасчёты, которые запускались при правке одного наряда по всему массиву данных завода, а не только по затронутому сотруднику;
• ✓протестировала обновлённую схему на реальном объёме — с фактическим числом сотрудников, смен и видов начислений, а не на демонстрационной базе с урезанными данными.

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

насколько ускорился расчёт после внедрения

Главный результат — расчёт зарплаты по заводу стал занимать вдвое меньше времени. Для бухгалтерии это разница между «расчёт съедает половину закрытия месяца» и «расчёт укладывается в рабочий день, а не растягивается на несколько».

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

что кейс BRZ показывает о выборе подрядчика по 1С

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

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

как ускорить расчёт зарплаты в 1С без миграции на новую конфигурацию

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

1. ✓Замерить, где реально теряется время — тестом производительности или профилированием конкретного регламентного расчёта, а не на глаз и не по общим жалобам «всё медленно».
2. ✓Проверить, считаются ли подразделения параллельно или один поток ждёт другой — на многофилиальных и многоцеховых предприятиях это частая причина многочасового расчёта.
3. ✓Свести дублирующие записи в справочниках начислений и надбавок — лишние строки увеличивают время обработки на каждом сотруднике и усложняют дальнейшую поддержку.
4. ✓Если типовых настроек не хватает под конкретную сдельную схему, потребуется доработка 1С — точечная, под фактические правила расчёта, а не переписывание модуля целиком.
5. ✓Проверить актуальность релиза — устаревшие регламентированные алгоритмы иногда закрывает штатное обновление 1С без доработки.

Если после этих шагов расчёт всё равно упирается в производительность сервера, а не в логику, разумно перенести базу на выделенную инфраструктуру — аренда сервера для 1С у нас начинается от 1 100 ₽/мес за пользователя, а готовое рабочее место в облаке — от 1100 руб/мес. Дальнейшее сопровождение регламентированного учёта и точечные правки логики расчёта — по тарифу сисадмина и специалиста 1С от 3800 руб/час, без привязки к абонементу и без обязательного перехода на новую конфигурацию.

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

Сколько стоит перенастройка расчёта зарплаты в 1С, если конфигурация не меняется?

Стоимость зависит от объёма правок: обычно это диагностика методики расчёта плюс точечная доработка справочников и регламентов. Разовые работы по нашим тарифам сопровождения 1С считаются от 3800 руб/час; итоговая смета зависит от числа видов начислений и подразделений, которые нужно пересобрать.

Нужно ли переходить на новую конфигурацию 1С, чтобы ускорить расчёт зарплаты?

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

Как понять, что расчёт зарплаты тормозит из-за сервера, а не из-за методики?

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

Можно ли ускорить расчёт зарплаты, если сдельная оплата привязана к производственному учёту в 1С:ERP?

Да, но перенастройку нужно вести с учётом связки производственных документов и начислений, иначе ускорение расчёта разорвёт синхронизацию с данными о выработке. Такие случаи требуют совместной работы с контуром 1С:ERP, а не изолированной правки одного модуля зарплаты.

Сколько времени занимает перенастройка регламентированного расчёта на предприятии уровня BRZ?

Сроки зависят от числа видов начислений и подразделений: диагностика обычно занимает несколько дней, перенастройка и тестирование на реальном объёме данных — от одной до нескольких недель, в зависимости от того, нужна ли доработка под нестандартные сдельные схемы.