itsm 2010 light

2010 АЛЬМАНАХ

itSMF РоссияИзбранные статьи

Ал

ьм

ан

ах I

TS

M 2

010

альманах ITSM 2010

Дорогие коллеги!

Я с радостью и гордостью держу в руках первый номер «Альманаха itSMF Россия» сбор-ника лучших статей по тематике управления услугами в ИТ, написанных российскими авторами. Это первая попытка itSMF Россия собрать вместе опыт российских професси-оналов, накопленный за несколько лет. Некоторые из статей уже печатались в различных тематических изданиях, некоторые были написаны для сайта itsmforum.ru, некоторые — специально для альманаха. Но каждая из них прошла серьезный отбор среди множества работ, присланных на конкурс. Экспертная группа форума в течение двух месяцев рабо-тала над содержанием альманаха. Работа проделана большая. Спасибо всем, кто принял в ней участие! Имена тех, кто трудился над созданием этого альманаха — на следующей странице. Велико и значе-ние этой работы. Опыт людей, накопленный в результате выполнения проектов в различ-ных компаниях, относящихся к нескольким отраслям, будет, несомненно, полезен для тех, кто внедряет ITSM-проекты в своих компаниях, кто заинтересован в том, чтобы ожи-дания от этих проектов были оправданы, и для тех, кто только стоит перед выбором: при-менять подход ITSM или нет. Популяризация в России сервисного подхода в управлении ИТ — задача форума, и альманах, как нельзя лучше, служит достижению этой цели.«Альманах itSMF Россия» — это наш новый проект, но далеко не единственный. ISO 20000 на русском языке — это реальность! Полным ходом идет последовательный перевод серии книг ITIL v3. Совсем скоро вы сможете приобрести их и использовать знания, накопленные мировым ITSM-сообществом, для самосовершенствования и улучшения методов работы в своих компаниях.Сайт itsmforum.ru — еще один проект, над которым мы сейчас работаем. Пришло время сделать его более функциональным, емким и полезным для его посети-телей — для вас. Появятся новые разделы: ITSM-фриланс, ITSM-обучение, шаблоны доку-ментов в электронном виде и пр. Мы будем счастливы, если среди вас, читателей аль-манаха, найдутся люди, которые захотят принять участие в этом, очень нужном для всех нас, деле. На протяжении всех пяти лет своего существования российский сайт работал благодаря усилиям одного-единственного человека — Павла Солопова, члена управля-ющего комитета itSMF Россия, руководителя направления «Интернет-представительство». Оказывается, даже один человек может сделать очень много! Спасибо, Павел!В этом году 20 апреля в лучших традициях мирового сообщества мы проводим 1-ю Всероссийскую конференцию ИТ-сервис-менеджмента «Услуги и управление. Практические ценности». Мы уверены, что конференция, задуманная нами как главное ITSM-событие года, оправдает наши надежды, и ежегодно в Москве будут собираться не меньше ИТ-профессионалов, чем, скажем, в Англии, на родине ITIL.Семинары, ставшие уже привычными для членов форума, расширяют не только свою тематику, но и аудиторию. Благодаря помощи института МИЭМ, нашего партнера, при-нять участие в мероприятии itSMF Россия смогли коллеги из многих городов. Семинар транслировался в прямом эфире, и спикеры смогли ответить на вопросы, поступившие из Хабаровска, Магнитогорска, Киева…Новые люди приходят к нам, чтобы вместе расти профессионально и развивать в своих компаниях культуру управления ИТ-услугами. Руководители компаний понимают, что членство в форуме — верное решение. Российское сообщество прирастает регионами. Санкт-Петербург первым открывает в своем регионе отделение itSMF Россия. Какой реги-он будет следующим?Мы открыты для общения. Форум приветствует любую инициативу, направленную на популяризацию подходов ITSM в управлении ИТ. Мы ждем ваши предложения. Мы при-глашаем всех ИТ-профессионалов, кто еще не присоединился, вливаться в движение itSMF! Став частью независимого, свободного от коммерческих интересов сообщества, вы получите возможность не только расти самому, развивать свой бизнес, ориентируясь на лучший опыт коллег, но и содействовать развитию сервисного подхода в управлении ИТ в России.

Павел Растопшин,Председатель itSMF Россия

2www.itsmforum.ru

2www.itsmforum.ru

Оглавление

Рождение itSMF в России 4Константин Зимин

Часть 1. Проблемы управления ИТ

Организационная структура ИТ-подразделения и взаимодействие с бизнес-отделами 10Михаил Потоцкий, Максим Григорьев

Управление в малых ИТ-подразделениях 14Николай Крачун

Как сократить затраты на ИТ или увеличить доход от предоставления ИТ-услуг? 17Владимир Павлов

ИТ-услуги: есть ли альтернатива ITIL? 20Сергей Овчинников

Как обосновать совершенствование управления ИТ 24Роман Журавлев

Преодолеет ли ITIL пропасть в России? 27Виталий Хозяинов

ITSM в России: уроки первого десятилетия 30Михаил Потоцкий, Наталья Дубова

Часть 2. Практика ITSM

Опыт внедрения Service Desk. Взгляд ИТ-директора 36Виталий Хозяинов

Краткий анализ проектов внедрения Service Desk 40Сергей Ямов

Миф о лучшей практике. Заметки на полях ITIL v3 46Александр Жилинский

Основание. Каталог ИТ-услуг в управлении ИТ-службой 51Кирилл Скрипкин, Светлана Растопшина, Игорь Баринов

Управление жизненным циклом ИТ-услуг 60Сергей Знаменский

Управление ИТ: не пора ли подумать о деньгах? 68Олег Скрынник, Анна Бусарова

Как разработать изменения в положениях об ИТ-подразделениях при внедрении процессов ITSM? 72

Ольга Оршанская, Борис Болтовский


Особенности распределения ролей в ИТ-подразделении и разработка должностных регламентов 78

Чулпан Мифтахова

Сертификация ПО на совместимость с ITIL. Теперь официальная 82

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

Применение BPMN для моделирования процессов ITSM 85Дмитрий Исайченко

Часть 3. На границах ITSM

Опыт управления мощностьюи финансами 88Виталий Хозяинов

О роли бизнес-ролей 92Антон Саввин

Семь «секретов» успеха на пути изменений в ИТ 97Владимир Павлов

Действие, порождающее эффективность 99Антон Саввин

Жизнь после внедрения. Разработка ПО с учетом последующей эксплуатации 104Дмитрий Исайченко

Управление конфигурацией и изменениями: RUP или ITIL? 108

Дмитрий Лапыгин, Александр Новичков

COBIT и ITIL в управлении ИТ 114Николай Крачун, Виталий Фролов

Управление ИТ: нужен ли новый шаг? 118Федор Байновский, Максим Григорьев, Михаил Потоцкий

Управление ИТ-услугами в России. Исследование практики управления ИТ-услугами в российских компаниях 124

Константин Зимин

Границы применения сервиса. ITIL и ИТ-архитектуры 132Владимир Ананьин

Группа экспертов itSMF Россия, принимавшая участие в работе над альманахом:

Александра Сарычева, Владимир Павлов, Михаил Потоцкий, Сергей Ямов, Олег Скрынник, Роман Журавлев, Сергей Гузик, Павел Солопов, Татьяна Орлова, Александр Сапронов, Сергей Овчинников, Николай Крачун, Игорь Баринов.

Ответственный редактор: Елена КарабановаРедактор: Константин ЗиминДизайн и верстка: Марина ДашковаКорректор: Вера Иванова

Альманах содержит статьи, права на которые принадлежат издательским домам «Открытые системы», СК Пресс, «Журнал СИО: Руководитель Информационной Службы» и «Connect! Мир связи». Эти статьи републикуются с разрешения соответствующих издательств.

© itSMF Russia 2010Все права защищены. Ни одна часть настоящего издания ни в каких целях не может быть воспроизведена в какой бы то ни было форме и какими бы то ни было средствами, если на это нет письменного разрешения itSMF Russia.Отпечатано в типографии «ABT Group». Тираж 3000 экз. Не для коммерческого распространения.

4www.itsmforum.ru

4www.itsmforum.ru

Рождение itSMF

в России

Константин Зимин

Возникновение любой,

независимой от вендоров и

поставщиков услуг ассоциации на

ИТ-рынке — явление достаточно

неординарное. Такие ассоциации

можно пересчитать по пальцам

одной руки. Практически пять лет

назад, в 2005 году в России

возник itSMF — независимое

сообщество профессионалов

ITSM. Как и почему это

произошло, и почему сообщество

ITSM в России едино, в отличие,

скажем, от специалистов по

проектному управлению?

Эта статья написана по

результатам встречи с

основателями форума и

«активистами со стажем»,

чтобы восстановить историю

рождения и развития форума.

К сожалению, далеко не все

смогли поучаствовать на встрече,

поэтому история, рассказанная

ниже, получилась не совсем

полной, но от этого, надеюсь, не

менее интересной.


В коротких штанишках

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

ITSM в России в то время еще «ходил в корот-ких штанишках». Появившись в нашей стране в тяжелом 1998 году, идеи сервисного подхода еще только начали проникать в умы российс-ких ИТ-менеджеров. Людей, которые обладали опытом в области ITSM в России, тогда было совсем немного, а тех, кто хотел им делить-ся — еще меньше. И круглые столы IT Expert были той единственной площадкой, где шел интенсивный обмен опытом в области ITSM.

ИТ-менеджеры с удивлением узна-вали, что, оказывается, услугами в ИТ можно управлять, что можно построить работу грамотно и обоснованно, что можно опереться на опыт и не изобре-тать велосипед! Сейчас это звучит банально, но в то время для большинс-тва это было открытием. «На наши круглые столы собирались люди, которые очень живо интересовались темой, — вспоминает Михаил Потоцкий, основатель и руководитель компании IT Expert, один из инициаторов созда-ния форума, член Управляющего Комитета. — Это был действительно обмен опытом». Идея была пра вильной — она и стала колыбелью российского itSMF.

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

Честность следования концепции

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

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

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

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

«Отвязка» методологии от того или иного

продукта, понимание того, что методология

существует как реальный инструмент ме-

неджмента — это был важнейший шаг на жиз-

ненном пути ITSM в России

6www.itsmforum.ru

шесть стран объявляли, что создают локальное отделение у себя.

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

Но не стоит переоценивать значение и роль международного itSMF. «Наличие междуна-родной организации — это очень хорошо, это ускоряет движение вперед, это возможность обмена опытом о развитии ITSM в разных странах, — замечает Михаил Потоцкий. — Но основное значение форума все равно возни-кает локально. Мы можем больше или мень-ше заимствовать лучший опыт других стран.

Однако основная ценность — передача опыта и знаний, создание культуры управления ИТ — все равно рождается в каждой стране, в том числе и в России».

Зачем это нужно нам?

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

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

активистов. — Василий Аксенов, Игорь Баринов, Владимир Бахметьев, Максим Григорьев, Сергей Гузик, Роман Журавлев, Николай Крачун, Александр Левинсон, Михаил Потоцкий, Олег Скрынник, Елена Щербо и Сергей Ямов — они и стали отцами-основателями форума.

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

«В какой-то момент все поняли, что это совершенно не коммерческое предприятие, — вспоминает Михаил Потоцкий. — Тогда зачем

оно нужно нам? Этот вопрос прозвучал в одном небольшом пивном ресторан-чике, где мы собрались обсудить идею создания форума. И после него все замолчали, наверное, на полгода. А потом, в сознании тех, кто решил дви-гаться дальше, произошло переосмыс-ление такого, сильно дискредитировав-шего себя в советское время понятия, как общественная деятельность. Мы поняли, что она необходима и далеко

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

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

Что-то такое есть в идеях ITSM, что собирает

вокруг себя порядочных людей. Может быть,

это идеология партнерства и взаимной чест-

ности, на которую опираются настоящие сер-

висные отношения?


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

Цели висели в воздухе

Конечно же, первостепенной задачей родивше-гося в 2005 году российского itSMF была просве-тительская, она и прописана в уставе форума. Но, прежде чем делиться опытом, нужно решить очень важную проблему. Для того чтобы опыт можно было понять и перенять, необходима некая платформа, общее понятийное поле. Поэтому одной из важнейших задач независимой площадки стал поиск и выработка этого общего языка. И выпуск, в прошлом году, «Глоссария ITIL v3» стал итогом этой долгой работы.

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

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

Идеи ITSM собирают людей

Развитие не всегда шло гладко и строго посту-пательно. В небольшой по продолжительности истории российского itSMF был «застой» и внут-ренний кризис. У большинства организаций

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

Так было и у российского itSMF. «Года три назад у меня было ощущение, что наступило некоторое затишье в активности, — делится наблюдениями Роман Журавлев. — Никто особо не спорил, публичных мероприятий мало, выбо-ры президента вялые, и т.д. Форум начинался по инициативе небольшой группы единомыш-ленников. И был риск, что он так и останется лишь их делом». Именно тогда на русский язык была переведена книга Service Support из ITIL v2, причем без участия форума. А ведь это должно было быть одной из его основных активностей.

Как же это медленное затухание удалось преодолеть? Новой кровью! Для подобных некоммерческих общественных организа-ций, где все держится на личном интересе и инициативе, очень важны новые активисты. И они пришли! Старые инициативы нашли новых «движителей», появились новые планы. Идеи itSMF продолжают вербовать себе сторонников. «Как идея находит человека, так и человек нахо-дит определенный круг идей, — рассуждает Владимир Павлов, один из тех, кто присоеди-нился к работе позже. — Важны не только идеи сами по себе, но и уровень их организации. И организованная концепция ITSM собирает вокруг себя людей. Под этими знаменами собираются те люди, которые имеют высокий уровень зрелости. И хотя ротация людей неиз-бежна, всегда есть определенный интерес».

Еще один фактор — кризис. «Как ни пара-доксально, экономический кризис сыграл

Председатели форума в разные годы2005—2006 годы. Михаил Потоцкий, генеральный директор компа-нии IT Expert.2006—2007 годы. Алексей Лебедев, начальник отдела Внешэкономбанка.2007—2009 годы. Игорь Баринов, директор по ИТ холдинга Storm International, затем руководитель компании «Технический вектор»С 2009 года. Павел Растопшин, директор по развитию бизнеса компании Triangle Consulting.

8www.itsmforum.ru

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

Работы еще непочатый край

«Победы у форума, несомненно, есть: Глоссарий ITIL v3, работа с ВУЗами, российский itSMF признан мировым форумом, хотя мы ни разу не заплатили ему членские взносы», — улы-бается Игорь Баринов, один из инициаторов создания форума и его экс-председатель.

Но тут как никогда верно: «поражение от победы ты сам не должен отличать». Конечно, говорить о «массе» и количестве вовлеченных в работу форума специалистов, можно лишь в переносном смысле. «Работы еще непочатый край, — вздыхает Олег Скрынник, один из тех, кто создавал форум и продолжает работать в совете форума до сих пор, — Давайте вый-дем за пределы московской кольцевой дороги и спросим: что такое форум ITSM?». «Сейчас вокруг форума собралось несколько сотен спе-циалистов, — рассуждает Олег Скрынник, — но сравните это с тем, что, например, в 2005 году одно лишь отделение британского itSMF собрало на конференцию более 1000 участников. И это в такой маленькой стране, как Великобритания. А в России с ее масштабами таких специалистов должно быть существенно больше». И не в разы, а на порядок! Даже с учетом того, что Англия — это колыбель ITIL и там совсем другой ментали-тет и отношение к общественной работе.

Куда же двигаться и какие еще направления развивать? Продолжается совершенствование и обновление «Глоссария ITIL v3», выпущенного в середине прошлого года. Сейчас начинания форума вышли на новый уровень зрелости. «Конечно, нужно продолжать локализацию ори-гинальных материалов книг ITIL v3, — говорит Игорь Баринов. — Мы замахнулись на пять книг ITIL v3, и эта задача уже не кажется нам невы-полнимой. Продолжаем серию полюбившихся семинаров в ВУЗах, в разгаре подготовка годо-вой конференции, которая соберет всех экс-пертов в области ITSM в России. Мы уже гораздо более четко, чем раньше, определяем цели.

Форум учится зарабатывать деньги, которые использует для того, чтобы поддерживать ITSM-движение в России».

Но возникают и принципиально новые вопро-сы, которых раньше просто не было. «Долгие годы сообщество жило в основном просвети-тельской идеей, — делится мыслями о новых задачах Михаил Потоцкий. — Но сейчас проис-ходит переосмысление, потому что, кроме про-светительской, возникают задачи регулирующе-го характера. Например, перевод экзаменов. Кто должен это делать? Вендоры? Они не могут выполнять подобное регулирование. Мы все больше и больше ощущаем необходимость этой регулирующей роли. И, на мой взгляд, если форум не возьмет на себя новые роли, то много потеряет. Потому что просветительская роль, на сегодняшний момент — не единствен-но необходимая для дальнейшего прогресса в области ITSM. Здесь российский itSMF уже стал достоянием общества. Надо двигаться дальше. Но задача генерации нового знания, «лабора-тория идей», не должна при этом исчезнуть или забыться — это наша «национальная идея».

Свобода выбора и обязательность исполнения

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

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

Форум руководствуется принципом, неод-нократно опробованным в многочисленных зарубежных ассоциациях: абсолютная сво-бода выбора параллельно с обязатель ностью исполнения взятых на себя обязательств. Хотите участвовать в работе форума и успевае-те — отлично, участвуйте! Не хотите или не успе-ваете — значит, работу сделают и без вас. К счастью, есть кому — критическая масса воо-душевленных людей, которые хотят и могут дви-гать проекты форума, уже достигнута. «У нас в itSMF принято так: каждый делает свой вклад и при этом чувствует его и своим и общим», — подводит итог Михаил Потоцкий.

Сегодня форум действительно остается тем,

чем он был задуман изначально — лабора-

торией идей. Те, кто считает свои наработки

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

торией воспользоваться

За последние годы специалисты

по менеджменту пришли к

общему мнению, что сочетание

гибкости в работе и стабильного

качества предоставления услуг

ИТ-подразделения может

быть достигнуто применением

процессных методов организации

деятельности. Однако процессное

управление не создается

«само собой», а требует

целенаправленной напряженной

работы.

колько существует человечество, возможно, столько же сущес-твует искусство управления и организации деятельности. Много было открыто в древности, сказано военными теоретиками, но еще больше было сделано в XVIII—XX веках учеными, которые во время развития рыночной экономики разработали принци-пы организации и управления большими производственными структурами. Эти принципы опробованы на многих предприяти-ях, в научных центрах и банках, включены в учебные программы ведущих университетов. Что же может быть проще, чем постро-ить свое подразделение с учетом многолетнего апробирован-ного опыта? Но почему-то вопрос, столь хорошо исследованный всеми, продолжает вызывать такой большой интерес.

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

В качестве другой причины следует назвать высокую динами-ку рынка, существующую в мире и постепенно набирающую

C

Михаил ПотоцкийОснователь и председатель совета директоров компании IT Expert, один из признанных авторитетов в области управления ИТ в России. Профессиональную карьеру начал в компании Hewlett-Packard Россия, где руководил отделом программного обеспечения. С момента созда-ния IT Expert в 2002 году активно участвует в ITSM-проектах компании, проводит тренинги по ITIL/ITSM. Обладает российскими и международ-ными сертификатами по ИТ сервис-менеджменту и корпоративному управлению. Входит в инициативную группу itSMF России.

Организационнаяструктура

ИТ-подразделения и взаимодействие с бизнес-отделами

Максим ГригорьевПрофессиональный консультант в области управления информацион-ными технологиями.С 1994 по 2005 год являлся начальником системного администрирова-ния в Главном управлении Банка России по Тульской области. Проводил сервисную трансформацию ИТ-подразделения, руководил инноваци-онными проектами. С 2005 года возглавляет направление ИТ-сервисов и внешнего управления ИТ-процессами компании IT Expert. Неоднократно успешно руководил проектами по реорганизации управления ИТ, пос-троению служб поддержки пользователей, проектированию и реализа-ции сервисного подхода и сервисной модели организации.

10www.itsmforum.ru

Часть 1

10www.itsmforum.ru

Часть 1


Проблемы управления ИТ

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

История вопроса. Анализ существующего опыта

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

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

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

1 Laurie Mullins, 1993.

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

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

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

Двойное подчинение, безусловно, обеспечи-вает гибкость и перекрестное решение задач, но его не так просто реализовать. Для того чтобы эффективно работала схема двойного подчинения, должно существовать четкое взаи-модействие между руководителями, что обычно организовать нелегко. В этой связи наибольший интерес представляют принципы процессно-го управления, выдвинутые еще в середине XX века, но массовое распространение полу-чившие только последние 20—30 лет. Суть их заключается в том, что деятельность сотрудни-ков, их координацию и управление ими следу-ет организовать в виде логически объединен-ных процессов, направленных на достижение определенных целей. Для обеспечения сла-женности работы ею должен управлять руково-дитель (менеджер) процесса. Таким образом, по своей сути процессное управление является

12www.itsmforum.ru

Часть 1

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

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

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

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

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

Практика использования. Основные проблемы

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

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

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

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

Рис. Пример организации деятельности

ИТ-подразделения на основе процессного управления.



ментальные принципы, позволяющие организо-вать эффективное процессное управление.

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

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

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

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

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

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

Заключение

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

Статья впервые опубликована в журнале «Connect! Мир связи» № 1/2002. Публикуется с разреше-ния издательства «Connect!».

14www.itsmforum.ru

Часть 1

Эта статья — попытка дать ответ на

вопрос одного «ИТ-шника»:

«Что за теория такая — ITIL — и

зачем мне, работающему с

компьютерами профессионально

уже -дцать лет, она нужна?».

Поскольку его должность —

«Начальник отдела управления

информационными системами» —

подразумевает некий элемент

менеджмента, ответить коротко:

«Это не теория, но тебе ни к чему»

не получилось.

Чем управляем?

«Персоналу шесть душ, локалка на две сотни рабочих мест плюс серверов с десяток, телефония, Интернет-канал…».

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

Руководство со своей стороны далеко не всегда понимает не только, чем заняты все эти «компьютерщики», но и что ком-пании дают сервера, Интернет, вообще все это компьютерное хозяйство, кроме, разве что, ноутбука самого директора. Из-за этого не только затруднено нормальное взаимопонимание между ИТ-менеджером и руководством компании (например, обсуждение затрат на ИТ упирается в тот же вопрос — «зачем?», а объяснение директору преимуществ клиент-серверной моде-ли — дело совершенно неблагодарное), но и фактическая польза для бизнеса от затрат и усилий ИТ-подразделения неиз-меряема, неуправляема и, как следствие, низка.

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

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

Николай КрачунДиректор по информационным технологиям компании «ЛЕНТА». Начал заниматься информационными технологиями в агентстве недвижимости «Невский простор» на должности специалиста по

ИТ. Затем работал ИТ-менеджером в российско-голландской компании «Строймода», руководителем отдела информатики

«Чупа-Чупс Рус». С 2004 по 2007 являлся ИТ-менеджером центра разработки Motorola. Затем был директором по ИТ в сети мага-

зинов «СантаХаус». Один из учредителей itSMF Russia.

Управлениев малых

ИТ-подразделениях

14www.itsmforum.ru

Часть 1

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

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

Нужна ли теория?

«Управление услугами — звучит заумно и тео-ретично. Для книжек по менеджменту оно, наверное, хорошо, только переходить от всем понятого администрирования локальной сети к какой-нибудь “услуге сетевого доступа” осо-бого желания нет. В разговорах с руководством можно, конечно, красивыми терминами блес-нуть, а вот в реальной работе удобство такого подхода сомнительно».

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

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

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

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

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

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



16www.itsmforum.ru

Часть 1

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

Какие цели и как измерять результат?

«Похоже, ничего оригинального в этом подходе нет. Судя по тому, что мы должны управлять предоставлением услуг, целями у нас они и будут — нормально предоставленные услуги (без перебоев и с хорошими техническими характеристиками). А уж для оценки резуль-татов параметры известны — скорость обра-ботки SQL-запроса, объем Интернет-трафика, время отклика Веб-сервера мерить умеем. Только для каждой услуги процесс строить — не слишком ли будет неказисто?»

