Автоматизация оценки персонала. 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-поддержка.
  • Нужно время, какой бы гибкой методологии мы ни следовали.
  • В команде проекта должны быть руководители, которые принимают решение и понимают, правильно ли мы движемся.
  • Вся работа должна вестись совместно - теми, кто процедуру настраивает, и теми, кто ее заказывает.


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

Комментарии

Популярные сообщения из этого блога

Какие инструменты необходимы для организации дистанционного обучения

Webtutor 3.5

Стандарты электронного обучения