- «У нас зарплата считается, но только если бухгалтер может зайти на офисный компьютер».
- «А если не может?»
- «Тогда ждем системного администратора. В прошлый раз ждали почти день - как раз перед выплатой».
Я слышал такой диалог не один раз. Когда расчет зарплаты держится на одной машине, RDP и человеке, который помнит, где лежит база, речь уже не про удобство. Это вопрос устойчивости процесса, который нельзя откладывать на завтра.
ЗУП нужен там, где бухгалтерия уже перестает справляться
Когда собственник спрашивает, что такое 1С ЗУП, я обычно отвечаю так: это отдельный контур для сотрудников, начислений и кадровых событий. Отпуска, больничные, премии, удержания, НДФЛ, взносы, переводы - все это живет здесь. 1С:Бухгалтерия считает бизнес в целом, ЗУП считает людей.
Пока в компании 10-15 человек и у всех оклад, зарплату еще можно вести в бухгалтерии и Excel. Потом появляются смены, совместители, два юрлица, ручные доплаты, и бухгалтер начинает собирать данные по чатам и таблицам. Я видел это у клиента из дистрибуции: на старте было 12 сотрудников, а когда штат вырос до 55 человек, подготовка начислений стала занимать 2-3 дня в месяц.
После перехода на 1С:Зарплата и управление персоналом база стала одной точкой учета для кадровика и расчетчика. Повторный ручной ввод сократился примерно на 30%, и пользы от этого оказалось больше, чем от любых споров о стоимости лицензий.
Если расчет зарплаты живет отдельно от кадровых событий, ошибка сначала выглядит как мелочь в процессе, а потом возвращается деньгами.
Fresh обычно покупают не из-за слова «облако»
Для собственника это история про риск. Для IT-менеджера - способ не держать свой сервер 1С, не заниматься обновлениями и резервными копиями. Для бухгалтерии - доступ через интернет без просьб «перезагрузите компьютер в офисе».
У одного клиента ЗУП стояла на Windows Server 2019, пользователи заходили по RDP. После обновления Windows удаленный доступ пропал, и закрытие месяца сдвинулось почти на 1 рабочий день. После перехода в 1С Fresh доступ перестал зависеть от конкретной машины.
По данным проектов, слабое место здесь почти всегда одно и то же: данные, а не платформа. Если остатки отпусков, НДФЛ и старые начисления заведены с ошибками, они просто переедут в новый контур.
Подключение без хаоса начинается с проверки базы
Самая частая ошибка - купить подписку и считать, что запуск уже состоялся. На практике первые проблемы всплывают на первом же расчете, когда выясняется, что в старой базе часть отпусков вели вручную, а кадровые документы проводили задним числом.
Мы обычно идем коротким маршрутом:
- смотрим, это старт с нуля или перенос действующей базы
- проверяем роли и доступы: расчетчик, кадровик, руководитель
- переносим справочники, сотрудников, остатки отпусков, НДФЛ
- настраиваем обмен с 1С:Бухгалтерией
- делаем параллельный расчет за 1 месяц
На проекте в рознице сама база в Fresh поднялась за 1 день. Но сверка данных заняла 9 рабочих дней, потому что отпускные остатки частично жили в 1С, частично - в таблицах. Для малого и среднего бизнеса реальный срок запуска обычно составляет от 5 дней до 4 недель.
Один раз мы сами недооценили объем сверки и заложили слишком оптимистичный срок. Ошибку заметили быстро, пересобрали план работ и уже после этого пошли в перенос. Такие вещи лучше признавать на старте, чем объяснять их в день расчета.
| Формат | Что получает бизнес | Где риск |
|---|---|---|
| Локальная база | максимум доработок | сервер, доступ, бэкапы на вашей стороне |
| Арендованный сервер | привычная логика | часть администрирования все равно остается |
| 1С Fresh | быстрый доступ, меньше инфраструктуры | ограничения по нетиповым доработкам |
Где Fresh подходит сразу, а где надо тормозить
Хороший сценарий - типовые начисления, несколько ролей, удаленные сотрудники, стандартный обмен с бухгалтерией. В таких проектах Fresh обычно закрывает задачу быстро. Если база не переписана, запуск идет спокойно, без лишней архитектуры и ручных обходов.
Плохой сценарий тоже узнается быстро. Сильно переделанная ЗУП, сложные премии, самописный обмен с внутренним порталом, согласования в обход типовой логики. Как рассказал один из участников такого проекта, ожидание было простым: раз «ЗУП уже есть», перенос займет 1 неделю. На деле не сработало: ключевые начисления держались на нетиповых механизмах, а обмен с порталом был написан под старую конфигурацию. Проект остановили, процессы описали заново и только потом вернулись к облаку.
Перед решением я бы проверил всего 5 вещей:
- база типовая или сильно переписанная
- нужен типовой обмен или есть самописные интеграции
- кто поддерживает систему при сбое
- сколько стоит 1 день простоя перед выплатой
- можно ли восстановить расчет без офисного ПК
Считать лучше не подписку, а цену сбоя
У Fresh есть свои затраты: перенос, настройка прав, обучение, сопровождение первого периода. У локальной схемы расходы обычно размазаны по разным статьям - системный администратор, бэкапы, аварии, ручной обмен файлами, простой перед выплатой. В одной таблице это редко видно, хотя именно там и лежат реальные деньги.
В прошлом году я все чаще видел один и тот же сдвиг: компании перестали обсуждать, нужно ли им облако как таковое, и начали считать, сколько людей зависит от одной машины в день зарплаты. Когда в начале статьи бухгалтер ждет системного администратора, это еще выглядит как бытовая заминка. На практике это уже управленческая проблема, и таких историй, по моим наблюдениям, будет только больше: бизнес все чаще выбирает не «облако», а предсказуемость процесса.
