Порталы: взлет и на свалку истории?
Вы никогда не задумывались, что такое корпоративный портал на самом деле? Новости, справочник сотрудников, пара-тройка папок со скучной «нормативкой» – и... все? Да, зачастую именно так. А бывает совсем наоборот. В этой статье мы рассмотрим, какие существуют порталы, как развиваются и к чему приходят.
Степень зрелости организации. Причем тут порталы?
Я заметил, что, как правило, степень зрелости организации напрямую коррелирует с качеством портала как продукта корпоративной жизни. Поясню. Небольшая организация не использует портал или использует «маленькие» решения – сам видел «внутренний корпоративный сайт» на одной из популярных платформ для создания сайтов. Нормально живет, работает, развивается и для своих целей – прекрасен. Тридцать сотрудников – справочник с быстрым поиском (самописный плагин), управленческая структура, кто за что отвечает, новости и фотоальбомы плюс образцы документов. Все, что надо, и ничего лишнего.
Представим себе, что организация продолжает расти и развиваться. У нее выделяются процессы (командировки, расчет, отпуска и т. д.), которые выносятся на портал. Рано или поздно «маленькое» решение перестает устраивать из-за дорогой поддержки, уникальности кода или других причин. Руководство принимает решение о смене портала. Дальше – либо уход в облако (есть целый класс портальных облачных решений), либо смена ПО. Портал меняет внешний вид и обрастает новыми функциями. После еще одна инкарнация: появляются процессы, интеграции. И еще...
То есть, так или иначе, в своем развитии порталы в рамках одной организации следуют за логикой развития данной организации. Это почти всегда так. Но иногда предприятие продолжает развиваться, а портал остается в состоянии 10-летней давности. Почему так?
Как правило, причина банальна: портал, как любое другое прикладное программное обеспечение (особенно то, которое работает на внутреннего пользователя), требует постоянного драйвера внутри организации. Если всех все устраивает, то ничего и не произойдет. Вторая причина – денежная. Нередко нет смысла вкладываться в неосновные функции, к которым чаще всего относится и внутренний портал. Работает? Не трогаем.
Ну и наконец, портал может служить индикатором степени зрелости организации. Имеем полузабытое и неподдерживаемое браузерное ПО? Скорее всего, организация незрелая, либо есть другие места в корпоративном онлайне, где происходят коммуникации.
Имеем посещаемый внутренний ресурс с актуальной информацией? Скорее всего, в компании достаточно высокая степень зрелости культуры и процессов. Имеем в каждом подразделении по своему порталу, часть из которых нерабочая? Скорее всего, бардак в процессах. И так далее.
А вообще, что они могут?
Действительно, что могут порталы? В чем хайп? Типичный маленький портал – это справочник сотрудников, новости и нормативная документация. Права доступа у всех на чтение, для ряда страниц – на комментирование, у избранных – на редактирование... Доступа к отдельным областям не предусмотрено. Грустно. Поэтому следующим шагом появляются права доступа, области совместной работы и организационная структура. Потом на портал «подвязывают» различные сервисы – от корпоративного чата до бюджета, что автоматически означает усложнение технической части. Появляются механизмы интеграции. С течением времени на портале может оказаться значительная часть корпоративных сервисов, после чего обычно происходит магия – появляется меню с быстрым поиском, наем отдельного дизайнера... А пользователи между тем у себя в закладках размещают ссылки на самые востребованные сервисы. Потому что, как правило, к этому моменту навигация на портале становится сродни «оси зла». А сам портал превращается в незыблемую крепость, потому что «повторить, но лучше» – стоит весьма ощутимых денег.
Итак, по-крупному, портал это:
-
разного рода справочная информация;
-
нормативные документы;
-
средства групповой работы;
-
области рабочих групп;
-
рабочие инструменты;
-
корпоративные системы.
То есть, по сути, портал представляет собой упакованное решение, содержащее разного рода корпоративные сервисы.
А еще портал может стать центром интеграции (поскольку он в идеале и так интегрирован почти со всем, чем можно) и единой точкой входа во все сервисы. А еще – и это, пожалуй, самая важная функция – портал может и должен быть единым центром консолидации хотя бы части бизнес-процессов организации (хотя эта функция «чисто технически» представляет собой следствие всех функций портала).
Про бизнес-процессы
Что такое консолидация бизнес-процессов на портале? Самое простое – портал может содержать ссылки на информационные системы, которые обеспечивают процессы, их инструкции. Чуть сложнее – портал может сам выступать провайдером бизнес-логики. И самое сложное – портал может представлять собой точки входа и точки принятия решений в тех или иных бизнес-процессах. Чаще, правда, встречаются все три вида работы одновременно: хорошие, давно используемые порталы имеют как ссылки, так и собственные процессы – наряду с интерфейсами, обеспечивающими прозрачную интеграцию с провайдерами бизнес-процессов.
Рассмотрим все это более подробно.
Со ссылками все относительно понятно. Более того, портал «технически» не может считаться порталом, если будет состоять исключительно из ссылок. Все-таки классический портал – это в первую очередь сервисы и процессы плюс групповая работа.
Что касается непосредственно процессов, то, говоря о «процессах на портале», необходимо помнить о том, что в правильных бизнес-процессах со временем происходят изменения. Соответственно, выбирая способ реализации того или иного процесса, очень желательно идти не просто по пути минимальных трудозатрат, а смотреть чуть вперед и видеть тот счастливый момент, когда что-то изменится в логике бизнеса, и это «что-то» будет необходимо поддержать со стороны портала.
Рассмотрим пример. Предположим, есть процесс согласования и оформления командировок. Он состоит из нескольких шагов:
-
создание заявки;
-
согласование заявки;
-
оформление командировки;
-
отчет о командировке.
Такой процесс можно легко построить практически на любом языке программирования. Последовательно, шаг за шагом, с отработкой простейшей логики «да/нет». Теперь представим ситуацию, при которой в процесс последовательно вносятся усложнения:
-
заявки могут согласовывать только члены определенной группы;
-
согласование заявки должно проходить по последовательно-параллельному маршруту в СЭОДО (система, внешняя по отношению к порталу);
-
оформление командировки проводится в 1С.
Хороший, «правильный» портал поддерживает все усложнения такого рода, позволяя внедрять их быстро и без длительных перерывов в работе.
Как? Например, через встроенные скриптовые языки, через механизм плагинов, через встроенные визуальные средства... Самое главное, чтобы все подобного рода вещи позволяли быстро проводить необходимые изменения.
Про свалку истории
Почему же тогда порталы отмирают, «схлопываясь» до уровня корпоративных сайтов? Как правило, причин несколько:
Во-первых, сложность поддержки изменения заведенных на портал активностей. Так происходит в случае, когда на портал «когда-то» и «кем-то» была заведена некоторая активность, при этом архитектурно она была не проработана – в итоге каждое изменение представляет собой весьма нетривиальное упражнение, требующее времени, денег и генерирующее большие риски. Причем (это основная причина, по моей статистике) именно по этой причине «гибнут» до 80% портальных решений (с которыми мне приходилось встречаться).
Во-вторых, отсутствие внятной документации (что и как было сделано). Кроме того что бизнес-процессы имеют тенденцию меняться, имеют тенденцию меняться и люди, которые делают те или иные решения. Однако документировать свою работу наши коллеги из ИТ, скажем честно, не очень любят. А потому, когда приходит необходимость понять, «как оно работает», сотрудник, которому поставлена такая задача, оказывается один на один с суровой правдой жизни, которая состоит в том, что проще переписать, чем разобраться. А руководство... Руководство смотрит на сроки и сильно расстраивается – потому что банальное действие занимает существенно больше ожидаемого времени. А когда пересчитывает в деньги – расстраивается еще больше... Но сложившаяся ситуация – не вина исполнителей, тут вопросы к тому, кто допустил необеспеченное документацией внедрение и не продумал архитектуру.
В-третьих, внедрение портала в варианте «базового функционала и множества костылей». Такой вариант, с одной стороны, обеспечивает быстрое внедрение и минимум затрат на старте, а с другой – огромный букет проблем по ходу эксплуатации.
Срабатывание любого из перечисленных факторов приводит к тому, что портал начинает восприниматься как чемодан без ручки: выкинуть сложно, а нести тяжело. И постепенно с портала начинают «осыпаться» сервисы, а портал держится только потому, что когда-то на него были потрачены деньги, которые записать в чистые убытки вроде как и не очень здорово.
Что делать, чтобы не на свалку?
Первое и самое главное – продумывать архитектуру ландшафта ИТ-решений, который включает в себя портал и архитектуру портала таким образом, чтобы с минимальными затратами и максимальной скоростью реагировать на изменения. Но как показывает практика, это очень просто посоветовать – и очень сложно выполнить. Особенно в условиях стартовых ограничений (бюджета, сроков, людей). Тем не менее это то, к чему нужно стремиться.
Далее о том, что следует иметь в виду: портал – это длительная активность, требующая постоянных инвестиций.
Поясню. Срок жизни типичного портала с интегрированными сервисами – от пяти лет. Это связано с тем, что инвестиции в портальные решения относятся к разряду долговременных. Кроме того, у подобных инвестиций сложно посчитать возврат, что автоматически превращает их в отдельную головную боль финансового департамента... Соответственно, портальное решение стоит проектировать так, чтобы затраты на поддержку оказались бы минимальны. Это не менее важно, чем предыдущий пункт, а в некоторых случаях даже более важно.
И последнее. Надо помнить, что портал – это решение, которое внедряется на длительный период и имеет множество разных следствий, например:
-
стоит на старте договариваться о скидках на лицензии;
-
стоит на старте фиксировать стоимость поддержки вендора и условия ее пересмотра;
- стоит на старте оценить требования к аппаратным средствам и оценить затраты на них (особенно в перспективе роста числа пользователей и «обвеса» дополнительными сервисами);
-
на старте стоит продумать структуру поддержки и механизмы передачи знаний (курсы, документация и т.д.)
-
и наконец, на старте стоит продумать момент, связанный с развитием портала, чтобы иметь более-менее понятную стратегию – куда движемся и что хотим получить по прошествии времени;
-
вкладываться в поддержку и развитие портала, в первую очередь ресурсами и внутренним пиаром;
-
на старте нужно иметь четкую цель и ответ на вопросы: зачем вообще нужен портал? какие он решает задачи? чем он поможет бизнесу?
Отдельно отмечу, что это все не гарантирует того, что портал будет жить, но выполнение данных рекомендаций точно прибавит решению запаса жизнестойкости, достаточного для того, чтобы в перспективе трех-пяти лет развиваться, не сильно вкладываясь в развитие (парадокс – но так бывает).
Опубликовано 27.09.2019