Все знают о существовании HR-аналитики, многие хотят иметь что-то подобное в компании, кто-то уже попробовал, а часть компаний успела разочароваться. Почему? Ответ прост – качество услуг от внешних провайдеров не удовлетворяет потребностям рынка. В этой статье мы поговорим о некоторых проблемах из области работы с данными, которые позволят избежать разочарований, если вы решили воспользоваться услугами внешних провайдеров, либо провести исследование своими силами», — рассуждает Арам Фомичев, руководитель направления «Аналитика» Лаборатории «Гуманитарные Технологии».

Что происходит с HR-аналитикой?

Так уж случилось, что HR-аналитика, как и вся область Data Science и Machine Learning, на данном этапе развития, попала на пик популярности в Gartner’s Hype Cycle. Что это значит? Цикл популярности Гартнер – модель, которая описывает популярность технологии и ожидания от использования технологии во времени. В ней есть всего один максимум – пик завышенных ожиданий, и находится он в самом начале цикла – технология появляется, в нее все начинают верить и ждать невероятного, потом приходит разочарование, и дальше сообщество уже свежим взглядом оценивает, как можно применять технологию.

Чтобы было понятнее – проведем параллель с чем-то, профессионально близким читателю. Например, эмоциональным интеллектом. Многие помнят о том, что относительно недавно каждый день появлялись новые статьи о нем, было много тренингов развития ЭмIQ и он преподносился как абсолютный ключ к успеху в профессиональной и личной сфере. Затем все «наигрались», понемногу осмотрелись и поняли, что это лишь один из факторов влияния, о котором неплохо знать и уметь уместно использовать. Конечно, ЭмIQ это не совсем та технология в узком смысле, о которой говорят в Гартнер, но кривую ажиотажа можно легко увидеть и почувствовать на его примере.

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

Проблема растет из вполне понятных источников – аналитика сейчас находится на стадии бурного развития и популяризации, что порождает активное развитие услуг. Консалтинговые компании понимают, что потребность появляется, а рынок не покрыт. Рабочих рук не хватает, для проведения статистического аудита нанимают вчерашних (или сегодняшних) студентов технических ВУЗов, бросая их на амбразуры проектов из «реального мира». При этом, как правило, такие подрядчики редко понимают специфику данных, с которыми работают, для них это просто цифры – они могут отражать удовлетворенность сотрудников заработной платой, объем космического мусора в стратосфере, KPI по фроду менеджера по банковским продуктам, количество нерп на Байкале – методы работы с цифрами будут одни и те же. И это путь весьма классический, но, к счастью, на данный момент все менее распространенный.

Как следствие мы имеем серьезную проблему – это низкая технологичность оказываемых услуг.

Что делать?

Благо, само явление аналитики не ново, и разработаны различные стандарты аналитического цикла, которые проверены годами и практикой, хорошо задокументированы, но оставляют неограниченный простор для свободы самого процесса анализа (ключевое здесь – что логика процесса остается жесткой). К таким технологическим циклам можно отнести CRISP-DM, KDD, SEMMA, IMPACT и ряд других менее распространенных практик. Для чего они нужны? Все просто – это общая канва методологии построения аналитического исследования. Рассмотрим подробнее цикл на примере модели CRISP-DM и поймем, на каких этапах можно подстелить соломку, чтобы Ваша аналитика принесла максимум пользы для компании.

Сама методология является стандартом, который был впервые представлен в 1996 году в Брюсселе. После этого, стандарт несколько раз дорабатывался и перерабатывался, и на данный момент выглядит как шестиступенчатый итеративный цикл – осознание проблемы и взвешивание ситуации, сбор данных, подготовка данных для анализа, построение моделей, проверка их работоспособности и внедрение моделей в практику. А затем все по новой, поскольку происходит сдвиг парадигмы управления от интуитивного принятия решений к управлению компанией на основе данных, что заставляет анализировать огромные пласты данных. Мы обрисовали общий вид цикла, теперь пора углубиться в детали. В таблице ниже приведены отдельные шаги на каждом этапе, о которых мы подробнее поговорим дальше.

Пройдем последовательно все шаги на примере реального кейса.Как это выглядит в реальной жизни?

Формулирование проблемы

Сначала, необходимо провести первичную коммуникацию с заказчиком. Понять, как он видит проблему, погрузиться в специфику бизнеса, оценить, какие есть ресурсы (и временные, и технические). После чего, можно уже переходить на более детальное описание желаемого результата и составление технического задания, чтобы зафиксировать все шаги.

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

Кстати, что за «белые пятна»?

А к ним относятся такие вещи, как:

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

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

Сбор данных

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

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

