Коробочные войны. Внедрение корпоративного портала: готовые решения или кастомная разработка?

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

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

Меня зовут Антон Бобров, в «КОРУС Консалтинг» я работаю над проектами по внедрению и развитию корпоративных порталов. За 10 лет работы я видел компании, которые вложили десятки миллионов в разработку собственного решения там, где можно было обойтись коробочным. И коробочное там, где нужен строго индивидуальный подход.

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

Несмотря на многообразие вендоров и большое количество платформ для разработки портальных решений, 97% пользователей выбирают продукты MS SharePoint, «1С-Битрикс: 24» или собственную разработку.

При этом интерес к собственной разработке (когда компания пишет свой интранет с нуля) снижается, как и доля платформы MS SharePoint, а доля отечественного решения «1С-Битрикс: 24», наоборот, растет.

Существует 4 сценария внедрения порталов:

1. Внедрение готовых решений от разработчика платформы — вендора.

2. Собственная разработка на базе распространенных платформ.

3. Разработка полностью с нуля, без использования платформ вендора.

4. Внедрение готовых решений на базе распространенных платформ от интеграторов (MVP).

Подробнее рассмотрим плюсы и минусы каждого варианта.

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

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

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

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

● Преднастроенные интеграции с распространенными информационным системами снижают затраты и время внедрения.

● Готовое решение не исключает создание уникального дизайна. Дизайн можно и нужно дорабатывать, это займет меньше времени, чем разработка с нуля.

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

● Даже если в готовом решении вы используете только 50% функциональности, вы все равно экономите на разработке. Даже с учетом необходимых доработок.

● «Коробка» гарантирует постоянное улучшение и развитие платформы: вендоры регулярно оптимизируют производительность системы, устраняют угрозы информационной безопасности и развивают платформу в соответствие с новыми трендами

Готовое решение подойдет:

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

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

3. Как экстренная мера. В случае, если компании необходимо оперативно перейти на платформу отечественной разработки из-за требований импортозамещения.

Основные риски:

● Высокие лицензионные платежи для компаний с многотысячным штатом сотрудников.

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

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

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

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

Кому подойдет:

1. Компаниям, где запуск готового решения не несет ценности для бизнеса и не решает его задачи.

2. При узкоспециализированных задачах портала, когда требуется доработка более 70% функциональности готового решения.

3. В компании уже закуплены лицензии одного из вендоров.

Основные риски:

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

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

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

Это полностью собственная разработка, без использования в основе решения какого-либо готового программного продукта. Весь код разработчики пишут под требования заказчика, часто с применением фреймворков.

Кому подойдет:

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

2. Компания не хочет зависеть от вендора или поставщика готового решения.

Основные риски:

● Очень высокая стоимость по сравнению с промышленными платформами: 20-100 миллионов рублей.

● Высокие и часто размытые во времени сроки реализации. От полугода и выше. Дата запуска всегда смещается на более позднее время.

● Нужен эксперт, а их на рынке единицы. Как следствие — прямая зависимость от конкретного человека и повышение риска нереализации.

● Риск получить «плохой дизайн» (правда, он есть везде, но тут вам его точно нужно будет делать, вы не сможете применить стайлгайд от вендора).

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

● Больше рисков по сравнению с внедрением промышленной платформы. Даже при внедрении готового решения что-то часто идет не по плану. В подобной ситуации при индивидуальной разработке вы гарантированно будете импровизировать.

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

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

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

Подобная версия называется MVP (от англ. Minimum Viable Product, «минимально жизнеспособный продукт»). Это самая ранняя версия продукта, которая обладает только необходимыми функциями, достаточными для того, чтобы донести основополагающие ценности до аудитории и проверить их на первых пользователях.

Эту модель я считаю оптимальной и рекомендую внедрять интранет, используя именно этот подход.

Как показывает моя практика в таких компаниях как «Газпром-нефть», «Росатом», Банк «Санкт-Петербург», «Петрович», «Балтика», «Сафмар» - для крупного бизнеса недостаточно типовой функциональности «коробки» вендора. В ней либо отсутствуют нужные модули, либо те модули, которые есть, неудобны для использования. Поэтому логично к коробочным решениям вендора добавлять готовые кастомизированные модули, разработанные за годы практики. Например, мы используем для этого собственные типовые блоки, которые легко интегрируются с коробкой. Это проверенные решения, значительно расширяющие базовую функциональность продукта вендора.

Функциональность, достаточная для продукта MVP:

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

Преимущества:

● Сокращение бюджета и сроков проекта. Внедрение портала с типовыми интеграциями занимает не более месяца.

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

● Постепенное развитие портала на основании обратной связи от сотрудников.

● Снижение рисков в случае, если вы промахнулись с концепцией.

● Упрощенное согласование бюджета на развитие: стоимость легче обосновать после того, как руководство увидело ценность и пользу от инструмента.

Примеры подобных модулей

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

Модуль «Главная страница»

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

Например, в стандартном решении «1С-Битрикс24» главная страница — это живая лента, где сотрудники выкладывают посты и новости. В больших корпорациях новость, выпущенная 5 минут назад, опускается так низко, что ее не найти. Это неудобно и неэффективно. К тому же, сам формат живой ленты значительно ограничивает возможности главной страницы.

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

1. Навигационное меню.

2. Строка поиска.

3. Слайдер с важными новостями.

4. Новостная лента.

5. Дни рождения.

6. Ссылка на профиль / личный кабинет.

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

Модуль «Новости»

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

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

Модуль «График отсутствий и отпусков»

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

Основные различия между типовым и улучшенным модулем отобразил в таблице:

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

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

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

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