Service Desk своими руками

Денис Бобров

Первый вопрос, возникающий у ИТ-руководителя, которому предложили идею процессного подхода к управлению ИТ-инфраструктурой: «Зачем мне нужен ITIL (ITSM, Service Desk, управление инцидентами и т. д.), если у меня и так все хорошо?» Вот каким может быть ответ.

Посмотрим, как обычно происходит управление ИТ-инфраструктурой рядового российского предприятия. Начальнику ИТ-отдела звонит генеральный директор компании и сообщает, например, что у него не работает электронная почта. Руководитель ИТ-подразделения ловит в коридоре технического инженера и отправляет его к директору для восстановления работоспособности почты. К этому моменту секретарь топ-менеджера уже сообщил системному администратору о возникшей проблеме, и тот самоотверженно бросается на помощь. Через считанные минуты в дверях кабинета генерального директора одновременно появляются два запыхавшихся «компьютерщика»… Едва ли такие действия можно назвать эффективным управлением ИТ-инфраструктурой.

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

Сколько это стоит?

Сегодня найдется немало компаний, которые могут помочь в построении службы Service Desk. Квалифицированные консультанты оценят уровень зрелости процессов ITIL на предприятии, разработают для ИТ-департамента план по внедрению того или иного процесса, подберут и настроят оптимальный инструментарий. Однако услуги консультантов не бесплатны. А руководители компаний среднего и малого бизнеса, как правило, не считают ИТ-департамент стратегическим подразделением и, следовательно, неохотно инвестируют средства в ИТ-проекты. Возникает вопрос: как доказать руководству необходимость выделения средств на развертывание службы Service Desk?

Если не удалось с первого раза убедить высшее руководство предприятия в необходимости инвестиций, то все последующие попытки также будут обречены на провал. Доказать инвестиционную привлекательность службы Service Desk практически невозможно, точно так же, как и рассчитать срок возврата инвестиций. Чтобы оценить экономический эффект, потребуются начальные данные, такие как среднее время разрешения одного инцидента, количество инцидентов в день, месяц, год и т. д. Но если в ИТ-департаменте еще не работает служба Service Desk, то как узнать, какое время в среднем тратится на разрешение одного инцидента? Если нет статистики об обращениях пользователей, то где взять информацию о количестве инцидентов? Помимо этого, на практике в первые месяцы работы службы Service Desk время разрешения одного инцидента увеличивается. Сократить его удается не сразу. Следовательно, говорить о положительном экономическом эффекте в первые месяцы работы службы не приходится.

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

С чего начать?

Многие скажут, что начинать надо с оформления проекта. Однако в случае построения службы Service Desk подобный подход нереализуем. Какие цели проекта следует указать? Какие сроки поставить? Какие риски проекта описать? Практика организаций, в которых работает Service Desk, показывает, что создать идеальную службу невозможно. Она постоянно изменяется и совершенствуется. Поэтому с большой вероятностью описанные грандиозные цели проекта по созданию Service Desk утратят свою актуальность еще в процессе их достижения. А между тем, срок такого проекта может исчисляться годами! Так нужен ли такой проект? С другой стороны, работать без четко описанных целей также невозможно. Необходимо понимать, в каком направлении двигаться и что должно получиться в итоге.

Таким образом, при создании службы Service Desk оптимальный вариант – серия небольших проектов с понятными, осязаемыми краткосрочными целями.

Шаг первый. Фиксируем регламенты

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

Допустим, вы купили новый телевизор. Как часто вы будете пользоваться инструкцией по эксплуатации? Наверное, не очень часто. Тем не менее ни у кого не возникает сомнения в полезности этого документа. То же самое можно сказать об описании функционирования службы Service Desk: оно обычно лежит на полке в одном из кабинетов ИТ-департамента до тех пор, пока не потребуется изменить или усовершенствовать процесс приема и обработки обращений пользователей.

Относительно объема данного документа, его полноты и развернутости четких рекомендаций не существует. Тем не менее нет смысла подробнейшим образом и максимально детально описывать все регламенты службы Service Desk. Документ получится слишком большим и нечитабельным. Однако создавать его излишне кратким также не стоит. В первом варианте документа на один регламент достаточно отвести одну-две страницы.

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

Количество линий поддержки службы Service Desk и распределение ИТ-сотрудников по линиям поддержки. Классика ITIL рекомендует развернуть три линии. К первой линии поддержки могут относиться операторы call-центра, ко второй – администраторы баз данных, системные администраторы, технические специалисты, к третьей – программисты, старшие системные администраторы. Ваши сторонние подрядчики, организации, которые предоставляют вам услуги по сопровождению ПО, провайдеры телекоммуникационных услуг и т. д. также могут быть отнесены к третьей линии поддержки.

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

Первый – телефонный звонок пользователя – самый простой и самый эффективный вариант. В этом случае оператор Service Desk имеет возможность успокоить пользователя, если тот чрезмерно взволнован очередным сбоем. Кроме того, в процессе общения с пользователем оператор call-центра может быстро определить причину инцидента и предложить решение. Тем самым запрос будет обработан в самые короткие сроки.

Вторым способом обращений пользователей за поддержкой может быть электронная почта. В этом способе коммуникации с Service Desk есть свои преимущества и недостатки. Далеко не на всех предприятиях пользователи настолько грамотны в области применения ИТ, чтобы с первого раза кратко и понятно описать ситуацию (произошедший сбой). Неточное описание может повлечь за собой долгую переписку между оператором call-центра и пользователем. Результат – увеличение времени решения проблемы. Положительные стороны обращения пользователя в службу Service Desk при помощи электронной почты, разумеется, тоже есть. Например, пользователь направляет электронное письмо с описанием сбоя на определенный адрес. При поступлении нового сообщения в этот почтовый ящик происходит автоматическая регистрация обращения в предварительно настроенной системе службы Service Desk. В этом случае оператор первой линии поддержки не тратит время на регистрацию обращения, а может сразу же приступить к поиску решения инцидента.

Третий способ – корпоративный портал или некий сайт, на котором пользователь может самостоятельно зарегистрировать инцидент. Этот способ обращения пользователя обладает всеми теми же положительными и отрицательными чертами, что и в случае с электронной почтой.

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

Каждый сбой в ИТ-инфраструктуре влечет за собой остановку бизнес-процесса одного конкретного специалиста, и/или отдельного отдела, и/или целого предприятия. Следовательно, каждый сбой имеет различные степени влияния. Поломка принтера у одного человека влияет только на бизнес-процессы одного сотрудника предприятия, и то не на все. Если же принтер сетевой, то влияние сбоя усиливается, поскольку сбои в бизнес-процессах затрагивают нескольких сотрудников. Если же остановился сервер обмена сообщениями (например Exchange Server), то сбой, скорее всего, затрагивает большинство подразделений.

При определенном навыке оператор Service Desk может сразу определить степень влияния того или иного сбоя. Например, если принтер остановился в бухгалтерии, то приоритет может быть невысоким. Бухгалтерские отчеты можно распечатать и днем позже (если, конечно, бухгалтерия не печатает отчеты накануне их сдачи в налоговую инспекцию). А остановка принтера, допустим, в главной диспетчерской центрального склада влечет за собой остановку отгрузки товара и, как следствие, убытки для предприятия. Таким образом, имеются два параметра: степень влияния и приоритет обращения. Исходя из этих данных, можно более детально рассчитать сроки прохождения инцидента по линиям поддержки.

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

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

«Главный регламент». Это не маршрутизация инцидентов и не перечень предоставляемой отчетности. «Главный регламент» – это мотивация ваших сотрудников. По опыту многих организаций и предприятий, которые развертывали службы Service Desk, можно однозначно утверждать: если не будет выстроена система материальной (и нематериальной) мотивации сотрудников, то служба Service Desk никогда не начнет работать эффективно. Необходимо уделить особое внимание этой части документа. Вот несколько рекомендаций, которые помогут в построении грамотной схемы мотивации.

• Мотивация в большей степени должна быть построена на поощрении сотрудников, а не на наказании. Использовать штрафные санкции допустимо только в крайних случаях, например при нарушении сотрудником установленных регламентов.
• Материальная мотивация должна быть ощутимой. 5% от оклада специалиста – это пародия на мотивацию.
• Схема мотивации должна быть проста и понятна каждому сотруднику ИТ-департамента. Пять-шесть параметров, которые используются для расчета премий специалистов, можно считать пределом.

Шаг второй. Обучение

Для того чтобы служба Service Desk начала работать эффективно, недостаточно одной, пусть даже идеальной схемы мотивации сотрудников. Весь штат ИТ-департамента должен знать, а еще лучше – понимать, зачем нужен Service Desk, что такое управление инцидентами и т. д. Для этого необходимо обучить всех сотрудников ИТ-департамента основам ITIL. Затраты при этом будут неизбежны.

Нежелательно обучать специалистов самостоятельно, так как цена неверно понятого описания процесса или термина может оказаться слишком высокой. Наибольший эффект достигается при обучении сотрудников ИТ-отдела профессиональными тренерами. Можно совместить приятное с полезным. К примеру: проведите обучение в выходной день за городом. В этом случае бизнес не останется без поддержки в рабочие дни, а все сотрудники ИТ-департамента приобретут не только полезные знания, но и хорошее настроение. Отказавшись от обучения персонала основам ITIL, можно столкнуться с большой проблемой – саботажем. Выбираться из этой ситуации окажется дороже, чем заранее предотвратить ее, проведя обучение специалистов.

После того как все сотрудники прошли тренинг по основам ITIL/ITSM, следует ознакомить их с регламентами, которые уже составлены. И никак не раньше. Уже с обученными сотрудниками (или с некоторыми из них) можно и нужно проконсультироваться, узнать их мнение, выслушать предложения. Здесь может произойти первая корректировка процесса приема и обработки обращений пользователей.

Шаг третий. Организация call-центра

«Что может быть проще! – скажете вы. – Берем стол, стул, компьютер, телефон, принимаем на работу девушку с приятным голосом. И вот call-центр готов». Однако не все так просто. Существует как минимум два вопроса, которым требуется уделить особое внимание: какими качествами должен обладать оператор и где расположить его рабочее место.

