Как мы сравнивали КСС. Часть 222.08.2015 05:22

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

А сейчас расскажем о двух подходах, которые можно встретить при выборе корпоративных социальных сетей — «сверху-вниз» и «снизу-вверх» — и дадим рецепт выбора «по-супереоновски». Начнем с подхода, который традиционно применяется при выборе классических ИТ-систем в крупных компаниях.

Подход «сверху-вниз»

В этом подходе, как правило, бизнес-заказчик находится в руководстве компании и является первичным выгодоприобретателем и двигателем проекта. Бизнес-заказчик анализирует текущие процессы и то, что недостает для достижения нужного результата в бизнесе. В результате он находит новые правила или процессы, которые надо внедрить. Если для реализации процессов требуется какая-либо дополнительная ИТ-система — подключается дирекция по информационным технологиям, которая разбирается с текущими ИТ системами, формирует технические требования к новой платформе. Если принято решение о внедрении, например, ERP системы, то начался бы проект по разворачиванию ИТ-платформы и внедрению новых процессов. Логика принятия решения немного видоизменяется, когда речь идет о корпоративных социальных сетях, которые объединяют людей, процессы и технологии коммуникации. В этом случае, на этапе анализа обычно подключается HR дирекция или департамент по внутренним коммуникациям, который на основе особенностей корпоративной культуры, ищет способы привлечения сотрудников к использованию новой системы, а затем, на этапе реализации проекта — старается вовлекать персонал в работу с новой системой. Схематично процесс выглядит примерно так:

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

Подход «снизу-вверх»

Вспоминаю небольшую историю из своей практики. У меня как-то на горизонте возник представитель крупного заказчика — заместитель ИТ директора, который попросил сделать сравнительный анализ функциональности Yammer с SharePoint для обоснования перехода на новую платформу. На тот момент у меня уже сформировалась устойчивая привычка первым делом поискать информацию в корпоративной социальной сети. Поэтому данный запрос сначала я направил туда. Признаюсь, меня озадачил ответ, полученный от зарубежного коллеги, продававшего Yammer практически со дня его основания. Оказалось, что него уже был опыт, когда его просили сделать подобный анализ. Из дюжины получившихся пунктов сравнения функциональность получилась очень схожая — общий счет был практически равный, немного в пользу SharePoint. Но ведь это совершенно разные платформы с разным внешним видом! В итоге заказчик купил Salesforce Chatter, потому что о функциональном сравнении вопросы задавал представитель департамента ИТ, а бизнес-заказчик в это время просто открыл тестовый доступ к Chatter и стал им пользоваться.

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

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

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

К варианту «сверху-вниз» больше тяготят Jive и IBM Connections. Так или иначе, но их создатели начинали свое движение к социальным сетям через социализацию порталов, которые исторически начинались как корпоративные СМИ и распространялись «сверху-вниз». Кстати, раньше по этому пути развивался и SharePoint, но потом он остановился в развитии функций социализации. Поэтому в этих платформах:

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

К подходу «снизу-вверх» больше тяготеют такие платформы, как Yammer и DaOffice, они:

не пытаются заменить собой корпоративные порталы, выглядят как «чистые» социальные сети, изначально имеют четкий, простой и понятный интерфейс;
как следствие первого пункта, очень похожи на своих публичных собратьев Facebook, Vkontakte и пр. (*);
отлично интегрируются с существующими портальными решениями, в первую очередь с SharePoint;
не имеют ограничений по времени тестового бесплатного использования (я знаю пример, когда одна из крупнейших мировых компаний пользовалась бесплатной версией Yammer полтора года);
имеют ограниченные возможности по кастомизации интерфейса.

Хотя, в настоящее время Yammer активно переписывается под Office 365, например, у него «растянули» интерфейс и делают еще ряд вероломностей.

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

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

Подход «по-супереоновски»

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

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

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

(*) Надо признать, сходство некоторых корпоративных и публичных социальных сетей возникло не просто так, а является следствием так называемого A/B тестирования. Выглядит это следующим образом: благодаря опросам заказчиков и работе аналитической группы возникает идея оптимизации интерфейса или добавления новой функциональности, которую реализует группа разработчиков. Потом выделяются две аналогичные группы пользователей облачной службы — одна группа использует текущий интерфейс, а вторая — доработанный или с новой функциональностью. В отличие от коробочной инсталляции в облачной службе это можно легко сделать. На примере этих двух групп пользователей производится анализ — начинает ли вторая группа использовать новую функцию и повышается ли уровень использования облачной службы вообще? Если да — то значит новая доработка прошла проверку «боем» и ее можно применять уже для всех пользователей. Если нет — новую функциональность убирают как недостойную корпоративной социальной сети. Например, столбец с перечислением групп, в которых вы состоите, всегда будет слева, и никогда не будет справа, поскольку согласно замерам A/B тестирования пользователям так удобнее.

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

Владимир Иваница