Конечно, неказисто, а главное — не нужно. Нормально предоставляемые услуги — это наша глобальная задача. Для ее решения как минимум надо:• чинить то, что сломалось, как можно быстрее разрешать возникающие проблемы;

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

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

(например, управление ЛВС или администри-рование СУБД).

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

Но, как уже было сказано, поставить задачу мало — обязательно надо ввести четкие крите-рии оценки достижения целей. Такие индика-торы успешности работы процессов должны быть понятны для всех участников (то есть не быть чересчур технически сложными), точно соответствовать цели процесса и быть изме-ряемыми, то есть мы должны понимать, как конкретно получить числовое значение индика-тора. Термины «хорошее», «быстрый», «точная» для них недопустимы — нам нужна шкала для измерения, чтобы о любом процессе можно было сказать: «он успешен на 85%».

В каждом случае мы сможем таким обра-зом зафиксировать, к какому результату мы стремимся. Например, для управления ликви-

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

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

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

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

Удобство использования ITIL в том, что он

содержит готовый набор «подсказок», осно-

ванный на опыте управления ИТ в реальных

организациях



Вопрос сокращения ИТ-затрат

для заказчиков услуг и снижение

себестоимости услуг для

поставщиков всегда крайне

актуален. В каждой зрелой

области деятельности человека

сформированы свои эталонные

модели, которые консолидируют

все достижения по направлению.

Для ИТ-услуг такой опыт

собран в библиотеке

передового опыта ITIL.

Пример сокращения затрат на 80%!

В одной крупной торговой компании, с которой мне пришлось работать, в ходе проекта Заказчик получил неожиданный резуль-тат: он сократил ИТ-затраты на 80%! Фантастика? Как это получи-лось? ИТ-бюджет компании был более-менее стандартным: около 50% бюджета занимали услуги связи, 30% — поддержка систем, 20% — поддержка рабочих мест и «железа». Компания покупала ИТ-услуги у своей «ИТ-дочки», с одной стороны — внешней компа-нии, но с другой — полностью управляемой. Однако наш пример показателен тем, что в данном случае не имело значения, поку-паются услуги на стороне (аутсорсинг) или оказываются своим ИТ-подразделением.

Все началось с описания услуги «обеспечение работы бухгал-терской системы». Расписали, что же делается в ходе этой услуги: устанавливаются новые версии, консультируются пользователи, делаются резервные копии и т. д. и вносятся изменения в систему: отчеты, формы и т. п. Затем директор попросил расписать стои-мость по всем работам этой услуги. Выяснилось, что 90% затрат приходится именно на внесение изменений по заявкам бухгалте-рии! (Кстати, ситуация очень распространенная). Решили из этой услуги изменения выделить отдельно и отдельно оплачивать каж-дое изменение.

Как сократитьзатраты на ИТили увеличить доходот предоставления ИТ-услуг?

Владимир ПавловДиректор по корпоративным проектам компании Деснол Софт Проджект, эксперт центра исследований Итилиум. Опыт работы в ИТ — более 30 лет. Принимал участие в разработке учебных программ и тренингов. Сертифицированный специалист по управлению проек-тами (IPMA) и ITSM. Член совета форума itSMF России, возглавляет комитет по региональному развитию и обще-ственным связям.

18www.itsmforum.ru

Часть 1

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

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

Аналогично дело обстояло и с рабочими местами: в «ИТ-дочке» два специалиста зани-мались VIP-обслуживанием — обслуживанием самого директора, его замов и начальников

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

А что пользователи? Поначалу многие были крайне недовольны. Им всем была предо-ставлена возможность сходить к директору и объяснить, почему именно им требуется повышенный уровень услуг, и что это даст компании. Часть так и сделала, некоторые их них получили необходимый им уровень услуг. Другие объяснить не смогли, но большинс-тво не пошло никуда. При этом ИТ-директор чувствовал себя вполне комфортно: он не принимал таких решений, и его не коснулась волна недовольства. Хотя, до начала проекта, в компании считалось, что ИТ-подразделение работает «плохо», что можно было бы и лучше при таких затратах на ИТ.

Каталог ИТ-услуг

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

По нашей статистике, первое создание каталога услуг позволяет снизить затраты не менее, чем на 10—20%. Правда, потом возмо-жен рост стоимости, после ввода новых услуг или осознания необходимости повышения качества сервиса для отдельных направлений. Однако, опять же по статистике, каталог услуг с четкими параметрами существует не более чем в 10% организаций, как потребителей услуг, так и поставщиков. (Это связанные вещи, если бы все работали по каталогу, то процент был бы высокий как для потребителей, так и для поставщиков услуг.)

Каталоги услуг бывают с разной степе-нью детализации, разной направленности.

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

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

Проблемы создания каталога ИТ-услуг

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

Создание каталога ИТ-услуг имеет мало

смысла без Service Desk. С другой стороны,

внедрение Service Desk без каталога услуг

быстро превращает службу в огромную

«помойку инцидентов»



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

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

Что не является проблемой?

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

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

Если вы поставщик услуг?

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

Рациональное зерно здесь только одно: при одинаковой зрелости сторон проще органи-зовать работу. Работа поставщика услуг без каталога ближе к бизнесу по продаже не ИТ-услуг, а по поставке специалистов, знающих ИТ.

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

поставки усгуг (а он точно попросит), будет ли поставщик услуг готов? Четкие параметры услуг часто являются единственным способом уста-новить цивилизованные отношения с клиентом и быть уверенным, что завтра от него не откажутся.


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

По статистике, первое создание каталога ус-

луг позволяет снизить затраты не менее, чем

на 10—20%

20www.itsmforum.ru

Часть 1

Сервисный подход к организации

работы ИТ-службы и библиотека

ITIL стали стандартом «де-факто».

Но существуют и альтернативы

этому подходу. Наиболее

распространенная из них — подход

обслуживания активов. Его можно

назвать «ремонтным». Он намного

более понятен российскому

бизнесу, чем сервисный подход.

Ключевой вопрос, который влияет

на эффективность сервисного

подхода — вопрос собственности

ИТ-активов.

Два подхода к управлению ИТ

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

Логика данного подхода проста — если на предприятии есть некие ИТ-активы, обслуживать их можно точно так же, как и обычные производственные активы: проводить ремонты, уст-ранять сбои. Раз есть система (любая, технологическая или информационная) — значит, она требует обслуживания. Цель такой деятельности — обеспечить работу активов, для чего необходимо проводить регламентные работы, осмотры, устра-нять аварии. В этом случае применимы обычные процессные ремонтные стандарты, такие, как ГОСТ 18322, ГОСТ 2.601, 2.602 и другие, полностью соответствующие концепции управления качеством.

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

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

Сергей ОвчинниковЗаместитель генерального директора по стратегии и планированию

«Информационно-технологической сервисной компании» (ИТСК). В 2000-2004 годах в должности начальника службы заказчика по ИТ в «ЮКОС РМ» вел проект по внедрению процессов ITSM, участвовал в

организации ИТ-аутсорсинга. Участвовал в создании сервисного ката-лога в «Лукойл-информе», внедрении ITSM-процессов в «Норильском

никеле», разработке ITSM-методик для «Еврохима». Был директором по развитию компании «Деснол Софт» и участвовал в создании системы

«Итилиум». Член управляющего совета российского itSMF.

ИТ-услуги: есть ли

альтернатива ITIL?



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

Естественно, для организации работ тоже активно применяется единая «точка входа» — диспетчерская служба (Service Desk). Такой подход описывается в учебниках по организа-ции производства на протяжении последних пятидесяти лет. Наличие Service Desk на пред-приятии не позволяет определить, какая кон-цепция работы используется в ИТ-службе: ITIL или что-то другое.

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

Нужны ли бизнесу ИТ-услуги?

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

Бизнес хорошо понимает, что такое услуги и что такое активы. С одной сто-роны, заметный эффект для бизнеса дает именно использование систем, активов. Об этом говорится и в ITIL. С другой, ИТ-служба, пытаясь внедрять ITIL, старается сформулировать услуги, сделать каталог ИТ-услуг, и часто встречает полное непонимание со стороны бизнеса. Причина, на мой взгляд, в том, чтó бизнес понимает под ИТ-услугой?

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

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

Активы — производственные и ИТ

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

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

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

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

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

Ключевая концепция, отличающая ремонтный

подход от сервисного — это концепция услуги.

Достаточно убрать из ITIL понятие «услуги для

бизнеса», и мы начинаем использовать под-

ход, основанный на ремонтах ИТ-активов

22www.itsmforum.ru

Часть 1

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

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

ITSM и аутсорсинг

Я не зря заговорил про аутсорсинг — именно здесь запрятан основной эффект от приме-нения концепции услуг. Что такое аутсорсинг в применении к промышленным активам? И можно ли в промышленности применять

принципы управления услугами вместо ГОСТ 18322? Да, можно. Посмотрите на крупнейше-го производителя спортивной обуви, компанию Nike — она активно применяет аутсорсинг производства, у нее нет своих заводов. Nike — лидер, а значит, такой аутсорсинг реально выгоден для всех сторон. Каждый специализи-руется на своем, предоставляя максимальную свободу и ответственность за качество другой стороне. Если бы у Nike были свои активы, то ей пришлось бы брать на себя ответственность за производительность труда и за состояние акти-вов. Постепенно идеи услуг аутсорсинга про-мышленных активов проникают и в Россию.

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

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

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

Любое ИТ-подразделение в компании, владеющей ИТ-активами, как правило, вос-принимается бизнесом как персонал, обслуживающий активы, не более. Каталог ИТ-услуг? Для бизнеса все выглядит просто:

услуга одна — все должно работать. Параметры тоже простые — все сбои устранить за час. Хотите предоставлять другие услуги? Но у вас же нет свободы распоряжения ИТ-активами!

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

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

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

Переносить подходы, неплохо зарекомен-

довавшие себя в производстве, на сферу ИТ

неправильно. ИТ-активы сильно отличаются

от производственных активов, и не зря пере-

довой опыт рекомендует использовать имен-

но концепцию услуг



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

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

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

Зависимость от поставщика

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

Аутсорсинг должен быть взаимовыгодным. Уже давно используется термин «взаимозави-симость»: обе стороны зависят друг от друга. И для поставщика ИТ-услуг на собственных ИТ-активах тоже возникает большая зависимость от заказчика. Посмотрите на огромные аутсор-синговые контракты, заключаемые в развитых странах. Там поставщик услуг всегда предо-ставляет свои ИТ-активы, это дает стабильность

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

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

ITSM для малого бизнеса

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

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

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

Если мы реально начнем покупать услуги, а

не активы, то бизнесу не придется доказывать

эффективность внедрения ITSM в сравнении

с альтернативным, ремонтным подходом

24www.itsmforum.ru

Часть 1

Обдумывая возможности

применения рекомендаций ITIL,

а также других источников в

области управления ИТ, мы

обязательно сталкиваемся

с вопросом обоснования

затрат на совершенствование

управления перед заказчиками

и владельцами ИТ. Авторы

и адепты подходов, книг и

стандартов прилагают немалые

усилия к формированию списков

выгод и преимуществ для

бизнеса. Однако значительная их

часть не выглядит в достаточной

степени убедительно. Попробуем

разобраться, каких же

следует ожидать преимуществ

от совершенствования

управления ИТ.

Подход

Работы по совершенствованию системы управления ИТ, извест-ные многим как «внедрение ITIL», обычно направлены на реше-ние следующих задач:• повышение результативности деятельности ИТ подразделения;• повышение рациональности деятельности ИТ подразделения;• повышение зрелости бизнес процессов ИТ подразделения.

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

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

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

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

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

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

Роман ЖуравлёвПрофессионально занимается ITSM c 2003 года. В 2004 — 2009 годах

работал в компании IT Expert, большую часть этого времени — в роли руководителя департамента обучения. Автор ряда учебных курсов по управлению ИТ-услугами. Аккредитованный EXIN тренер (Expert Level). За время работы обучил более 2500 слушателей, в том числе более

250 — по программе IT Service Manager. В настоящее время возглав-ляет департамент обучения компании Cleverics. Член инициативной

группы по созданию форума itSMF в России.

Как обосноватьсовершенствованиеуправления ИТ



О роли ИТ

Рассмотрим три варианта той роли, которую может играть ИТ в бизнесе.

1. Информационные технологии — это основ-ная область работы компании.

2. Информационные технологии — это фактор дифференциации компании.

3. Информационные технологии — это компо-нент базовой инфраструктуры компании.

1. Если ИТ — это основной бизнес коммании, то:• зрелость, результативность и рациональ-ность ИТ-процессов определяет зрелость, рациональность и результативность органи-зации в целом;

• степень зависимости от ИТ чрезвычайно вы сока:► потребность в эффективном контроле

в области ИТ высока;► потребность в эффективном управле-

нии ИТ-рисками высока;► доля ИТ-затрат в бюджете организации

может превышать 50%.

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

• зависимость от ИТ носит стратегический характер:► изменения в бизнесе и в ИТ тесно взаи-

мосвязаны и взаимно обусловлены;► потребность в эффективном контроле

в области ИТ высока;► потребность в эффективном управле-

нии ИТ-рисками высока;

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

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

• зависимость от ИТ может быть высокой, но не является стратегической:► изменения в ИТ инициируются исключи-

тельно бизнесом, и их число минимизи-ровано;

Рис. Взаимосвязь характеристик деятельности

ИТ-подразделения.

26www.itsmforum.ru

Часть 1

► потребность в эффективном контроле в области ИТ стабильна и может быть невысока;

► потребность в эффективном управ-лении ИТ-рисками стабильна и может быть невысока;

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

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

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

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

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

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

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

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

Каждому овощу — свой фрукт

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

Организация/Область совершенствования

Результативность Рациональность Зрелость

ИТ — это бизнес Обеспечение достижения бизнес-целей всех уровней

Повышение рациональнос-ти бизнеса, обеспечение роста и развития

Снижение рисков в облас-ти результативности, обес-печение роста и развития, маркетинговые преиму-щества

ИТ — это фактор успеха Обеспечение достижения стратегических целей

Снижение затрат на разви-тие бизнеса

Снижение рисков в облас-ти результативности про-ектов и планов развития, повышение вероятности реализации стратегии

ИТ — это часть инфра-структуры

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

Оптимизация эксплуатаци-онных затрат, обеспечение возможности роста

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

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



На каком этапе находится

распространение ITIL в России?

Какие аргументы сдерживают его

распространение и какие доводы

можно привести в качестве

контраргументов? В основе

статьи лежат положения книги

ITIL v3 — Service Strategy и работы

Джеффри Мура «Crossing the

Chasm» и «Inside the Tornado».

В

Преодолеет ли ITIL пропасть в России?

Виталий ХозяиновНезависимый эксперт по информационным тех-нологиям, сертифицированный сервис-менеджер. Профессионально занимается ИТ с 1996 г. За более чем 11 лет работы в международной косметической компа-нии «Мэри Кэй» создал развитую службу ИТ для восточ-ноевропейских офисов организации, а также портал, через который осуществляется более 50% продаж ком-пании в странах Восточной Европы. В 2008-2009 гг. рабо-тал в компании «Видео Интернешнл». С 2009 г. — незави-симый эксперт по ИТ.С ним можно связаться по адресу: [email protected].

27

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

• На изучение лучших практик нет времени, потому что люди работают.

• Зачем повышать производительность, если работодатель за это не повысит оплату и даже не похвалит?

• Высшему руководству (владельцам) неинтересно повышение управляемости/прозрачности бизнеса.

• Следование ITIL требует значительных финансовых вложений, но не гарантирует отдачу.

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

• «Жить по уставам тяжело суставам» — эмоциональное выра-жение неприятия регламентации на рабочем месте.

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

Думаю, каждый из читателей может дополнить этот список.

Рассмотрим приведенные выше аргументы с точки зрения положений книги Service Strategy. Версия 3 ITIL впервые вносит в набор лучших практик понятия о рынке и рассматривает службу ИТ в рыночной среде. ITIL учит, что выживание органи-зации зависит от ее способности быть ценной (create value) и для себя, и для своих клиентов. Такой подход является важ-ным эволюционным шагом по сравнению с версией 2, ори-ентировавшей службу ИТ на оказание услуг согласованного качества по согласованной цене, оставляя вопрос о целесо-образности цены на усмотрение заказчика. Версия 3, по сути, призывает руководителей ИТ мыслить как предпринимателей. Предпринимательское же мышление, в свою очередь, требует

28www.itsmforum.ru

Часть 1

применения гораздо более разнообразного инструментария, чем предоставляет нам ITIL.

Жизненный цикл высокотехнологичного продукта

Основой всякого бизнеса являются продажи. Как сказала Мэри Кэй Эш, одна из 25 самых влиятельных женщин мира в 1985 г. и основатель-ница одной из крупнейших частных корпораций, «Ничто не произойдет, пока кто-нибудь не про-даст что-нибудь». Чтобы было что продать, необ-ходимо создать некий продукт. Первые же зада-чи, которые приходится решать при создании продукта — это определение самого продукта и способа его вывода на рынок, т. е. маркетинг. Для высокотехнологичных продуктов, с которыми и работают службы ИТ, признанным авторите-том в области маркетинга является Джеффри Мур (Geoffrey A. Moore). Для дальнейших рас-суждений воспользуемся понятиями, детально рассмотренными в его книгах «Crossing the Chasm» и «Inside the Tornado».

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

Продукт преодолевает пропасть путем захвата отдельных ниш на рынке. После захвата

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

С различными этапами жизненного цикла связаны и различные рекомендации по постро-ению отношений с клиентами. На этапе работы с новаторами и ранними последователями о клиентах рекомендуется заботиться, так как без этого невозможно «доведение до ума» продукта и захват рыночных ниш. На следующем затем этапе взрывного роста (Tornado) нужды клиентов рекомендуется игнорировать, так как они все равно готовы купить лидирующий на рынке про-дукт, чтобы не оказаться отстающими. При этом идет борьба за долю рынка, а не за относитель-ную величину маржи со сделки. Затем следует этап Главной улицы (Main street), характери-зующийся потребностью в придании продукту дополнительных отличий от продуктовконкурентов и оптимизации затрат. Выполнение таких требо-ваний невозможно без внимания к клиентам.

ITIL в России

На каком этапе жизненного цикла находит-ся ITIL на таких развивающихся рынках, как российский и рынки стран СНГ? В докладе Татьяны Орловой на конференции по вопро-сам ITSM в рамках форума «Программные миры HP 2009», было очень верно отмече-но — пока спрос на применение ITIL сводится к внедрению функции Service Desk и процесса управления инцидентами. В качестве крите-рия профессиональной компетентности для руководителя службы ИТ в Великобритании или США знание ITIL упоминается примерно в 80% объявлений о найме, в России — менее чем в 20%. Периода взрывного спроса на связанные с ITIL услуги российский рынок не переживал. На основании этих сведений можно сделать вывод, что собственное ITIL как продукт в России находится на этапе ранних последо-вателей, делая первые шаги в отдельные ниши рынка, где начало формироваться осознание преимуществ эффективного управления.

Рис. Жизненный цикл высокотехнологичного продукта



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

Контраргументы в пользу ITIL

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

руются противники ITIL, приводя список своих аргументов). Однако ко всем аргументам наших оппонентов можно привести контраргу-менты (см. таблицу).

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

Аргумент против ITIL Контраргумент в пользу ITILВсе и так работает, зачем добав-лять сложности и увеличивать административные затраты на совершенствование процессов?

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

На изучение лучших практик нет времени, потому что люди рабо-тают.

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

Зачем повышать производитель-ность, если работодатель за это не повысит оплату и даже не пох-валит?

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

Высшему руководству (владель-цам) не интересно повышение управляемости/прозрачности бизнеса.

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

Следование ITIL требует значи-тельных финансовых вложений, но не гарантирует отдачу.

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

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

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

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

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

Таблица. «За» и «против» ITIL.

30www.itsmforum.ru

Часть 1

Последние десятилетия характеризуются кардинальным изменением

роли ИТ для бизнеса, национальной экономики и внешней среды в целом.

Из поставщика простых систем, решающих отдельные задачи расчета

зарплаты и предоставления отчетности, современные ИТ превращаются

в мощный и одновременно сложный инструмент обеспечения деятельности

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

все большее число отраслей уже просто не в состоянии нормально

функционировать. Это и послужило стимулом к быстрому становлению

принципов организации и управления ИТ, направленных на то, чтобы

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

впервые сформулированные в ITIL более двух десятилетий назад,

сегодня развиваются и дополняются другими важными областями

знаний, позволяя от простых процессов и регламентов переходить

к комплексному реформированию ИТ-организаций.

Михаил Потоцкий Основатель и председатель совета директоров компании IT Expert, один из признанных авторитетов в области управления ИТ в России. Профессиональную карьеру начал в компании Hewlett Packard Россия, где руководил отделом программного обеспечения. С момента создания IT Expert в 2002 году активно участвует в ITSM-проектах компании, проводит тренинги по ITIL/ITSM. Обладает российскими и международными сер-тификатами по ИТ сервис-менеджменту и корпоративному управлению. Входит в инициативную группу itSMF России.

Наталья ДубоваРаботает в журнале «Открытые системы» с момента его основания в 1993 году, сотрудничает с еженедельником ComputerWorld Россия также с начала его выхода в 1995 году. Являясь научным редактором журнала, публикует обзоры технологий инфраструктурного ПО, управления ИТ, ста-тьи по тематике программной инженерии, проблемам ИТ-образования, российской компьютерной истории. Является автором одной из первых публикаций в России на тему ITSM и уже в течение десяти лет занимается проблематикой управления ИТ-сервисами.

30www.itsmforum.ru

Часть 1

ITSM в России: уроки первого

десятилетия

стория реализации в ИТ идей и методов управления ИТ-сервисами (IT Service Management) насчиты-вает уже более 20 лет. В конце 80-х годов под эгидой правительства

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

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

В 1998 году отдельные отечественные пред-приятия (такие, как, например, тульское Главное управление ЦБ РФ) начали целенап-равленно изучать ITIL. В это же время компания HP начинает продвигать на рынок свою мето-дологию управления ИТ-сервисами на базе ITIL и ее реализацию в программных продуктах, которая стала возможна благодаря приобретению ведущего на тот момент разработчика cредств автоматизации служб технической поддержки и дру-гих процессов ITIL/ITSM, голландской компании Prolin. Для популяризации идей ITSM HP организовала бесплат-ные семинары. К концу года в стране, пережившей августовский дефолт, потребность в подобном обучении еще более возросла, поскольку отрез-вленные глубоким экономическим кризисом предприятия готовы были решиться на покупку новых программных решений, только получив понимание, для чего они нужны. Так именно 1998 год стал отправной точкой в развитии оте-чественного бизнеса ITSM.

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

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

Подводные камни ITSM

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

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

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

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

И



Первый подводный камень внедрения ITSM —

неумение найти ответ на вопрос «зачем

это нужно», то есть правильно определить

цели перехода к ITSM для всех участников

этого процесса

32www.itsmforum.ru

Часть 1

мационных и технических ресурсов или реали-зация управления операционными рисками.

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

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

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

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

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

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

А судьи кто?

Несмотря на десятилетний опыт, рос-сийская ИТ-индустрия до сих пор не имеет четких критериев реализации

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

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

Вторым «подводным камнем» внедрения ITSM

является формальность реализации — непо-

нимание ИТ-менеджерами того, что переход

к принципам ITSM означает серьезную орга-

низационную перестройку ИТ-департамента



свидетельством правильной реализации про-цессов у компании-поставщика ИТ-сервисов. ISO 20000 разработан на основе стандарта Британского института стандартизации (British Standard Institute, BSI), который теперь занима-ется процедурами сертификации по ISO 20000, в том числе и на российском рынке.

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

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

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

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

своей ИТ-инфраструктуры. В результате круг завоевавших доверие поставщиков услуг аут-сорсинга остается крайне узким.