Приятный голос – это далеко не самое главное, чем должен обладать человек, работающий на первой линии поддержки Service Desk. Стрессоустойчивость гораздо важнее для оператора, который в течение одного рабочего дня может несколько десятков раз слышать одну и ту же фразу: «У меня не работает компьютер!» — и при этом обязан всегда одинаково невозмутимо и доброжелательно выяснять у пользователя, что же действительно сломалось. Кроме того, сотрудник первой линии поддержки должен хорошо владеть русским языком. Грубые грамматические и синтаксические ошибки, допущенные оператором при регистрации обращения пользователя, могут неблагоприятно отразиться на понимании сути заявки другими специалистами. Наконец, оператор call-центра должен обладать общими ИТ-знаниями. Комментарии здесь излишни. Очевидно, что оператор, услышав слово «винчестер», должен представлять себе устройство долговременного хранения информации, а не огнестрельное оружие.

Практика показывает, что нахождение первой и третьей линий поддержки в одном помещении крайне негативно сказывается на результатах работы высококвалифицированных специалистов. Резко снижается эффективность системных администраторов. Количество ошибок в программном коде у программистов возрастает в несколько раз! Этот факт обусловлен тем, что сотрудники, работающие на третьей линии поддержки, решают, как правило, нетривиальные задачи, требующие высокой степени сосредоточенности. А как можно сосредоточиться, если рядом каждые десять минут звонит телефон, и оператор отвечает: «Добрый день, отдел ИТ слушает»?

Совсем другая обстановка возникает, если расположить рабочее место оператора call-центра рядом с рабочими местами сотрудников второй линии поддержки. Решение задач второй линии поддержки не требует особой сосредоточенности и, следовательно, общение оператора с пользователями не будет сильно их отвлекать. В то же время тесное общение специалистов первой линии поддержки с сотрудниками второй линии может дать положительные результаты: через некоторое время часть проблем, которые ранее решались на второй линии, смогут устраняться уже на первой. Этим можно улучшить один из главных показателей эффективности Service Desk – сократить среднее время решения проблем.

Шаг четвертый

Когда принципы функционирования службы Service Desk описаны (подготовлена документация), сотрудники знают и понимают основы ITIL/ITSM и определено рабочее место операторов call-центра, стоит задуматься об инструментарии. Для того чтобы контролировать процесс приема и обработки обращений пользователей, необходимо специализированное программное обеспечение. Наиболее распространенным инструментом сегодня является HP OpenView ServiceDesk. Но многие компании не имеют средств на приобретение такого программного обеспечения, да и нужен ли на стартовом этапе инструмент такого высокого уровня? Скорее всего, нет, так как сначала требуется наладить сам процесс приема и обработки обращений пользователей.

Если в штате ИТ-департамента есть хотя бы один программист, то задача построения собственной системы приема и обработки обращений пользователей решается сама собой. Любой программист менее чем за месяц может создать базу данных и подготовить генерацию стандартных отчетов. Если же программиста нет, то можно пойти еще более простым путем: достаточно зайти на сайт http://www.helpdesk.com, где хранится огромный список ссылок на различного рода программное обеспечение для поддержки служб Help Desk, Service Desk и call-центров. Потратив немного времени, можно найти бесплатный и вполне достаточный по набору функций инструментарий. Если и этот вариант не устраивает по каким-либо причинам, то можно, наконец, использовать «подручные» средства – Microsoft Excel и Access. Потратив несколько часов рабочего времени, можно создать свой собственный уникальный инструмент для службы Service Desk.

Первые результаты

Теперь все готово для запуска в работу новой службы Service Desk. Конечно, нужно не забыть оповестить всех пользователей о новой услуге, сообщить единый телефонный номер отдела ИТ, по которому пользователи могут обратиться с любым вопросом.

Каких же результатов стоит ожидать? Если в первый день работы службы на телефон call-центра поступит более одного звонка от пользователей – это достижение. Если в первый месяц работы хотя бы один сотрудник компании скажет, что ему стало удобнее общаться с ИТ-департаментом, – это победа.

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

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

Вторая проблема, с которой придется столкнуться, – увеличение среднего времени обработки одного инцидента. Это плата за те статистические данные по обращениям, которые получит менеджер уже после первого месяца работы службы Service Desk. Увеличение времени решения инцидента, безусловно, будет заметно для пользователей, и именно с этим будут связаны основные негативные эмоции сотрудников предприятия. Ничего особенного в этом нет: служба только-только начала работать, процесс управления инцидентами еще слабо настроен, и сотрудники ИТ не привыкли действовать по новой схеме. Но уже через месяц после запуска Service Desk можно получить данные, из анализа которых видно, где в процессе слабое место, что и как нужно исправить, кто мешает нормальному ходу процесса. Начнется бесконечная настройка и модернизация службы Service Desk. В зависимости от скорости реагирования на выявленные проблемы и неточности в функционировании службы будет сокращаться среднее время решения инцидентов, повышаться удовлетворенность пользователей и т. д.

Пути развития

После того как служба Service Desk начала стабильно работать и прошел период адаптации, после того как улягутся первые страсти пользователей, можно задуматься о том, в каком направлении развиваться дальше. Путей много. Самым очевидным из них является повышение компетенции первой линии поддержки. Сразу после запуска службы первая линия (операторы call-центра) сможет закрывать максимум 20-30% всех регистрируемых инцидентов. Этот результат весьма хорош. Но совершенству нет предела. Развивая компетенцию операторов, обучая их, добавляя им дополнительные права и обязанности, можно повысить процент инцидентов, закрываемых на первой линии поддержки. В этом случае специалисты второй и третьей линий в большей степени смогут посвятить себя сложным и нетривиальным задачам. Второй эффект от увеличения числа инцидентов, закрываемых операторами, проявится в большей удовлетворенности пользователей работой департамента ИТ: та часть вопросов, которая ранее решалась, к примеру, в течение двух-трех часов (время реакции второй линии поддержки), теперь будет решаться за 10-20 минут.

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

Без рисков не обойтись

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

Денис Бобров, заместитель руководителя ИТ-департамента ЗАО «Талосто», Bobrov_DA@talosto.ru

http://www.osp.ru

Сервисный подход и учет затрат ИТ-службы

Кирилл Скрипкин

Если результат деятельности ИТ-службы представляется в виде набора ИТ-услуг, оказываемых бизнесу, затраты ИТ-службы необходимо учитывать также в разрезе ИТ-услуг. При любом другом подходе затраты и результаты ИТ-службы оказываются несопоставимыми. Основой данного подхода выступает совокупная стоимость владения.

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

Модель оценки совокупной стоимости владения (Total Cost of Ownership, TCO) — одна из первых попыток привязать затраты ИТ-службы к надлежащим объектам затрат. Исторически она рассматривалась как модель учета затрат на активы вообще и учета затрат на ИТ-активы в частности. Объектами затрат в этой модели были рабочие места, оборудование, программные пакеты и даже ИТ-инфраструктура предприятия в целом. Для актива рассматривалась вся совокупность связанных с ним затрат, в том числе затраты на оборудование, программное обеспечение, администрирование, техническую поддержку, внешние услуги, потери от простоев пользователей и т. п.

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

Рис. 1. Выбор платформы на основе модели TCO

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

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

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

Вот пример семилетней давности. В организации X система SAP R/3 внедряется в качестве инструмента ведения бухгалтерского учета по GAAP. Необходимые операции по подведению баланса выполняются в таблицах Microsoft Excel и затем переносятся в R/3, где в полуавтоматическом режиме перекладываются в отчетность по стандартам GAAP. В то же самое время в организации Y система R/3 внедрялась для планирования закупок. В системе учитывались все запасы на складах, заявки на списание материалов и заявки на их закупку, причем объем информации не позволял вести такой учет за пределами системы R/3.

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

TCO ИТ-услуги и метод прямых затрат

ИТ-услуга — конечный результат деятельности ИТ-службы. Соответственно, задача определения TCO ИТ-услуги — классическая задача костинга (от английского слова costing — определение издержек), то есть задача определения себестоимости конечного продукта или услуги.

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

Простейшая модель костинга — метод прямых затрат, подробно описанный в книге Service Delivery, London: the Stationary Office, 2001. Согласно этой модели, все затраты делятся на прямые и косвенные. Прямые затраты относятся на ИТ-услугу непосредственно. Например, амортизация выделенного сервера электронной почты относится на услугу электронной почты. Также к прямым затратам можно отнести амортизацию специализированного программного обеспечения, например серверного ПО электронной почты или информационных терминалов Reuters, Bloomberg, РБК и т. д. Затраты на поддержку такого программного обеспечения или пополнение информационных баз данных со стороны внешних поставщиков также относятся к прямым.

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

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

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

В рамках модели прямых затрат решение задачи костинга в целом состоит из следующих шагов:

1. Разделение всех элементов затрат на прямые и косвенные. 2. Среди косвенных затрат выделение затрат, распределяемых по критерию, и затрат, распределяемых равномерно. 3. Для прямых затрат — непосредственное распределение на соответствующие ИТ-услуги. 4. Для затрат, распределяемых по критерию, — определение значения критерия для каждой ИТ-услуги и исчисление соответствующих этому значению затрат. 5. Для затрат, распределяемых равномерно, отнесение на каждую ИТ-услугу 1/N величины элемента затрат, где N — число ИТ-услуг. 6. Суммирование всех затрат по каждой ИТ-услуге.

Таким образом, для каждой ИТ-услуги рассчитываются прямые затраты на сопровождение. Подход TCO требует также определения потерь от простоев. Для расчета этих потерь простои делятся на четыре группы: «невидимый» простой, сбой операции, сбой процесса и сбой организации (рис. 2).

Рис. 2. Денежная оценка потерь от простоев

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

График на рис. 2 описывает зависимость потерь от простоя ИТ-услуги от длительности простоя данной услуги. Наряду со временем простоя на величину потерь влияет приоритетность ИТ-услуги и момент, в который случился простой. Например, для ИТ-услуг главной книги простой в момент подготовки бухгалтерской или налоговой отчетности имеет значительно более серьезные последствия, нежели в любое иное время. Исходя из этих факторов — длительности простоя, приоритетности услуги, момента простоя — выделяется несколько (обычно три-пять) категорий простоя, общих для всех ИТ-услуг организации. Например, если выделены категории простоя от A (наименее важный) до E (наиболее важный), то простой услуг Internet может относиться к категории A, простой электронной почты — к A или B в зависимости от длительности простоя, простой электронных платежей — к C, D или E, также в зависимости от длительности простоя.

