Мащабируеми работни процеси

01Конфигурируеми етапи на подбора по длъжност

Работният процес по подразбиране е седем етапа — кандидатстване, скрининг, кратък списък, интервю, оферта, нает, отхвърлен — но това не е фиксирано глобално. Всяка обява може да дефинира своя собствена последователност от етапи, така че масово наемане в търговията на дребно може да добави допълнителни етапи на скрининг, докато едно търсене на изпълнителен директор може да се сведе само до кандидатстване, интервю и оферта. Конфигурацията живее в обявата, а не на някаква отделна страница с настройки, изключена от конкретната роля, за която се прилага.

02Role-based permissions

Четири роли — собственик, администратор, специалист по подбор и мениджър по наемане — виждат и могат да правят съзнателно различен дял от продукта. Мениджърът по наемане може да премества кандидати и да оставя обратна връзка за ролите, за които наема, без да се нуждае от администраторски достъп до фактурирането или управлението на екипа; специалистите по подбор управляват своите работни процеси без възможност за промяна на настройките за цялата организация. Това става по-важно с растежа на екипа извън точката, в която всеки разумно се нуждае от пълен достъп до всичко.

03Партидни операции при голям обем

Оценяването на всеки кандидат в пайплайн поотделно не е мащабируемо за повече от шепа кандидати. Едно единствено действие преоценява всяка неоценена молба за дадена позиция с едно минаване, съобразявайки се с месечния лимит на кредити за интелигентно оценяване на организацията и възобновявайки работата чисто, ако бъде прекъснато по средата – полезно за роля, която е получила двеста молби през уикенда и се нуждае от кратка селекция до сутринта в понеделник.

Създаването на насипни кандидати и работни места следва същата философия: до 100 работни места могат да бъдат създадени от едно CSV качване, а кандидатите могат да бъдат добавяни групово чрез CSV, поставен JSON масив или чрез пускане на пакет от CV файлове директно, като всеки от тях се анализира и се добавя към групата от таланти автоматично. Никой от тези масови пътища не заобикаля същата логика за валидиране и дедупликация, която използват формулярите за един запис — дублиращ се имейл в масов CSV импорт се пропуска по същия начин, както би се пропуснало дублирано ръчно въвеждане.

04Какво не се променя с растежа на обема

Основната методология за оценяване, одитната следа за всяко заявление и моделът на разрешения не се държат по различен начин при 10 заявления спрямо 10 000 — няма отделен „режим за предприятия“ с различни гаранции. Това, което мащабира, е броят места в нивото на плана, лимитът за активни позиции и месечният кредит за интелигентно оценяване, а не механиката на това как работи оценяването или разрешенията отдолу.

05Какво обикновено се чупи първо при разрастването на екипа по подбор

Екипите, преминаващи от няколко рекрутъри към по-голяма функция за привличане на таланти, са склонни да се сблъскват едни и същи няколко точки на триене, независимо от инструментите, които използват. Видимостта на пайплайна е първата: след като повече от двама или трима души местят кандидати през пайплайна на една и съща длъжност, някой неизбежно пита „чакайте, кой премести този кандидат и кога“ — ето защо всяка промяна на етап получава времеви печат и се приписва по подразбиране, а не като незадължителна функция за одит, добавена по-късно.

Непоследователната оценка сред различните специалисти по подбор е вторият проблем, тесно свързан с проблема с отклонението, описан на страницата за структуриран подбор — двама специалисти, проверяващи една и съща роля с малко по-различни ментални критерии, създават работен процес, който изглежда последователен на повърхността (същите етапи, същата дъска), но всъщност прилага различни стандарти. Разрастването на пълномощията е третият: с растежа на екипа пропастта между „всеки има пълен достъп, защото беше по-лесно, когато бяхме трима души“ и „всъщност имаме нужда от разрешения, обвързани с ролята“ обикновено пристига внезапно, обикновено точно след грешка, свързана с достъпа, а не проактивно — поради което моделът на разрешения въз основа на роля съществува от първия ден, а не като път за надграждане, който нарастващият екип трябва да не забравя да конфигурира по-късно.