Портал HR-процессов нужен не ради ещё одного кабинета. Его задача — собрать повторяющиеся действия сотрудников и HR в понятные маршруты: оформить выход, запросить отпуск, пройти адаптацию, получить справку или увидеть статус обращения. На практике хороший MVP обычно начинается с 2–4 сценариев, а не с попытки оцифровать весь HR сразу.
Когда HR-портал действительно нужен
Если один и тот же вопрос проходит через почту, мессенджер, таблицу и личные напоминания, компания платит за отсутствие единого маршрута потерянным временем и ошибками. Это не означает, что любой HR-процесс надо немедленно превращать в сложную систему. Сначала полезно измерить повторяемость, число участников, чувствительность данных и цену задержки.
- заявки сотрудников теряются между каналами или дублируются;
- HR вручную проверяет одни и те же поля и пересылает статусы;
- руководитель не видит, на каком шаге завис процесс;
- новому сотруднику приходится спрашивать, где найти регламент или форму;
- доступ к кадровым данным выдается шире, чем нужен для работы.
Хотите понять, какой внутренний портал нужен вашей компании? Напишите в Telegram или оставьте заявку: разберём процессы, роли и первый полезный контур.
Какие сценарии включить в первый релиз
Для первого релиза выбирайте не самые эффектные, а самые повторяемые процессы. Например, заявка на отпуск полезна как маршрут согласования, но её ценность появляется только вместе с понятными правилами, уведомлениями, журналом решений и ограничением доступа. Адаптация сотрудника может объединить чек-лист, документы, задачи руководителя и подтверждение прохождения этапов.
| Сценарий | Что видит сотрудник | Что получает HR/руководитель |
|---|---|---|
| Адаптация | чек-лист, материалы, вопросы | статус этапов и просрочки |
| Отпуск и отсутствие | форма, остаток статуса, история | маршрут согласования и журнал |
| Справки и документы | запрос и готовность | очередь, срок, ответственный |
| Изменение данных | что можно исправить самому | проверка и аудит изменения |
| Обучение | назначенные материалы и тест | результат и напоминания |
Как спроектировать роли и права доступа
Аутентификация отвечает на вопрос «кто это», но не объясняет, что человеку разрешено делать. Для HR-портала нужно отдельно описать роли, объекты и действия: сотрудник видит свои заявки, руководитель — заявки своей команды, HR — рабочий контур кадрового процесса, администратор — настройки, но не обязательно всё содержимое по умолчанию. OWASP рекомендует минимальные права и запрет по умолчанию, если правило явно не разрешает доступ.
- опишите матрицу «роль — объект — действие — условие»;
- проверьте горизонтальный доступ: один сотрудник не видит данные другого;
- проверьте вертикальный доступ: обычный пользователь не вызывает действие руководителя через API;
- добавьте журнал важных изменений и кто их выполнил;
- перед релизом протестируйте не только интерфейс, но и прямые запросы к серверу.
Почему форма — это часть процесса, а не просто экран
Форма должна подсказывать обязательные поля, сохранять понятный статус и объяснять ошибку текстом. W3C в WCAG 2.2 отдельно фиксирует требования к идентификации ошибок и подписям полей. Для HR-сценариев это особенно важно: сотрудник должен понимать, что именно исправить, а HR — получить данные в согласованном формате, а не разбирать свободный текст.
Как выглядит реалистичный MVP
В MVP можно оставить единый вход, профиль, 2–3 типа заявок, маршруты согласования, уведомления, поиск по внутренней базе знаний и базовый журнал. Необязательно сразу делать сложный конструктор процессов, мобильное приложение, десятки интеграций и полноценный кадровый архив. Эти функции следует добавлять после наблюдения за реальными сценариями и очередью изменений.
| Слой | В MVP | Позже |
|---|---|---|
| Пользователь | профиль и мои заявки | персональные рекомендации |
| Процесс | фиксированные маршруты | конструктор правил |
| Данные | поля и статусы | глубокая аналитика |
| Интеграции | почта/календарь при необходимости | зарплатная и ERP-системы |
| Контроль | роли и журнал | расширенные политики и отчёты |
Что подготовить до разработки
- соберите 5–10 реальных примеров заявок без персональных данных;
- назовите владельца каждого процесса и срок реакции;
- зафиксируйте роли и исключения, а не только счастливый путь;
- решите, какие сведения нельзя показывать соседним ролям;
- опишите критерии приёмки: статус, уведомление, права, ошибка, журнал.
Как Paladin Engineering может помочь
Paladin Engineering помогает провести discovery, разложить HR-задачи на пользовательские сценарии, спроектировать роли и собрать первый рабочий контур. В план разработки входят интерфейсы, серверная логика, интеграции, тестирование и правила передачи проекта. Такой подход позволяет обсуждать не абстрактный «портал для HR», а измеримый набор процессов.
Частые вопросы о HR-портале
Нужно ли оцифровывать весь HR сразу?
Нет. Начните с нескольких повторяемых процессов, где уже видны задержки и ручная работа.
Можно ли начать без интеграции с кадровой системой?
Да, если границы ручного ввода и последующей синхронизации зафиксированы заранее.
Какие права доступа обязательны?
Минимальные права, запрет по умолчанию, разделение своих и чужих данных, журнал критичных действий.
Нужен ли мобильный интерфейс?
Проверьте сценарии. Для коротких заявок адаптивный web-интерфейс часто достаточен на старте.
Как понять, что MVP удался?
Смотрите на прохождение ключевых маршрутов, долю ручных уточнений, ошибки и прозрачность статуса.
Что дать подрядчику для оценки?
Сценарии, роли, данные, интеграции, критерии приёмки, ограничения безопасности и список отложенных функций.
Как проверить портал до запуска
Попросите пройти один маршрут сотрудника и один маршрут руководителя на тестовых данных. Проверьте пустую форму, ошибочное поле, отмену заявки, повторное открытие и смену роли. Отдельно зафиксируйте, какие данные должны остаться в журнале и кто получает уведомление. Такая проверка выявляет не только дефекты интерфейса, но и пробелы в самом процессе. Это обязательный шаг.
Если задача уже созрела, начните с короткого discovery. Paladin Engineering поможет превратить список пожеланий в сценарии, backlog и проверяемую оценку.
Комментарии