Автоматизация оценки персонала. Типовые ошибки
Почему некоторые проекты по автоматизации процедур оценки персонала оказываются неуспешными: не доходят до конца, не удовлетворяют заказчика, стоят дороже, чем планировалось? Как правило, причины этого связаны не с программным обеспечением, а с тем, как проект организован, и с определенными заблуждениями заказчика о внедрении автоматизированной оценки.
Как показывает практика, это типичные ошибочные представления о процессе, с которыми сталкивается большинство подрядчиков. Чего ждать компаниям от разработчика, внедряющего автоматизированную оценку персонала, как подготовиться и как не совершить ошибок – об этом в нашей статье. Также поговорим об эффективности agile подхода и ситуациях, когда и он не поможет.
Заблуждение № 1: Процедуру оценки можно автоматизировать раз и навсегда
Первое заблуждение, которое приводит к большому количеству проблем, состоит в том, что оценочную процедуру можно автоматизировать раз и навсегда. На самом деле вероятность того, что она не претерпит изменений уже после года проведения, фактически равна нулю.
Для сравнения: задачи обучения, задачи рекрутмента могут быть автоматизированы более или менее надолго (на несколько лет). Процедуру оценки почти наверняка приходится менять. При этом каждая следующая оценка проходит немного иначе. Когда эти, казалось бы, незначительные изменения накапливаются на протяжении достаточно длительного времени, то процедура меняется весьма ощутимо.
Большое дополнительное влияние оказывает такой тренд, как Digital transformation. Если компания проходит стадию цифровой трансформации, в ней меняется подход к огромному количеству процессов, и со 100%-й вероятностью изменится и подход к оценке, а значит, и процедура ее автоматизации.
Чтобы иметь возможность без труда вносить организационные и технические изменения, при выборе подхода к автоматизации оценки стоит ориентироваться на гибкие инструменты настройки практически всех элементов: экранных форм, отчетных форм, workflow, уведомлений, формул расчетов. Все предполагаемые корректировки необходимо изначально учитывать в проекте, и это нужно обсуждать с подрядчиком или ответственными специалистами компании. Только при гибком подходе вместе с изменением бизнес-процесса у вас будет возможность оперативно и с относительной легкостью поменять и настройки процедур.
Например, у вас будет возможность убрать из типовой оценки Performance Management этап каскадирования целей, изменить разделение KPI на блоки и т.д. Если же вы жестко «зашьете» функцию в программное обеспечение, не заложите гибкие механизмы еще при проектировании базовой процедуры оценки, то легко внести изменения у вас не получится. Резюме таково: если что-то может поменяться, то оно скорее всего поменяется, и это нужно учитывать «на входе».
Заблуждение № 2: Качество данных не имеет значения
Многие компании, имеющие опыт автоматизации HR-процессов и, соответственно, определенные данные, уверены, что этого достаточно для успешной автоматизации оценки. Это второе заблуждение. Качество данных должно быть совершенно другим.
Допустим, в компании реализованы процессы дистанционного обучения, данные о структуре и должностях сотрудников загружены в систему кадрового учета, и их достаточно чтобы автоматизировать, например, процедуру назначения курса.
Но как только вы переходите от автоматизации процедуры обучения к автоматизации оценки, вы понимаете, что вам нужна абсолютно точная информация: кто является руководителем сотрудника, причем не только по организационной структуре, но и функционально. Особенно это важно в контексте перехода многих компаний к системе функциональной подчиненности, к моделям командной работы и т.д.
Если качество информации об организационной структуре неудовлетворительное (ведется нерегулярно, актуализируется не вовремя), то при внедрении процедуры автоматизации оценки вы неминуемо столкнетесь с этой проблемой. Все это ведет к необходимости изменять наполнение базовой системы кадрового учета, формировать дополнительные данные для загрузки в систему, что, естественно, требует времени и трудозатрат.
Суровая правда для процедуры оценки такова, что качественные данные крайне важны. Необходимо, чтобы они четко отражали структуру подчиненности в компании, а интеграция с ними должна быть точной и регулярной.
Более того, могут потребоваться совершенно новые данные. Допустим, в системе дистанционного обучения есть типовая информация, какую позицию сотрудник занимает на текущую дату. Но за определенный период он мог перейти из одного подразделения в другое, а значит, нам понадобится информация о том, сколько времени человек отработал в одном и другом подразделении, кто был его руководителем, какие цели у него были в эти периоды. Это новые данные, которые не нужны для задачи обучения, но будут крайне критичны для задачи оценки. Важно понимать, есть ли у нас эти данные, ведь их предстоит загружать в систему и учитывать в процедуре оценки.
Данные, которых достаточно для дистанционного обучения:
• Данные о структуре компании
• Данные о должности, которую сотрудник занимает на данный момент
Данные, которые нужны для оценки:
• Кто является руководителем сотрудника по оргструктуре
• Кто является функциональным руководителем сотрудника
• Переходил ли сотрудник из одного подразделения в другое за отчетный период
• Сколько времени отработал в каждом подразделении и кто являлся его руководителем
• Каковы были цели сотрудника в каждый из этих периодов
• И другие данные...
Заблуждение № 3: Можно автоматизировать процесс оценки за минимальное время
Третье заблуждение состоит в том, что оценку можно запустить за минимальное время.
Действительно, сам процесс оценочной формы можно настроить довольно быстро. Но основное время занимает огромная подготовительная работа:
• формирование профилей, если оно различное для разных категорий руководителей и специалистов;
• формирование и загрузка в систему плана оценки или описание алгоритма, как система будет определять руководителей и подчиненных, в оценке 360;
• формирование и настройка отчетов, уведомлений и напоминаний.
С учетом этого можно ли говорить, что в крупных компаниях из нескольких сотен, тысяч человек проект может быть полноценно запущен за несколько дней? Конечно, нет. Это невозможно, даже если заказчик берет готовое коробочное решение.
Если мы говорим о проектах, которые реализуются по классической методологии, то процесс занимает в среднем 3-4 месяца.
Исключение могут составлять простые типовые процедуры типа обратной связи 360. Но если мы говорим о процедурах, которые должны учесть специфические процессы загрузки данных, особые маршруты согласования, нестандартные требования к экранам форм и т.д., то это действительно очень непростая задача.
Почему ее решение занимает 3-4 месяца и что необходимо реализовать в этот период?
1. На начальном этапе необходимо время на анализ, понимание и формирование реальных требований к процедуре. Если речь идет о классическом подходе, то на этом этапе ведется подготовка и согласование технического задания и техпроекта, что в среднем требует не меньше месяца.
2. Время на непосредственную реализацию проекта.
3. Функциональное тестирование. На этом этапе разработчик или консультант, который настраивал систему, подтверждает, что процедуру можно запускать, и заказчик, используя методику тестирования, убеждается, что она работает. Функциональное тестирование можно провести за несколько дней.
4. Нагрузочное тестирование. Крайне важная процедура, и, если вы ее раньше не проводили, ниже подробнее объясним, почему это необходимо делать.
5. В идеальном случае выделяется время на запуск «пилота». Как правило, для этого выбирается HR или IT подразделение, либо бизнес-подразделение, которое изначально заявило о готовности комментировать процесс. В отличие от функционального тестирования, пилотирование процесса невозможно осуществить в течение дня или нескольких дней.
Идеальный вариант, когда «пилот» запускается за месяц до того, как процесс будет масштабирован на всю компанию. Это не всегда возможно, но крайне желательно.
Отдельное внимание уделим нагрузочному тестированию. Когда мы говорим о процессах, в которых участвуют от пяти тысяч человек, этот этап становится критично важным. Даже если у вас есть система, в которой сотрудники проходят дистанционное обучение, это не означает, что на том же оборудовании то же количество человек успешно пройдут оценочную процедуру. С большой вероятностью это будет не так, так как нагрузка будет существенно выше и иного характера. Автоматизированная оценочная процедура с точки зрения нагрузки может быть похожа на единовременное тестирование или массовый опрос, когда у сотрудников есть жесткий срок, в который они в конкурентном режиме, то есть все вместе, должны выполнить определенные действия.
Осложняющим фактором может стать организационная сторона процесса. Очень часто автоматизированные системы настраиваются таким образом, что в самый последний момент (за несколько дней до конца оценки) пользователям рассылается автоматическое уведомление, что оценочные формы в ближайшее время станут недоступными. Велика вероятность того, что все несколько тысяч сотрудников одновременно устремятся в систему. Вы уверены, что ваше оборудование, каналы связи, сервер, базы данных выдержат такую нагрузку?
Для проверки этого и существует нагрузочное тестирование с помощью специальных технических решений (инструментов для нагрузочного тестирования). При запуске системы в первый раз проведение нагрузочных испытаний крайне рекомендовано. Для этого нужно специально резервировать человеческие и технические ресурсы.
Выдержит ли ваша система, если в нее захотят зайти одновременно несколько тысяч сотрудников? Если вы никогда не проводили нагрузочных испытаний, эмуляция пиковой нагрузки при объемах процедур больше 5 тысяч участников крайне важна.
Заблуждение № 4: Можно автоматизировать процесс, которого не существует
Четвертое заблуждение – это автоматизация процесса, которого нет. Сразу разграничим две ситуации:
1) Когда реализовать проект сложно, но можно. Речь идет об автоматизации оценки в первый раз, когда не было автоматизированного или вообще никакого процесса; а также о случаях радикальных изменений в компании: например, когда происходит реорганизация, меняется высшее руководство, изменяются процессы, и HR и внутренний бизнес-заказчик не до конца понимают, что автоматизировать. В этом случае, как шутят айтишники, при автоматизации бардака получается автоматизированный бардак. Но можно рассчитывать хоть на какой-то результат.
2) Когда лучше вообще ничего не автоматизировать. Если у заказчика хотя бы на верхнем уровне нет понимания процесса, то лучше ничего не предпринимать. Да, на начальном этапе трудно сформулировать, как должны выглядеть оценочные формы. Нет детального представления, как будет формироваться ИПР. Но нужно иметь ответы хотя бы на вопросы верхнего уровня: будут ли цели или KPI? Или и цели, и KPI? Будут ли компетенции? Процедура будет квартальной, полугодовой, годовой? Если этого базового понимания нет, проект обречен на провал.
Что существенно помогает в работе, если проект все же решено запускать, так это agile. Гибкий подход к внедрению автоматизированной процедуры оценки дает невероятный результат по сравнению с классическим водопадным методом реализации проекта, требующим согласования ТЗ, техпроекта и т.д., и позволяет сократить расходы (до двух раз) и срок разработки (до 1,5 месяцев), улучшить качество, повысить общую удовлетворенность результатом.
Суть agile подхода состоит в том, что работы осуществляются в ходе определенных промежутков времени, спринтов. Допустим, есть общая оценочная процедура, которая будет состоять из трех блоков: 1) постановка цели, 2) промежуточная оценка, 3) итоговая оценка. На примере первого блока спринт выглядит следующим образом: осуществляется процедура постановки целей, определяется маршрут согласования, получается финальный отчет. «Пилотная» разработка отдается группе или подразделению, и по итогам использования собирается обратная связь.
Примеры пожеланий: в дополнение к обычному руководителю добавить функционального, сделать отчет более понятным, добавить подсказки на разных этапах документооборота, внести изменения в дизайн и т.д. Эти изменения вносятся в ходе второго спринта (допустим, недели), и получается обновленная версия решения. Она снова апробируется, и, если с ней все хорошо, то разворачивается на всю компанию. Аналогичным образом проходит работа над следующими блоками. Это классическое правильное применение agile подхода. Помешать ему могут только спонтанные решения заказчика изменить что-то в системе накануне ее запуска.
Еще одна проблема автоматизации оценки в контексте несуществующих процессов – это избыточно сложные процедуры, а именно стремление заказчика учесть огромное количество гипотетических ситуаций. Например: представим, что у нас поменялся руководитель – нужно автоматически «перебросить» его в оценочные формы; вдруг кому-то будет нужна процедура параллельной оценки – надо добавить и т.д.
Все это невероятно усложняет в общем-то простую задачу автоматизации оценочной процедуры. А причин тому две. Первая – стремление сделать автоматизированное решение раз и навсегда («вдруг потом денег не дадут, надо включить сейчас всего побольше»). Вторая – желание по максимуму использовать услуги разработчика за те же деньги. Кстати, при работе по agile оплачивается каждый час работы специалиста, поэтому заказчик несколько раз подумает, зачем отдельно платить за функцию, необходимость которой неочевидна. Таким образом agile не только снижает сложность разработки, но и экономит время и деньги.
Стремление заказчика предусмотреть большое количество гипотетических и частных случаев и по максимуму внедрить функции, ценность которых неочевидна, приводит к избыточно сложным процедурам.
Другая сторона избыточно сложных процедур – это реальное непонимание процесса. Сотрудник, который отвечает за автоматизированную процедуру, может сомневаться, нужна ли кнопка, тот или иной отчет. И тогда он просит добавить кнопку по умолчанию, а отчеты сделать сразу все – какой-нибудь да понадобится. Это противоречит логике гибкой модели, согласно которой необходимо сделать минимально жизнеспособный продукт (minimum viable product), учитывающий все первостепенные нужды, и только затем, после тестирования и обратной связи, можно будет добавлять в него дополнительные функции.
Кроме этого, не стоит неоправданно усложнять решение, если оно касается незначительного количества сотрудников. Нет смысла автоматизировать процедуру, если в ней задействованы, допустим, 20 человек. В этом случае сначала надо искать простые решения, а автоматизацией заниматься тогда, когда задача затрагивает сотни пользователей, тысячи разных сценариев.
Избыточно сложная процедура – это всегда дополнительные расходы, увеличенные сроки, повышенная сложность сдачи-приемки, большее количество возможных ошибок. Если ее можно избежать, это нужно делать.
Заблуждение № 5: Ресурсы заказчика не имеют значения
Последнее заблуждение состоит в том, что ресурсы заказчика не имеют значения. Они не просто важны, а необходимы.
В первую очередь речь идет о непрерывном процессе внутренних коммуникаций. Без более или менее регулярного участия функционального заказчика проект практически гарантированно умирает и в 100 % случаев заканчивается неудачей. И, наоборот, успешный проект – это плод совместной деятельности разработчиков (внутренних, внешних, консультантов) и функционального заказчика.
Agile подход вообще строится на регулярном взаимодействии сторон в соответствии со спринтами (недельными, двухнедельными, месячными). В начале каждого периода функциональный заказчик и разработчик обсуждают, что они будут делать, потом совместно тестируют результаты и переходят к следующему спринту. Только так можно полноценно воплотить все идеи в жизнь.
В идеале в процесс должен быть вовлечен как можно более высокий руководитель со стороны заказчика, например, директор по персоналу. Пускай его участие в процессе будет не day by day, но промежуточные результаты он должен видеть и оценивать (например, на этапе согласования внешнего вида оценочных форм, прототипов интерфейса и т.д.). Сейчас все больше HR-руководителей осознают, что автоматизированная оценка, которая запускается на несколько тысяч человек в компании, имеет очень серьезное значение, а потому с большей готовностью участвуют в процессах.
IT-ресурсы тоже очень важны и нужны для того, чтобы решить задачу интеграции. Участие представителей от соответствующей службы компании надо планировать на начальном этапе проекта. Без их помощи не обойтись в случае нехватки данных, при проведении нагрузочных испытаний и следующих за ними мер. Например, если выяснится, что сервер недостаточно мощный, надо будет делать кластер серверов, выделять более мощную виртуальную машину или наращивать мощности СУБД, и эти задачи лягут на плечи ответственных за IT.
Подводя итоги, можно вывести определенную «формулу успеха»:
1. Для автоматизации оценки очень важен гибкий подход. При планировании и проектировании надо максимально гибко относиться к инструментам и технологиям, которые вы используете, и постепенно двигаться шаг за шагом.
2. Очень важны качественные данные и IT-поддержка.
3. Какой бы гибкой методологии мы ни следовали, нужно время. Его необходимо закладывать на пилотирование процесса, нагрузочные испытания и т.д.
4. В процессе принятия решений, на этапах agile моделирования должны быть руководители, которые принимают решения, понимают, правильно ли мы движемся, и вносят коррективы, если нужно.
5. Вся работа должна вестись совместно – теми, кто процедуру настраивает, и теми, кто ее заказывает.
Следованием этим пяти несложным пунктам позволит вам успешно реализовать проект по автоматизации оценки и избежать типичных ошибок.
Как показывает практика, это типичные ошибочные представления о процессе, с которыми сталкивается большинство подрядчиков. Чего ждать компаниям от разработчика, внедряющего автоматизированную оценку персонала, как подготовиться и как не совершить ошибок – об этом в нашей статье. Также поговорим об эффективности agile подхода и ситуациях, когда и он не поможет.
Заблуждение № 1: Процедуру оценки можно автоматизировать раз и навсегда
Первое заблуждение, которое приводит к большому количеству проблем, состоит в том, что оценочную процедуру можно автоматизировать раз и навсегда. На самом деле вероятность того, что она не претерпит изменений уже после года проведения, фактически равна нулю.
Для сравнения: задачи обучения, задачи рекрутмента могут быть автоматизированы более или менее надолго (на несколько лет). Процедуру оценки почти наверняка приходится менять. При этом каждая следующая оценка проходит немного иначе. Когда эти, казалось бы, незначительные изменения накапливаются на протяжении достаточно длительного времени, то процедура меняется весьма ощутимо.
Большое дополнительное влияние оказывает такой тренд, как Digital transformation. Если компания проходит стадию цифровой трансформации, в ней меняется подход к огромному количеству процессов, и со 100%-й вероятностью изменится и подход к оценке, а значит, и процедура ее автоматизации.
Чтобы иметь возможность без труда вносить организационные и технические изменения, при выборе подхода к автоматизации оценки стоит ориентироваться на гибкие инструменты настройки практически всех элементов: экранных форм, отчетных форм, workflow, уведомлений, формул расчетов. Все предполагаемые корректировки необходимо изначально учитывать в проекте, и это нужно обсуждать с подрядчиком или ответственными специалистами компании. Только при гибком подходе вместе с изменением бизнес-процесса у вас будет возможность оперативно и с относительной легкостью поменять и настройки процедур.
Например, у вас будет возможность убрать из типовой оценки Performance Management этап каскадирования целей, изменить разделение KPI на блоки и т.д. Если же вы жестко «зашьете» функцию в программное обеспечение, не заложите гибкие механизмы еще при проектировании базовой процедуры оценки, то легко внести изменения у вас не получится. Резюме таково: если что-то может поменяться, то оно скорее всего поменяется, и это нужно учитывать «на входе».
Заблуждение № 2: Качество данных не имеет значения
Многие компании, имеющие опыт автоматизации HR-процессов и, соответственно, определенные данные, уверены, что этого достаточно для успешной автоматизации оценки. Это второе заблуждение. Качество данных должно быть совершенно другим.
Допустим, в компании реализованы процессы дистанционного обучения, данные о структуре и должностях сотрудников загружены в систему кадрового учета, и их достаточно чтобы автоматизировать, например, процедуру назначения курса.
Но как только вы переходите от автоматизации процедуры обучения к автоматизации оценки, вы понимаете, что вам нужна абсолютно точная информация: кто является руководителем сотрудника, причем не только по организационной структуре, но и функционально. Особенно это важно в контексте перехода многих компаний к системе функциональной подчиненности, к моделям командной работы и т.д.
Если качество информации об организационной структуре неудовлетворительное (ведется нерегулярно, актуализируется не вовремя), то при внедрении процедуры автоматизации оценки вы неминуемо столкнетесь с этой проблемой. Все это ведет к необходимости изменять наполнение базовой системы кадрового учета, формировать дополнительные данные для загрузки в систему, что, естественно, требует времени и трудозатрат.
Суровая правда для процедуры оценки такова, что качественные данные крайне важны. Необходимо, чтобы они четко отражали структуру подчиненности в компании, а интеграция с ними должна быть точной и регулярной.
Более того, могут потребоваться совершенно новые данные. Допустим, в системе дистанционного обучения есть типовая информация, какую позицию сотрудник занимает на текущую дату. Но за определенный период он мог перейти из одного подразделения в другое, а значит, нам понадобится информация о том, сколько времени человек отработал в одном и другом подразделении, кто был его руководителем, какие цели у него были в эти периоды. Это новые данные, которые не нужны для задачи обучения, но будут крайне критичны для задачи оценки. Важно понимать, есть ли у нас эти данные, ведь их предстоит загружать в систему и учитывать в процедуре оценки.
Данные, которых достаточно для дистанционного обучения:
• Данные о структуре компании
• Данные о должности, которую сотрудник занимает на данный момент
Данные, которые нужны для оценки:
• Кто является руководителем сотрудника по оргструктуре
• Кто является функциональным руководителем сотрудника
• Переходил ли сотрудник из одного подразделения в другое за отчетный период
• Сколько времени отработал в каждом подразделении и кто являлся его руководителем
• Каковы были цели сотрудника в каждый из этих периодов
• И другие данные...
Заблуждение № 3: Можно автоматизировать процесс оценки за минимальное время
Третье заблуждение состоит в том, что оценку можно запустить за минимальное время.
Действительно, сам процесс оценочной формы можно настроить довольно быстро. Но основное время занимает огромная подготовительная работа:
• формирование профилей, если оно различное для разных категорий руководителей и специалистов;
• формирование и загрузка в систему плана оценки или описание алгоритма, как система будет определять руководителей и подчиненных, в оценке 360;
• формирование и настройка отчетов, уведомлений и напоминаний.
С учетом этого можно ли говорить, что в крупных компаниях из нескольких сотен, тысяч человек проект может быть полноценно запущен за несколько дней? Конечно, нет. Это невозможно, даже если заказчик берет готовое коробочное решение.
Если мы говорим о проектах, которые реализуются по классической методологии, то процесс занимает в среднем 3-4 месяца.
Исключение могут составлять простые типовые процедуры типа обратной связи 360. Но если мы говорим о процедурах, которые должны учесть специфические процессы загрузки данных, особые маршруты согласования, нестандартные требования к экранам форм и т.д., то это действительно очень непростая задача.
Почему ее решение занимает 3-4 месяца и что необходимо реализовать в этот период?
1. На начальном этапе необходимо время на анализ, понимание и формирование реальных требований к процедуре. Если речь идет о классическом подходе, то на этом этапе ведется подготовка и согласование технического задания и техпроекта, что в среднем требует не меньше месяца.
2. Время на непосредственную реализацию проекта.
3. Функциональное тестирование. На этом этапе разработчик или консультант, который настраивал систему, подтверждает, что процедуру можно запускать, и заказчик, используя методику тестирования, убеждается, что она работает. Функциональное тестирование можно провести за несколько дней.
4. Нагрузочное тестирование. Крайне важная процедура, и, если вы ее раньше не проводили, ниже подробнее объясним, почему это необходимо делать.
5. В идеальном случае выделяется время на запуск «пилота». Как правило, для этого выбирается HR или IT подразделение, либо бизнес-подразделение, которое изначально заявило о готовности комментировать процесс. В отличие от функционального тестирования, пилотирование процесса невозможно осуществить в течение дня или нескольких дней.
Идеальный вариант, когда «пилот» запускается за месяц до того, как процесс будет масштабирован на всю компанию. Это не всегда возможно, но крайне желательно.
Отдельное внимание уделим нагрузочному тестированию. Когда мы говорим о процессах, в которых участвуют от пяти тысяч человек, этот этап становится критично важным. Даже если у вас есть система, в которой сотрудники проходят дистанционное обучение, это не означает, что на том же оборудовании то же количество человек успешно пройдут оценочную процедуру. С большой вероятностью это будет не так, так как нагрузка будет существенно выше и иного характера. Автоматизированная оценочная процедура с точки зрения нагрузки может быть похожа на единовременное тестирование или массовый опрос, когда у сотрудников есть жесткий срок, в который они в конкурентном режиме, то есть все вместе, должны выполнить определенные действия.
Осложняющим фактором может стать организационная сторона процесса. Очень часто автоматизированные системы настраиваются таким образом, что в самый последний момент (за несколько дней до конца оценки) пользователям рассылается автоматическое уведомление, что оценочные формы в ближайшее время станут недоступными. Велика вероятность того, что все несколько тысяч сотрудников одновременно устремятся в систему. Вы уверены, что ваше оборудование, каналы связи, сервер, базы данных выдержат такую нагрузку?
 |