После того, как наша база данных задокументирована, мы можем переходить к оценке качества исходных данных. Мы проверяем, есть ли значения, которые выходят за границы указанных диапазонов, есть ли пропуски в данных, есть ли неожиданные значения (например, в массиве появляется сотрудник с неопределенным полом, в возрасте 108 лет, который относится к инженерному подразделению). Таких данных быть не должно, но, если они появляются – должна быть четко определенная стратегия, что с ними делать. Оценили, исправили, можно двигаться дальше.

Подготовка данных для анализа

Следующие два этапа являются исключительно техническими, но отнимают основную массу времени. Они могут быть недоступны заказчику напрямую, но, тем не менее, должны быть отражены в отчете.

Во-первых, необходимо из всего массива данных отобрать релевантные. Данных может быть больше, чем нам необходимо. Там могут быть, помимо прочего, предоставлены музыкальные предпочтения сотрудников. С точки зрения исследовательских задач – данные очень интересны. С точки зрения бизнес-контекста их изучение означает трату лишних сил и денег. Мы отбираем нужные признаки, очищаем базу от неожиданных или пропущенных значений, создаем новые данные, если это необходимо (например, у нас есть данные об оплате труда сотрудников, данные об их переработках, мы можем посчитать новый массив – стоимость трудочаса сотрудника), затем сводим все данные из разных мест хранения (например, есть данные из систем 1С, из SAP, из старых корпоративных хранилищ), приводим их к нормальному виду и начинаем моделировать.

Построение моделей

Процесс построения моделей – задача творческая. Вариантов моделей много – классификаторы, регрессионные модели, ансамбли моделей. Нам необходимо заранее определить, какие модели нам потенциально подходят, провести несколько итераций построения моделей, оценить их качество – например, по предсказательной способности и точности – после чего можно переходить к отбору наиболее подходящих.

На данном этапе важно не увлечься. Например, в техническом задании мы отразили, что решение должно обладать 85% точностью предсказания оттока. Поднимать точность можно бесконечно. При этом, построение модели с 85% точностью может занять неделю. А подъем точности до 86% может занять дополнительный месяц. Поэтому какой порог зафиксировали – к тому и идем. Жаль терять потенциальную точность, но реалии бизнеса жестоки и сугубо инструментальны.

Оценка качества моделей со стороны бизнес-задач

Построили хорошую модель – идем к заказчику и вместе вырабатываем общий язык. То, что транслируется на языке математики – бизнесу не ясно. Ну, показали мы график предсказательной способности в зависимости от удовлетворенности – и что дальше? Ну, назвали мы этот график кривой ROC – а как это скажется на сэкономленных ресурсах HRD? Надо говорить на одном языке.

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

Внедрение решений

Здесь важно проработать детали в общих чертах: кто дает доступ к корпоративным системам, в каком виде планируется внедрять алгоритмы, в каком виде предоставляются результаты. Например, в нашем банке широко применяется SAP. Наша модель дает вероятностную оценку категории сотрудника (удовлетворен\не удовлетворен, в зоне риска\вне зоны риска). Необходимо заранее понять, кому результаты будут доступны, в каком виде они будут отображаться в системе, какие внутренние доработки должны быть произведены IT-отделом, чтобы все это качественно функционировало. После этого переходим к внедрению.

Внедрение начинается с календарного плана и с разделения зон ответственности, поскольку на данном этапе задействован и внешний исполнитель, в нашем случае – консалтинговое агентство, и внутренний – администратор SAP, и весь отдел IT со стороны заказчика.

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

По результатам проекта пишется отчет, который предоставляется заказчику. Данный отчет является зеркальным отражением ТЗ – что было выполнено, что не было выполнено. Если не было – то по каким причинам. Этот отчет является сигналом для обеих сторон, что проект подошел к своей заключительной фазе, и дальше будет происходить только ненавязчивый этап поддержки функционирования с обеих сторон.

И в результате

Перегружена ли по смыслу такая система работы – да, однозначно. Приводит ли она к ожидаемому результату – да, при правильном применении. Экономит ли она ресурсы и уводит от непонимания – на все сто процентов, если она изначально верно применяется. Поэтому, в подобных ситуациях, результат соответствует затраченным ресурсам.

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

Выводы

Давайте подчеркнем две важные вещи, которые могут помочь вам в будущем либо выбрать правильного внешнего исполнителя, либо направить внутреннего исполнителя в правильное русло:

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

И в целом:

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

Помните об этом, и HR-аналитика вас не разочарует.

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

До встречи в новых статьях и пусть ваши модели делают ваших сотрудников счастливее, а ваш бизнес успешнее!

Источник