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

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

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

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

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

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

В-третьих, вам точно и, скорее всего, не раз будут предлагать сделать внутри вашего продукта функцию изменения руководителя. Я не могу вам запретить, но уверяю — вам это не нужно. Своя версия руководства только запутает и вас, и HR, и самих сотрудников. Если у сотрудника другой руководитель — так и нужно менять его для всех и сразу.

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

История перемещений Без истории перемещений вы не сможете автоматически генерировать карты и управлять периодом их действия. Для правильной работы с перемещениями вам нужно предварительно согласовать с методологами правила их учёта: когда создавать карту, когда нужно закрывать одну и создавать вторую, а когда можно просто поменять какие-то атрибуты внутри первой.

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

Только не жадничайте. Не тащите про запас в продукт суперчувствительные данные. Условный оклад редко участвует в постановке целей, но вот в части внутренней ролевой модели, контроля доступов и безопасности в целом может серьёзно усложнить, а следовательно, и удорожить продукт.

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

Подробнее: https://dzen.ru/a/ajG3teOyMHI-s5pt