Почему срываются проекты внедрений (на примере 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
