Как внедрить 1C:ЗУП без рисков и лишних доработок: составляем BRR
Рассказываем про документ, который облегчает переход на новую систему расчета заработной платы и кадрового учета.
Бывает, что компания переходит на 1C:ЗУП и в первый же месяц все идет не по плану: в расчетных листах у сотрудников разные суммы, у части из них не учтены льготы, а привычные надбавки исчезли. Чаще всего проблемы появляются не из-за самой программы, а из-за того, что при внедрении не учли специфику бизнеса: особенности кадрового учета, структуры начислений или бухгалтерских проводок.
Избежать таких ситуаций помогает BRR — Business Requirements Review, или обзор бизнес-требований. Это документ, в котором подробно описаны процессы компании и отмечены все расхождения с типовой функциональностью ЗУП.
Мы в UCMS Group имеем опыт внедрения программы 1C:ЗУП в десятках компаний — от небольших предприятий до крупных холдингов. Знаем, насколько важно правильно написать BRR. В этой статье расскажем, из чего состоит документ, как его готовят и какие особенности он помогает выявить.
Что BRR дает бизнесу
Когда компания переходит с другой системы на 1C:ЗУП, не всегда можно сразу учесть все нюансы. Часто руководители просто не знают, что программа умеет, потому что раньше с ней не работали. BRR помогает понять это заранее.
Документ описывает, как именно будет работать система после внедрения: какие функции нужны, как они связаны между собой, какие данные будут использоваться и откуда их будут брать.
BRR превращает абстрактные требования вроде «хотим, чтобы все считалось само» в четкий план действий для группы внедрения. Стороны договариваются на берегу, что именно автоматизируют, как это должно работать, какой результат ожидается.
Например, если в компании есть особые правила расчета командировочных или специфические форматы табелей, они будут учтены в BRR. Тогда при настройке 1C:ЗУП это не упустят, и организация не столкнется с ситуацией, когда новая система не будет работать по внутренним правилам.
Что компания получает благодаря BRR:
• Прозрачные ожидания. Руководители и команда внедрения одинаково понимают, что будет в системе, а чего не будет. Риск сюрпризов на запуске минимален.
• Экономию времени и денег. Если требования зафиксированы, то в будущем можно избежать лишних доработок и затяжных согласований.
• Возможность планировать работу. BRR задает приоритеты. Понятно, на чем нужно сконцентрироваться сейчас, а что не является срочным.
• Единый язык для всех участников. BRR — это не формальное техническое задание, а документ, написанный человеческим языком. Его поймут и кадровый специалист, и HR-менеджер, и разработчик.
Из каких блоков составляется BRR
BRR строится из нескольких ключевых блоков. Каждый из них описывает отдельный аспект работы системы и показывает, где достаточно типовой функциональности 1C:ЗУП, а где потребуются доработки.
Ниже — основные блоки, из которых формируется BRR:
• кадровый учет,
• расчет заработной платы,
• отчеты,
• портал табельщика,
• бухгалтерские проводки,
• резервы,
• банковские выплаты.
Некоторые блоки, особенно сложные, — например, бухгалтерские проводки — мы выносим в отдельные приложения и согласовываем в самом конце. Это связано с тем, что проводки часто зависят от всех предыдущих настроек и могут быть нестандартными.
Как составляется BRR: ключевые этапы
Составление BRR проходит поэтапно, чтобы ничего не упустить и сразу согласовать нюансы будущей системы.
1. Сбор вводных от клиента
На старте просим клиента рассказать про организационную структуру, предоставить действующие положения по оплате труда, шаблоны документов и печатные формы. Эти материалы помогают понять, какие процессы есть в компании и что важно учесть при настройке системы.
2. Интервью с сотрудниками
Общаемся с теми, кто будет работать в системе каждый день: HR-специалистами, расчетчиками зарплаты, бухгалтерами. Когда обсуждаем проводки, подключаем главного бухгалтера и при необходимости сотрудников финансовой службы.
Цель этапа — узнать все о процессах, понять, какие документы участвуют и какой результат нужен на выходе. Например, если клиенту нужно выгружать проводки в SAP, мы заранее отмечаем это как отдельный блок и обсуждаем его с ответственными. Часто на этом этапе всплывают детали, которые ранее не были озвучены.
3. Анализ информации и составление документа
Структурируем собранные данные, сравниваем их с возможностями типовой функциональности 1C:ЗУП и фиксируем, где нужны доработки. Затем приступаем к написанию — документ пишется вручную.
Перед отправкой клиенту BRR проходит внутреннюю вычитку у программистов. Они смотрят на документ с точки зрения реализации: где нужно уточнить формулировки, что вызывает вопросы, где стоит подстраховаться. Параллельно можем протестировать решения в демобазе, чтобы избежать неожиданностей во время внедрения.
4. Презентация BRR и согласование дорожной карты
Готовый BRR презентуем клиенту, обсуждаем, вносим правки. По результатам согласуем дорожную карту внедрения: что делаем в первую очередь, а что можно отложить. Если часть блоков BRR уже согласована, начинаем внедрение по ним, не дожидаясь финализации всего документа.
На всех этапах мы рекомендуем клиенту придерживаться типовой функциональности 1C:ЗУП. Это касается печатных форм, формул и подходов к расчету отдельных видов начислений.
Один из наших клиентов хотел кардинально пересмотреть многие расчеты, что потребовало бы большого количества доработок. После подробного объяснения, как работает типовая функциональность и какие результаты она дает, клиент согласился оставить большинство стандартных настроек, а доработали только один отчет.
Такая работа выгодна обеим сторонам: уменьшаются трудозатраты и риски, упрощается поддержка системы, а при обновлениях не приходится отслеживать, как доработки повлияют на работу ЗУП.
Когда BRR согласован с клиентом, наши специалисты берут документ в работу и начинают настройку системы: где нужно, пишут код, подстраивают стандартную функциональность под конкретные процессы клиента. Так мы трансформируем базовую платформу 1C:ЗУП под реальные потребности компании.
Какие особенности и нюансы помогает выявить BRR
BRR позволяет увидеть то, что может осложнить внедрение 1C:ЗУП или потребовать нестандартных решений. Вот какие нюансы мы фиксируем чаще всего.
1. Расхождение в подходах к расчету зарплаты
Иногда подход компании к расчету зарплаты расходится с тем, как стандартное решение 1C:ЗУП работает в типовой функциональности. У некоторых клиентов есть особые правила расчета — например, включение или исключение определенных выплат, использование собственных коэффициентов. BRR помогает выявить расхождения и заранее решить, как их обойти: доработать систему или изменить внутренние процессы.
2. Проблемы с качеством исходных данных
При подготовке BRR мы проверяем, насколько корректны и полны данные, которые будут загружаться в 1C:ЗУП. Может оказаться, что часть информации отсутствует или в данных есть ошибки: неправильные ставки или привязки к неверным подразделениям. Такие моменты проще исправить на этапе подготовки BRR, чем сталкиваться с ними после запуска.
3. Особые схемы мотиваций и KPI
В разных компаниях могут быть свои правила премирования: за выполнение планов или качество работы. Иногда бонусы зависят от сложных формул и нескольких источников. BRR позволяет описать эти схемы так, чтобы их можно было корректно реализовать в системе.
В одной из компаний, с которой мы работали, при интервьюировании сотрудников выяснилось, что регламент по премированию устарел и не отражает реальных правил. Фактическая схема оказалась сложнее и требовала доработки системы — это удалось учесть еще на этапе BRR.
Что влияет на сроки подготовки BRR
Сроки подготовки BRR зависят от особенностей процессов клиента. Для небольших компаний документ обычно формируется за 1–2 месяца, для крупных срок может доходить до полугода.
На продолжительность работы над BRR влияют несколько факторов:
• Размер компании и структура бизнеса. Чем больше сотрудников, подразделений и видов начислений, тем дольше собираются данные и описываются процессы. Например, если видов начислений пять — документ формируется быстро, если их 100 — каждый блок нужно детально зафиксировать.
• Сложность расчетов. Большое количество начислений, уникальные формулы и особые схемы мотивации требуют больше времени на анализ.
• Особенности учета. Например, необходимость выгрузки проводок в SAP добавляет этапы описания, согласований и проверок. Также скорость подготовки во многом зависит от полноты исходных данных. Если какие-то аспекты требуют дополнительного анализа, мы проводим детализацию совместно. Когда же клиент предоставляет исчерпывающую информацию с самого начала, это позволяет сократить сроки реализации.
• Вовлеченность клиента и распределение ролей. Чем быстрее сотрудники предоставляют данные и принимают решения, тем быстрее формируется BRR. Если нужно согласовывать детали с несколькими подразделениями, сроки увеличиваются.
• Степень автоматизации текущих процессов. Если многие процессы уже отлажены и документооборот стандартизирован, BRR составляется быстрее. В компаниях с ручными расчетами подготовка документа требует больше времени.
В одном крупном проекте нашего клиента сроки подготовки BRR выросли, потому что часть исходных данных отсутствовала, были сложные схемы начислений, выгрузка проводок в SAP. Команде пришлось уточнять правила расчетов и дорабатывать детали, прежде чем отправлять документ на финальное согласование.
BRR — это основа для надежного внедрения 1C:ЗУП. Без него процесс может обернуться множеством доработок, ошибками и затягиванием сроков. Работа над BRR — инвестиция в прозрачный, понятный и управляемый переход в новую систему. Он позволяет заранее согласовать задачи, определить приоритеты и избежать сюрпризов на этапе внедрения.
UCMS Group готовит BRR перед внедрением 1C:ЗУП. Для работы используется собственный шаблон, который разработан на основе десятков проектов и постоянно дорабатывается с учетом опыта новых внедрений.
Если вас заинтересовал аутсорсинг внедрения 1C:ЗУП, напишите нам. Также подписывайтесь на телеграм-канал UCMS Group — там публикуются кейсы и новости из мира аутсорсинга.