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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Три вещи, без которых интранет умирает при любом качестве разработки, и ни одну нельзя купить вместе с проектом.

Первое — владелец продукта внутри компании: человек с правом расставлять приоритеты между подразделениями и сказать «нет» запросу на ещё один модуль. Иначе портал развивается по принципу «кто громче попросил».

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

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

Не обещаем вовлечённости. Портал делает работу удобнее, но не делает интересной корпоративную новость. Если задача звучит как «повысить вовлечённость», интранет — не тот инструмент, и честнее сказать это сразу.

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

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

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

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