АС УП - не «ЗУП с доработками»: опыт функционального моделирования кадрового администрирования

Практический разбор на примере кадрового администрирования

Автор: Файзрахманов Айрат, руководитель «Акрус-Про».

При первом знакомстве с АС УП легко сделать неверный вывод: система создана на платформе «1С:Предприятие» и использует «1С:Зарплата и управление персоналом КОРП 3.1», значит, внедрять ее можно как обычную ЗУП - обследовать учет, перенести данные, добавить недостающие реквизиты и запустить расчет.

На практике сходство заканчивается довольно быстро.

АС УП - это не отдельная база ЗУП, приспособленная под одно предприятие. В тиражном корпоративном решении объединены типовые возможности ЗУП, общие кадровые правила, централизованные справочники, унифицированные документы, разграничение полномочий и информационное взаимодействие с другими частями системы.

Команде недостаточно хорошо знать кадровый учет и механизмы ЗУП КОРП. Нужно уметь подключить предприятие к уже определенной корпоративной модели, не разрушить ее местными изменениями и при этом сохранить обязательную специфику предприятия.

Граница материала. В статье рассматривается только один из участков АС УП - кадровое администрирование. В него входят персональные данные, движение персонала, поощрения и взыскания, планирование и учет отсутствий, а также воинский учет. АС УП шире этого участка, поэтому приведенные ниже примеры нельзя считать полным описанием системы или всех этапов ее развития.

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

В рамках функционального моделирования мы разбирали не только пользовательские операции. В предмет работы входили реестр кадровых процессов, сопоставление требований с типовой ЗУП КОРП, описание целевых сценариев и изменений на уровне объектов системы, распределение прав, подготовка данных и организационные мероприятия для последующих этапов проекта. На этой работе и основана статья.

Почему АС УП нельзя воспринимать как «ЗУП с доработками»

При обычном внедрении ЗУП предприятие чаще всего является владельцем своей системы. Оно определяет правила учета, самостоятельно ведет справочники, утверждает местные печатные формы и принимает решение о доработках. Если у кадровой службы есть особое требование, его можно оценить и реализовать в границах одной информационной базы.

В АС УП любое локальное решение необходимо рассматривать в общем контуре. Новый реквизит может повлиять на корпоративный отчет. Дополнительный вид кадрового события - на информационное взаимодействие с другими системами. Изменение справочника - на сопоставимость данных разных предприятий. Местная печатная форма - на единообразие кадрового делопроизводства.

Поэтому вопрос «Можно ли это разработать?» становится вторичным. Сначала нужно ответить на другие вопросы:

1. Обязательно ли требование по закону или локальному нормативному акту?
2. Предусмотрен ли нужный порядок в действующей версии АС УП?
3. Не решается ли задача типовыми средствами ЗУП КОРП?
4. Можно ли привести процесс предприятия к корпоративному порядку?
5. Является ли потребность общей для других организаций?
6. Кто имеет полномочия утвердить изменение?
7. Как изменение повлияет на справочники, формы, отчеты, права и передачу данных?
8. Кто будет сопровождать его после обновления системы?

Команда не складывает все пожелания в перечень будущих доработок. По каждому требованию она выясняет, какое место оно занимает в тиражном решении и кто вправе принять решение по расхождению.

Как устроено предметное описание кадрового администрирования

Одна из особенностей работы с АС УП - подробное разложение кадровой деятельности на взаимосвязанные процессы и отдельные сценарии.

На верхнем уровне кадровое администрирование можно представить шестью группами:

• учет персональных данных;
• движение персонала;
• поощрения и взыскания;
• планирование отсутствий;
• учет отсутствий;
• воинский учет.

Каждая группа делится на процессы второго уровня, а те - на конкретные сценарии. Например, «Движение персонала» - это не только прием, перевод и увольнение. Отдельного рассмотрения требуют отмена приема, окончание временного перевода, изменение условий трудового договора, отмена увольнения, восстановление на работе, совмещение, прекращение дополнительной работы и приостановление трудового договора.

Такое разложение важно для внедрения. Формулировка «прием на работу поддерживается» слишком общая и практически ничего не говорит о готовности предприятия. Необходимо проверить весь сценарий:

