Почему срываются проекты внедрений (на примере HR-автоматизации)

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


На конференциях по темам HR и e-learning спикеры могут поделиться факапами. Но подаются они чаще всего под “соусом” фана. То есть это провалы и неудачи, вызывающие недоумение или восхищение. Реально мало кто готов выйти на сцену и рассказать горькую правду.


В этом посте сделана подборка реальных причин неудачных проектов по HR-автоматизации из различных дискуссий экспертов: как со стороны заказчиков, так и со стороны поставщиков ИТ-решений.

Семь причин, почему срываются проекты внедрений HR-автоматизации


1. В больших компаниях слишком много лиц, которые принимают решение о проекте.


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


2. Техническое задание на покупку HR-системы или LMS составляет ИТ-специалист, который не понимает задачи.


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


3. Компании покупают HR-систему или LMS без понимания того, для какой конкретно задачи понадобится этот функционал.


Сейчас действительно технологии меняются быстро и за всем уследить сложно. Может показаться, что вариант купить что-то инновационное и трендовое избавит вас от необходимости вникать в функционал системы. Но реально это не так. Вначале должна стоять задача, а потом уже выбор инструментов для ее реализации. Вероятность того, что универсальный коробочный функционал подойдет именно вашей компании под ваши цели: 50/50. Или подойдет, или нет. Попытки купить, то что в трендах, и добиться WOW-эффект, могут быть плачевными. Поэтому разобраться в инструментарии системы важно до принятия решения о покупке. Если нет возможность сделать это самостоятельно, можно обратиться к тем же провайдерам, которые помогут определить: подходит ли под вашу задачу функционал данной системы.


4. В техническое задание на покупку HR-системы или LMS добавляют новые задачи уже на этапе тендера.


Такая ситуация одинаково нежелательна и для заказчика, и для поставщика системы. Когда ТЗ продумано и предварительно согласовано, у обеих сторон есть понимание задачи и правил сотрудничества. Изменения на этапе тендера сбивают договоренности, не дают возможности спокойно переосмыслить проект с учетом изменений и становятся источником потенциальных рисков. Новые задания это потенциально появление других ЛПР или бизнес-процессов, с которыми нужно будет “подружить” новую систему. Поэтому лучше обо всем договориться на берегу.


5. У проекта нет бюджета для дальнейшего развития.


Как человек, который семь лет проработал в HR-подразделениях, я понимаю в этой сфере как сложно с бюджетом. Ведь это направление, у которого цель - сэкономить ФОТ, затраты на обучение, расходы на неэффективных сотрудников и в том же духе. Поэтому обоснование покупки системы HR-автоматизации ли LMS сложная задача. И порой радостной новостью становится уже то, что выделены средства хотя бы на покупку. Но любая ИТ-система, проект требуют ресурсов для развития. Иначе сэкономленные деньги станут напрасными затратами на то, что не получится использовать в дальнейшем. Поэтому в стратегии внедрения и развития предусматривают не только план по задачам, которые будет решать система в ближайший год, два, три, пять. НО и по тому, какие ресурсы (денежные, человеческие, информационные, временные) понадобятся в дальнейшем. Это могут быть расходы на лицензию или подписка оплаты на количество пользователей, техническая поддержка, приобретение дополнительных модулей, доработки.


6. У проекта меняется руководитель или команда, и все начинается с нуля.


Риск того, что проект будет перезапущен, существует на разных этапах. Если придется только переписать техническое задание, это практически рядовой случай. А вот если желание обнулиться возникает сразу после старта или после нескольких лет сотрудничества, становится неприятно. Вопрос “Какую LMS платформу выбрать” постоянно конкурирует с вопросом “Менять ли LMS платформу?”. И чем больше предложений появляется на рынке, тем чаще появляется возможность выбора. Новый менеджер проекта может раскритиковать подходы своего ушедшего из компании коллеги и решит сменить HR-систему. Топ-менеджер может усомниться в эффективности онлайн-обучения и распорядится о тендере на покупку новой системы. Руководитель ИТ-направления скажет, что новая система не была с ними согласована, иначе он бы сразу предупредил о сложностях в интеграции данных. А руководитель отдела безопасности посмотрит на результаты успешного пилота и вынесет вердикт: система не подходит, так как большие риски утечки информации.
Конечно, такие обстоятельства, как смена менеджера проекта, сложно предусмотреть. Но можно постараться учесть риски со стороны интересов ЛПР и максимально прояснить задачу компании, которая будет реализована с помощью ИТ-системы.


7. Система, которая одновременно развивается изнутри и снаружи, приводит к конфликту сторон.


Когда нет четкого понимания зон ответственности и когда команда не согласует свои действия, могут возникать конфликты в дальнейшем развитии системы. Например, когда провайдер что-то изменяет в системе со своей стороны (на основе ТЗ или  обращения заказчика в службу поддержки). А заказчик силами своих ИТ-специалистов параллельно настраивает, ну, скажем, интеграцию с CRM системой или системой учета рабочего времени. Результаты такой несогласованной работы будут непредсказуемыми. Поэтому так важно, чтобы у проекта HR-автоматизации или LMS системы был один менеджер проекта, который синхронизирует действия всех других участников.


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

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

Подготовлено для WebSoft

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

Как отработать на практике новые знания?

База знаний про онлайн-обучение и не только (лучшие статьи блога)

Профессиональные сообщества: зачем их создавать и как развивать?