| Выдержит ли ваша инфраструктура неожиданную нагрузку в тысячи пользователей в день? |
Для проверки этого и существует нагрузочное тестирование с помощью специальных технических решений (инструментов для нагрузочного тестирования). При запуске системы в первый раз проведение нагрузочных испытаний крайне рекомендовано. Для этого нужно специально резервировать человеческие и технические ресурсы.
Выдержит ли ваша система, если в нее захотят зайти одновременно несколько тысяч сотрудников? Если вы никогда не проводили нагрузочных испытаний, эмуляция пиковой нагрузки при объемах процедур больше 5 тысяч участников крайне важна.
Заблуждение № 4: Можно автоматизировать процесс, которого не существует
Четвертое заблуждение – это автоматизация процесса, которого нет. Сразу разграничим две ситуации:
1) Когда реализовать проект сложно, но можно. Речь идет об автоматизации оценки в первый раз, когда не было автоматизированного или вообще никакого процесса; а также о случаях радикальных изменений в компании: например, когда происходит реорганизация, меняется высшее руководство, изменяются процессы, и HR и внутренний бизнес-заказчик не до конца понимают, что автоматизировать. В этом случае, как шутят айтишники, при автоматизации бардака получается автоматизированный бардак. Но можно рассчитывать хоть на какой-то результат.
2) Когда лучше вообще ничего не автоматизировать. Если у заказчика хотя бы на верхнем уровне нет понимания процесса, то лучше ничего не предпринимать. Да, на начальном этапе трудно сформулировать, как должны выглядеть оценочные формы. Нет детального представления, как будет формироваться ИПР. Но нужно иметь ответы хотя бы на вопросы верхнего уровня: будут ли цели или KPI? Или и цели, и KPI? Будут ли компетенции? Процедура будет квартальной, полугодовой, годовой? Если этого базового понимания нет, проект обречен на провал.
Что существенно помогает в работе, если проект все же решено запускать, так это agile. Гибкий подход к внедрению автоматизированной процедуры оценки дает невероятный результат по сравнению с классическим водопадным методом реализации проекта, требующим согласования ТЗ, техпроекта и т.д., и позволяет сократить расходы (до двух раз) и срок разработки (до 1,5 месяцев), улучшить качество, повысить общую удовлетворенность результатом.
Суть agile подхода состоит в том, что работы осуществляются в ходе определенных промежутков времени, спринтов. Допустим, есть общая оценочная процедура, которая будет состоять из трех блоков: 1) постановка цели, 2) промежуточная оценка, 3) итоговая оценка. На примере первого блока спринт выглядит следующим образом: осуществляется процедура постановки целей, определяется маршрут согласования, получается финальный отчет. «Пилотная» разработка отдается группе или подразделению, и по итогам использования собирается обратная связь.
Примеры пожеланий: в дополнение к обычному руководителю добавить функционального, сделать отчет более понятным, добавить подсказки на разных этапах документооборота, внести изменения в дизайн и т.д. Эти изменения вносятся в ходе второго спринта (допустим, недели), и получается обновленная версия решения. Она снова апробируется, и, если с ней все хорошо, то разворачивается на всю компанию. Аналогичным образом проходит работа над следующими блоками. Это классическое правильное применение agile подхода. Помешать ему могут только спонтанные решения заказчика изменить что-то в системе накануне ее запуска.
Еще одна проблема автоматизации оценки в контексте несуществующих процессов – это избыточно сложные процедуры, а именно стремление заказчика учесть огромное количество гипотетических ситуаций. Например: представим, что у нас поменялся руководитель – нужно автоматически «перебросить» его в оценочные формы; вдруг кому-то будет нужна процедура параллельной оценки – надо добавить и т.д.
Все это невероятно усложняет в общем-то простую задачу автоматизации оценочной процедуры. А причин тому две. Первая – стремление сделать автоматизированное решение раз и навсегда («вдруг потом денег не дадут, надо включить сейчас всего побольше»). Вторая – желание по максимуму использовать услуги разработчика за те же деньги. Кстати, при работе по agile оплачивается каждый час работы специалиста, поэтому заказчик несколько раз подумает, зачем отдельно платить за функцию, необходимость которой неочевидна. Таким образом agile не только снижает сложность разработки, но и экономит время и деньги.
Стремление заказчика предусмотреть большое количество гипотетических и частных случаев и по максимуму внедрить функции, ценность которых неочевидна, приводит к избыточно сложным процедурам.
 |
