Автоматизация оценки персонала. 5 типовых ошибок.

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

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

Как правило, ключевые проблемы связаны не с программным обеспечением, а с тем, как проект организован, как он ведется.

Заблуждение 1

Процедуру оценки можно автоматизировать раз и навсегда

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

Процедуру оценки практически наверняка придется менять.

Если вы жестко зашьете в систему, например, разделение KPI на три блока, то через год у вас KPI может разделиться на 4 блока или слиться в два, а формула уже не меняется. Поэтому все прогнозируемые, предполагаемые изменения, даже если вы не знаете, какими именно они будут, надо сразу закладывать в проект. Для этого целесообразно применять гибкие инструменты настройки практически всех элементов: экранных форм, отчетных форм,  workflow, уведомлений, формул расчетов.

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

Заблуждение 2

Качество данных не имеет значения

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

Для оценки требования к качеству данных принципиально другие.

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

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

Могут также потребоваться и совершенно новые данные.

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

Заблуждение 3

Можно автоматизировать процесс оценки за минимальное время

Мы подрядчики, и у нас коробочный продукт. У нас есть стандартная процедура оценки 360. Мы постоянно автоматизируем управление по целям и формирование индивидуальных планов развития. Означает ли это, что в компании из нескольких сотен человек проект оценки может быть запущен за два дня? Ответ - нет.

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

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

Даже если процедура относительно простая, необходимо резервировать время:

• на анализ требований

• на функциональное и нагрузочное тестирование
• на пилот процедуры

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

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

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

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

Заблуждение 4

Можно автоматизировать процесс, которого не существует

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

Самый первый совет для таких случаев: если процесс не понятен, лучше ничего не автоматизировать.

Часто заказчик предполагает, что для решения можно применить agile подход. Честный ответ здесь состоит в следующем. Если хотя бы в целом, на уровне целей верхнего порядка, заказчик не понимает, что он хочет, никакой agile, scrum или digital transformation не помогут.

У вас будут цели или KPI? Или и цели, и KPI? Компетенции будут?

Процедура будет квартальной? Годовой? Полугодовой?

Да, вы не можете сейчас сформулировать, как выглядят оценочные формы. Вы не до конца, не до деталей понимаете, как у вас будет формироваться ИПР, но хотя бы на вопросы верхнего уровня нужно иметь ответы.

Мы - апологеты agile подхода: он действительно дает невероятные результаты, намного лучше, чем классический водопадный метод. Он позволяет существенно сократить расходы, ускорить процесс, повысить качество.

Но он работает, если мы видим и понимаем общую картину и идем к цели некоторыми спринтами.

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

По итогам пилота первого спринта могут сформироваться новые требования и дополнения. В следующем спринте вы получаете обновленную версию. Она “выкатывается” на следующий пилот, и после этого, например, принимается решение, что она “раскатывается” на всю компанию. Это нормальный, правильный подход.

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

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

Однако это полностью противоречит логике гибкой модели.

В гибкой модели:

1. Наша задача - сначала сделать что-то, что очевидно и понятно, как работает, сделать решение, в котором есть все, что действительно нужно.
2. Добавлять новые возможности целесообразно только по мере того, как мы получаем обратную связь пользователей и анализируем реальные кейсы.
3. Решение, нужно ли что-то менять или добавлять, принимается с помощью опроса пользователей.
4. При этом задачу действительно стоит автоматизировать, если она массовая - затронет сотни пользователей и тысячи реальных сценариев. Если  задача описывает единичные случаи - тогда нужно просто ее учесть в процессе, но не нужно автоматизировать. Если речь идет о единичных случаях, сначала нужно искать простые решения.

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

Заблуждение 5

Ресурсы заказчика не имеют значения

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

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

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

Реальный заказчик, человек, который принимает решение, например, директор по персоналу, должен в той или иной мере участвовать - видеть промежуточные результаты, согласовывать оценочные формы, прототипы интерфейса. Это значительно снижает риски.

IT-ресурсы очень нужны, IT-департамент должен быть готов вовремя получить и предоставить необходимые данные, провести нагрузочные испытания, вовремя сделать необходимые преобразования после проведения этих испытаний. Если сервер оказался недостаточно мощным, что мы будем делать? Если у вас есть проектная команда, то в ней должен быть ответственный за IT.

• При автоматизации оценки очень важен гибкий подход: все, что может поменяться - изменится.
• Очень важны качественные данные и очень важна IT-поддержка.
• Нужно время, какой бы гибкой методологии мы ни следовали.
• В команде проекта должны быть руководители, которые принимают решение и понимают, правильно ли мы движемся.
• Вся работа должна вестись совместно - теми, кто процедуру настраивает, и теми, кто ее заказывает.

По материалам вебинара Алексея Королькова.

Посмотреть запись вебинара можно здесь.