Как мы построили HR-систему в Notion
С ростом любой, а в особенности IT-компании, возникает потребность в расширении функции HR. Там, где еще вчера хватало только специалистов по рекрутингу и КДП, а лиды и руководители занимались адаптацией новых сотрудников своими силами резко возникает потребность в новых процессах: полноценный и качественный онбординг, работа над удержанием сотрудников, сбор и аналитика информации для прогнозирования и работы с рисками. И, помимо возникновения необходимости в HR специалистах более широкого профиля, возникает вопрос: куда собирать и как хранить все собранные данные, как автоматизировать эти процессы?
С ростом TrendTech мы столкнулись с этой дилеммой. Провели аналитику и протестировали различные HR-системы.
Основные задачи, которые мы хотели закрыть:
- Сбор и хранение информации по сотрудникам. Важно, чтобы это было в одном месте иметь эдакое “досье” с историей взаимодействий с сотрудниками, расширяемостью для учета изменения и внедрения новых процессов. Надо понимать, что хранить какую то чувствительную информацию вроде ЗП, документов сотрудника и прочего в Notion все же не стоит, и некоторые вещи мы оставили в 1С.
- Возможность проведения кастомизированной аналитики: подсчет текучести, конверсии с испытательного срока, быстрого поиска и фильтрации сотрудников по заданным параметрам (удаленка, отдел, другие специфичные фильтры)
- Автоматизация работы с персоналом. Помимо сбора и хранения, с данными должно быть удобно работать, иметь возможность удобной навигации по системе, иметь двусторонние ссылки между сотрудниками (рукводитель-подчиненный, ПМ-команда)
По итогу тестирования нескольких систем, которые сейчас доступны, мы пришли к нескольким выводам:
- Нет функционала, который закрыл бы наши актуальные задачи (см. выше)
- Много функционала, который нам сейчас не нужен, но который перегружает систему, тем самым мешая быстро ориентироваться по системе.
Конечно, мы могли доработать под себя Битрикс, которым уже пользуемся, могли заплатить за доработку одной из систем, НО! Профит, который бы мы получили получался сильно меньше чем затраченные средства.
Мы используем Notion как одну из основных систем для работы с данными, документацией, в качестве WIKI для сотрудников и многого другого. И так как я довольно неплохо владею Notion было решено попробовать реализовать систему именно в нем.
Данное решение с одной стороны закрывало наши запросы, и было абсолютно бесплатно, с другой. Возможно в дальнейшем с ростом компании мы реализуем нашу систему по другому и в другом месте (а может и сами разработаем? :)), но пока что текущий вариант более чем помогает.
Что мы в итоге сделали?
- Создали общую базу сотрудников с необходимыми для нас properties. На текущий момент у нас их более 19, что, с одной стороны избыточно, но с другой стороны дает возможность сортировать и фильтровать данные по нужным критериям.
- Создали несколько готовых фильтров по необходимыми для нас данными.
- Создали отдельно базу с событиями по сотрудникам и добавили фильтрованное отображение по каждому отдельно взятому сотруднику в карточку.
Позже пришли к мысли что общая база событий ценности большой не несет, а наоборот добавляет ограничений к возможности давать доступ например лидам к отдельно взятым сотрудникам. Но об этом позднее.
- Пролинковали всех сотрудников между собой (лиды, ПМ, при необходимости рекрутер). В карточке у ПМ можно увидеть его команду, у лида - кто входит в его направление. Выглядит это следующим образом в карточке лида:
Что мы получили:
- Информация по всем сотрудникам в одном месте.
- Уже посчитали базовую аналитику (текучесть на ИС, общая)
- Удобная навигация. Хочешь посмотреть кто в команде ПМ? Вот тебе сортировка по лиду! Хочешь посмотреть когда последний раз проводился one-to-one? Держи сортировку по дате последнего.
- Автоматизация процесса one-to-one.
Что сейчас надо доработать:
- Возможность лидам или ПМ добавлять информацию по проведенным one-to-one по своим сотрудникам в систему. В теории - все просто. Но на практике возникла необходимость сделать так, чтобы лиды видели события только по своим сотрудникам, а из-за единой базы событий по сотрудникам это стало практически невозможно. Плюс - если это делать, то надо будет делать по каждому сотруднику индивидуально вручную. Возможно, есть более простой путь, но я пока его не нашла.
- Собственно - разделить общую базу событий. В общем виде лично я ей не воспользовалась ни разу. Но видимо моя старая любовь к созданию огромных БД в Notion тут дала о себе знать на старте, так что пока терпим и собираемся с силами для переработки.
- Подчистить properties по сотрудникам, потому что некоторое делалось на энтузиазме, но в работе не пригодилось и теперь только засоряет базу данных.
Если у вас есть идеи как подобную систему можно было бы сделать лучше или свои примеры в других инструментах - буду очень им рада 🙂
Ну и так же, если будет интересно, в одной из следующих статей я могу сделать развернутый туториал по созданию такой же системы.