Для каждой из таких категорий простоя устанавливается денежная оценка. Итоговая сумма потерь от простоя в этом случае составляет сумму произведений оценки часа простоя и времени простоя в часах по всем категориям простоя.

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

Затраты на ИТ-проекты и их распределение на ИТ-услуги

ИТ-услуги могут быть приобретены двумя способами: в рамках либо текущей деятельности, либо ИТ-проектов. Приобретение в рамках текущей деятельности полностью укладывается в схему рис. 3. Зато ИТ-проект требует более сложного учета затрат.

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

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

Отдельно следует рассмотреть закрытие временного центра затрат при успешном завершении ИТ-проекта. Примеры таких проектов: внедрение системы электронной почты, системы электронного документооборота, беспроводного доступа стандарта Wi-Fi. В этом случае распределение затрат зависит прежде всего от числа вновь созданных или модифицированных ИТ-услуг.

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

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

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

Кирилл Скрипкин — директор департамента ИТ-планирования и взаимодействия с бизнесом компании СУАЛ, k.skripkin@sual.com

Внедрение ITSM: памятка для начинающего

Автор статьи: Александр Башкиров

Ответы на наиболее часто задаваемые вопросы о том, как внедрять управление ИТ-услугами на основе рекомендаций ITIL

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

Прежде всего определимся с часто упоминаемыми терминами, вызывающими путаницу. Управление ИТ-услугами (Information Technology Service Management, ITSM) – это сервисный процессный подход к организации работы ИТ-службы. Суть его в том, что вся деятельность ИТ-подразделения рассматривается в разрезе услуг, оказываемых им другим подразделениям в соответствии с соглашениями об уровне услуг. ITSM декларирует, что ИТ-отделом можно управлять, основываясь на тех же принципах, которые применимы к бизнес-подразделениям.

Библиотека ИТ-инфраструктуры (Information Techno-logy Infrastructure Library, ITIL) – это библиотека рекомендаций, обобщающая международный опыт по организации работы ИТ-департаментов и разъясняющая, что надо сделать для реализации подхода ITSM. ITIIL состоит из ряда книг, каждая из которых описывает тот или иной аспект деятельности в виде набора процессов. В настоящее время выпущена вторая версия ITIL, активно ведется работа над созданием третьей. В ITIL описывается, как должна быть организована деятельность ИТ-структур, но не приводятся конкретные шаги по внедрению содержащихся в ITIL рекомендаций. Конкретные методики внедрения ITSM на основе ITIL предлагают компании, которые специализируются на подобных проектах.

Как объяснить бизнесу необходимость ITSM?

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

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

Как получить финансирование на проект и оценить его окупаемость?

Для получения финансирования проекта по внедрению ITSM часто необходимы убедительные обоснования. В зависимости от конкретного случая это могут быть следующие три основных аргумента.

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

Увеличение эффективности и направление фокуса ИТ-деятельности на решение задач бизнеса. Внедрение даже ограниченного набора процессов ITIL (службы Service Desk и процессов управления инцидентами и уровнем услуг) позволит организовать работу ИТ-службы таким образом, что в центре ее внимания окажется именно бизнес. ИТ-отдел из «вещи в себе» превратится в ориентированную на потребности бизнеса внутреннюю сервисную структуру.

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

Дополнительным аргументом может служить ответ на вопрос об окупаемости проекта по внедрению ITSM. Стоимость решения заявки на этапе промышленной эксплуатации решения, состоящего из процессной части и настроенной системы автоматизации в случае, когда внедрена часть процессов ITIL, по сравнению с ситуацией, когда не внедрен ни один из процессов, в пересчете на единицу времени оказывается ниже. Таким образом, окупаемость проекта по внедрению рекомендаций ITSM может быть вычислена для каждой конкретной организации. В простейшем случае рассчитываются стоимости единицы рабочего времени специалиста каждой из линий поддержки до и после внедрения. Более сложный расчет учитывает стоимость возможного простоя сотрудников бизнес-подразделений, стоимость аренды помещений и т.д.

Следует ли затраты на ИТ распределять по бизнес-подразделениям и бизнес-пользователям?

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

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

С чего начать внедрение? Какие процессы внедрять?

Проект по внедрению рекомендаций ITIL, как и любой другой, связанный с управлением, следует начать с определения бизнес-требований и анализа состояния дел ИТ-департамента. Для анализа можно применять известные методики (например, Pink Elephant, HP ITSM) или самостоятельно составленные опросные листы. Как правило, дополнительно проводится анализ по бизнес-модели: делается описание того, как работает ИТ-отдел в данный момент, в виде связанной совокупности бизнес-процессов. Следует отметить, что такой анализ полезен даже в случае полной деструктурированности работы ИТ, поскольку помогает выявить внутренние зависимости и связи, опираясь на которые, можно будет спроектировать тот или иной процесс.

Одновременно с построением картины работы «как есть» проводится анализ бизнес-требований к ИТ-отделу на основе сбора и обобщения требований и ожиданий бизнеса от ИТ и возможностей ИТ-службы удовлетворить потребности бизнес-подразделений.

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

Как установить соответствие между услугами, которые бизнес желает (или ожидает) получить от ИТ-подразделения, и ИТ-услугами?

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

Какие фазы внедрения ITSM существуют? Что влияет на его успешное завершение?

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

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

Обязательно ли организовывать Service Desk?

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

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

При отказе от Service Desk более вероятно возникновение «очередей» заявок у высококвалифицированных ИТ-специалистов, которые будут совершенно неэффективно тратить свои ресурсы. Запуск же квалифицированной службы Service Desk позволяет спустя некоторое время разрешать до 70% заявок на первой линии благодаря накоплению базы знаний и другим преимуществам правильно организованных процессов. Это экономит время высокооплачиваемых специалистов, и они могут направить его для решения более важных задач. Оставшиеся 30% заявок маршрутизируются таким образом, что гарантируется их скорейшее решение.

При отсутствии службы Service Desk ее функции выполняет вся ИТ-служба.

Как оценить численность сотрудников Service Desk?

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

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

Нельзя ли обойтись при внедрении рекомендаций ITIL без автоматизированной системы?

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

Если в компании уже есть система учета заявок, обязательно ли внедрять специализированный продукт для управления ИТ?

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

Может ли ITSM помочь при внедрении ERP (CRM и т.д.)?

Если в организации внедрен один или несколько процессов в соответствии с рекомендациями ITIL, безусловно, может. Служба Service Desk возьмет на себя ответы на запросы пользователей и регистрацию инцидентов, связанных с новой системой. Эти инциденты будут разрешаться в рамках процесса управления инцидентами, анализироваться и использоваться для выявления проблем в рамках процесса управления проблемами. Разрешение инцидентов будет происходить путем проведения изменений в рамках процесса управления изменениями, а информация о конфигурации инфраструктуры будет постоянно актуальной вследствие работы процесса управления конфигурациями. Расчет мощностей, требуемых для внедрения новой системы, будет проведен в рамках процесса управления мощностями, в рамках процесса управления доступностью будут сформированы требования, удовлетворение которых обеспечит требуемый уровень доступности. В рамках процесса управления непрерывностью будет сформирован план обеспечения непрерывности для ERP-системы, финансы на приобретение требуемых серверов и поддержку программно-аппаратного комплекса формируются в рамках процесса управления финансами, мероприятия по обеспечению безопасности конфиденциальных данных в ERP будут обеспечены в рамках процесса управления безопасностью. Далее, имея организованную в соответствии с определенными регламентами службу ИТ, легче проводить планирование внедрения, поскольку при четкой организации деятельности ИТ повышается прозрачность и управляемость ИТ.

Отдельно следует рассмотреть параллельное внедрение ERP и ITSM. В этом случае вероятность успешного завершения каждого из проектов будет ниже, чем при последовательном внедрении. Дело в том, что и тот и другой проект относятся к так называемым «стрессовым» проектам, требующим перестройки как ИТ-службы, так и бизнес-подразделений. Таким образом, на время параллельного внедрения ERP и ITSM повышается нагрузка на сотрудников, возрастает неопределенность и влияние человеческого фактора, в итоге значительно повышаются риски подобного проекта.

Чем ITSM может помочь при организации аутсорсинга?

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

Обязательно ли использовать консалтинг при внедрении ITSM?

Порой проще и выгоднее использовать компанию-консультанта, имеющую опыт внедрения проектов, связанных с ITSM, чем создавать свою команду. Тем более что после завершения проекта наверняка возникнет вопрос, что будет делать его команда. Распущена? Переведена на другие проекты? Как правило, внедрение рекомендаций ITIL — это совместный проект с внешней компанией-консультантом.

Что будет, когда закончится проект?

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

Александр Башкиров — ведущий консультант отдела IT/Telco Service Management компании BCC, abashkirov@bcc.ru

© osp.ru

Забудьте о KPI ! (или простые ошибки)

Забудьте о KPI !

Навсегда забудьте о KPI! Стройте и улучшайте процессы управления ИТ с четко поставленными целями. Тогда создавать KPI в творческих муках просто не будет необходимости. Показатели и так будут у вас под рукой. Парадокс? Давайте попробуем разобраться.

Ситуация в большинство ИТ-отделов с практикой создания и использования процессных метрик действительно удручает. Фразу «если не измеряешь, значит не управляешь» многие компании выучили наизусть, и ошибка номер раз – полное отсутствие измерения ИТ процесса – постепенно вымирает на просторах отечественного ИТ. Хоть что-нибудь, но померяем. Качественно ли измерим, то ли измерим, что нужно – второй вопрос. Средняя температура известна. И после шага один становится немного сложнее. Дальше нас подстерегают интересные, познавательные грабли.

До сих пор во многих известных и уважаемых компаниях наиболее используемым отчетом Service Desk все еще остается простой реестр инцидентов с главным показателем – количество инцидентов. Это хороший KPI процесса управления инцидентами? Прошу вас, после чтения этой статьи – взгляните на этот простой вопрос и ответьте на него еще раз.

