Портал №1 по управлению цифровыми
и информационными технологиями

Личные мобильные устройства на работе: как быть?

Опубликовано 15 февраля 2013
Рубрики: Общие вопросы менеджмента, Постоянное улучшение, Эксплуатация ИТ
Комментарии

Ну что ж, пришла, видно, пора поговорить про BYOD на этом портале.

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

Никто никого не переспорил (надеюсь), а в конце всплыл еще один кейс. Сотрудникам компании моего слушателя разрешили носить на работу и использовать в служебных целях личные планшеты, смартфоны и плафоны. Мол, как в Гугл. А ИТ-команде – головная боль. Кроме  традиционных для подхода Bring Your Own Device рисков, связанных с информационной безопасностью, приходится еще думать о совместимости собственных систем с мобильными платформами, настройке VPN-каналов, мощностях офисных беспроводных сетей, об этом вот всём.

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

Мне кажется приемлемым такое решение:

  • В CMDB нужно учитывать эталонные конфигурации мобильных устройств в качестве прототипных КЕ (самое простое: диагональ экрана+версия мобильной платформы).
  • Пользователей следует информировать об ограничении ответственности ИТ-команды: "Мы проектируем и поддерживаем ИТ-услуги для следующих эталонных конфигураций:…".

Но это только моя точка зрения…

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

Кто из вас сталкивался с BYOD на просторах бывшего СССР? Не рановато ли нам, практикам ITSM, решать проблему некорпоративных устройств потребления ИТ-услуг на системном уровне? Давайте решим в комментариях!

P.S.: Приятно, что с недавнего времени можно почитать про BYOD по-русски – благодаря Карен Феррис и нашему коллеге Степану Хрулёву.

ИНТЕНСИВ С ТРЕНЕРОМ
VAP: Управление поддержкой ИТ-услуг
Строим эффективную ИТ-поддержку, оптимизируем существующую

Также по теме:

Комментариев: 16

  • Ivan

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

  • Vladimir Kalenov

    Хотел отметить, что тему использования стандартных процессов в разрезе, не только BYOD, но и в условиях виртуализации сред, поднимал на последнем собрании форума господин Овчинников.
    На моей практике – налоговый кодекс (трудовой), считает, что никакой сотрудник не захочет, что бы за его счет оплачивалась амортизация, и внимательно смотрит, чтобы никто не купил себе домой доменную печь 🙂 ну, т.е. как-то так http://na.buhgalteria.ru/document/n67919
    Да и самый распространенный способ борьбы с BYOD в России – запрет или снятие с себя ответственности, мягко говоря не сервис ориентирован.
    Как уже отметил Константин, такой подход решает часть вопросов усложнения поддержки и немного снижает риски утери информации.
    Второе популярное решение – разрешить всем использование личных устройств и максимально ориентировать внутренние сервисы на на мобильность.
    По моей практике, выбор, при отсутствии у ИБ и ИТ ложного ощущения контроля над ситуацией, очень сервис ориентирован и зависит от срока полезного использования информации. Если бизнесу важнее быстро передать информацию и принять на ее основе решение (быстрая одноразовая информация) – выбирается вариант максимальной открытости (например, разработчики, сервисные организации), если информация имеет большой срок годности и высокую секретность, то жесткий контроль устройств, вплоть до запрета (некоторые банки), остальные ищут компромиссный вариант – в зависимости от того, что дороже.
    Возвращаясь к ITSM, я вижу два отдельных вопроса
    1. Создание услуги “доступ к … с личного устройства” и включение или не включение в рамках процесса SLM ее в каталог предоставляемых услуг.
    2. Создание инфраструктуры и процессов сопровождения, здесь есть прекрасная возможность использовать инструментарий и методики мобильных разработчиков и сайтостроителей.

    • Константин Нарыжный

      Владимир, спасибо за ссылку на письма Минфина. Надо обдумать физический смысл для мобильных устройств в следующих словах: “использование, износ (амортизацию) инструмента, личного транспорта, оборудования и других технических средств и материалов, принадлежащих работнику, а также возмещаются расходы, связанные с их использованием” (ст. 188 ТК). Изнашивается ли смартфон, на котором работает два личных почтовых аккаунта, если на него повесить еще рабочий?

      • Vladimir Kalenov

        Из практики – амортизация не проблема, если использование – дополнительный платный трафик, оплачивает компания 🙂

  • Vladimir Kalenov

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

  • Grigory Kornilov

    Быть так, как более полезно на данном этапе + в перспективе.
    Для кого-то важнее безопасность, для кого-то экономия или лояльность\привязанность сотрудников.

    Лепить инвентарный номер на не приобретенный компанией девайс не правильно, но регистрировать\идентифицировать девайс важно для безопасности, например.

    • Константин Нарыжный

      Григорий, еще во внимание следует принять пользователей. В этом кейсе – это разработчики ПО. Политики и инвентарные номера им зачастую, мягко скажем, неинтересны (Картинка с Дилбертом, в этом смысле строго обратна). Такие пользователи, столкнувшись с запретом от СБ в лучшем случае найдут обходной маневр. В худшем – уйдут =)

      • Grigory Kornilov

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

        Под пользователями я так же подразумеваю подразделение безопасности компании и владельцев конфиденциальной информации.

        Подход нет смысла запрещать, не поможет не поддерживаю.

  • Олег Скрынник

    http://www.facebook.com/photo.php?fbid=492224830834229&set=a.492178770838835.111393.100001401489005&type=1&relevant_count=1

    Товарищ из среднего размера компании (250 айтишников в штате) рассказываает про свой опыт. Он в компании главный по ITSM. Первый вывод – нет смысла запрещать, не поможет. Второй – как только разрешите, всем будет больно и плохо. Жалуется, что ITIL не дает ответов.

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

    Интересно, что на конференции его пришло слушать около 30 человек, а в соседних секциях по 100-120 посетителей. Нет такой проблемы в ИТ?

    • Константин Нарыжный

      А, ну так я о таком же списке и говорю. К пунктам этого списка можно и инциденты вязать, и релизы, т.д.
      И что, ему помогло? Товарищ из Европы или из Штатов?

      • Олег Скрынник

        Товарищ из Штатов. Рассказывал чудеса. К примеру, они у себя пришли к тому, что вместо того, чтобы платить за корпоративные телефоны 50$ в месяц они теперь платят столько сотрудникам за то, что они используют свои айфоны и андроиды.

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

  • ZW

    Внедрение BYOD в России начинается с руководства. Купил шеф смартфон и понеслось допиливание нужного ему ПО для его телефона. Яркий пример такого внедрения – Ipaдомания года четыре назад. Но, так как правило это очень большие люди в компании, для них требуется прежде всего отчётность, которыю и запиливают ввиде отдельного сервиса. А так как для таких людей (уж не знаю, как там на загнивающем:)) не ITIL в компании обычно работает, а люди для обслуживания VIP-клиентов.
    PS. А по правильному, конечно нужно переориориентировать сервисы на конкретные платформы (а не устройства). А ведь часто сервисы для клиентов работают и на сотрудников компании, которые могут оперативно сообщить о проблеме, до которой клиенты ещё не добрались и оказать более корректную помощь в решении проблемы.
    Кстати, одна известная компания, поддалась на уговоры сотрудников и стала им выдавать для работы продукцию Apple. А как известно, продукция этой компании очень недружествена к корпоративной среде, на что эта среда овечает ей полной взаимностью. Так вот, выдали и сказали, что сопровождение девайсов и решение проблем с нашими корпоративными сервисами это ваша проблема. Но при этом выдали серверные ресурсы для портала/wiki/форум/база знаний и полную свободу действий. Так как среди фанатов яблок оказались и разрабы сервисов – сервисы стали узнавать, что есть такие девайсы с яблоком на боку.
    Результат – часть сервисов уже официально поддерживают эту продукцию и радуют клиентов компании.
    PPS. Не надо людей ограничивать, людей надо направлять.

  • Степан Хрулёв

    Напишу немного очевидностей 🙂
    Вариантов как всегда несколько. Первое, что приходит в голову:
    – Не учитывать. Например, если мы решим, что использовать свои устройства можно, но поддержку по ним оказывать не обязываемся. Тогда нам просто не нужна информация о личных устройствах.
    – Учитывать в виде списка эталонного ПО. Если мы декларируем некоторый список устройств и гарантируем доступность тех или иных услуг (а также поддержку) при использовании личных устройств из указанного списка.
    – Учитывать каждый девайс. Если нам важно оказывать всеобъемлющую поддержку, то логичным шагом будет хранить необходимую информацию обо всех личных устройствах. Получать информацию и заносить в CMDB можно, например, при первом обращении пользователя, связанного с данным устройством. Либо можно объявить, что поддерживаться будут только те устройства, которые пользователь принесет для регистрации выделенным специалистам.

    Вообще говоря, единого для всех однозначного ответа тут нет. Все зависит от специфики бизнеса и организации. Но если есть желание использовать принципы BYOD, ответы на такие вопросы должны быть сформулированы в некотором документе (политике). Этот документ должен содержать:
    – общую высокоуровневую информацию, т.е. ответы на вопросы “а зачем нам это?”, “что мы хотим получить от BYOD?”,
    – ответы на тактические вопросы, т.е. “какие ограничения накладываются с точки зрения безопасности?”, “какую поддержку мы можем обеспечить?”, “какие услуги следует предоставлять с помощью личных устройств?”, “на что следует и на что не следует тратить деньги при наличии BYOD в компании?”
    – и различную конкретику, включая описание связи с операционными процессами – “Как учитывать личные устройства?”, “Будет ли отличаться уровень услуги при использовании личных устройств?”, “Что писать в карточке инцидента/обращения/изменения, если оно касается личного устройства?”, “Нужно ли рассматривать проблемы, связанные с личными устройствами, в рамках процесса управления проблемами?”
    Так, рассуждая от общих целей и постепенно углубляясь в детали, можно ответить на многие частные вопросы касательно BYOD в своей компании.
    Вот, кстати, неплохая маленькая шпаргалка для написания такой политики:
    http://venturebeat.files.wordpress.com/2013/02/how-to-create-a-byod-policy.png

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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.