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

image

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

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

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

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

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

Это явление описывается с помощью специального термина «теневые технологии» (“shadow IT” в английском варианте) — программные продукты и железо, которые в жизни компании используются, но не одобрены официально. Риски утечки, фрагментации, потери, искажения и воровства информации в результате применения теневых технологий для профессионального общения чрезвычайно высоки.

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

Способ закручивания гаек

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

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

image

Метод номер два: страус на пляже

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

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

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

Метод номер три: «Мы пойдём другим путём»

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

Изначальное противоречие можно описать так: с одной стороны, большая часть продуктов, призванных решать проблемы взаимодействия внутри крупных организаций, не очень удобны (вспомним, например, вот эту яростную критику системы Yammer); с другой стороны, любой сотрудник компании в повседневной жизни может пользоваться десятком аналогичных «потребительских» сервисов, которые гораздо удобнее, надёжнее, и быстрее (Skype и WhatsApp приходят на ум первыми). При таком положении дел довольно сложно ожидать энтузиазма от сотрудников, вынужденных использовать неудобный (но разрешённый корпорацией) софт.

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

Облако как окончательное решение

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

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

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

Следующий шаг: Kato Enterprise

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

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

Перечисленные проблемы решаются в корпоративной версии нашего продукта, названной Kato Enterprise — благодаря интеграции с облачным сервисами управления идентификацией (смотрите вот эту статью из Википедии о Single sign-on) Okta и OneLogin, корпоративные пользователи смогут авторизоваться в мессенджере Kato, используя свою учетную запись в Active Directory, Google Apps, или LDAP.

image

SSO-сервисы (примеры — Okta и OneLogin) позволяют компаниям работать с облачными продуктами без необходимости создания в них отдельных учетных записей — «логиниться» в условный Dropbox можно с помощью учетной записи в SSO-сервисе (которая может быть привязана к той же Active Directory). При этом возможен не просто логин в условный Dropbox по доменной учетной записи, но и получение в условном Dropbox-сервисе прав, соответствующих правам данного конкретного пользователя в корпоративной сети, прописанных в SSO-сервисе (так называемый “provisioning”).

SSO-сервисы, кроме того, позволяют легко объединять и разделять директории компаний. Например, если одна компания, используящая Okta, купит другую, использующую какую-либо директорию (Active Directory, Google Apps, LDAP), то в Okta-директории первой компании почти автоматически появится Okta-директория второй компании, перечисляющая её сотрудников.

Связка между Kato и SSO-сервисами позволяет создавать в мессенджере команды на основе структуры компании, отражённой в её директории.

Например, группы в Active Directory, Google Apps или LDAP, описывающие бухгалтерию или отдел продаж, отображаются как отдельные команды в Kato — это уникальная возможность среди мессенджеров. Помимо этого, в мессенджере будет присутствовать и общая “зонтичная” команда, объединяющая всех сотрудников компании.

Версия Kato Entreprise в данный момент находится на этапе бета-тестирования. После завершения тестирования пользоваться версией Kato Enterprise смогут действительно крупные компании с числом сотрудников в десятки тысяч.

«Почему не на нашем сервере?»

Один из частых вопросов в комнатах поддержки Kato — «Как можно доверять чувствительную корпоративную информацию мессенджеру, над серверами которого у компании нет контроля?».

Несколько фактов позволяют дать ответ на этот вопрос:

  • Взломы серверов, находящихся под полным контролем компаний-хозяев — достаточно частое явление (последние нашумевшие примеры: Sony, Home Depot, Target, Adobe, eBay)
  • Неоспорим общий (и усиливающийся) тренд к переходу корпоративных сервисов в облако — облачные технологии позволяют бизнесу получать лучшие результаты при меньших затратах (уже даже Microsoft, заработавший неисчислимые миллиарды на инсталлируемых офисных программах, выпустил Office Online)
  • Компании, которые раньше других поняли выгоды использования облачных технологий, получают конкурентные преимущества
  • Системы, обеспечивающие коллективную безопасность участников, всегда дешевле и надёжнее систем, обеспечивающих сравнимый уровень безопасности для этих участников индивидуально.

P. S. Топик был обновлен в 23:05 по московскому времени.

 

Источник:http://habrahabr.ru/company/kato/blog/246839/

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>