Основные ошибки.
Попробуем типизировать наиболее распространенные ошибки создания и внедрения показателей:
1) Не измеряем вообще.
2) Набор показателей формируем на основе списка, взятого из литературы, системы, уже реализованного проекта или просто придуманного человеком, в глаза не видевшего измеряемого процесса.
3) Ключевых показателей формируем столько, сколько это возможно в принципе – чем больше, тем лучше.

Номер раз обсуждать не будем – ясно без микроскопа.

Ошибка номер два наиболее логично вытекает из нашей любимой библиотеки ITIL. Там со времен второй версии к KPI относились так, что иногда становилось жутко. Как тонко подметил когда-то один коллега: берем аналогию процесса с автомобилем, где ключевые показатели – спидометр, тахометр и пр. Тогда KPI, приведенные в ITIL v2 – это намек на прибор, измеряющий обороты двигателя в милях, скорость в фаренгейтах и температуру двигателя в градусах. Цельсия или угловых градусах – изволь читающий угадать сам. А еще разработчики ITIL любят давать по несколько штук таких приборов, дублирующих показания в разных шкалах.

О чем говорят эти метрики? Общее количество чего – зарегистрированных, закрытых, открытых за период, или всего в системе? Каким средне- или долгосрочным целям соответствуют метрики? Каковы пороги «удовлетворительно – нормально – хорошо – отлично» для этих метрик? А что делать, если неудовлетворительно, если инциденты сваливаются в backlog мы их закрываем медленнее, чем регистрируем? Количество инцидентов вдруг сократилось на 20%, а потом еще на 30%? Это как, хорошо или плохо? Если хорошо – мы проактивны! Если плохо – чем же мы будем заниматься?

Ну ладно, бог с ITIL’ом. Наша любимая библиотека никогда не акцентировалась особенно на шаге измерения. Спасибо и за цикл Деминга, положенный в основу процессной модели. Возьмем разработанные системы Helpdesk. Их разработчики (о боже!) тоже читали ITIL и умеют фантазировать на тему KPI. Возьмем оттуда, ведь эта система была выбрана нами, а значит там должно быть большинство необходимых отчетов для подсчета KPI. На семинарах часто наблюдаю одна и та же забавную картину, где рабочая группа приступает к проектированию KPI. Процесс спроектирован, теперь его нужно как-то измерять. Хорошо, если в наличии шаблоны реализованных проектов. А давайте посмотрим на существующие наборы KPI? Те, что понравятся – оставим, а остальные додумаем уже потом. Я не то, чтобы против «посмотреть», однако в большинстве случаев такое «посмотрим» приводит к бездумному копированию чужих измерителей эффективности и результативности процесса на свой собственный.

Копирование возможно только в одном случае – если копируемый процесс соответствует поставленным целям, содержит качественные, опробованные KPI и он копируется целиком!

Ошибка номер три, пожалуй, самая известная и распространенная при пользовании ИТ вообще – обусловленная кажущейся легкостью получения данных, годных для отчетности в информационных системах. В момент, когда мы перестаем различать просто данные и информацию (данные, годные для анализа с целью принятия решений), обычно стартует ошибка номер три. «Мы пока сами не знаем, какая именно информацию нам понадобится» – а поэтому давайте разработаем как можно больше отчетности, избыточной, дублирующей друг друга. Отчеты – это же так просто! «Пусть их будет как можно больше, а уж мы точно разберемся, какие использовать» – обычная для многих проектов формулировка. И заказчики процессов управления ИТ стараются не отставать: сколько у вас KPI для процесса? Всего двадцать?! Да вы что, в гроб меня загнать хотите. Конечно нужно больше! И пошла-поехала генерация любых показателей, выдаваемых за KPI.

Ценная информация быстро тонет в бесконечном, фрагментарно обрабатываемом потоке данных. Отсутствует любая, хотя бы самая простая технология проектирования KPI.

© Александр Жилинский,  ИТ консультант

Общая схема процессов ITIL v3

© http://www.best-management-practice.com/officialsite.asp?DI=597910&trackID=002192

Основные направления защиты

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

Защита документов

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

Защита каналов утечки

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

Мониторинг (аудит) действий пользователей

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

• перемещение документа, как единого целого;
• копирование информации из документа;
• изменение документа с целью обмана следящих систем.

К первой группе можно отнести копирование файла на сменные носители, отправку по почте, публикацию в Интернет, печать.

Ко второй – копирование информации из документа в буфер Windows, копирование временного файла Windows и т.п.

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

Классификация внутренних нарушителей

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

• Злонамеренные;
• Халатные;
• Действующие по заказу;
• Ставящие себе цели сами;
• Охотники за конкретной информацией;
• Ворующие все, что смогут.

Для составления прогноза действий конкретного нарушителя его поведение нужно правильно классифицировать.

Внутренних нарушителей можно разделить на следующие категории:

• Неосторожные;
• Манипулируемые;
• Саботажники;
• Нелояльные;
• Мотивируемые извне.

Таблица2.

Нарушители по типу могут быть подразделены на незлонамеренных и злонамеренных.

Незлонамеренные нарушители

В свою очередь незлонамеренные нарушители подразделяются на:

• Манипулируемых;
• Неосторожных.

Неосторожные (халатные)

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

Манипулируемые

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

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

Злонамеренные сотрудники

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

• Саботажники;
• Нелояльные;
• Мотивируемые извне;
• Другие.

Саботажники (обиженные сотрудники)

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

Нелояльне сотрудники

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

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

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

Нарушители, мотивированные извне

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

Другие типы нарушителей

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

Пресечь утечку такой информации техническими средствами невозможно.

Нетехнические меры защиты от внутренних угроз

Психологические меры

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

Если же система защиты от внутренних пользователей внедряется открыто, то ознакомление сотрудников с новыми регламентами, ознакомление с попытками выноса запрещенной информации за пределы компании поможет предотвратить хищение информации незлонамеренными сотрудниками.

Организационные меры

Права локальных пользователей

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

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

Стандартизация ПО

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

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

Регламентация процессов обслуживания и осуществления модификации аппаратных и программных ресурсов автоматизированных систем

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

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

Все изменения конфигурации технических и программных средств защищенных рабочих станций (PC) и серверов (различных уровней защищенности в соответствии с «Положением о категорировании ресурсов АС») должны производиться только на основании заявок начальников структурных подразделений организации либо заявок начальника IT, согласованных с руководителем службы защиты информации.

Право внесения изменений в конфигурацию аппаратно-программных средств защищенных рабочих станций и серверов АС должно быть предоставлено уполномоченным сотрудникам (могут быть отданы соответствующими приказами) определенных подразделений:

• в отношении системных и прикладных программных средств, а также в отношении аппаратных средств – уполномоченным сотрудникам отдела IT;
• в отношении программно-аппаратных средств защиты – уполномоченным сотрудникам службы защиты информации;
• в отношении программно-аппаратных средств телекоммуникации – уполномоченным сотрудникам службы (отдела) связи (телекоммуникации).

Изменение конфигурации аппаратно-программных средств защищенных рабочих станций и серверов кем-либо, кроме уполномоченных сотрудников перечисленных подразделений, должно быть ЗАПРЕЩЕНО.

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

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

Специфические решения

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

Работа с кадрами

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

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

Выявление «специалистов-любителей» возможно во время традиционной аттестации. Стоит добавить в опросник вопрос «Как снять зависший процесс в Windows?» и провести разъяснительную работу с теми, кто начнет ответ со слов: «Нажать одновременно клавиши Ctrl, Alt и Del». Ведь правильный ответ на этот вопрос для большинства пользователей – «Вызвать системного администратора».

Хранение физических носителей

В настоящее время еще одним каналом утечки информации является вынос носителей с резервными копиями с территории предприятия.

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

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

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

Уровни контроля информационных потоков

Системы контроля информационных потоков позволяют контролировать информационные потоки в трех режимах:

• Режим архива;
• Режим сигнализации;
• Режим активной защиты.

Режим архива

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

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

Недостатком этого режима является невозможность предотвращения утечки.

Режим сигнализации

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

Преимуществом этого способа является возможность немедленно реагировать на события.

Недостатком этого режима является также невозможность предотвращения утечек, а для офицера ИБ недостатком является необходимость постоянно находиться в режиме on-line.

Этот режим нередко используется для тестовой эксплуатации системы перед переходом к режиму активной защиты.

Режим активной защиты

Этот режим позволяет активно вмешиваться в информационные процессы, блокировать опасные операции безвозвратно или до их разрешения офицером безопасности.

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

Недостатком этого режима является необходимость постоянного присутствия офицера информационной безопасности для разбора спорных случаев и ложных срабатываний. На сегодняшний день максимальная достоверность использующихся технологий не превышает 90%, поэтому в режиме активной защиты на офицера ИБ ложится ответственность за оперативное решение спорных вопросов. Также недостатком такого режима является высокая требовательность к ресурсам, особенно при обработке on-line потоков. Приходится резервировать каналы и наращивать вычислительную мощность, чтобы обеспечить минимальную задержку писем и сообщений в Интернет.

Заключение

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

Литература

1. Законодательные акты Европы и США в сфере IT-безопасности http://www.infowatch.ru/threats?chapter=150685169&id=170278262.

© Безмалый В.Ф.

MVP Consumer Security

Microsoft Security Trusted Adviser

Мысли про Helpdesk, SLA и прочее

Цель любого helpdek – обеспечение единой точки контакта ИТ – бизнес, и, в рамках процесса управления инцидентами, с поправкой на SLA (для определения приоритетов), максиально быстрое разрешение поступающих запросов. Таким образом, скорость, с которой разрешается тот или иной конкретный запрос, зависит от текущей загрузки сотрудников ИТ, и от SLA инициатора запроса. (А SLA, в свою очередь, зависит от должностных обязнностей инициатора и от характера определяющего сервиса).

Таким образом, для реализации описанной выше модели с точки зрения ИТ, требуется в первую очередь определить  перечень сервисов, затем проранжировать этот перечень по сложности поддержки и определить минимальное и максимальное время восстановления (либо предоставления – в случае так называемого «сервиса по запросу»), после чего ввести логическое разделение не ИТ-сотрудников на группы по отношению к каждому предоставляемому сервису. После чего внедрить эту стройную картину в жизнь. Для этого разработанная модель должна быть доведена до не-ИТ подразделений, SLA согласованы с руководством этих подразделений и руководством предприятия, helpdesk обучен… По идее, именно в этот момент и должно наступить великое счастье.

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