| Не пытайтесь запихнуть в систему все |
Другая сторона избыточно сложных процедур – это реальное непонимание процесса. Сотрудник, который отвечает за автоматизированную процедуру, может сомневаться, нужна ли кнопка, тот или иной отчет. И тогда он просит добавить кнопку по умолчанию, а отчеты сделать сразу все – какой-нибудь да понадобится. Это противоречит логике гибкой модели, согласно которой необходимо сделать минимально жизнеспособный продукт (minimum viable product), учитывающий все первостепенные нужды, и только затем, после тестирования и обратной связи, можно будет добавлять в него дополнительные функции.
Кроме этого, не стоит неоправданно усложнять решение, если оно касается незначительного количества сотрудников. Нет смысла автоматизировать процедуру, если в ней задействованы, допустим, 20 человек. В этом случае сначала надо искать простые решения, а автоматизацией заниматься тогда, когда задача затрагивает сотни пользователей, тысячи разных сценариев.
Избыточно сложная процедура – это всегда дополнительные расходы, увеличенные сроки, повышенная сложность сдачи-приемки, большее количество возможных ошибок. Если ее можно избежать, это нужно делать.
Заблуждение № 5: Ресурсы заказчика не имеют значения
Последнее заблуждение состоит в том, что ресурсы заказчика не имеют значения. Они не просто важны, а необходимы.
В первую очередь речь идет о непрерывном процессе внутренних коммуникаций. Без более или менее регулярного участия функционального заказчика проект практически гарантированно умирает и в 100 % случаев заканчивается неудачей. И, наоборот, успешный проект – это плод совместной деятельности разработчиков (внутренних, внешних, консультантов) и функционального заказчика.
Agile подход вообще строится на регулярном взаимодействии сторон в соответствии со спринтами (недельными, двухнедельными, месячными). В начале каждого периода функциональный заказчик и разработчик обсуждают, что они будут делать, потом совместно тестируют результаты и переходят к следующему спринту. Только так можно полноценно воплотить все идеи в жизнь.
В идеале в процесс должен быть вовлечен как можно более высокий руководитель со стороны заказчика, например, директор по персоналу. Пускай его участие в процессе будет не day by day, но промежуточные результаты он должен видеть и оценивать (например, на этапе согласования внешнего вида оценочных форм, прототипов интерфейса и т.д.). Сейчас все больше HR-руководителей осознают, что автоматизированная оценка, которая запускается на несколько тысяч человек в компании, имеет очень серьезное значение, а потому с большей готовностью участвуют в процессах.
IT-ресурсы тоже очень важны и нужны для того, чтобы решить задачу интеграции. Участие представителей от соответствующей службы компании надо планировать на начальном этапе проекта. Без их помощи не обойтись в случае нехватки данных, при проведении нагрузочных испытаний и следующих за ними мер. Например, если выяснится, что сервер недостаточно мощный, надо будет делать кластер серверов, выделять более мощную виртуальную машину или наращивать мощности СУБД, и эти задачи лягут на плечи ответственных за IT.
Подводя итоги, можно вывести определенную «формулу успеха»:
1. Для автоматизации оценки очень важен гибкий подход. При планировании и проектировании надо максимально гибко относиться к инструментам и технологиям, которые вы используете, и постепенно двигаться шаг за шагом.
2. Очень важны качественные данные и IT-поддержка.
3. Какой бы гибкой методологии мы ни следовали, нужно время. Его необходимо закладывать на пилотирование процесса, нагрузочные испытания и т.д.
4. В процессе принятия решений, на этапах agile моделирования должны быть руководители, которые принимают решения, понимают, правильно ли мы движемся, и вносят коррективы, если нужно.
5. Вся работа должна вестись совместно – теми, кто процедуру настраивает, и теми, кто ее заказывает.
Следованием этим пяти несложным пунктам позволит вам успешно реализовать проект по автоматизации оценки и избежать типичных ошибок.