Аудит нового типа

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

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

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

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

Несмотря на десятилетний опыт, российская

ИТ-индустрия до сих пор не имеет четких кри-

териев реализации ITSM

34www.itsmforum.ru

Часть 1

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

На пути к комплексной системе управления ИТ

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

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

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

2. Стремление предприятий следовать обще-мировым экономическим тенденциям рест-руктуризации деятельности и, в частности,

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

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

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

ной структурированной системы управления ИТ-деятельностью.

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

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

Зрелость процессов — важный,

но скорее внутренний инструмент анализа

ИТ-деятельности, который мало что говорит

бизнес-руководителям.



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

От управления сервисами к стратегическому управлению ИТ

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

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

* Руководство ИТ (IT Governance) — часть общекорпора-тивного руководства компанией (Corporate Governance), определяющая постановку ИТ-целей. В отличие от руко-водства ИТ, управление ИТ (IT Management) обеспечивает достижение уже поставленных ИТ-целей.

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

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

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

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

Статья Михаила Потоцкого и Натальи Дубовой «ITSM в России: уроки первого десятилетия» была впервые опубликована в журнале «Открытые системы» № 6/2008. Републикуется с разрешения издательства «Открытые системы» (www.osp.ru). Все права сохранены.

Если проблемы организации ИТ-процес-

сов обсуждаются широко и разносторонне,

то на новые задачи культурной перестройки

ИТ-организации российское профессиональ-

ное сообщество только начинает обращать

внимание

Статья является обобщением опыта

автора по внедрению функции

Service Desk в двух организациях.

В обоих случаях внедрение

проводилось с опорой на

ITIL v.2. Хотя ситуация в компаниях

была различной и проблемы, с

которыми пришлось столкнуться

по ходу проекта — тоже, тем не

менее, возможны определенные

обобщения.

Виталий ХозяиновНезависимый эксперт по информационным технологиям, сертифицированный сервис-менеджер. Профессионально занимается

ИТ с 1996 г. За более чем 11 лет работы в международной косметической компании «Мэри Кэй» создал развитую службу ИТ для восточноевропейских офисов организации, а также портал, через который осуществля-ется более 50% продаж компании в странах Восточной Европы. В 2008—2009 гг. работал в компании «Видео Интернешнл». С 2009 г. —

независимый эксперт по ИТ. С ним можно связаться по адресу:

[email protected].

36www.itsmforum.ru

Часть 2

Опыт внедрения Service Desk.

Взгляд ИТ-директора


Практика ITSM

ервый проект внедрения функции Service Desk проводился в между-народной компании (в пределах региона EMEA) в 2006—2007 годах. Компания находилась на 2—3 уровне

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

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

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

Проблемы заинтересованности и мотивации

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

Для преодоления возникших разно гласий был предпринят ряд шагов. Во-первых, авто-

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

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

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

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

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

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

П

Идея Service Desk как единой точки контакта

для всех обращений за обслуживанием долж-

на укладываться в культуру организации.

Появление обходных каналов подрывает

саму идею унифицированной процедуры об-

служивания

38www.itsmforum.ru

Часть 2

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

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

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

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

поддержки в обособленный отдел с заинтере-сованным в тематике руководителем.

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

Проблема языка

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

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

Проблемы на этапе запуска

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

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

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

Для 2-го уровня были характерны неразвернутые ответы, недоступные пониманию менее квалифицированных сотрудников. Для 3-го уровня, представ-ленного внутренними разработчиками ПО и сотрудниками головного офиса,

было характерно непонимание приоритетнос-ти инцидентов, несмотря на наличие сведений о приоритете в «тикетах».

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

Выбор средства автоматизации

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

Крайне желательно, чтобы для сотрудников

Service Desk применялись системы мотива-

ции, связывающие их личные показатели

с вознаграждением по итогам работы

за месяц



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

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

Итоги

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

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

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

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

2. Необходимо корректное, реально и адек-ватно учитывающее потребности всех заин-тересованных сторон техническое задание.

3. Корректный выбор инструмента — ПО соот-ветствующего требованиям ТЗ. Делать выбор в пользу менее функционального инструмен-та, соблазняясь его меньшей ценой, означа-ет перенести затраты с оплаты лицензии на оплату доработки или повышение стоимости обработки инцидентов.

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

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

40www.itsmforum.ru

Часть 2

Проведенный осенью 2008 года

опрос ИТ-директоров

(организаторы — российское

отделение itSMF и журнал

Intelligent Enterprise) показал,

что две трети российских

организаций внедряют у

себя современные методы

организации ИТ-службы.

Около 70% из них начинали с

выстраивания деятельности

по поддержке пользователей

и Service Desk. За прошедшее

десятилетие накоплен богатый

опыт создания Service Desk.

Анализу этого опыта и

посвящена статья.

ермин Service Desk начал приживаться в стране ориентировочно в 2000—2001 году, вместе с началом популяризацией сервис-ного подхода к организации ИТ-служб, информацией о книгах ITIL [1,2] и первыми успешными проектами в организациях с легкоузнаваемыми именами. Начиная с 2003—2004 года, про-екты по созданию Service Desk начинают приобретать массовый характер. На сегодняшний день проекты по созданию Service Desk в целом уже перешли в класс типовых, в России накоплен богатый опыт их выполнения, а сама служба Service Desk уже прочно вошла в «малый джентльменский набор» стандартных организационных решений большинства директоров по ИТ круп-ных российских предприятий. В связи с этим вопрос «Надо ли строить Service Desk?» постепенно трансформируется в вопрос «А почему он еще не построен?».

Построение Service Desk — типовая постановка задачи

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

• внедрение сопутствующих процессов (процедур, регламен-тов) горизонтального взаимодействия с другими ИТ-подразде-лениями в части, как минимум, обработки заявок, полученных от пользователей, устранения инцидентов. Эти процессы существенно зависят от Service Desk и, наоборот, без фор-мализации которых Service Desk не может успешно функци-онировать. Книги ITIL и стандарт ISO 20000 [3] весьма детально описывают рекомендации к их построению;

• пересмотр и формализацию правил взаимодействия пользо-вателей с ИТ-службой;

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

Сергей ЯмовДиректор департамента систем управления ИТ компании «Ай Эс Джи». В ИТ индустрии более 15 лет. Участвует во внедрении сер-висного подхода с 2000 года, начиная с первых российских ITSM-проектов. Последние пять лет возглавляет коллективы консультан-тов в области управления ИТ (IT Expert, ISG). Один из учредителей российского отделения itSMF, регулярный докладчик по вопросам организации и совершенствования ИТ деятельности, ITIL Expert, IT Service Manager.

Краткий анализпроектов внедрения

Service Desk

Т

40www.itsmforum.ru

Часть 2



• налаживание контроля деятельности Service Desk и сопутствующих процессов.

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

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

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

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

лизация некоторых дополнительных точек контакта по специализированным вопросам (работа с ERP, телефония…).

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

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

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

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

1 Для грубого расчета нагрузки на Service Desk и требуемых ресурсов можно использовать следующие ориентиры: в среднем от пользователя поступает 1,5 заявки в месяц; оператор Service Desk, в зависимости от его обязанностей и удобства средств автоматизации, может в среднем обрабатывать 20—45 заявок в день.

Концентрация на одной-двух приоритетных

задачах из возможного длинного списка —

один из основных факторов успеха, позволя-

ющий при ограниченных ресурсах и в обозри-

мые сроки достичь ожидаемых результатов

42www.itsmforum.ru

Часть 2

Выбор средства автоматизации

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

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

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

2. Настраиваемая система или, скорее, среда разработки. Первое обещает более про-

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

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

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

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

о компонентах ИТ в CMDB (configuration management database). Автоматизация Service Desk — лишь небольшая часть их возможностей. Системы этого клас-са обладают мощными средствами интеграции, широкими возможностями по масштабированию и встроенными средствами разработки, позволяющи-ми реализовать практически любой функционал. Яркими представителями этого класса систем являются BMC

Remedy IT Service Management Suite, HP Service Manager. Стоимость лицензий систем этого класса для внедрения среднего масштаба выше 100 тыс. долларов.

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

2 Информация о средствах автоматизации Service Desk может быть почерпнута из регулярных отчетов компаний Gartner (Magic Quadrant for the IT Services Desk) и Forester (The Forrester Wave: Service Desk Management Tools); полезно изучение систем сертификации средств автома-тизации управления ИТ PinkVerify компании Pink Elephant (www.pinkelephant.com/PinkVERIFY) и ITIL Product Compliant компании OGC. При анализе материалов из этих зару-бежных источников нужно помнить о требованиях к обяза-тельной локализации продукта, а также наличия в России технических специалистов по внедрению и поддержке.

Литература

1. Service Support (из серии книг ITIL второй редакции), Stationery Office, 2000 года.

2. Service Operation (из серии книг ITIL третьей редак-ции), Stationery Office, 2007 года.

3. Серия стандартов ISO/IEC 20000 Information technology — Service management.

Построение Service Desk — это в первую оче-

редь выстраивание эффективного конвейера

по обработке обращений пользователей и

организация накопления ценной управлен-

ческой информации. Значит, вопрос автома-

тизации встает в полный рост



Эти системы, как правило, имеют ограничения в части реализации нестандартных требований, масштабирования и создания территориально распределенных конфигураций. Стоимость лицензий систем этого класса для внедрений среднего масштаба колеблется в пределах от 30 долларов до 100 тыс. доллароов. Примерами являются HP Service Desk v4.5 и v5. x (снятый с продажи, но поддерживаемый), Axios Assyst, Numara Footprints, Omnitracker ITSM Center3.

Легкие системы ориентированы в пер-вую очередь на автоматизацию Service Desk. К этому классу отнесены недорогие системы (от бесплатных, до полноценных коммер-ческих продуктов ценой от 1500 долларов до 20 тыс. долларов за внедрение среднего мас-штаба). Системы этого класса представляют собой либо хорошо продуманные системы с «жесткими» границами в части настроек (например, Numara Track-IT!), или же системы,

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

Встречаются инициативы по автоматизации Service Desk собственными разработками (от файла MS Excel, до базы на MS Access) или с использованием неспециализированных средств автоматизации (системами документооборота или средствами «учета ошибок»4, используемых разработчиками ПО). Собственные разработки могут вполне отвечать запросам небольшого ИТ-подразделения. Однако серьезные инвести-ции денег и сил для автоматизации Service Desk на базе неспециализированных средств редко оправдываются. Даже легкие системы автома-тизации Service Desk включают в себя большое количество продуманных решений и удобств, не говоря уже о специфических возможностях интеграции с системами мониторинга, инвента-ризации и т. д. Воспроизводить эти возможности в неспециализированных системах — дело небла-годарное.

Таблица. Шесть стадий типового проекта по созданию Service Desk.

Стадия Содержание работ Средняя продолжительностьПуск проекта Планирование работ, формирование проектной команды,

решение ключевых организационных вопросов, перечислен-ных в разделе «Типовая постановка задачи». Включает элемен-ты обследования, если привлекаются внешние исполнители.

1-3 недели

Проектирование Детальная проработка организационных вопросов. Может сопровождаться прототипированием для иллюстрации воз-можной автоматизации некоторых организационных реше-ний.

3-4 недели

Техническое проектирование

Проработка технических аспектов, связанных со средствами автоматизации.

2-4 недели

Построение решения

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

Продолжительность существенно зависит от класса системы авто-матизации, квалификации техни-ческих специалистов и качества проработки решения на преды-дущих стадиях. Ориентировочная длительность — 2-6 недель

Планирование запуска

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

1 неделя

Запуск Service Desk

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

Ориентировочная продолжитель-ность — 3-6 недель.

3 Кроме перечисленных автором примеров, в России доступны и другие системы для автоматизации Service Desk: IBM Tivoly, CA Unicenter, FrontRange ITSM и FrontRange HEAT, Touchpaper IT Business Management Suite, LANDesk Management Suite, Naumen Service Desk, «СофтИнтегро» «ИнфраМенеджер» и другие — Прим. ред. 4 bag tracking.

44www.itsmforum.ru

Часть 2

Подходы к внедрению Service Desk

Создание Service Desk и внедрение сопутству-ющих процессов является в первую очередь организационной задачей, и это должно быть учтено при планировании работ и привлечении внешних подрядчиков. Можно говорить о «типо-вом проекте» по созданию Service Desk (такие проекты характерны для организаций в 20—200 сотрудников ИТ с централизованным управлени-ем оперативной деятельности). Для него можно кратко описать хорошо зарекомендовавший себя подход, привнесенный в Россию еще в начале прошлого десятилетия. В соответствии с этим подходом работы разбиваются на 6 стадий, которые показаны в таблице5.

Описанный подход применим и в крупных распределенных организациях с поправкой на степень централизации работ. Централизация работ по созданию Service Desk и совершенс-твованию поддержки пользователей может при-нимать различные формы:• выпуск стандартов на организацию деятель-ности (по этому пути, например, в свое время двигалось РАО «EЭС России», выстра-ивая деятельность через стандарт предо-ставления услуг в области информационных технологий);

• создание единого Service Desk;• создание иерархических взаимодействующих

Service Desk (например, филиалы — центр) с определением границ ответственности, правил взаимодействия, и централизацией контроля эффективности служб всех уровней (например, так поступают некоторые МРК, входящих в состав ОАО «Связьинвест»).

Средняя продолжительность проектов с использованием описанного подхода состав-ляет 2,5 — 3,5 месяца. Он позволяет получить качественный скачок в работе службы ИТ, одна-ко при этом требует:

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

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

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

При таком подходе следует придерживаться установленных правил.

1. Уделить тщательное внимание проработ-ке ключевых организационных вопросов, обозначенных в разделе «Типовая постановка задачи».

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

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

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

Если в организации нет специалистов, име-

ющих необходимую подготовку, и не плани-

руется привлечение консультантов, можно

применять эволюционный метод внедрения.

Недостатки — длительный срок и растянутые

во времени многочисленные изменения.

5 Указанные стадии можно привязать к стадиям разработ-ки автоматизированных систем в соответствии с ГОСТ 34.601-90, как того требуют многие организации, придер-живающиеся государственных стандартов. Однако это не рекомендуется делать, так как при такой привязке может потеряться организационная доминанта в проводимых работах.



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

Service Desk заработал, что дальше?

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

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

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

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

Статья впервые была опубликована в журнале «Connect! Мир связи» № 1-2/2010. Публикуется с разрешения издательства «Connect!».

46www.itsmforum.ru

Часть 2

Много лет назад Фрэнсис

Бэкон разработал учение об

идолах — ложных предрассудках,

мешающих познанию. Похоже,

пора дополнить его учение

мифологией «лучших практик».

Складывается впечатление, что

даже разработчики ITIL версии 3

не избежали влияния сложившихся

в прошлом мифов. Эта статья

посвящена одному из таких

мифов — схеме приоритезации

инцидентов.

об Инглэнд (Rob Englang), широко известный как IT Skeptic, публикует шокирующие статьи. Шаг за шагом Роб играючи и остроумно доказывает, что внедрение конфигурационной базы данных в понимании ITIL версии 2 невозможно по определению и сходу приводит десяток причин отказаться от внедрения CMDB.

По мере чтения обновленной, ITIL версии 3 также возникает ряд интересных вопросов. Представители организаций с высо-ким уровнем зрелости при знакомстве с новой версией библи-отеки интересуются вопросами тактического и стратегического уровня процессов — управление жизненным циклом услуги, каталогом услуг, уровнем обслуживания, доступностью услуг. И действительно, если начинать чтение с высокоуровневых книг Service Strategy, Service Design различия в структуре процессов заметны невооруженными взглядом.

А много ли нововведений внесено в базовые операционные процессы? Ключевое новшество — разделен процесс управ-ления инцидентами. И все? Если внимательнее посмотреть на содержание операционных процессов ITIL версии 3, то часто можно увидеть применение студенческого приема copy-paste из ITIL версии 2. Я вижу этому самое простое объяснение — раз-работчики уже подвержены мифологии «лучших практик», не замечая потребностей в изменении давно устаревших концеп-ций и оправдываясь старой, как мир, отговоркой программис-тов «зачем трогать то, что и так хорошо работает».

Рекомендации ITIL

Разберем один простой пример, касающийся базового опе-рационного процесса управления — управления инцидентами. Попробуем внимательнее рассмотреть процедуру классифика-ции и назначения приоритетов. Очевидно, что ее цель — подача на вход последующих шагов наиболее достоверной и объектив-

Жилинский Александр,ИТ-консультант департамента консалтинга и интеграции компа-нии «ИНЛАЙН ГРУП». Специализируется на ИТ-консультировании (более 15 проектов), а также на проектах тиражирования для холдингов и филиальных структур. Организацией сервиса (ITSM, ITIL, CobiT) занимается с 2004 года. Участник itSMF Россия и про-екта перевода глоссария ITILv3 на русский язык под эгидой itSMF. Ведет профессиональный блог «Записки ITSM консультанта» (itsmnotes.blogspot.com).

Миф о лучшей практике.Заметки на полях ITIL v3

Р

46www.itsmforum.ru

Часть 2



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

Приоритет — первенство, первое место по времени в открытии, изобретении, форму-лировке какой-нибудь идеи; преимущест-венное право на что-нибудь.

Толковый словарь Ушакова.

С давних пор ITIL приводит пример консер-вативной схемы расстановки приоритетов:

Приоритет = Срочность x Влияние1

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

Схема расстановки приоритета инцидента в ITIL v3 осталась совершенно неизменной по сравнению с ITIL v2! А таблицу приоритезации разработчики просто скопировали и превра-тили из примера в рекомендуемую схему2.

Схема приоритезации, рекомендуемая ITIL

Участники лекций и семинаров всегда про-сят объяснить смысл этой схемы. И практически всех слушателей не удовлетворяют стандарт-ные объяснения. А внимательных же слушате-лей, уже владеющих навыками внедрения ITSM,. или менеджеров «боевых» процессов — тео-ретические объяснения не устраивают никог-да. Участники семинара всегда пытаются дополнить и доработать схему расстановки приоритетов. Каждая такая дискуссия все боль-

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

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

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

Распределяем инциденты

В рекомендуемой ITIL схеме значимость при-оритета показана двумя способами:• собственно в названии приоритета — «крити-ческий», «высокий», «средний».

• в значении планового срока устранения (target resolution time, он же крайний срок исполнения, оно же просто deadline) — 1 час, 8 часов, 24 часа.

Работу с инцидентом мы начнем с той зада-чи, которая имеет более высокий приоритет. Из двух задач с приоритетами «критический» и «средний» мы обычно выберем «критический» при прочих равных условиях. Когда же могут возникать условия «неравные»? Обратимся к числовому значению приоритета, выраженному в часах и определяющему крайний срок испол-нения. В случае, когда только началась работа над инцидентом с высоким приоритетом (выде-лен красным цветом на рис. 1), к исполнителю в рабочую группу неожиданно поступает неслож-ный инцидент с приоритетом ниже (выделен желтым цветом на рис. 1). В такой ситуации логично будет сначала разрешить «желтый» инцидент, не допустив срыва сроков по нему, а уже затем завершать «красный» инцидент.

Срочность ВлияниеВысокое Среднее Низкое

Высокая 1 2 3Средняя 2 3 4Низкая 3 4 5

Код приоритета

Описание Крайний срок исполнения

1 Критический 1 час2 Высокий 8 часов3 Средний 24 часа4 Низкий 48 часов5 Планируемый В соответствие

с планом

1 Или степень воздействия, в оригинале impact2 Сравните ITIL v2, Service Support, Annex 5B: Example of a

priority coding system и ITIL v3, Service Operation, Table 4.1 Simple Priority Coding System.

Рис. 1. Ситуация разрешения первым инцидента

с более низким приоритетом.

3 Еще одним сюрпризом для меня является отсутствие в ITIL3 процесса управления работами (Workorder Management).

48www.itsmforum.ru

Часть 2

Неравные условия могут возникать в случаях:

• отсутствия последовательного поступления инцидентов на вход процедуры;

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

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

гичная прямая рекомендация в ITIL не найдена. Правила распределения, построенные на такой практике, универсальны — они работают, когда инциденты поступают последовательно, когда инциденты поступают «вразброс» по любым причинам.

Назначаем инциденту приоритет

Пока схема работы с инцидентом, которая предлагается ITIL, выглядит достаточно неплохо, хоть с небольшими оговорками. Полнейшее разочарование наступает на следующем шаге! Мало иметь таблицу, схему приоритетов для инцидентов, нужно еще и уметь назначить конкретный приоритет для конкретного посту-пающего инцидента. Возможность назначения и изменения контрольных приоритетов собс-твенно исполнителем по инциденту приводит к краху. Мы получаем «контроль исполняюще-го» и стандартную проблему классической модели предоставления услуг, разрыв в пони-мании качества обслуживания между испол-нителем и потребителем услуги. Приоритет исполнителя не всегда совпадает с приори-тетом пользователя, и даже больше — ЧАЩЕ ВСЕГО приоритеты ИТ и пользователя услуги НЕ совпадают!

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

Задачи Service Desk:

• Обеспечить единую точку контакта для пользователей4;

• Способствовать восстановлению нор-мального уровня предоставления услуги с минимальным влиянием на бизнес в соот-ветствии с согласованным уровнем услу-ги и бизнес-приоритетами.

ITIL v2, том Service Support.

Однако обладает ли первая линия поддерж-ки необходимой квалификацией для использо-вания объективных критериев при управлении

потоком инцидентов?

В качестве инструмента для объектив-ного указания приоритета ITIL предлагает два параметра — срочность и влияние. Но каким же образом в общем случае сотрудник первой линии обычной ква-лификации может объективно точно определить срочность инцидента? Со слов пользователя? Смех, да и толь-ко. У пользователя для всех его заявок

всегда один и тот же приоритет: «жить не могу», «сверхсрочно» и «сделать вчера!». Применение опросных листов? Примеры реально рабо-тающих оперативных анкет по определению срочности мне неизвестны. Однако возьму на себя смелость предположить, что эффектив-ность и результативность анкет будет невелика. Определять срочность, пользуясь дистанцион-ным доступом, дотошно проверяя слова поль-зователя? Долго, дорого и не всегда помогает. Ведь среднестатистический Service Desk слабо разбирается в бизнес-специфике большинс-тва услуг, используемых в бизнес-приложениях; если это, конечно, не услуги вида «рабочее место», «печать» или «электронная почта». Заметим также, что в общем случае доскональ-ное знание специфики услуг не есть главная задача первой линии поддержки.

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

Хорошей стоит признать практику ориенти-

роваться при определении порядка работ

по времени, оставшемуся до крайнего срока

исполнения, однако аналогичная прямая ре-

комендация в ITIL не найдена

4 В оригинале Customer, здесь в значении получатели, поль-зователи услуг.

5 Major.



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

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

Есть серебряная пуля!

Итак, в случае применения предлагаемой ITIL схемы (Приоритет = Срочность х Влияние) мы получаем:• системную необъективность оценок приоритета;

• изначально неэффективные проце-дуры (необъективные оценки нужно как-то корректировать и оценивать успешность такой корректировки);

• для нормальной работы по рекомен-дуемой ITIL v2 и v3 схеме для приори-тезации на первой линии обязательно требуются высококлассные техничес-кие эксперты (а еще лучше — пред-сказатели будущего и телепаты в про-мышленных объемах).

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

Основная цель процесса управления инцидентами:

Максимально быстрое восстановление нормального предоставления услуги и минимизация отрицательного влиянияе на бизнес… Нормальное предоставление услуги определено в соглашении об уровне услуги (SLA) 6.

ITIL v2, том Service SupportITIL v3, том Service Operation

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

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

ренное время. Крайний срок исполнения — что это, как не приоритет?

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

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

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

6 The primary goal of the Incident Management process is to restore normal service operation as quickly as possible and minimise the adverse impact on business operations, thus ensuring that the best possible levels of service quality and availability are maintained. ‘Normal service operation’ is defined here as service operation within Service Level Agreement (SLA) limits.

