Внутренний портал компании: что он должен уметь и во что обходится

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

За словами «корпоративный портал» стоят три разные системы

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

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

Третий уровень — рабочий инструмент. Внутри живут процессы целиком: маршруты согласования, роли, замещения на время отпуска, история решений. Портал перестаёт быть окном в 1С и становится местом, где работают каждый день.

Разница в стоимости между первым и третьим — не проценты, а разы. Поэтому разговор «сколько стоит портал» без этого различения бессмысленный.

Портал ничего не хранит — он показывает

Это главное про стоимость, и это же обычно обнаруживают в процессе, а не до начала.

Портал почти никогда не источник данных. Кадры и расчёт живут в 1С, задачи — в трекере, документы — в СЭД, доступы — в службе каталогов, а часть правды — в файле у конкретного человека на компьютере. Портал — витрина поверх всего этого, и его сложность определяется не тем, как выглядит витрина, а состоянием того, что за ней.

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

Мы делали внутренний портал промышленной компании — единый вход, данные и процессы внутри корпорации, интеграция с 1С, процессы в BPMN. Основная работа была не в интерфейсе. Она была в том, чтобы договориться, где лежит правда, и что делать, когда две системы отвечают по-разному.

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

Скучное, на чём всё ломается

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

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

Мобильный доступ. Значительная часть сотрудников работает без стационарного компьютера: цех, склад, объект, машина. Если портал открывается только с рабочего места, до половины компании он не доедет — а это ровно те люди, у которых чаще всего вопросы про график и расчётный лист.

Задержка данных. Если данные подтягиваются из 1С раз в час, об этом должно быть написано в интерфейсе. Подпись «данные на 14:30» стоит один день работы и снимает целый класс обращений вида «в портале одно, а в бухгалтерии говорят другое». Задержка сама по себе никого не смущает, если о ней написано. Смущает цифра, которая разошлась с бухгалтерией: после пары таких случаев сотрудники начинают перепроверять данные звонком — и портал превращается в лишний шаг перед тем же самым звонком.

Поведение при сбое. Недоступность учётной системы — это авария, и лечится она на своём уровне: резервированием, мониторингом, SLA. Но пока авария длится, портал остаётся единственным, что видит сотрудник. Пустой экран или вечный спиннер не объясняют ничего — человек решит, что потерялась его заявка, и пойдёт выяснять по старым каналам: писать в чат, звонить в кадры, дёргать руководителя. Сообщение «раздел временно недоступен, ваша заявка на месте» пишется за день и экономит десятки таких обращений.

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

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

Из чего складывается стоимость и как не переплатить

Смету обычно представляют как экраны, умноженные на сложность. На практике экраны — самая предсказуемая часть.

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

Самый надёжный способ не переплатить — начать не с портала, а с одного вопроса, который чаще всего приходит в кадры, бухгалтерию или АХО. Обычно два-три вопроса дают львиную долю обращений: «сколько у меня осталось отпуска», «нужна справка», «где мой пропуск». Первая версия, закрывающая только это, окупается понятным образом — снятыми обращениями, а не ощущением современности. И даёт побочную выгоду: вы увидите, как ваши данные ведут себя на живых пользователях, до того как построите поверх них большую систему. Расхождения между 1С и реальностью всплывут на одном сценарии, а не на пятнадцати сразу.

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

Главный риск — не технический

Внутренние системы редко умирают от плохой архитектуры. Они умирают от того, что ими не пользуются.

У сотрудника уже есть способ решить свой вопрос: написать кадровику, поймать руководителя в коридоре, спросить у соседа. Способ работает, и чтобы человек его сменил, портал должен быть быстрее, а не «правильнее». Заявление на отпуск в три экрана проиграет сообщению в мессенджере, даже если по регламенту так нельзя.

У портала появился способ выиграть эту конкуренцию — ИИ-агент. Сотрудник пишет обычным сообщением: «оформи отпуск с 10 по 24 июня» или «сколько у меня осталось отгулов» — агент разбирает запрос, сверяется с данными, заводит заявление в учётной системе и отвечает, что сделано. Формы в три экрана нет: портал конкурирует с мессенджером на его территории, а заявка при этом остаётся заявкой — с номером, статусом и следом в системе, а не договорённостью в переписке.

Два условия, без которых это не работает. Агент действует строго в правах сотрудника: видит и делает только то, что положено его роли, — это те же права, что и в остальном портале, а не отдельная договорённость с нейросетью. И на неоднозначный запрос он переспрашивает, а не догадывается: «отпуск с 10-го» — с 10 июня или июля? Лучше один уточняющий вопрос, чем отменённое заявление.

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

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

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

Коротко

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

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