• на каком основании начинается оформление;
• кто вводит сведения;
• какие поля обязательны;
• какие справочники используются;
• какие проверки выполняются;
• какие документы формируются;
• кого необходимо уведомить;
• куда передаются результаты;
• как исправляется или отменяется операция;
• какие права требуются участникам.

На уровне сценария становится видно, что уже обеспечивает типовая ЗУП, что добавлено в АС УП, где достаточно настройки предприятия, а что относится к последующему развитию.

Какие результаты должны появиться до настройки системы

До настройки конфигурации команда должна подготовить взаимосвязанный комплект решений.

1. Реестр кадровых процессов

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

Без такого реестра одно и то же требование может несколько раз появиться под разными названиями. Например, уведомление об окончании срока договора может обсуждаться одновременно в приеме, изменении условий договора и увольнении. Реестр позволяет увидеть связь и назначить единого владельца решения.

2. Требования к каждому сценарию

Требование должно описывать не пожелание пользователя, а проверяемый результат. Вместо «нужно удобное уведомление» следует указать:

• событие, после которого формируется уведомление;
• получателя;
• срок отправки;
• состав сведений;
• условие повторной отправки;
• действие при ошибке;
• возможность проверить факт отправки.

Такая формулировка позволяет понять, поддерживает ли требование типовая ЗУП, нужна ли настройка или требуется изменение АС УП.

3. Сопоставление с типовой ЗУП КОРП

По каждому требованию необходимо зафиксировать результат проверки типовой функциональности. Простого ответа «есть» или «нет» обычно недостаточно. Возможны разные ситуации:

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

На практике любое несовпадение нередко сразу записывают в разработку. Но результатом обследования может быть и отказ от местной практики с переходом на единый порядок АС УП.

4. Карточка изменения системы

Если типовых возможностей недостаточно, изменение описывается на уровне объектов системы. В карточке указываются:

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

Такой подход защищает от «маленьких» изменений с большими последствиями. Дополнительный флажок в кадровом документе может потребовать отдельной истории, новой строки корпоративного отчета, передачи в смежную систему и особого права доступа.

5. Перечень организационных изменений

Не все различия устраняются программно. Для начала работы предприятия могут потребоваться:

• утверждение единых печатных форм;
• изменение местных регламентов;
• назначение владельцев справочников;
• перераспределение полномочий;
• введение нового порядка подачи кадровых сведений;
• отказ от неформализованных списков и файлов;
• установление сроков ввода и проверки данных.

Это одно из важнейших отличий от обычной ЗУП. В АС УП меняется не только система - в согласованной части меняется само предприятие.

Этапы внедрения АС УП

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

Этап 1. Определение версии и границ внедрения

АС УП развивается, поэтому нельзя начинать обследование с общего вопроса «Что умеет система?». Сначала необходимо определить:

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

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

Результатом этапа становится ведомость границ: процессы, ожидаемые результаты, участники, связанные системы и условия приемки.

Этап 2. Обследование действующего порядка предприятия

На этом этапе мы изучаем не только документы старой ЗУП. Необходимо установить реальный порядок работы:

• откуда кадровая служба получает основание для операции;
• кто проверяет штатную единицу и условия оплаты;
• где хранятся сведения, отсутствующие в учетной системе;
• какие действия выполняются вручную;
• какие файлы используются параллельно с ЗУП;
• кто получает уведомления;
• какие местные формы утверждены;
• какие сведения передаются в другие подразделения;
• как исправляются ошибки прошлых периодов.

По каждому требованию необходимо запросить основание. Если пользователи говорят «у нас всегда было так», выясняем, закреплено ли это в нормативном документе и сохраняется ли потребность после перехода на корпоративную модель.

Этап 3. Сопоставление процессов предприятия с АС УП

Это центральный этап внедрения. Для каждого сценария сравниваются:

• действующий порядок предприятия;
• типовая возможность ЗУП КОРП;
• действующий порядок АС УП;
• обязательные требования законодательства;
• корпоративные правила;
• местные нормативные особенности.

Расхождение получает один из следующих результатов:

