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