Разработка корпоративного портала под ключ

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

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

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

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

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

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

Личный кабинет сотрудника

Профиль, роль, подразделение, доступные сервисы, уведомления и история обращений. Пользователь видит только те данные и действия, которые относятся к его полномочиям.

Заявки и согласования

Формы для разных типов запросов, последовательность согласующих, статусы, комментарии и уведомления. Для каждого процесса задаются обязательные поля и правила перехода между этапами.

База знаний

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

Панель управления

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

Корпоративный портал редко работает изолированно. До проектирования важно составить перечень систем, с которыми он должен обмениваться данными: кадровый и бухгалтерский учёт, CRM — система учёта клиентов и продаж, документооборот, сервис-деск, почта или корпоративный каталог пользователей.

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

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

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

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

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

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

Расскажите G&GApp, кто будет пользоваться порталом и какой процесс нужно перенести в цифровой контур первым. На встрече можно определить границы решения, обязательные интеграции и состав первой версии без лишних функций.