Как выглядит типичный проект по автоматизации HR-процесса

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

Я выделил пять этапов, но это условное деление. На бумаге проекты в разных компаниях будут выглядеть по-разному: другие названия, другое распределение работ по этапам — это зависит от политики актирования в компании, количества участников проекта и т.д. Мы рассмотрим логику работ внутри типичного проекта. Она в большей степени относится к облачным решениям. Если вы внедряете решение оn-premise, последовательность и состав этапов будут похожими, но могут добавиться дополнительные согласования и настройки.

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

«Психоаналитическая сессия»: этап подготовки

Первый этап — подготовительный, он определяет:

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

Мы называем его психоаналитической сессией, потому что успех всего проекта во многом зависит от того, насколько честно и откровенно договорились заказчик и провайдер. Уточнение всех важных моментов — процесс, когда обе стороны должны «выговориться»: клиенту важно рассказать не только о том, что он хочет получить в результате и какие требования предъявляет к будущей системе, но и поделиться своими сомнениями, страхами, рассказать об особенностях компании.

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

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

«У нас такая корпоративная культура, что каждый документ мы согласовываем не меньше недели».

Мы бы выбились из графика, если бы клиент не рассказал об особенностях согласования документов в компании.

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

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

Советы заказчику:

• Уже на подготовительном этапе согласуйте даты очных встреч команды интегратора с вашей рабочей группой: так руководители топ-уровня запланируют эти встречи заранее и примут участие в обсуждении.
• Зафиксируйте все договорённости этого этапа письменно. В дальнейшем именно результирующие документы подготовительного этапа подскажут, кто за что отвечает, какие ресурсы закладывались на каждую задачу и к какому сроку ждать результатов каждого этапа.

«Компромисс»: этап реализации

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

У заказчика есть представление об идеальном решении, а у провайдера — об идеальном внедрении. Но в любом проекте возникают ситуации, когда требования клиента разбиваются об ограничения системы, а видение консультантов об идеальном внедрении IT-продукта сталкивается с реальными бизнес-процессами компании. Скорость работы и качество результата будет зависеть от того, насколько обе стороны готовы уступать и договариваться.

На одном из проектов по автоматизации работы с Кадровым резервом мы с клиентом ещё на этапе продажи обсудили, что будем внедрять стандартное коробочное решение SAP SuccessFactors. Оно предполагает серьёзное участие менеджмента в HR-процессах: так, например, руководитель принимает активное участие в формировании ИПР сотрудника и мониторит его выполнение.

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

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

Совет заказчику:

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

«Терпимость»: тестирование системы заказчиком

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

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

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

Однажды мы внедряли систему постановки целей и на этапе реализации клиент высказал такое пожелание: «Завершать процесс постановки цели для всех сотрудников компании должен HR: он будет проверять формулировки целей на корректность и согласовывать их». На тот момент это пожелание казалось понятным и адекватным. Однако первичное тестирование системы показало, что такая настройка процесса не оставит HR-специалисту времени на другие задачи: всё его рабочее время будет уходить только на то, чтобы проверить, насколько корректно менеджер поставил цели своему сотруднику.

Мы изменили процесс — HR перестал быть в нём заключительным звеном. Вместо этого мы ужесточили правила постановки целей: добавили в систему чёткие инструкции и функцию проверки цели на корректность формулировки.

Советы заказчику:

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

«Передышка»: подготовка к ОПЭ

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

Советы заказчику:

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

«Испытание»: этап опытно-промышленной эксплуатации

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

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

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

На финальном этапе провайдер смотрит, насколько качественно внедрили решение, и вносит последние несущественные корректировки в систему по результатам работы пользователей. Заказчик оценивает, достигнуты ли цели проекта и какую пользу несёт система.

В результате

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

Источник : formatta.ru