Внутренний портал должен сокращать путь сотрудника
Корпоративный портал полезен, когда сотруднику приходится искать регламент в разных местах, писать ответственному, вручную уточнять статус заявки и переходить между несколькими системами ради одного рабочего действия.
Задача портала — дать понятную точку входа во внутренние процессы с учётом роли, подразделения и полномочий пользователя.
Это не то же самое, что личный кабинет клиента. Для внешних пользователей, организаций, заказов и партнёрского самообслуживания предназначен отдельный контур — B2B-порталы и личные кабинеты.
Идентичность сотрудника — основа архитектуры
До проектирования экранов нужно понять, откуда система знает, кто вошёл.
Фиксируем:
- корпоративный каталог или другой источник учётных записей;
- правила входа и SSO, если он используется;
- подразделение и должность;
- роли и дополнительные полномочия;
- временное замещение;
- создание доступа при приёме сотрудника;
- изменение прав при переводе;
- блокировку при увольнении;
- технические и сервисные учётные записи;
- требования к журналу действий.
Портал не должен хранить собственную независимую копию организационной структуры без понятного механизма синхронизации.
Портал собирает рабочие сценарии, а не просто ссылки
Единое меню само по себе не делает систему рабочим порталом. Пользовательская ценность появляется, когда сотрудник может завершить конкретный сценарий.
Например:
- подать внутреннюю заявку;
- согласовать документ или запрос;
- найти актуальный регламент;
- увидеть свои задачи или обращения;
- получить доступ к нужному сервису;
- проверить статус;
- найти контакт или ответственное подразделение;
- получить внутреннее уведомление.
Для каждого сценария определяются владелец процесса, статусы, сроки, исключения и источник данных.
Заявки и согласования: портал или автоматизация процесса
Портал может быть интерфейсом для внутренних заявок, но он не должен автоматически становиться владельцем всей процессной логики.
Если основная задача — формализовать маршруты, статусы, правила, эскалации и исключения, её владелец — автоматизация бизнес-процессов. Портал может использовать этот процесс и показывать сотруднику его часть.
Такое разделение уменьшает риск превратить пользовательский интерфейс в единственное место, где скрыты критичные бизнес-правила.
Знания и внутренние документы
База знаний полезна только тогда, когда сотрудник может отличить актуальную инструкцию от устаревшей.
Нужно определить:
- кто публикует материал;
- кто подтверждает его актуальность;
- есть ли версии;
- каким ролям доступен документ;
- когда материал снимается с публикации;
- где хранится оригинал;
- нужен ли поиск;
- как связать инструкцию с реальным процессом или заявкой.
Если у заказчика уже есть система электронного документооборота или база знаний, портал не обязан её заменять. Он может давать сотруднику правильную точку входа и контекст.
Портал не должен становиться второй системой учёта
Внутренний портал часто зависит от кадровой, учётной, документной, сервисной и других систем.
Для каждой интеграции фиксируются:
- владелец данных;
- направление обмена;
- какие поля можно показывать;
- частота обновления;
- поведение при недоступности;
- аудит изменений;
- права технической учётной записи;
- тестовый контур;
- правила повторной обработки.
Если новый интерфейс вообще не нужен, а задача заключается в обмене между существующими приложениями, её следует вести как интеграцию и API.
Внутренний контур тоже требует строгого доступа
Фраза «система только для сотрудников» не является моделью безопасности.
Нужно учитывать:
- роль и подразделение;
- доступ к персональным и служебным данным;
- конфиденциальные документы;
- права руководителей и замещающих сотрудников;
- административные действия;
- срок сессии;
- удалённый доступ;
- журналирование;
- блокировку учётной записи;
- резервное копирование;
- восстановление.
Права должны проверяться не только тем, показана ли кнопка в интерфейсе, но и при выполнении действия на серверной стороне.
Как не превратить портал в монолит
Корпоративный портал может объединять пользовательский опыт, не объединяя все данные и бизнес-логику в одну базу.
Рациональная архитектура часто оставляет кадровые сведения в кадровом контуре, документы — в документной системе, финансовые данные — в учётной системе, идентичность — в корпоративном каталоге, а портал использует эти источники через согласованные границы.
Конкретная архитектура определяется по фактическим системам заказчика, а не по универсальному шаблону.
Запуск начинается с ограниченного набора сценариев
Попытка сразу перенести в новый портал все внутренние сервисы повышает риск и затрудняет приёмку.
Первый этап лучше строить вокруг нескольких законченных сценариев. Например:
вход сотрудника → поиск нужного сервиса → создание заявки → согласование → уведомление → проверка статуса.
Приёмка проверяет:
- корректность ролей;
- жизненный цикл доступа;
- прохождение штатного сценария;
- обработку отказа и возврата;
- интеграции;
- журнал действий;
- поиск и актуальность опубликованных материалов;
- поведение при недоступности зависимой системы.
После пилота можно подключать новые подразделения и процессы.
Где проходит граница этой услуги
Корпоративный портал — пользовательский внутренний контур.
Если требуется:
- внешний кабинет клиента, дилера или партнёра — B2B-портал;
- уникальное рабочее место под узкую операцию — заказная разработка ПО;
- автоматизация процесса без необходимости единого портала — автоматизация бизнес-процессов;
- обмен между существующими системами — интеграции и API.
SoftTech не заявляет внедрение HRIS, СЭД или другой конкретной платформы без подтверждённого проектного контура. Такие системы рассматриваются как существующие или потенциальные источники данных и интеграций.
Что подготовить для первого обсуждения
Для начала достаточно ответить:
- кто будет пользоваться порталом;
- какие три действия сотрудники выполняют чаще всего;
- откуда берутся учётные записи и структура компании;
- какие внутренние системы уже существуют;
- где сейчас хранятся регламенты и знания;
- какие данные имеют ограничения по доступу;
- какой сценарий можно проверить первым.
Пароли, рабочие токены и реальные выгрузки персональных данных через форму передавать не нужно.
Обсудить корпоративный портал →
Подробнее о специализированной команде разработки — на stdev.by.