14 ошибок при внедрении корпоративного портала и как их избежать

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

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

Как этого избежать?

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

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

Заручитесь поддержкой заинтересованных сторон и участников команды внедрения. Исполнитель и заказчик должны видеть одинаковую итоговую картину.

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

Как этого избежать?

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

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

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

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

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

Как этого избежать?

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

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

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

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

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

Как этого избежать?

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

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

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

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

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

Как этого избежать?

Сделайте простую форму обратной связи прямо на портале. Запустите чат-бот, в котором можно легко оставить предложения и замечания по порталу. Другой вариант — банк идей.

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

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

Как этого избежать?

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

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

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

Как этого избежать?

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

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

Делайте названия разделов и пунктов меню интуитивно понятными. В разделе с названием «Информация» может храниться все, что угодно. Это распространенный пример неудачного названия пункта меню.

Не делайте меню слишком большими — оптимально разместить 6-8 пунктов. Избегайте большой вложенности разделов — достаточно сделать 2-3 уровня. Выносите на главную страницу портала сервисы и быстрый доступ к разделам, которыми сотрудники пользуются ежедневно.

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

Как этого избежать?

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

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

Чтобы понять, какие разделы и сервисы востребованы на портале, важно анализировать поведение пользователей.

Классическая ошибка: «У нас отличный корпоративный портал, он стабильно работает и не требует вложений». Но если посмотреть в аналитику, оказывается, что порталом не пользуются.

Как этого избежать?

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

Задача корпоративного портала — стать единым окном для доступа к корпоративной информации и сервисам.

Хотите погубить свой портал? Превратите его в телефонный справочник, на котором периодически публикуются новости. Если в вашей компании для доступа к базе знаний, системе дистанционного обучения, таск-трекеру, совместной работе с документами сотрудникам нужно обращаться к разным системам и они не интегрированы друг с другом, то это скорее «зоопарк», а не digital workplace.

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

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

Как этого избежать?

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

Сотрудники не должны привыкать к разными интерфейсам и многократно вводить одни и те же данные в разные системы. Стандартный набор интеграций корпоративного портала включает: кадровую систему (1С ЗУП, БОСС кадровик, SAP), Active Directory, почтовый сервер. Также часто требуется интеграция с системой подбора персонала, дистанционного обучения, КЭДО, BPM.

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

Как этого избежать?

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

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

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

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

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

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

Как этого избежать?

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

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

Как этого избежать?

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

Реагируйте на все обращения пользователей. Разработайте SLA, который позволит сегментировать заявки в зависимости от типа и срочности. Для этого нужны 3 линии поддержки.

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

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

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

Как этого избежать?

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

Источник: РБК