• «Уход от ответственности». Ситуация встречается, когда служба helpdesk, в силу тех или иных причин (ограниченность бюджета, времени, денег, ресурсов, компетенции) не имеет возможности выполнить SLA. При этом не секрет, что часто мотивация сотрудников helpdesk зависит от скорости выполнения заявок, и прочих количественных факторов (Как это ни странно, но на качественные факторы мало когда обращают внимание). Таким образом, в особо (технологически) сложных случаях, для того, чтобы не портить статистику, сотруднику helpdesk проще закрыть заявку с приемлемой причиной (например, «не предоставлены все требуемые данные»), чем разбираться с конкретной проблемой. И это явление порождает следующую ситуацию:
• «Излишняя формализация». Helpdesk, как инструмент поддержки пользователя, при фиксации и первичной классификации обращения, основывается на информации, предоставленной пользователем. Часто для сбора информации применяют автоматизированный механизм «опросных листов» или самостоятельного заполнения форм пользователем. Чрезмерная формализация этой процедуры позволяет (на вполне законных основаниях) закрыть обращение в случае малейшей ошибки в данных, предоставленных пользователем.
• «SLA в голове». Ситуация, при которой формально SLA есть, но фактически в качестве SLA используются произвольные величины, находящиеся в умах одного-двух сотрудников Helpdesk’a. Вариант: SLA вообще не прописаны, а служба поддержки работает «по понятиям», то есть SLA изменяется от обращения к обращению, или вообще может зависеть от отношения конкретного сотрудника Helpdesk к конкретному пользователю.
• «Размывание зоны ответственности». В этом случае в SLA фиксируются наиболее типовые сервисы, а обращения по нетиповым сервисам игнорируются либо «запускаются по кругу», превращая процесс в классический «футбол заявки». Как вариант, SLA по нетиповым сервисам составляется таким образом, чтобы сотрудник Helpdesk всегда имел возможность закрыть его на основании какой-либо формальной причины. (см. пункт «излишняя формализация»)
• Helpdesk представляет собой одновременно первую, вторую, третью и т.д. линии поддержки. Подобная организация сводит на нет преимущества организации многоуровневой поддержки, так как в рамках подобного универсального подразделения будут находиться специалисты разного уровня, и, как следствие, запросы по одному и тому же сервису, в рамках одного SLA, будут выполняться с разной скоростью и различным качеством.
  Можно возразить, что в любом Helpdesk’e на одной линии работают специалисты разного уровня. :) Так-то, оно, конечно, так, но уровень их компетенции колеблется у некого среднего уровня, и вряд ли на Helpdesk пойдет работать человек с компетенцией сетевого администратора…
• Helpdesk представляет собой «центр защиты специалистов», то есть низкоквалифицированных сотрудников, которые всеми возможным средствами пытаются не допустить общение пользователя со второй линией поддержки, и, в меру своей квалификации, решать все поступающие к ним инциденты. Обычно подобная картина перерождается в излишнюю формализацию, поскольку задача первой линии в этом случае – найти формальный повод не выполнять требуемых работ. На практике такая картина часто возникает из-за того, что неверно трактуется описанная в ITIL организация службы поддержки.
• «Полный бардак». Helpdesk не организован, но декларируется «жизнь по ITIL». Учет заявок не ведется, или половина заявок проходит вне системы учета. Формально SLA определены, но фактически об этом никто не знает. И все счастливы… (Клинический случай?)

К чему это я? Да к тому, что формально внедрив «что-то из ITIL», организовав Helpdesk, радоваться и расслабляться рано – проблемы будут, только другого порядка, возможно, решаемые более просто – по отношению к тем, которые присутствуют в ситуации, когда Helpdesk’a нет, как класса, а ITIL является магической аббревиатурой…

© Alexander Bashkirov

Обманутые ожидания ITIL: Как внедрять процессы и не парализовать работу службы поддержки.

Если быть очень кратким, то ITIL – это просто инструмент. Как мы знаем, сам по себе инструмент работу не делает, даже если это супер-мега-крутой инструмент. Этот пост об обманутых ожиданиях. Ожиданиях того, что инструмент будет делать работу сам.

Статистика блога говорит, что вопрос количества персонала куда как более интересен, чем правильное общение с тех.поддержкой и даже самый популярный пост – быстрый генератор карт AD. Это и неудивительно, оптимизация штатов – штука такая, может начаться и в вашей компании. Кстати, почитать что делать в такой ситуации и как это происходит можно уже сегодня в блоге Алены – толкового специалиста по работе с кадрами. Вопрос грамотных людей особенно важен для внедрения процессов ITIL и MOF – ведь именно они будут использовать этот инструмент. Именно Ваши люди по идее станут работать лучшее, веселее и результативней…

“Увы! Далеко не всегда, даже когда есть единая точка контакта счастье наступает быстро и безоговорочно. (Скромно молчу про остальные случаи). Жизнь вносит свои коррективы, выражающиеся порой в довольно забавных казусах. Рассмотрим типичные ситуации для внутренней поддержки…”

Читайте Александра Башкирова про работу Helpdesk

Ставьте перед собой реальные цели! Убедитесь, что эти цели понимает и разделяет ваш коллектив.

Основная проблема внедрения процессов в том, что, как правило, никто не представляет зачем этот процесс нужен. Обидно, что иногда даже идеологи внедрения процессов ITIL или MOF не могут внятно и четко расказать ЧТО и ЗАЧЕМ они внедряют. Если вы внедряете процессы ради процессов, то можете уже сегодня рапортовать, что проект завершен. Если же вы ожидаете, что внедрение процессов поможет вам в чем-то конкретном, то срочно надо вспомнить как у вас называется проект.

Например, если проект называется “Внедрение процессов ITSM на предприятии XYZ”, то это симптом безнадежного внедрения. Смысл прост, название не говорит нам о ВЫГОДЕ которую мы должны получить с этого проекта. Т.е. цель внедрения остается внутри бумаг, которые, будем честны сами с собой, редко кто читает.

Итак, назовите свой проект так, чтобы в одном предложении было видно главную ЦЕННОСТЬ вашего внедрения – это очень важно. Ведь так вы сможете избежать большого числа бюрократичесикх войн “процесс-ради-процесса”. У вас всегда на виду будет главный критерий правильности для любых спорных ситуаций- что лучше, быстрее, дешевле помогает достичь ценности, то и верно. Иначе вас ждут долгие и тяжелые в разрешении философские споры вроде:

-Каждый звонок в службу Service Desk должен быть задокументирвоан в программе – так по процессу(книге, тренингу) правильнее!

-Нет, понимаете, у нас нет столько операторов, чтобы регистрировать в Excel каждый звонок, а автоматически без АТС и средств автоматизации это не возможно! Так что регистрируем только серьезные проблемы

- Нет вы понимаете, процесс говорит, что тогда управление проблемами будет не полным, а это неправильно.

Спроси меня кто-нибудь еще год назад кто из спорщиков правее, я бы не колебась сказал, что конечно знаток ITIL  – абсолютно прав. Правильное документирование – это наше все, без этого ничего не достигнем. Но сейчас… я бы не стал так катигорично заявлять. Все сильно зависит от ЦЕЛЕЙ, которые ставят для внедрения процессов. От ЦЕННОСТИ, которую служба ИТ, действуя по этим процессам, должна принсоить.

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

• Убедитесь что существует понятная и осязаемая цель(или цели) для внедрения процессов ITIL/MOF.
• Сформулируйте эту цель доступно и понятно прямо в названии проекта. Причем цель должна выражать ценность проекта. Т.е. целью может быть ”10 сотрудниками поддержки решать проблемы 2000 человек”, но сформулировать ее лучше так:“Разрешение большинства проблем ИТ за 1 день в результате внедрения процесса управления инцедентами ITIL” . На мой взгляд, такое название лучшее чем “Первый этап внедрения процессов ITSM” отражает и ЦЕЛЬ внедрения, и его ЦЕННОСТЬ.
• Ищите единомышленников и формируйте культуру достижения ЦЕННОСТЕЙ, а не просто работу по процессу.

Процессы и автоматизация – две важные составляющие успеха, которые зависят друг от друга.

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

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

Часто просто поразительных успехов в вопросе повышения эффективности труда можно достичь более простыми процессами, чем ITIL. Например, стандартизация ПО и рабочих мест – т.е. устранение зоопарка снимут вопрос уникальных проблем, а так-же позволят более прогнозируемо тратить деньги и на поддержку, и на закупки. Автоматизация процесса инвентаризации – это не только большое подспорье в вопросе борьбы с воровством железа, но и, я считаю, просто обязательный элемент для актуализации CMDB в рамках ITIL.

Microsoft разработал достаточно интересную методологию, которая является сплавом MOF(т.е. ITIL), стандартизации и автоматизации – модель оптимизации инфраструктуры(Infrastructure Optimization Model)

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

Модель оптимизации инфраструктуры (Infrastructure Optimization Model) помогает клиентам добиться существенной экономии средств, затрачиваемых на ИТ-инфраструктуру, путем перехода от неуправляемой среды к динамической среде

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

Посмотрим, что нам говорят про первый уровень в модели IO:

«Базовый» уровень: «тушение пожаров»

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

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

Не существует механизма обмена накопленными знаниями между разными областями ИТ в организации.

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

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

Вы узнали здесь черты своей организации? Узнайте как это можно исправить.

© Alexander Bashkirov

Оптимизация AD: Cтруктура орг. подразделений(OU) служит для делегирования прав и назначения групповых политик

Дерево орг. подразделений(OU) – это, прежде всего, рабочий инструмент администратора сети, поэтому структура должна быть понятной и удобной именно администратору для выполнения ежедневных операций. Организационное подразделение в Active Directory, как и обычная папка-контейнер, может содержать различные объекты: пользователей, группы, компьютеры, другие папки и организационные подразделения.