1. использовать готовую возможность АС УП;
2. выполнить разрешенную настройку предприятия;
3. изменить местный процесс;
4. уточнить корпоративную методологию;
5. развить тиражное решение;
6. создать изолированное местное дополнение;
7. отнести функцию к последующему развитию;
8. отказаться от требования как от необоснованного.

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

Этап 4. Подготовка нормативно-справочной информации

В самостоятельной ЗУП кадровик часто может создать недостающий элемент справочника или изменить существующий. В корпоративной системе часть справочников ведется централизованно.

Поэтому для каждого справочника заранее определяется:

• кто является владельцем;
• кто может создавать и изменять элементы;
• как предприятие запрашивает новое значение;
• какие реквизиты обязательны;
• с какой даты действует изменение;
• как закрывается ошибочное или устаревшее значение;
• какие системы используют этот справочник;
• допускается ли местное расширение.

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

На практике именно справочники часто становятся причиной задержки переноса. Если местная должность, основание кадрового приказа или вид отсутствия не сопоставлены с корпоративным значением, загрузить документ технически можно, но получить сопоставимую отчетность уже нельзя.

Этап 5. Настройка и реализация изменений

Работы выполняются только после принятия решений по расхождениям. Для каждого изменения проверяем:

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

Отдельно контролируется изоляция местной специфики. Даже обоснованное требование одного предприятия не должно бесконтрольно менять общий механизм для всех организаций.

Этап 6. Подготовка и перенос данных

Перенос кадровых данных - это не копирование справочников из старой базы. Сначала определяется, какие сведения действительно необходимы новой системе.

Для кадрового администрирования могут потребоваться:

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

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

По каждому объекту фиксируем:

• источник;
• правило отбора;
• глубину истории;
• сопоставление справочников;
• правило преобразования;
• контрольное количество;
• способ содержательной сверки;
• ответственного за приемку.

Требуется несколько пробных переносов. Первый проверяет техническую загрузку, второй - полноту и качество, последний воспроизводит окончательный переход с замером времени. Если правила менялись после последней репетиции, результат нельзя считать полностью проверенным.

Этап 7. Испытания кадровых сценариев

Проверять нужно не только создание документа. Для каждого критичного сценария выполняются:

• обычная операция;
• операция списком, если она предусмотрена;
• исправление;
• отмена;
• ввод задним числом;
• действие при незаполненном обязательном поле;
• попытка выбрать недопустимое значение;
• формирование печатной формы;
• проверка отчета;
• передача сведений в связанный процесс;
• проверка прав другого пользователя.

Особенно важны отрицательные сценарии. Если срочный трудовой договор нельзя провести без даты окончания, испытание должно подтвердить сам запрет, понятность сообщения и правильную работу после заполнения даты.

Для тиражного решения дополнительно проверяются:

• отсутствие влияния местных настроек на другие организации;
• работа централизованных справочников;
• сохранение функций после установки новой версии;
• производительность массовых операций;
• полнота регистрации значимых действий.

Этап 8. Организационная подготовка предприятия

До запуска должны быть утверждены не только настройки системы, но и новый порядок работы.

Необходимо проверить:

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

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

Этап 9. Переход и опытная эксплуатация

План перехода должен содержать точную последовательность действий:

1. ограничение ввода в старой системе;
2. окончательная выгрузка;
3. загрузка и контроль;
4. перенос изменений переходного периода;
5. проверка справочников и прав;
6. выполнение контрольных кадровых операций;
7. проверка передачи данных;
8. открытие доступа пользователям;
9. усиленное сопровождение.

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

Практический пример: прием на работу

Прием на работу хорошо показывает разницу между обычным внедрением ЗУП и внедрением АС УП.

Типовая ЗУП уже умеет оформить прием сотрудника, указать организацию, подразделение, должность, вид занятости, график работы, оплату и условия договора. Если смотреть только на наличие документа, можно сделать вывод, что процесс готов.

Но в корпоративном решении проверяется полный состав требований. В зависимости от действующей версии АС УП могут потребоваться дополнительные правила:

• обязательное указание срока окончания срочного договора;
• признак приема в порядке перевода;
• формализованное основание для приказа;
• указание замещаемого сотрудника;
• отдельный номер для печатной формы;
• уведомление заинтересованных подразделений;
• напоминание об окончании срока договора;
• унифицированная форма приказа и трудового договора.