7 В ITIL v3 процесс Request Fulfilment, том Service Operation.8 В ITIL v3 процесс Event Management, том Service

Operation.

В случае применения предлагаемой ITIL схе-

мы мы получаем: системную необъективность

оценок приоритета; изначально неэффек-

тивные процедуры; для нормальной работы

по рекомендуемой ITIL v2 и v3 схеме на пер-

вой линии обязательно требуются высоко-

классные технические эксперты

50www.itsmforum.ru

Часть 2

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

Подходы к приоритезации на основе услуги

Рассмотрим подробнее механизм приори-тезации на основе услуг. На данный момент в российской практике существует два подхода:• 1, схема назначения приоритета по связке

«Услуга — Тип, Категория»;• 2, прямая классификация приоритета по услугам «Услуга — Подуслуга» (с двумя и более уровнями вложенности зависит от конк-ретного каталога).

• А также комбинации первых двух под-ходов с привлечением дополнительной аналитики.

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

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

Второй подход предлагает, не меняя ключе-вой идеи, перенести аналитические признаки на следующие уровни каталога услуг. Назначая услугу инциденту из второго или третьего уровня каталога, оператор автоматически проставляет и приоритет, уже заданный для детализиро-ванной услуги. Пример такой приоритезации; услуга «ERP\ERP Logistic\Устранение сбоя»

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

Несомненно одно — концепция опреде-ления приоритета в процессе управления инцидентами, без изменений перенесенная в ITIL v3, давно устарела. Ее нужно приводить к механизму приоритезации, основанному на услуге и SLA.Рис. 2. Схема приоритезации «Услуга — Тип »

Первоисточник дает нам в руки абсолютно

четкую и недвусмысленную подсказку.

Более высокий приоритет должен отдавать-

ся тем инцидентам, воздействия на услуги ко-

торых более критичны для бизнеса и должны

быть исправлены в первую очередь



Кризис часто оказывается тяжелым временем для ИТ-службы: требования

бизнеса растут одновременно с сокращением расходов на ИТ. В этих условиях

особенно насущными оказываются три вопроса: сколько стоит ИТ и почему так

дорого? Кто потребляет ИТ и почему так много? И — last but not least1 — что нельзя

сокращать, без чего мы не сможем жить и развиваться? Ответ на эти вопросы

дает каталог ИТ-услуг. В статье подробно описывается построение каталога услуг,

моделирование затрат на ИТ-услуги и основные подходы к внедрению каталога.

1 Последнее по счету, но не по важности (англ.)

Основание.Каталог ИТ-услуг в управлении ИТ-службой

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

Светлана Растопшина Кандидат технических наук. Базовое образование: сертификация и стандартизация качества услуг. С успехом применяет его на ниве ИТ. Обладает опытом выполнения проектов в следующих областях управле-ния качеством: разработка Каталога ИТ-услуг и определение сервис-ных параметров; определение измеряемых процессных метрик ИТ и их мониторинг; подготовка и проведение аудитов ИТ-процессов на соот-ветствие CMMI; расчет стоимости ИТ-услуг и моделей аллокации затрат ИТ; разработка и согласование SLA с бизнес-заказчиками ИТ-услуг; разработка и внедрение методики для измерения уровня удовлетворен-ности пользователей ИТ-услуг; оптимизация ИТ-процессов и внедрение инструментов их автоматизации.

Игорь БариновГенеральный директор компании «Технический вектор». С 1997 по 2000 гг. работал начальником отдела информационных систем холдинга East Line Group. С 2000 по 2005 гг. руководил службой контроля качества Департамента ИТ в компании «Билайн». С командой специалистов «Билайна» сумел повысить зрелость процессов ИТ департамента до уровня 4—4,5 баллов. С 2005 г. по май 2007 г. являлся директором по ИТ холдинга Storm International. С 2002 г. — постоянный участник ITSMF International. Один из инициаторов создания российского отделения itSMF. С июня 2007 г. по май 2009 г. был председателем itSMF Россия. В настоящее время — заместитель председателя форума, руководитель Комитета по конференциям и семинарам itSMF Россия, активно зани-мается популяризацией идей сервис-менеджмента в России.

52www.itsmforum.ru

Часть 2

Зачем нужен каталог ИТ-услуг?

Еще недавно большинство экспертов в области управления ИТ-службой давали на этот вопрос четкий и недвусмысленный ответ: для заключе-ния SLA, т. е. соглашения об уровне сервиса. Оно и в самом деле немыслимо без каталога услуг, иначе непонятен предмет соглашения. Но верно ли обратное? Действительно ли ката-лог услуг — часть SLA и не более того?

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

• показатели объема и качества услуг в составе каталога и их текущие значения;

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

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

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

операционного бюджета на 30%» в разряд «снижение качества (или объема) сервиса Х позволяет сократить бюджет на Y%»2. Основная разница в том, что предприятие в целом или отдельные его подразделения так или иначе заинтересованы в этих задачах.

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

устойчивое финансирование.

Теперь второй вопрос: «Кто потребля-ет ИТ и почему так много?». Этот вопрос задается гораздо реже, нежели первый, но при его отсутствии возникает дисба-ланс между требованиями к ИТ-службе и ее ресурсами, что влечет за собой накопление рисков, описанных выше. Но если объем потребления услуги

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

Особенно важен каталог ИТ-услуг при зна-чительных изменениях объемов потребления ИТ-услуг и/или бюджета ИТ-службы. В этом слу-чае на первый план выступает модель оценки стоимости услуги при изменении требований к ее объему или качеству. Эта модель может решать и иную задачу — показывать, сколько времени ИТ-служба может проработать на сокращенном бюджете до того, как накоп-2 Авторам доводилось лично наблюдать, сколь отрезвляю-щее воздействие оказывает на желающих сократить опе-рационный ИТ-бюджет фраза «Отлично. Тогда скажите, пожалуйста, поддержку каких ИТ-услуг мы теперь можем сократить или остановить».

Каталог услуг представляет собой полное

описание «конечного продукта» ИТ-службы —

ИТ-услуг, оказываемых бизнесу, включая их

стоимость, а также модель изменения этой

стоимости



ление технических и иных рисков приведут к деградации качества услуг.

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

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

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

Что такое каталог ИТ-услуг?

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

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

54www.itsmforum.ru

Часть 2

• услуги должны быть организованы иерархи-чески;

• описание услуги должно включать в себя объем, параметры качества, сервисные пакеты;

• по каждой услуге должны быть известны заказ-чик, владелец, ключевые потребители;

• с каждой услугой могут быть связаны внутрен-ние сервисы, оказываемые подразделениями ИТ друг другу;

• наконец, каждая услуга должна иметь стои-мость и механизм корректировки последней при изменении объема и/или качества услуги.

Рассмотрим каждое требование по -дробнее.

ИТ-услуга должна быть сформулирована так, чтобы она была понятна как ИТ-службе, так и бизнесу. С точки зрения бизнеса, ин -формационная система — это ресурс, а результат использования этого ресур-са — решение тех или иных задач в интере-сах бизнеса. Именно поэтому определение услуги как «поддержка системы такой-то» совершенно не подходит для каталога ИТ-услуг. По этой же причине число услуг в каталоге не должно быть слишком большим. Если реше-ние задачи, которую бизнес воспринимает как единое целое, требует обращения к 5-6, а то и 10 услугам в каталоге ИТ-услуг, эти услуги сформулированы плохо и не пригодны для решения задач, стоящих перед каталогом. Как следствие, услуг в каталоге ИТ-услуг не должно быть слишком много — даже для круп-ной компании каталог, скорее всего, будет включать в себя порядка 100 услуг нижнего уровня. Для обеспечения понятности и прозрач-ности каталога ИТ-услуг крайне желательно согласовывать проекты каталога с заказчиками ИТ-услуг.

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

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

Если разные пользователи услуги предъявля-ют разные требования к качеству, показатель объема услуги в целом теряет смысл. В этом случае выделяются так называемые сервис-ные пакеты — варианты услуги с разными требованиями к качеству (например, обычная поддержка в режиме 8×5 и VIP-поддержка в режиме 12×7). Это дает возможность пользо-ваться показателями объема, считая его разде-льно для разных сервисных пакетов.

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

3 Для указанных услуг возможны и другие показатели объема.

4 Имеются в виду банковские и телекоммуникационные услуги соответственно.

Рис. 1. Двухуровневый каталог ИТ-услуг.



вия обслуживания и баланс затрат и резуль-татов ИТ.

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

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

Наконец, стоимость услуг — большая и важ-ная тема, которая будет рассмотрена ниже отдельно.

Ресурсно-сервисная модель

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

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

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

В экономике эта проблема решается дву-мя способами — аллокацией6 либо состав-лением так называемых ресурсно-технологи-ческих карт. Сейчас мы рассмотрим оба эти способа.

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

• приложения — любое программное обеспе-чение, непосредственно используемое для оказания ИТ-услуг, например, АСУ ТП, SAP R/3, «1С», MS Excel;

• платформы — программное обеспечение, используемое не для непосредственного оказания ИТ-услуг, а для создания приложе-ний, например, СУБД Oracle, платформа для создания портальных приложений IBM WebSphere;

• инфраструктура — оборудование и про-граммное обеспечение, обеспечивающее работу приложений и платформ, например, ОС MS Windows, ПК, сервера, коммуникаци-онное оборудование;

• среда — объекты, не относящиеся к сфере ИТ как таковой, но обеспечивающие работу ИТ-инфраструктуры, например, серверные и кроссовые помещения, кондиционеры, источ-ники бесперебойного питания.

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

6 От английского слова allocation — размещение, распре-деление

Рис. 2. Пример распределения затрат по аллокацион-

ной модели.

56www.itsmforum.ru

Часть 2

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

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

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

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

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

Таблица 1. Пример нормативов ресурсно-технологических карт на единицу услуги

Сервисный пакет

Единицаизмерения

НормативыОператор, чел.-часов

Инженер тех. поддержки,

чел.-часов

Техническаяподдержка ПО,

чел-часов

Запасныечасти, руб.

………….

Стандартное рабочее место в год

Рабочее место

1,2 6 0,5 90

Таблица 2. Расчет потребления ресурсов по нормативам

Сервисный пакет

Единицаизмерения

Числоединиц

Оператор, чел.-часов

Инженер тех. поддержки, чел.-часов

Техническая поддержка ПО,

чел-часовЗапасныечасти

Стандартное рабочее место в год

Рабочее место 80 96 480 30 7200

Рис. 3. Расширенная аллокационная модель.



нес-услуги: «при росте объема услуги на 1%, объем технического сервиса возрастает на X%». Тем самым образуется цепочка: рост объ-ема бизнес-услуги — рост объема некоторых технического сервисов — рост потребления ресурсов этими сервисами. Такой подход пред-ставляет собой разумный и максимально эко-номичный компро мисс между потреб ностями прогнозирования затрат и объемом данных, необходимых для такого прогнози рования.

Модель расчетно-технологических карт. Наиболее развитый вариант ресурсно-сервис-ной модели — модель расчетно-технологических карт. В этой модели для каждой бизнес-услуги составляется расчетно-технологическая карта, содержащая нормативы расхода ресурсов на оказание сервиса. Пример такой карты приве-ден в табл. 1 и 2. В первой из них приведены нор-мативы расхода ресурсов на единицу услуги, во второй — расчет по требления ресурсов, исходя из объема потребления.

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

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

Как внедрять каталог?

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

Основная проблема — подход «все или ничего». Этот подход в равной мере относит-ся и к каталогу ИТ-услуг в узком смысле, и к ресурсно-сервисной модели. От каталога ИТ-услуг такой подход требует совершенно точ-

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

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

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

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

7 Заметим, что на протяжении всего материала мы упот-ребляли слова «оценка затрат»

8 Естественно, при условии, что эти шаблоны у консультан-та есть

Возможны три варианта ресурсно-сервисной

модели: аллокационная модель, расширенная

аллокационная модель и модель ресурсно-

технологических карт, которая обеспечива-

ет более точный прогноз затрат, но требует

больших объемов информации

58www.itsmforum.ru

Часть 2

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

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

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

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

После утверждения проекта каталога ИТ-услуг и детальной структуры ресурсно-сервис-

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

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

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

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



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

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

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

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

• согласованием промежуточных и, тем более, конечных результатов проекта с бизнес-заказ-чиками ИТ-службы;

• участием в проекте консультанта, располага-ющего шаблонами самих каталогов ИТ-услуг и ресурсно-сервисной модели, а также про-цессов их ведения;

• правильным выбором средств автоматиза-ции;

• систематическим обучением исполнителей;• возможно более ранним привлечением сотрудников компании к ведению каталога ИТ-услуг и ресурсно-сервисной модели.

Вместо заключения: а что же дальше?

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

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

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

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

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

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

При внедрении процесса управления ката-

логом ИТ-услуг компания выбирает не между

точным и приближенным знанием сервисов, а

между приближенным знанием и отсутствием

всякого знания

60www.itsmforum.ru

Часть 2

Принцип управления жизненным

циклом ИТ-услуг является

основополагающим для

третьей редакции библиотеки

ITIL. Статья объясняет, почему

так важно уделять особое

внимание услугам, оказываемым

ИТ-службой, и почему внедрение

эффективных методов управления

жизненным циклом услуг

необходимо для эффективного

решения задач сервисного

обслуживания1. На примере

использования программного

обеспечения НР показаны

возможности, которые дает

применение принципа жизненного

цикла услуг.

Сергей ЗнаменскийТехнический консультант в департаменте прграммных решений в рос-сийском представительстве НР. Имеет десятилетний опыт поддержки продаж инструментария автоматизации компании НР для ITSM проектов. Имеет сертификат ITIL сервис-менеджера.

Управлениежизненным циклом

ИТ-услуг

Р

1 В статье использованы материалы HP WhitePaper D. Barron «Service Lifecycle Management».

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

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

Жизненный цикл услуги

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

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



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

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

Операции и процессы жизненного цикла ИТ-услуг:• построение и визуализация связей ИТ-услуг с ИТ-системами и клиентами;

• публикация описаний услуг в сервисном каталоге;

• определение поддерживаемых уровней сер-виса для каждого определения в каталоге;

• самостоятельный запрос на услуги для инди-видуальных работников и подразделений;

• выполнение заказов на услуги с учетом управ-ления изменениями и заказами;

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

• оценка и анализ эффективности оказания услуг;

• оптимизация оказания услуг и поддержки кли-ентов.

Термины и определения

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

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

2. Пользователь услуги (service subscriber). Между службами и их клиентами могут существовать устойчивые отношения. Пользователь услуги — это клиент, который подписан на использование определенной услуги. Подписчиками могут быть как отде-льные пользователи, так и целые структурные подразделения.

3 Подписка на услугу (service subscription). Используется для установления связи клиен-

тов ИТ-службы с потребляемыми услугами. Подписка может включать в себя соглашения об уровне услуг (SLA), историю, дополнитель-ные услуги и заявки на изменения, требую-щие рассмотрения.

4. Транзакционные заявки (transactional requests) и заявки на подписку (subscription requests). Одна из подгрупп услуг, предостав-ляемых ИТ-службой, — поддержка транзак-ционных заявок. Эти заявки выполняются в виде разовой поставки товара или услуги. Однако многие важные услуги, предостав-ляемые ИТ-службой, имеют некоторый срок действия. Согласно нашей терминологии, заявки на подобные услуги называются заяв-ками на подписку. Пользователями могут выступать группы людей, например, все работники отдела. Такие услуги называются совместно используемыми (shared business services). В иных случаях пользователями являются отдельные лица, и заявки для них на зываются заявками на персональные услуги (dedicated services) и могут включать в себя оборудование по индивидуальному выбору.

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

6. Сервисно-ресурсная модель. Иерар хи-ческую схему, которая представляет сущ-ность ИТ-услуг и их взаимосвязей с элемен-тами конфигурации CI, обеспечивающими ИТ-услуги, обычно называют сервисно-ресур-сной моделью. Предположим, на предпри-ятии реализована система электронной почты в виде набора систем, куда входят серверы, коммутируемые каналы, сетевые устройства, веб-серверы и базы данных. Все эти компоненты смоделированы как конфигурационные единицы (Configuration Item, CI) в базе данных управления конфи-гурациями (Configuration Management Data Base, CMDB). На верхнем уровне каждая услуга также смоделирована как элемент кон фигурации со ссылками на связанные системы и с определением компонентов в CMDB. Визуализация сервисно-ресурсной модели в виде графической схемы важна для пред-ставления информация о состоянии услуги

62www.itsmforum.ru

Часть 2

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

Каталог услуг

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

На рис. 2 в качестве примера показан спектр услуг, которые могут быть представлены в каталоге.

Для удобства применения каталог услуг иерархически структурирован в соответствии с категриями услуг. Категории услуг охватыва-ют основные сферы деятельности ИТ-службы, например:• услуги для повышения производительности труда персонала;

• бизнес-услуги;• услуги для сотрудников;• технические ИТ-услуги.

Для каждой услуги приводится подробное опи-сание и указывается следующая информация:• наименование и описание услуги;• стоимость разового и повторного использова-ния услуги;

• целевой заказчик (отдельное лицо или струк-турное подразделение);

• объект заявки с указанием сроков, необходи-мых для ее выполнения;

• соглашение об уровне услуги, отражаю-щее стандартные цели, которые определяют доступность услуги, ее поддержку и обеспе-чение.

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

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

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

Остальные заявки делаются от имени груп-пы работников. Это так называемые заявки от структурных подразделений (departmental requests), которые могут поступать от любо-

Рис.1. Отображение сервисно-ресурсной модели для

услуги «электронная почта».

Транзакционныезаявки

(Transactional Requests)

Сброс пароля

E-mail

Web Portal

Бизнес-приложениеАБВ

Перемещениерабочего места

Восстановление данныхиз резервной копии

…

…

…

Заявки на подпискуна услуги

(Subscription Requests)

Совместноиспользуемые услуги

SharedService

Персональныеуслуги

Резервное копированиеданных с ПК

Рассылка новостей

Каталог IT-услуг

Рис. 2. Пример структуры каталога ИТ-услуг.



го структурного подразделения. Конкретные пользователи, называемые заявителями от структурного подразделения (departmental requesters), получают особые права для подачи такого рода заявок.

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

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

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

Управление уровнем обслуживания

Для того чтобы гарантировать выполнение поже-ланий клиентов надлежащим образом, важно определить характеристики каждой услуги, чтобы их можно было оценить и учесть в общем плане управления уровнем услуг (Service Level Management, SLM). Главным элементом процесса управления уровнем услуг является соглашение об уровне обслуживания (Service Level Agreement, SLA), которое регламентиру-ет договорные отношения по предоставлению услуг между ИТ-службой и ее клиентами.

Целевые показатели уровня обслуживания (Service Level Target, SLT). Объекты, описанные в SLA, называются целевыми показателями уров-нями обслуживания (SLT) и охватывают разнооб-разные характеристики, в том числе:• доступность услуг;• эффективность применения;

• порядок функционирования службы работы с клиентами;

• показатели разрешения нештатных ситуаций;• планирование и проведение процесса вне-сения изменений.

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

Производительность услуг. Один из типов SLT обеспечивает контроль над производитель-ностью услуги. Пример такой записи приведен в таблице 1. Такие SLT обрабатываются в HP Service Manager путем интеграции с пакетом мониторинга бизнес сервисов HP Business Availability Center.

Таблица 1. Характеристики контроля за производительностью услуги.

Наименованиеконфигурации

Наименование параметра

Оператор Уровень сервиса

«Серебро»

Уровень сервиса «Золото»

Приложение Ответ на транзакцию

<= 2 сек 1 сек

Службы Web Время ответа <= 3 сек 1.5 сек

Таблица 2. Характеристики контроля доступности услуги.


Уровень сервиса «Серебро»


Наличие доступа к услуге

< 95% < 98%< 97% < 99%

Таблица 3. Характеристики времени реагирования на заявку.

Наименование конфигурации


Оператор Уровень сервиса

«Серебро»


Перемещение/ перебазиро-вание рабочей станции

Время перемещения

<= 3 рабочих дня

Следующий день

Запрос в служ-бу обслужива-ния клиентов

Время ответа <= 24 часа 4 часа

Рис. 3. Портал самообслуживания по выбору ИТ-услуг.

64www.itsmforum.ru

Часть 2

Доступность услуг. Второй тип SLT контроли-рует доступность услуги. Пример такой записи приведен в таблице 2. Параметры наличия и доступности услуг отслеживаются в HP Service Manager путем учета перерывов в предостав-лении услуг наряду с урегулированием особых ситуаций и управлением изменениями. Кроме того, в целях предоставления дополнительной оперативной информации о перерывах в пос-тавке услуг может применяться комбинирование нескольких инструментов контроля, в том числе пакет мониторинга НР Business Availability Center.

Время реагирования на обращение. Третий тип SLT включает в себя параметры времени реагирования на заявку. Пример такой записи приведен в таблице 3.

Соглашения об уровне обслуживания (SLA)

Обычно SLT объединяются в комплексные соглашения об уровне обслуживания (SLA). HP Service Manager поддерживает два параллель-ных подхода к определению таких соглашений. Первый — через определение SLA, ориентиро-ванных на клиента (customer centered SLAs). Соглашения, ориентированные на клиента, согласуются между ИТ-службой и ее клиен-тами и имеют несколько целевых уровней

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

Для примера рассмотрим службу почтовых ящиков в системе электронной почты с различ-ными уровнями обслуживания:• Email Gold SLA:

► SLT: доступность 99%► SLT: время ответа на вопросы, задаваемые службе поддержки клиентов — 8 часов

• Email Platinum SLA:► SLT: доступность 99.99%► SLT: время ответа на вопросы, задаваемые службе поддержки клиентов — 3 часа

Другой пример: пакет программ для сети настольных ПК. Он представлен в каталоге вместе с набором имеющихся в наличии SLA:• Desktop Gold SLA:

► SLT: время ответа на запросы о стандарт-ных изменениях — 1 неделя

► SLT: время ответа на вопросы, задаваемые службе поддержки клиентов — 8 часов

• Desktop Platinum SLA:► SLT: время ответа на запросы о стандарт-ных изменениях — 3 дня

► SLT: время ответа на вопросы, задаваемые службе поддержки клиентов — 3 часа

Описания услуг и соглашения об уровне обслуживания (SLA)

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

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

Рис. 4. Последовательность операций при обработке

двух различных типов заявок.



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

Управление выполнением запросов (заявок)

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

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

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

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

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

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

66www.itsmforum.ru

Часть 2

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

Для удобства в HP Service Manager имеются графические средства визуализации потока операций (workflow) процессов управления запросами и изменениями (рис. 5).

Самостоятельная техподдержка

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

Мониторинг ИТ-услуг

Для оптимальной поддержки услуги рекомен-дуется установить систему автоматического мониторинга, которая позволит в режиме реального времени обнаруживать проблем-ные моменты, связанные с услугами и их компонентами. Подобный контроль может быть осуществлен с помощью пакета HP Business Availability Center.

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

Рис. 6. Оформление заказов и подключение к

ИТ-услугам через каталог услуг.

Рис. 7. Последовательность событий в рамках подачи

сигналов тревоги.

Рис. 5. Средства визуализации потока операций

процессов управления запросами и изменениями.



делены на уровни, показанные в таблице 4.

Таблица 4. Уровни сигналов тревоги.

Уровень тревоги Время отклика порталаЗеленый Среднее время отклика

приложения < 1 секЖелтый Среднее время отклика

приложения < 2 секКрасный Среднее время отклика

приложения > 2 сек

Как только система мониторинга обнаружи-вает, что скорость реагирования ниже допусти-мого зеленого уровня, создается инцидент в HP Service Manager по обнаруженной неполадке. Помимо создания инцидента, мониторинг также может быть связан с особым SLA, в котором описан порядок срочности для возврата продук-тивности услуги на должный уровень. Например, в SLA для услуг веб-портала может быть установ-лено время возврата производительности ИТ-услуги с желтого на зеленый уровень — 4 часа, тогда как время возврата с красного на желтый или зеленый уровень — 30 минут.

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

