HR-автоматизация — истории успехов и неуспехов
Михаил Протасов
Посмотреть запись вебинара
Ошибка выжившего — то, почему я люблю обращать внимание не только на успешные, но и на неуспешные проекты.
Этот термин появился в следующей истории. Когда во время Второй мировой войны вылетали самолеты, часть из них возвращалась в аэропорты, а часть были сбиты. Инженеры, которые осматривали вернувшиеся самолеты, думали, что можно сделать, чтобы улучшить выживаемость самолетов. Смотрели, в какие места попало больше всего снарядов и где больше всего повреждений на самолете, и в этих местах предлагали ставить больше брони. Но среди инженеров были те, кто высказал такую мысль: как раз наоборот, нужно ставить броню на ту часть самолетов, на которой меньше всего повреждений. Почему? Потому что если снаряд попал в какую-то часть самолета и он вернулся, значит самолет может «пережить» такое попадание. А если снаряд попал в такие места, которые у вернувшихся оказались целыми, то самолеты погибали.
На самом деле видеть и решать надо именно те проблемы, которые были в неуспешных проектах.
Поэтому сегодня будут разные кейсы: те, в которых было все хорошо, и те, в которых все было плохо (не буду называть компаний). Я в этих проектах принимал участие или в качестве заказчика, или в качестве исполнителя, или в качестве стороннего консультанта.
Успешные или неуспешные кейсы мы рассмотрим по каждому из следующих принципов HR-автоматизации:
Целеполагание
Возможность доработок
Интеграция
Устойчивость
Agile
Сохранение компетенций
Пример со знаком «-»
В организации проводили тендер на автоматизацию обучения. Предполагалась и поставка контента, и автоматизация всего процесса организации обучения. Когда тендер был завершен, внезапно выяснилось, что победил подрядчик, против которого были некоторые из представителей организатора. Стали выяснять. Почему же возникли сомнения? Похоже было, что какие-то критерии не учитывались среди тендерных показателей. И действительно оказалось, что есть очень много заинтересованных лиц в этой автоматизации, но все абсолютно по-разному видят, что должно произойти дальше, после того как тендер завершится и начнется работа. У различных подразделений совершенно разные представления, часто конфликтующие между собой.
Было принято решение не заключать контракт (условия тендера это позволяли). В принципе, это не такой уж плохой кейс, потому что гораздо хуже, когда контракт выполнен, большое количество ресурсов вложено, но автоматизация провалилась.
Этот кейс хорошо показывает важность
- правильного целеполагания и
- координации между всеми участниками тех целей, которые ставятся на тот или иной проект.
Пример со знаком «+»
Еще один кейс. Организация решила автоматизировать HR-процессы. Было принято решение, что будет набираться команда внутрь, в штат, несколько человек, которые будут внутри организации отвечать за HR-автоматизацию. Мало того что было проведено целеполагание, но еще в момент, когда был принят руководитель этой команды, то вместе с его приходом был еще раз полностью проведен этот этап.
Этот кейс был успешным. Было успешно автоматизировано множество процессов, на основе их провели много выступлений, написали статьи — делились успешным опытом.
Принципы целеполагания
Я рекомендую продумывать, какие у вас цели. Если вы сформулировали цель и сделали это не формально, не лишь бы что-нибудь написать, а все-таки более конкретно, то это уже половина успеха.
Какие цели вообще могут стоять в области HR-автоматизации?
1. Управление по целям
Автоматизируем рекрутинг и хотим понимать, сколько у нас вакансий, какая эффективность рекрутеров, какая скорость закрытия вакансий. То есть мы вводим определенные метрики. Это можно сделать для чего угодно: и для обучения, и для системы премирования и т.д.
2. Контроль бизнес-процессов
- Например, мы не хотим, чтобы к оборудованию на производстве имел доступ человек, который не прошел обучение по работе с этим оборудованием.
- В одной компании был интересный кейс про информационную безопасность. Если человек не проходит обучение по информационной безопасности, то ему недоступен выход в интернет с рабочего места, потому что он создает дополнительные риски для безопасности корпоративной сети.
- Или в страховой компании: если страховой агент хочет заключать страховые контракты по какому-то определенному продукту, он должен пройти обучение. После этого у него появляется право подписания соответствующих страховых контрактов с определенными лимитами.
Если вы такие бизнес-процессы хотите контролировать, то без автоматизации это очень сложно.
3. Система аналитики
Например: нужна возможность анализировать эффективность обучения. Если мы обучаем продавцов, то мы можем провести такое исследование: правда ли, что продавец продает больше тех продуктов, по которым он прошел обучение?
У некоторых вызывает сомнение, что подобный анализ возможен, но есть множество кейсов, когда такие эксперименты проводили и были получены конкретные цифры. Там ключ в том, что должно быть автоматизировано не только управление персоналом, но и другие бизнес-процессы организации. Если это есть, то такая аналитика возможна.
4. Уменьшение ручной работы
Если мы хотим проводить оценку, если при этом у нас очень много людей, то мы можем все автоматизировать и потом не сводить все эти эксели. Если 10 человек — автоматизация небольшой эффект даст, но если 10 000 — ручная работа существенно уменьшится.
5. Скорость обмена данными
Допустим, рекрутеры ищут людей в разные города. В каком-то городе уволился сотрудник. Как быстро рекрутер узнает, что уже актуальна еще одна позиция в том или ином городе? Сколько времени проходит от заявления об увольнении до подписанной заявки на подбор? Бывает, что сначала отдел кадров проводит увольнение, только потом создается заявка, потом процедура согласования и только потом рекрутер узнает, а это недоштат. Это значит какое-то подразделение недоукомлектовано, и это сказывается на бизнес-процессах организации. Если есть автоматизация, то сообщить о вакансии можно, даже когда человек еще не уволился, а только планирует. Идея в том, чтобы обеспечить максимально быстрое поступление информации. Подбор — только один из примеров, то же самое может касаться самых разных бизнес-процессов.
Возможность доработок
То, о чем мы будем говорить в этом пункте, в первую очередь касается крупных организаций численностью от 1000 человек штатного персонала. Но если у вас небольшая организация, то многое из этого вам тоже будет полезно.
Пример со знаком «-»
Организация хотела автоматизировать один из бизнес-процессов. Они нашли подрядчика, который сказал: «Все, что вы хотите, уже есть в нашей системе. Вы ставите систему, и сразу же все заработает так, как вам нужно».
В тот раз в компании поставили себе этот софт. И потом поняли, что нужно все-таки что-то дорабатывать под их специфику. Выяснилось, что с учетом доработок стоимость проекта во много раз превышает исходную, и сроки оказались совершенно неприемлемыми. Это пример, когда на этапе закупки не был проработан вопрос — сможем ли мы дорабатывать систему под наши потребности и насколько это будет сложно?
Пример со знаком «+»
Другой кейс. В положительном примере, который уже упоминали здесь (когда в компании принимали команду разработчиков внутрь), как раз предполагались доработки этой системы. Система была выбрана такая, чтобы иметь возможность дорабатывать даже без подрядчиков, своими силами. Это был успешный кейс, потому что это решение было принято на старте.
На что я рекомендую обращать внимание?
1. Открытый код. Это означает, что можно посмотреть код, который реализует некую функциональность, его исправить и эту функциональность скорректировать.
Закрытый код означает, что посмотреть исходный код невозможно. Если код закрытый, то нужно обращаться к автору кода. И таким образом вы полностью зависите от того, кто написал этот код.
Если у вас открытый код, то вы можете обратиться к разным подрядчикам или вы можете сформировать компетенцию внутри компании.
2. Распространенность системы на рынке и количество специалистов и подрядчиков на рынке. Я рекомендую делать следующее. Посмотреть, как много специалистов и подрядчиков, которые могут дорабатывать систему. Вы можете сделать независимую от вендора проверку довольно легко. Как? Заходите на любой карьерный ресурс и вводите название системы в поиск. Вы видите, сколько компаний ищут специалистов с навыками работы с этой системой, и видите профиль специалиста.
Интеграция
Пример со знаком «-»
Ко мне обратилась организация с тем, чтобы получить консультацию по системе обучения, с которой они тогда работали. Их более-менее устраивало, как автоматизировано обучение, но они хотели бы, чтобы учетные записи появлялись автоматически. Каждый раз, когда нужно было еще кого-то обучить, им нужно было заходить и создавать учетную запись. Это отнимало много времени. Еще хотелось смотреть результаты обучения в привязке к бизнес-показателям сотрудников.
Когда они обратились к своему вендору, то он сказал, что инструментов для интеграции у них практически нет, и предложил, вместо того чтобы интегрировать свою систему с другими, все необходимые другие процессы перевести к ним.
Это заказчику не понравилось: и так уже есть зависимость от вендора, а если еще прочие процессы к нему перевести, то и зависимость значительно возрастает.
Это был довольно неудачный кейс, потому что компанию устраивало обучение, но они поняли, что его сложно будет развивать дальше.
Пример со знаком «+»
Более успешный кейс с интеграцией. Ситуация была такая.
В компании были система кадрового учета и система обучения, обе имели открытый код и могли быть интегрированы. Первая попытка, тем не менее, провалилась, в интеграции было огромное количество ошибок: какие-то сотрудники не передавались, какие-то передавались слишком поздно, какие-то дублировались.
Но в этой компании проанализировали ситуацию, сделали выводы и пошли на второй заход по интеграции. Он выглядел примерно так.
- Собрали лучшие практики, как передавать данные из их исходной системы, из системы кадрового учета.
- Написали документацию, как это делается в других интеграциях, как это делается на рынке.
- Решили, что система, которая принимает данные, должна подстраиваться под правила исходной системы.
Например, как мы будем учитывать, кто является руководителем?
- Мы можем поставить галочку у позиции — данный сотрудник является руководителем подразделения.
- Мы можем к каждому подразделению привязать, кто является его руководителем.
- Мы можем у каждого сотрудника указывать, кто является его руководителем.
Это организационно похожие вещи, но технически это три разных формата учета. Если в кадровой системе настроить один формат учета, а в принимающей системе другой, то с большой вероятностью у вас будут ошибки.
После того как этот проект был выполнен заново с учетом сделанных выводов, интеграция заработала прекрасно.
На что я рекомендую обращать внимание?
1. Применение технологий, в которых есть больше практики. Здесь я говорю про практику конкретной организации. Если ваши IT-специалисты проводили интеграции других систем, если они используют примерно одинаковый набор технологий, то и в новой интеграции нужно использовать тот же самый набор. Почему?
- Если у вас много технологий используется в разных интеграциях, то ошибки будут самыми разнообразными.
- Если же все примерно одинаково: в одной интеграции возникла ошибка, вы и ее поправили и сразу же можете поправить во всех прочих интеграциях.
Эффективность работы значительно выше, если следовать этому принципу.
2. Отслеживание качества и целостности данных. Возьмем пример с руководителями: вы хотите, чтобы система обучения знала, кто чей руководитель. Это необходимо, чтобы руководитель мог посмотреть, какое обучение прошли его подчиненные, или сформировать план обучения для них.
Если у вас в кадровой системе заполнено только 10%, а 90% информации отсутствует, то желательно это знать до старта интеграции. Я видел множество проектов, где это всплывало в самом конце. Все сделали, а потом выяснилось, что данные не заполнены или в данных много ошибок, или они были заполнены год назад и с тех пор не обновлялись.
Устойчивость
Пример со знаком «-»
Я встречался с примером, когда в компании минимум 4 раза на протяжении 10 лет полностью меняли систему, которую использовать для автоматизации HR-процессов. Все переделывали полностью с нуля с потерей всех прошлых наработок. Два раза из четырех шли по пути собственной разработки, но каждый раз забрасывали.
Пример со знаком «+»
Другая компания. Это было достаточно давно, и сейчас за этот проект я испытываю одновременно и гордость, и стыд. Стыд, потому что это был один из первых проектов, которые я вел как фрилансер, и там было довольно много неудач. Но проект был все-таки реализован и доведен до конца. Спустя несколько лет ко мне опять обратился этот же заказчик и попросил сделать некоторые доработки. Тогда я все же испытал некоторую гордость. То, что я сделал (хоть и были сложности во взаимодействии), потом точно служило этой организации несколько лет. И я рад, что получилось создать такую устойчивую систему.
Я рекомендую вам обращать на это большое внимание. Когда у вас стартует проект по автоматизации, подумайте, насколько он будет устойчивым, насколько эффективными будут инвестиции, которые вы вкладываете сейчас.
Как это сделать, как учесть эти факторы? Я рекомендую смотреть на следующее:
1. Максимум готовых решений. Чем больше используете готовых наработок, тем устойчивее будет ваш проект. А доработки — вести точечно, там, где есть несоответствия вашим бизнес-процессам.
2. Минимум технологий. Есть заказчик (руководитель подразделения или HR), есть IT-департамент, и есть внешний подрядчик. И часто бизнес-заказчик не обращает внимания, какие технологии будут использованы в доработке системы. А я рекомендую это делать. Чем меньше разнообразие технологий, тем проще будет вам в будущем найти людей, которые смогут поддерживать систему. Я за то, чтобы как можно меньший набор технологий использовать в ваших доработках.
3. Качество кода и архитектуры. HR-специалисту сложно оценить качество кода и архитектуры, это задача для IT, но стоит это всегда учитывать. Если у нас код некачественный, то какие будут последствия? Во-первых, если надо будет доработать эту систему, то доработка потребует гораздо больше времени. Это же касается не только доработок, но и поддержки. Как много времени понадобится, чтобы найти причину поломки? Это зависит от качества кода и качества архитектуры.
Что можно сделать?
- Найти того, кто будет перепроверять. Есть такая практика — code rewiew. Один разработчик написал, а другой, сторонний, независимый, посмотрел и сказал: «да, этот код я оцениваю как качественный» или «я вижу недостатки, вот их перечень, предлагаю их поправить». С такой практикой устойчивость разработки резко возрастает.
- Сохранять имеющиеся разработки. Очень часто программисты хотят все переделать. Это понятное желание и очень распространенное. Но все-таки более опытные разработчики, и я в том числе, за то, чтобы сохранять максимально то, что было. Могут быть ошибки, может быть что-то кривое, что-то неудобное. Но следует понимать, что когда мы все это переделываем, мы тратим довольно большие ресурсы и мы теряем накопленный опыт. Кривой код, возможно, решает ошибку, с которой ранее столкнулись. Если будем переделывать с нуля, опять повторно наступим на те же самые грабли. Ценность того опыта, который уже заложен в разработку, очень высока.
Agile
Это распространенный набор практик, он выходит за пределы только разработки.
Пример со знаком «-»
Одна организация собиралась автоматизировать HR. Тогда они были на этапе выбора программных продуктов и набора команды. Ко мне они обратились с задачей провести исследование: какие программные продукты подходят, какие требования предъявлять к команде внутри или к внешним командам.
Эти заказчики дали очень подробное описание того, что они хотят. Тогда я подумал: как круто, что люди так понимают свои потребности, что они так вложились в то, чтобы описать то, что они хотят. Я спросил, сколько времени они потратили на то, чтобы эти описания подготовить. Ответили — год: со всеми встречались, со всеми обсуждали.
Тогда я им оказал консультационные услуги и помог сформировать то, что им делать на следующих этапах. Сейчас я бы уже не стал так делать.
Почему? Следующий этап — тендера — продолжался еще год. А потом оказалось, что им порезали бюджет, и они закрыли проект.
Пример со знаком «+»
Другой кейс — успешный проект, где мне понравилось, как действовала организация. Она хотела автоматизировать адаптацию, чтобы люди быстрее обучались, быстрее выходили на уровень опытного сотрудника. Они не стали писать подробное описание — потратили на это примерно две недели. Часть была описана более подробно, часть менее. Я предложил начать с той, которая была описана более подробно — там было работы на один-два месяца, и уже можно было получить результат и начать получать преимущества автоматизации. Но это было точно не все, что нужно, — следующие шаги решили обсуждать позднее. Так мы и сделали. Было множество этапов реализации запроса. И на каждом следующем этапе еще что-то добавлялось в адаптации, в интеграции адаптации с другими процессами, добавлялись дополнительные целевые аудитории.
На что я рекомендую обращать внимание?
1. Частая и ранняя поставка результатов, mvp. На каждом новом этапе вы дорабатываете процесс с учетом того, что стало понятно на предыдущем, с учетом опыта взаимодействия с сотрудниками.
2. Изменения — это хорошо. Чем больше правок, тем лучше. Даже если правка приводит к тому, что существенную часть того, что было, нужно переделать: если мы поняли это через месяц, а не через год, то это очень хорошо. Полученный опыт позволяет уточнять, что будет дальше.
3. Ресурсы на неопределенный срок. Когда вы понимаете только первый ваш результат довольно точно, а следующие примерно, то непонятно, сколько нужно времени, сколько бюджета, чтобы реализовать весь проект. И многие организации говорят: нам надо знать бюджет, нужно заранее закладывать стоимость и сроки, и не может быть по-другому. Но я исхожу из того, что может. Можно найти много крупных организаций, которые работают этому принципу. Главное — правильно выстроить процессы, подумать, как это можно сделать. Можно найти много препятствий, но под каждое препятствие можно найти организации, которые с похожими трудностями успешно справились.
4. Agile-манифест. Рекомендую его загуглить и прочитать. Он короткий, переведен на много языков. Там более подробно написаны все принципы Agile. Они применимы не только к автоматизации, их можно применить к любым проектам.
Сохранение компетенций
Пример со знаком «-»
В компании уровень автоматизации был высокий, но в какой-то момент пришла новая команда. И система стала подкидывать сюрпризы: то сделала рассылку на всю компанию, что какой-то курс не пройден, то на главной странице портала появились какие-то бонусы, которые выдаются сотрудникам (они, действительно, когда-то выдавались, но сейчас уже нет). С опаской в этой компании ждали, что же произойдет еще через неделю, что еще сделает эта система, какие там еще новые сюрпризы могут оказаться.
Это довольно частая ситуацию: увольняются сотрудники, и никто не понимает, как работает то, что было сделано раньше.
Пример со знаком «+»
Другой пример. Ко мне обратилась организация, чтобы продолжить развивать то, что делала внутренняя команда. Было два разработчика, но так получилось, что они уволились оба. Ребята, видимо, в хороших отношениях оставались с работодателем, и оставили документацию. Они все подробно описали: как работает то, что они сделали, какие есть компоненты, что какой компонент делает. Наличие этой документации значительно упростило передачу следующей команде.
На что обратить внимание?
1. Дублирование функций. Если только один человек понимает, что происходит в вашей системе, риски максимальные.
2. Сочетание инхаус и аутсорс-разработки
3. Документирование
4. План роста зарплат. Когда вы будете поднимать зарплату своим разработчикам? С какими темпами? Если это не запланируете, то у вас разработчики будут меняться постоянно.
Как избежать ошибок, которые приведут к провалу автоматизации, и сделать ваш проект качественным и успешным? Давайте еще раз пройдемся по принципам, с которых мы начали и которые вам в этом помогут:
Правильное, не просто формальное, целеполагание
Возможность доработок
Интеграции с другими системами
Создание устойчивой системы
Использование Agile-подхода
Сохранение компетенций
