У каждого продукта есть срок жизни. У интранета тоже. Это не означает, что по прошествии скольких-то лет он перестанет работать. Возможность им пользоваться никуда не исчезнет. Но как минимум он перестанет отвечать новым требованиям, процессам организации. Бывает, что в компании интранет существует давно, но поддерживался бессистемно или временный вариант на «скорую» руку так и остался постоянным. Руководители именно таких компаний приходят к нам за созданием более совершенного и современного продукта. Приходят за реновацией интранета. Это далеко не просто техподдержка, не разовые задачи или точечные улучшения. Это системное, часто достаточно масштабное, обновление. Работы по реновации включают следующие три этапа: Подготовка к реновации начинается, когда собственно обновление еще не стартовало. На этом этапе важно проработать и четко зафиксировать 3 момента: В миссию и цели участников реновации углубляться не будем. Как правило клиент приходит уже с четким пониманием куда и для чего двигаться. А вот с командой и бюджетом обычно сложнее. Остановимся на них. Определим концептуальные моменты, о чем нельзя забывать. Командой проекта не может быть один человек. Это всегда многослойная история. Как внутри агентства, так и на стороне клиента. Понимать роль участника важно, потому что она определяет степень его компетенции в проекте, зону влияния и ответственности. Так мы избегаем дискоммуникации и путаницы. Например, в проекте для Первой грузовой компании коммуникация трехуровневая. Менеджер проекта общается с рабочей группой, на уровне проектного комитета общается аккаунт-менеджер, а директор агентства — на уровне управляющего комитета. Приступая к вопросу реновации, клиенту нужно определить ключевых личностей в команде по следующим «должностям». Идейный вдохновитель, евангелист, который знает куда и зачем идти. Он идет впереди всех. В нашей практике без такого человека проекты получали негативный сценарий: затухали, останавливались, пропускали этапы. Он занимается оперативным управлением: следит за ходом выполнения проекта, взаимодействует с подрядчиком, контролирует качество и сроки реализации. Иногда совмещает работу с ролью стратега в процессе реновации. В структуре Заказчика должен быть сотрудник или команда, отвечающая за вопросы безопасности, интеграции. Именно эти сотрудники будут помогать в технических вопросах от подрядчиков, предъявлять техтребования к реализации, принимать решения об использовании старых или новых мощностей для обновленного портала. Для эффективного обновления нужны носители знаний о процессах компании и нюансах работы в ней. Это те, для кого создается интранет — эксперты, консультанты, представители разных подразделений заказчика, активисты из числа рядовых сотрудников. Как правило, они предлагают изменения, но не принимают решение. Работы по реновации не рассчитаны на короткую дистанцию и будут идти более месяца, двух. Здесь важно определиться, кто поддерживает актуальность информации в старом пространстве. Ведь появляются новые документы, доступ к которым нужно дать всему коллективу, запускаются внутренние проекты, ведутся задачи. Пока обновленный портал не запущен, прежний интранет должен оставаться рабочим. Мы всегда рекомендуем выработать регламенты и завязать на этом сотрудников, а ответственных включить в рабочую группу. В проекте реновации портала БайкалСи проблема с актуализацией была решена так. Заказчик завязал квартальные премии на контенте и отсутствии жалоб. Контент актуальный — есть премия. Причем распространяется это требование в том числе на руководящие должности, тем самым в БайкалСи ещё и подталкивали руководство к участию в общественной портальной жизни. Публично вывесили информацию о владельцах разделов, чтобы к ним можно было обращаться с вопросами и правками. Это сработало. Людям стало то ли стыдно, то ли жалко времени на ответы пользователей, но контент стал обновляться регулярно. Когда заказчик принимает решение о реновации, то важно, чтобы он для себя определил порог финансирования. Обновление портала — серьезная инвестиция, и такие работы должны учитываться в общем бюджете компании, закладываться заранее. Плюс это длительная история, так как легким рестайлингом по нашей практике заказчики не ограничиваются. Мы предлагаем рассматривать траты на интранет, как такие же траты компании на внутреннее обустройство, на кофе, чай, мебель, канцелярию. Под таким углом вложения воспринимаются легче. Для наглядности можно рассчитать, какое количество чашек кофе в месяц на одного сотрудника равно бюджету проекта за три года. Почему ориентация именно на три года? Как правило, таков срок жизни любого IT-проекта. Потом он требует реновации или доработки. Меняется и бизнес, и подход, и масштаб, требования, технологии. Если рассмотреть компанию порядка 5000 сотрудников, то получается, что 54 млн. — не так много. Всего две чашки в месяц на сотрудника. Когда определились с командой и бюджетом, можно двигаться в проект. На этом этапе мы превращаем запрос «сделайте что-нибудь с нашим интранетом» в четкую стратегию и описание, что именно, для кого и как делать. Многоэтапный процесс агрегации помогает выявить и учесть потребности целевой аудитории, согласовать структуру будущих работ по реновации. Все собранные на этапе данные идут в основу двух базовых документов проекта — дорожной карты и устава проекта. В агрегации мы следуем двум принципам: Общение для сбора требований охватывает всю вертикаль компании. Важно не упустить значимые ниши, не ограничиваться только узкими пожеланиями руководства. Мы сталкивались с проблемой, когда каждый уровень заявлял разные потребности. Топы говорили о задачах бизнеса. Это верхнеуровневые, глобальные задачи, они не раскрывают реального запроса. У руководителей подразделений были свои боли, страхи. Непосредственно рядовые сотрудники, для которых делается интранет, говорили о рутинных проблемах. Сотрудники компании N в один голос говорили, что им нужен расчет и согласование «важных показателей». Спросили у представителей IT-блока — такие функции ни в одной системе не реализованы и в планах пока нигде не стоят. Спросили у топ-менеджмента, те ответили — да, это важная приоритетная задача. Зеленый свет! Спроектировали, согласовали с рабочей группой, отправили на согласование по всей компании, но процесс застрял на одном из руководителей, он постоянно искал, за что зацепиться. То одну мелочь поправить, то другую. Процесс вроде не стоит, но и не идет. Оказалось, что у этого сотрудника, который в будущем и должен был реализовывать задуманное с точки зрения организации, просто нет времени. Позже выяснилось, что он ещё и обиделся, что его не позвали в проект. Мораль: нужно выявлять не только потребности, но и проблемы, которые могли бы помешать реализации. Налаживайте мосты сразу, даже с недоброжелателями. Собственник одного из производителей оборудования поставил задачу: сделать новый сайт. Современный, технологичный, продающий. Изучили пользователей, пообщались с сотрудниками, руководителями, директором по продажам, построили CJM, реализовали прототип, дизайн. В компании принято согласовывать дизайн с собственником бизнеса, пришли к нему. И тут он говорит: — Я просил сделать сайт «продающим», а вы сделали сайт, после просмотра которого мне хочется взять трубку и мгновенно позвонить! — Ну да, чем больше звонков — тем больше продаж, статистика это подтверждает — все переглянулись, а Директор по продажам немного напрягся. — Моя компания — бутик в своей сфере, мне нужны только платежеспособные клиенты, которые готовы потратить на меня много денег. И они должны понимать это сразу, а не после разговора с менеджером! Сайт должен отсечь всех ненужных и на выходе получить готовый заказ с итоговой ценой, чтобы менеджеру оставалось только выставить счет на оплату. Я не хочу раздувать штат и тратить время своих драгоценных специалистов на общение со всеми подряд. Мораль: обязательно пообщайтесь с руководителями и не постесняйтесь задать ему глупые вопросы на уточнение. Прежде чем предложить конкретные решения по запросам, нужно разобраться, кто именно пользуется, мог бы пользоваться интранетом, какие задачи ему необходимо решить и с какими проблемами сотрудники сталкиваются в процессе. Для выяснения всего этого мы применяем два подхода: При обсуждении задачи о создании электронной заявки на такси выяснилось, что топы, руководители и обычные сотрудники заказывают такси совершенно разными способами. Но, когда такси нужно быстро или для важного клиента, обычный сотрудник оказывается в обстоятельствах топа — для заказа достаточно позвонить секретарю. Сразу предупредим, что в таком процессе, как агрегация, трудно представить четкий план действий. Часто этапы живут в параллели. Реальность заставляет возвращаться с одного на другой и проходить его по новой. Вы не сможете выделить потребность без небольшого интервью. И провести грамотное интервью по запросам без понимания потребности. Количество запросов от разных структур может зашкаливать. Важно не хвататься за всё одновременно, а выделить действительно значимые потребности. Те, на которых сходятся сотрудники с разных уровней. Задачи топов, запросы сотрудников и статистические данные (обращения в техподдержку, цифры и метрики) всегда нужно совмещать, подходить к задаче с разных точек. Вполне может выясниться, что слова и жизнь отличаются. И то, что руководители заявляют как «очень важное», таковым будет лишь для них. На слова надо смотреть скептично. Как может выглядеть выявление приоритетных потребностей хорошо покажет проект реновации для гипермаркетов «Глобус». Работа по определению реальных запросов и приоритетности строилась на нескольких источниках: спрашивали у руководства, проводили живой опрос в гипермаркетах, анализировали конкретные запросы по форме обратной связи, анализировали непосредственно метрики, реальные поведенческие факторы. Как видно на схеме, не все заявленные требования от бизнеса были нужны клиентам, а что-то показал только опрос пользователей. После определения явной потребности, нужно подготовиться и провести глубинное интервью. Не забывая о принципах многоуровневости, подходе персон и обстоятельств. Блок подготовки к интервью включает: В самом интервью нужно общаться глубоко и устно. Всегда задавать вопрос «Почему? Какие мотивы у именного такого решения задачи?» Фиксируйте каждую деталь. Бэклог важен, потом вместо перепроверки гипотезы решения задач, можно просто обратиться к зафиксированным требованиям. На основе интервью и анализа действующих систем создается карта пользовательского опыта (CJM). Карта визуализирует путь пользователя, ожидания и барьеры на этом пути. Глобальная цель любой карты — понять в какой момент и как сделать взаимодействие сотрудника с цифровой средой наиболее удобным, улучшить цифровое пространство. Есть разные подходы к формированию карты, мы строим CJM из следующих блоков: Для дочки АФК Система мы реализовывали процесс сдачи авансового отчета. У компании много торговых представителей в разных точках России, они перманентно находились в командировке. Возникала потребность сдавать авансовые отчеты вовремя: выслать документы, подписать у бухгалтера, руководителя, провести в 1С. Пока предыдущий отчет не сдан, новый транш не выдается. Разумеется, было много ошибок, документы терялись, затраты на корреспонденцию росли, сотрудники были недовольны. Мы предложили решение состоящее из двух релизов: Столкнулись с одной сложностью. У командировочных на руках были корпоративные мобильные телефоны или планшеты, не было ноутбуков. Подписывать ЭЦП нужно было в облаке. Реализовать ЭЦП без токенов достаточно проблематично, но решение нашли. Кстати, решение используется до сих пор, а это уже почти три года. Помимо косвенной пользы в виде ускорения процессов, сокращения ошибок, была явная выгода в виде экономии на курьерской доставке. Такие суммы экономии можно смело писать в бизнес-требования, с финансовыми доводами сложно поспорить. Когда работа по агрегации требований финализирована, собран массив данных, расставлены приоритеты, пришло время составить два фундаментальных документа: устав проекта и дорожная карта. Это рамочный документ, который описывает, каким именно образом будет реализовано то, что выявлено на предыдущих этапах. Он нужен, чтобы договориться внутри заказчика и с подрядчиком, если на этом этапе он уже включился в работу. Устав проекта включает: Включает: Мы, как правило, ведем ее в Google Docs. Это достаточно простой и знакомый инструмент, не тратим ресурсы и время на внедрение новой специальной системы. Зачем нужна карта? Ее не стоит рассматривать как инструмент для оперативного менеджмента. Это все-таки дашборд, срез, где можно увидеть ключевую информацию и понять, на каком этапе проект, куда движется и что останавливает. В ней собраны приоритеты, сроки, бюджеты, документы, акты по заказам, их статус, отмечены стоп-факторы местонахождение разработанных процессов или интерфейсов — на каком сервере они работают. Так выглядит одна из дорожных карт, где есть список функций, плановые цифры, общие стоимости по функциям. Дорожная карта и устав проекта — неотъемлемые документы при реновации. Но есть и дополнительные эффективные помощники. Подробная карта взаимодействий портала с другими системами заказчика. Помогает видеть белые пятна, которые могут мешать развитию или потребуют обновления при масштабировании проекта. Например, в ПГК у менеджерского звена есть и SAP и CRM для работы со своими клиентами, но нашлось место так называемому «Интерфейсу менеджера» для работы с клиентами в личном кабинете. В случае когда кардинально меняется принцип взаимодействия внутри сервера и его слоев схема становится необходимой. Перед выбором платформы заказчику важно очертить технические требования и как это должно работать. Привлекается архитектор подрядчика или внешний специалист. Идеально, если такой сотрудник есть в штате у заказчика. В задачи архитектора входит оценить трудоемкость, сложность реализации, сроки и бюджет, найти вместе с подрядчиком узкие места во взаимодействии внутренних систем. Изначально при реновации все было просто — просто Битрикс. Потом возникло целое семейство микросервисных систем. Процесс усложнился, но так как мы изначально это предполагали и проработали, такое усложнение не стало критичным для проекта. Когда все подготовительные работы сделаны, планы составлены, можно начинать само действо. Нормальной и частой практикой является переезд по частям. Его не нужно бояться. При выборе поэтапного переезда важно предусмотреть два момента: Сам переезд мы предлагаем делать в несколько потоков. До начала работ по обновлению портала, важно проговорить с подрядчиком типовую схему релиза. Мы включаем в нее описание этапов релиза, что должно являться результатом каждого этапа, на каком шаге внутри этапа требуется запустить согласование и кто таким согласантом будет выступать. Это решит многие вопросы в перспективе: Разрабатывали десктоп-версию системы и мобильное приложение. Когда начали запускать, заказчик спрашивает нас: а где мобильная версия, браузерная которая? Мы были твердо уверены, что для этих целей разрабатывается мобильное приложение, да и макеты только для десктопа рисовали, вопросов не было. Недоразумение разрулили, но осадок остался. Важный урок, который мы вынесли из этого промаха: ни под каким давлением сроков и молчаливым согласием клиента не пропускать согласование технических требований. Интранет редко является самостоятельной единицей в IT-системе, не связанной с остальными внутренними инструментами клиента. Поэтому когда речь заходит о реновации, затрагиваются и вопросы текущей интеграции площадки в экосистему компании. Нас часто спрашивают, надо ли менять интеграцию. Если все работает и работа устраивает то, не рекомендуем её ломать. Однако, как показывает практика, когда клиенты приходят с задачей реновации, то ее требует не только сам интранет, но и внутренние базы, которые питают портал. В процессе сбора требований неоднократно в разных компаниях слышали от сотрудников сожаления о том, что каких-то данных в интранете не хватает, или что-то долго загружается из других систем, потому что какая-то питающая база перегружена обращениями. То есть вопросы встают часто и к имеющейся архитектуре баз и систем. В процессе реновации вносятся изменения и в объем данных, которые портал должен получить извне. Количество информации добавляют, приходиться менять интеграционные запросы, их состав данных, форматы ответов. Проработка обновленной интеграции — это также заблаговременные работы. Нельзя их запускать одновременно со стартом реализации бизнес-требований. Потому что можно элементарно не сойтись, если копать тоннель одновременно с двух сторон. Бэклог — реестр всех требований, дополнений к ним, выявленных на этапе агрегации или внедрения. Ведение бэклога — это аксиома для любого проекта. И интранета тем более, так как задачи и потребности сотрудников меняются, обновляются. В процессе переезда появляются новые «хотелки». Ведение бэклога можно реализовать в двух форматах: Бэклог проекта не является общим для всех сторон-участниц реновации. Нужно разделять бэклог пользователя, команды разработчика и заказчика. Это разные сущности. Каждое обновление важно сопровождать анонсом и краткой памяткой для пользователя в виде инфографики или видео-ролика. Это обеспечивает информационно-консультационную поддержку пользователям. Идеально, если с внедрением обновления подготовлен соответствующий контент и дополнен раздел «Вопрос-ответ» или «Помощь». Или внедрена система быстрых подсказок, которая проведет пользователя за руку по новому интерфейсу. Станьте ближе к пользователю, хотя бы просто через чат. И периодически проводите митапы в неформальной обстановке, там пользователи скажут то, что думают. Что же делает реновацию успешной? И стоит ли игра свеч, раз выходит сложно и масштабно? Реновация интранета — это долгосрочная инвестиция. И как это характерно для подобных вложений, результаты и прибыль они не дают мгновенно. Подобные инвестиции должны приобрести накопительный эффект, который становится заметным лишь через 1,5-2 года работы проекта. Да, обновление интранета серьезный шаг, к которому нужно быть готовым. И в этот процесс нужно погружаться с большой самоотдачей. Все проекты, где заказчик был включенным в процесс от начала до конца, где он был требовательным, внимательным к деталям, следовал намеченному с командой курсу, все такие проекты в нашей практике имели положительный сценарий развития и становились центральными темами в PR-активностях компании. Мы часто говорили про многослойность процесса. Именно поэтому нет смысла искать тот единственный компонент, от которого зависит успех. В реновации важна и команда, и подход к агрегации требований, и качество дальнейшего планирования. Влияет всё в комплексе. Поэтому важно не терять концентрацию на всех этапах подготовки и реализации ни заказчику, ни подрядчику. Но в первую очередь важно четко понимать, куда вы идете и какой новый продукт вы хотите по итогу получить. Интранет-системы, веб-разработка, SEM, apps