Корпоративный портал для сотрудников: зачем бизнесу интранет

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

Главное отличие портала от набора чатов и таблиц в том, что данные в нём связаны и у каждого действия есть владелец. Заявка на закупку не растворяется в переписке, а висит на ответственном со сроком. Смена закрыта не словами в чате, а записью в системе. Через полгода на эти записи можно опереться: кто обслуживал гостя, кто подтвердил бронь, какая версия регламента действовала в марте. Это и есть практическая разница между корпоративным порталом и общим чатом: портал оставляет след, чат оставляет ощущения.

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

Чего корпоративный портал не делает, если его спроектировали честно: он не заменяет мессенджеры и не становится ещё одной лентой новостей, которую никто не читает. Портал нужен там, где есть повторяющиеся операции с ответственными и сроками. Если у вас пять человек и один процесс, портал избыточен, достаточно CRM и общей папки с документами. Интранет для компании начинает окупаться, когда появляются смены, объекты, роли и передача работы между людьми.

Коротко, из чего состоит ценность портала:

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

Рабочий минимум обычно собирается из шести блоков. Их не обязательно запускать одновременно: нормальная практика это два блока на первом шаге и расширение по мере того, как команда привыкает фиксировать работу в системе.

В нашем кейсе цифровизации сети банных комплексов в Санкт-Петербурге портал сотрудника закрыл именно операционный слой: визиты, услуги и кафе. Сеть из 5 комплексов до этого работала разрозненно, бронирование кабинок, обслуживание гостей и продажи в кафе жили порознь, и данные не сходились в одну картину. Теперь бронь ставится в «шахматке», внутреннем приложении Битрикс24, где администратор видит занятость по комплексам и ставит брони в наглядной сетке, а POS-касса кафе работает через Битрикс24 REST и остаётся частью общего контура, а не отдельной кассой сбоку. Там же работает механика лояльности с выпуском сертификатов и абонементов. Решение в проде, мы ведём действующее сопровождение портала.

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

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

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

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

Проектировать роли удобно простой матрицей: роль, объект данных, разрешённое действие. Матрица на одну страницу экономит недели переделок и сразу показывает дыры: например, что никто не отвечает за отзыв доступа при увольнении. Если у вас уже есть CRM, роли портала стоит сверить с ролями в ней, чтобы не получить два разных набора прав на одни и те же данные.

Чек-лист перед тем, как рисовать первый экран:

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

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

Кейс сети банных комплексов это как раз смешанный путь. Основа коробочный Битрикс24, который уже был у клиента и который мы сопровождали, а специфика бань добавлена отдельными приложениями поверх: «шахматка» броней со своей базой данных, портал сотрудника с четырьмя ролями, POS-касса кафе через REST. Строить второй инструмент рядом было бы дороже и привело бы к расхождению данных о гостях.

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

Таблица с критериями развилки:

AI-ассистент по базе знаний это поиск ответов словами сотрудника. Человек спрашивает «что входит в услугу и сколько она длится», а ассистент отвечает по вашим регламентам и прайсам со ссылкой на документ, вместо того чтобы сотрудник листал папки и дёргал старшего по смене. Технически это RAG, то есть генерация с опорой на найденное: простыми словами, модель перед ответом находит нужные фрагменты в ваших документах и отвечает по ним, а не по общим знаниям из интернета.

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

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

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

С чего начинать подключение:

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

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

Если вы примерно понимаете, какой процесс хотите собрать в одном месте, начните с бесплатного экспресс-аудита на 30 минут. Мы разберём, какие операции у вас повторяются каждую смену, какие роли нужны и что они должны видеть, что уже есть в Битрикс24 или в CRM, какие системы придётся связать и где достаточно настройки вместо разработки. По итогам у вас остаётся состав работ по этапам и понимание, что реально запустить на первом шаге.

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