Комплексное решение мониторинга ИТ-услуг на основе программных пакетов HP Service Manager и HP Business Availability Center позволяет также отображать в реаль-ном времени на информационной панели (рис. 8) оперативные интегральные показатели качества ИТ-услуги, такие, как:• cреднее время между отказами ИТ-услуги

(service Mean Time Between Failures, MTBF);• cреднее время между инцидентами по ИТ-услуге (service Mean Time Between System Incidents, MTBSI);

• cреднее время восстановления ИТ-услуги (service Mean Time to Resolution, MTTR).

Контроль и оптимизация ИТ-услуг

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

ки настраиваемые представления и отчеты (рис. 9), демонстрирующие основные пока-затели качества ИТ-услуг за отчетный период, такие, как:• статистические данные о выполнении SLA;• инциденты и изменения по данной ИТ-услуге;• показатели доступности и сбоев в работе ИТ-услуги.

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

Рис.8 Отражение оперативных интегральных показателей

качества ИТ-услуги.

Рис.9 Отчеты, показывающие основные показатели качества ИТ-услуг

за период.

Статья впервые была опубликована в журнале Rational Enterprise Management № 6/2008. Публикуется с разрешения издательства с изменениями.

68www.itsmforum.ru

Часть 2

Вопросы, связанные с

управлением финансами в

ИТ-сервисах все больше и

больше выходят на первый план.

Как разделить эти затраты

на конкретные сервисы и как

управлять стоимостью каждого

сервиса в отдельности? Вот те

вопросы, на которые нужно найти

ответ поставщику ИТ-сервисов.

Кроме того, руководители

ИТ-служб сталкиваются с

трудностями при составлении

и обосновании ИТ-бюджета,

которые продиктованы

спецификой ИТ.

Олег СкрынникВ области информационных технологий работает более 14 лет. Работал в Московской центральной бирже недвижимости и корпора-ции «Инком-Недвижимость». С 2004 по май 2009 года работал в компа-нии IT Expert, последняя должность на этом месте работы — директор департамента ИТ-консалтинга. В настоящее время возглавляет компа-нию Cleverics. Имеет опыт построения и реорганизации работы подраз-делений ИТ нескольких крупных компаний, включая «Уралкалий», ВЭБ, BSGV, ВТБ24, РЖД и другие.

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

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

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

68www.itsmforum.ru

Часть 2

В

Управление ИТ: не пора ли подумать

о деньгах?

Анна БусароваОкончила экономического факультета МГУ им. М.В. Ломоносова, кан-дидат экономических наук. В настоящее время возглавляет Отдел ана-лиза и развития бюджетной системы Департамента бюджетной поли-тики и методологии Минфина России. В 2001-2009 годах работала в сфере консалтинга. В сфере управления государственными финанса-ми занимается вопросами бюджетирования, повышение эффективнос-ти расходов. Работала в проектах по управлению экономикой и госу-дарственными финансами на федеральном, региональном и муници-пальном уровнях. Параллельно в сфере корпоративного финансового управления (с 2006 года) специализируется в области экономики и финансов в информационных технологиях.



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

Сколько стоит ИТ-сервис?

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

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

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

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

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

Поэтому надо опираться на внутреннюю систему управленческого учета. А до ста-

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

• учитывается ли основное ИТ-оборудование и программное обеспечение по его типам (описав состав аппаратного и программного обеспечения, участвующего в предоставле-нии ИТ-сервисов, нужно будет распределить по ним его стоимость);

• какова детализация накладных расходов в ИТ (аренда, сервисные контракты и т. п.);

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

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

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

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

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

Расчет себестоимости обеспечит понимание

структуры затрат на предоставление сервиса,

анализ которой не только позволит более точ-

но предсказать будущие затраты, но и помо-

жет оптимизировать портфель сервисов

70www.itsmforum.ru

Часть 2

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

Расчет себестоимости обеспечит понима-ние структуры затрат на предоставление сер-виса, анализ которой не только позволит более точно предсказать будущие затраты, но и поможет оптимизировать портфель сервисов.

Бюджетирование для поставщика внутренних ИТ-услуг

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

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

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

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

Управление финансами для специализированного ИТ-провайдера

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

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

• более сложная система управленческого учета, имеющая не только привычный поста-тейный разрез, но и разрезы, например, по сервисам и заказчикам;

• задача выстраивания политики ценообразо-вания;

• процесс планирования доходов, расходов и мер по обеспечению их баланса;

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

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

Рис. Управление экономикой ИТ по ITIL v3.



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

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

Проблемы управления экономикой и финансами в ИТ

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

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

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

Статья «Управление ИТ: не пора ли подумать о деньгах?» впервые опубликована в журнале «Открытые системы» № 6/2008. Публикуется с разрешения издательства «Открытые системы». Все права сохранены.

72www.itsmforum.ru

Часть 2

Статья посвящена практическому

примеру разработки положений об

ИТ-подразделениях при внедрении

процессов ITSM в государственной

организации с многоуровневой

территориально-распределенной

структурой. Приведенный опыт

разработки регламентов может

быть применен и в другой ситуации.

Категории ИТ-подразделений. Этапы разработки изменений

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

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

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

Ольга ОршанскаяКонсультант департамента управленческого консалтинга компании «Информационные Бизнес Системы» (IBS). Управленческим консалтин-гом и процессами ИТ-служб занимается около 3 лет. С ней можно свя-заться по адресу [email protected].

Как разработать изменения в положениях

об ИТ-подразделениях при внедрении процессов ITSM?

Борис БолтовскийГлавный системный архитектор департамента управленческого консалтинга компании «Информационные Бизнес Системы» (IBS). Управлением информационными ресурсами и сервисами занимает-ся около 20 лет. С ним можно связаться по адресу [email protected].



Ответ на эти и другие вопросы дает приво-димый ниже проектный опыт, полученный на основе внедрения в государственных струк-турах процессов ITSM. Рассмотрим такой опыт на примере внедрения и автоматизации процессов: управление конфигурациями, управление инцидентами, управление уров-нем ИТ-сервисов, управление изменениями и управления проблемами.

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

В целом разработка изменений осуществля-лась в три этапа (рис. 1).1. Формирование исходных данных и типовых положений на основе описаний внедряемых процессов.

2. Подготовка изменений в положения для объ-ектов автоматизации, включенных в пилот-ную зону.

3. Тиражирование изменений в положения, применительно к другим объектам автома-тизации предприятия.

Рассмотрим работы, выполняемые на каж-дом из приведенных этапов.

Процессы — роли — функции. Общие подходы

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

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

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

• права и ответственность ИТ-подразделения;• взаимодействие ИТ-подразделения.

Типовое положение

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

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

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

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

Рис. 1. Этапы разработки положений об

ИТ-подразделениях.

74www.itsmforum.ru

Часть 2

(показатель определяется как процент выпол-нения годового плана);

• степень освоения годового ИТ-бюджета (пока-затель определяется как процент неосвоен-ных запланированных средств);

• результаты аттестации персонала ИТ-под-разделений (показатель определяется как отношение числа сотрудников прошедших аттестацию с положительными выводами к общему числу аттестованных);

• доступность предоставляемых ИТ-сервисов (показатель определяется отношением реального времени доступности ИТ-серви-са к времени доступности, определенному договорами и внутренними соглашениями);

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

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

• результаты аудита общего состояния ИТ-инф-раструктуры и актуальности информации в системе учета объектов ИТ-инфраструктуры;

• время рассмотрения и выполнения запросов на внедрение новых ИТ-сервисов организации;

• процент жалоб к общему количеству посту-пивших запросов за месяц.

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

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

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

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

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

• изменение в организационной структуре, исходя из внедряемых процессов;• минимизация изменений в существу-ющей организационной структуре;

• передача части функций по техни-ческой эксплуатации автоматизиро-ванной системы и поддержке пользо-вателей силами внешних сервисных операторов;

• учет положительного опыта ИТ-подраз-делений управлений в региональных управлениях и требования к Центрам компетенции;

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

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

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

• группы сопровождения прикладного ПО (по числу основных прикладных систем), кото-рая отвечает за его сопровождение, включая администрирование, устранение нештатных ситуаций, учет и хранение дистрибутивов и

В ходе опытной эксплуатации, а также при

проведении последующего аудита, прово-

дился контроль исполнения персоналом

ИТ-подразделений региональных отделений

автоматизируемых процессов эксплуатации

автоматизированной системы и корректности

распределения ролей



документации, тестирование и внедрение обновлений, архивирование и хранение БД;

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

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

Цель Задачи Основные функции

Разработка и проведение ИТ-политики в интересах функ-циональных подразделений организации

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

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

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

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

Планирование и управление ИТ-бюд-жетом организации

Планирование затрат на проекты по модернизации и совершенствованию автоматизированной системы

Формирование программы развития персонала ИТ и пользователей функ-циональных подразделений с учетом общей стратегии развития автоматизи-рованной системы организации

Формирование программ обучения персонала для эффективности использования ИТРазработка планов повышения квалификации ИТ-сотрудников

Взаимодействие с внешними орга-низациями по вопросам развития в области информационных технологий

Разработка критериев оценки компетентности и надеж-ности внешних консалтинговых компаний

Создание, внед-рение и совер-шенствование прикладных информаци-онных систем и информацион-но-технической инфраструктуры организации

Формализация и документирование рабочих процессов

Разработка предложений по стандартизации и оптими-зации производственных процессов

Управление разработкой прикладно-го ПО, ИТ-инфраструктуры и типовых ИТ-решений

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

Организация плановой подготовки пользователей и обслуживающего пер-сонала автоматизированной системы

Разработка методик обучения и проведение обучения пользователей

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

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

Обеспечение штатного функ-ционирования прикладных информаци-онных систем и ИТ-инфраструк -туры

Обеспечение заданного качества ИТ-сервисов автоматизированной сис-темы

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

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

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

Контроль предоставления ИТ-сервисов внешними организациями и предпри-ятиями

Контроль выполнения требований соглашений о качест-ве предоставляемых ИТ-сервисов

Совершенствование деятельности ИТ-служб.

Внедрение процессных технологий в деятельности ИТ-подразделений. Анализ апробации и использование положительного опыта ИТ-подразделений региональных управлений

Таблица. Задачи и функции ИТ-подразделения.

76www.itsmforum.ru

Часть 2

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

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

Пилотная зона. Изменения в действующих положениях

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

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

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

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

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

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

Тиражирование решений

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

Итог

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

2. Снизить стоимость и сократить время тира-жирования организационных решений в региональные управления территориально-распределенной организации.

3. Централизовать обучение сотрудников ИТ-под-разделений региональных управлений вопро-сам организации их деятельности в соответс-твии с внедряемыми процессами ITSM.

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

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

78www.itsmforum.ru

Часть 2

В статье приводится

описание механизма

распределения ролей

исполнителей внедряемых

процессов управления

ИТ-сервисами (ITSM) и их

функций в ИТ-подразделении.

Распределение учитывает

особенности структуры ИТ-

подразделения, должностей

и иерархий. Кроме того,

приводится порядок разработки

должностных регламентов

сотрудников, планируемых

к вовлечению в реализацию

внедряемых процессов ITSM.

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

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

2. распределение ролей и их функций между структурными единицами ИТ-подразделения;

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

Далее в статье мы подробнее рассмотрим особенности реше-ния перечисленных задач.

1. Обследование ИТ-подразделения

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

Используются следующие методы получения информации:• анализ внутренних документов ИТ-подразделения и существу-ющей нормативно-методической документации по организа-ции ее деятельности;

• анкетирование представителей ИТ-подразделения;• интервьюирование ключевых специалистов ИТ-подразделения;• наблюдение за процессами деятельности.

Чулпан МифтаховаСтарший консультант департамента управленческого консал-

тинга компании «Информационные Бизнес Системы» (IBS). Вопросами организации управления ИТ занимается около

трех лет. С ней можно связаться по адресу [email protected]

Особенности распределения ролей

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

регламентов

В



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

• должностные регламенты сотрудников ИТ-подразделения;

• регламенты и инструкции, определяющие порядок деятельности персонала ИТ-подраз-деления;

• договоры на сопровождение и техническую поддержку программно-технических средств;

• порядок взаимодействия с пользователя-ми функциональных подразделений при осуществлении поддержки использования информационных систем или при устране-нии нештатных ситуаций;

• другие документы, регламентирующие деятельность персонала ИТ-подразделения.

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

2. внутренняя функциональная структура ИТ-подразделения и основные направления деятельности его структурных единиц;

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

4. набор функций, передаваемых ИТ-подраз-делением на ИТ-аутсорсинг;

5. уровень профессиональной подготовки сотрудников и предпочтения в деятельности ИТ-подразделения;

6. полнота и актуальность существующих долж-ностных регламентов ИТ-подразделения;

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

2. Распределение ролей в ИТ-подразделении

Для распределения ролей и их функций (по внедряемым процессам) между струк-турными единицами ИТ-подразделения исполь-зуется следующий пошаговый алгоритм:1. выделяется совокупность «роль-процесс-функции» из моделей описания внедряемых процессов;

2. функции (роли) распределяются по струк-турным единицам ИТ-подразделения в соот-ветствии с зафиксированными в рамках обследования основными направлениями их деятельности;

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

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

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

ние этого алгоритма.

2.1. Обзор моделей внедряемых процессов управления

Модель каждого внедряемого процесса пред-ставляет собой набор диаграмм, нижний уровень, как правило, отображают в виде диа-граммы событийно-управляемого процесса eEPC (extended Event-driven Process Chain). Диаграмма представляет собой строгую пос-ледовательность действий (функций) и событий. На ней отображается, в том числе, исполнитель каждой функции. Таким образом, для каждой роли можно выделить совокупность функций, выполняемых в рамках каждого из про цессов. Получающийся список показан в таблице 1.

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

2.2. Распределение ролей по структурным единицам ИТ-подразделения

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

Роль Процесс ФункцииДиспетчер • Управление

инцидентами• Регистрация инцидента• Эскалация инцидента• …

• Управление изменениями

• Регистрация изменения

Менеджер инцидентов

• Управление инцидентами

• Эскалация инцидента• Разрешение конфликт-ных ситуаций

…• Управление изменениями

• Регистрация изменения

… • … …

Таблица 1. Состав основных функций ролевых участников процессов.

80www.itsmforum.ru

Часть 2

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

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

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

2.3. Распределение ролевых функций между сотрудниками

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

Группирование ролей производится на осно-ве таблицы 2, разработанной с учетом реко-

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

2.4. Расчет загруженности должностей и выводы по численности

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

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

3. Разработка ролевых регламентов

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

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

Наименование процесса

Процесс управленияинцидентами проблемами конфигурациями изменениями … уровнем

сервиса

Упра

влен

ие

инцидентами - Х Р Х - Рпроблемами - - О О - -конфигурациями - - - О Р -изменениями - - - - - Р… - - - - - -уровнем сервиса

- - - - - -

Примечание:Х – роли совмещать нельзя; О – рекомендуется совмещение ролей;Р – необходимо рассматривать в каждом конкретном случае.

Таблица 2. Рекомендации по совмещению ролей в рамках процессов.



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

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

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

3. права и обязанности;4. ответственность (описание зоны ответствен-ности);

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

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

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

4. Разработка должностных регламентов

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

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

• положения, закрепленные в соответствующих ролевых регламентах;

• внутренние требования к структуре и содер-жанию регламентов и имеющиеся в этой области наработки ИТ-подразделения;

• положения, закрепленные в действующих должностных регламентах ИТ-подразделения.

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

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

Выводы

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

• обеспечить руководителей ИТ-подразделения необходимыми знаниями для скорейше-го внедрения новых процессов управления ИТ-сервисами;

• адаптировать ролевые проектные решения к реальной организационной структуре ИТ-подразделения и привести в соответствие должностные инструкции его персонала к внедряемым процессам;

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

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

82www.itsmforum.ru

Часть 2

В самом начале октября

2009 года OGC объявил о запуске

новой, официальной схемы сер-

тификации программного обес-

печения на совместимость с ITIL.

Так как встретить на практике

оперативные процессы управле-

ния без автоматизации довольно

сложно, необходимо разобраться

в новой схеме и предположить

последствия ее запуска.

Сертификация ПО на совместимость с ITIL.

Теперь официальная

Олег СкрынникВ области информационных технологий работает более 14 лет. Работал в Московской центральной бирже недвижимости и корпора-ции «Инком-Недвижимость». С 2004 по май 2009 года работал в компа-нии IT Expert, последняя должность на этом месте работы — директор департамента ИТ-консалтинга. В настоящее время возглавляет компа-нию Cleverics. Имеет опыт построения и реорганизации работы подраз-делений ИТ нескольких крупных компаний, включая «Уралкалий», ВЭБ, BSGV, ВТБ24, РЖД и другие.

Что было раньше

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

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

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

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

82www.itsmforum.ru

Часть 2



характер, а результат оценки — бинарный: кри-терий либо выполнен, либо — нет.

На момент написания этой статьи по схеме PinkVerify сертифицировано около 50 программ ных продуктов, из которых более10 доступны в России. С выходом в 2007 году новой версии библиотеки ITIL сертификация и критерии PinkVerify были обновлены.

Схема сертификации PinkVerify довольно проста и представлена на рис. 1. Производитель программного обеспечения, имеющий жела-ние подтвердить соответствие своего продукта тому, что написано в библиотеке ITIL, обраща-ется в компанию Pink Elephant. Если его продукт успешно проходит проверку соответст вия крите-риям2, то за небольшую плату он получает право использовать логотип PinkVerify при рекламе и маркетинге своего ПО.

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

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

Новая реальность

Однако, скорее всего, появление официальной схемы сертификации ПО было лишь вопросом времени. С выходом ITIL v3 мир ITIL сильно изме-нился. Появился новый игрок, коммерческая компания APM Group (APMG), взявшая на себя существенную часть функций OGC, присту-пившая к «наведению порядка» и внедрению новых правил. Можно вспомнить область сер-тификации специалистов по ITIL, и параллели с сертификацией ПО появятся сами собой.

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

Итак, OGC предоставил компании APMG право аккредитовывать другие компании, назы-ваемые Licensed Software Assessor — лицензи-рованный оценщик ПО. Эти компании и будут проводить оценку программных инструментов на основе единых критериев, разработанных, вроде бы, APMG.

Первым лицензированным оценщиком ПО стала компания The Service Management Consultancy Group (SMCG). Спустя некоторое время вторым лицензированным оценщиком стал Pink Elephant. Текущая расстановка сил очень похожа на ситуацию в области обуче-ния — несколько лет назад условный союз ком-паний EXIN и ISEB был «разбавлен» компаниями LCS, CSME, Dansk IT, DF Certifiering AB, TÜV SÜD Akademie и собст венно APMG. Все они сейчас имеют право принимать официальные экзаме-ны по ITIL.

Первой компанией, получившей заветный статус ITIL Process Compliant, стала BMC. За ней последовали CA, IBM и Intasoft (к слову, програм-мный продукт последней не имеет сертифика-ции PinkVerify, в отличие от остальных трех компа-ний). В чем же заключается этот новый статус?

Рис. 1. Схема сертификации PinkVerify.

Рис. 2. Схема сертификации согласно APMG.

2 Есть, правда, нюанс — первичную оценку собственного ПО производитель выполняет самостоятельно, но в контек-сте данной статьи это лишь детали.

84www.itsmforum.ru

Часть 2

Предусмотрено три уровня сертификации — бронзовый, серебряный и золотой. Эти уровни довольно забавны.• ITIL Process Compliant — Bronze Level означает, что ПО проходит по критериям, но нигде и никем пока не применяется.

• ITIL Process Compliant — Silver Level предна-значен для ПО, которое не только удовлетво-ряет критериям, но и установлено3 не менее чем в трех различных организациях.

• ITIL Process Compliant — Gold Level присваива-ется ПО, которое ко всему прочему не только установлено, но и реально применяется как минимум тремя клиентами, при этом эти кли-енты счастливы4.

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

Счастье, оно ведь совсем рядом…

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

Далее, вероятнее всего, по аналогии с экзаменационной схемой появится несколь-ко новых лицензированных оценщиков, при этом многие из них будут мало знакомы ITSM-сообществу. Наверное, это неплохо, ведь в таком случае производители ПО могут выбирать, с кем иметь дело (ровно так же, как слушатели курсов сейчас выбирают, в какой компании сдавать экзамен по ITIL). Однако здесь ситуация несколько сложнее, чем при приеме экзаменов. Скорее всего, при провер-ке ПО большинство программ получит отметку «выполнимо» почти по всем критериям, и только от внимательности, опыта и беспристрастности оценщика зависит вердикт. В прошлом провер-ку проводил Pink Elephant, ставя на карту собс-

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

Здесь можно вспомнить один нюанс. Критерии проверки PinkVerify, как было сказано выше, доступны бесплатно всем желающим: эта схема сертификации полностью открыта. С критериями официальной схемы ситуация ровно противопо-ложная — они закрыты и известны очень неболь-шому числу лиц. Получается, что клиент должен полностью доверять той компании, которая раз-работала критерии. Но снова на ум приходит аналогия с экзаменами по ITIL, когда даже отно-сительно простой экзамен «ITIL v3 Foundation» пришлось существенно переделывать, так как ни вопросы, ни ответы не позволяли кандидатам его нормально сдавать, а рекомендованная литература содержала противоречия с текстом экзамена. Более того, в истории с сертификаци-ей ПО критерии проверки недоступны даже про-изводителям ПО5: «Вопросы проверки остаются у лицензированного оценщика и задаются произ-водителю только в момент оценки».

Известная в ITSM-кругах личность, Эйден Лоуз (Aiden Lawes), на протяжении восьми лет воз-главлявший itSMF UK и itSMF International, делает весьма резкие заявления6 в адрес новой схемы сертификации: «[схему] намеревались запус-тить в интересах клиентов, но, похоже, она полу-чилась в интересах небольшой группы (OGC, APMG и SMCG), вовлеченной в ее секретную разработку». Зачем закрывать завесой тайны механизм, который, очевидно, должен быть полностью прозрачным для главных потреби-телей схемы сертификации — клиентов, выби-рающих для себя программное обеспечение? Или не они являются реальными потребителями?

Президент SMCG, он же один из двух работ-ников этой компании, на сайте своей ком-пании заявляет7 буквально следующее: «Этот новый стандарт был разработан и установлен компанией SMCG». Какова же реальная роль SMCG в этой истории?

И, наверное, последний вопрос. Много ли будет желающих среди производителей ПО прой ти новую, официальную сертификацию? Учи-тывая непрозрачность, субъективность и непро-работанность схемы — видимо, нет. Однако ответ не так очевиден, если принять во внимание еще одну цитату разработчиков: «… ожидается, что оценка на соответствие ITIL будет являться обяза-тельной для всех поставщиков ПО, которые жела-ют продавать свои продукты в Великобритании, напрямую или в качестве сервисов».

3 Именно так — deployed.4 В оригинале: «…are using the product and are happy to

reference…» http://www.best-management-practice.com/Knowledge-Centre/News/ITIL-News/? DI=620593

5 http://www.smcgltd.com/Software_Assessments

6 http://www.itpreport.com/default. asp? Mode=Show&A=2012

7 http://www.smcgltd.com/Software_Assessments



Новый стандарт описания процессов

Говорят, однажды, в возрасте девятнадцати лет, будучи студентом Мюнхенского университета, Макс Планк рассказал пожилому профессору Филиппу Жолли о своем намерении посвятить себя теоретической физике. Выслушав его, профессор воскликнул: «Молодой человек, зачем вы хотите испортить себе жизнь? Ведь теоретическая физика уже в основном закончена… Стоит ли браться за такое бесперспективное дело?!». Двадцать пять лет спустя Макс Планк выдвинул гипотезу дискретного излучения, став-шую основой принципиально нового направления — квантовой физики, которая перевернула многие сложившиеся представле-ния физиков ХХ столетия и по сей день лежит в фундаменте сов-ременных представлений об устройстве мира.