Возможность назначать групповые политик на орг. подразделения (OU) – основное отличие от обычного контейнера AD. Для OU, как и для обычного контейнера, можно гибко задавать права доступа и делегировать управление. Забавный факт, в оснастке Windows 2008 Active Directory Users’n’Computers просто так создать контейнер из меню New не получится, на выбор только объекты или орг. подразделение.

Таким образом, задачи OU, помимо хранения объектов в Active Directory это
•    Делегирование управления другим администраторам компании
•    Назначение групповых политик

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

Разрабатывайте дерево OU в первую очередь для делегирования прав и удобства работы

Вопрос какова “правильная структура Active Directory” конечно стандартный и очень частый, но достаточно дискуссионный, так как у всех организаций разные уровни зрелости ИТ, и всегда есть свои особенности администрирования ИТ-систем. В частности, важно знать: сколько людей сопровождают AD, какое количество площадок, каким образом все организовано административно-нормативно, какие есть принятые политики безопасности.

По аналогии с известной моделью оптимизации ИТ-инфраструктуры (IO модель) типовая эволюция дерева OU в разных компаниях примерно такая:

1. «Базовый уровень» – пользователей складываем в папку Users, иногда в специально созданные один или два контейнера OU без особого смысла. О том, что такое OU в теории никто ничего не знает, зачем завели – не помнят (достаточно много компаний).
2. «Стандартизованный уровень» – структура OU повторяет штатное расписание компании… ну без комментариев, кроме одного – иногда бывает, что такая «штатка» куда точнее отражает реальность, чем например известные документы в отделе кадров. Распространенность – многие компании, считающие себя продвинутыми в AD, но без географических особенностей. Скажем честно, усилия, которые тратятся на поддержание такой структуры, как правило, неоправданные.
3. «Рациональный уровень» – структура OU сформирована с учетом количества администраторов и делегирования полномочий на первом уровне вложенности, как правило, это география, а дальше повторяет штатное расписание из «стандартизованного уровня». Смысл в том, что в региональных отделениях компании есть свои админы, которые должны следить за своими пользователями – так что OU первого уровня заводят по географии, которая может несколько отличатся от структуры компании, но часто к ней крайне близка.
4. «Динамический уровень». Структура OU организована так, чтобы с минимальными усилиями решать известные задачи администрирования пользователей, компьютеров и групп, при этом имея возможность предлагать людям инструменты для гибкой самостоятельной работы.

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

Организация OU на примере структуры AD -  встречается и в Windows SBS, и в больших распределенных каталогах Active Directory

За основу для проектированы своего дерева OU в Active Directory имеет смысл взять стандартный подход, который использует Microsoft в своих решениях. Этот подход можно увидеть и в реализации дерева OU MyBusiness в Small Business Server, и в больших штучных проектных решения MCS для конкретных заказчиков.

Единица администрирования и делегирования – ветвь дерева OU, внутри которой структура создана , прежде всего, для удобства ежедневной работы и групповых политик. Имеет смысл разделить на отдельные контейнеры пользователей, группы безопасности и рассылки, а также создать различные контейнеры для рабочих станций, лэптопов и серверов.

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

Помните, что делегировать доступ лучше всего, используя ролевую модель администрирования, т.е. предоставлять доступ для специально созданных ролевых групп безопасности, куда затем включать учетные записи администраторов. Для делегирования доступа, конечно же, надо использовать удобный, надежный и простой Мастер делегирования прав доступа Active Directory, который запускается из контекстного меню оснастки Active Directory Users’n’Computers.

Важно заметить, что здесь речь идет именно о каталоге Active Directory, т.е. мы предоставляем доступ для создания-удаления-перемещения пользователей, компьютеров и групп внутри контейнеров. Делегирование административных прав на конкретные рабочие станцией и сервера – это вопрос групповых политик и назначаемых групп.

Лучшее решение – решение удобное в реальной работе

Свою структуру можно создать вручную, можно ее существенно расширить или наоборот упростить по сравнении с примером на картинке. Иногда есть смысл использовать скрипты для генерации дерева OU из штатного расписания, а можно внедрить полноценное решение по оптимизации работы с идентификационной информацией, например MS Identity Lifecycle Management.

Какой бы из вариантов работы вы не выбрали – помните, что обычным людям все эти деревья OU совершенно неинтересны, нужно чтобы все работало быстро и надежно.

Успехов.

© Alexander Bashkirov

Новые технологии? Старые проблемы!

Сегодня мы с вами живем в мире быстроразвивающихся технологий. Еще несколько лет назад никто и не думал о таком широком распространении мобильных технологий, а уж, тем более, о внедрении «вычислений в облаке». Еще недавно никто не задумывался о внедрении беспроводных сетей, а сегодня? Сегодня эти технологии прочно вошли в нашу жизнь.
Однако не стоит забывать о том, что новые технологии часто несут с собой не только очередные блага, но и новые угрозы. А если на эти угрозы накладывается еще и резко снижающийся профессиональный уровень ИТ (это больная тема, которую нужно оговаривать отдельно), и резкий рост числа слабо подготовленных, а вернее, просто не подготовленных в вопросах безопасности, пользователей, то картинка становится совсем грустной.
Давайте рассмотрим подробнее каждую из приведенных технологий и угрозы, которые она несет с собой. Хотелось бы отметить, что в одной статье нельзя рассмотреть все угрозы для каждой из технологий, поэтому перечень угроз будет далеко не полным.
Мобильные устройства
В перечень рассматриваемых мобильных устройств можно включить такие устройства как ноутбуки, коммуникаторы, смартфоны, устройства для хранения данных (флешки и внешние жесткие диски, плееры большой емкости) и т.д.
Что несет с собой применение подобных технологий? Только ли благо? Отнюдь нет!
Да, удобство применения таких устройств, несомненно, но ваша безопасность оставляет желать лучшего. Давайте подумаем вместе с вами, что же привносит в нашу жизнь использование мобильных устройств. Только ли благо? Надеюсь, что, прочитав эту статью, вы задумаетесь над проблемой широкого применения подобных устройств. Итак, приступим.
Сегодня смартфоны и КПК (PDA – Personal Digital Assistants в англоязычной литературе) имеют настолько высокое быстродействие и большое количество памяти, как ПК несколько лет тому назад. Многие из подобных устройств существенно улучшают производительность труда, облегчая сотрудникам доступ к информации. Однако необходимо понимать, что использование подобных устройств приносит и новые риски для организаций, так как конфиденциальные, корпоративные и просто персональные данные могут быть утеряны в случае утраты устройства. Появляются новые типы вредоносного ПО, спама и ПО по взлому мобильных устройств.
Смартфоны и коммуникаторы сегодня объединяют в себе полноценные телефоны с возможностью полноценной обработки данных, ранее присущей только ПК. Помимо обычных телефонных звонков и SMS (MMS), пользователи могут запускать приложения, сохранять и управлять данными в корпоративных сетях и Интернет. Карты памяти для подобных устройств уже
перешагнули порог в 8 Гбайт, обеспечивая вполне достаточный объем памяти для хранения данных и приложений. Не стоит забывать, что сегодня разработчики ПО могут писать приложения для мобильных платформ, используя все большее количество программных инструментов. Появляющиеся сегодня операционные системы типа Symbian или Microsoft Windows Mobile позволяют неограниченно устанавливать приложения. Внедрение беспроводных технологий типа Wi-Fi или Bluetooth способствует ускоренному внедрению данных устройств в бизнес-среде. Все чаще и чаще организации начинают понимать, что обеспечение безопасности мобильных устройств настолько же важно, так и обеспечение безопасности рабочих станций и серверов. Однако не стоит забывать, что немалая часть подобных устройств используется домашними пользователями, а они, увы, все еще не озабочены проблемами безопасности и более того, считают, что за них должны думать производители оборудования и программного обеспечения.
Увеличение числа мобильных устройств.
Согласно данным IDC, число мобильных сотрудников в мире превысит 850 миллионов сотрудников уже в 2009 году1, что сопоставимо с четвертой частью всей рабочей силы во всем мире. Прогнозируемый рост числа смартфонов и коммуникаторов вынудит организации считаться с их влиянием на безопасность предприятия. Уже сегодня многие служащие используют смартфоны, коммуникаторы и PDA для ведения деловых переговоров и хранения важных данных, не нуждаясь при этом в ПК. В дополнение к стандартным телефонным функциям, персонал может использовать подобные устройства для:
 Пересылка email;
 Пересылка мгновенных сообщений (SMS, MMS, IM-сообщений с помощью ICQ или Windows Messenger);
 Использование приложений:
o ERP –систем;
o CRM-систем;
o SFA (системы автоматизации продаж);
 Просмотр и анализ штрих-кодов;
 Сетевые игры;
 Различного рода чаты;
 Web-серфинг;
 Загрузка и совместное использование файлов в Интернет;
 Хранение персональной и конфиденциальной информации;
 И т.д.
Все это приводит к тому, что данные устройства будут представлять все большую опасность для компании в целом. 1 1 IDC, Worldwide Mobile Worker Population 2005-2009 Forecast and Analysis, Doc #34124, Oct 2005
Вместе с тем стоит учесть, что все большее число компаний будет использовать данные устройства для доступа к деловым приложениям и данным компаний, что постепенно превратит PDA и мобильные устройства из дополнительных в критические устройства для бизнеса компании.
Риски безопасности, связанные с мобильными устройствами.
Стоит понимать, что сегодня мобильные устройства приносят не только увеличение производительности, но и новые угрозы безопасности, нарушение которой может очень дорого стоить предприятию.
Все увеличивающееся число мобильных пользователей и взрывной рост Интернет уничтожил понятие периметра организации. Защита сети компании с помощью межсетевого экрана больше не отвечает современным реалиям. Пользователи часто путешествуют вне периметра, где в свою очередь подвергают рискам конфиденциальные и персональные данные и могут подвергнуться риску нападения. Мобильные устройства могут быть легко атакованы с помощью вредоносного ПО или использоваться для его переноски. Другая опасность заключается в мобильности этих устройств – их легко потерять или украсть, что поставит под угрозу данные, которые на них хранятся.
Основные риски, связанные с мобильными устройствами:
 Потеря конфиденциальных данных из-за хищения или утери мобильных устройств;
 Потеря производительности из-за заражения вредоносным ПО;
 Потеря конфиденциальных данных из-за заражения вредоносным ПО;
 Мошенничество и потеря производительности из-за взлома.