Для каждого пункта нужно определить источник данных и последующее использование. Например, признак приема в порядке перевода может влиять не только на текст приказа, но и на кадровую отчетность. Сведения о замещаемом сотруднике должны проверяться на непротиворечивость с действующим отсутствием. Уведомление должно отправляться только после того, как прием получил установленное состояние, иначе связанные службы могут начать оформление доступа по непроведенному документу.

Затем сценарий раскладывается на шаги:

1. получение основания;
2. проверка физического лица на дубли;
3. проверка штатной позиции;
4. заполнение условий договора;
5. проверка обязательных реквизитов;
6. проведение кадрового документа;
7. формирование печатных форм;
8. передача сведений заинтересованным участникам;
9. проверка отражения в отчетности;
10. испытание исправления и отмены приема.

Такой разбор показывает, почему знание документа «Прием на работу» в ЗУП еще не означает знания внедрения АС УП. Специалист должен понимать весь корпоративный сценарий и последствия каждой записи.

Отличия от классического внедрения ЗУП КОРП

Ошибки, которые выдают отсутствие опыта работы с АС УП

«Мы сначала соберем пожелания, а потом решим, что разрабатывать»

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

«Если функция есть в ЗУП, значит, процесс автоматизирован»

Наличие документа не подтверждает выполнение корпоративного сценария. Необходимо проверить реквизиты, формы, уведомления, права, отчетность и исправления.

«Недостающий справочник создадим на предприятии»

Если справочник централизован, местное создание элемента нарушит сопоставимость данных и может привести к ошибкам передачи.

«Перенесем всех сотрудников и всю историю»

Состав переноса определяется последующим использованием данных. Избыточная история увеличивает сроки сверки, а недостаточная делает невозможными отдельные кадровые операции и отчеты.

«Достаточно проверить проведение документов»

Необходимо испытать отмену, исправление, обратную дату, печатную форму, права, массовые операции и передачу результата.

«После запуска предприятие будет работать по-старому»

АС УП предполагает организационные изменения. Если сохраняются местные формы, параллельные файлы и неформальные правила, единая система остается единой только технически.

Как мы понимаем опыт работы с АС УП

Опыт работы с АС УП - это не только знание ее форм и документов. Команда должна уметь:

• определить границы конкретной версии;
• разложить кадровую деятельность на проверяемые сценарии;
• сопоставить требования с типовой ЗУП и действующей АС УП;
• отличить настройку от изменения процесса и развития тиражного решения;
• работать с централизованными справочниками;
• описать изменение на уровне объектов, прав и движения данных;
• подготовить предприятие к унифицированным формам и правилам;
• определить состав и глубину переноса;
• провести испытания обычных и исключительных ситуаций;
• организовать переход и многоуровневое сопровождение.

По этим задачам хорошо видно, работала ли команда с тиражной корпоративной системой или воспринимает АС УП как еще одну измененную конфигурацию ЗУП.

Наш практический опыт относится прежде всего к функциональному моделированию АС УП. В 2026 году мы завершили этот этап на промышленном предприятии: связали кадровые требования с целевыми сценариями, определили границы применения типовой ЗУП КОРП и изменений АС УП, проработали роли, данные и организационные условия дальнейшего внедрения. Поэтому приведенный подход основан не только на изучении возможностей системы, но и на выполненной проектной работе.

Заключение

АС УП использует знакомую специалистам основу «1С:ЗУП 3.1 КОРП», но внедряется по другим правилам. Предприятие подключается не только к программе, но и к корпоративной модели кадровых процессов, справочников, документов и полномочий.

На примере кадрового администрирования видно, что единицей внедрения становится не документ ЗУП, а полный кадровый сценарий: от основания и ввода данных до печатной формы, отчетности, передачи сведений и исправления ошибки.

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

В статье рассмотрен только участок кадрового администрирования. Он показывает подход к внедрению, но не описывает всю АС УП. Для каждого следующего функционального участка нужно отдельно изучать процессы, состав решения, данные, связи и порядок приемки.