С тех пор прошло около ста лет. Изобретено и используется множество подходов к описанию бизнес-процессов (IDEF0, IDEF3, CFD, EPC и другие). И все же продолжают появляться новые стан-дарты описания процессов. В 2004 году опубликована первая спецификация новой графической нотации описания бизнес-процессов BPMN (Business Process Modeling Notation). Зачем и кому нужен BPMN? Будет ли BPMN полезен при моделировании процессов ITSM? И сможет ли этот «новичок» совершить переворот в современной практике моделирования процессов?

Применение BPMNдля моделированияпроцессов ITSM

Дмитрий ИсайченкоВозглавляет департамент консалтинга компании Cleverics. В области информационных технологий работает с 1997 года. С 2005 по май 2009 года работал в компании IT Expert, последняя должность на этом месте работы — заместитель директора департамента ИТ-консалтинга. Имеет опыт обследования и реорганизации работы подразделений ИТ ряда средних и крупных компаний: BSGV, ВТБ24, Банк «Санкт-Петербург», «Внешэкономбанк», «Банк Москвы», «Центральный телеграф», СУАЛ, «Сильвинит» и других.

Чтобы сформировать точное,

пригодное для автоматизации

описание сложного процесса,

применяется стандарт BPMN.

Может ли он помочь в описании

процессов ITSM? Да, ведь они

содержат «сложные» участки,

адекватное описание которых с

использованием только базовых

инструментов крайне громоздко.

Однако пока использование

BPMN в ITSM — это удел

энтузиастов.

86www.itsmforum.ru

Часть 2

Суть идеи

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

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

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

каемых потоков, или ветвления по произошед-шему событию);

• события (события времени, внешние события, например, важные изменения котировок, вхо-дящие или исходящие сообщения, ошибки и так далее);

• точки синхронизации параллельных потоков работ;

• различные варианты подпроцессов (напри-мер, повторяющиеся подпроцессы или под-процессы без четких правил исполнения).

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

Как обеспечить выполнение процесса, если у нас имеется его точное описание в BPMN? Традиционный вариант — передать диаграмму процесса системному аналитику для реализа-ции в используемой системе автоматизации. Где-то для этого придется писать код, где-то — использовать графический редактор workflow, где-то — использовать редактор бизнес-правил, не требующий программирования. И этот под-ход вполне работает.

Рис. Описание процедуры закрытия инцидента на BPMN.



Если ваша система автоматизации подде-рживает BPEL, то можно просто «транслировать» диаграмму BPMN в код BPEL и запустить его в работу — базовая автоматизация процесса готова. BPEL — это универсальный высокоу-ровневый язык исполнения бизнес-процессов (Business Process Execution Language). Таким образом, BPMN предназначен для людей и используется для разработки точных описаний сложных процессов, а BPEL предназна-чен для машин, выполняющих автома-тизацию этих процессов. Так про это и говорят: BPEL is not for people (не для людей).

BPMN и процессы ITSM

Итак, у нас есть стандарт BPMN, и его можно применять для описания раз-личных процессов, в том числе процессов управления ИТ-сервисами. Но есть ли от этого какая-то польза? Оказывается, есть.

Дело в том, что процессы ITSM тоже содер-жат «сложные» участки, адекватное описание которых с использованием только базовых инструментов крайне громоздко. Типичные примеры таких участков — согласования изме-нений и документов, получение подтверждения пользователей о решении инцидентов, органи-зация периодического контроля известных оши-бок в рамках управления проблемами, то есть такие участки, где взаимодействие участников работ непосредственно поддерживается систе-мой автоматизации. Рассмотрим простейший пример: проверку инцидента перед закрытием.

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

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

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

Чтение представленной диаграммы тре-бует определенной привычки, однако схема

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

Подобных примеров в процессах ITSM можно привести множество.

Выводы

Конечно, BPMN — не универсальная «палочка-выручалочка». По-прежнему основные про-блемы ITSM-проектов заключаются в полной подмене основной идеи — вместо проведения изменений в подходе к управлению зачастую выполняется просто внедрение системы авто-матизации, сдобренной пачкой регламентов. Их не читают и не используют. Диаграммы BPMN в них никто не увидит и не оценит. Систем автоматизации ITSM-процессов, поддерживаю-щих BPMN и BPEL, пока не появилось. Похоже, время Макса Планка в управлении ИТ еще не пришло…

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

• взаимодействие процессов и исполни -телей.

Процессы ITSM содержат «сложные» участки,

адекватное описание которых с использова-

нием только базовых инструментов, крайне

громоздко. Здесь и примени' м BPMN

88www.itsmforum.ru

Часть 3

Эта статья является анализом

собственного опыта автора по

созданию процессов управления

мощностью и финансового

управления для ИТ.

Опыт управленияОпыт управлениямощностью и финансамимощностью и финансами

Виталий ХозяиновНезависимый эксперт по информационным технологиям, сертифицированный сервис-менеджер. Профессионально занимается

ИТ с 1996 г. За более чем 11 лет работы в международной косметической компании «Мэри Кэй» создал развитую службу ИТ для восточноевропейских офисов организации, а также портал, через который осуществля-ется более 50% продаж компании в странах Восточной Европы. В 2008—2009 гг. работал в компании «Видео Интернешнл». С 2009 г. —

независимый эксперт по ИТ. С ним можно связаться по адресу:

[email protected].


На границах ITSM

«Канарейку за копейку, чтобы пела и не ела».Народная присказка

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

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

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

Опыт решения проблемы произодительности

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

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

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

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

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

Прогнозирование потребностей в мощности

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

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

Б

90www.itsmforum.ru

Часть 3

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

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

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

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

Выбор решения

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

Финансовая сторона

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

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

Рис. Зависимость нагрузки на конфигурационные

единицы от времени.

92www.itsmforum.ru

Часть 3

Антон СаввинРуководитель службы развития систем поддержки операций компа-нии «Вымпелком». Практик внедрения и автоматизации процессов ITSM и OSS Telecom. В качестве процессного менеджера построил в компании ИТ-процессы управления конфигурациями, мощностями и изменениями ИТ-инфраструктуры. Внедрил единую корпоративную систему управления инцидентами, проблемами и конфигурациями ИТ. Выполнил интеграцию OSS систем Trouble Ticketing, Inventory и Umbrella Monitoring для мобильной сети.

92www.itsmforum.ru

Часть 3

Александр ЧижовДиректор департамента консалтинга и разработки компании «Би-Эй-Си» группы «Астерос». Основатель практик консалтинга в облас-ти ИТ и внедрения ITSM-систем. Осуществляет непосредственное руко-водство программами внедрения системы управления ИТ-сервисами в компании «Вымпелком» и системы управления доступом к ИТ-ресур-сам в «МегаФоне».

О роли«бизнес-ролей»

В чем проблема?

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

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

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

• проактивное понятие «цель» переходит в реактивное понятие «функция»;

• выполняемые человеком «бизнес-операции» превращаются в «сценарии» работы программного обеспечения;

• географическое местоположение теряет смысл, поскольку пользователь работает в виртуальном логическом сетевом пространстве;

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

Эта статья появилась как

результат дискуссий людей,

пытающихся на практике строить и

автоматизировать бизнес-процессы

в области ИТ и Телекоммуникаций.

Мы искренне надеемся, что

полученный нами опыт будет

интересен как руководителям,

строящим в своей организации

управление бизнес-процессами,

так и непосредственным

участникам предоставления

сервисов, желающих понимать не

только свою позицию в линейном

департаменте, но и свою роль в

достижении общих результатов.



Современный бизнес все больше становится электронным, когда практически единственной точкой контакта корпорации с клиентом являет-ся телекоммуникационное устройство, через которое реализуется электронная услуга в виде цепочки взаимодействия сервисов, использую-щих ресурсы. Описание такого подхода хорошо изложено в телекоммуникационных методологи-ях Telemanagement Forum (www.tmforum.com).

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

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

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

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

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

Акцент на строительстве процессов

Сам по себе, процессный подход давно общепризнан, как для корпорации в целом [2], так и для отдельной ее части (например, мето-дология ITIL [3] для управления процессами ИТ), однако одно дело понимать и соглашаться c правильностью подхода и другое дело стро-ить процессы на практике. Приведем только несколько цитат основоположников реинжи-ниринга бизнес-процессов М. Хаммера и Д. Чампи [2]:

• Компании состоят из функциональных шахт или дымоходов, вертикальных структур, опи-рающихся только на небольшие элементы процессов»;

• Люди смотрят внутрь (в направлении своего отдела) и вверх (на своего начальника), но

Сотрудник

Пользователь

Рис. 2. Матрица «Процессы — Организационная

структура».

Рис. 1. Граница между архитектурными слоями: «люди» и

«инструменты».

94www.itsmforum.ru

Часть 3

никто не смотрит наружу (в направлении кли-ента)»;

• Часто эффективность подразделений дости-гается в ущерб общей эффективности ком-пании»;

• Часто источником проблем является работа, требующая координации нескольких подраз-делений»;

• Часто, даже если конкретная работа очень важна для компании, за нее некому отвечать»;

• Фирмы должны выйти за рамки функциональ-ного построения подразделений и обратить внимание на процессы».

Думаем, для многих, особенно среднего размера предприятий, это актуально и сегодня.

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

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

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

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

Введение понятия бизнес-роль

В реальной жизни мы интуитивно оперируем не процессными, а совсем другими «агреги-рованными» ролями, как правило, полностью описывающими характер деятельности сотруд-ника. Например «Администратор баз данных», «Разработчик программного обеспечения», «Инженер Service Desk»… Отличительной чертой этой группы ролей является предметная область и бизнес-объекты (Data Base, Software, Incidents), за которую несет ответственность сотрудник, а участие сотрудника в разных процессах является только следствием этой ответственности.

Таким образом, отвечая на основной вопрос «Что такое роль?», мы предлагаем пользоваться двумя понятиями:• «процессные роли», которые отражают связь

«роли — процессы», полностью инкапсулиро-ваны в процесс и определяются конкретной процессной методологией (COBIT, ITIL…) или владельцем процесса;

• «бизнес-роли», которые отражают связь «роли — данные» и определяются предмет-ной областью организации.

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

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

Рис.3. Диаграмма классов, описывающая деятельность

сотрудника



Таблица. Пример ролевой матрицы.

Бизнес-роли Объекты предметной области

Роли в процессе управления заявками на

услуги

Роли в процессе управления инцидентами

Роли в процессе управления проблемами

Роли в процессе управления изменениями

Роли в процессе управления конфигура-

циямиСотрудник компании Заявки на услу-

ги, инцидентыИнициаторзаявки на услугу

Инициатор инци-дента

Ключевой бизнес-пользователь

Проблемы, RfC, приложения

Инициатор проблемы

Инициатор RfC, согласую-щий RfC

Читатель CMDB

Менеджер продукта Продукты, метрики

Информи руемый Инициатор проблемы


Владелец КЕ

Менеджер сервиса Сервисы, метрики




Бизнес — ладелец КЕ Разные Согласующий заявки




Специалист Service Desk

Заявки на услу-ги, инциденты

Координатор заявок


Специалист HelpDesk

Заявки на услу-ги, инциденты

Исполнитель заявок

Инженер 1-го уровня поддержки


Дежурный администратор

Разные Исполнитель заявок

Инженер 2-го уровня под держки


Исполнитель RfC


Эксперт HelpDesk Инцидент Инженер 1-го уровня под держки


Согласующий RfC, исполни-тель RfC


Администратор рабочих мест

Рабочие места, приложения

Исполнитель заявок





Эксперт по рабочим местам


Согласующий заявки


Эксперт по проблемам



Менеджер-владелец рабочих мест



Эскалируемый Менеджер про-блемы

Согласующий RfC

Менеджер-владелец КЕ

Администратор бизнес-приложения

Приложение Исполнитель заявок





Релиз-менеджер Приложение Инженер 3-го уровня под держки




Эксперт по бизнес-приложе-ниям

Приложения Согласующий заявки



Инициатор RfC, согла -сующий RfC


Менеджер-владелец бизнес-приложений

Приложения, метрики





Администратор баз данных

Базы данных Исполнитель заявок





Эксперт по базам данных

Базы данных Согласующий заявки





Менеджер-владелец баз данных

Базы данных, метрики





Эксперт по инфор-мационной безопас-ности

Разные Согласующий заявки





Менеджер контроля качества

Метрики Владелец КЕ

Менеджер процес-са

Сотрудники,процессные роли

Менеджер про-цесса SRM

Менеджер про-цесса INC

Менеджер про-цесса PRB

Менеджер процесса CHG

Менеджер процесса CFG

Линейный руководи-тель

Сотрудники,бизнес-роли


Информируе мый,эскалируемый

Менеджер про-блемы



96www.itsmforum.ru

Часть 3

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

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

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

Практический пример

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

Вариант фрагмента персональной ролевой инструкции может быть таким:

Задачами сотрудника является исполне-ние бизнес-ролей «Специалист Service Desk», «Дежурный администратор», «Администратор бизнес-приложения»… участие в процессах «Управление заявками на услуги», «Управление инцидентами», «Управление проблемами», «Управление изменениями» «Управление конфигурациями», участие в процедурах «Согласование заявок», «Обработка инциден-тов», «Решение проблем», «Обработка запро-сов на изменения»… в качестве координатора и исполнителя заявок на услуги, инженера 2-го уровня поддержки приложений, инициатора

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

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

Общие выводы по поводу ролевой инструкции и организации процессов

1. Используйте в дополнение к официальной должностной инструкции персональную ролевую инструкцию, назначающую сотруд-ника на бизнес-роли.

2. Различайте процессные роли, исполняющие операции, и бизнес-роли, ответственные за предметную область.

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

4. Владельцам процессов следует делать акцент на разработке сервисно-ориентиро-ванных процедур с использованием процес-сных ролей только из ролевой матрицы.

5. Линейным менеджерам следует обеспечи-вать полноту списка бизнес-ролей и факти-ческое назначение каждого своего подчи-ненного сотрудника на одну или несколько бизнес-ролей.

6. Для хранения связанной информации используйте автоматизированную базу дан-ных, например, CMDB.

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

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

9. Моментом изменения персональной роле-вой инструкции является не переход с долж-ности на должность, а момент изменения бизнес-ролей сотрудника в связи с измене-нием предметной области или изменением полномочий в процессе.

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

Статья впервые была опубликована в журнале CIO № 9/2008. Публикуется с разрешения издатель-ского дома «Журнал СИО: Руководитель Информационной Службы».

Литература1. Сервисная модель архитектуры 5-DSM. А. Саввин, А. Чижов, CIO № 5/2007.

2. Хаммер М., Чампи Д. Реинжиниринг корпорации: манифест революции в бизнесе.

3. Материалы ITIL. http://www.ogc.gov.uk/guidance_itil_4672. asp



Переход к современным моделям

предоставления ИТ-услуг и

внедрение информационной

системы управления ИТ —

дело непростое и хлопотное.

Достаточно много провальных

проектов реформирования

ИТ на предприятиях на основе

сервисной модели. Как можно

исправить ситуацию? Для этого

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

методов управления изменениями.

Главное — изменитьменталитет и поведение людей

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

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

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

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

Семь «секретов» успехана пути изменений в ИТ

98www.itsmforum.ru

Часть 3

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

Семь этапов проведения изменений

Суть предлагаемого подхода, его основная философия, очень проста и описана в литерату-ре по бизнесу (например, в книге John P. Kotter, Dan S. Cohen «The Heart of Change»), но крайне редко применяется на практике в области ИТ-проектов. Практически во всех случаях измене-ний существует последовательность из семи этапов. Исключение любого из них, переход на следующий без решения задач предыдущего — может свеcти на нет все потраченные усилия!

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

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

Итак, ощущение необходимости немед-ленных перемен «откроет дверь проекту», определит акценты, поможет собрать видение проекта.

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

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

На четвертом этапе исключительно важно заинтересовать в проекте уже всех участни-ков, а не только группу лидеров. Отсутствие

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

Планирование быстрых побед необ-ходимо выделить в отдельный пятый этап, в силу их огромной важности.

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

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

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

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

Практически во всех случаях изменений су-

ществует последовательность из семи эта-

пов. Исключение любого из них может свеcти

на нет все потраченные усилия



Любой руководитель бизнеса

хочет, чтобы у клиента не было

проблем. Точнее — стремится

предоставить сервис с заранее

оговоренным качеством. Однако

в реальной жизни всегда

происходят ошибки, и вопрос

лишь в том, как к ним относиться

и какой уровень ошибок допустим.

Клиенты расценивают получение

некачественного сервиса как

инцидент и пытаются любым

способом достучаться до людей,

продавших сервис. Бизнес

пытается упорядочить эту

активность, выстраивая «горячие

линии», центры обработки

вызовов, разделы поддержки на

сайтах. Данный материал — моя

попытка поделиться мыслями

о нескольких моментах, на

которых важно фокусироваться

при построении архитектуры

поддержки клиента.

Действие, порождающее

эффективность

Антон СаввинРуководитель службы развития систем поддержки операций компа-нии «Вымпелком». Практик внедрения и автоматизации процессов ITSM и OSS Telecom. В качестве процессного менеджера построил в компании ИТ-процессы управления конфигурациями, мощностями и изменениями ИТ-инфраструктуры. Внедрил единую корпоративную систему управления инцидентами, проблемами и конфигурациями ИТ. Выполнил интеграцию OSS систем Trouble Ticketing, Inventory и Umbrella Monitoring для мобильной сети.

Сверим понятия

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

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

• по уровню контекста — «порожденные людьми» и «порожден-ные автоматизированными системами».

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

• по значимости для «меня лично», события делятся на важные и неважные (говоря «важные» мы в конечном счете подразумева-ем «влияющие на качество моей жизни»).

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

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

100www.itsmforum.ru

Часть 3

Второе наблюдение: анализ можно упрос-тить, совместив понятия качества и важности, а также понятия сложности и ресурсоемкости, и оперировать обобщенным понятием ресурс:

«Ресурсы» = «физические»+«программные»+«информационные»+«человеческие»+«финансовые»+«время»

Тогда анализ сводится к рассмотрению поведения системы по отношению к двум основным параметрам — «ресурсоемкость» и «важность». Эти два параметра по сути заме-няют классический проектный треугольник-ограничитель «время»-«деньги»-«качество».

Нельзя дважды войти в одну и ту же реку

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

В общем случае, элементарный цикл деятельности представляет собой цепочку:

«событие» → «рефлексия» → «анализ и приня тие ре шения» → «планирование дейст-вия» → «ответное событие»

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

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

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

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

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

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

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

3. Крупные изменения, трансформирующие систему в новое качественное состоя-ние. Эта область соответствует проектной деятельности.

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

Рис. 1. Воронка событий: от мелких транзакций к

трансформации самой системы



как объем бизнеса, а уровни изменений — как уровни принятия управленческих решений.

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

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

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

О неделимости системы

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

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

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

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

Лучше один раз увидеть, чем семь раз услышать

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

Первый источник (внешний) — «взгляд со стороны клиента» — непосредственное обще-ние с клиентами через колцентры, сайты… Для управления общением с клиентами обычно используется одна или несколько CRM-систем. Веских причин специально централизовать всех клиентов в одной системе практически нет. Основным критерием разделения потоков обращения по системам является тип клиента.

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

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

102www.itsmforum.ru

Часть 3

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

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

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

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

4. Для операционной деятельности внести в пословицу зависимость от времени и источ-ников информации: «Лучше один раз зара-нее увидеть на мониторе, чем семь раз услышать потом, от клиентов».

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

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

Сколько требуется уровней поддержки?

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

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

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

Рис. 2. Два потока событий о качестве сервисов.



Мудрый не попадает в ситуацию, из которой умный с честью выходит

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

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

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

Области 5, 6, 7 являются зонами эффек-тивной работы. Классический подход пред-лагает фокусироваться на важных, но несрочных делах. Я сознательно убрал из анализа время, включив его в общий пара-метр «ресурс» и предлагаю фокусироваться только на важности результата и минимальных ресурсах.

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

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

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

Практические выводы по архитектуре поддержки

1. Не бояться децентрализации CRM-систем по типам клиентов, а систем мониторинга — по типам ресурсов.

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

3. Фокусироваться на проактивном управлении важными проблемами, соблюдая баланс между результатом и затрачиваемыми уси-лиями.

Возможно, эти выводы покажутся кому-то оче-видными, однако следуют им почему-то далеко не все.

Рис. 3. Квадрант эффективности. Соответствие

важности событий и ресурсов, которые вы готовы

заплатить за результат.

104www.itsmforum.ru

Часть 3

Как правило, разработка и

эксплуатация информационных

систем относительно слабо

связаны между собой. Если

говорить более точно, во многих

случаях при запуске и выполнении

проекта по внедрению новой

информационной системы

об эксплуатации вспоминают

только на этапе развертывания

системы. Однако именно на стадии

эксплуатации наиболее полно

проявляются риски, связанные с

использованием информационных

систем. На практике получается,

что подразделение эксплуатации

к началу внедрения системы

оказывается совершенно не

подготовленным.

а годы работы с банковскими структурами мы убедились, что процесс разработки программного обеспечения в банках находится на относительно высоком (для российского рынка) уровне зрелости. Довольно часто в работе используются как зарубежные [1], так и отечественные [2], [3] стандарты и своды знаний в области разработки программного обеспечения. Многие организации также систематически работают над фор-мализацией и совершенствованием деятельности по эксплуа-тации информационных систем.

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

Вместе с тем, только когда начинается «жизнь после внедре-ния», то есть на стадии эксплуатации, информационные системы:• становятся важным (а иногда критичным) элементом обеспе-чения деятельности организации;

• обеспечивают реализацию итоговой ценности для заказчика, заложенной в систему в ходе ее создания;

• начинают существенно влиять на работу пользователей в ходе их участия в бизнес-процессах организации.

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

Дмитрий ИсайченкоВозглавляет департамент консалтинга компании Cleverics. В области информационных технологий работает с 1997 года. С 2005 по май 2009 года работал в компании IT Expert, последняя должность на этом месте работы — заместитель директора департамента ИТ-консалтин-га. Имеет опыт обследования и реорганизации работы подразделе-ний ИТ ряда средних и крупных компаний: BSGV, ВТБ24, Банк «Санкт-Петербург», «Внешэкономбанк», «Банк Москвы», «Центральный теле-граф», СУАЛ, «Сильвинит» и других.

Жизнь после внедрения.

Разработка ПО с учетом последующей эксплуатации

З



ние и содержание инфраструктуры, обучение персонала и проч.).

Однако на практике получается, что под-разделение эксплуатации к началу внедрения системы оказывается совершенно не подготов-ленным:• не хватает ресурсов, в том числе иногда и персонала (администраторов, специалистов по поддержке), а на поиск и найм требуемых специалистов может уйти значительное время;

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

• не проработаны жизненно важные для экс-плуатирующего подразделения вопросы отказоустойчивости, журналирования, мони-торинга;

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

• выясняется, что заказчику были обещаны сроки окончания проекта, совершенно несовместимые с текущими планами работ эксплуатирующего подразделения.

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

1. Стандарты и рекомендации

К сожалению, информации о том, как организо-вать взаимодействие подразделений разработки и эксплуатации, в общедоступных источниках и стандартах не так много, как хотелось бы. Так, отечественный ГОСТ 34.601 «Автоматизированные системы. Стадии создания» вообще не акцен-тирует внимание на эксплуатации. С выходом стандарта ГОСТ Р ИСО 12207-1999 «Процессы жизненного цикла программных средств» ситуа-ция немного улучшилась:• стадии эксплуатации и сопровождения явно выделены в жизненном цикле программных средств и систем (разделы 5.4 и 5.5 стандарта);

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

• выполнение эксплуатационных требований подлежит проверке в ходе квалификационных испытаний системы (пункт 5.3.11.2) и далее на этапе эксплуатационных испытаний (пункт 5.4.2);

• жизненный цикл охватывает не только внед-рение, но и вывод системы из эксплуатации (пункт 5.5.6).

