Планфикс для HR (для подзадачи "найм")

[Александр Лещинский]

Это не "обмен опытом" в чистом виде, скорее изложение сырой идеи и просьба оценить/предложить более прямой метод, идеологически правильный
Появилась мысль добавить немного Smart-возможностей борщеваркам, которые (обычно) трудятся во всех компашках на "закрытии вакансий", а то там сейчас обычный "Адъ и Израиль", даже если в остальной части компании все более-менее адекватно.
Почему Планфикс? А почему бы и нет, если остальная часть ERP это Планфикс, и именно Планфикс можно вычурно выгнуть "подо все"

Ну а теперь - собственно тело

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

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

Готов выслушать идеи, если кому-то будет интересно и по силам - возможно и просто отдам контракт (но буду подглядывать из-за плеча: учиться)

[Илья Федоров]

Я вот так сделал описал это в статье в блоге.
https://blog.planfix.ru/получение-в-пла ... е-с-hh-ru/

Вакансия это "надзадача", соискатели на данную вакансию это подзадачи.
Если один соискатель рассматривается на 2 вакансий то это две подзадачи с разными надзадачами. В карточке контакта видим все такие подзадачи-резюме и переписку.
Это подходит для внутренего подбора.
Для внешнего возможно что идея одна заявка на подбор - один проект более правильная тема, чтобы можно было подключать к таким проектам команду компании заказчика и автоматом например подключать их по ролям в задачи-резюме например когда наступает этап представить потенциального кандидата уже представителю работодателя. Да и отчетность для заказчиков так проще делать.

[Dmitry Goncharenko]

открытая вакансия это проект, соискатель - задача (+ все так же контакт)

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

одновременно получается (в теории) много проектов открытых и море задач

Это не страшно, они хорошо расклассифицированы и ими удобно оперировать.

если вакансия=проект, то достаточно быстро даже на дорогих планах закончатся лимиты проектов

В платных тарифах нет ограничения по количеству проектов в принципе.

точно так же остается проблема неклассифицированной кучи контактов

В задачах-соискателях нужно делать контакт контрагентом. Тогда в его карточке всегда будет видно, в каких вакансиях он был соискателем (они будут отображаться в чек-листе и на панели задач).

есть сложности (или мне кажется) с вытягиваем сводки истории взаимоотношений с контактом для второго/третьего контакта: на этот раз со стороны работодателя.

Также решается привязкой контакта к задаче-соискателю в роли контрагента.

Еще по опыту: имеет смысл заложить в шаблон контакта поля с описанием его характеристик по важным параметрам (навыки, опыт работы и т.п.) в форматах, которые потом будут удобны для отбора - т.е. не просто текстом набивать "большой опыт работы в продажах" или "владеет Django и Laravel", а через поля, привязанные к справочникам, чтобы придерживаться общей классификации по каждому признаку. Тогда при открытии вакансии можно будет сразу сделать фильтр по контактам ("Продажник, уровень средний" или "Spring, Angular") и посмотреть, кого он принесет из тех, кто уже есть в базе.

Из интересного: люди делают воронку переходов соискателей по вакансии, чтобы видеть, сколько нужно на вход подать соискателей для закрытия вакансии условного продажника или программиста определенного уровня - это помогает в том числе регулировать бюджеты на всяких HH.ru и т.п. Для крупных компаний также представляет интерес воронка по рекрутерам - кто с какой эффективностью закрывает вакансию. Еще она полезна для оценки процента отсева на каждом из этапов - если, к примеру, при переходе от первого собеседования к тестовому заданию у этого рекрутера повышенный относительно других отсев, значит имеет смысл посмотреть на то, как он проводит это собеседование - возможно, он что-то делает не так. В общем, полезная штука, в том числе для KPI корпоративного HR-отдела.

[Александр Лещинский]

В задачах-соискателях нужно делать контакт контрагентом.

I beg you pardon, но я всегда считал что "контрагент" - это свойство сущности "проект", а не задача. И в карточке задачи он только показывается. Я не прав?

Еще по опыту: имеет смысл заложить в шаблон контакта поля с описанием его характеристик по важным параметрам (навыки, опыт работы и т.п.) в форматах, которые потом будут удобны для отбора - т.е. не просто текстом набивать "большой опыт работы в продажах" или "владеет Django и Laravel", а через поля, привязанные к справочникам

Эту (очевидную для меня) часть я просто писать не стал, потому что "ну а как иначе-то?"

[Dmitry Goncharenko]

I beg you pardon, но я всегда считал что "контрагент" - это свойство сущности "проект", а не задача. И в карточке задачи он только показывается. Я не прав?

Нет, это свойство на уровне задачи. Причем очень полезное.