Кроме того, нельзя забывать, что современный мобильный телефон может быть так же орудием атаки в руках умелого злоумышленника. Так, к 1 октября 2008 года анонсирован выход NeoPwn — телефона на базе Neo FreeRunner. Основной особенностью данного телефона является режим Pwn, в котором он занимается поиском уязвимостей Bluetooth и Wi-Fi. Телефон оснащен большим набором атакующего софта, включая Metasploit и Airhack. Телефон доступен в различных конфигурациях c ценой от $699. Также можно приобрести программный пакет NeoPwn без самого телефона, начиная от $79. (http://www.neopwn.com)
Потеря конфиденциальных данных из-за хищения или утери мобильных устройств
Сегодня стоимость аппаратных средств во много раз меньше, чем стоимость информации, содержащейся на устройстве. Потерянные данные могут привести к потере репутации, потере конкурентоспособности и потенциальным судебным тяжбам.
Во всем мире уже давно вопросы шифрования данных регулируются соответствующими законодательными актами. Так, например, в США, U.S. Government Information Security Reform Act (GISRA) требует шифрование данных для защиты конфиденциальной информации, принадлежащей правительственным органам. В странах ЕС принята Директива European Union Data Privacy Directive. Канада и Япония имеют свои соответствующие инструкции.
Все эти законы предусматривают серьезные штрафы за утрату персональной или корпоративной информации.
Как только ваше устройство похищено (утеряно) – ваши данные могут быть утрачены вместе с ним. Для запрета несанкционированного доступа к данным можно использовать две технологии:
 Удаленное стирание данных
 Шифрование данных
Данные могут быть стерты удаленно по специальной команде стирания или автоматически из-за нарушения политики безопасности (превышения количества неудачных входов в систему). Следует учесть, что удаленная команда стирания далеко не всегда эффективна, так как она может не быть передана, если устройство не подключено к Интернет или беспроводной сети. В таком случае шифрование обеспечит куда более надежную защиту для ваших данных.
Кроме того, не стоит забывать о такой опасности, как несанкционированный доступ к данным во время ремонта (в том числе гарантийного), либо продажи устройств, бывших в употреблении.
Риски вредоносного ПО
Сегодня риски вредоносного ПО на обычных ПК уже давно привычны, но возможности мобильных устройств делают их все более привлекательными для вирусописателей. Перспективы распространения вредоносного ПО для мобильных устройств несут все большие риски для корпоративных пользователей.
В свете дальнейшего развития технологий мобильной связи в будущем мы с вами увидим бурный всплеск мобильной преступности. Стимулом этому является унификация абонентских телефонов. Уже сейчас большая часть смартфонов использует всего четыре программные платформы – Symbian, Microsoft Windows Mobile, Palm Source и Linux.
Наибольшей угрозой для пользователей смартфонов являются действия спамеров, фишеров и вирусописателей. Все действия подобных злоумышленников будут направлены, прежде всего, на хищение конфиденциальной информации, личных данных или на создание проблем в работе устройств. Не стоит недооценивать и еще одну угрозу, о последствиях которой мы все чаще слышим в новостях. Это перехват голосового трафика, т.е. незаконное прослушивание телефонов. Стоит соблюдать несколько несложных правил для минимизации риска заражения своих устройств:
 необходимо отключать Bluetooth и инфракрасный порт в местах массового скопления народа
 следует принимать и открывать файлы, присланные только из достоверных источников;
 нельзя отвечать на подозрительные сообщения;
 необходимо установить специальные антивирусные программы, которые сегодня существуют практически для всех основных типов мобильных платформ.
В компании Trend Micro – разработчике средств защиты от вирусов и других угроз – прогнозируют начало массовых вирусных «мобильных» эпидемий, как только доля пользователей смартфонов достигнет 30-50% от общего числа сотовых абонентов.
Какую опасность современные вирусы представляют для смартфона?
Вирусы могут:
 незаметно для пользователя проводить массовую рассылку SMS и MMS, за которые абоненту придется платить; несанкционированно звонить на платные номера;
 уничтожить данные пользователя (телефонная книга, файлы и т.д.) или похитить конфиденциальную информацию;
 заблокировать функции телефона (SMS, игры, камера и т.д.) или аппарат в целом;
 разряжать аккумулятор телефона в несколько раз быстрее обычного;
 рассылать от вашего имени всеми возможными способами (e-mail, WiFi, Bluetooth и т.д.) зараженные файлы;
 при синхронизации смартфона с компьютером переслать на ПК деструктивный код.
Как вирус может попасть на ваш смартфон?
 Через Bluetooth-соединение;
 В MMS-сообщении;
 При загрузке в смартфон ПО из ненадежного источника.
Крупномасштабная вспышка вируса на открытой платформе возможна при наличии следующих условий:
1. Достаточное количество терминалов данной платформы, чтобы стать интересной целью для авторов вирусов
2. Достаточно множество функциональных возможностей для действий вируса.
3. Достаточно возможностей соединения, чтобы вирус распространялся.
Заражению вирусом подвержены не только смартфоны. «Лаборатория Касперского» обнаружила вредоносные программы, способные заражать мобильные телефоны с поддержкой технологии Java (J2ME). В последние годы эта платформа устанавливается на все трубки, поскольку с помощью нее запускаются приложения и игры. Оказавшись в мобильнике, троянец начинает рассылать сообщения на некоторые платные мобильные сервисы. При этом со счета пользователя снимается 5-6 долларов (Вирус Redbrowser).
Что делать, если вы подозреваете заражение вашего телефона вирусом?
Если Вы подозреваете, что у Вас вирус, проверьте следующее:
 Узнайте, откуда получен вирус:
o через Bluetooth;
o через ММS;
o загружен из Интернета.
 Проверьте список задач, и закройте все неизвестные.
 Проверьте, есть ли на экране значок Bluetooth.
 Проверьте, получают ли другие телефоны, находящиеся рядом, от вас запросы связи по Bluetooth.
 Уточните, есть ли в вашей телефонной книге люди, которые получали от вас ММS-сообщения с приложенными .sis-файлами.
 Проверьте, работает ли меню телефона.
 Проверьте, не отображается ли что-то необычное на экране.
 Проверьте, работает ли менеджер приложений.
 Установите Мобильный Антивирус, обновите вирусные базы, и сделайте полное сканирование системы.
 И пожалуй самое эффективное – это полная перезагрузка устройства с восстановлением заводских настроек!
Что делать?
В борьбе с мобильными вирусами существует два подхода. Во-первых, антивирус необходимо устанавливать на оборудование оператора связи, а во-вторых, на телефон пользователя.
Но что же делать пользователю? Попробуем дать несколько советов:
1. Устанавливать специализированное антивирусное ПО.
2. Если вы в данный момент не нуждаетесь во включенном Bluetooth – отключите его!
3. Если вы все же используете Bluetooth (например, Bluetooth-гарнитуру), включите на вашем телефоне так называемый «режим невидимости». Это затруднит работу взломщика, хотя полной гарантии безопасности вам не даст.
4. Не принимайте сообщения через Bluetooth, если вы его не заказывали. Т.е. НИКОГДА не принимайте сообщения с незнакомых номеров.
5. Не принимайте SMS и MMS, отправленные с незнакомых номеров.
6. Выключайте Wi-Fi, если вы его не используете.
7. При использовании Wi-Fi не забудьте о необходимости использования межсетевого экрана.
8. Не загружайте ПО из сомнительных источников.
9. Не используйте взломанное ПО, ведь стоимость лицензии намного ниже, чем стоимость возможного ремонта телефона.
10. Не забывайте о необходимости шифровать ваши данные.
11. И вообще, будьте внимательнее!
Но если все так грустно, почему мы не наблюдаем вирусных эпидемий? Причина в том, что смартфоны пока еще не настолько широко распространены. Но это, увы, только вопрос времени.
Беспроводные сети
Вот уж точно пример того, что технологии идут куда быстрее, чем успевают пользователи. На сегодня полно примеров создания полностью открытых беспроводных сетей. Приведу пример. Пока я иду на остановку общественного транспорта, я успеваю засечь как минимум 5-6 точек доступа. Из них только одно соединение использует WPA2, остальные беззащитны полностью. И это не потому что технологии сделаны плохо, а потому что пользователи не принимают элементарных мер защиты! Подчеркиваю, своей защиты!
Вот пример вопиющей безалаберности пользователей. Стоит проехать в метро 4-5 остановок, как в вагоне можно увидеть штук 20 включенных Bluetooth устройств. Причем их хозяевам не приходит в голову, что эти устройства можно элементарно просто поставить в режим невидимости. Но самое интересное не в этом. Однажды мой сын попытался разослать найденным Bluetooth картинку с изображением ослика и надписью «Кто прочел, тот осел!» Так что вы думаете? 6 человек ее приняли! Это что? Элементарнейшее головотяпство или нежелание думать о своей безопасности? А ведь, наверное, неоднократно и читали и слышали об опасности подобных действий. Но, тем не менее, это их не останавливает, верно?
Технология «вычисления в облаке»
Так как данная технология, вернее идея ее создания, лишь недавно заявлена Микрософт, то вначале посвятим несколько слов тому, что это за технология.
На состоявшейся в Лос-Анжелесе конференцииProfessional Developers Conference 2008, корпорация Microsoft официально объявила о выпуске новой операционной системы Windows Azure, являющуюся платформой для создания распределенных (облачных) веб-приложений и известную ранее под названием Windows Cloud. Новая платформа будет работать на группе серверов, доступ к которым осуществляется через интернет.
Microsoft начнет предоставление услуг по хостингу распределенных проектов, работающих на базе Windows Azure, предлагая дисковое пространство и вычислительные мощности своих серверов, а также новую систему в качестве услуги по подписке. «Управляя своими веб-проектами
и серверами с большим траффиком, Microsoft получила огромный опыт в подобного рода системах», – сказал Рэй Оззи, исполнительный директор корпорации Microsoft
В корпорации описывают Windows Azure как платформу, объединяющую окружение Windows, вычислительные возможности кластеров, практически неограниченные возможности по хранению и обработке данных. Рэй Оззи так же отметил, что на Windows Azure можно создавать как традиционные веб-приложения, так и решения для мобильных пользователей.
В платформу Azure Services Platform, которую Microsoft предложит в ближайшее время своим клиентам, входят пять основных подсистем: сама ОС Windows Azure, управляющая дисковым пространством, приложениями и сетями, Microsoft SQL Services для хранения данных и их обработки, Microsoft .NET Services, контролирующие работу приложений и поддерживающие расширения .NET, Live Services для синхронизации, обмена и хранения различных документов, фото и видео. Отдельно для бизнес-пользователей Microsoft поставит доступ к сервисам Microsoft SharePoint Services и Microsoft Dynamics CRM Services, предназначенных для совместной работы над проектами и управления взаимоотношениями с клиентами.
Ну вот, распределенные вычисления-то тут при чем, спросите вы. Да ведь дело-то в том, откуда, с какого компьютера, вы будете выходить в «облако»!
При использовании Windows Azure на самом деле резко увеличится опасность взлома для пользователей или организаций. Почему? Вовсе не потому что корпорация Microsoft чего-то не досмотрела. В первую очередь потому, что в силу основного правила безопасности, прочность всей цепи определяется самым слабым ее звеном, вся прочность безопасности подобных вычислений будет равна прочности ваших методов аутентификации. Ведь для доступа к вашим данным вы должны будете пройти процедуру аутентификации. Верно? А как сегодня обстоят дела с парольной аутентификацией? Правильно! Отвратительно! Причем это еще мягко сказано! Чаще всего пользователи или используют пароли типа «12345678» или что-то типа пользователь Ivan пароль Ivan. Попробуйте мне возразить! Обрадуйте меня! Не выйдет!
Почему? Да просто потому что сами пользователи пока еще не осознали, что в первую очередь их безопасность, финансовая и физическая, зависит, прежде всего, от них самих!
Проблема же для Microsoft может состоять в том, что хорошая идея использования распределенных вычислений может быть дискредитирована из-за халатности пользователей по отношению к своим данным. Т.е. обворованные ввиду своей беспечности пользователи будут очень громко кричать, что опять корпорация предоставила плохие услуги. Ведь мало у кого хватит мужества признаться, что он сам виноват в своих неприятностях.
Отдельно хотелось бы указать, что широкому распространению угроз будет способствовать крайне низкий уровень ИТ-знаний у пользователей.
Почему я так в этом уверен?
Просто события, которые происходят в последнее время, показали, что люди склонны к предубеждениям. Наиболее часто при этом встречается предубеждение, связанное с беспричинным оптимизмом. Именно оно заставляет нас совершать рискованные действия на дорогах и одновременно жаловаться на такое поведение со стороны других водителей. Именно поэтому мы можем игнорировать риск информационной безопасности, даже зная неутешительную статистику взломов. Именно поэтому мы всегда считаем, что нам удастся выйти сухими из воды там, где другим это не удается.
Почему так? Прежде всего, причиной тому является эволюция. Ведь животные развивались таким образом, чтобы недооценивать потери. Это происходит потому что те, кто подвергались потерям, просто не выжили, а те кто выжили, считают, что раз потерь нет, значит риск это нормально.
И это не просто потому что мы считаем что с нами ничего плохого произойти не может, а потому что думаем что положительное решение проблемы более вероятно чем отрицательное.
Все чаще и чаще злоумышленники используют не ошибки в программном обеспечении, а людскую психологию. А с другой стороны – все чаще и чаще создатели систем безопасности внушают ложное чувство безопасности, рассказывая о достоинствах своих систем и забывая указать, что сложной системе нужен грамотный пользователь и, в конце концов, защищенность системы всегда зависит от множества компонент.
Согласно данным IT Observer (http://www.ebcvg.com/articles.php?id=907) владельцы мобильных устройств значительно повышают риски утечки данных их корпоративных сетей. Например, 49% портативных устройств с модулями Bluetooth настроено таким образом, что кража информации из них, а, равно как и заражение вирусами становится делом всего нескольких минут.
Вместе с тем исполнительные лица, отвечающие за информационную безопасность корпораций, зачастую не представляют уровень угроз, исходящих от мобильных устройств, а те, кто осознают их уровень, не могут противостоять данным угрозам.
Приведем несколько цифр:
87% компаний на сегодня не в состоянии предотвратить неавторизованное подключение мобильных накопителей к корпоративной сети, при этом 51% респондентов осознает какому риску подвергается. 36% компаний считают, что портативные мультимедиа устройства вообще не представляют опасности. *1+.
Если же говорить о необходимости шифрования мобильных устройств, то здесь пользователи проявляют вопиющую халатность!
Не так давно в моей практике был следующий случай. Стоя у кассы в супермаркете я увидел под ногами валяющуюся флешку. Естественно подобрал ее, а дома, после проверки антивирусом нашел на ней 2(!) бизнес плана различных компаний. Интересно, пользователь, записавший их на этот носитель, задумывался о том, что флешку так элементарно потерять?
А вот еще более вопиющие примеры.
Внештатный сотрудник министерства внутренних дел Великобритании потерял карту памяти с личными данными более чем сотни тысяч преступников, в том числе и отбывающих тюремный срок.
Об этом говорится в сообщении ведомства.
На носителе хранились имена, адреса и, в некоторых случаях, детали обвинений 84 тысяч заключенных, содержащихся в тюрьмах Соединенного Королевства.
Также на карте памяти находятся адреса 30 тысяч человек с количеством судимостей от шести и выше.
Как уточнили в министерстве, информация с карты памяти использовалась исследователем из компании РА Consulting.
«Нам стало известно о нарушении правил безопасности, повлекшем за собой потерю сотрудником, находящемся на договоре, личной информации о нарушителях закона из Англии и Уэльса. Сейчас проводится тщательное расследование», – сказал представитель МВД.
С комментарием по этому поводу уже успел выступить министр внутренних дел «теневого» правительства Доминик Грив. Он отметил, что британские налогоплательщики будут «в совершенном шоке» от того, как британское правительство относится к секретной информации.
Это далеко не первый в Великобритании случай потери конфиденциальной информации различными организациями и ведомствами, напомнил Грив.
В апреле крупный британский банк HSBC признался в потере диска, на котором хранились личные данные 370 тысяч его клиентов. В середине февраля стало известно о краже из британской больницы Russels Hall Hospital в городе Дадли (графство Уэст-Мидландс) ноутбука с медицинскими данными 5 тысяч 123 пациентов.
В конце января появилось сообщение, что у британской сети супермаркетов Marks and Spencer украден ноутбук с личными данными 26 тысяч сотрудников.
Глава Минобороны Великобритании Дес Браун 21 января объявил, что у ведомства были украдены три ноутбука с личными данными тысяч человек.
В декабре прошлого года стало известно о том, что частная американская компания потеряла сведения о трех миллионах кандидатов на получение британских водительских прав. Они содержались на жестком диске компьютера. Среди утраченных данных – сведения об именах, адресах и телефонных номерах претендентов на получение водительских прав в период с сентября 2004 по апрель 2007 года.
В конце октября 2007 года два диска, на которых содержалась информация о 25 миллионах получателей детских пособий и их банковских счетах, пропали по дороге между двумя государственными учреждениями. Масштабная операция по поиску дисков, которая обошлась налогоплательщикам в 500 тысяч фунтов, не дала результатов. Также в июне нынешнего года в одном из поездов, следовавших в Лондон, был обнаружен пакет с секретными документами (http://korrespondent.net/world/493585), в которых содержится информация о борьбе с финансированием террористов, контрабандой наркотиков и отмыванием денег.
Ранее пакет с секретными документами, которые касаются последней информации о террористической сети Аль-Каида, был обнаружен (http://korrespondent.net/world/490374) на сиденье поезда в Лондоне.
Спрашивается, чем думали пользователи, допустившие это?
А вот еще один факт, который должен заставить задуматься владельцев мобильных устройств Согласно отчета Ponemon Institute (http://computerworld.com/action/inform.do?command=search&searchTerms=The+Ponemon+Institute) ежегодно в больших и средних аэропортах США теряется около 637 000 ноутбуков Согласно обзора, ноутбуки, как правило, теряются в контрольных точках безопасности. Около 10 278 ноутбуков теряются еженедельно в 36 больших американских аэропортах, и 65 % из них не возвращаются владельцам. В аэропортах среднего размера регистрируется потеря около 2 000 ноутбуков в аэропортах среднего размера, и 69 % не из них не возвращены. Институт провел опросы в 106 аэропортах 46 государств и опросил 864 человека. Наиболее часто ноутбуки теряют в следующих пяти аэропортах: · Los Angeles International · Miami International · John F. Kennedy International · Chicago O’Hare · Newark Liberty International. Путешественники не уверены что они возвратят потерянные ноутбуки. Приблизительно 77 % опрошенных рассказали, что у них нет никакой надежды на возвращение потерянного ноутбука,, 16 % говорят, что они ничего не делали бы, если бы потеряли свой ноутбук. Приблизительно 53 % сказали, что ноутбуки содержат конфиденциальную информацию компании, а 65 %, не сделали ничего для защиты информации. (http://computerworld.com/action/article.do?command=viewArticleBasic&taxonomyId=17&articleId=9105198&intsrc=hm_topic) Вывод, который нужно сделать! Ваши ноутбуки обязательно должны поддерживать функцию шифрования конфиденциальных данных. Это может быть использование Windows Vista BitLocker или SecretDisk NG от Aladdin или что-то другое. Но использовать ОБЯЗАТЕЛЬНО! И обязательно предусматривать двухфакторную аутентификацию при работе с шифрованными дисками!
Но вот сумеют ли придерживаться этого вывода пользователи или нет – покажет время. Пока оно показывает только разгильдяйство пользователей.
Вывод
Уважаемые господа руководители предприятий! Уважаемые господа пользователи! Помните что никто и никогда не сможет обеспечить ваше безопасность, если вы сами не будете за ней следить! Ваше спасение только в ваших руках! Как бы ни были совершенны технологии, но до тех пор пока пользователи только просто нажимают на клавиши и представляют из себя (простите за грубость)
– прокладку между стулом и клавиатурой – никто им не сможет помочь! Спасение утопающих – дело самих утопающих!

©  Безмалый В.Ф.
MVP Consumer Security