50 корпоративных сервисов — это не цифровизация. Это квест для сотрудника
Есть корпоративные порталы, которые обещают стать «единым цифровым рабочим пространством».
А потом сотрудник открывает их и обнаруживает:
- отпуск оформляется в одной системе;
- пропуск — в другой;
- доступ к почте — через третью;
- переговорку надо бронировать где-то ещё;
- а узнать, что происходит с заявкой, можно, если вспомнить, кому именно ты писал две недели назад.
Формально цифровизация состоялась. Практически сотрудник всё ещё занимается поиском нужного человека.
Систем много, сотрудник один
Для бизнеса фрагментация сервисов выглядит вполне логично.
HR нужна своя система. IT — своя. Административной службе — третья. Где-то уже есть система электронного документооборота, где-то — сервис заявок, где-то — собственные приложения.
Каждая система сама по себе может работать прекрасно. Проблема начинается на стыке. Сотруднику совершенно неважно, какая именно система отвечает за его отпуск. Ему важно просто взять отпуск.
Он не должен думать:
«Так, это HR-процесс, значит, мне нужен такой-то портал, а если я хочу проверить статус, нужно зайти вот сюда».
Для сотрудника это одна задача. Для компании — потенциально пять систем, три интеграции и один человек, который в итоге всё равно отвечает на вопрос: «А где посмотреть статус?»
Именно здесь возникает идея единой точки доступа — не очередной страницы с двадцатью кнопками, а одного понятного входа во внутренние сервисы компании и это прежде всего не вопрос интерфейса, а вопрос организации рабочего процесса.
Что такое единая точка доступа на практике
Самый простой вариант — сделать страницу с карточками:
Отпуск | Командировка | Пропуск | Доступ к почте | Бронирование переговорной | Заявка в IT
Уже лучше.
Но если на этом остановиться, получится просто красиво оформленный список ссылок.
Настоящая единая точка доступа должна закрывать весь путь сотрудника:
найти сервис → создать обращение → отправить его → дождаться обработки → увидеть статус → получить результат.
То есть сотруднику не нужно помнить, где живёт тот или иной процесс. Он просто приходит в одно место. А дальше портал сам отправляет запрос туда, куда нужно. В этом сценарии корпоративный портал становится своеобразным «ресепшеном» компании. Только без сотрудника на ресепшене, который каждый день отвечает на 300 раз одно и то же: «А куда мне обратиться по поводу…?»
Как это можно собрать
В Инкоманд такой сценарий можно построить на нескольких базовых механизмах.
1. Каталог сервисов
Сначала описываем, какие сервисы вообще доступны сотруднику.
Например:
- отпуск;
- командировка;
- заказ пропуска;
- доступ к корпоративной почте;
- бронирование переговорной;
- заявка в IT;
- хозяйственная заявка.
Для каждого сервиса можно хранить не только название, но и описание, категорию, ответственного, срок исполнения и доступность. То есть это уже не набор кнопок, а структурированный каталог.
2. Отдельные формы для разных задач
Универсальная форма «Опишите вашу проблему» кажется удобной ровно до первой сотни заявок. Потом выясняется, что сотрудник написал:
«Мне нужен доступ».
К чему? Когда? Зачем? На какой срок? Кто согласовал? Начинается переписка.
Поэтому для каждого сервиса лучше сделать свою короткую форму. Для отпуска — даты и комментарий. Для переговорной — дата, время, помещение и продолжительность. Для доступа к почте — тип доступа и обоснование. Пользователь видит только те поля, которые нужны именно для его задачи. Меньше полей — меньше ошибок. Меньше ошибок — меньше уточняющих писем. Меньше писем — меньше нагрузки на поддержку. Редкий случай, когда UX можно довольно быстро перевести в деньги.
3. Статусы вместо магии
Отправить заявку только половина дела. Вторая половина начинается с вопроса:
«А что с моей заявкой?»
Если ответа нет, сотрудник начинает писать в HR, IT или административную службу. А сотрудник поддержки начинает искать заявку.
Поэтому у обращения должен быть понятный жизненный цикл:
Создана → На согласовании → В работе → Выполнена → Закрыта.
Причём важно не просто хранить статус, а показывать сотруднику, на каком этапе находится его запрос и кто сейчас его обрабатывает.
Это небольшая деталь интерфейса, которая способна заметно сократить количество повторных обращений.
4. А если процесс сложнее, чем «нажать кнопку»?
Большинство корпоративных процессов именно такие. Например, сотрудник запросил доступ к системе. Заявка должна попасть руководителю. После согласования — в IT. После выполнения — вернуться сотруднику.
Получается маршрут:
Сотрудник → Руководитель → IT → Сотрудник.
И таких маршрутов в компании могут быть десятки. Для этого в Инкоманд используется конструктор бизнес-процессов: можно описать этапы, исполнителей, согласования и переходы между ними.
В результате портал становится не просто «витриной сервисов», а рабочим контуром, в котором заявка действительно проходит весь путь от создания до закрытия.
Единый вход не означает «покажем всем всё»
Есть одна опасность. Можно собрать в одном месте вообще все корпоративные сервисы. И получить каталог на 300 пунктов. Поздравляем: теперь сотруднику не нужно искать нужную систему. Ему нужно искать нужную кнопку среди 300 других.
Поэтому единую точку доступа нужно сегментировать:
Новому сотруднику можно показывать сервисы адаптации и базовые HR-запросы.
Руководителю — согласования, командные сервисы и заявки сотрудников.
HR — кадровые сервисы.
Административной службе — помещения, пропуска и хозяйственные запросы.
При этом логика каталога остаётся общей, а содержимое меняется в зависимости от роли и контекста пользователя. Именно поэтому «единая точка доступа» не должен означать «одинаковый портал для всех».
Что делать с уже существующими системами?
Самое интересное начинается здесь. В реальной компании никто не просыпается утром с мыслью:
«Сегодня мы полностью заменим все корпоративные системы».
Поэтому единая точка доступа не обязана означать перенос всех сервисов внутрь портала. Часть процессов можно оставить во внешних системах, но дать сотруднику единый доступ через портал.
Например:
Каталог → карточка сервиса → внешний корпоративный сервис.
Или портал может получать данные из другой системы и показывать их пользователю в едином интерфейсе. Получается довольно прагматичная архитектура: не обязательно выбрасывать всё старое, чтобы сделать удобным путь пользователя.
Главный тест
Есть простой способ проверить, работает ли единая точка доступа.
Дайте новому сотруднику задачу «Оформи заявку на доступ к системе X». Не присылайте ссылку. Не давайте инструкцию.
Если первый вопрос будет «А куда заходить?», значит единая точка доступа пока не очень единая.
Если сотрудник открывает портал, находит сервис, отправляет заявку и видит её статус — задача решена.
Хороший корпоративный портал не демонстрирует сотруднику сложность ИТ-ландшафта. Он её скрывает.
Пусть архитектор знает, сколько там систем, интеграций и маршрутов. Сотруднику достаточно знать две вещи: куда зайти и что нажать. Остальное — работа ИТ. А у сотрудника и так достаточно интересной работы.