Кадровый учет — та область, где сказываются и размер компании, и географическое присутствие, и активность законодательной власти. ИТ‑системы, автоматизирующие учет кадров, постоянно требуют актуализации и изменений. О своем опыте рассказывают Егор Кимхай, начальник отдела разработки информационных проектов логистической компании Itella Logistics (ранее «НЛК»), и Алевтина Денисова, заместитель руководителя службы по кадровому администрированию той же фирмы.

Intelligent Enterprise: Каковы особенности кадрового учета в вашей компании?

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

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

Егор Кимхай: Мы и раньше применяли для кадрового учета продукт «1С» — «ЗУП 2.0» («1C: Зарплата и управление персоналом»). Так как законодательство и требования регулирующих органов меняются быстро, постоянно приходилось вести доработки. Часто мы их не успевали сделать своевременно, поскольку наше решение плохо сочеталось с типовым решением «1С», и слишком много требовалось доделывать. Каждое изменение требований к отчетности или законодательства вызывало серьезные переделки, от которых страдали все, поскольку использовать стандартные обновления было невозможно. В августе 2010 г. стартовал проект перехода на ЗУП 2.5. Для выполнения работ была выбрана компания «Микротест».

Какие особенности были у этого проекта?

Егор Кимхай: Он был рассчитан на очень жесткие сроки: в начале 2011 г. мы уже планировали перейти на новое ПО. Почти успели. С января начали работать в двух системах, в феврале окончательно перешли на новый продукт.

Перенос данных составлял основную проблему. Данные в новую базу вносили сотрудники подрядчика, взяв за основу нашу базу. Автоматически конвертировать одну базу в другую было невозможно. А стояла задача перенести не только 6 тыс. сотрудников, но и налоги за год, чтобы сдавать их уже из нового ПО. При этом часть сведений о налогах не соответствовала изменившемуся законодательству. Специалисты компании «Микротест» смогли создать удачные скрипты, позволившие перенести данные напрямую из старой базы в новую, сконвертировав их в соответствии с новыми правилами.

Затем началась проверка введенных данных. Абсолютно всё мы не могли проверить, но были выбраны «реперные» точки, по которым проверяли часть записей, а по некоторым параметрам — и всех сотрудников полностью. Однако работа по переносу оказалась сложнее и объемнее, чем мы планировали. Из-за этого весь январь пришлось работать в двух системах, хотя первоначально планировали переходить сразу, без этапа параллельной работы.

Что показал опыт эксплуатации «ЗУП 2.5»?

Егор Кимхай: Мы уже около года используем этот инструмент. Теперь можно смело утверждать, что поставленной цели мы достигли: наши подрядчики — сотрудники «Микротест» создали систему, в которой реализованы все наши требования, но в то же время сохранилась возможность легкого обновления на очередные релизы «1С». Внесения обновлений конфигурации теперь практически никто не замечает. Только два человека проводят после очередных изменений стандартные про­цедуры тестирования. Раньше мы иногда отставали от законодательства на месяц, а то и на квартал. Теперь же — максимум на неделю.

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

Кроме того, у нас есть система фиксации всех изменений, вносимых в ПО. Это касается всех систем, не только «1С». На все изменения, даже небольшие, обязательно есть ТЗ, хоть из двух строк. И все это хранится в единой базе. Всегда видно, что менялось, кто менял и чей это был заказ.

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

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

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

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

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

Административный персонал оценивается с помощью системы грейдов. Новая программа помогла сделать этот процесс системным, удобным и четким. Так, для каждой должности у нас есть некоторая система поощрений. Теперь стал возможен их централизованный учет. Для складского персонала есть отдел обучения. Через определенное время кандидаты на повышение проходят тесты, комиссия присваивает успешным более высокую категорию по совокупности прохождения обучения и тестов. Планирование и учет всех этих процессов тоже идут в «1С». Мы видим, люди какого типа насколько быстро делают карьеру. Раньше это было в наших записях, «на коленке», в головах у кадровиков. Теперь все эти данные введены в программу и доступны для анализа. Бизнес наш очень динамичен, часто идет массовой набор сотрудников для отдельных проектов. Из них сразу можно выделить перспективных и целенаправленно их развивать.

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

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

Itella — финская компания. Насколько жестко штаб-квартира требует исполнения в России стандартов, принятых в Европе, в том числе и в кадровом учете?

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

При синхронизации информации и действий с штаб-квартирой больше проблем возникает не с кадровым учетом, а с расчетом зарплаты. В практике западных компаний в России часто бывает так, что присланные из штаб-квартиры стандарты расчета зарплат противоречат законодательству РФ, одновременно требуя аналитических показателей отчетности, которым нет соответствия в российском зарплатном и кадровом учете. Компромиссные решения нам помогли найти консультанты из «Микротест», имеющие значительный опыт подобных проектов, особенно в области подготовки финансово‑аналитической информации.

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