Масштабовані робочі процеси
Одна й та сама система для команди рекрутингу з двох осіб та організації з придбання талантів із п'ятдесяти осіб.
Робочі процеси найму зазвичай ламаються двома прогнозованими способами: вони або настільки жорсткі, що підходять під процес рівно однієї команди найму і нікого іншого, або настільки вільні, що зростаюча команда втрачає узгодженість у той момент, коли над однією і тією ж воронкою працюють більше кількох рекрутерів. На цій сторінці описано конкретні точки конфігурації, які дозволяють робочому процесу Expertini масштабуватися в обидва боки без перероблення.
На цій сторінці
01Налаштовувані етапи конвеєра для кожної вакансії
Воронка за замовчуванням складається з семи етапів: подано заявку, скринінг, шорт-лист, співбесіда, оферта, найнято, відхилено, але це не є фіксованим глобально. Кожна вакансія може визначати власну послідовність етапів, тому масовий набір у роздрібній торгівлі може додати додаткові етапи скринінгу, тоді як один пошук керівника може скоротитися лише до подачі заявки, співбесіди та оферти. Конфігурація зберігається для вакансії, а не на якійсь окремій сторінці налаштувань, відірваній від конкретної ролі, до якої вона застосовується.
02Role-based permissions
Чотири ролі — власник, адміністратор, рекрутер і менеджер з найму — кожна бачить і може виконувати цілеспрямовано різну частину продукту. Менеджер з найму може переміщувати кандидатів і залишати відгуки щодо ролей, на які він проводить найм, без необхідності адміністративного доступу до біллінгу чи управління командою; рекрутери керують своїми воронками без можливості змінювати налаштування організації. Це стає ще важливішим у міру того, як команда переростає момент, коли всім обґрунтовано потрібен повний доступ до всього.
03Пакетні операції у великих обсягах
Оцінювання кожного кандидата у воронці окремо не працює для великої кількості претендентів. Одна дія переоцінює всі не оцінені заявки на вакансію за один прохід, враховуючи місячний ліміт кредитів на інтелектуальне оцінювання організації та коректно відновлюючи роботу в разі переривання на півдорозі — це зручно для вакансії, яка отримала двісті заяввок за вихідні та потребує ранжованого короткого списку до ранку понеділка.
Масове створення кандидатів і вакансій підлягає тій самій філософії: до 100 вакансій можна створити з єдиного завантаження CSV, а кандидатів можна додавати масово за допомогою CSV, вставленого масиву JSON або перетягування пакету файлів резюме безпосередньо, причому кожне з них автоматично розбирається та додається до бази талантів. Жоден із цих масових шляхів не обходить ту саму логіку валідації та дедуплікації, яку використовують форми для окремих записів — дублікат електронної пошти в масовому імпорті CSV пропускається точно так само, як і дублікат ручного введення.
04Що не змінюється зі зростанням обсягів
Базова методологія оцінювання, контрольний журнал для кожної заявки та модель прав доступу не поводяться інакше для 10 заявок порівняно з 10 000 — тут немає окремого «режиму підприємства» з іншими гарантіями. Масштабується кількість робочих місць на рівні плану, ліміт активних вакансій та щомісячний ліміт кредитів на оцінювання штучним інтелектом, а не механіка того, як працює оцінювання чи дозволи нижче.
05Що зазвичай ламається першим у міру зростання команди найму
Команди, які переходять від кількох рекрутерів до більшої функції залучення талантів, зазвичай стикаються з одними й тими самими проблемами незалежно від того, які інструменти вони використовують. Видимість воронки — перша з них: коли більше ніж дві-три людини переміщують кандидатів через воронку однієї вакансії, хтось неминуче запитує: «Хвилиночку, хто і коли перемістив цього кандидата?», через що кожна зміна етапу за замовчуванням маркується міткою часу та приписується конкретній особі, а не як додаткова функція аудиту, додана пізніше.
Несумісна оцінка з боку рекрутерів є другою проблемою, тісно пов'язаною з проблемою дрейфу, описаною на сторінці «Структурований найм» — двоє рекрутерів, які проводять скринінг на ту саму роль із дещо відмінними критеріями в голові, створюють пайплайн, який виглядає згладженим на поверхні (ті самі етапи, та сама дошка), але фактично застосовує різні критерії оцінки. А розповсюдження повноважень (credential sprawl) — це третя проблема: у міру зростання команди розрив між станом «усі мають повний доступ, бо так було легше, коли нас було троє» і станом «нам насправді потрібні дозволи на основі ролей» зазвичай настає раптово, як правило, одразу після помилки, пов'язаної з доступом, а не проактивно. Саме тому модель дозволів на основі ролей існує з першого дня, а не як шлях оновлення, який зростаюча команда має не забути налаштувати пізніше.
Архітектура та операції платформи
A1Як це побудовано в архітектурі платформи
Масштабовані робочі процеси is not a bundle of point products — it is a slice through one platform. Платформа навмисно рендериться на сервері: кожне представлення готується сервером додатків і надсилається як повний HTML, без клієнтського фреймворку, без сторонніх сценаріїв CDN і без конвеєра збірки між даними та сторінкою. Відображається те, що обчислив сервер — властивість, яка робить інтерфейс доступним для аудиту.
Усе збереження даних працює на єдиному пошуковому сховищі документів; кожен запит містить ідентифікатор організації як обов'язковий фільтр на найнижчому шарі запитів. Тому ізоляція орендарів є структурною — властивістю того, як складається кожен запит, а не політикою, яка покладається на те, що код додатку не забуде виконати перевірку.
Кожна можливість, згадана на цій сторінці, зводиться до зареєстрованого інструменту або конектора: каталог інструментів та каталог інтеграцій є відображеннями тих самих реєстрів, які додаток застосовує під час виконання, тому те, що описує ця сторінка, і те, що обмежує продукт, ніколи не можуть розійтися.
A2Операційна позиція та позиція аудиту
Скринінг є детермінованим та опублікованим — ті самі вхідні дані дають ті самі результати, жорсткі вимоги блокують, а не усереднюють, а методологія опублікована на сторінці досліджень. Дії, що стосуються зовнішніх систем, є явними та за журналюються для кожної події; звітність про використання агрегує ті самі журнали, які пишуть дії, а не паралельну систему телеметрії.
Усе, що виходить за межі шляху запиту — розсилка сповіщень, доставка вебхуків, ведення журналу активності, пошта — виконується у фонових потоках за принципом «надіслав і забув». Повільна зовнішня кінцева точка ніколи не призведе до зависання інтерфейсу, а помилковий побічний ефект реєструється, а не повторюється мовчки до виникнення суперечливості.
Усе написане належить вам: експорт у форматі CSV та застосунок Експорт даних охоплюють ті самі сховища, які читає сам продукт. Вихід відкритий так само, як і вхід — за задумом, а не як поступка.
Поширені запитання
Чи можуть різні вакансії мати різні етапи воронки?⌄
У чому різниця між ролями рекрутера та менеджера з найму?⌄
Чи пропускає масовий імпорт кандидатів перевірку, яку має ручне введення?⌄
Чи є обмеження на кількість кандидатів, яких можна оцінити одночасно?⌄
Короткий огляд
- Налаштовувані етапи пайплайну для кожної вакансії
- Чотири різні ролі дозволів
- Пакетне оцінювання CMS в один клік у великих обсягах
- Масовий імпорт кандидатів у форматах CSV, JSON та через перетягування резюме
- До 100 вакансій за одне масове завантаження CSV
- Той самий аудиторський слід і методологія за будь-якого обсягу
Перегляньте масштабовані робочі процеси на власному наймі.
Візьміть реальний опис вакансії на 30-хвилинну демонстрацію — безкоштовний пробний період у комплекті.
Замовити демо