Новичок вышел на работу, но не знает, кто выдаёт ноутбук. Руководитель написал в чат, ИТ ждёт согласование, а инструкция лежит в старой папке. Корпоративный портал может связать этот путь в понятный процесс. Но одна главная страница с новостями проблему не решит.
В Гуси-Лебеди предлагаем проектировать портал от ежедневных задач сотрудников. Разберём функции, права, интеграции и запуск на условном примере компании с офисной и выездной командой. Сквозной сценарий: подготовка рабочего места новичка. Это учебный пример, а не результат клиентского внедрения.
Что такое корпоративный портал и когда он нужен
Корпоративный портал объединяет доступ к внутренней информации и сервисам компании. Сотрудник может искать коллег и инструкции, подавать заявки, проходить согласования или открывать нужную систему. Конкретный набор функций определяется процессами, а не обязательным списком модулей.
Начните с наблюдаемой проблемы. Например: заявку на оборудование отправляют в общий чат, исполнителя назначают устно, а статус приходится выяснять новым сообщением. Портал может дать форму, ответственного и историю, если компания заранее согласовала правила исполнения.
Отличайте портал от корпоративного сайта для клиентов. Внутренний сервис предназначен прежде всего для сотрудников. CRM организует работу с клиентами и сделками, документооборот управляет документами, чат помогает общаться. Портал может связывать эти инструменты, сохраняя их назначение.
Если проблема ограничена несколькими документами и существующее хранилище уже подходит, отдельный продукт может быть избыточен. До разработки корпоративного портала определите, какое затруднение он устраняет и кто отвечает за результат процесса.
Какие функции и разделы выбрать для сотрудников
Соберите повторяющиеся действия разных групп: офисных сотрудников, выездной команды, руководителей и внутренних служб. Посмотрите реальный путь заявки, а не только список пожеланий. Если после формы человек всё равно пишет знакомому исполнителю, выясните, чего не хватает: статуса, доверия к маршруту или ответственного.
| Раздел | Практическая задача | Что нужно согласовать |
|---|---|---|
| Справочник сотрудников | Найти нужного коллегу | Источник должностей и контактов |
| База знаний | Получить действующую инструкцию | Владелец и дата проверки |
| Заявки | Заказать оборудование или помощь | Маршрут и ответственный |
| Согласования | Получить решение | Полномочия и история |
| Новости | Узнать важное для своей работы | Аудитория и редактор |
Не включайте всё сразу. Для первой версии выберите законченные сценарии, которым нужны понятные вход, результат и обработка ошибки. Определить границы поможет подход к первой версии продукта. Недостающий модуль можно добавить позже, а незаконченный обязательный путь затруднит запуск.
Сравнивайте готовую платформу и заказную разработку на этих сценариях. Проверьте права, доступные интеграции, мобильную работу, экспорт и ограничения до выбора. Рассчитывайте не только запуск, но и лицензии, поддержку, обучение и доработки. Универсальной цены для такого набора задач нет.
Как описать процесс на примере рабочего места новичка
В нашем примере HR сообщает о планируемом выходе сотрудника. Руководитель подтверждает роль и нужный комплект оборудования. ИТ готовит учётную запись, исполнитель выдаёт технику, а новичок видит необходимые инструкции. Это предполагаемый маршрут, который компания должна утвердить под свои правила.
Для каждого этапа укажите входные данные, исполнителя, решение и следующий шаг. Что происходит при переносе даты выхода? Кто заменяет отсутствующего согласующего? Как поступить, если нужной техники нет? Такие вопросы определяют поведение системы лучше, чем перечень экранов.
Статус должен соответствовать выполненному действию. «Заявка создана» не означает «ноутбук подготовлен». Согласуйте понятные названия и право переводить задачу дальше. Сотруднику нужна возможность узнать, что происходит, без обязательного сообщения в чат.
Продумайте изменения и отмену. Если руководитель поменял комплект после согласования, исполнители должны увидеть актуальное решение. Не теряйте историю важных действий. До разработки испытайте прототип основных сценариев с теми, кто будет подавать и обрабатывать заявки.
Как настроить вход и права доступа
Успешный вход подтверждает личность пользователя, но не разрешает ему читать любой документ. Для сотрудника, руководителя, HR, ИТ и подрядчика согласуйте доступ к данным и действиям. Опишите также ограничения по подразделению, конкретному объекту и состоянию заявки, если они нужны процессу.
OWASP рекомендует минимальные необходимые права, отказ по умолчанию и проверку разрешений при каждом запросе. Скрытая кнопка не заменяет серверную проверку. Защищать нужно также файлы и прямые адреса ресурсов.
Проверьте доступ к чужой заявке и вложению под разными ролями. Поиск тоже не должен раскрывать закрытое содержание через заголовок или фрагмент. Если пользователь сменил подразделение или уволился, предусмотрите изменение прав и завершение доступа по согласованному процессу.
Для входа определите корпоративный источник учётных записей, восстановление и управление сессиями. Рекомендации OWASP по аутентификации рассматривают дополнительные меры для важных операций. Выбирайте их по требованиям проекта и проверяйте реализацию. Само наличие единого входа не доказывает безопасность портала.
Для телефона проверьте смену пользователя, выход и повторное открытие. Особое внимание уделите общим устройствам выездной команды. Понятный кабинет с разграничением доступа должен сохранять рабочий сценарий без смешения данных сотрудников.
Как связать портал с данными и поддерживать актуальность
Для каждого поля определите основной источник. Должность может приходить из кадровой системы, оборудование из системы учёта, инструкция храниться в базе знаний. Портал может показывать эти данные, обращаться к другому сервису или хранить собственную запись. Зафиксируйте выбранную модель до разработки.
Не создавайте конкурирующие копии без правил обновления. Если сотрудник изменил контакт в портале, должно быть понятно, куда попадёт изменение и кто может его подтвердить. При ошибке обмена пользователь не должен видеть старое значение как бесспорно актуальное.
Для интеграций портала с внутренними системами согласуйте идентификаторы, права сервисов, события и обработку повторов. Проверяйте недоступный источник, неполную запись и изменение структуры. Подробности рассматриваем в статье про контракт API и обработку ошибок обмена.
У контента тоже нужен владелец. Для инструкции укажите ответственное подразделение, дату проверки и способ исправления. Устаревший документ с красивой обложкой не становится полезным. Перед переносом соберите реестр, удалите из рабочей выдачи неактуальные дубли по согласованным правилам и проверьте поиск.
Сотрудник должен находить материал привычными словами. Испытайте поиск по названию процесса, короткому запросу и частой формулировке из чата. Объясните, куда обратиться, если ответа нет. Наличие поискового поля ещё не подтверждает, что нужная инструкция находится.
Как внедрить портал и проверить пользу
Запустите пилот на выбранном процессе с реальными участниками. Для рабочего места новичка проверьте полный путь: создание заявки, согласование, подготовка, выдача и доступ к инструкции. Сравните записи с фактическим результатом, а не только с отметками на экране.
| Проверка | Что подтвердить |
|---|---|
| Согласующий отсутствует | Работает установленный порядок замены |
| Данные изменились | Участники видят актуальное решение |
| Интеграция недоступна | Ошибка заметна и есть восстановление |
| Пользователь не имеет права | Закрытая информация недоступна |
| Сотрудник работает с телефона | Нужное действие можно завершить |
Подготовьте короткое обучение по ежедневным задачам. Покажите, как найти инструкцию, создать обращение и узнать статус. Назначьте владельца процесса, редактора контента и ответственного за технические ошибки. После запуска эти роли не должны исчезать.
Измеряйте то, что связано с исходной проблемой: завершение заявок, возвраты на доработку, время прохождения этапов или успешный поиск. Зафиксируйте метод и исходные наблюдения. Количество входов само по себе не означает экономию времени, а расчётный эффект нельзя выдавать за полученный.
В Гуси-Лебеди предлагаем принимать портал как рабочий инструмент. Сотрудник понимает следующий шаг, данные имеют ответственного, доступ проверен, а ошибки можно обнаружить и исправить. Именно такая связка позволяет оценивать дальнейшее развитие по реальным задачам команды.