Таблица, ATS или своя HR-система: как выбрать

Короткий ответ: выбирайте не по числу резюме, а по сложности совместной работы

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

Переход становится обоснованным, когда ломается координация: разные версии статуса расходятся, обратная связь живёт в чатах, руководители не понимают свою очередь действий, кандидаты получают повторные вопросы, а отчёт собирается вручную. Тогда нужно выбирать между готовой ATS, настройкой платформы и собственной системой — в зависимости от процесса, а не моды.

Сначала опишите фактический процесс найма

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

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

Когда таблицы действительно достаточно

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

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

Что даёт готовая ATS — и чего она не исправит

Готовая ATS создаёт единый профиль кандидата, этапы вакансии, историю действий, задачи, шаблоны коммуникации, отчёты и разграничение доступа. Официальная документация Greenhouse и Microsoft показывает, что зрелые системы различают роли администратора, рекрутера, нанимающего руководителя и участника интервью, а права могут зависеть от конкретной вакансии.

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

Настроенная платформа часто лучше разработки с нуля

Между готовой ATS и собственной разработкой есть практичный промежуточный вариант: настроить этапы, поля, роли, шаблоны, отчёты и интеграции в существующей платформе. Он подходит, когда основа процесса стандартна, а отличия бизнеса можно выразить конфигурацией и несколькими надёжными связями с почтой, календарём, сайтом вакансий или HRIS.

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

Когда собственная HR-система может быть оправдана

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

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

Права доступа и история решений — обязательные требования

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

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

Спроектируйте данные и сроки хранения до миграции

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

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

Проведите пилот на одной реальной вакансии

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

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

Матрица решения: оставить, настроить, купить или разработать

Оставьте таблицу, если процесс редкий, простой и контролируется одним владельцем. Выберите готовую ATS, если нужны стандартная воронка, совместная работа, история, отчёты и права доступа. Настройте платформу, если стандартное ядро подходит, но требуются свои поля, правила и несколько интеграций. Рассматривайте собственную систему, если уникальные сценарии критичны, повторяются и не поддерживаются рынком без постоянных обходов.

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

Источники

ICO: защита данных при найме и отборе

Greenhouse: уровни доступа в системе найма

Greenhouse: функции GDPR и сроки хранения данных

Microsoft Learn: роли в приложении HR Recruiting

HR-системы и автоматизация найма