Вместе с тем, раздел 5.4 «Процесс эксплу-атации» занимает чуть менее одной страницы (это один их самых коротких разделов стан-дарта) и по существу ограничивается краткими и высокоуровневыми требованиями к тому, что должно быть обеспечено. Это естественно для подобного стандарта, но не дает ответа на воп-рос, как организовать выполнение предъявлен-ных требований.

Пожалуй, наиболее полные рекомендации по поставленному вопросу содержатся в материалах библиотеки ITIL [4], но и они, безу-словно, требуют интерпретации, преломления через собственный опыт.

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

2. Вариант решения задачи

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

(5.3.2);2. проектирование (5.3.3-5.3.6);3. создание, программирование и квалифика-ционные испытания (5.3.7-5.3.11);

4. ввод в опытную эксплуатацию (5.3.12);5. опытная эксплуатация и приемочные испы-тания (5.3.13, 5.4.2);

6. эксплуатация (5.4.3-5.4.4) и сопровождение (5.5).

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

2.1. Определение и анализ требований заказчика

На этом этапе эксплуатирующее подразде-ление привлекается для решения следующих задач:• верификации требований на предмет пол-ноты;

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

• согласования высокоуровневой архитектуры решения (на этом этапе фактически выполня-ется высокоуровневое проектирование буду-щей системы);

• оценки требований на предмет реалистич-ности исполнения;

106www.itsmforum.ru

Часть 3

• формирования бюджетных оценок на инф-раструктурное обеспечение системы.

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

Этап завершается подписанием высокоу-ровневого документа, определяющего буду-щую систему в терминах решаемых задач и основных требований — System Definition Document [1], согласованный тремя сторона-ми — заказчиком, разработчиком и, что очень важно, подразделением эксплуатации.

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

• анализирует возможные альтернативы;• исходя из предложенного решения, назна-чает ответственного за систему со стороны эксплуатации (в дальнейшем именно этот сотрудник координирует все вопросы по сис-теме в ходе эксплуатации и сопровождения).

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

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

2.3. Создание, программирование и квалификационные испытания

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

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

Данный этап завершается проведением ква-лификационных испытаний, которые проводят-ся в выделенной тестовой среде. При этом все операции по развертыванию в тестовой среде выполняет выделенная группа тестирования в составе подразделения эксплуатации, прове-ряя по согласованной программе испытаний:• успешность процедур развертывания;• успешность процедур отката в исходное состояние (если это применимо к системе);

• работу средств журналирования и монито-ринга;

• работу решений по отказоустойчивости;• функциональную работоспособность систе-мы (к функциональному тестированию при-влекаются пользователи системы);

• наличие необходимой документации;• другие аспекты (при необходимости).

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

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

2.5. Опытная эксплуатация и приемочные испытания

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

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



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

Подписанием акта приемки заканчивается проект по внедрению системы. И начинаются этапы эксплуатации и сопровождения.

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

2.7. Разделение ролейКак видно из разделов 2.1-2.6 статьи, в отличие, например, от того же стандарта ГОСТ Р ИСО 12207-1999, работы по сбору и анализу требо-ваний, проектированию, квалификационным испытаниям, вводу в опытную эксплуатацию выполняются не только разработчиками, но и командой эксплуатации.

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

1. Руководитель проекта от ИТ-подразделения назначается, как правило, из числа сотрудни-ков подразделения разработки. В интересах руководителя проекта «двигать работы», не допускать нарушения сроков проекта, «застреваний» на тех или иных участках работ. Эта роль также хорошо накладывает-ся на развитое проектное мышление разра-ботчиков.

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

Слаженная работа руководителя проекта от ИТ-департамента и ответственного за систему

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

3. Выводы

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

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

На практике внедрение данного подхода во многих организациях требует проведения серь-езных организационных изменений:• четкого определения порядка взаимодействия трех сторон — заказчиков, разработчиков и команды эксплуатации (причем правила разработки для разработчиков никто не уста-навливает, определяются только правила сов-местной работы);

• формализации границ между этапами, гарантирующих необходимую верификацию полученных результатов;

• организацию действенного процесса управ-ления изменениями.

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


[1] Alain Abran, James W. Moore, Pierre Bourque, Robert Dupuis, Leonard L. Tripp, «Guide to the Software Engineering Body of Knowledge — 2004 Version», IEEE, 2004, ISBN 0-7695-2330-7.

[2] ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания».

[3] ГОСТ Р ИСО 12207-1999 «Процессы жизненного цикла программных средств».

[4] «ITIL Service Transition», Version 3 edition, Stationery Office, 31.05.2007, ISBN 011331048X.

108www.itsmforum.ru

Часть 3

Рано или поздно любой

долгосрочный проект, связанный

с разработкой программного

обеспечения, разрастается до

необъятных размеров, становясь

трудно управляемым и трудно

прогнозируемым. Но, пожалуй,

самая главная проблема в

том, что руководящий состав

начинает терять контроль над

процессом и часто не имеет

четкого представления о качестве

выпускаемого изделия. Лишенные

ощущения осознания руководством

поставленных задач подчиненные

начинают опираться в своей

работе не на научную базу, а на

вдохновение и душевные порывы.

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

К сожалению, значительная часть разработчиков считает процесс управления конфигурациями неким видом тотального контроля (если не насилия) над собой и с недоверием относят-ся к попыткам его внедрения. Но часто формализованный про-цесс — это не насилие, а благо, облегчающее жизнь разработ-чика, и мы надеемся это объяснить. Мы рассмотрим два под-хода к организации процессов управления конфигурациями и управления изменениями: подход, основанный на Information Technology Infrastructure Library (ITIL), и подход, предлагаемый в IBM Rational Unified Process (RUP).

Проблемы разработки

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

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

Дмитрий Лапыгин Технический специалист департамента программного обеспечения IBM Восточная Европа/Азия с 2005 года. Вопросами разработки ПО занимается с 1994 года. С 1998 года занимался решениями в области программной инженерии с использованием инструментов Rational в компаниях-партнерах Rational Software и IBM. Участвовал в проектах внедрения процессов авто-матизации жизненного цикла программных средств на основе технологий Rational и PVCS.

Управлениеконфигурациейи изменениями:

RUP или ITIL?

Александр НовичковРаботает в области ИТ с 1994 года. Является руководителем отдела консал-тинга и внедрения IBM Rational в компании СМ-Консалт. Участвовал более чем в 20 успешных проектах внедрения IBM Rational. Является сертифициро-ванным специалистом по продуктам IBM Rational. За время работы в кон-салтинге им обучено более 500 специалистов ведущих ИТ-компаний России и СНГ. Связаться с ним можно по адресу [email protected].

О



2. Недостаток контроля. Поскольку програм-мное обеспечение является нематериальным в физическом смысле, его сложно контроли-ровать. Без точной оценки процесса разра-ботки срываются графики выполнения работ и превышаются установленные бюджеты. Сложно оценить объем выполненной и остав-шейся работы.

3. Недостаток трассировки. Неучтенные связи между отдельными объектами или события-ми проекта могут привести к его провалу.

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

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

RUP и ITIL

Чтобы эффективно бороться с проблемами разработки ПО нужно:• использовать хорошо зарекомендовавшую себя на практике методологию;

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

Оба этих критерия применимы как к ITIL (www.itsmf.ru/main. phtml? oblast=itil), так и к RUP (www-130.ibm.com/developerworks/rational/products/rup) — наиболее известным на сегод-няшний день подходам к организации процессов управления конфигурациями и изменениями.

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

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

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

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

Библиотека ITIL представляет собой набор книг по наиболее важным видам деятельности ИТ-подразделений, составленных на основании изучения лучших примеров мирового опыта. Безусловно, ITIL имеет значительно более широ-кий «охват», по сравнению с RUP, поскольку ориентирована на управление ИТ в целом, тогда как RUP изначально ориентировался на разработку ПО. Для наших целей интересны три процесса ITIL: «Управление конфигураци-ей (Configuration Management)», «Управление изменениями (Change Management)», «Управление релизами (Release Management)». Основными чертами ITIL являются: взгляд на деятельность ИТ как на бизнес и процессно-ориентированный подход к управлению ИТ. Все процессы рассматриваются во взаимосвя-зи и большое значение уделяется правильному внедрению процессов.

Обычно участники проектов разработки и сопровождения, принимая решение о внедре-нии процессов управления конфигурациями и изменениями, преследуют следующие цели:• заказчики — организацию портфелей проек-тов разработки и сопровождения ПО, созда-ние систем приемочного тестирования и сопровождения;

• разработчики — организацию коллективной разработки ПО, в том числе распределенной;

• сопровождающие организации — внедрение автоматизированного процесса сопровож-дения;

• службы тестирования — внедрение автомати-зированных процессов сборочного, приемоч-

110www.itsmforum.ru

Часть 3

ного, аттестационного функционального и нагрузочного тестирования.

Динамическая структура RUP состоит из четырех фаз: Inception (Обследование), Elaboration (Технический проект), Construction (Рабочий проект) и Transition (передача в экс-плуатацию) (рис. 1). Фазы могут подразде-ляться на итерации. Переход с фазы на фазу возможен только после выполнения задач фазы и представляет собой контрольную точку (milestone) процесса. Статическая структура RUP состоит из процессов, в которые группиру-ются работы, задачи, артефакты и роли. Они описывают кто, что, как и когда выполняет.

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

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

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

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

С управлением конфигурациями тесно связан процесс управления изменениями, цель которого — контроль над проведением и снижение негативных последствий от измене-ний. Область действия процесса управления изменениями соответствует области действия процесса управления конфигурациями — все изменения фиксируются в CMDB и анализ пред-лагаемых изменений проводится на основании данных из CMDB. Управление изменениями, как и конфигурациями, тесно связано с процессом управления релизами, который занимается кон-тролируемым распространением версий про-граммного и аппаратного обеспечения. Каждый релиз является следствием запроса на изме-нение и включает в себя определенный набор взаимосвязанных конфигурационных элементов (соответствует понятию Baseline в управлении конфигурациями с точки зрения RUP).

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

Отметим, что ITIL содержит рекомендации по внедрению процессов, тогда как RUP вовсе не содержит рекомендаций по своему внед-рению. Но этот недостаток компенсируется значительным количеством публикаций, посвя-щенных внедрению RUP (например, www-128.ibm.com/developerworks/rational/rationaledge).Рис. 1. Фазы и дисциплины в RUP.



Внедрение управления конфигурациями и изменениями

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

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

2. Политика управления конфигурациями. Необходимо определить результаты, ожида-емые от внедрения управления конфигура-циями.

3. Документированность задач и целей управ-ления конфигурациями. Обычный недоста-ток — отсутствие понимания того, для чего все делается.

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

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

6. Элементы конфигурации. Элементы конфи-гурации представляют собой внутренние и внешние сборочные узлы проекта. Они явля-ются окончательным результатом всей рабо-ты, проделанной при реализации управления конфигурациями в организации. Элементы конфигурации управляются средствами автоматизации управления конфигурациями, например, IBM Rational или CVS.

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

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

Эффект от внедрения

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

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

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

На основе нашего опыта можно следую-щим образом оценить общие выгоды от внед-рения процессов управления конфигурациями и изменениями:

Рис. 2. Значимость требований, необходимых для

успешного внедрения.

112www.itsmforum.ru

Часть 3

• прирост производительности (относительно исходного уровня) — 30%;

• возможность для компании планомерно раз-вивать продукт без авралов и срывов сроков проекта;

• налаженное взаимодействие между тести-ровщиками, разработчиками и аналитиками;

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

• прозрачное управление проектом (за счет строгой формализации процессов);

• снижение рисков, связанных с невыполнени-ем проекта в заданный срок с запланирован-ными ресурсами;

• возможность мониторинга текущей загрузки разработчиков (прозрачность процессов и полный контроль) и снижение зависимости от человеческого фактора;

• накопление статистической информации по проектам;

• соответствие процессов разработки и сопро-вождения стандартам качества.

Что выбрать?

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

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

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

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

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

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

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

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

Статья «Управление конфигурацией и изменениями: RUP или ITIL?» впервые была опубликована в журнале «Открытые системы» № 2/2005. Публикуется с разрешения издательства «Открытые сис-темы» с некоторыми сокращениями.


«Внедрение методологии ITSM в образовательные стандарты (ВУЗ)» — этот пункт был записан два года назад как «возможный» в План работы itSMF Россия. Цель выдвижения такой задачи — распространение знаний об ITIL в среде будущих специалистов и преподавателей ВУЗов, включение курсов по ITIL в образовательные программы (на уровне foundation). Сотрудничество с ВУЗами — один из ключевых моментов нашей программы.

Сегодня — это реальность. Расширяется круг наших партнеров. Мы заинтересованы в налаживании долгосроч-ного взаимовыгодного сотрудничества с ВУЗами, способствующего популяризации подходов ITSM в управлении ИТ в России. Руководство ВУЗов, как никто другой, понимает, что профессионалы в области ITSM нужны нашей стране. И мы рады этому сотрудничеству. Проведены совместные мероприятия по тематике ITSM/ITIL с МИРБИС, МЭСИ, МГУ, МИИТ, МИЭМ.

В. Павлов,член управляющего комитета,

руководитель комитета по региональному развитиюи общественным связям

«Библиотека ITIL — важный элемент в управлении IT инфраструктуры компании. Мы развиваем данное направление в рамках программы МВА «IT менеджмент», т. к. пони-маем значение этих знаний для современного IT-руководителя».

Агеев Михаил Евгеньевич,руководитель программы МВА «IT-менеджмент»

Московской международной высшей школы бизнеса МИРБИС

Деятельность IT-специалиста XXI века невозможна без знаний в области управления информационными сервисами и их активного использования в практической работе. Партнерство с Российским ITSM Форумом помогает существенно повысить уровень профессиональных компетенций выпускников Института компьютерных технологий Московского государственного университета экономики, статистики и информатики в области ITIL/ITSM. Швей Владимир Игоревич,

Директор Института компьютерных технологийМосковского государственного университета

экономики, статистики и информатики

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

Зива Светлана Валерьевна,Руководитель программ развития факультета,

Заместитель директора Учебного центрапо информационно-техническому развитию

факультета Вычислительной математики и кибернетикиМосковского государственного университета имени М. В. Ломоносова

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

Вакуленко Сергей Петрович,Профессор, директор Института управления и информационных технологий,

директор Высшей школы управленияМосковского государственного университета путей сообщения

114www.itsmforum.ru

Часть 3

В 2005 году в петербургском

центре программных разработок

корпорации Motorola был запущен

проект построения оптимальной

схемы предоставления ИТ-услуг.

Применение передового опыта

управления ИТ, в частности COBIT

и ITIL, позволило достаточно

быстро и без привлечения

внешних консультантов

реализовать этапы программы

совершенствования ИТ-услуг.

В статье рассказывается об

опыте совместного применения

подходов ITIL v2 и COBIT

(использована версия 3,

актуальная на момент проекта).

COBIT и ITILв управлении ИТ

Николай КрачунДиректор по информационным технологиям компании «ЛЕНТА». Начал заниматься информационными технологиями в агентстве недвижимости «Невский простор» на должности специалиста по ИТ. Затем работал ИТ-менеджером в российско-голландской компании «Строймода», руководителем отдела информатики «Чупа-Чупс Рус». С 2004 по 2007 г. являлся ИТ-менеджером центра разработки ПО компании Motorola. Затем был директором по ИТ в сети магазинов «СантаХаус». Один из учредителей itSMF Russia.

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

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

Причины совершенствования управления ИТ

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

Виталий ФроловНачальник отдела оптимизации ИТ-процессов банка «Санкт-Петербург». Имеет 7-летний опыт работы в области ITSM. С 2001 по 2008 г. работал менеджером управления уровнем ИТ-сервисов и менеджером по информационной безопасности центра разработ-ки ПО компании Motorola.

Ш



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

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

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

4. Стремление к совершенствованию планирования и управления ресур-сами. Рациональная деятельность ИТ-подразделения подразумевает постоянный контроль и оптимизацию затрат.

Два источника

Основными источниками совершенствова-ния процессов ИТ-подразделения стали ITIL (в версии 2) и COBIT (в версии 3). Инструмент COBIT был выбран для контроля деятельности ИТ-подразделения и предоставления отчетности менеджменту компании по метрикам. Прежде всего, этот подход использовался в Motorola для внутреннего ИТ-аудита. Однако COBIT был выбран не только поэтому. Он также служит неоценимым источником структурированной информации по измеримым показателям деятельности ИТ-подразделения (метрикам), характеризующим как продуктивность работы (Key Goal Indicators), так и ее рациональность (Key Performance Indicators). Кроме того, COBIT содержит наиболее полный перечень про-цессов, что помогает стратегически оценить самые важные направления совершенствова-ния деятельности ИТ.

COBIT основан на многих методиках и стан-дартах — ISO 9000, ITIL, SPICE, TickIT, Common

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

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

Существуют и другие модели, на которых можно основываться при внедрении процес-сного подхода в разной степени приближа-ющие идеи ITIL к практической реализации (такие, как HP ITSM Reference Model, Microsoft Operations Framework и иные,), но они имеют ряд ограничений. Так, ITSM Reference Model не является свободно доступной и использует-

ся HP в рамках собственных консалтинговых проектов, однако в нашем случае широко-масштабного привлечения внешних консуль-тантов не предполагалось. Microsoft Operations Framework, одна из составляющих инициативы Microsoft Enterprise Services, фокусируется на эксплуатации информационных систем, пре-имущественно построенных на платформе Microsoft, а ядро ИТ-инфраструктуры Центра Motorola базируется на Sun Solaris.

Основными целями проекта совершенство-вания процессного управления в ИТ-подразде-лении были:• повышение качества предоставляемых ИТ-услуг, их ориентация на бизнес-потребности;

• достижение третьего уровня зрелости по клю-чевым процессам;

• обеспечение успешного прохождения корпо-ративного ИТ-аудита на соответствие требова-ниям внутренних стандартов Motorola;

• повышение эффективности работы ИТ-под-разделения;

• внедрение системы контроля качества и предоставление менеджменту метрической отчетности по процессам.

Много времени было потрачено на формули-

рование единого понимания и языка общения

в ИТ-команде. Без использования общей тер-

минологии уходило бы гораздо больше време-

ни на согласование межпроцессного взаимо-

действия

116www.itsmforum.ru

Часть 3

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

Опыт совместного применения методик

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

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

Мы выбрали пять из 34 процессов COBIT, Document Management, Request Management, Security Management, Change Management и Service Level Management, на которых было решено сосредоточить усилия. В приложении

к нашей компании не все они в точности соответствовали процессам, описанным в COBIT и ITIL. Так, сферы действия Document Management и Develop and Maintain Procedures у нас полностью перекрывались, причем процесс Document Management являл-ся составной частью процесса Configuration Management из ITIL. С другой стороны, актив-ность процесса Educate and Train Users из COBIT у нас распределена между Request Management и Security Management. Однако и COBIT, и ITIL вполне допускают подобную адап-тацию к специфике конкретной организации.

Для определения измеримых результатов первого этапа по каждому из процессов были сформулированы цели аудита:• определить уровень документированности

(требуется только высокоуровневое описание процесса либо необходим полный набор рабочих инструкций);

• определить собираемые метрики (вводить ли их на первом этапе, и если да, то какие и сколько);

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

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

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

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

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

COBIT

COBIT — набор из шести публикаций, созданный орга-низациями ISACA и ITGI. Структурированность проявляет-ся в COBIT очень сильно: четыре базовые группы (доме-на) содержат 34 процесса, которые управляются 318 сферами контроля. COBIT больше предназначен не для управления ИТ-инфраструктурой, а для аудита инфор-мационных систем компаний, поскольку разработан в основном сотрудниками консалтинговых фирм. При этом такие его элементы, как модель зрелости процес-сов, инструмент проведения аудита и набор инструмен-тов внедрения (Implementation Tool Set), могут оказать неоценимую помощь при внедрении процессного подхода к управлению ИТ-инфраструктурой. Проект, описанный в статье, основан на версии 3.



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

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

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

Дальнейшие шаги

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

Тем не менее, результат работы признан в целом успешным.

Организации, начинающие внедрять про-цессный подход, делают первый шаг на пути постоянного улучшения. Для того чтобы плано-мерно продолжать эту деятельность, необхо-димо составить программу постоянного улуч-шения услуг (Continuous Service Improvement Programme) или план повышения качества услуг (Service Quality Plan), а затем двигаться по шагам:• проектирование или реинжиниринг процесса и обеспечение готовности команды к изме-нению;

• измерение продуктивности и рациональ-ности;

• оценка и выявление слабых мест;• принятие решений о наиболее эффективных изменениях.

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

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

Впервые статья Николая Крачуна была опубликована в журнале «Открытые системы» в № 1/2005. Републикуется с разрешения издательства «Открытые системы» (www.osp.ru) с некоторыми исправлениями.

Крайне важным оказалось не только согласо-

ванно задать целевые уровни зрелости взаи-

мосвязанных процессов (чтобы зрелый про-

цесс не буксовал из-за недостаточно четкого

взаимодействия с незрелым), но и составить

проектный план с указанием временны' х эта-

пов по каждому из процессов

118www.itsmforum.ru

Часть 3

Многие ИТ-руководители не могут дать ответа на вопросы: внедрен ли у нас ITSM?

Что он дал компании в целом? И в чем вообще заключается структурированное

управление ИТ? Модели зрелости процессов и организаций (в том числе

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

и не дает руководству компаний ответа на вопрос: что зрелость ИТ-департаментов

приносит организации? Один из возможных путей — использование практики

управления рисками, связанными с ИТ.

Федор БайновскийВозглавляет управление ИТ-аудита в компании IT Expert. Обладает 13-летним опытом управления и контроля в области ИТ. C 1997 по 2003 г. осуществлял руководство проектами по созданию и внедрению слож-ных территориально-распределенных ИТ-систем, автоматизирующих функции Банка России по надзору и лицензированию деятельности кредитных организаций. В 2004 г. возглавил Управление аудита инфор-мационных систем Банка России и сформировал основанную на меж-дународных подходах систему информационного аудита подразделе-ний Банка России.

Управление ИТ: нужен ли новый шаг?

Максим ГригорьевВозглавляет направление ИТ-сервисов и внешнего управления ИТ-про-цессами компании IT Expert. С 1994 по 2005 г. являлся начальником сис-темного администрирования в Главном управлении Банка России по Тульской области. Проводил сервисную трансформацию ИТ-подразде-ления, руководил инновационными проектами. Неоднократно успешно руководил проектами по реорганизации управления ИТ, построению служб поддержки пользователей, проектированию и реализации сер-висного подхода и сервисной модели организации.

Михаил ПотоцкийОснователь и председатель совета директоров компании IT Expert, один из признанных авторитетов в области управления ИТ в России. Профессиональную карьеру начал в компании Hewlett-Packard Россия, где руководил отделом программного обеспечения. С момента созда-ния IT Expert в 2002 г. активно участвует в ITSM проектах компании, про-водит тренинги по ITIL/ITSM. Обладает российскими и международными сертификатами по ИТ-сервис-менеджменту и корпоративному управ-лению. Входит в инициативную группу itSMF России.



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

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

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

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

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

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

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

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

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

Как продвинуться на шаг вперед?

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

Во-первых, оценка ИТ-управления и конт-роль соответствия нормам и требованиям, как

К

Оценка ИТ-управления и контроль соответст-

вия нормам и требованиям является важным

дополнением к подходам ITSM, позволяющим

сделать развитие управляемым

120www.itsmforum.ru

Часть 3

внутренним, так со временем, возможно, и внешним. Этот вопрос является важным допол-нением к подходам ITSM, позволяющим сде-лать развитие управляемым.

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

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

Проблемы оценки и контроля соответствия

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

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

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

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

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

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

1 Эта модель изложена в книгах ITIL, начиная со второй версии. Она использует широко известную модель зрелости процессов Capability Maturity Model (CMM), предложенную в 1987 году и неоднократно обновляемую позднее Институтом программной инженерии (Software Engineering Institute), являющегося частью Университета Карнеги-Меллона.

Модель зрелости не дает руководству ком-

паний ответа на вопрос: что зрелость ИТ-де-

партаментов приносит организации? В ре-

зультате реакция руководства достаточно

очевидна — на словах признание необходи-

мости движения, но на деле весьма сдержан-

ная поддержка проектов



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

Практика управления рисками

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

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

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

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

бенно если в данный контур управления вовле-чен внутренний корпоративный аудит.

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

При этом оценка может не ограничиваться классическими ITSM-процессами, а должна включать как минимум процессы управле-

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

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

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

Идея оценки операционных рисков, связан-

ных с ИТ, является логической «надстройкой»

над COBIT, позволяющей интерпретировать

язык зрелости процессов для бизнес-руко-

водства компаний, не отрицая его

122www.itsmforum.ru

Часть 3

интегрированная среда, показывающая взаи-мосвязь этих широко используемых подходов и интерпретирующая результат на языке, доступном высшему руководству компании.

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

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

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

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

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

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

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

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

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

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

Статья Федора Байновского, Максима Григорьева и Михаила Потоцкого «Управление ИТ: нужен ли новый шаг» была впервые опубликована в журнале «Открытые системы» № 5/2009. Републикуется с разрешения издательства «Открытые системы». Все права сохранены.

Используя подход «сверху вниз», можно

одновременно решить две смежные зада-

чи: провести рискориентированную оценку

ИТ-деятельности и сформировать контроль-

ную среду для последующего управления и

контроля соответствия

ФОРУМ — ЭТО МЫ! ПРИСОЕДИНЯЙТЕСЬ!

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

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

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

Ведущие российские системные интеграторы и IT-консультанты с нами, потому что:

мы — не конкурентная среда, а сообщество успешных профессио налов;

активность специалистов в форуме в качестве экспертов — пока-затель высокого уровня подготовки кадров направления ITSM в компании;

мы предлагаем уникальную возможность целевого позициониро-вания услуг.

Для производителя оборудования и ПО членство в форуме — это: возможность проведения вендорских тематических мероприятий на площадках форума с гарантированно целевой аудиторией;

уникальная возможность целевого позиционирования продуктов и услуг;

участие в подготовке и издании русскоязычных материалов по тематике ITSM.

Специалистам в области ITSM членство в форуме открывает воз-можности:

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

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

эксклюзивные лекции и семинары для студентов последних кур-сов профильных факультетов;

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

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

По вопросам вступления в форум и участия в наших проектах просим обращаться по электронному адресу [email protected] или напрямую к Елене Карабановой, административному директору itSMF Россия ([email protected])

124www.itsmforum.ru

Часть 3

Какова реальная практика

услуг в российских компаниях?

Для ответа на этот вопрос

осенью 2008 года журнал

Intelligent Enterprise совместно

с российским сообществом

профессионалов ITSM

(itSMF-Russia, www.itsmforum.ru)

провел исследование.

Мы ставили перед собой цель

как можно яснее обрисовать

картину управления ИТ.

При этом за методологическую

и терминологическую основу

был взят ITIL v2. То есть, задавая

все вопросы, мы смотрели

сквозь призму подходов

ITIL v2. Но выводы, которые

следуют из этого исследования,

выходят далеко за рамки ITIL.

Н

Исследование практики управления ИТ-услугами в российских компаниях

Управление ИТ-услугами

в России

124www.itsmforum.ru

Константин ЗиминГлавный редактор журнала «Intelligent Enterprise».

В ИТ-журналистике работает более 10 лет. Автор серии исследований:

«Практика использования ИТ» 2007, 2008, 2009.

аправления исследования были следующие.1. Представления и точки зрения ИТ-директоров о ценности ITSM для бизнеса и управления ИТ, цели и предпосылки построе-ния управления ИТ на основе сервисной модели.

2. Реальная практика управления ИТ-услугами на российских предприятиях (факты и их оценка), по двум разрезам:

• фактическая последовательность внедрения процессов ITSM;• оценка существующего уровня зрелости внедренных про-цессов (в данной статье об этом мы говорить не будем).

Для разработки методологии опроса и вопросов анкеты была создана инициативная группа, в которую вошли эксперты ITSM-форума. Надо сказать, что время проведения исследования сов-пало с началом кризиса — заполненные анкеты были собраны в октябре — ноябре 2008 года. Однако поскольку вопросы, которые мы исследовали, были связаны в основном со стратегическим уровнем управления ИТ, то, на наш взгляд, особенности, связан-ные с кризисными временами, не оказали серьезного влияния на ответы респондентов.

Нам удалось собрать 145 анкет, заполненных ИТ-директорами и ИТ-менеджерами из разных регионов России. Активное участие в исследовании приняли клубы ИТ-директоров Санкт-Петербурга, Урала, Нижнего Новгорода и Юга России, за что редакция выра-жает им благодарность.

Портрет респондентов

Немного о респондентах, которые приняли участие в исследо-вании. Среди наших респондентов оказалось довольно много небольших компаний, с числом сотрудников менее 500 (40%), с количеством пользователей информационных систем до 500 (55%) и ИТ-отделом с менее чем 15 сотрудниками (38%). Заметим, что сама по себе такая доля небольших компаний нормальна — на рынке их еще больше (по количеству).

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



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

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

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

Цели движения к сервисной модели со стороны ИТ

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

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

Лишь 2% респондентов сказали, что использо-вание подходов ITSM не даст никакого эффек-та. Остальные уверены в ее эффективности.

Согласно результатам опроса, основными целями использования сервисной модели ИТ

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

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

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

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

Рис. 1. Цели движения к сервисной модели

со стороны ИТ.

126www.itsmforum.ru

Часть 3

лено лишних ИТ-активов почти на миллион дол-ларов. Однако это пример западный. Подобные явления практически неизвестны российским ИТ-директорам и ИТ-менеджерам. Российских приме ров нет.

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

так не мала. Но, как мы сказали выше, крупных ИТ-департаментов среди наших респондентов не много (13% — более 150 человек). Это, по всей видимости, и привело к таким ответам.

Однако надо отметить, что в целом задачи внедрения ITIL/ITSM оцениваются российскими ИТ-директорами и ИТ-менеджерами вполне зрело.

Типовые цели перехода на сервисную модель управления ИТ со стороны ИТ

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

Результаты этой группировки подтверждают выводы предыдущего раздела. В целом «вне-шние» вопросы взаимодействия с бизнесом служат преимущественной целью ITSM-проек-тов примерно так же часто, как и внутренние (повышение качества, гибкости и т. д.). Треть опрошенных ИТ-директоров и ИТ-менеджеров (35%) применяют или планируют применять модель ITSM преимущественно с целью постро-ения отношений с высшим руководством. Почти стольких же (41%) волнуют вопросы внутреннего характера — преодоление сложностей управ-ления ИТ. И лишь 4% опрошенных видят в ITIL/ITSM преимущественно возможность добиться эконо-мии затрат на ИТ.

Предпосылки движения к ITSM со стороны бизнеса

Следующий вопрос исследования — предпо-сылки движения в сторону ITSM со стороны биз-неса. Поскольку мы опрашивали ИТ-директоров и ИТ-менеджеров, то вопрос поставили следу-ющим образом: «Связано ли ваше движение к сервисной модели с какими-либо тенденциями

ОСНОВНЫЕ ВЫВОДЫ ИССЛЕДОВАНИЯ

1. Цели и ожидания от использования модели

ИТ-услуг и реальная практика их применения

значительно расходятся.

2. Вряд ли можно говорить о том, что российс-

кие компании при построении управления ИТ

опираются только на ITIL/ITSM. Скорее всего,

мы имеем дело с несколько другими моделя-

ми управления ИТ, и это вполне нормально.

3. В некоторых ответах прослеживается непони-

мание основ ITIL/ITSM.

РЕКОМЕНДАЦИИ

1. Четкое понимание целей постановки процес-

сов управления ИТ-услугами, с точки зрения

как ИТ, так и бизнеса.

2. Внимательный анализ на соответствие этим

целям как набора внедряемых процессов, так

и их последовательности.

3. Отклонение от рекомендаций ITIL/ITSM долж-

но четко осознаваться и опираться на серьез-

ные доводы.

4. Изучение подходов, предлагаемых ITIL/ITSM,

чтение литературы и обучение.

Рис. 2. Типовые наборы целей перехода на сервисную

модель управления ИТ.



и направлениями в области управления пред-приятием?» Мы рассчитывали выяснить, скорре-лирует ли движение в сторону ITSM со стороны ИТ с направлениями улучшения управления в компании в целом. Мы предложили несколько таких направлений (рис. 3).

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

Лишь 10% считают, что движение к сервис-ной модели управления ИТ никак не связано с общим развитием бизнеса. То есть вполне оче-видно, что большинство респондентов считает необходимым связывать ITSM с соответствующи-ми тенденциями в развитии управления пред-приятием в целом.

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

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

Каждый четвертый ИТ-директор и ИТ-менед-жер (26%) отметил движение к процессной модели управления предприятием в целом, что вполне закономерно, но несколько меньше, чем мы ожидали, ведь связь здесь самая прямая.

Видимо, это происходит потому, что процессная модель управления предприятием в России встречается все же еще достаточно редко.

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

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

Типовые предпосылки движения к ITSM со стороны бизнеса

Так как при ответе на вопрос о предпосылках к переходу ИТ-отдела на сервисную модель со

Рис. 3. Предпосылки движения к ITSM со стороны

бизнеса.

128www.itsmforum.ru

Часть 3

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

Результаты этой группировки подтверждают выводы предыдущего раздела. С определенной долей условности можно считать, что об ITSM-проектах можно говорить с бизнесом в трех аспектах:• сокращение затрат;• контроль рисков;• повышение прибыли.

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

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

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

Порядок постановки процессов ITSM

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

Первый аспект — порядок постановки и автоматизации процессов управления ИТ-сервисами. Ответы на прямой вопрос о последовательности приведены на рис. 5. По вертикали на ней показаны те процес-

Рис. 5. Порядок внедрения процессов управления

сервисами.

Рис. 4. Типовые наборы предпосылок движения к ITSM

со стороны бизнеса.



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

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

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

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

Совершенно с другой стороны начинают компании, которые на первом-втором этапах ITSM-проекта поставили процесс управления уровнем обслуживания. Даже если процесс управления уровнем обслуживания в этом слу-чае поставлен не полностью в соответствии с практиками ITIL (например, только каталог услуг), эти компании реально начинают с одной из самых проблемных областей — пост-роения взаимоотношений с бизнесом. Но таких компаний в 10 раз меньше, чем тех, кто начина-ет с процессов Service Support.

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

Типовые пути постановки процессов ITSM

Как и в предыдущих случаях, в этом вопросе мы постарались из всего набора ответов выделить несколько типовых путей продвижения в области ITSM (рис. 6). Всего их получилось пять.

Эта группировка подтверждает и делает более наглядными те выводы, которые сдела-ны выше. Более половины опрошенных (43% + 9%) на первых двух-трех этапах ITSM-проекта ставили процессы из области Service Support. А процессы Service Delivery либо не ставились вовсе (как правило), либо шли позже (такие ком-пании в нашей выборке есть, но их очень мало).

Следующая группа (24%) также включает в себя компании, которые начинали с управле-ния инцидентами, но на втором-третьем этапе внедряли управление уровнем услуг (либо другие процессы Service Delivery). Они почти

Рис. 6. Типовые наборы путей автоматизации

процессов.

130www.itsmforum.ru

Часть 3

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

Соответствие реальной практики и целей

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

Аналогичным образом мы исследовали вза-имосвязь типовых наборов путей автоматизации ИТ-процессов и предпосылок движения к ITSM со стороны бизнеса. На рис. 8 показаны типо-вые наборы автоматизации процессов (ось Y) и предпосылки к движению к ITSM со стороны бизнеса (ось X), а диаметр кругов показывает относительное количество компаний, которые имеют соответствующие типовые пути и группы предпосылок.

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

При взгляде на эти диаграммы возникают сле-дующие вопросы:• как можно построить взаимоотношения с руководством, занимаясь только процессами из области Service Support поддержки услуг или вообще только несколькими процесса-ми: управлением инцидентами и конфигура-циями?

• как соответствуют цели преодоления внут-ренних сложностей в управлении ИТ и поста-новкой в первую очередь управления уровня обслуживания и каталога сервисов?

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

Рис. 7. Взаимосвязь типовых наборов автоматизации

процессов и целей движения к ITSM со стороны ИТ.

Рис. 8. Взаимосвязь типовых наборов путей

автоматизации процессов и предпосылок к ITSM со

стороны бизнеса.



Варианты объяснения несоответствий путей и целей

Этим несоответствиям, на наш взгляд, может существовать три объяснения.

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

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

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

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

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

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

Во-первых, таких компаний очень много. Из исследования можно сделать вывод, что лишь 20—30% компаний движутся к ITSM вполне соглас-но с рекомендациями ITIL. Назвать столь боль-шое количество компаний, причем компаний успешных, давно работающих и построивших весьма немаленькие информационные систе-мы, «недозрелыми» язык не поворачивается.

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

***

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

В мире существует большое разнообра-

зие форм управления компаниями и пред-

приятиями

Статья впервые опубликована в журнале Intelligent Enterprise № 17–18/2009. Публикуется с разреше-ния издательства «СК Пресс».

132www.itsmforum.ru

Часть 3

ITIL шествует по миру ИТ уже

почти десять лет, вышла его

третья версия, сформировалась

целая сеть профессиональных

сообществ. И тем не менее

масштаб реального применения

ITIL в бизнесе пока невелик.

По данным Gartner Group [1]

лишь 20% компаний крупного

бизнеса используют ITIL и 29%

планируют его использовать.

В среднем бизнесе эти цифры

еще меньше: соответственно

7 и 19%. Что же сдерживает

активное распространение ITIL?

Наверное, было бы сильным

упрощением связывать это с

недостаточной квалификацией

консультантов, слабой

маркетинговой активностью

профессионального

сообщества или тотальной

незрелостью бизнеса. Похоже,

у данного явления есть более

глубокие причины.

ITSM — модель партнерства

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

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

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

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

Владимир АнаньинНа ИТ рынке с 1993 г. С 2007 г. — независимый консультант. Занимается ИТ-консалтингом в следующих областях: корпо-ративные ИТ-стратегии, управление ИТ-проектами и програм-мами, управление ИТ-сервисом, eправление инновациями. С 2004 г. — преподаватель в MBA/MBI бизнес школах для CEO, CIO, CFO и руководителей ИТ проектов. Член совета форума itSMF Russia. С ним можно связаться по адресу [email protected]

Границыприменения сервиса.

ITIL и ИТ�архитектуры

www.itsmforum.ru



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

Типы архитектур КИС

На сегодняшний день во всем мире существуют три основных типа архитектур КИС [2]. Gartner Group выделяет их больше, но доминирующими являются только три: «лоскутное одеяло», «силь-ная интеграция» и «слабая интеграция». Данные типы представляют собой точки зрения прежде всего бизнес-пользователей, а уж потом ИТ-специалиста.

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

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

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

ся их слепком. «Лоскутное одеяло» похоже на мозаику: глаз видит осколки, а картину достраи-вает воображение.

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

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

В этом случае требования к исполнителям на операционном уровне снова невысоки, так как система по сути выстраивает конвейер, к которому достаточно добавить инструкции поль-зователей. Пользователь здесь — это «прослой-ка между инструкцией и экраном». А вот на управленческом уровне, напротив, и архитектор системы, и ключевой специалист, ведущий биз-нес-модель, должны быть людьми высочайшей квалификации. Они, и только они, обладают «тай-ным знанием» об устройстве системы и связях модели бизнес-процессов. Именно в серьезной зависимости от знающих людей заключена «ахил-лесова пята» подобных архитектур. Многие ERP-проекты потерпели неудачу как раз потому, что таких людей со стороны бизнеса не было или их не удалось удержать по окончании работ. Кроме того, полученная модель системы должна быть стабильна, потому что если при сильной интегра-ции вы начнете менять бизнес-процессы, то это выльется в бесконечную перенастройку. Легко перенастраивать систему без данных. Но когда система проработала хотя бы полгода и «оброс-ла» учетными данными, то перенастройки неиз-бежно будут сопровождаться их потерей.

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

Идеология управления ИТ�сервисами

построена на модели партнерства ИТ�службы

и бизнеса, когда обе стороны

договариваются друг с другом

134www.itsmforum.ru

Часть 3

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

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

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

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

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

ники, и у них появляется право выбора.

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

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

Уже появились целые направления, которые описывают происходящее в компании не в тер-минах бизнес-процессов, а в виде системы биз-нес-правил, отличающихся от процессов тем, что описывают жизнь предприятия не по принци-пу «делать так и только так», а по прин ципу огра-ничения «разрешено все, что не запрещено». Это совершенно другой подход к организации бизне-са. В качестве типичного примера бизнес-правил можно привести законодательство государства или учетную политику предприятия. В области ИТ и управления начали появляться языки описания бизнес-правил. World Wide Web Consortium (W3C)

В каких задачах и при каких условиях

бизнес и ИТ�служба готовы перейти от

функциональных обязанностей к партнерс-

ким соглашениям? Опыт показывает, что это

возможно, но далеко не всегда

Таблица. Сценарии отношений между ИТ�службой и бизнесом.

Готов ли бизнес к партнерству с ИТ-службой

Cильная интеграция (пример — ERP-система)

Слабая интеграция (пример — ECM-система)

«Лоскутное одеяло» (пример — сеть АРМ)

Нет (функциональная организация)

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

Архитектура неустойчива и деградирует к «лоскутному одеялу», ИТ служба — «пожарная команда»

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

Да (ITSM) ИТ-служба — «центр компетенции», наем команды профессионалов. Каталог сервисов состоит из одного сервиса — доступ к ERP-системе. Устойчив только вариант аутстаффинга

ИТ-служба — «сервисный центр». Полноценный ITSM. ИТ-сервис — это сервис бизнес-приложения. Возможен аутсорсинг. Идеально соответствует ITIL

ИТ-служба — «сервисный центр». Полноценный ITSM. ИТ-сервис — это отдельное бизнес-приложение. Возможен аутсорсинг. Идеально соответствует ITIL



уже содержит стандарты таких языков [3]. Язык Business Process Executive Language (BPEL) как раз позволяет на очень глубоком уровне детализации описывать бизнес-правила и бизнес-процессы. При слабой интеграции реальные траектории процессов в большей степени зависят не от зара-нее заданных маршрутов, а от происходящих в бизнесе событий, которые отражены в данных. Типичным примером бизнес-приложений, осно-ванных на этой архитектуре, являются системы класса Enterprise Content Management (ECM). Они ориентированы на управление, например, документами, которое отталкивает-ся не столько от бизнес-процессов их движения, сколько от содержания самих документов.

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

Реальные архитектуры

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

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

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

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

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

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

Применение ИТ�сервисов в рамках разных архитектур

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

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

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

Возможность построения ИТ�сервисов сильно

зависит от тех архитектурных решений КИС, к

которым стремится сама ИТ�служба

136www.itsmforum.ru

Часть 3

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

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

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

сворачивается в один сервис — доступ к интег-рированному приложению. В третьем сценарии 80% инцидентов, связанных с КИС, являются уни-кальными, такими, которые может понять только небольшая группа специалистов. В то время как ITIL предполагает, что 60 — 70% инцидентов должно разрешаться на уровне Service Desk. Это также цена сложности. Именно в сценарии № 4 — сервисного центра — ИТ-сервисы хоро-шо выносятся на аутсорсинг.


Представленный анализ показывает, что возмож-ность построения ИТ-сервисов сильно зависит, во-первых, от желания бизнеса выстраивать партнерские отношения со своими подраз-делениями, в том числе и с ИТ-службой, а во-вторых, от тех архитектурных решений КИС, к которым стремится сама ИТ-служба. В каждом бизнесе реальная архитектура КИС представля-ет собой уникальный симбиоз различных типов архитектур, который оказывается чрезвычайно чувствительным к изменениям самого бизне-са и статуса его ИТ-службы. В этом случае построение отношений между ИТ-службой и бизнесом также будет синтезом различных сценариев. Поэтому превращение функций ИТ-службы в ИТ-сервисы — процесс не быстрый, а иногда и обратимый. Видимо, с этим связа-ны и масштабы использования ИТ-сервисов, приведенные Gartner Group [1]. Ограничения в применении — это свойство любой практически значимой методологии. Если мы не понимаем ее ограничений, значит, мы не понимаем, как эффективно ее использовать. Универсальны только неработающие методологии.

Задачу разработки каталога ИТ-сервисов сле-дует рассматривать в контексте всей ИТ-стра-тегии бизнеса, которая должна анализировать долгосрочные тенденции изменения самого биз-неса. Особенно остро проблема ИТ-сервисов возникает с появлением у бизнеса планов аут-сорсинга. На аутсорсинг можно вынести только сервисы. Многочисленные попытки «вытолкнуть» на аутсорсинг свою ИТ-службу, назвав их функ-циональные обязанности ИТ-сервисами, всегда заканчивались серьезными проблемами для бизнеса [3]. Представленный анализ показывает также, что вывод на аутсорсинг — процесс пос-тепенный и, возможно, обратимый.

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

Статья была впервые опубликована в журнале Intelligent Enterprise № 2/2008. Публикуется с раз-решения издательства «СК Пресс».


1. Holmstrom Eija. IT Service Manage ment — best practices / Presenta tion in Moscow. itSMF Russia, 25.04.2007.

2. Ананьин В. И. Формирование архитектуры корпора-тивной информационной системы путем естествен-ного отбора // Intelligent Enterprise, 2006, № 17.

3. Хейвуд Д. Б. Аутсорсинг. В поисках конкурентных пре-имуществ. Москва — Санкт-Петербург — Киев, ИД «Вильямс», 2004.

BMC Software получила первый официальный сертификат соответствия ITIL

в сфере Программного Обеспечения

В мае 2009 года компания BMC Software добилась получения первого сертификата «ITIL® Process Compliant». Данная награда еще раз подтверждает уверенность клиентов BMC Software в том, что их инвестиции ведут к улучшению и повышению эффективности ИТ процессов в полном соответствии со стандартами и лучшими практиками ITIL (Information Technology Infrastructure Library).

По словам Шерон Тэйлор, главного архитектора и контролера ITIL v3: «В нынешней экономической среде, ITIL процессы и решения Business Service Managements (Управление бизнес-услугами), такие как решения BMC, являются главным приоритетом для бизнеса. Они нацелены на получение наивысшего результата, одновременно снижая затраты...»

BMC Remedy IT Service Management Suite — платформа, которая включает в себя следующие модули:

BMC Remedy Service Desk Application (автоматизация процессов Incident и Problem Management)BMC Remedy Asset Management Application (автоматизация процессов Asset и Configuration Management)BMC Remedy Change Management Application (автоматизация процессов Change и Release Management)BMC Service Level Management BMC Service Request Management (портал самообслуживания пользователей, автоматизация процесса Request Management)BMC Project and Portfolio Management (автоматизация процесса управления проектами и портфелями проектов)BMC Vendor Relationship Management (автоматизация процесса взаимоотношений с поставщиками услуг и оборудования)BMC Remedy Knowledge Management (управление знаниями)BMC Analytics for BSM (система отчетности и аналитики)BMC Dashboards for BSM (система on-line отчетности)BMC Remedy AR System Server (платформа, на которой написаны и в среде которой работают приложения Remedy)BMC Atrium CMDBBMC Atrium Service Catalog (Каталог сервисов)BMC Atrium Product Catalog (Каталог типов оборудования и ПО)BMC Atrium Impact Simulator (моделирование влияния сбоев\остановок в инфраструктуре на бизнес сервисы)BMC Service Management Process Model (средство документирования и публикации регламентной документации, включающее в себя готовые регламенты для 11 процессов)

Более подробную информацию можно получить на сайте www.bmc.com или обратившись в московский офис компании: 115035, Москва, Садовническая ул., 82/2 тел.: +7 495 225 9384; e-mail: [email protected]

Ал

ьм

ан

ах

ITS

M2010

itsm 2010 light

Documents