Овладевая ITIL. Скептическое руководство для ответственных лиц

Овладевая ITIL® Скептическое руководство для ответственных лиц

Роб Ингланд (ИТ-Скептик)

Перевод: Роман Журавлёв Редактор: Олег Скрынник Дизайн обложки: Евгений Шилов Ингланд, Р. Овладевая ITIL / Роб Ингланд; Пер. с англ. - М.: Лайвбук, 2011. - 200 с. ISBN 978-5-904584-13-9 © Two Hills Ltd, 2009 [email protected] www.twohills.co.nz © Издание на русском языке, перевод, оформление ООО «Клеверикс», 2011 www.cleverics.ru Поддержка, распространение, сообщество читателей и практиков - портал Real ITSM www.realitsm.ru Издательство LiveBook. www.livebooks.ru Все права защищены. Никакая часть этой публикации не может воспроизводиться, сохраняться, копироваться и распространяться какими бы то ни было средствами - электронными, механическими, фотокопированием и любыми иными - без предварительного письменного разрешения автора или правообладателя. Эта книга не может быть продана, выдана или иным способом распространена в любой форме, отличной от оригинального оформления, без предварительного разрешения автора или правообладателя. ITIL® - зарегистрированная торговая марка UK Office of Government Commerce (OGC). Аббревиатура ITIL® зарегистрирована U.S. Patent and Trademark Office. Цель этой книги - предоставить читателям комментарии автора относительно ITIL® как явления в отрасли ИТ. Эта книга не является частью библиотеки IT Infrastructure Library® и никак с ней не связана. Эта книга и её автор никак не связаны с OGC или какой-либо другой организацией. Несмотря на то, что содержание книги прошло тщательную подготовку, автор, издатель и переводчик не несут никакой ответственности за возможный ущерб, понесенный кем-либо вследствие ошибок или неточностей в книге.

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

Посвящается Арту Джейкобсу, человеку, давшему зелёный свет в бизнесе этому парню.

Сообщество овладевающих ITIL Англоязычные читатели этой книги объединились в сообщество на сайте www.itskeptic.org/owningitil. Там можно найти: • дополнительные материалы; • дискуссии и обсуждения; • обновления и исправления текста книги. Русскоязычные читатели могут обсудить вопросы, поднимаемые в этой книге, на портале Real ITSM (www.realitsm.ru). О рекомендациях По тексту книги щедро разбросаны многочисленные рекомендации. Эти рекомендации также обсуждаются на сайте www.itskeptic.org/owningitil, где предполагается их критика, анализ и развитие. Рекомендации в книге даются исключительно в информационных целях и не должны восприниматься как профессиональные консультации для каждого конкретного случая. Автор, переводчики или издательство не несут никакой ответственности за возможные последствия следования рекомендациям. Мы также не обещаем, что от них будет польза.

2

Содержание Содержание ........................................................................................................................................................ 3 Предисловие....................................................................................................................................................... 4 Владея Овладевая ITIL ...................................................................................................................................... 4 Предисловие к русскому изданию ................................................................................................................ 4 Комментарии для руководства .......................................................................................................................... 5 Об ITIL ............................................................................................................................................................... 6 Что такое ITIL................................................................................................................................................ 6 Книги ITIL ..................................................................................................................................................... 8 Движение ITIL ............................................................................................................................................. 11 Индустрия ITIL ............................................................................................................................................ 13 Мыльный пузырь ITIL................................................................................................................................. 15 Управление услугами .................................................................................................................................. 17 Альтернативы ITIL ...................................................................................................................................... 18 Будущее ITIL ............................................................................................................................................... 22 Чего надо остерегаться .................................................................................................................................... 22 Лучшие практики, данные свыше ............................................................................................................... 22 Культ ITIL .................................................................................................................................................... 23 Потому что все делают это.......................................................................................................................... 24 Не ждите доказательств............................................................................................................................... 26 Не надо «внедрять ITIL» ............................................................................................................................. 29 Измерение ITIL при помощи ITIL .............................................................................................................. 30 Не надо чинить то, что работает ................................................................................................................. 31 CMDB не бывает ......................................................................................................................................... 32 Референтные площадки ............................................................................................................................... 34 Совместимость с другими методологиями................................................................................................. 35 Преимущества ITIL ..................................................................................................................................... 35 Забавные расчеты эффективности .............................................................................................................. 35 ASP или ISP ................................................................................................................................................. 36 Чего ждать от ITIL ........................................................................................................................................... 37 Изменения культуры ................................................................................................................................... 38 Возврат инвестиций..................................................................................................................................... 39 Артефакты ................................................................................................................................................... 40 Метрики ....................................................................................................................................................... 41 Как добиться успеха ........................................................................................................................................ 41 Не делайте этого .......................................................................................................................................... 42 Управляйте ITIL- трансформацией как проектом ...................................................................................... 43 Люди Процессы Технологии ....................................................................................................................... 44 Изменения культуры (опять)....................................................................................................................... 45 Приверженность руководства ..................................................................................................................... 47 Ресурсы ........................................................................................................................................................ 48 ITIL - подходу а не проект .......................................................................................................................... 48 Интегрируйте ............................................................................................................................................... 49 ITIL2 или ITIL3............................................................................................................................................ 50 Каталог услуг - как можно раньше ............................................................................................................. 52 Ограничьте управление конфигурациями .................................................................................................. 53 Инструментарий .............................................................................................................................................. 55 Они все работают ........................................................................................................................................ 55 Процессы диктуют требования ................................................................................................................... 55 Соответствие систем ITIL ........................................................................................................................... 57 Услуги к вашим продуктам ......................................................................................................................... 59 Какие нужны инструменты? ....................................................................................................................... 60 ИТ - тоже заказчик....................................................................................................................................... 61 Заключение ...................................................................................................................................................... 62 14 вопросов про предложение о внедрении ITIL............................................................................................ 62 14 вопросов по ходу ITIL-проекта .................................................................................................................. 63 14 вопросов перед закрытием ITIL- проекта .................................................................................................. 64 14 вопросов о жизни в ITIL-среде ................................................................................................................... 64

3

Предисловие Кое-кто скажет, что это довольно неблагодарно с моей стороны - кусать руку, которая меня кормит. ITIL можно было назвать основным источником моих доходов на протяжении многих лет, да и сейчас этот источник время от времени подпитывает мой счёт поступлениями за консалтинг. Я отвечу на это, что последовательному скептику надлежит выявлять несуразицы во всём, что его окружает, и профессиональная среда не может быть исключением. Сейчас, когда ITIL является стандартом де-факто в области операционного управления ИТ, пришло время непредвзято проанализировать достоинства и недостатки этого подхода. В мире ITIL пока ещё сезон «весна-лето». В этой книге предпринята попытка уравновесить тепло и беззаботный оптимизм, свойственные этому времени, ледяным ветром скептицизма в сочетании с проверенным средством оценки - здравым смыслом. Я хотел бы ещё многое добавить, но предпочитаю оставить вас наедине с собственными мыслями и выводами. Должен предупредить, что некоторые тезисы в книге повторяются дважды. Причин тому две: во-первых, чтобы подчеркнуть и усилить их; во-вторых, потому что не все прочтут книгу целиком. По ходу рассказа я буду давать советы и рекомендации. Некоторые из них могут показаться лично вам очевидными до банальности. Не сочтите их свидетельствами моего высокомерия. Мне приходилось встречать очень разных руководителей, и я стараюсь писать для них всех. Эта книга - не отрицание ITIL. Мы обсудим преимущества ITIL, и пути достижения успеха в ITIL-трансформации (чуть позже я поясню, почему «трансформация» - лучшее слово для ITIL, чем «внедрение»). Просто я пытаюсь подходить к вопросам взвешено, сбалансировано. Утверждения, высказанные здесь, подлежат сомнению и обсуждению, и так и было задумано: я хочу инициировать дискуссии, которых так не хватает в профессиональном сообществе. ITIL- не серебряная пуля, решение об использовании ITIL должно быть сознательным. Я убежден, что эта книга заполняет существующий вакуум: полное отсутствие объективной аналитики ITIL для тех, кто отвечает за руководство применением ITIL, а не за непосредственную реализацию. Я искренне надеюсь, что эта книга приведёт к снижению числа ITIL-проектов, но увеличит долю успешных среди них. Позвольте мне выразить сердечную благодарность всем, кто принимал участие в подготовке и издании этой книги. В особенности, спасибо за бесценные комментарии, сделанные Харви Калдером (Harvey Calder), Джеймсом Фини- стером (James Finister), Кэри Кингом (Сагу A. King), и Полом Вилкинсоном (Paul Wilkinson). Отдельное спасибо моим жене и сыну за то, что они всё это терпят.

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

Наша работа - в перерывах между переводами книжек - состоит в том, чтобы помочь российским компаниям овладеть ITIL и в дальнейшем получать пользу от этого владения. Не раз и не два в своей практике мы ловили себя на том, что многое из того, что мы делаем, описано в этой книге. Не раз и не два при первом знакомстве с книгой мы говорили себе: «а ведь именно так мы и делаем!». Как и в случае с «Введением в реальный ITSM», работа над этой книгой доставила нам огромное удовольствие. Мы надеемся, что результат вместе с удовольствием принесёт читателям пользу. Команда Cleverics.

Комментарии для руководства ITIL не имеет смысла в статичной среде, где ничего не меняется, не ломается и не растёт. ITIL не даёт рекомендаций в области технологий, а равно технологии не могут быть средством внедрения ITIL. ITIL - о том, как процессы и участвующие в них люди отвечают на запланированные и незапланированные изменения в окружающем мире, от сбоев до роста и развития, так, чтобы соответствовать ожиданиям бизнеса. ITIL - о человеческой деятельности. Любой организации нужны процессы, описанные в ITIL. И в любой организации они уже есть. ITIL просто предлагает вариант стандартизации их исполнения. Возможно, вы не нуждаетесь в ITIL, но каждая ИТ-служба так или иначе должна делать то, что ITIL описывает. Некоторые практики, описанные ITIL, никогда не будут реализованы, а если всё же будут, должны быть немедленно прекращены, чтоб не мучились. Модный нынче культ ITIL приводит к появлению предложений, предполагающих, мягко говоря, не самое оптимальное использование ресурсов. ITIL эксплуатирует любовь ИТ-специалистов к быстрым техническим решениям сложных проблем. ITIL выглядит как симпатичный коробочный набор шаблонов для преодоления трудностей, связанных с сервисной культурой. На самом деле ITIL не является таким набором, но это обстоятельство не помешало сообществу вендоров / консультантов / аналитиков широко рекламировать ITIL именно в таком качестве, да ещё и построить на базе этого заблуждения серьёзный рынок консалтинга, обучения и программного обеспечения. С ITIL связано множество глупостей и заблуждений, например: ITIL нельзя померить, пока ITIL не внедрит метрики; ITIL не может работать без комплексной базы конфигураций; ITIL невозможно и не следует обосновывать с точки зрения затрат, а следует просто внедрять. В ITIL нет ничего волшебного. Любой связный с ITIL проект должен обосновываться и управляться так же, как любой другой проект в организации. Если вы оказались ответственным за строчку «ITIL» в бюджете; назначены куратором проекта ITIL; если вас попросили утвердить бизнес-обоснование чего-то, именуемого ITIL - тогда эта книга адресована именно вам. Обладая необходимой информацией, вы встретите ITIL во всеоружии и сможете принять верное решение. А если вы вынуждены отчитываться перед кем-то из перечисленных в предыдущем абзаце, эта книга поможет вам говорить правильные слова и делать правильные дела. ITIL - это полезный инструмент в рамках широкомасштабной инициативы по изменению отношения людей к тому, как они предоставляют услуги. В случаях, когда это оправдано и обосновано, ITIL может использоваться как один из инструментов для изменений культуры и совершенствования процессов, как источник примеров широко принятых хороших практик. Если вам предлагают ITIL как что-то большее, чем такой инструмент, или если ITIL объявляют самодостаточной целью внедрения, эта книга поможет вам отбиться. Если сосредоточиться на том, что действительно нужно, есть шанс преуспеть. Вместо, скажем, трёх успешных ITILпроектов из десяти, хотелось бы видеть, скажем, четыре из семи. 1

1

«От 3 из 10 к 4 из 7» - модель, заимствованная у Арта Джекобса и методологии целевых продаж (Target Account Selling methodology)

5

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

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

Что такое ITIL В зависимости от вашего положения ITIL - либо набор книг, которые можно дорого продать, либо глобальное движение, уничтожающее ИТ-сообщество. ITIL - это порождение OGC (Office of Government Commerce), государственной структуры Великобритании. Вообще-то, создание ITIL в 1980-х - дело рук более ИТ-ориентированного предшественника OGC, но урок истории не входит в наши планы. Согласно OGC, 1 «ITIL® (the IT Infrastructure Library) - это наиболее широко принятый в мире подход к управлению ИТ- услугами. ITIL предлагает целостный набор лучших практик, отражающих опыт частных и государственных компаний из разных стран. ITIL поддерживается комплексной схемой сертификации, аккредитованными тренинговыми организациями, инструментарием оценки и внедрения. Процессы, описанные в ITIL, поддерживают и поддержаны британским стандартом в области управления ИТ- услугами, BS-15000». [Сейчас на смену BS15000 пришел ISO/IEC 20000] Это очень скромное описание. ITIL- наиболее широко распространенный подход к Управлению ИТ во всём мире. Теоретически, сервисный подход - лишь один из возможных при организации операционной деятельности, но лучшего пока никто не предложил. Сервисный подход 1

www.ogc.gov.uk/guidance_itil.asp

6

предполагает бизнес-соответствие ИТ1, то есть, говоря простым языком, предлагает давать бизнесу то, что ему нужно, а не то, что ИТ хочет ему давать. В наше время все пытаются делать именно это, a ITIL - лучшая компиляция практик, или «свод знаний», в этой области. На протяжении ряда лет такой подход обсуждался и рассматривался, и вот, наконец, пришло его время. Основной плюс от использования ITIL - это, без сомнения, стандартизация, общий язык. Аудиторы, консультанты, поставщики могут быстро разобраться, что есть, что и кто есть кто, если вы используете терминологию ITIL (особенно - когда вы используете её традиционным образом). ITIL— фактически устоявшийся язык для операционной деятельности в сфере ИТ. Второй плюс - это импульс, который дают вашей организации обученные специалисты, опытные консультанты, хорошие книги, профессиональные сообщества в Интернете. Использование вывески «ITIL» может помочь обосновать инициативы в области сервисной культуры и получить финансирование (...или помешать; в зависимости от прошлого опыта тех, кто выделяет средства и одобряет инициативы: иногда лучше не называть это «ITIL»). Есть ещё несколько важных преимуществ, которые свойственны ITIL, хотя и не только ITIL: • • • • •

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

С другой стороны, ITIL - это что-то вроде культа. А в таких случаях никого не интересует объективная полезность и вообще объективность. Мы следуем священным книгам, мы делаем так, потому что «так говорится в ITIL» (а не потому что видим в этом практический смысл), мы пересматриваем все наши процессы, а не только те, что работают неоптимально... мы делаем ITIL ради ITIL. В результате мы переделываем то, что отлично работало, то есть действуем, по меньшей мере, нерационально. Кроме того, с некоторых пор ITIL - это область коммерческих интересов; так неминуемо должно было случиться при достижении определенного масштаба и популярности. Это означает, что ITIL не всегда развивается в интересах конечных потребителей, а равно и в интересах совершенствования и развития философии ITSM. Ну и наконец, ITIL - отрезанный ломоть; интеграция ITIL с другими важными системами, такими как COBIT2, ISO 2700X, ISO 900X, CMMI, очень ограничена; даже связь с ISO 200003, мягко говоря, неполна. Следствие - более высокая стоимость объединения этих систем на благо конкретной организации. В целом, однако, можно сказать, что ITIL оказывает позитивное влияние на управление ИТ - там, где применяется правильно и уместно. Хотя COBIT является во многих отношениях более полным и целостным сводом знаний, чем ITIL, популярность ITIL существенно выше. ИТ-Скептик предлагает такую аналогию: ITIL - это справочник путешественника, COBIT - энциклопедия, в точности как известные Справочник путешественника автостопом по галактике и Галактическая Энциклопедия.

1

Business-IT Alignment COBIT4.1, Аудит и контроль информационных систем, 2008, ISBN 978-5-9901321-1-5 3 ISO 20000 - международный стандарт по управлению ИТ-услугами. Более корректно называть его ISO/IEC 20000:2005, но так почти никто не делает. 2

7

Совершенно потрясающая книга Дугласа Адамса, «Автостопом по галактике»1, так описывает Справочник путешественника: «Во многих цивилизациях Внешней Восточной Оконечности Галактики, где нравы менее строги, "Путеводитель по Галактике для автостопщиков" в качестве общепринятого вместилища знаний и мудрости уже заменил Великую Галактическую Энциклопедию, поскольку, несмотря на то, что он кое в чем неполон, содержит много сомнительного или, во всяком случае, вопиюще неточного, он имеет два важных преимущества перед этим более старым и приземлённым трудом. Во-первых, он немного дешевле, а во-вторых, на его обложке большими и приятными для глаз буквами написаны слова "Без паники!" 2» Если не брать во внимание тот факт, что ITIL намного дороже, а на обложках изображены огромные рентгеновские снимки животных и растений, автор как будто бы говорил об ITIL и COBIT. ITIL демонстрирует удивительные небрежность и расслабленность (например, в использовании термина «процесс»), ITIL в тоже время яростно отстаивает спорные и неоднозначные идеи (например, книга Service Strategy в отношении сетей предоставления ценности, value networks). В ITIL, по сравнению с COBIT, многого не хватает. ITIL описывает эксплуатацию и в основном игнорирует разработку и создание решений. ITIL лишь изредка заглядывает в управление проектами и пропускает много важных аспектов - например, в управлении запросами. А главное, в COBIT можно найти систематизированный список всего, что должно делаться, а в ITIL - некоторые комментарии о том, как это можно делать. «Вот что говорится в Великой Галактической Энциклопедии об алкоголе. В ней говорится, что алкоголь - это бесцветная летучая жидкость, получаемая при ферментации сахара, и отмечается также её интоксицирующее воздействие на некоторые формы жизни, основанные на углероде. "Путеводитель по Галактике для автостопщиков" также упоминает алкоголь. Он говорит, что самый лучший из существующих алкогольных напитков - это пангалактический бульк-бластер. Вот как он описывает действие пангалактического бульк-бластера: "как будто вам по мозгам заехали ломтиком лимона, с завёрнутым в него здоровенным слитком золота". Путеводитель также сообщает, на каких планетах смешивают самый лучший пангалактический бульк-бластер, сколько он может стоить, и какие благотворительные организации помогут вам справиться с его последствиями. Путеводитель даже описывает, как вы сами можете его приготовить...» Нельзя не отметить сходства с ITIL и COBIT . Статья в энциклопедии, описывающая химическое соединение, именуемое «этиловый спирт», куда как менее интересна, чем практическое руководство по изготовлению, употреблению и реабилитации. То, что Справочник путешественника неполон, устарел, субъективен и ненадёжен, с запасом перевешивается его практической полезностью ...и человечностью. Причуды и несовершенства - свидетельства натуральности. Так же и с ITIL.

Книги ITIL Материальная составляющая ITIL - это книги.

1

The Hitchhiker’s Guide to the Galaxy, Douglas Adams, various publishers including Del Rey 1995, ISBN-13:9780345391803 2 Пер. Юрия Ариновича (2005)

8

Существует несколько версий ITIL. В 2007 вторая версия (здесь и далее - ITIL2) была подвергнута «обновлению» до новой, третьей, версии (здесь и далее - ITIL3). ITIL1 до сих пор издается, и есть люди (постепенно исчезающая каста консерваторов старой школы), что до сих пор присягают на этих книгах. Основа Несколько книг составляют так называемые «основные» публикации ITIL (около девяти книг в ITIL2, пять или шесть - в ITIL3, смотря как считать). В этих книгах описаны процессы, составляющие «лучшие практики» операционной деятельности ИТ. Они подробно описывают роли, виды деятельности, связи процессов и тому подобные вещи. В ITIL2 была даже «основа основ»: многие люди ошибочно полагают, что в ITIL2 и было-то всего две книги - «синяя» и «красная», Service Support1 и Service Delivery2. Вопреки распространенному убеждению, ITIL не является общественным достоянием. Управляет библиотекой OGC, публикует книги издательство TSO 3, с недавних пор - частная коммерческая организация. Права на библиотеку принадлежат Её Величеству королеве Великобритании (хотя маловероятно, чтобы она их читала). Торговую марку защищает OGC - по крайней мере, так они говорят, хотя пока что множество продуктов использует слово «ITIL» безо всякой лицензии. Книги можно купить в традиционной бумажной форме, на одно- или многопользовательских CD (ITIL2) или в электронном формате (pdf или онлайн-подписка, ITIL3)4. Книги ITIL отнюдь не дёшевы. Минимальный «основной» набор из двух книг второй версии обойдется вам в шесть сотен долларов на CD или вдвое дешевле на бумаге. Остальные книги стоят примерно столько же, некоторые - примерно в два раза меньше. В итоге полный набор книг ITIL2 стоит около 1000 фунтов стерлингов на CD или около 1000 долларов США на бумаге. Пять «главных» книг ITIL3 можно купить все вместе, комплектом. Стоит комплект примерно 300 фунтов стерлингов. Есть другой вариант: однопользовательская подписка па электронную версию сроком на один год за примерно ту же сумму. Теоретически доступно корпоративное лицензирование. Эти суммы, конечно, меньше, чем цены на некоторые проприетарные разработки - подходы, методологии, - но всё же больше, чем цена на такие подходы, как MOF, COBIT, FITS (см. стр. 18), которые в основном могут быть скачаны из Интернета бесплатно. Надо добавить, что «Официальное введение в жизненный цикл ITIL»5 часто рассматривается как шестая «основная» книга ITIL3. Книги можно купить в следующих местах: • • • • • •

TSO the publisher, www.tsoshop.co.uk Van Haren, www.vanharen.net Amazon, www.amazon.com других книжных магазинах в Сети через локальное отделение itSMF 6 itSMF International. Кстати, если вы участник глобального itSMF, вы можете получить через них куда лучшие условия, чем через локальное отделение. Локальные отделения форума не очень этому рады.

1

Поддержка услуг, 2006, ISBN 0-11-330948-1 Service Delivery, OGC, TSO 2001, ISBN 978-0113300174 3 British Government Stationary Office 4 В середине 2010 года издание бумажных книг второй версии прекращено, http://www.tsoshop.co.uk/bookstore.asp?di=583774 (прим. переводчика) 5 The Official Introduction to the ITIL Service Lifecycle, OGC, TSO 2007, ISBN 978-0113310616 6 Вроде бы это значит, что через itsmforum.ru. По-моему, пока никто не пробовал это сделать (прим. переводчика). 2

9

Дополнения А ещё есть книги, дополняющие основные публикации с разных сторон. Хороший пример вводная книга, изданная в дополнение к ITIL21. Эти книги издаются целым рядом организаций и обычно стоят как деловая литература. В ITIL3 есть официальные дополнения, одобренные и интегрированные с основными публикациями, их важно не путать с изданиями, выпускаемыми третьими сторонами, вроде этой книги. Первое официальное дополнение - книжка «Сдаём экзамен ITIL Foundation»2, второе «Построение ITIL-ориентированного сервисного подразделения»3 (про организационную структуру, не про внедрение ITIL). В 2009 году должна выйти в свет книга «Предоставление ИТуслуг с использованием ITIL, PRINCE2 и DSDM» (DSDM - это такая методология, про которую каждый прикидывается, что он о ней уже слышал). 4 Между itSMF International и OGC подписано соглашение о переводе книг ITIL3 на разные языки. 5 И качестве дополнений к ITIL3 можно также рассматривать ITIL Live™ Portal6, управляемый TSO на коммерческой основе. Годовая персональная подписка стоит £2500, конкурентная коммерческая - вдвое больше. Какова ценность этого ресурса и найдутся ли желающие узнать это за указанную цену, покажет время. Стоит также обратить внимание на «альтернативные», неофициальные дополнения к ITIL. В первую очередь это издания itSMF International, выпускаемые издательством Van Haren в серии «Библиотека ITSM». Особенно интересно «Введение в управление ИТ-услугами на основе ITIL v2», отличный реферат основных пяти книг ITIL3, лишенный свойственных оригиналу повторов и пробелов. Кроме перечисленных, есть ещё множество книг сторонних авторов, вроде той, что вы держите в руках. Ищите в интернет- магазинах. Рекомендации 1. Приступая к использованию ITIL имеет смысл почитать об ITIL3, чтобы иметь общее представление о тенденциях, даже если вы будете основывать свою практику на ITIL2. 2. В качестве первой книги стоит выбрать «Сдаём экзамен ITIL Foundation». По сравнению с наиболее очевидным кандидатом эту роль, «Официальным введением...», эта книжка примерно вдвое дешевле при том же объёме. Плюс в ней есть примеры вопросов экзамена, которые помогут вам проверить, как там у вас внутри усваивается материал. (Примечание: с момента выхода этой книги программа экзамена менялась неоднократно. Поэтому мы НЕ рекомендуем использовать её для подготовки к экзамену. Что не отменяет её достоинств в качестве введения в предмет.) 3. «Сдаём экзамен...» может оказаться достаточным чтением для того, чтобы ответить на все ваши вопросы. Если его вдруг не хватило, прочтите «официальное введение». В случае если бюджет ограничен, или если всё, что вам нужно, - это поддержать разговор при случае, скачайте (бесплатно) «Обзор ITIL v3», подготовленный itSMF 7. 4. Ответственному лицу, курирующему тему ITIL, скорее всего, будет достаточно того, что перечислено выше. Если есть желание, можно ещё пройти курс «Основы ITIL v3». 1

An Introductory Overview of ITIL. Rudd, itSMF, 2004 Passing your ITIL foundation exam: the official study aid, Nissen, TSO, 2007, ISBN 978-0113310791 3 Building an ITIL based Service Management Department, M. Fry. TSO 2008, ISBN 9780113310968 4 http://en.wikipedia.org/wiki/DSDM 5 http://its1nforum.ru/news/all_news/2010_01_13 6 www.bestpracticelive.com 7 An Introductory Overview of ITIL V3, itSMF 2007, ISBN 0-9551245-8-1 www.itsmfi.org/files/itSMF_ITILV3_Intro_Overview.pdf 2

10

5. Если и этого вам покажется мало, прочтите или «две главные книги» ITIL2, или упомянутое выше «Введение в управление ИТ-услугами на основе ITIL v3». 6. Если вы считаете, что вам нужно прочесть пять книг ITIL3, значит, у вас слишком много времени для «ответственного лица, принимающего решения».

Движение ITIL Сегодня ITIL - гораздо больше, чем просто набор книг. Это движение, профессиональное сообщество, индустрия. Огромная активность по продвижению и поддержке ITIL наблюдается во всем мире. Существенная её часть никем не управляется и происходит спорадически. Здание ITIL покоится на множестве колонн, и лишь четыре из них находятся под управлением OGC. Основные публикации Управляется и тщательно контролируется OGC. Хорошая работа. Сертификация специалистов Ещё одна колонна в здании ITIL, которую OGC хорошо контролирует путем организации комитета по сертификации (ITIL Certification Management Board, ICMB) и через аккредитацию тренеров и экзаменаторов. В конце 2006 года эта часть работы по управлению ITIL была передана частной компании, АРМ Group, или APMG. Торговая марка Бренд ITIL зарегистрирован и защищается в Великобритании и США. Дополнительные публикации Официальные дополнения неплохо управляются, а качество материалов тщательно проверяется. Независимые - и, следовательно, неконтролируемые - дополнения, вроде этой книги, представляют собой пёстрое сборище, не все участники которого так же хороши, как она. Орган управления Нет такого. Не существует вышестоящей организации, представляющей все заинтересованные стороны, избираемой, устанавливающей политики, правила, стратегию, в общем, осуществляющей руководство всеми колоннами здания ITIL. Как сказал, один вендор1, «Рынок ITIL пока что управляется в основном заказчиками, но зависит от хрупкого союза OGC, itSMF, APMG, ISO, TSO, EXIN, ISEB, тренинговых и консалтинговых компаний и поставщиков ПО. Для того чтобы рынок работал эффективно, участникам следует сотрудничать». Объединённый комитет по стратегии (Combined Strategy Board, CSB), работающий под председательством OGC, не реализует руководящую функцию. APMG говорит2, что этот комитет «отвечает за маркетинг и развитие продукта по всему миру», что скорее связано с развитием, чем с руководством. Кроме того, это вообще довольно мутная организация: они мало публикуют, они не выбираются, а назначаются, и они ни за что не отвечают. Профессиональная организация До недавнего времени таковой тоже не было. Теперь в Великобритании есть Институт Управления Услугами (Institute of Service Management) и Институт Сертифицированных сервисменеджеров (Institute of Certified Service Managers) в США. И ещё ITSM-институт. И Общество по Сервис-Менеджменту. Ассоциация управления ИТ - инфраструктурой. Международная ассоциация по управлению ИТ-сервисами. AITP. IEEE. И другие. Никто из них официально не связан с OGC, и OGC никак не контролирует их работу.

1

Perspectives on the Developments around ITIL-3 and Accreditation, ITpreneurs, itpreneurs.com/Content/Resources/Trends/itil/itil3_and_accreditati0n.htm 2 International Best Practice for IT Service Management wwv.apmgroup.co.uk/nmsruntime/saveasdialog.asp?lID=532&sID=222

11

Сообщество пользователей Форум по сервис-менеджменту1, itSMF, IT Service Management Forum2, был основан вокруг ITIL и полагает себя неофициальным хранителем чистоты этого источником (OGC эту точку зрения не разделяет). Часто itSMF воспринимают как сообщество, объединяющее практиков и пользователей ITIL. Это не так. Согласно заявленным целям, itSMF занимается продвижением стандартов и практик управления ИТ-услугами, включая ITIL. То есть эта организация работает на индустрию, а не на пользователей (кроме тех случаев, когда их интересы совпадают). На практике все зависит от того, в какой стране вы живёте и работаете. В некоторых странах itSMF - это интернет - клуб любителей ITIL; в других - витрина ITIL перед лицом общества, в основном теоретического свойства; в третьих - коалиция ITSM-вендоров. Иногда itSMF декларирует выражение мнений и интересов своих участников, вот только неясно, как форум узнает эти мнения и интересы. С некоторых пор существует официальный онлайн-форум3, но механизмы обратной связи с OGC или itSMF примитивны или вовсе отсутствуют. Нет голосований, нет опросов. Попробуйте предложить добавление или исправление в какую-нибудь из книг ITIL... В итоге наиболее корректным будет сказать, что itSMF выражает интересы сообщества «элиты» ITIL. OGC ничего не было сделано для создания сообщества практиков и пользователей ITIL или управления имеющимся сообществом. Можно надеяться, что когда-нибудь и у ITSM будет свое глобальное сообщество, созданное и существующее с использованием современных информационных технологий. Управление и контроль В индустрии ITIL какой-либо контроль осуществляется только в области профессиональной сертификации. Когда производители и поставщики продуктов или услуг получают право использовать марку ITIL, никто не проверяет, насколько корректно это использование, а также обладают ли эти поставщики компетенцией и ресурсами для создания продуктов и предоставления услуг. Теоретически это делает OGC, но у них нет механизмов реализации этой теории на практике. Сертификация продуктов Одна из ведущих консалтинговых компаний, Pink Elephant, придумала собственную сертификацию для программных решений по автоматизации процессов ITIL - PinkVerify™. OGC фактически уклоняется от этой темы4. Нет требований к ПО и в стандарте ISO 20000 (пока нет: говорят, скоро выйдет четвёртая часть, и там они будут). Потребность в прозрачной независимой некоммерческой сертификации очевидна, и была очевидна десять лет назад. Эту роль могла бы играть сертификация OGC/APMG, по пока что она существует лишь в теории, а возможные критерии оценки неизвестны 5. AI'MG от имени OGC продает право использовать логотип OGC («водоворот», которым обозначены все методологии, управляемые OGC, не только ITIL), но пока что ни один ITILвендор этим не воспользовался6. Сертификация организаций В отсутствие инициативы такого рода со стороны OGC различные консалтинговые компании изобрели свои методики оценки зрелости своих клиентов. 1

Здесь и далее использован перевод названия itSMF, который выбран для самоназвания itSMF –Россия. В соновном же слово «сервис-менеджмент» переводится как «управление услугами», поскольку именно такой перевод рекомендован в глоссарии ITIL, переведенном тем же itSMF -Россия. - прим. переводчика 2 www.itsmf.org 3 www.itsmfi-forum.org 4 Уже не уклоняется. С мая 2009 действует официальная сертификация ПО на соответствие ITIL (см. http://www.cleverics.ru/ru/subject-field/hot-issues/itil-software-scheme) - прим. переводчика 5 Критерии опубликованы (http://www.itil-offic.ialsite.com/ Software- Scheme/MandatoryAssessmentCriteria.asp). На практике оказалось, что независимость, прозрачность и некоммерческий характер не свойственны сертификации OGC/APMG. - прим. 6 По данным на конец 2008 года.

12

ITIL активно использует понятие «цикл Деминга» и подчеркивает необходимость оценки текущего состояния до начала изменений. Но не предлагает никакой методики для выполнения такой оценки. Ссылается на модель СММ и описанные в ней уровни зрелости, но не говорит, как их измерить. Это было простительно в первой версии, но сейчас потребность в таких рекомендациях неудовлетворена в той же мере, что и очевидна. Стандарт Мы долго ждали стандарта в сфере управления ИТ- услугами - сначала BS 15000, потом ISO 20000. ITIL- стандарт мог бы решить задачу сертификации организаций (а может, и продуктов), а также прибавить ITIL веса. Но BS 15000 (и тем более ISO 20000) вышли гораздо позже ITIL2, так что жизнь успела уйти вперед, и стандарты заметно обогнали ITIL1. Можно было надеяться, что выход ITIL3 скомпенсирует этот разрыв, и ITIL догонит ISO 20000. Но, хотя и ISO 20000 (и другие своды знаний, например, COBIT) упоминаются в ITIL3, систематической работы по их совмещению проделано не было, и даже просто ссылок по тексту никто не добавил, так что ITIL3 продолжает идти своим путем. ITIL и стандарт стали ближе, но остались далеки2. Между стандартом и ITIL3 много отличий: •

• •

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

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

Индустрия ITIL ITIL - это книги, а книги - это ITIL, но вокруг этих книг выросла целая отрасль. И эта отрасль ежегодно приносит множеству игроков миллионы долларов. itSMF itSMF - некоммерческая организация, которая очень неплохо зарабатывает на членских взносах, конференциях и собственных публикациях. Отделения форума действуют более чем в пятидесяти странах3. Членство в itSMF может быть полезным - по крайней мере, ключевым ITIL-специалистам вашей организации. Можно купить передаваемое корпоративное членство для нескольких сотрудников в разных странах, или даже глобальное членство. Разработчики и продавцы ПО Автоматизация не является необходимым компонентом ITIL, но, как правило, без автоматизации Service Desk не обходится, так что разработчики систем Service Desk очень любят ITIL. Вендоры убедили мир, что CMDB и остальные компоненты комплексной автоматизации ITSM так же необходимы, как Service Desk. 1

ISO/IEC 20000 and ITIL - the difference explained, J. Dugmore and A. Holt www.best-managementpractice.com/bookstore.asp?FO=1229332&DI=571307 2 ITIL® V3 and ISO/IEC 20000. J. Dugmore and S. Taylor, www.best-managementpractice.com/gempdf/ITIL_and_ISO_20000_March08.pdf 3 http://www.itsmfi.org/content/chapters

13

Кроме того, ITIL формирует спрос на инструментарий эксплуатации ИТ: средства мониторинга, аудита, управления, отчетности и прочее, и прочее... ITIL - существенная часть бизнеса многих софтверных компаний: гигантов вроде HP и IBM, разработчиков ITSM- ПО, вроде СА и ВМС, и нишевых компаний, таких как Marval или ServiceNow. Microsoft, Oracle, Novell и другие постепенно входят на этот рынок. Всех и не перечислить. Консалтинг Консультанты - важные участники любого внедрения ITIL. Нет более быстрого и рационального способа интеграции мудрости ITIL в тело вашей организации. Мудрость поступает предварительно обработанной, адаптированной под ваши потребности, в удобной для потребления форме. Фокус в том, как и всегда с консультантами, чтобы найти правильных и держать их под контролем. Есть четыре основных типа консультантов: • • • •

БОЛЬШИЕ консалтинговые компании (Accenture участвовала в написании одной из книг ITIL3). Специализированные ITSM-консультанты, вроде Pink Elephant (большинство таких компаний - региональные). Вендоры. Остерегайтесь тех, что норовят продать вам чудо-коробку: обычно это чистые технари с минимумом консалтинговых услуг. Независимые специалисты, обычно сертифицированные ITIL-эксперты с несколькими большими внедрениями в резюме.

Тренинги и сертификация Хотя многие консультанты являются одновременно тренерами, обучение - это отдельная полноценная индустрия. В то время как сертификация организаций и ПО не утверждена, в отношении сертификации специалистов и аккредитации тренеров и тренинговых компаний существуют чёткие правила и механизмы управления. Базовая сертификация - «Основы ITIL». Многие сотрудники получают этот сертификат в ходе проектов внедрения ITIL. Это такая форма посвящения. Часто это обучение проходят больше сотрудников, чем надо, и само оно глубже и шире, чем требуется, но в результате у проекта появляется несколько рьяных сторонников внутри организации. Ещё есть несколько сертификатов промежуточного уровня (в ITIL2 они назывались Практиками, Practitioners), предполагающих углубленную подготовку для исполнителей конкретных ролей. ITIL Expert (раньше - «Менеджер» или «Мастер») на сегодняшний день является высшей ступенью сертификации... ...поскольку высший анонсированный уровень, очень удачно названный ITIL Master, пока что находится в разработке.1 Все уровни сертификации являются хорошим индикатором наличия базовых знаний, но надо иметь ввиду, что все они - результат тренинга продолжительностью несколько дней и теста формата «выберите верный ответ из нескольких». Сертификация не предполагает ни практического опыта, ни выполнения практических заданий, ни регулярного подтверждения и точно не может считаться аналогом высшего образования. Kак сказано выше, аккредитация экзаменующих и тренинговых организаций была передана АРМ Group. Некоторые компании предлагают симуляционные игры как часть своих тренингов, часто - как дополнение к «Оспинам ITIL». Это чрезвычайно эффективный способ обучения через действие, и его стоит использовать независимо от прохождения курсов ITIL.

1

http://www.realism.ru/2010/08/itil-v3-master-vremya-eshhyo-ne-prishlo/

14

Публикации Основные книги, как и некоторые официальные дополнения, а также их переводы, издаются TSO (The Stationery Office), до 2006 года - подразделением правительства Её Величества. В 2006 году оно было продано, и впоследствии продано снова. Есть и другие издательства, в том числе - itSMF и Van Haren.

Мыльный пузырь ITIL Тех наблюдателей, что сравнивают ITIL с «проблемой 2000», можно понять. У них в самом деле много общего. Проблема 2000 года стала самостоятельной отраслью. По мере объединения усилий её участников формировался мощный инструмент пропаганды и продаж, которому мало кто мог противостоять. Если вы не видите вокруг консультантов и вендоров, раздувающих огонь ITIL, просто отойдите на шаг назад и оглядитесь ещё раз. Проблема 2000 вознесла искусство СНС1 на невиданную ранее высоту - и вряд ли этот успех удастся когда-то повторить: мир стал умнее и циничнее... надо надеяться. Деловой мир был ввергнут в безумие закупок. Каждый делал это, потому что все делали. Если вы не готовились к 2000 году, вас считали сумасшедшим, хуже того - вас считали безответственным. Подпитывается ли ITIL за счёт СНС? Нет, но ITIL подпитывается за счёт слепой веры в то, что ITIL надо внедрять, потому что все это делают. Повальное модное увлечение? Безусловно. Подстёгиваемое вендорами и консультантами? Ещё как. Оно стало самостоятельной отраслью, и маркетологи, развивающие её, многое взяли из опыта «проблемы 2000». Итак, есть много общего у ITIL и «проблемы 2000»: маркетинговое безумие, волнообразное распространение, девиз «А вы почему не с нами?». Надо надеяться, 2000 год чему-то нас научил, и мы не повторим ошибок десятилетней давности. Надо надеяться, мы избавились от стадного чувства. Гартнер2 придумал отличную модель для иллюстрации иррациональных всплесков успеха ИТотрасли, регулярно наблюдаемых на протяжении последних лет - цикл ажиотажа. Она описывает как всеобщий энтузиазм сменяется таким же всеобщим разочарованием, а затем - стабильным трезвым отношением. 3 И реальной жизни этот цикл в большинстве случаев заканчивается более или менее заметным периодом увядании и последующим забвением предмета ажиотажа. В случае с информационными технологиями иногда всё закапчивается превращением в рудиментарный элемент инфраструктуры, бесполезный, но требующий внимания и финансирования. Тем временем новый герой привлекает всеобщее внимание и греется в лучах славы. Сейчас ITIL находится где-то недалеко от пика интереса, точная позиция меняется от страны к стране. В любом случае, это пока не провал: до сих пор ITIL встречают с интересом и даже с энтузиазмом. Но движение к склону уже началось. Возможно, немного объективности на этом этапе поможет сделать пик не таким высоким, а спуск - не таким крутым, и поскорее подняться по ту сторону провала к разумной зрелости. Мир ИТ любит новые игрушки. Это следствие общей незрелости (в сравнении с любой другой технической отраслью). Вы видели инженеров, ежегодно предлагающих новые крутые способы строительства, скажем, мостов (как правило - более дорогие и менее надежные, чем те, что применялись на протяжении многих лет)? Те из нас, кто работает в ИТ достаточно долго, помнят некоторые из таких игрушек. Если у вас нет такого опыта, простите мне следующие несколько абзацев... Возможно, вы узнаете в них ИТбезумства, свидетелями которым вы были. Кое-кто ещё помнит, что когда-то все данные хранились в виде «плоских» файлов, но потом появились реляционные базы данных, и это и был ответ на все вопросы, универсальное решение 1

Страх, Неуверенность и Сомнение (FUD): техника продаж, по слухам, изобретённая IBM. Известная аналитическая компания: www.gartner.com 3 См. Wikipedia: en.wikipedia.org/wiki/Hype_cycle 2

15

всех проблем. Как только все данные удалось сложить в одно место, проблемы связей, ссылок и целостности должны были исчезнуть! С появлением SQL программирование должно было стать легким, и нам уже не были нужны все эти программисты, ведь пользователи получили удобное средство для написания собственных запросов. Автор этой книги начинал изучая языки четвёртого поколения, которые пришли на смену несовершенным языкам поколения третьего, таким как COBOL. Конец программирования как профессии снова был близок, как никогда ранее - языки становились простыми и понятными обычным пользователям. То же говорилось о COBOL, когда отец автора изучал его в 70-х, но на этот раз это было правдой. Честно-честно. Потом мы все занимались построением корпоративных моделей данных. Раз уж у нас есть вся информация, сложенная в одном месте, и все данные приведены к третьей нормальной форме1, ответы на все вопросы будут сами падать нам в руки. Автор работал с системой, в которой было примерно четыре с половиной тысячи чудных нормализованных таблиц - парень, который помогал пользователям писать те самые запросы. Мы тогда работали с IBM 370 серии, и компьютеры тогда ещё не были дёшевы. Затем пришли CASE-средства2, чтобы снова перевернуть программирование. Теперь, когда весь код генерируется в одном месте, пользователи смогут просто рисовать картинки и получать готовые приложения. Автоматически. Уже двадцать лет прошло, а программирование всё никак не перевернется. Структурное программирование, модульное программирование, объектно-ориентированное программирование (теперь все методы тоже объединены в одном месте), информационная инженерия, репозитории (все метаданные в одном месте!), RAD 3, JAD4, каталоги (теперь нее данные проиндексированы и выглядят так, как будто Лежат в одном месте), хранилища данных (копии всех данных - в одном месте!), EAI5 (старые и новые приложения автоматически склеены вместе и выглядят так, словно место и в самом деле одно), HTML, ERP 6 (наконец-то весь чертов бизнес сложен в одно место), веб-службы (все API- интерфейсы динамически связаны, a UDDI позволяет нам искать всё, что надо, в одном месте...), и, конечно, электронная коммерция [смущенное молчание, все краснеют]. Десять лет назад любимой игрушкой стали персональные компьютеры, клиент-серверные и трёхуровневые архитектуры, позволяющие децентрализовать все обратно. Сейчас у нас есть браузеры, тонкие клиенты, виртуальные машины - для того, чтобы всё централизовать. Всё, что перечислено, добавило в информационные технологии немножко пользы и много сложности. Ничто при этом не стало серебряной пулей, под видом которой подавалось консультантами и вендорами. Всё стоило больше и приносило меньше, чем обещалось. Неудивительно, что сегодня бизнес относится к ИТ с известным цинизмом. Не то чтобы у них так уж много прав кидаться камнями в ИТ: пока всё описанное занимало наше время в серверной, наверху, в зале заседаний, обсуждались и внедрялись циклы качества, BPR 7, бюджетирование «с нуля», TQM 8, 6sigma, МВО 9, КМ 10, коучинг, интеллектуальный капитал, ISO 9000, аутсорсинг и оффшоры, и, конечно, электронная коммерция... Время от времени случаются инновации, которые в самом деле меняют правила игры. Такими «тектоническими сдвигами» стали компьютеры (сначала «большие», потом персональные), мышки, гиперссылки, Интернет, управление цепочками поставок. Когда-нибудь станет ясно, попадёт ли в этот список управление услугами. 1

3NF. состояние священной чистоты данных CASE: Computer Aided Software Engineering 3 RAD: Rapid Application Development 4 JAD: Joint Application Development 5 EAI: Enterprise Application Integration 6 ERP: Enterprise Resource Planning 7 BPR: Business Process Re-engineering 8 TQM: Total Quality Management 9 MBO: Management by Objectives, «управление по целям». 10 KM: Knowledge Management, «управление знаниями» 2

16

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

Управление услугами Как было сказано выше, не оправдавшие себя огромные затраты на решение «проблемы 2000» изменили отношение бизнеса к прозрачности и обоснованности трат на ИТ. Что привело к появлению новых (или адаптации имеющихся) методов управления бизнес-соответствием, в частности - управления услугами, или сервис-менеджмента. В новом веке организации требуют от своих отделов ИТ большей зрелости - они хотят, чтобы ИТ-служба управлялась как бизнес-подразделение, а порядок и дисциплина в ней напоминали те, что приняты у инженеров. Подход, который сформировался в ответ на эти требования, можно назвать сервис-менеджментом. Это действительно смена парадигмы (выражение, которым часто злоупотребляют, но которое использовано здесь верно и сознательно). Этот подход является одним из следствий более масштабного сдвига в общественном сознании, который мы не можем здесь исчерпывающе рассмотреть: перехода от продукт-ориентированной эры производства к сервис-ориентированной эре информации. Тем, кто хочет больше узнать об этих изменениях в обществе, стоит познакомиться с произведениями Питера Друкера1 и Элвина Тоффлера2, а тем, кому интересно их влияние на компьютерную отрасль - с работами Джона Захмана3. Этот переход занимает не одно десятилетие и до сих пор продолжается. Cервис-менеджмент предполагает, что всё планирование и управление в ИТ должно основываться на потребностях бизнеса и ИТ-услугах, которые бизнес потребляет, - то есть на результатах работы ИТ для пользователей, а не на технологиях, используемых для формирования этих результатов. Ориентация на заказчика - подход, весьма популярный в других, не-ИТ, отраслях - стала основой для новой информационной эры. Можно нарисовать матрицу, в которой технологии будут пересекаться с предоставляемыми бизнес-услугами. Сервис-менеджмент поворачивает ИТ-службу на 90 градусов, обращая её лицом к заказчикам и заставляя управлять услугами для бизнеса, а не технологиями. Иначе говоря, сервис-менеджмент - это подход, при котором персонал ИТ (а на самом деле любой поставщик услуг), сначала думает о том, что важно потребителям услуг, а уже затем определяет, что для этого требуется на уровне технологий и систем. Обычно потребителям гораздо важнее, что они получают на выходе, а не то, какими средствами это было произведено. В больших организациях переход от продукт - ориентированной к сервис-ориентированной культуре прошел без участия ИТ. Пока бизнес двигался вперед, на ходу меняя свои ожидания в отношении ИТ, ИТ-служба оставалась отдельным племенем со своим собственным языком. Но, вдохновленные передовыми идеями производственного сектора, ИТ придумали свой сервисменеджмент (отсюда и название - ITSM, ИТ Сервис- менеджмент), чтобы преодолеть образовавшуюся между ними и бизнесом пропасть. Сегодня мы видим, как ИТ- службы приносят идеи сервис-менеджмента обратно в бизнес, теперь - в качестве методологии для построения отношений, ориентированных на заказчиков, а также кросс-организационных процессов управления. Вторым важным результатом произошедшего изменения в отношениях ИТ и бизнеса стало то, что ИТ-службы теперь перестраиваются, обретая сервис-ориентированную структуру и выстраивая её как систему процессов, управляющих услугами, вместо привычной функционально и технологически ориентированной организации. И наконец, третье изменение: люди в ИТ начинают думать о стратегии. 1

The Post Capitalist Society, P. Drucker, Harper Business 1994 The Third Wave, A. Toffler, Morrow 1980 3 Enterprise Architecture: The Issue of the Century, J. Zachman, Database Programming and Design, 1997 2

17

Как только мы понимаем, какие услуги мы предоставляем и чего от них ждут потребители, мы можем планировать, тратить деньги, управлять, измерять и совершенствовать на основе этого знания. Это важно, и это можно использовать чрезвычайно широко, и мы ещё много интересного увидим в будущем в этой связи. Сервис-менеджмент использует такие понятия TQM 1, как качество с точки зрения заказчика, постоянное совершенствование, управление на основе измерений. Услуги определяются в терминах людей, которые их потребляют. То кс касается уровней, на которых эти услуги предоставляются. Точкой отсчета служат стратегия и цели бизнеса и ТО, как компьютеризация должна их поддерживать. Услуги и их уровни согласуются с заказчиками (ITIL разделяет понятая «заказчик» и «пользователь»: первые платят за услуги, вторые выступают как их непосредственные потребители) и документируются. Процессы и роли структурированы вокруг предоставляемых услуг, а не обеспечивающих их предоставление технологий. Например: управление проблемами, изменениями, доступностью, уровнем услуг, а не серверов, сетей, приложений и т.п. Контракты с поставщиками должны поддерживать соглашения об уровне услуг. Технологии - в последнюю очередь. Они лишь обеспечивают возможность предоставления услуг в соответствии с сегодняшними и завтрашними потребностями. Если технологии не оказывают позитивного влияния на предоставляемые услуги, значит, они не нам нужны. Акцент делается на обеспечении и постоянном повышении качества услуг. Уровни услуг измеряются. Процессы совершенствуются, чтобы лучше управлять качеством услуг. Так идеи, родившиеся в производственном секторе, нашли своё применение в сфере услуг. Сервис менеджмент возник не на пустом месте. За ним - огромный практический опыт и соответствие общественным макротенденциям. Он в самом деле существует. Но это не значит, что всем нам надо прямо сейчас бежать и скорее внедрять ITIL. Как то я разговорился с UNIX-программистом, работавшим в одном банке. Я спросил его, какие приложения работают на серверах, которыми он «владеет». Он начал перечислять HP-UX, Oracle, OpenView... Нет, сказал я, приложения... ну, для бизнес-процессов. Он не понял вопроса, А когда понял - не смог ответить. Он не знал.

Альтернативы ITIL Глядя на то, что происходит сегодня в ИТ-отрасли, можно подумать, что «сервис-менеджмент» значит «ITIL», но на самом деле у нас есть и другие любимые авторы. Модификации и альтернативы • Библиотека ITSM (ITSM Library 2), издаваемая itSMF. Исторически так сложилось, что itSMF одобрил и выпустил множество книг, в основном написанных авторами из Нидерландов, так или иначе связанных с ITIL общим содержанием, но обычно более доступных - и содержательно, и финансово. • MOF3 от компании Microsoft, разумеется, в значительной степени сфокусирован на управлении в Windows-среде. MOF немного отличается от ITIL (довольно необычно наблюдать эту компанию выпускающей что-то специфическое, отступающее от общепринятого подхода). В 2008 году вышла новая, четвертая версия MOF, бесплатно доступная на условиях лицензии Creative Commons4. • Универсальный свод знаний по управлению услугами (USMBOK 5) - действительно довольно масштабный свод знаний со сложной историей, но и со своими сторонниками и

1

Total Quality Management, или всеобщее управление качеством. См. например, http://ru.wikipedia.org/wiki/TQM 2 www.itsmfbooks.com/index.php?cPath=4_421 3 Microsoft Operating Framework, Microsoft Corporation, www.microsoft.com/technet/itsolutons/cits/mo/mof/default.mspx 4 http://creativecommons.org/licenses/by/3.0/ (см. также http://ru.wikipedia.org/wiki/Creative_Commons) 5 Universal Service Management Body of Knowledge™ www.usmbok.org

18

• •

энтузиастами. Вводное руководство по USMBOK 1 пригодится тем, кому нужен профессиональный независимый обзор ITSM, не привязанный к ITIL. Руководство2, выпущенное Help Desk Institute, описывает ITSM с точки зрения службы поддержки, что, в общем, неудивительно. COBIT3 - чрезвычайно подробный и широко используемый «контрольный список» для аудита, с недавних пор применяемый, в частности, для контроля соответствия требованиям закона Сарбейнса- Оксли (SOX).

ИТ-Скептик считает, что COBIT дорос до состояния, при котором входящие в его состав публикации формируют полноценный свод знаний, способный составить неплохую альтернативу ITIL. Те, кто говорит, что «COBIT - о том, что надо делать, а ITIL - о том, как надо делать» (сам COBIT тоже такое говорит), или не читали COBIT, или искусственно все упрощают, или чрезмерно вежливы по отношению к ITIL. Да, ITIL местами копает глубже, но утверждать, что COBIT покрывает лишь верхушку - значит сильно недооценивать взаимное пересечение подходов. COBIT весьма серьёзно затрагивает область, связанную с «как». К тому же COBIT шире, он покрывает области, не описанные в ITIL (даже в ITILv3). В докладе 4, посвященном сравнению COBIT и ITIL, который был подготовлен совместно представителями обеих авторских групп, выделяется девять областей, детально описанных в COBIT и вообще никак не затронутых в ITILV3: • • • • • • • • •

РО2 Определение информационной архитектуры РО3 Определение направления технологического развития РО6 Информирование о целях и направлениях развития ИТ РО7 Управление персоналом РО8 Управление проектами DS7 Обучение и подготовка пользователей МЕ2 Мониторинг и оценка системы внутреннего контроля МЕ3 Обеспечение соответствия внешним требованиям МЕ4 Обеспечение корпоративного управления ИТ

…а также 17 процессов, лишь частично описанных в ITIL3. Ранние версии COBIT были подвержены болезни множества книжек, не обошедшей и первые версии ITIL: фрагментированный подход позволяет рассматривать предмет с разных точек зрения, но затрудняет выбор верной. Ещё один источник доходов консультантов. Лучшее в COBIT по версии ИТ-Скептика: Практики контроля (COBIT Control Practices 5). В сочетании с Руководством по проверке (IT Assurance Guide 6) и Рекомендациями по организации руководства ИТ (IT Governance Implementation Guide7), и Рекомендациями для сервисменеджеров (COBIT User's Guide for Service Managers 8).

1

The Guide to the Universal Service Management Body of Knowledge, I. Clayton, Tahuti 2008, ISBN: 978-0-9814691-0-2 Implementing Service and Support Management Processes: A Practical Guide, Higday-Kalmanowitz and Simpson Ed., Van Haren, 2005, ISBN 1- 933284-37-4 3 COBIT4.1, Аудит и контроль информационных систем, 2008, ISBN 978-5-9901321-1-5 4 Mapping of ITIL v3 With COBIT 4.1, IT Governance Institute 2008, ISBN 978-1-60420-035-5, http://www.isaca.org/Knowledge-Center/Research/ResearchDeliverables/Pages/COBIT-Mapping-Mapping-of-ITIL-V3With-COBIT-4-1.aspx 5 COBIT Control Practices: Guidance to Achieve Control Objectives for Successful IT Governance, 2nd Edition, IT Governance Institute, ISACA 2007, ISBN 978-193328473 6 IT Assurance Guide: Using COBIT, IT Governance Institute, ISACA 2007, ISBN 978-19933284743 7 IT Governance Implementation Guide: Using COBIT and Val IT, 2nd Edition, IT Governance Institute, ISACA 2007, ISBN 978-1933284750 8 Details not available at time of publication but this book should be available by the time you read this. The author was a reviewer of this book. 2

19

Сложите это всё вместе, и вы получите полноценный свод знаний о том, как управлять ИТуслугами, способный соперничать с ITIL. Но говорить об этом в дни расцвета ITIL не принято, считается невежливым. База для сравнения и оценки Если вы просто хотите померить, насколько хороша ваша система управления услугами, вы можете обратиться к нескольким источникам, содержащим стандартизированные метрики. Единого согласованного стандарта для измерения ITIL нет, и каждая консалтинговая компания, начиная с itSMF, использует собственную методологию для получения ответов на вопросы. ITIL о том, «как», а не о том, «насколько хорошо». •

ISO 200001 (и предшествовавший ему BS 15000) более всего приблизился к тому, чтобы быть стандартом для измерения ITIL. Несмотря на часто звучащие уверения в обратном, ISO 20000 - не совсем то же самое, что ITIL. • COBIT (см. выше), или его «легкая версия», COBIT Quickstart 2 • «Хозяева» СММ, университет Carnegie Mellon, выпустили eSourcing Capability Model3. Эта модель позволяет проводить оценку ИТ-услуг. В составе модели есть «клиентская» и «провайдерская» части. • Утверждается, что она подходит как внутренним, так и внешним поставщикам услуг, но на практике ориентирована в основном на аутсорсинг. Также в ней отражены особенности руководства в ситуации, когда услуги предоставляются несколькими поставщиками. eSCM содержит свод практики и методологию оценки. С момента публикации eSCM лишь десяток компаний был сертифицирован на её основе, так что невзирая на многочисленные достоинства, назвать эту модель успешной трудно. • Модель зрелости для управления ИТ-услугами (IT Service Capability Maturity Model4) также основана на модели оценки зрелости СММ. Она ненадолго мелькнула на рынке в январе 2005 года. Судя по всему, какие-то ребята нашли пару дней, чтобы по- быстрому разработать методологию, за которой выстроятся в очередь тысячи компаний и рядовых консультантов. Забудьте, ребята. Никто не придёт. … время от времени возникают новые и новые подходы. Всё-таки это пока очень молодая отрасль. Варианты попроще Если ITIL - слишком сложный подход для вашей организации, у вас есть возможность выбрать что-нибудь попроще: •

•

Во-первых, присмотритесь к облегченной версии ITIL, официальное название - ITIL Small-Scale Implementation5. Это официальное издание ITIL, в котором авторы попытались смасштабировать ITIL для нужд малого бизнеса. Книга может быть полезной, но надо учитывать, что «малый бизнес» в их понимании - не обязательно то же, что в вашем. Легкий ITIL чем-то похож на «легкие сэндвичи» в придорожной закусочной - там всё ещё много- много калорий. Версия 1998 года 6 была довольно удачной, но осталась почти незамеченной; остается подождать следующих и посмотреть, что получится. Самая свежая из имеющихся версий вышла в 2008 году как официальное дополнение к ITIL3. FITS7 - пожалуй, самый недооцененный из подходов этого класса. Разработанный для британских учебных заведений, он оказался реально работающим подходом к управлению

1

ISO 20000-2:2005 IT Service Management Standard: Code of practice for service management. International Standards Organisation, 2005 2 COBIT Quickstart, IT Governance Institute, 2003. ISBN 1-893209-59-8 3 itsqc.cmu.edu/models/index.asp 4 The IT Service Capability Maturity Model Niessinka, Clerca, Tijdinka, and inn Vliutb, CIBIT, 2005, www.itservicecmm.org 5 ITIL Small-scale Implementation, Office of Government Commerce, The Stationery Office Books, 2008, ISBN 9780113310784 6 IT Infrastructure Library practices in Small IT Units. Office of Government Commerce, The Stationery Office 1998 7 becta.org.uk/fits/index.cfm В настоящий момент эта инициатива не развивается http://www.realitsm.ru/2010/06/orgvopros/ (примечание переводчика)

20

• •

ИТ-услугами, отлично подходящим ИТ-командам из нескольких человек, начиная с одного. ISM1, «коробочное решение для управления ИТ-услугами». Звучит очень многообещающе, но только для тех, кто умеет разговорить Яна ван Бона 2. Core Practice 3 («Основные практики», СоРr) - интересная новая разработка, достойная внимания 4 (см. стр. 22). Пока, правда, это лишь интересная концепция почти без наполнения и совсем без поддержки сообщества. Пока.

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

подходы к разработке и приобретению программного обеспечения: CMMI-DEV 5, ASL6, BiSL7, CMMI- ACQ 8, ISPL9 безопасность: ISO 2700110 управление проектами: MSP 11, М_o_R12, РМВоК 13 и PRINCE214. руководство (governance): ISO 3850015, IT Balanced Scorecard16 отраслевые стандарты и подходы: Basel II17 для банковской сферы, еТОМ 18 для телекоммуникаций. управление качеством: TQM 19, ISO 900020, Baldrige 21 и SixSigmas22.

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

1

Integrated Service Management www.ismportal.nl/nl/ism-out-box- solution-it-servicemanagement Ян ван Бон - главный редактор портала itsmportal.com, известный и авторитетный специалист по управлению ИТ. Если коробочное управленческое решение вообще существует (в чем автор и переводчики сильно сомневаются), то оно, скорее всего, существует именно у Яна. 3 www.corepractice.org 4 Примечание: автор вовлечен в данный проект. 5 CMMI for Development www.sei.cmu.edu/publications/documents/06.reports/06tr008.html 6 Application Services Library www.aslbislfoundation.org/uk/asl/index.html 7 Business information Services Library www.aslbislfoundation.org/uk/busl/index.html 8 CMMI for Acquisition www.sei.cmu.edu/publications/documents/07.reports/07tr017.html 9 Information Services Procurement Library projekte.fast.de/ISPL 10 ISO/IEC 27001:2005 Information technology - Security techniques - Information security management systems – Requirements www.iso.org/iso/catalogue_detail?csnumber=42103 11 Managing Successful Programmes www.apmgroup.co.uk/MSP/MSPHome.asp 12 Management of Risk www.apmgroup.co.uk/M_o_R/MoR_Home.asp 13 A Guide to the Project Management Bodv of Knowledge (PMBOK® Guide), PMI. PMI 2004, ISBN 9781930699458 14 PRojects IN Controlled Environments www. apmgroup.co.uk/PRINCE2/PRINCE2Home.asp 15 ISO/IEC 38500:2008 Corporate governance of information technology www.iso.org/iso/catalogue_detail?csnumber=51639 16 IT Balanced Scorecard Revisited, A. Cram, Information Systems Control Journal Volume 5, 2007 www.isaca.org/Template.cfm?Section=Home&CONTENTID=35667&TEMPLATE/СontentManagement/ContentDisplay.cf m 17 en.wikipedia.org/wiki/Basel_II 18 www.tmforum.org/browse.aspx?catID=1647 19 Total Quality Management en.wikipedia.org/wiki/ Total_Quality_Management 20 ISO 9001:2000 Quality management systems – Requirements www.iso.org/iso/iso_catalogue/ management_standart/iso_9000_iso_14000/iso_9000_essentials.htm 21 Baldrige National Quality Program baldrige.nist.gov 22 en.wikipedia.org/wiki/Six_Sigma 2

21

Будущее ITIL Без всякого сомнения, ITIL сейчас является самым популярным и авторитетным сводом знаний в области операционной деятельности ИТ. С учётом изменчивости отрасли можно предположить, что это ненадолго, вопрос лишь в том, насколько. Наверняка ITIL будет оставаться на вершине, пока от этого будет польза, и когда ведущую роль займет какой-то другой подход, этот подход будет, скорее всего, основан на тех же принципах, и организации смогут «расти» к нему используя прежние наработки. Что это будет за подход, пока лишь догадки. В ближайшее время можно ожидать появления библиотеки, аналогичной ITIL, но более полно совместимой со стандартом ISO 20000 или с COBIT. Оба эти подхода определяют, как могут быть оценены и измерены практики управления услугами, но дают меньше практических советов по их реализации, чем ITIL. Но стоит им начать предлагать такие советы, и ситуация может стремительно измениться. COBIT быстро приближается к состоянию, когда он будет представлять собой полную и авторитетную альтернативу ITIL. Возможно, у COBIT даже слишком много общего с ITIL, и потому преимущества перехода «с ITIL на COBIT» проигрывают в сравнении с такими особенностями ITIL как широкое признание, по крайней мере, проигрывают, пока дела в мире ITIL идут неплохо. Если же в этом мире случится что-нибудь нехорошее, ещё один претендент на роль ведущего свода знаний в ITSM - MOF: это вполне вписывается в планы Microsoft относительно мирового господства. Однако вероятно и появление чего-то менее предсказуемого, чего-то, что придет извне, чтобы поколебать господство ITIL. Пока же можно с уверенностью сказать1, что в течение как минимум ближайших нескольких лет ITIL останется основным подходом к управлению ИТ-услугами. То, что придет на смену ITIL, вероятно, предложит более полную картину, охватывая услуги, руководство, контроль2; или разработку наряду с эксплуатацией; или эксплуатацию в не-ИТ сферах... Надо надеяться, ITIL войдет в состав такого подхода с не очень значительными изменениями. Разумеется, если управление ИТ-услугами (ITSM) будет объявлено вредной ересью и заменено чем-то принципиально иным, ITIL тоже придет конец.

Чего надо остерегаться В ITIL есть недостатки, странности и белые пятна. Но они не отменяют возможности полезно использовать ITIL. У этой книги нет цели показать все слабые места и недочеты ITIL3. Зато есть цель показать важнейшие слабые места и недочеты того, что люди думают об ITIL. Если иное не указано специально, эти недочеты справедливы для всех версий ITIL. Любому, кто вынужден принимать решения в отношении ITIL-проекта эта глава даёт перечень того, чего надо остерегаться в первую очередь, а также некоторые советы по правильному обращению со связанными с ITIL неприятностями.

Лучшие практики, данные свыше Как заметил Марк Ди Сомма4, Совершенство, достигнутое в определенной области - сила куда большая, чем безуспешные попытки достичь совершенства во всем сразу. Лучше быть стойким во всем и непобедимым в некоторых областях, чем пытаться стать непобедимым во всем и не преуспеть!

1

«Можно с уверенностью сказать» - любимая вводная фраза всех предсказателей «Контроль» здесь - это все области, связанные с управлением рисками, аудитом, безопасностью и обеспечением соответствия нормам и правилам. 3 См. I Think Something is Missing From ITIL, Clayton Peasley and Sutherland, Red Swan 2006, ISBN 1933703067 4 www.markdisomma.com/upheavals.asp 2

22

...и ещё он сказал: «Передовой опыт выглядит в точности как обычная практика». Нельзя сформировать конкурентные преимущества делая то, что делают все вокруг. В этом случае проблема не в ITIL, а в слепой готовности принимать «лучшие практики» как единственный приемлемый способ деятельности. Вот что говорят об этом «Основные практики»1: Не всем нужны лучшие практики, и не все могут себе их позволить. Мы полностью поддерживаем следование передовому опыту для тех компаний, которые обладают достаточными ресурсами, верой и причинами для того, чтобы следовать ему - в определенной области или сфере деятельности. Тем, кто не обладает этим всем, нужно что-то более прикладное. Именно таким компаниям (небольшим, только что основанным, или вынужденным экономить) и адресованы Основные практики. «Если больше вы ничего не делаете, делайте хотя бы это». Мы сокращаем Core Practice до СоРr и произносим это как «Copper2». Почему Copper? Во-первых, так читается сокращение, что вполне очевидно, но есть и другая причина. Дело в том, что это в самом деле не золото. Нужно золото? На рынке полно желающих продать его вам. Мы продаем медную версию. Она почти так же выглядит и обладает почти (!) такими же свойствами, но за существенно меньшие деньги. «Лучшие практики» стали чем-то вроде священной коровы современного бизнеса. Считается само собой разумеющимся, что организации хотят следовать лучшим практикам во всем, что они делают, а те, которые не хотят, в чем-то хуже тех, что хотят. Это неправильно. Следование передовому опыту - это стратегическое решение, которое должно приниматься в случаях, когда инвестиции, связанные с мим, будут сочтены оправданными... Мы убеждены, что мир готов к Основным практикам: стратегическому решению о снижении затрат через реализацию деятельности, достаточной для (l) выполнения обязательств и (2) снижения рисков для организации и заинтересованных лиц до приемлемого уровня. [звучит так, как будто мы3 что-то продаем вам (но «за существенно меньшие деньги»). Это не так. Основные практики бесплатны. Основной акцент СоРr - на малый бизнес, так что корпорации, ищущие для себя «быстрый и легкий вариант ITIL», скорее всего, не смогут обойтись основными практиками. Извините.] Рекомендации 8. Внедряйте ITIL (а равно любые другие «Лучшие практики») только если это обосновано. Если нет - не тратьте зря свою энергию и ресурсы организации. 9. Если вам в самом деле нужно золото, попробуйте поискать его в альтернативных источниках; возможно, это поможет вам опередить толпу, наперегонки бегущую к «лучшему».

Культ ITIL Временами ITIL демонстрирует явные признаки культа. Вот, например: Как определить, что процесс - плохой и нужно внедрять ITIL? •

Явный признак - низкая оценка по модели зрелости ITIL.

Что это за модель? •

Написанная в ITIL.

А как получить более высокую оценку? 1

Core Practice, www.corepractice.org Copper - медь (как металл и мелкая монета) 3 Основные практики придумал автор этой книги 2

23

•

Быть ближе к определениям в ITIL.

Кто выбирает определения и проводит оценку? •

Консультанты, которые исправляют процессы. Нам не кажется, что это цикл? «Может, на практике это и работает, но сомневаюсь, чтобы это было теоретически возможно»1 Что будет, если мы попробуем оценить действующие процессы, используя независимые измеримые показатели полезности для бизнеса, или возврата инвестиций, или чего-то ещё, что в самом деле волнует организацию? Мы можем обнаружить, что процессы не отвечают модели ITIL, но работают. В этом случае, возможно, нет оснований их менять. Любой, кого хоть раз останавливали на улице милые люди с предложением погадать, прочесть судьбу и предсказать будущее, знает этот прием: скажите человеку, что его дела плохи, а потом предложите способ всё исправить. Сообщество, которое определяет, что такое «хорошо» и что такое «плохо» на основе сравнения с собственными книгами, а потом заявляет, что в этих книгах - ключ к улучшению, чем-то похоже на секту. Прислушайтесь к её проповедникам: Первый шаг к изменениям - базовый тренинг ITIL: пока люди пребывают в неведении, они не спасутся. Неважно, как они называют свои процессы сейчас, они должны узнать правильные названия. «Если вы не знаете моего учения, то вы ничего не знаете». Следующий шаг - поддержка высшего руководства. Первое правило миссионера: если хочешь обратить всё племя, сначала обрати их вождя. Теперь надо найти способ реализовать культурные изменения, иначе говоря - преодолеть сопротивление. В недавнем исследовании «72 процента определили сопротивление организации как главный барьер на пути к ITIL». Здравствуйте, приехали. Почему вы думаете, что вы - правы, а они - нет? Перед тем как сметать сопротивляющихся со своего пути, хотя бы выслушайте, что они говорят. Избегайте фанатизма. Часто он становится проблемой недавно вставших на путь ITIL консультантов. Более опытные практики ITIL проявляют больше гибкости. Самые опытные, те, что писали ITIL, недаром сделали одним из базовых принципов ITIL «adopt and adapt» «принимать и применять». Очень часто об этом принципе забывают. Рекомендации 10. Проводите оценку и измерения используя в качестве основы что-то отличное от предлагаемого решения (см. «Измерение ITIL при помощи ITIL» стр. 30). 11. Если организация сопротивляется, на то могут быть причины. Убедитесь, что предпосылки для внедрения ITIL определены верно. 12. Не позволяйте никому давить на вас авторитетом («У меня гораздо больше опыта в ITIL», «Я - ITIL Master», «Вы ведь не были на тренинге»). 13. Не увлекайтесь формальным соответствием букве ITIL. 14. И главное: избегайте фанатизма. Откажитесь от позиции «мы делаем это, потому что так написано в книжках, и точка». «Сомнение - не самое приятное состояние, но уверенность - просто нелепа». Вольтер

Потому что все делают это Согласно упомянутому выше исследованию 2, 1

«The Making of a French Manager», J. Barsoux and P/ Lawrence, Harvard Business Review (July-Aug., 1991): 58-67. North American Information Technology Infrastructure Library (ITIL) Benchmark, Evergreen Systems, 2006, www.evergreensys.com/campaign/itil_benchmark_2006/blog/index.htmI

2

24

•

72 процента опрошенных называют самым серьёзным препятствием на пути принятия ITIL сопротивление внутри организации. Второе место с существенным отрывом занимает неуверенность в вопросе «с чего начать» (34%). • ITIL быстро становится важной частью жизни корпоративных ИТ. 36% респондентов реорганизуют процессы предоставления услуг (Service Delivery), 29% планируют реализацию всех 10 процессов [ITIL2], • Большинство программ внедрения ITIL реализуются в опасном вакууме. При том, что около 95% опрошенных следуют рекомендациям ITIL при организации эксплуатации услуг, менее 20% что-либо знают о COBIT или CMMI. • «В то время как всё большее число СЮ признает полезность ITIL, не может не тревожить распространенная комбинация неэффективного планирования, сопротивления нововведениям и необходимости преобразований уровня всей организации. Многие инициативы не принесут никакой пользы, пав жертвами неэффективного планирования в сочетании с нехваткой поддержки руководства и финансирования», - сказал Дон Кассон, президент и генеральный директор Evergreen. Обычно эти факты подчеркиваются теми, кто стремится устранить симптомы. Мы же исследуем корневую причину. Приведенные данные говорят о том, что люди ввязываются в проекты внедрения ITIL лишь потому, что все остальные тоже делают это. У них нет поддержки в организации, они не знают контекста и не изучали альтернативных подходов, и около трети из них пытаются действовать кавалерийским наскоком, без какого-либо планирования. Как-то не очень верится, что у трети организаций все десять основных процессов ITIL2 в настолько плачевном состоянии, что существует разумное обоснование проекту по корректировке их всех. Есть мнение, что все 10, или 13, или 27 процессов надо перестраивать вместе, потому что они все взаимосвязаны. По мере роста ITIL от версии к версии этот тезис выглядит всё менее и менее убедительным. Конечно, одно из преимуществ ITIL состоит в том, что процессы рассматриваются гам во взаимодействии, а не изолировано, но это не отменяет возможности использовать на практике отдельные рекомендации. Люди делают это ежедневно, и у них получается. Начните там, где это действительно нужно, там, где болит, посмотрите, помогает ли (если помогает — покажите остальным), и тогда решайте, какой шаг будет следующим. Попытки съесть слона целиком, как правило, заканчиваются провалом. Хуже того. Вот что написано в исследовании, проведенном itSMFUSA 1: Затем был задан вопрос о том, как компании измеряют зрелость своих ITILпроцессов. Только четыре процента респондентов сказали, что зрелость всех их процессов измеряется, и менее трети участников опроса заявили, что обладают инструментами для оценки зрелости всех ITIL-процессов. На вопрос о том, как им удается связать повышение производительности с результатами оценки зрелости процессов, только девять процентов респондентов заявили о понимании и способности измерять такие связи. При этом 72% (!) заявили о том, что не видят никакой связи между зрелостью процессов и повышением производительности. Есть в этом исследовании что-то от самобичевания, верно? В этой статистике слышатся орды фанатиков, сметающих здравый смысл на пути к великой цели - незамутненной чистоте ITIL. Рекомендации 15. Внедряйте ITIL, если для этого есть бизнес- обоснование, и только в этом случае. (См. дискуссию об обосновании ITIL, стр. 39) 16. Реализуйте ITIL постепенно. Обеспечьте измеримость каждого этапа. Начинайте там, где это наиболее необходимо или выгодно. 1

itSMFUSA Research Letter, Volume 2, Issue 4, April 2006 data.memberlicks.com/site/itsmf/Research_Newsletter_April_2006_Issue.pdf

25

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

• •

Провести количественный анализ затрат и выгод от внедрения ITIL (в сравнении с другими подходами к оптимизации деятельности, или простым наведением порядка, или простым внедрением ПО Service Desk) на статистически значимой репрезентативной выборке предприятий. Провести анализ затрат и выгод в организациях, использовавших в своей практике только ITIL, без одновременного применения SixSigma, CMMI или других программ управления качеством, способных повлиять на общий результат. Провести оценку доли организаций, получивших в итоге пользу от внедрения ITIL.

Никто не говорит, что ITIL не даёт результата, просто нет достоверных свидетельств, что даёт. То есть любое решение о внедрении ITIL, в частности - ваше решение, основано на опыте, инстинкте и интуиции, а не на точном расчёте и тщательном анализе. Если вы принимаете такие решения, полагаясь на мнения аналитиков и поставщиков (то есть так, как все их принимают), вот интересная информация к размышлению 3: В исследовании, охватившем 125 организаций на 400 площадках, около половины организаций, внедривших ITIL, не получили измеримых преимуществ в качестве услуг или скорости решения инцидентов. «Иногда [обычный] helpdesk превосходит в производительности тех, кто следует лучшим практикам в этой области. Лучшие практики не обязательно означают высшую производительность. ITIL - не единственный путь развития, а лишь один из возможных». Нот данные ещё одного исследования 4: «Вы готовили бизнес-обоснование, принимая решение о внедрении?» (исследование 62 европейских компаний): «Нет» - 68% Это ДВЕ ТРЕТИ. «Вы оценивали возврат инвестиций?» (20 европейских компаний): «Нет» - 50%, «Не знаю» - 30%, «Да» - 20%.

1

The Capability Maturity Model: Guidelines for Improving the Software Process, Paulk, Weber, Curtis, and Chrissis, SEI Series in Software Engineering, Addison-Wesley, 1995. 2 CMMI Overview, Carnegie Mellon SEI, 2005 http://ru.wikipedia.org/wiki/CMMI 3 ITIL Experts Warn on Compliant Software, Datamonitor Computerwire. 26 January 2006, www.computerwire.com/industries/research/?pid=8673Di22-721B-4450-8C57-30A9665D4BA2 4 Firms Must Take ITIL Beyond IT Operational Goals, R. Peynot, Forrester, March 14, 2006 i.i.com.com/cnwk.id/html/itp/Front_Range_ITIL_Beyond_Goals.pdf

26

Раз уж только треть компаний выполняли бизнес- обоснование, можно предположить, что у нихто причины внедрять ITIL в самом деле были. И тем не менее только 20% из них получили ожидаемые значения ROI! Ирония в том, что собственно ITIL всячески подчеркивает важность как бизнес-обоснования, так и необходимости оценки ROI. Но на практике лишь немногие компании думают об обосновании самого внедрения ITIL, и ещё меньшее число измеряет результаты таких проектов. Те же, кто измеряет, строят свои обоснования в отсутствие каких-либо достоверных исследований, способных подтвердить или опровергнуть их предположения. Остаток этой главы описывает свидетельства, которые можно получить на практике, так что на их основе вы можете судить об успешности проекта. itSMF itSMF в своей книге «An Introductory Overview of ITIL»1, основанной на ITIL2, обещает: Сокращение времени простоев сервисов на 70 и более процентов Повышение ROI более чем на 1000% Сокращение затрат на £100 млн. в год Сокращение времени вывода новых продуктов на рынок более чем вдвое. Никаких ссылок, объяснений или обоснований не приводится, но источник авторитетный, а цифры впечатляющие. Академические исследования До своего исчезновения Группа исследования лучших практик (a Research Unit, BPRU) была представлена сайтом2, утверждавшим, что она связана с проектом обновления ITIL до версии 3. Учитывая двадцатилетнюю историю ITIL, появление такой организации закономерно. И даже как-то стыдно говорить, что ни со стороны OGC, ни со стороны itSMF, не было попыток создать подобную исследовательскую группу (нечто похожее делает только itSMF USA). На сайте BPRU в отношении проблемы свидетельств полезности [было] написано следующее: Множество материалов по управлению ИТ, и в том числе - по управлению ИТ услугами, носит оттенок назидательности, нормативности. Лишь немного детальных научных исследований было предпринято для оценки новых инструментов, техник, методов и подходов с точки зрения успешности и полезности их внедрения. Существует опасность того, что новые подходы возникают за пределами профессионального сообщества и практически не подтверждены реальным опытом. «Немного научных исследований» - это мягко сказано. Единственное такое исследование, известное Скептику - это работа под громким и неподтвержденным заголовком «Свидетельства эффективности использования подхода ITIL»3. Она открывается словами «В области лучших практик управления ИТ почти не существует академических исследований...», а итоги самой этой работы выглядят так: Мы выяснили, что удовлетворенность заказчиков и операционная производительность повышаются по мере следования подходу ITIL. Следовательно, использование ITIL способствует повышению удовлетворенности заказчиков и операционной производительности. Хотя исследование ограничилось одной организацией, заявления руководителей этой организации и OGC относительно вклада ITIL в эффективность деятельности можно считать 1

An Introductory Overview of ITIL, C. Rudd, itSMF 2004 Скептик приводит здесь ссылку на сайт www.tonybetts.com/about_bpru. С комментарием о том, что сама страница BPRU более не существует. На момент подготовки русского издания не существует и www.tonvbetts.com. 3 Evidence that use of the ITIL framework is effective, B.C. Potgieter. J.H. Bolha, C. Lew www.naccq.ac.nz/conference05/proceedings_04/potg_itil.pdf 2

27

подтвержденными. Для уточнения связи между использованием ITIL и производительностью необходимо провести более детальные исследования, в особенности - направленные на уточнение роли каждого процесса ITIL. Объектом для проведения исследования явилась «крупная сервисная организация, внутреннее подразделение структуры местной власти в северной Африке в 2002/03 годах». Одна площадка, локальная властная структура... не лучшая база для исследования. Что ещё важнее, основными предметами изучения, позволившего сделать такие громкие выводы, стали (l) удовлетворенность заказчиков (было проведено три опроса, из них один - среди менеджеров, то есть всё, что можно сказать - рядовые пользователи, кажется, были счастливы) и (2) «объективное качество услуг», которое оценивалось по «числу обращений, зарегистрированных службой поддержки», потому что «можно уверенно сказать, что число зарегистрированных проблем прямо отражает общее качество сервиса». Последнее утверждение совершенно обесценивает это исследование в глазах всякого, кто хоть немного понимает в ITIL и ITSM. Никакого анализа затрат и выгод. Ни одной объективной метрики. Если выкинуть достаточное количество казённых денег на что угодно, и сопроводить это вполне агрессивной PR-кампанией, пользователи, весьма вероятно, будут счастливы в связи с этим «чем угодно». Это не доказывает вообще ничего. Те, кто обладает опытом в этих вопросах, согласятся, что снижение числа обращений пользователей в первые месяцы работы службы поддержки - повод не радоваться, а волноваться. Но можно спорить, что этот документ будет цитироваться направо и налево как авторитетное свидетельство эффективности ITIL. Остерегайтесь. Аналитики Когда-то Скептик ввел понятие «фекафакта»1. Фекафакты - это полная чушь, которая выглядит в точности как факты. Наиболее активными извергателями фекафактов являются аналитики, вплотную за ними в рейтинге держатся вендоры и консультанты. Большинство опубликованных аналитических «исследований»: • • • • •

• •

Выполнялись с целью подтвердить определённое утверждение. Похожие исследования в области раковых заболеваний проводятся по заказу табачных компаний. Направлены на привлечение внимания к вопросу и демонстрацию компетенции исследователей, а в конечном итоге - на формирование спроса на их услуги. Бессистемны и субъективны. Произведены заинтересованными, а не независимыми исследователями. Отсюда обороты типа: «Как вам удалось такое чудо?..», «Верные решения были приняты благодаря...», «Отдача на сделанные инвестиции составила...» Непрозрачны, а потому невоспроизводимы: какова была методология исследования? Какие вопросы задавались? Как формировалась выборка? Как обеспечивалась валидность результатов (если как-то обеспечивалась)? Где посмотреть на собранные необработанные данные? Ненаучны. Нет контрольных групп для сравнения. Нет слепой выборки. Собранные данные не раскрываются, проверка выводов невозможна. Респонденты выбираются заинтересованными лицами. Не проходят экспертную оценку. Где профессиональные журналы и конференции, с учеными в редколлегиях? Ну или хотя бы веб-сайт? (Примечание: itSMF планирует в 2009 году выпуск такого журнала2).

Компания Гартнер (Gartner) - по всей видимости, самые известные аналитики в ИТ. Во многих текстах и презентациях можно встретить цитаты, согласно которым они ожидают «сокращение на 48% затрат на ИТ благодаря реализации принципов сервис-менеджемента». Первоисточник 1

Crap Factoids, www.itskeptic.org/crap-factoids Примечание переводчика: на осень 2010 был выпущен один номер (http://www.itsmfi.org/content/new-itsmfinternational-magazine-your-service-launched), об экспертах в редколлегии информации не поступало. 2

28

найти не удалось, но цитируют его постоянно. Легко узнать это заявление по авторитетным «48%». Не пятьдесят, сорок восемь. Возможно, тщательные раскопки приведут нас к настоящим исследованиям, но в большинстве случаев это просто разговоры. Вот лишь один пример (Forrester Research). Документ называется Application Mapping For The CMDB1. Девятнадцать страниц о том, как-хорошо использоватьинструменты-формирования-связей-между-приложениями-и-инфраструктурой: «лучшее понимание того, как приложения передаются в эксплуатацию ... лучший контроль над изменениями в инфраструктуре и приложениях ... возможность контролировать спиральные (!) затраты на приложения ... больше возможностей для консолидации инфраструктуры ... лучшее планирование резервных площадок» ... излечение бородавок ...синергия Запада и Востока …и сравнение восьми систем. Ни одного слова о том, полезны ли в итоге эти системы и работают ли в них эти чудодейственные связи. Проведенное Forrester исследование эффективности систем состоит из таких понятий, как «успех у заказчиков», а все измерения выполняются исключительно с точки зрения вендора. Что до функциональности, то «оценивались возможности систем по построению схем и обнаружению изменений. Рассматривались задачи по сбору данных, необходимость ручного» ввода, глубина собираемых данных, безопасность и сопровождение итоговой CMDB». Очевидно, не рассматривалась применимость итоговой модели для управления услугами. Они проделали это путем (l) опроса вендоров и (2) опроса сотрудников «трёх компаний, которые провели независимое изучение продуктов». Никакой информации о том, использовали ли эти компании те продукты, и о том, как тестировали, и о том, как оценивали результаты; возможно, компании просто ознакомились с брошюрами, написанными поставщиками. И нет никаких указаний на то, что исследователи Forrester видели хотя бы одну из систем в действии, не говоря уж «инсталлировали и тестировали самостоятельно». Для невнимательного читателя - а большинство читателей как раз невнимательны девятнадцатистраничный документ с картинками, схемами и таблицами выглядит весьма авторитетно. Большинство пробежит его по диагонали, задержится на табличках, где системы проранжированы, и решит, что это, наверное, объективная оценка, а не очередная попытка продать что-нибудь ненужное. Нужно больше примеров? Их2 можно найти у любой аналитической фирмы, отнюдь не только у упомянутых здесь (один из наиболее вопиющих случаев искажения фактов и фальсификации статистических данных описан здесь: www.itskeptic.org/node/709.) Аналитические компании нанимают умных ребят, которые хорошо понимают, куда движется мир. Ребята ходят по миру, из отрасли в отрасль, слушают, смотрят и думают. Часто они говорят интересные вещи. Почти всегда они говорят лучше, понятнее и честнее, чем вендоры. Главное не читать «исследований», которые они иногда публикуют. Помните, что аналитики существуют для того, чтобы стимулировать изменения. Они всегда интерпретируют. Им интересно провоцировать развитие, в частности - широкое использование очередной мега-системы для получения счастья. Им бы следовало честнее именоваться: внешний маркетинг. Вендоры это усвоили и используют. Имейте это в виду. Рекомендации 17. Не ждите объективного обоснования ITIL. Определите способ получения субъективного (вашего) обоснования. 18. Делите на два или игнорируйте любые значения, заявляемые аналитиками и/или вендорами.

Не надо «внедрять ITIL» 1

The Forrester Wave: Application Mapping For The CMDB Q1 2006, Forrester, www.cnetdirectintl.com/direct/bmc/Q3_2006/еbook/Service_Management/UK/registration.htm 2 См. www.itskeptic.org/analvsts.

29

Остерегайтесь предложений, содержащих слова «внедрение ITIL», или «запуск управления инцидентами», или «применение управления изменениями». Они могут указывать на некорректное, ограниченное понимание ITIL (впрочем, каждый хоть иногда, но использует подобные формулировки). Вы не внедряете процессы, а улучшаете1 их (см. далее замечания о том, почему такие проекты лучше рассматривать как трансформацию, а не внедрение). Все и так управляют инцидентами. Вопрос в том, насколько хорошо они это делают. Для ответа на этот вопрос обычно используется модель зрелости СММ, от первого до пятого уровня. Если кто-то говорит, что у него нет процесса, процесс есть - просто на первом уровне2. Работа делается, инциденты происходят и устраняются. Просто они делают это бессистемно, хаотически. ITIL - о постоянном улучшении услуг, и основа улучшения - процессная модель, которую можно использовать, определяя, документируя и направляя свои собственные процессы. То есть вы не «внедряете управление инцидентами», вы пытаетесь поднять его зрелость со, скажем, первого уровня до, скажем, третьего. Это улучшение - постоянная деятельность. Первый проект - лишь первый шаг. Для того, чтобы защищать, развивать и использовать его результаты, нужна постоянно действующая программа управления качеством. Если вы знакомы с циклом Деминга, ищите в предложениях по «внедрению» следы его применения. Очевидно, что если колесо улучшений не поддерживать и не толкать вверх, оно неминуемо катится вниз. Если авторы предложения этого не понимают - они не понимают главного. Рекомендации 19. Ищите в предложениях о внедрении ITIL указаний на целевой уровень зрелости улучшаемых процессов (и оценку текущего уровня). 20. Убедитесь, что предложения содержат меры по измерению, обеспечению и улучшению процессов. Решите, делать ли эти меры предметом оценки при расчете затрат и ROI. 21. Сделайте итоговый уровень зрелости основным KPI проекта. Но избегайте измерения ITIL с помощью ITIL, используйте независимые источники. (См. Измерение ITIL при помощи ITIL, стр. 30).

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

1

Для солидности можно использовать слово «совершенствуете». (Прим.переводчика) Почти всегда. Однажды автор видел полное отсутствие управления проблемами и однажды - управления изменениями и релизами. Разработчики меняли код в продуктивной среде, когда видели в том нужду... на мейнфрейме IBM System370. 2

30

Рекомендации 22. Подумайте об использовании COBIT (или eSCM, или ISO 20000) для измерения зрелости своей организации. В них есть доступные структурированные метрики, которые неплохо зарекомендовали себя, например, при проведении аудитов. 23. Может быть, имеет смысл позвать консультантов для проведения обследования. Но перед тем как сделать это, скачайте COBIT (бесплатно, в отличие от ITIL) и оцените собственные силы. 24. Установите KPI, отражающие бизнес-причины вашего ITIL-проекта. Если вы собираетесь повышать доступность, оценивайте проект по итоговой доступности. Если удовлетворенность клиентов - по удовлетворенности. 25. Возможно, будет полезно непосредственное измерение культурной зрелости. Конечная цель - изменить поведение людей, так что мерить можно ABC (Attitudes, Behaviour, Culture - отношение, поведение, культуру). Прибегните к помощи профессионалов (вам понадобятся консультанты в HR, а не в IT). Один из клиентов сказал мне: «Если мы будем измерять удовлетворенность заказчиков вместо соответствия ITIL, они будут хитрить и найдут другие способы повысить её, вместо того, чтобы использовать ITIL». Я спросил: «Ну и что?»

Не надо чинить то, что работает Возможно, одна из самых печальных картин в мире ITIL - организации, внедряющие процессы из книг в то время как их собственные процессы отлично работали. Вот Скептик недавно завершил ремонт дома. Это и до ремонта был хороший дом: крыша не текла, двери были прочными, было чисто и не было пожарной опасности. Ремонт был не лучшим вложением средств, мы делали его скорее для удовольствия. В случае продажи дома мы не получим от вложений в ремонт сколько-нибудь существенной отдачи. Если я решаю тратить собственные деньги на изменение внешнего вида своего собственного дома, это моё право: деньги-то мои. Деньги, на которые внедряется ITIL, не мои. Можно сорвать отличный ковёр с целью тщательной полировки пола под ним. Очень занимательно, но вполне бесполезно. Таковы многие проекты по внедрению ITIL. ИТ-эксплуатация - это область, неизменно привлекающая перфекционистов. Здорово ведь, когда доступность сайта заявляется как 99.999%! Беда в том, что перфекционисты вовлекают в свою деятельность всех вокруг, заражая их Излишней Технической Скрупулезностью (ИТС)1. Технари любят полноту и точность, не говоря уж о нежном пристрастии к сложным, умным и изящным решениям, независимо от наличия задачи. В результате мы получаем ИТС: стремление делать вещи правильно независимо от того, будет ли это полезно, рационально, выгодно и разумно - то есть от того, имеет ли это смысл. Есть и те, кто инициирует изменения, потому что изменения дают им власть. Замечательный бизнес-комментатор Скотт Адаме сказал2: «Изменения - отличная штука для тех, кто их вызывает. Эти люди понимают новую информацию, добавляемую в мир, лучше прочих. Они выглядят умнее этих прочих». Кроме описанных, встречается такое явление как «Новый ИТ-директор». Ну, тот-кто-призванвсё-изменить. Бывает, что призван и не для этого, но всё равно старается начать с перемен. Хорошие руководители находят то, что работает, и стараются не сломать. Все перечисленные проекты объединяет одно: они возникают потому, что кто-то решил: «отличная идея!». Возросшее в последние годы внимание к тому, как ИТ тратит деньги бизнеса, снизило число таких проектов, но их по- прежнему хватает.

1

Феномен ИТС первые описан Скептиков в книге «Введение в реальный ITSM», Гаятри/Livebook, 2010, ISBN 978-5904584-05-4, а также на www.realitsm.com 2 The Dilbert Principle: A Cubicle's-Eye View of Bosses, Meetings, Management Fads & Other Workplace Afflictions, S. Adams, Collins, 1997 ISBN-13:978-0887308581

31

Рекомендации 26. Не ограничивайтесь в принятии решений аргументами типа «потому что я так думаю» или «потому что все так делают». 27. Не ограничивайтесь аргументом «станет лучше». И что? Сейчас - плохо? Текущие или ожидаемые требования бизнеса не удовлетворяются? 28. Если оно работает - не чините. Используйте деньги там, где они принесут пользу. Когда-то автор работал в большой компании, которая занималась разработкой программного обеспечения. Как-то раз СЮ этой компании давал интервью журналист, который задал вопрос о том, используется ли в компании ITIL. А надо сказать, что это была в самом деле немаленькая компания: глобальные сети, множество серверов, десятки тысяч пользователей... И она продавала систему для Service Desk. Было ужасно интересно, что же СЮ ответит. Автор знал, что ITIL в компании не используется, и неоднократно обсуждал это обстоятельство с коллегами (как и он, не имевшими веса в обсуждаемом вопросе): как это мы умудряемся продавать ПО для ITIL, не следуя ITIL в своей работе (но вовсю используя то самое ПО)? Ответ, данный СЮ журналисту, был таким: нет, мы не используем ITIL, потому что наши собственные процессы отлично работают. Если перестанут - мы рассмотрим ITIL как возможный подход к их улучшению. В тот раз компанию просто закидали камнями, но она продолжила успешно работать. Несмотря на оказываемое давление и политические соображения, СЮ не собирался тратить деньги на модные штучки.

CMDB не бывает CMDB - это централизованное хранилище информации обо всех объектах, управляемых ITIL, и связях между ними. CMDB описывается ITIL, начиная с самой первой версии. Из ITIL2 было непонятно, является ли CMDB единым физическим хранилищем. В ITIL3 явно сказано, что не является, кроме тех мест в тексте, где это по-прежнему непонятно. Оценивая любые предложения по внедрению ITIL тщательно изучите планы по развитию CMDB. Скептик настаивает на том, что создать на практике CMDB, описанную в ITIL, за разумные деньги невозможно. Такая работа потребует огромных ресурсов и как следствие - огромных и неоправданных затрат. Те организации, которые стремятся поднять зрелость управления конфигурациями до четвёртого или пятого уровня, вероятно, попытаются проделать эту работу. Остальные остановятся на этапе обоснования затрат. Вот ещё пример: корпоративный самолёт при правильном подходе может, наверное, оправдать связанные с ним инвестиции. Будет ли это оптимальным способом потратить деньги с учётом других вариантов - отдельный вопрос. Надо сказать, что так рассуждает меньшинство, но всё же не только автор этой книги. С CMDB связано много споров1. Дополнительную информацию по теме можно найти на сайте Owning ITIL2. CMDB как ERP для IT3 Есть мнение, что CMDB объединяет всю-всю информацию об ИТ так же, как ERP объединяют всю-всю информацию о предприятии в целом. Вопрос о полезности ERP - отдельная интересная тема. Есть множество примеров, когда ERP привели компании на грань краха или перевели через эту грань. Автор не знает ни одного проекта, в котором ERP оправдали бы сделанное бизнес-обоснование. 1

www.itskeptic.org/cmdb www.itskeptic.org/ownitigitil 3 Прим. переводчика: «База данных управления конфигурациями как система управления ресурсами предприятия для информационных технологий». Или «Си Эм Ди Би как И Ар Пи для Ай Ти». В общем, нет пока устоявшегося перевода названия этой главы. 2

32

Хотя, конечно, есть организации, которые достаточно велики, широко распределены и безумны для того, чтобы инвестиции в ERP себя оправдали. Но утверждать на этом основании, что инвестиции в CMDB тоже себя оправдают, - это всё равно что утверждать, будто бы использование тяжелой транспортной авиации компанией DHL для доставки грузов автоматически оправдывает использование тех же самолетов для доставки молока в столовую компании DHL. То, что организация управляется при помощи супердорогого чуда техники, ещё не значит, что такое же чудо должно управлять объектами ИТинфраструктуры. ITIL убеждает нас, что нам нужен А380, в то время как денег у нас как раз достаточно для покупки ручной тачки. С ней мы идём на крышу и пытаемся полететь. Результат нетрудно предвидеть. Жизнь без CMDB Многочисленные ERP, базы данных, словари данных, хранилища, каталоги не преуспели в деле унификации среды, в которой мы существуем. CMDB тоже не справится (а равно Web Services, SOA, .NET...). Очнитесь и прекратите изобретать магическую систему для управления всем на свете. Давайте позволим нашим данным пребывать в неполном порядке. Давайте отойдем от принципа «всё должно быть полным и корректным». Можно жить и без CMDB... ...и отлично себя чувствовать. Статистически управление конфигурациями - один из самых редко внедряемых процессов. Одно исследование, проведенное в 2008 году1, показало, что 30% крупных организаций (то есть тех, что могут позволить себе CMDB) утверждают, что у них есть что- то, что они так называют. Скептик оценивает долю организаций, использующих СМОВ-какэто-понимает-ITIL как 2%-5%. Возникает вопрос: а как остальные справляются? Управление инцидентами / проблемами / изменениями чудно довольствуется базой активов. И не так уж важно, что управление релизами, доступностью или непрерывностью использует другие источники информации. Перфекционисты считают, что источник информации должен быть общий, но если это правило нарушается, ничего особенно страшного не происходит. Здорово, если удается хранить базовую информацию о зависимостях между ключевыми КЕ2 и услугами. Опыт показывает, что большинству организаций неплохо удается вручную поддерживать эти связи в порядке для пары- тройки десятков услуг. Всего услуг немного больше - обычно в несколько раз. И люди просто выбирают наиболее важные для того, чтобы вести учёт связей. Что происходит с остальными? Они просто работают. Как всегда это делали. И если надо, анализируются «на лету». И это помогает. Пока вам не нужно управлять конфигурациями на уровне зрелости выше третьего, вы можете делать это без CMDB. Многие так поступают. У вас может быть реестр активов, средства удаленной диагностики и управления, система управления закупками и даже каталог услуг. И не быть CMDB в понимании ITIL. С другой стороны, если вы NASA, или Boeing, или Tata, или EDS, не обращайте на меня внимания. Вы ищете пятого уровня зрелости, и для большинства процессов это потребует CMDB... ну или работ по её созданию. Скептик по-прежнему сомневается, что эти работы закончатся построением идеальной CMDB. И будьте готовы к тому, что попытки дорого вам обойдутся. О том, что делать со своей CMDB, читайте в главе «Ограничьте управление конфигурациями», стр. 53. Рекомендации 29. Убедитесь, что управление конфигурациями использует прагматический подход, собирая необходимый минимум данных. 30. Маловероятно, что начинать использование ITIL стоит с построения CMDB. Убедитесь, что начали с более важных вещей. 1 2

How to Develop Your CMDB Project's ROI, EMA, 2008, white-papers.techrepublic.com.com/abstract.aspx?docid=386941 КЕ, или CI = Конфигурационная Единица/Configuration Item, так ITIL называет предметы.

33

31. Начните с каталога услуг (см. стр. 52): сформируйте его техническую версию для персонала ИТ. В этом техническом каталоге укажите ключевые КЕ, поддерживающие каждую услугу. Если персонал ИТ заслужил новую игрушку, внесите услуги в систему Service Desk и свяжите их с ключевыми КЕ. Но держите эту игрушку под строгим родительским контролем: она должна сохранять управляемость за разумные деньги. Возможно, в этот момент вы подойдёте к CMDB на максимально возможное расстояние. На одной ITIL конференции представитель государственной структуры рассказывал мне о том, какая у них будет замечательная CMDB благодаря мудрому решению включать в неё только важное, оставляя за бортом все лишнее. - Что лишнее, например? - спросил я. - Например, персональные компьютеры. - А на них нет важных приложений? - уточнил я. Тут же выяснилось, что ключевые системы имеют архитектуру «клиент-сервер», так что компьютеры придется включить в CMDB. - Но там не будет периферии, всяких там принтеров... - Вот как? А какова доля обращений пользователей, связанных именно с принтерами? - ОК, пусть принтеры будут. Но не мышки же с клавиатурами! - Мммм... Вы ведь госслужба? Вам приходится прислушиваться к требованиям охраны труда и быть политкорректными? Среди ваших сотрудников есть инвалиды, которым нужны специальные устройства ввода? К этому времени он был бледен, потен и неприветлив.

Референтные площадки Мало кому надо рассказывать о том, насколько объективную информацию дают референтные визиты на площадки, рекомендованные вендорами. Просто для полноты картины уточним, почему такие визиты не должны влиять на ваши решения при оценке обоснований внедрения ITIL. Референтные площадки формируются вендорами одним из четырех механизмов: • • •

•

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

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

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

Совместимость с другими методологиями Если ваша организация уже использует RUP, SDLC, Agile, СММ, PMI, COBIT, 6Sigma, TQM или что-то в этом роде, убедитесь, что в ITIL-проекте запланировано привлечение экспертов из этих областей для того, чтобы обеспечить интеграцию 1TIL с ними. Учитывайте, что в ITIL не описаны интерфейсы к этим подходам, а кое-где между ними возникают противоречия. Даже ITIL3 всё ещё не вполне обеспечивает интеграцию с ISO 20000, часто вульгарно именуемым «Стандарт ITIL», не говоря уж о прочих подходах и методологиях (см. «Стандарт», стр. 13). Рекомендации 34. Требуйте учета действующих связанных методологий при оценке влияния внедрения ITIL. 35. Требуйте оценки работ по формированию интерфейсов.

Преимущества ITIL Как мы выяснили (см. «Не ждите доказательств», стр. 26), не существует достоверных свидетельств преимуществ ITIL в деле улучшения процессов управления ИТ по сравнению с другими подходами. Вы можете успешно оптимизировать свои процессы применяя вместо ITIL астрологию. Процессы всегда улучшаются, если уделять им достаточно внимания. Разница между ITIL и плацебо пока не исследована. В большинстве случаев в пользу ITIL говорит статус стандарта де-факто. Но не делайте это единственным фактором, влияющим на ваш выбор. Рекомендации 36. Убедитесь, что рассмотрели альтернативные варианты (см. «Альтернативы ITIL», стр. 18): MOF для влюблённых в Microsoft; COBIT, если он лучше соответствует вашим требованиям; ISO 20000 или SM-CMM если вы - поставщик услуг; или чтото простое, вроде FITS'a. 37. Возможно, можно поступить ещё проще. Как любое изменение процессов, ITIL подразумевает вовлечение людей посредством программы культурных изменений. Может, этой программы будет достаточно? Может, просто научить людей лучше работать в имеющихся процессах, уделить им немного внимания, дать им высказаться на семинарах, скорректировать распределение ответственности, чтобы процессы работали эффективнее?

Забавные расчеты эффективности Возможно, это для всех очевидно, но всё же: есть такой смешной способ обосновывать внедрение ITIL. Собственно, в нём нет специфики ITIL, он довольно универсален. Выглядит это примерно так: «Простой систем в прошлом году привел к потере компанией 185 миллионов долларов. Общее время простоя составило 83 часа, то есть каждая минута простоя обошлась компании в 37 тысяч долларов. Среднее время восстановления для инцидентов первого приоритета составляет около 150 минут. Согласно данным из презентации на конференции, где был кто-то из моих знакомых, внедрение ITIL обеспечивает сокращение времени восстановления на 10%. В прошлом году у нас было 22 инцидента первого приоритета, поэтому ожидаемое сокращение потерь для бизнеса в результате внедрения ITIL составит 22 х 150 х 0.1 х $37,000 = $12,000,000 в год при затратах на внедрение всего в $ 7,000,000, которые окупятся за 7 месяцев». 35

Самый красивый вариант такого обоснования, наглядно демонстрирующий его полную бессмысленность, выглядит так: «бла-бла-бла, поэтому пользователи будут тратить на 7 минут в день меньше на общение со службой поддержки. Имея 23 тысячи пользователей и оценивая стоимость разговоров с ними как $72,000 в год на каждого, мы оцениваем сокращение расходов в результате [бла-бла-бла] как $24,000,000 в год». Чепуха. Дополнительные семь минут свободного времени в день будут использованы пользователями для того, чтобы выпить лишнюю чашку кофе, или поболтать с коллегой, или подольше пообедать — если они вообще заметят разницу. То же касается попыток рассчитывать сумму потерь от часа или, ещё лучше, минуты простоя. Эти цифры хороши, чтобы демонстрировать участникам обработки инцидентов важность их работы, но не надо транслировать каждую сэкономленную минуту в выгоду для бизнеса. Исследования в области отдачи от инвестиций в ITIL могут дать полезную информацию отрасли в целом, но для конкретной компании вся доступная на сегодня информация вполне бесполезна. Эффективность в конкретной организации будет зависеть от того, насколько всё плохо в настоящее время. Так что информация о том, что некая компания получила ROI в сумме $7,43 от внедрения ITIL, не имеет к вашей ситуации никакого отношения. Если только ваши компании не близнецы. ITIL - не новая волшебная вещь, которой у вас раньше не было. ITIL - это перевод существующих процессов с одного уровня зрелости на другой (надо надеяться, более высокий). Так что результаты зависят от того, что есть на старте и насколько велика область возможных улучшений. Средние показатели потери веса при использовании некой диеты не определяют её возможное действие на мой организм, особенно - если я и без того недобираю в весе1. Если бы существовали такие таблицы, в которых можно было бы посмотреть средние показатели ROI при переходе с одного заданного уровня зрелости на другой, и если бы вы не пожалели денег на определение вашего текущего уровня зрелости, тогда обобщенная информация о ROI от ITIL имела бы для вас какой-то смысл. Но все, что мы имеем сейчас - недостоверные истории, рассказываемые аналитиками и вендорами о том, как одна компания сэкономила миллион долларов. Они (l) не влияют на ваши результаты и (2) в большинстве случаев - полная ерунда. Рекомендации 38. Старайтесь понять реальные выгоды от использования ITIL в вашей организации, не доверяйте забавным расчётам и выдуманным историям.

ASP или ISP Тонкая грань между этими понятиями - в том, какие именно услуги предоставляются организации (или какие услуги она хочет, чтобы ей предоставлялись). Помните ASP (Application Service Provider)? Сейчас их модно называть SaaS (Software as a Service). В конце девяностых они должны были полностью изменить современный бизнес. Не изменили, хотя некоторые интересные примеры успеха в этой области есть: SalesForce.com и ... э ... ну... SalesForce.com. На самом деле, есть, конечно, ещё несколько примеров, в том числе - связанных с ITIL. Самый известный - service-now.com, онлайн Service Desk. Многие департаменты ИТ на самом деле выступают как ASP в своей компании. Они предоставляют приложения, обеспечивая хостинг, обслуживание и поддержку, и иногда - в надежде получать за это деньги. Бизнес не интересуется инфраструктурой, обеспечивающей работу приложений. ИТ - это черный ящик. Пользователям не интересны насосы, им важно, что течет из трубы: бухучет, логистика, заказы... 1

Это просто аналогия, недобор в весе - это не про Скептика

36

Однако во многих случаях бизнесу нужен ISP (Infrastructure Service Provider, а вы-то думали, что «I» означает «Internet»). Бизнес управляет своими приложениями и ждёт от ИТ поддержки платформы (серверов, операционных систем, СУБД, сетей...) и выполнения работ по эксплуатации (безопасность, доступность, резервирование, восстановление...). Такой подход распространен в технических компаниях/подразделениях, но может неожиданно всплыть где угодно. «Правильного» варианта нет. Какая из этих моделей будет выбрана, должно быть определено в части бизнес-стратегии, посвященной информационным технологиям, но этот документ - за рамками нашей книги. Что по-настоящему важно, так это обеспечить одинаковое понимание роли ИТ всеми сторонами. Бывали случаи, когда разногласия и споры прекращались, как только стороны осознавали, что просто говорили на разных языках. Примечание: различие между ISP и ASP, вероятно, описано в книге Service Strategy (ITIL3). Кто знает... (Для тех, кто ещё не имел удовольствия читать это произведение, приведем такие слова1: «Потребуется год, чтобы впитать её содержимое, ещё один - чтобы осознать его в применении к практике, и дополнительное время, чтобы разложить впечатления по полочкам. ИТ-сообщество будет переваривать Service Strategy несколько лет. Лишь некоторые найдут эту книгу несъедобной. Большинство сформирует на её основе долговременный продовольственный резерв».) Рекомендации 39. Обсуждая ИТ-услуги, договоритесь предварительно о роли ИТ: ISP или ASP. Убедитесь, что все участники дискуссии - на одной волне. 40. Составляя каталог услуг, в каждом случае уточняйте, к какой модели относится конкретная услуга. 41. любом споре об услугах убедитесь, что причина разногласий - не в разном понимании роли ИТ (ISP/ASP).

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

ITIL Version 3 Service Strategy: An Early Review, The IT Skeptic, wwww.itskeptic.org/owningitil

37

Мегасофт остается игрушкой пилотной группы, процесс игнорируется или обходится. Инструкции собирают пыль. Другие проекты признаются успешными потому, что процесс начинает работу по-новому. Но через год-другой реальная работа все меньше походит на документированные процедуры, контроли не используются, охват не соответствует планам, этапы, запланированные как продолжение, не реализуются, владение и управление процессом не осуществляются... организация сползает к допроектному состоянию. Не прижилось. Неудачи при внедрении, или неспособность сохранить изменения, почти всегда - следствие пренебрежения человеческой составляющей, самой главной в троице «Люди - Процессы Технологии». При этом обвиняют в неудачах обычно наименее важную часть: технологии. Мы часто говорим о «внедрении» ITIL. Это выражение используют все, и автор этой книги - не исключение, но это неправильные слова. ITIL - это не внедрение, а трансформация. Процессы уже есть, мы лишь меняем их: стандартизируем, закрепляя иной (надо надеяться, лучший) способ их реализации. Мы меняем процессы путем их перепроектирования и поддерживаем их в новом состоянии путём изменений в культуре. Если процесс работает, автоматизация может сделать его более рациональным, лучше измеряемым, более управляемым. Если процесс не работает, или если люди его не принимают, автоматизация - пустая трата денег. В мантре «Люди - Процессы - Технологии» порядок имеет значение. Я занимался организацией Service Desk и процессов управления инцидентами, проблемами и изменениями для одной компании, внедрившей новую систему автоматизации. Во время интервью с сотрудниками заказчика я обнаружил множество несвязанных фрагментов отдельных процессов. Обычная ситуация: каждый знал свой небольшой участок работы, но никго не видел общей картины, ничего не документировалось, планирование не велось... Они просто росли. Как-то я разговаривал с одним из специалистов поддержки, и что-то отвлекло меня; на стене за его спиной висела подозрительно знакомая диаграмма. Действительно, это оказалась подробная схема процесса управления инцидентами! Я попросил разрешения взять рисунок себе. «На здоровье!» ответил мой собеседник. «Ей все равно никто не пользуется». Я почувствовал себя инженером, строящим дорогу сквозь джунгли и поминутно натыкающимся на куски бетона, асфальтированные участки и фрагменты заграждений...

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

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

1

Чтобы понять, насколько этот пункт сложен, вспомните акулу Брюса из мультика «В поисках Немо»: «Рыбы друзья, а не еда».

38

Рекомендации 42. Рассматривайте изменения в культуре как важнейший результат проекта. 43. «Слушайте эфир» для оценки хода изменений в культуре: какие слова используют ваши сотрудники? Думают ли они об услугах?

Возврат инвестиций В ITIL нет ценности, ценность - в улучшении услуг. «Улучшение» подразумевает повышение рациональности (оптимизацию затрат) и/или результативности (улучшение качества). Ценность появляется лишь в тех случаях, когда бизнесу нужны оптимизация затрат или повышение качества (это не всегда так: первое может привести к снижению качества, второе - к увеличению затрат). То есть ценность должна рассматриваться в бизнес- контексте. По данным исследования 1, проведенного в 2004 году, «Средняя стоимость проекта внедрения ITIL составляет около £5338 на каждого сотрудника ИТ независимо от общего числа вовлеченных сотрудников». И это только внешние платежи, из которых около половины приходится на консультантов, треть - на инструментарий и шестая часть - на обучение. В том же исследовании говорится, что менее чем в 20% случаев проект позволил сократить численность персонала ИТ, а в более чем половине случаев изменений не произошло. Остальные увеличили численность персонала. То есть цель ITIL-проекта, скорее всего, не в повышении рациональности. Обычно цифры в рассказах о внедрении ITIL - условны и нематериальны, и вряд ли их можно рассматривать как «реальные деньги, которые теперь можно использовать по-другому» (см. «Забавные расчеты эффективности», стр. 36). Единственное исключение - численность персонала ИТ. То есть оценивать эффективность инвестиций приходится качественно, используя вместо ROI показатель VOI (Value on Investment, польза от инвестиций): сокращение простоев бизнеспроцессов, снижение числа неуспешных изменений, более высокая удовлетворенность заказчиков, более оперативная поддержка новых услуг. Прочие результаты внедрения ITIL ещё сложнее измерить, что отчасти зависит от наличия/отсутствия в организации методологии оценки таких вещей как, например, повышение соответствия внешним нормам или снижение уровня рисков. Рекомендации 44. Сравнивайте предлагаемые внешние траты на ITSM- проект с эмпирически определенными ориентирами: Половина - на консультантов, треть - на ПО и 1/6 - на обучение Примерно $10,0002 на каждого сотрудника ИТ (в ценах 2008 года) 45. Следите за соотношением трат на людей, процессы и технологии. 46. Определите методологию для оценки VOI, или принимайте решения на основе доверия. 47. Многое из описанного в ITIL делается только потому, что ИТ хочет сделать что-то «лучше». Спросите себя: Есть ли выгода или иная польза? Если есть, отлично... а бизнесу нужно «лучше»?

1 2

The ITIL Experience: Has it been worth it?, N. Bruton, 2004 Достоверные цифры для российского рынка не известны (прим. переводчика).

39

И даже если нужно, лучший ли это из доступных способ потратить деньги? (См. «Не делайте этого», стр. 42)

Артефакты Говоря о видимых, осязаемых результатах ITIL-проекта, мы, как правило, говорим о документах. Кроме документов, встречаются внедренные средства автоматизации, а иногда - ещё и изменения организационной структуры. Убедитесь, что среди документов, сформированных в ходе проекта наряду с многочисленными свидетельствами того, что консультанты поработали на славу и деньги потрачены не зря, есть следующие (в самом деле важные): • • • • • •

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

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

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

•

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

•

Технический каталог: объединение актуального и красивого каталогов, дополненное подробной технической информацией. Используется в работе ИТ. SLA (если есть) являются частью технического каталога; кроме того, в него входят: перечень критических компонентов, связанные услуги, правила эскалации... Целевая аудитория - LIT.

•

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

1

Service Pipeline Подробнее и нагляднее о том. как эта структура накладывается на портфель услуг, описанный в ITIL3, можно по адресу http://www.itskeptic.org/owning-itils-catalogues

2

40

2008 года эта идея вдруг стала очень популярной, хотя необходимые технологии успешно используются уже лет десять. Как и со всем остальным в ITIL, программная оболочка здесь — самая простая часть. Главное - бизнес-модель, условия предоставления и оплаты услуг, но прежде всего - готовность организации работать по-новому. И ещё: Автоматизированный каталог должен быть основан на трёх перечисленных выше документах. Эти уровни дополняют друг друга, а не заменяют. Целевая аудитория пользователи. Первое, что нужно создать, и как можно раньше, - актуальный каталог. Красивый и технический появятся со временем. Многие организации никогда не будут использовать автоматизированный каталог. Рекомендации 48. Сделайте одним из первых результатов проекта акгу- альный каталог услуг, (см. «Каталог услуг - как можно раньше», стр. 52).

Метрики Главный результат ITIL-проекта - культурные изменения. Измерить их трудно. Основные подходы здесь - оценка обратной связи заказчиков и/или «культурный аудит». Обратную связь легко собрать, документировать и понять, с аудитом всё это сделать сложнее. Существуют консультанты (не ИТ), способные измерить настроения и мысли в вашей организации с множества точек зрения и тем самым создать точки отсчёта для дальнейшего сравнения. Эта работа не имеет отношения к оценке или обследованию «по ITIL» и не должна выполняться ITIL- консультантами: мы уже выяснили на стр. 23, что измерение успеха ITIL на основе ITIL циклическая и попахивающая сектантством практика. Следующая важная задача - измерить результативность обновлённых процессов. На эту тему есть неплохие полуофициальные дополнения к ITIL1. Только не путайте оценку процессов с оценкой хода культурного изменения. ITIL3 в книге «Continual Service Improvement» предлагает использовать карты сбалансированных показателей (Balanced Scorecard), классический инструмент оценки результативности систем управления. Измерения - хитрая штука. Мы знаем из физики, что наблюдатель всегда влияет на эксперимент. Аналогично, измерения и оценка деятельности людей всегда формируют у них стремление работать «на метрику», что вовсе не значит - работать правильно (по-новому). Описанный эффект не будет подробно рассматриваться в рамках этой книги. Рекомендации 49. Измеряйте изменения культуры не ограничивая себя рамками ITIL. 50. Измеряйте успех ITIL с точки зрения улучшений в результативности и рациональности процессов. 51. Ну и только если это так уж необходимо, измеряйте ITIL с помощью ITIL (см. «Культ ITIL», стр. 23)

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

1

Implementing Metrics for IT Service Management, D. Smith, Van Haren, 2008, ISBN 978-9087531140 Metrics for IT Service Management, P. Brooks, Van Haren, 2006 ISBN 978- 9077212691 Метрики для управления ИТ-услугами, Алпина Бизнес Букс, Альпина Паблишерз, 2008 ISBN 978-5-9614-0647-4, 9077212-69-8

41

вопросы, требующие внимания от тех, кому приходится отвечать за проект, связанный с ITIL. ITIL это трансформация, а не внедрение. ITIL2 очень немного рассказывает о том, как мы добиваемся этой трансформации. В книге «Planning to Implement Service Management»1 можно найти рекомендации, сводящиеся к описанию двух классических механизмов: (i) «текущее состояние - целевое состояние — способы изменения» и (2) цикл Деминга, или Plan-Do-Check-Act. ITIL2 придает циклу Деминга большое значение, но уделяет очень немного внимания тому, как его связать с практическими рекомендациями по управлению услугами. ITIL3 не добавляет ничего существенного. Хочется верить, что причина - в том, что грядут дополнительные публикации. Пока что четыре из пяти основных книг ITIL3 лишь время от времени ссылаются на цикл Деминга, не предлагая никакой системной информации по этому вопросу. Предполагается, что модель улучшений описана в пятой книге, «Continual Service Improvement», но эта модель не имеет ничего общего со сложившимися в отрасли практиками и вообще ни на что не похожа. Поскольку деятельность по внедрению ITIL сама по себе тоже носит циклический характер, её можно назвать мета-циклом: жизненным циклом жизненного цикла управления услугами (следите за руками!). Описывая жизненный цикл услуг, книги ITIL заодно предлагают довольно много рекомендаций по организации инфраструктуры для управления этим циклом. Там говорится о планировании, внедрении, совершенствовании, есть даже неплохой раздел о культурных изменениях2. Но все эти рекомендации изложены в контексте управления услугами, а не системой управления услугами. С учётом двадцатилетней истории ITIL это выглядит странно. Вероятно, авторы не хотели расстраивать многочисленных консультантов публикацией рекомендаций «сделай ITSM сам». И всё же, в открытом доступе немало полезной информации. Час-другой работы с поисковиком и вы будете обладателем многочисленных и часто вполне корректных советов и рекомендаций. Рекомендации по управлению мета-циклом - за рамками этой книги и вообще книг... пока что. Но мы всё же предлагаем вам в коллекцию некоторые советы по успешному использованию ITIL.

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

Потребность/требование/проблема — У нас есть причина? • Ожидаемые выгоды — Оно того стоит? (см. «Возврат инвестиций», стр. 39) • Соответствие нашим планам, в частности - бизнес-стратегии3 — Это именно то, на чем нам следует сосредоточиться, и прямо сейчас? • Место инициативы в портфеле проектов (вы ведь управляете портфелем проектов, верно?) — Проект может успешно пройти предыдущие проверки, но является ли он лучшим (оптимальным) способом потратить ресурсы? Или бизнес больше выиграет, если мы используем деньги и людей в другом месте? Эти критерии работают как для ITIL, так и для любого другого проекта. Но многие связанные с ITIL инициативы оцениваются только на первых двух уровнях, особенно если решение принимается под влиянием излишней технической скрупулезности (стр. 31). 1

Planning to Implement Service Management, Office of Government Commerce, The Stationery Office, 2002. ISBN-13:9780x13308774 2 Service Transition, chapter 5 3 ИТ Скептик принадлежит к числу тех, кто считает излишней такую штуку как «ИТ-Стратегия». Должна быть стратегия бизнеса, указывающая. где уместно, на роль ИТ в бизнесе.

42

ИТ Скептик принадлежит к числу тех, кто считает излишней такую штуку как «ИТ-Стратегия». Должна быть стратегия бизнеса, указывающая. где уместно, на роль ИТ в бизнесе. Рекомендации 52. Проверяйте все ITIL-инициативы по четырём критериям, приведенным выше. 53. Если проект не проходит все четыре проверки - решайте, стоит ли двигаться дальше; что бы вы ни решили, это будет сознательный выбор. В общем случае Скептик рекомендует отклонять инициативы, не удовлетворяющие всем четырём критериям.

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

Теоретически, ITIL-трансформация может финансироваться так:

То есть мы инициируем программу по совершенствованию и постепенно, «медленно и методично», улучшаем управление услугами при постоянном уровне затрат. Но: • • •

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

Итак, начало трансформации - это всегда проект, а средства будут выделяться примерно так:

43

...и так далее, снова и снова. Просто для того, чтобы консолидировать и сохранить достижения первого «прорыва» нам потребуется периодически освежать их. И если успех будет так велик, как обещают, нам захочется развить его на следующих фазах, ведь так? Рекомендации 54. Используйте проектный подход: бизнес-обоснование, бюджет, цели, вехи, проверка результатов. Если вы решились делать это, делайте это правильно. 55. Не просите людей менять процессы в свободное от основной работы время. Не отвлекайте себя и других никуда не ведущими гениальными идеями. 56. Не прекращайте усилий, когда проект завершен. Сделайте программу последующих действий необходимым результатом проекта. (См. «ITIL- подход, а не проект», стр. 48)

Люди Процессы Технологии Люди - Процессы - Технологии (People Process Technology) - это базовая модель, применяемая к любой ИТ-инициативе. (В некоторых материалах ITIL добавляется четвертый элемент Партнеры.1 Ещё более сложные варианты включают Видение, Стратегию, Руководства, Процессы, Людей, Технологии и Культуру2.) Важно выбрать верный порядок вовлечения этих элементов (люди, потом процессы, потом технологии) и поддерживать баланс элементов в дальнейшем. Мы часто начинаем с технологий, время от времени начинаем с процессов и почти никогда- с людей (культура, команда, поддержка, энтузиазм...). Технологии работают там, где они воспринимаются как инструмент, помогающий людям и поддерживающий процессы, там, где они были выбраны или спроектированы для процессов и людей, и там, где люди и процессы могут работать хорошо независимо от наличия технологий. Технологии помогают людям работать рациональнее и повышают стабильность процессов. Очень редко они делают возможным что-то, что не было возможно без них. Иначе говоря, хороший персонал может работать при плохих процессах и неэффективном ПО; хорошие процессы могут компенсировать неэффективность ПО; но установка лучшего ПО не может исправить плохие процессы, и лучшие в мире процессы не способны создать хороших людей. Клиенты, которых я консультирую, устали от постоянно повторяемой мною мантры «Люди Процессы - Технологии», но я не меньше устал от того, что они продолжают нарушать этот порядок. Отметьте фразы, которые кто-то мог услышать от вас: □ «Да, хорошо, ну а как будет выглядеть форма RFC?» □ «Я бы хотел получить коробочное решение» 1 2

An Introductory Overview of ITIL, С. Rudd. itSMF 2004 Planning to Implement Service Management, Vernon Lloyd, The Stationery Office, 2002

44

□ «Сейчас у нас нет возможности это улучшить — мы слишком заняты» □ «Мы тут купили Service Desk, и теперь нам надо решить, как его лучше использовать» □ «Мы думали, процессы входят в ПО» □ «Нам нужны от вас только документы» □ «Нам нужны от вас только шаблоны» □ «Нам только нужно, чтобы вы настроили процесс в системе» □ «Кажется, я знаю, почему никто не следует новому процессу. Эй, туту кто-то вообще умеет читать?» □ «[Вендор] установит ПО, закачает тестовые данные и проведет один тренинг» □ «Я не могу уволить его за то, что он не следует процессу. Это наш лучший специалист» □ «Вот если бы у нас была нормальная система, а не эта развалина, люди точно использовали бы её» □ «Как можно интегрировать процессы, не интегрируя системы?» □ «Ему не надо соблюдать эти процедуры, он же директор» □ «Когда мы одобряли это изменение, я не знал, что оно будет иметь такое влияние» □ □

«Мы внедрили ITIL в прошлом году» «Мы не можем позволить себе никаких улучшений»

Изменения культуры (опять) Сначала - люди. Как мы уже обсуждали, ITIL-проект - это трансформация, а не внедрение. Трансформация культуры. Это переориентация людей, изменение их отношения к работе. Меняя людей, мы делаем возможными изменения процессов. Несомненно, это аспект ITIL-проектов, которым пренебрегают более всех прочих, даже более чем «приверженностью руководства»1 (этот фактор мы обсудим далее). Для того чтобы изменить отношение, мы меняем поведение. Для того чтобы изменить поведение, мы меняем процессы и процедуры. Чтобы облегчить эти изменения, нам могут пригодиться технологии - как средство устранить узкие места, разрывы коммуникаций, задержки и другие слабые места наших процедур. Существует отличный подход к организации этой работы, описанный Джоном Коттером и известный как «8 шагов Коттера». Многочисленные комментаторы и консультанты будут рады рассказать вам подробности, включая авторов книги «Service Transition» из ITIL3, где эта модель описана в главе о культурных изменениях (глава 5). Вот ещё несколько идей. Изменение культуры касается коммуникаций, мотивации и образования. Коммуникации Формируйте сообщество равных. Дайте людям почувствовать себя участниками происходящих изменений - полноправными, имеющими вес, влияющими на решения. Обеспечьте прозрачность принимаемых решений, их логику и процесс их принятия. Работайте с сопротивлением. Спорьте. Обсуждайте недовольства. Лучше победить сопротивление сейчас и полностью, не оставляя в своем тылу партизан. Организуйте анонимный форум для несогласных. О сопротивлении лучше знать, чем не знать. Совет: электронная почта - не способ общения. Семинары, телефонные звонки, дискуссии, встречи, совещания и разборы полётов - вот способы общения. Рассылка — лучше, чем её отсутствие, но разговор всегда лучше рассылки.

1

Executive Commitment

45

Мотивация Вдохновляйте, измеряйте, поощряйте. Лучший способ достичь того, чтобы люди сделали что-то — заплатить им за эту работу. Показатели, привязанные к оплате, отлично искажают деятельность людей, но если они спроектированы с умом, это точно лучше отсутствия показателей. Обеспечьте обратную связь, позитивную и негативную. Люди должны знать, как их измеряют. Покажите им результаты. Раздавайте славу и почёт. Обучение Обычного погружения в ITIL (тренинга «Основы ITIL») - не достаточно. Часто это в то же время больше чем надо, поскольку большинству этот тренинг не нужен, им нужно что-то другое. Не нужна им теория из ITIL. Им нужен курс о том, как эта теория будет работать в их практике, для их компании и их должностей. Курс о том, что изменится, что нужно будет делать подругому, за что они будут отвечать и как будут оцениваться. Это настоящий ITIL-тренинг, и в природе он встречается крайне редко. Меня всерьез тревожит количество людей, отправляемых на курс «Основы ITIL». Учитывая стоимость профессиональной сертификации по ITIL, я уверен, что компании, отправляющие всех подряд на теоретические курсы по ITIL, зря тратят свои деньги. Настоящая целевая группа для этого обучения - специалисты и консультанты. Привлекайте внешних экспертов, вашу собственную проектную команду и ключевых пользователей для разработки адаптированного курса на следующие темы: • Зачем мы это делаем? • Что изменится для нас? • Какие из наших ролей будут затронуты изменениями? • Как выглядят наши новые процедуры? • Что лично каждому участнику придется делать по- другому? • Где можно найти подробности новых процедур? • Как можно получить помощь, поддержку', обучение? • Как поделиться впечатлениями и идеями? • Как будут измеряться и поощряться успехи? • И главное: зачем это каждому из нас? Вот две основные причины, по которым организация должна организовать такой тренинг: l) Теоретический курс по ITIL - это просто ещё один сертификат на стене. Да, он даст проекту нескольких энтузиастов, но описанный выше тренинг даст больше. (Кстати, ещё один результат «Основ ITIL» - запись в резюме, маленький штрих к карьерному пути ваших сотрудников. Отличная вещь, если вы знаете, что делаете.) 2) Без этого тренинга трансформация имеет отличные шансы закончиться ничем. Обучение тому, что значат проводимые изменения для организации, - необходимая основа всего культурного изменения. Без него все новые инструкции, схемы и роли не имеют смысла. Многие фабрики тренингов - именно фабрики. У них нет навыков или процедур разработки тренингов для конкретного заказчика: эта работа требует навыков анализа и консультирования. Такие тренинги создаются консультантами, или тренерами совместно с консультантами, и обязательно - в сотрудничестве с внутренней командой, проводящей трансформацию. Так гораздо больше пользы, в том числе - в расчёте на вложенные средства. Но и хороший тренинг - это ещё не всё. Люди запоминают примерно половину того, чему их учили, и интериоризируют1 ещё меньше. Важно: • • •

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

1

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

46

• обеспечивать поддержку отстающих. Почему ИТ-департаменты не учатся, не используют коучинг? Это такая дурацкая ИТмужественность: «Я никогда не прошу помощи. Беру мануал - и вперёд. И всегда выплываю». Усилия и деньги, потраченные на организацию обучения и наставничества в ИТ - одна из лучших инвестиций, доступных ИТ-руководителю. Совет: инструкции - не форма обучения. Думаете, это сложно? Не слишком - по сравнению с попытками поменять процессы, не заручившись поддержкой людей. Думаете, это дорого? По крайней мере треть ваших расходов должна приходиться на персонал. Лучше половина. То есть общая стоимость проекта будет выше, верно? Если на ПО должна приходиться меньшая доля, общие затраты должны быть выше. Относитесь к этому как к цементу для ваших процессов и технологий. Если вы не вкладываете усилия и средства в изменение культуры, все ваши траты на процессы и технологии - впустую. Или внедрение провалится сразу, или вскоре после запуска. Делайте правильно с первой попытки. Планируйте культурные изменения, вкладывайтесь в них, и сделайте это частью проекта по трансформации. Рекомендации 57. Сделайте изменение культуры главной целью и основным показателем успешности проекта. 58. Не принимайте и не утверждайте планов, не уделяющих внимания культурным изменениям. 59. Обращайте внимание на планируемые затраты, связанные с коммуникациями, совместной работой, разборами полетов, мониторингом, обучением, оценкой... 5% на людей - формальность, 30% - похоже на правду, 50% говорят о серьёзном отношении к изменению культуры. 60. Обучите нескольких специалистов теории ITIL. В их случае «основ» недостаточно, понадобятся и практические курсы. Если они планируют сертификацию ITIL Expert, то они вас, вероятно, скоро покинут :) 61. Привлекайте внешнюю экспертизу, наймите консультантов. Никакой тренинг не сформирует экспертизу внутри. 62. Разрабатывайте адаптированные тренинги. 63. Слушайте эфир. Люди будут сопротивляться, и это отлично, во всяком случае на начальной стадии. Профессиональные продавцы знают, что отрицание свидетельство готовности купить. Но если сопротивление длится или усиливается, надо принимать меры. Усильте атаку, добавьте семинаров и тренингов. В крайнем случае «если вы не можете изменить людей - поменяйте людей». Найдите тех, кто будет работать по правилам.

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

Если у боссов получается жить мимо правил, будут пытаться и все остальные. Рекомендации 64. Интегрируйте сервис менеджмент в как можно большую часть организации (идеально - во всю компанию, минимально - в операционную часть ИТ). 65. Передавайте дух сервис менеджмента своим клиентам и требуйте того же от партнёров и поставщиков. 66. Включите сервис менеджмент в показатели всех ролей всех сотрудников. На высшем уровне, где вы не влияете на сами показатели, продемонстрируйте зависимость текущих показателей от успехов сервис менеджмента. (Если такой зависимости нет, у вас проблемы.) 67. Если руководители пытаются обходить новые правила, есть два пути: Заручитесь поддержкой генерального директора, договоритесь с ним о пресечении таких попыток. Измените правила, сделайте привилегии прозрачными. Введите платиновый уровень услуг. Возьмите исключения под контроль.

Ресурсы Не пытайтесь привлекать сотрудников к ITIL- трансформации на условиях частичной занятости, а тем более - в свободное от основной работы время. Сформируйте и оформите проект, назначьте профессионального менеджера проекта, выделите ресурсы, дайте им полномочия и не отвлекайте их на другие задачи. Не просите сотрудников придумать сервис-менеджмент. Привлекайте внешнюю экспертизу, чтобы сократить время обучения и получить необходимые знания. Наймите дополнительных сотрудников, чтобы обеспечить выполнение работы и задать ускорение. Нужна внешняя экспертиза, а значит, действуют обычные в таких случаях предупреждения. Берегитесь мальчиков в галстуках. Многие консалтинговые фирмы держат одну- две звезды для показательных выступлений на этапе продажи проекта. После продажи вы их не увидите, к вам придут мальчики в галстуках. Сертификация ITIL Foundation подтверждает только то, что человек знает некоторые специальные термины и может поддержать беседу на тему ITIL за стойкой в баре. Даже сертификация ITIL Expert (она же Manager или Master в ITIL2) - всего лишь красиво звучит. Ищите старых воинов, покрытых шрамами. В ITSM ничто не заменит опыта. Рекомендации 68. Позовите консультантов. 69. Лучше всех - местные независимые эксперты с хорошей репутацией (слушайте рынок). За ними - большие компании с громкими именами.

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

точнее сервис менеджмент, это трансформация культуры - того, как люди думают; того, как они относятся к работе. Такого рода изменения никогда не бывают результатом краткой вспышки активности. Они требуют постоянного воздействия, напоминаний, мониторинга и корректировок. Иначе изменения не приживутся. ITIL говорит о постоянном улучшении услуг, CSI. Собственно, так называется одна из пяти основных книг ITIL3. Но подход ITIL к этому вопросу незрел - в том смысле, который вкладывают в «зрелость» SPICE, или СММ, или Six Sigma. И все же попытка сделана. Что часто остается без внимания, так это тот факт, что программа постоянного улучшения обязательный, а не опциальный элемент. Даже если первичный проект закончился успешно, для поддержания этого успеха, предотвращения регресса, для того, чтобы «колесо Деминга» вращалось в нужную сторону, необходима постоянно1 действующая программа. Мы обсуждали это в главе «Не надо «внедрять ITIL»», на стр. 29. Если ITIL не воспринимается как «то, как мы теперь живём», ITIL останется очередной игрушкой менеджмента, ещё одной затеей, которая пройдет, как и все прочие, если набраться терпения и переждать. ITIL - трансформация культуры, а не реорганизация процессов и уж тем более не внедрение ПО, хотя эта трансформация может подразумевать и то, и другое. Рекомендации 70. Подходите к ITIL как к программе культурных изменений. 71. Привлекайте экспертизу в области культурных изменений. 72. Предусмотрите бюджет, ресурсы и ответственность для программы постоянных улучшений по завершении проекта.

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

Управление бизнесом — Стратегия и планы бизнеса — — — — — —

•

Управление проектами — — — —

•

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

Разработка — Связь изменений с жизненным циклом разработки ПО

1

ITIL V3 предлагает забавный комментарий к разнице между- «постоянно» и «непрерывно». «Постоянная программа» действует регулярно и циклично, но не 24*7.

49

— Отслеживание хода разработки и построения, в частности - результатов тестирования — Приёмка — Передача в эксплуатацию •

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

•

Управление персоналом — Учёт перемещений, приёма на работу, увольнений — Уведомление ИТ о новых сотрудниках, с указанием их роли или профиля, должно быть автоматизировано — То же касается изменения ролей — Контактная информация должна управляться централизованно — Необходимо обеспечить информирование и обучение в соответствии с политиками (безопасности, процессов, изменений...) — Предоставление активов и услуг должно управляться ИТ или HR (не обоими)

•

Поставщики — Необходимы интерфейсы к их системам и службам поддержки — Согласование контрактов с учетом SLA

Рекомендации 73. Обеспечьте интеграцию ITIL-проекта в организацию: проверьте состав участников семинаров и тренингов, списки утверждающих.

ITIL2 или ITIL3 Не спешите использовать ITIL3. Вендоры будут настойчиво советовать вам третью версию, но научатся с ней работать они не сегодня и не завтра. Для тех организаций, которые уже «прошли уровень ITIL2», ITIL3 будет логичным продолжением; для тех, кто только начинает, эта версия может оказаться недостижимо далекой целью. Потихоньку люди начинают понимать, насколько ITIL3 («обновление») отличается от ITIL2, насколько больше охват и как широко размахнулись авторы. Масштаб изменений впечатляет. Это всё равно что перейти с командной строки в чёрном окошке к Windows-интерфейсу с встроенным потоком работ. Работа вроде та же, но инструкция выглядит несколько иначе! Сказать, что ITIL3 - это просто дополнение, это всё равно что сказать, будто Шевроле Корвет дополнение к мотору, или что Windows - дополнение к MS-DOS. То есть ITIL2 точно можно найти где-то там глубоко внутри, но никак нельзя сказать, что это легко сделать. Тем организациям, которые только начинают, я бы пока рекомендовал ITIL2. (Если, конечно, вы не относитесь к немногочисленным поставщикам услуг, сознательно стремящихся к совершенству во всем.)

1

•

В ITIL2 нет несовместимых с жизнью ошибок.

•

ITIL3 - это очень много информации и очень мало помощи при её употреблении (пока что, в начале 2009 года).

•

ITIL3 - ещё очень сырой материал, и толком его пока никто не понимает, во всяком случае - книгу Service Strategy1.

•

Профессиональная сертификация в соответствии с ITIL3 пока ещё не доделана, а кроме того...

http://wwv.cleverics.ru/ru/subject-field/hot-issues/david-cannon-interview

50

•

...лишь малая часть ITSM-сообщества настолько продвинулась в практике сервис менеджмента, что в самом деле нуждается в ITIL3. ITIL2 работает. И неплохо. Скептик неоднократно критиковал ITIL2, и всё же в целом это неплохой свод знаний. Если говорить только о двух «главных книгах ITIL2», синей и красной, то можно утверждать, что ITIL2 понятнее, проще, надежнее, практичнее, чем ITIL3. Если от ITIL2 была польза для бизнеса в прошлом году, куда она должна деться в этом? Как было однажды замечено на форуме itSMFI1: ITIL - это не софт, «новый и улучшенный»... V2 не потеряла ничего из своей ценности для бизнеса с появлением V3. Мой домашний компьютер - это Pentium 3. На нём можно играть в SimCity 3, что, собственно, и требуется. Мой телефон - старый i-Mate PocketPC: здоровый такой кирпич, без красот, без 3G, без WiFi. Вот уже много лет я езжу на Холдене 74-го года. Это мало для кого что-то значит, поэтому добавлю, что передач у него три, и они переключаются рычагом на руле. Эти «старые» решения работают. Они отвечали требованиям бизнеса тогда - что изменилось? Бывает, что меняются требования, и поддерживающая инфраструктура должна двигаться вперёд, но бывает и так, что требования НЕ меняются. Или так, что развитие инфраструктуры может быть отложено до момента, когда она будет лучше к этому готова. Мало того, что ITIL2 неплохо работает, так ещё неизвестно, хорошо ли работает ITIL3. Если ITIL2 учит нас ходить, то ITIL3 учит нас бегать. Проблема в том, что многие из нас пока ещё сидят. Лишь немногие организации уже отправились в путешествие под именем «ITIL» в сравнении с числом тех, что ещё не отправились. Вероятно, лишь около ю% организаций, использующих ITIL, готовы применять «продвинутые» опции ITIL3. Всегда есть соблазн сразу выбрать ITIL3, чтобы впоследствии не пришлось «мигрировать». Не поддавайтесь. ITIL - о постепенном улучшении. ITIL3 - улучшение ITIL2. Нам постоянно говорят о том, что версии полностью совместимы, по крайней мере - при повышении. Так что держитесь пока за ITIL2. Некоторые организации используют «политику первого сервис-пака», то есть ждут первой волны исправлений перед тем, как внедрять продукт. (Кстати, для ITIL такой пакет исправлений уже вышел, просто об этом мало кто знает: для ITIL не существует открытого управления релизами.) Вероятность выпуска существенного пакета обновлений для ITIL3 очень невелика, так что этот аргумент против немедленного использования ITIL3 не очень убедителен. Гораздо важнее то, что если вы немного подождете, вы сможете использовать в своей практике больше дополнительных публикаций, выход которых запланирован на ближайшее время. В частности, есть надежда увидеть среди них рекомендации по движению к цели, иначе говоря, по внедрению ITIL. Как следствие объединения всех «забытых книг» ITIL2 (немногие знают, что вторая версия библиотеки состояла из одиннадцати, а не из двух, книг), ITIL3 на порядок шире и сложнее, чем две основные книги ITIL2. Это хорошая новость для отрасли, шаг на одну ступеньку вверх по лестнице компетентности. К сожалению, это шаг - только для тех, кто уже стоит на ступеньке под названием ITIL2. Если же вы ещё не знакомы с сервис менеджментом, это не ступенька, а стена. ITIL3 не дает советов о том, как преодолеть эту стену. ITIL2 - единственный источник начального уровня. OGC2 и TSO 3 делают все возможное, чтобы окончательно извести ITIL2. Но вряд ли это удастся до того времени, когда в дополнение к ITIL3 будет опубликован какой-то

1

Michiel Croon, www.itsmfi-forum.org UK's Office of Government Commerce, «owners» of ITIL 3 The Stationery Office, formerly the UK Government printers and now a privatized for-profit organisation. The official publishers of ITIL. 2

51

другой вариант «ITIL для чайников». Или же люди начнут искать простые альтернативы, вроде FITS1 . Ещё одна книга, которой нам остро не хватает, это «Как внедрять ITIL3», с рекомендациями по подъему на стену с указанием промежуточных точек. Пять главных книг много говорят о том, куда надо придти, но традиционно мало - о том, как туда добраться. Подождите, пока опубликуют книгу, которая это исправит. И главное. Дождитесь ясности в вопросе о том, что в ITIL3 работает, а что - не очень. К сожалению, ITIL3 позиционируется то как описание практик, подтвержденных опытом многих компаний, то как описание передовых идей в области сервис-менеджмента. Вместо «лучших практик» используется термин «хорошие практики», ещё лучшим вариантом могли бы стать «общепринятые практики», аналогично GAAP для бухгалтерского учета. Описывает ли ITIL3 Общепринятые Практики Управления Сервисами2 или новейшие передовые идеи - время покажет. В тексте ITIL3 эти позиции занимаются в зависимости от автора и главы. В книгах нет четкой индикации надежности материала. Им бы следовало использовать цвета: зеленый - для безопасных рекомендаций ОПУС, небесно-голубой - для воздушных теорий, предлагаемых отрасли в качестве направления развития (одну из книг надо бы всю напечатать на голубой бумаге). Но они не используют цвета. Это опасно, прежде всего, для тех, кому книги должны быть адресованы: новичкам в сервис менеджменте, которым нужен хороший учебник. Если вы в состоянии отличить практически полезные рекомендации ITIL от воздушных теорий, вам не нужны эти книги. Так что подождите ясности относительно надёжных и рискованных областей ITIL3. Дождитесь, пока консультанты наберутся опыта в ITIL3 - опыта, а не двухдневного обзора «What's new». В любом случае сертификационная схема не будет завершена до 20093, так что пока все равно негде брать консультанта с сертификатом ITIL3 Master. К концу 2009 года они будут лучше знать, о чем говорят. Для подавляющего большинства читателей нет смысла связываться с ITIL3 в 2009 году. Приходите в 2010 или позже. К тому времени вы достигнете уровня, когда ITIL3 будет вам в самый раз. Рекомендации 74. Для большинства компаний лучшее начало - «синяя» и «красная» книги ITIL2. Если вам попались хорошие консультанты, осторожно добавьте к этим книгам отдельные элементы ITIL3, вроде портфеля услуг, обработки запросов, оценки услуг или управления событиями. 75. Подождите, пока дозреют ITIL3 и консультанты. Этого не произойдет раньше начала 2010 года. 76. Если вы уже используете ITIL, или вам в самом деле нужны все элементы ITIL3, тщательно проанализируйте причины этот шага.

Каталог услуг - как можно раньше Каталог услуг содержит информацию обо всех услугах, предоставляемых пользователям, а также указания на уровни этих услуг, согласованные в SLA. В главе «Каталог услуг», на стр. 40 описана четырёхуровневая модель каталога услуг. Здесь мы говорим об актуальном каталоге, то есть о каталоге в его бытовом, общепринятом значении. Независимо от того, какими процессами ITIL вы решите заниматься в первую очередь, каталог должен стать одним из первых результатов проекта. Это даст людям объект приложения сил и заложит основу для развития сервис- ориентированной культуры в организации. 1

becta.org.uk/fits/index.cfm В настоящий момент эта инициатива не развивается http://www.realitsm.ru/2010/06/orgvopros/ (примечание переводчика). 2 Прим. переводчика: GASMP, или General Accepted Service Management Practice. По-русски - ОПУС, то есть «Общепринятые практики управления сервисами». 3 http://www.realitsm.ru/2010/08/itil-v3-master-vremya-eshhy0-ne-prishlo/

52

На практике так происходит не всегда. Многие считают, что каталог не следует создавать до того, как мы сможем определять и измерять то, что мы предоставляем. Эта точка зрения, как правило, основана на понимании каталога как совокупности всех четырёх уровней, описанных в главе «Каталог услуг» на стр. 40. Технический каталог и соответствующие SLA действительно должны подождать до тех пор, пока мы специфицируем параметры услуг, которые нужно и возможно измерять. По этой же причине актуальный каталог, возможно, не следует сразу публиковать для пользователей. Но для персонала ИТ он необходим, и как можно раньше. Если же его верно позиционировать и использовать с умом, он станет отличной основой для обсуждений ожиданий и требований с заказчиками, а в дальнейшем - и для формирования SLA. В идеальном случае первая версия красивого каталога тоже появится довольно скоро - как краткий перечень того, что ИТ делает для заказчиков и над чем мы намерены работать в дальнейшем. Рекомендации 77. Убедитесь, что формирование актуального каталога запланировано как один из первых результатов проекта. Не давайте перфекционистам ждать, пока станет доступной вся-вся нужная информация - передайте актуальный каталог сотрудникам ИТ как можно раньше, в первую очередь - как базу для обсуждения. 78. Убедитесь, что актуальный каталог играет ключевую роль в плане коммуникаций.

Ограничьте управление конфигурациями Те, кто работают с ИТ, любят мечтать о «кольце всевластья»: реляционные базы данных, корпоративные модели данных, словари данных, хранилища, панели управления, порталы, каталоги и SOA. Идея сложить всё в одно место и по порядку выглядит чрезвычайно привлекательно, но на практике всякий раз оказывается требующей ничем не оправдываемых расходов, а результат никогда не приближается к идеалу. Управление конфигурациями - отличная идея: давайте организуем сбор информации обо всех ИТ-объектах и их связях, а потом обеспечим удобное представление этой информации, так что сотрудники ИТ смогут отслеживать зависимости и анализировать влияние изменений и событий (в идеале - на бизнес). Место, в котором мы соберем всю эту информацию, назовем CMDB (см. «CMDB не бывает», стр. 32). Важно, чтобы те, кто работают с ITIL, понимали разницу между процессом управления конфигурациями и инструментом CMDB. Вам нужен процесс. Так или иначе вы уже управляете конфигурациями: люди держат нужные данные в головах, в таблицах, в разрозненных базах, в разных системах. Важно определить, какой уровень зрелости управления конфигурациями нужен вашей организации, и насколько важно иметь доступ к данным о конфигурациях, и как быстро нужно его получать. Только тогда станет понятно, нужна ли вам CMDB. Вероятно, любая компания, сумевшая построить работающую CMDB (это удается не всем), получит от этой CMDB пользу. Вопрос лишь в том, оправдывает ли эта польза затраты (часто не оправдывает) и является ли это лучшим доступным способом потратить ресурсы (обычно не является). Лишь для тех немногих компаний, в которых инфраструктура чрезвычайно сложна, а требования к срочности предоставления информации чрезвычайно высоки, CMDB оправдывает себя. CMDB - ответ на желание любого технаря найти техническое лекарство от культурных и организационных болезней. К сожалению, процессы невозможно исправить технологиями. Скептик совершенно серьёзно предлагает иной подход1 к централизации и актуализации конфигурационных данных: собирайте их по мере появления потребности. 1

См. On Demand CMDB, на сайте Owning ITIL: www.itskeptic.org/owningitil

53

Не надо держать все данные в одном месте постоянно, собирайте их по запросу. В этой идее нет ничего нового, мы и так делаем это. Если данных нет, а они нужны для, скажем, подготовки отчёта начальству, мы собираем их, вычищаем и готовим отчёт. А если бы у нас был эксперт (или несколько) по сбору необходимой информации в ответ на поступающие запросы? С формализованными процедурами получения, проверки, обработки данных. С инструментарием и навыками его использования. Большинство таких экспертов имело бы в головах CMDB: они знали бы, где и у кого получить нужную информацию. Вместо любительского судорожного поиска информации мы могли бы иметь профессиональный и осуществляемый в рамках формализованного процесса. Эти люди должны обладать базовыми навыками статистического анализа. В ответ на запрос руководства о, например, распределении инцидентов по категориям они должны суметь получить выборку инцидентов, классифицировать их в соответствии с запросом (говоря начистоту, часто ли имеющаяся классификация достаточна для ответа на очередную фантазию руководителей?), сформировать и предоставить отчёт. И должна быть дежурная команда на случай крупных инцидентов: «В серверной произошла авария и такие-то серверы остановлены. Какие услуги пострадали вследствие этого события, и кого из пользователей нам придется вызвать на работу в субботу?» Возможно, ответ не найдётся сразу, но эти люди лучше прочих знают, где и как его искать и сколько времени займут поиски. Разумеется, нам понадобится простейшая постоянно действующая CMDB. Там будет та информация, которую мы уже умеем собирать автоматически: данные о закупках, об активном сетевом оборудовании, о рабочих станциях... плюс та информация, которую мы собираем (или стараемся собирать) на бумаге - записи об изменениях, каталог услуг, списки телефонов, контракты... Экономия на не-построении идеальной CMDB может быть колоссальной. Плата за эту экономию - то, что нужная информация не будет получена нами мгновенно. Возможно, для её получения понадобятся часы, возможно - дни. Следовательно, нужно провести анализ того, насколько актуальные данные нам нужны. Найдутся организации, которым придется пройти непростой путь создания и поддержания CMDB. Но большинству это не необходимо. Рекомендации 79. Ограничьте охват управления конфигурациями. 80. Если вы - часть большинства (не NASA, Boeing, EDS или Tata), вам не нужна CMDB. 81. Заведите «CMDB по имени Сью 1»: одного или двух живых человек, знающих, как всё устроено, и способных анализировать это. 82. Лучше использовать готовые коробочные решения для CMDB, пусть неидеальные, чем разрабатывать идеальную CMDB самостоятельно. 83. Если вы уверены, что CMDB нужна - пусть она будет частью системы Service Desk. Не занимайтесь интеграцией, пусть её сделают другие. 84. Пресекайте попытки построить идеальную книжную CMDB, если только вы не огромная организация с завышенными стандартами, жёсткими требованиями и бездонными карманами. 85. Если потребность в CMDB в самом деле есть, не возлагайте заботы о поддержании её актуальности на одну выделенную группу. Сделайте это частью ежедневной работы тех, кто управляет предоставлением и поддержкой услуг, и не забудьте учесть эту работу в системе мотивации. Тем не менее, владение всей CMDB должен осуществлять кто-то один.

1

Прим. переводчика: Имя не играет существенной роли. «Дмитрий», «Женя» или «Олег» отлично подойдут.

54

86. Если CMDB не нужна, сосредоточьтесь на конфигурации сети («что с чем соединено»), данных об активах («что есть что») и инвентаризации устройств («что на чём работает»). 87. Рассмотрите возможность организовать команду для формирования конфигурационной информации по запросу.

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

Они все работают Вообще-то все они не работают. Во всяком случае, в том качестве, в котором люди пытаются их использовать: они не решают проблемы. Установите систему, и даже окружите её процессами, всё это всё равно сломается. Возможно, не сразу, но непременно. Начинать надо с людей. Измените культуру / отношение / привычки / поведение, и помогите людям разобраться с процессами. Когда требования к процессам в вашей организации будут понятны, можно будет искать подходящую систему для автоматизации. Любая другая последовательность означает попытки внедрения инородных объектов в культуру организации и потому обречена. В модной нынче манере Скептик утверждает: «Инструменты не имеют значения». Есть и ещё причина, по которой они не имеют значения: они все работают. И помогают добавить рациональности и постоянства в действующие процессы. Если система не работает совсем, это скоро станет ясно даже самым дружественным аналитикам, и её разработчик очень быстро вылетит с рынка. Рекомендации 88. Сначала разберитесь с процессами. Потом составьте короткий список хороших систем. Подойдет любая из них. Все они сделают своё дело, различия не так уж важны. Выбирайте поставщика и цену. 89. При выборе ставьте во главу угла надёжность вендора, наличие местной поддержки, и цену. Не давайте воли технарям, борющимся за «вкусные» функции. 90. Не пренебрегайте бесплатными решениями с открытым кодом и предложениями на основе SaaS.

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

В ИТ существует интересный спор между теми, кто мыслит объектами и теми, кто мыслит действиями («мыслит» понимается здесь шире, чем «программирует»). Вот простейший лингвистический тест для определения ведущего стиля мышления: какие слова они чаще используют - глаголы/действия или существительные/объекты? Технологии или процессы, объекты или деятельность, глаголы или существительные... истина всегда где-то посередине. Но культура ИТ в начале двадцать первого века тяготеет к объектному мышлению. Послушать вендоров, так все решения лежат в сфере новых технологий. Пониманию того, как организована работа, управлению качеством, формированию культуры почти не уделяется внимания. Существует момент на определённом этапе проектирования процессов, когда приходит пора обратить внимание на возможности систем автоматизации по автоматизации управления и/или выполнения деятельности в процессе. Когда мы понимаем возможности и желания наших людей, когда мы понимаем, чего мы хотим от своего процесса, тогда и только тогда мы можем обосновать себе и другим покупку средств автоматизации. Чтобы сделать верный выбор, мы должны понимать, каких результатов мы ждём от каждой транзакции и как именно мы планируем выполнять эти транзакции. То есть к моменту выбора системы мы должны проделать большую часть работ по проектированию процесса. Лично я дождался бы тестового прогона процесса, но обычно сдерживать жаждущих новых игрушек технарей так долго не удается. По меньшей мере, не дайте им начать проект с выбора системы. Большинство бизнес-проблем, с которыми сталкивается служба ИТ, связаны с культурой или процессами. Если проблема в культуре, решение не может лежать в области технологий. Если вы стареете и толстеете, покупка красной спортивной машины не решит эту проблему (хотя, возможно, ваше отношение к ней изменится). Технологии работают там, где служат людям и процессам, там, где они были выбраны или спроектированы с оглядкой на тех людей и те процессы, и там, где люди и процессы могут обойтись и без технологий. Технологии делают работу людей более производительной, а процессы - более стабильными. И крайне редко делают возможным то, что не было возможно без них. В модели РРТ1 буквой Т можно обозначить не Технологии (Technology), а вещи (Things), поскольку перекос в восприятии мира носит более общий характер: во главу угла ставятся продукты, документы, формы... объекты. Находятся даже люди, рассматривающие процессы как объекты. Для того, чтобы изменить практику, необходимо работать с людьми, участвующими в изменении, и с «процессом внедрения процессов» («мета-процессом»). Только потом появится процесс-какдокумент, то есть описание новой практики. Тем не менее многие проекты начинаются с рисования форм, после чего люди начинают решать, как эти формы реализуют необходимые функции. Более того, бывает, что новые формы публикуются - и всё, это и есть новый процесс. Это всё тот же подход «от вещей». Он не работает. Эти новые формы никто не будет использовать. Аналогично, множество проектов сводится к написанию и распространению документов, описывающих новый процесс. И это тоже не работает, и документы собирают пыль на шкафах. Оглянитесь: сколько процессов вы видите вокруг - на стенах, в общих папках, на корпоративном портале, где угодно, только не в реальности? People - Process - Technology. People - Practices - Things. Какую бы модель вы не использовали, думайте о культуре в первую очередь, а о предметах - в последнюю, и вы увидите, что внедрение новых услуг, систем, практик пойдёт гораздо легче и результативнее. Рекомендации 91. Начинайте все внедрения систем с изменения культуры, с людей. Затем переходите к деятельности, а уже потом - к вещам. 92. Не пытайтесь исправлять людей с помощью технологий. 1

People - Process - Technology

56

Соответствие систем ITIL OGC и itSMF пренебрегли такой областью как соответствие ПО ITIL. Официального определения такого соответствия не существует. Поэтому о таком соответствии не заявляет только ленивый. Большинство систем, автоматизирующих эксплуатацию ИТ, «поддерживают ITIL» или «соответствуют ITIL». Есть даже примеры вендоров, чьи продукты якобы сертифицированы по ITIL (чего не бывает в принципе, сертификация в ITIL есть только для специалистов).1 Особенно раздражают те производители ПО, которые вешают ярлык «ITIL» на отдельные функции (кнопки, формы) своих продуктов - в случайной связи с первоначальными значениями слов, в которых они видят соответствие. («О! Непрерывность! У нас это есть: администратор может делать резервную копию данных. Мы соответствуем!») ITIL не зависит от технологий. Вы можете следовать рекомендациям ITIL, используя липкие бумажные листочки Post-it™, и если дела и дальше пойдут так, как они идут сейчас, зМ скоро будет рекламировать эти листочки как «совместимые с ITIL». Привычка вендоров лепить слово «ITIL» на каждый продукт, хоть как-то связанный с эксплуатацией ИТ, размывает и обесценивает смысл слова «ITIL» и вводит в заблуждение потребителей. Их (вендоров) можно понять (ну... до некоторой степени). Несмотря на бездействие OGC и itSMF, они не могут оставить ITIL без внимания. Независимой сертификации программных продуктов на соответствие ITIL тоже не существует. Pink Elephant предлагает сертификацию PinkVerify™, но, по опыту Скептика, она не учитывает некоторых важных критериев (из числа приведённых ниже) при оценке соответствия. OGC уже давно проводит сертификацию специалистов, а стандарт ISO 20000 дал нам и сертификационную схему для организаций. Ходят слухи о появлении в будущем и сертификации ПО на основе ISO20000. Вендорам ничего не остаётся, кроме как изобретать собственные свидетельства «соответствия» и некуда идти за подтверждением этого соответствия, кроме как в Pink Elephant. Однако существует несколько очевидных признаков, по которым можно довольно уверенно судить о «соответствии ПО ITIL». Задайте приведённые ниже вопросы кандидатам на роль вашего поставщика ПО для ITIL, не исключая тех, что уже прошли сертификацию PinkVerify2. Кто утверждает, что этот продукт соответствует ITIL? На каком основании? Какой уровень зрелости процессов он поддерживает? То, что кто-то считает, что система обеспечивает адекватную автоматизацию управления инцидентами на уровне зрелости «2», не очень ценно для вас, если вам нужно автоматизировать управление уровнем услуг на уровне «4». Есть ли среди проектировщиков продукта сертифицированные сервис-менеджеры или эксперты? Главный архитектор сертифицирован по ITIL? Нет? Вообще никто? Тогда кто тот гуру, что их консультировал? Потребуйте возможности пообщаться с этими людьми. Используется ли терминология ITIL (корректно!)? Важный плюс от следования любому общепринятому подходу или стандарту - это стандартные термины. Благодаря им поставщики, аудиторы, тренеры и временные сотрудники быстро находят общий язык. Поэтому нет ничего хорошего в том, что инциденты называются в системе как- то иначе (особенно - в том, что они называются там «проблемами», а проблемы - «сбоями»). Путаница может зайти очень далеко. 1

С момента написания книги ситуация изменилась. OGC стремительно наверстывает упущенное. Подробнее о современном состоянии сертификации ПО на совместимость с ITTL можно узнать, например, здесь: http://vww.cleverics.ru/ru/subject-field/hot-issues/itn-software-scheme 2 ...и тем более - не исключая тех, что прошли сертификацию OGC (Прим. переводчика)

57

Поддерживаются ли системой процессы ITIL? Использовать правильные слова недостаточно. В книгах ITIL довольно внятно описаны процессы. Если система не поддерживает эти процессы (и их бесчисленные вариации, возникающие при внедрении в жизнь), то система не поддерживает ITIL. Поменять пару слов на экранных формах и сказать, что теперь мы соответствуем ITIL - это слишком просто. Большинство серьёзных производителей ПО предлагают своим покупателям консалтинг. В этом случае посмотрите внимательно на состав предлагаемых работ. Внедрение продукта и внедрение ITIL - очень разные вещи. Иногда консультанты даже не упоминают ITIL. Посмотрите на сайт вендора: какие там есть руководства и другие поддерживающие документы? Если ITIL в них не упоминается, вы можете быть уверены: вас пытаются провести. Поддерживает ли система потоки работ (workflow)? Довольно странно, если система автоматизации процессов этого не делает. Есть ли в системе шаблоны потоков работ для процессов ITIL? Описывает ли документация к системе внедрение этих потоков? ITIL - про управление качеством. Как решается эта задача в системе? Например, как реализовано определение целей и порогов? Как формируется соответствующая отчётность? Как реализован цикл Деминга? (Примечание: практически все продукты на рынке проваливают эту часть теста.) Позволяет ли система управлять услугами? Системы, которые не транслируют измерения на уровень услуг - не ITIL-системы. Что не мешает им предоставлять последним полезные данные об инфраструктуре. Например, средства мониторинга должны показывать текущий статус услуг; система Service Desk должна показывать состояние услуг с учетом случившихся инцидентов, проблем и изменений; должна быть доступна историческая информация по услугам и параметрам их качества. Как поддерживаются SLA? Управление услугами невозможно без управления уровнем услуг (SLM). Независимо от того, чем управляет предлагаемая система - доступностью, производительностью, безопасностью... узнайте как она получает информацию о содержании SLA и как участвует в мониторинге выполнения SLA. SLA - это контракты с довольно сложной структурой. Они определяют условия предоставления услуг, ответственность сторон и параметры качества услуг. Каждому параметру соответствует целевое значение, или SLT (Service Level Target). Договоренность о времени обработки инцидентов - это ещё не SLA. Это лишь одна из множества целей. Не позволяйте производителям ПО переопределять понятие SLA, подгоняя его под возможности своих систем1. SLA - это про услуги. Это может казаться очевидным, но SLA - не про активы, и вообще ни про что другое; они - про услуги, они определяют уровни услуг. Отдельные цели в SLA могут относиться к отдельным активам; SLA- не могут. Есть ли в команде вендора, работающей на внедрениях, специалисты с сертификацией ITIL выше уровня Foundation? «Основы» - это только основы. Если ваша организация достаточно велика и сложно устроена, вам, скорее всего, понадобится кто-то более сведущий, причём одной сертификации здесь мало, пригодятся ещё знания и опыт. Тем не менее, уровень их формальной подготовки как минимум говорит о серьёзности их отношения к ITIL.

1

Дополнительную информацию по этому пункту можно получить здесь: ABC Cafeterias на сайте Owning ITIL. www.itskeptic.org/owningitil

58

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

Услуги к вашим продуктам Есть вендоры, которые считают, что за процессы отвечает ITIL: «Мы не проектируем процессы, потому что они есть в ITIL». Они путают процессы (описанные в ITIL) с процедурами (требующими настройки с учетом организации и системы). Лишь некоторые из вендоров догадались продавать вместе с системой процессный консалтинг, большинство же ограничивается базовым учебным курсом по ITIL, или же вообще не предоставляет никаких услуг, кроме инсталляции (и иногда - кастомизации) ПО и обучения работе с ним. Такое случается по двум причинам: 1) Непрофессиональные продавцы. Очень часто в ИТ продажами занимаются случайные люди, читавшие надписи на коробках и маленькие цветные брошюры. Продавать коробки проще, чем услуги, a ITIL - лишь одно из слов на коробке. 2) Клиенты, сосредоточенные на продукте. Давайте не будем во всем винить вендоров. Многие заказчики хотят «купить ITIL». При этом они не хотят прилагать усилия к формированию процессов и не хотят платить больше, чем написано на ценнике, приклеенном на коробку с софтом. В результате сотрудники заказчика вертят в разные стороны купленную систему, не вполне понимая, что они, собственно, делают, заново изобретая процедуры и ломая систему в попытках преодолеть кривую обучения, с которой они вообще-то не должны были сталкиваться в одиночестве, без поддержки. Если же в игре участвуют правильные консультанты, они привносят в неё знания, опыт, прошлые наработки, и методологию для построения процессов и мотивации людей. ИТ-отрасль, кажется, обречена вечно вновь и вновь открывать для себя тот факт, что покупка интеллектуальной собственности всегда дешевле, чем её повторное изобретение. Будьте реалистами. Стоимость хорошего консалтинга при внедрении системы автоматизации будет выше стоимости самой системы. Такое внедрение должно включать в себя разработку процедур, учитывающих специфику вашей организации, при активном участии ваших сотрудников; обучение персонала работе по-новому; документирование этих процедур; запуск постоянно действующей программы по поддержке, мониторингу и совершенствованию, включающей в себя обучение новых сотрудников. Будьте ещё реалистичнее. Общая стоимость системы вместе с консалтингом должна составлять меньше трети общей стоимости проекта с учетом проектирования процессов и - снова и снова мы будем говорить об этом - изменения культуры. Ищите подходящих людей. Иногда хорошие консультанты находятся у вендоров, но это скорее исключение. Обычно крупные консалтинговые фирмы обладают хорошей методологией и подготовленными специалистами, но вместо этих специалистов заказчик часто получает мальчиков в галстуках. Берегитесь экспертов-продавцов, покидающих проект немедленно после подписания договора. Часто самые опытные и грамотные консультанты - это фрилансеры, для которых лучшая реклама - это отзывы клиентов, передаваемые из уст в уста. С другой стороны, объявить себя консультантом может кто угодно... Формальная квалификация в ITIL значит очень немного. Экзамены по ITIL3 - это тесты, не имеющие ничего общего с практикой; сертификация бессрочна и не требует подтверждения; каждый курс занимает лишь несколько дней. 59

Ничто не заменит практики и результатов, которые можно посмотреть и пощупать. Даже опыт значит мало: в отрасли хватает ветеранов, вроде автора этой книги, занимающихся ITIL со времен перфокарт. Это не обязательно значит, что они хорошие консультанты (хотя может и означать). Узнайте о прошлом консультантов. Выясните что они сделали. Рекомендации 94. Запаситесь солидной суммой денег, чтобы обеспечить отдачу от внедрения системы. 95. Тратьте эти деньги на людей, которые внедрят систему быстро и качественно. 96. Выбирайте людей, а не компании, на которые они работают. 97. Выбирайте этих людей на основе результатов их прошлой деятельности. 98. Поинтересуйтесь стандартным набором услуг, который они предлагают: если у них достаточно опыта, они смогут сформировать для вас такое предложение.

Какие нужны инструменты? Ваши требования к системам автоматизации могут меняться в зависимости от сложности, зрелости и важности процессов ITIL в организации, но можно определить универсальный минимальный набор инструментов. Service Desk В теории подойдет и Excel, но на практике всем требуется средство отслеживания «заявок» инцидентов, проблем и изменений. Эти три типа должны быть отдельными объектами, а не подвидами одного объекта. Неважно, что говорит поставщик. Система учёта заявок (инцидентов, нарядов, тикетов...) - это ещё не Service Desk, хотя система Service Desk и должна отслеживать обработку заявок. В ней должна храниться информация об активах, и заявки должны связываться с активами. Должна быть информации о пользователях, и заявки должны связываться с пользователями. Если активы тоже связываются с пользователями - отлично. Заявки должны передаваться между группами и отдельными исполнителями. Очень важна база знаний: возможность сохранять, находить и повторно применять решения силами пользователей и персонала ИТ. Поддержка потоков работ - отличное дополнение. Она позволяет определять стандартные последовательности действий для типовых инцидентов, проблем и изменений. Управление активами Лучше, если управление активами будет интегрировано в систему Service Desk, но возможно и использование отдельных от Service Desk решений. CMDB Об этом сказано достаточно. Скорее всего, она вам не нужна, ибо: • • • •

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

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

Мониторинг в точке потребления Самый быстрый, результативный и недорогой способ измерения производительности и доступности - это агент, установленный на некоторых рабочих станциях, измеряющий время прохождения транзакций, отклика интерфейсов и другие показатели в точке потребления. Сделайте такую систему приоритетной задачей при организации мониторинга. Каталог услуг Любой текстовый редактор справится с задачей формирования каталога. Не покупайтесь на рекламу мега- инструментов, они только ограничат возможности форматирования. Управление проектами Не пытайтесь управлять проектами в системе Service Desk. Используйте специализированные инструменты. Существуют бесплатные - как в сети1, так и устанавливаемые2. Управление исходным кодом Часто это оказывается полезным приобретением - как для службы эксплуатации, так и для разработчиков. Разработчикам может потребоваться только контроль версий и сборок. Полный жизненный цикл включает в себя построение релизов, контролируемое развертывание в продуктивной среде, и вообще перемещение между средами. Отчётность Почти у всех ИТ-служб есть универсальное средство генерации отчётов. Вам захочется собирать данные из таких средств и лепить из них отчётность о качестве услуг (и пока вы не научитесь это делать, не обещайте заказчикам «отчётность» в качестве параметра в SLA). Рекомендации 99. Будьте проще. Системы, которые не обеспечивают значимую автоматизацию процесса, или не повышают рациональность, или производительность, только повышают затраты и риски. 100. Интеграция - не самоцель. Не надо ради неё совершать подвигов, коль скоро инциденты, проблемы, изменения, активы и пользователи каким-то образом связаны в ваших системах.

ИТ - тоже заказчик Чрезвычайно забавно наблюдать, с каким великолепным презрением относятся департаменты ИТ к своим собственным системам. Не требует долгих доказательств утверждение, что система Service Desk или средства мониторинга по меньшей мере так же важны для бизнеса, как основные бизнес-системы. Если система Service Desk или центр мониторинга недоступны, влияние этого события на все работающие системы очевидно, так почему эти системы так редко бывают сами переданы в эксплуатацию? Они заслуживают уважения и соответствующего обращения; в частности, по ним должны быть подписаны SLA и они должны быть переданы на поддержку наравне с другими важными бизнессистемами. Рекомендации 101. Все системы «для ИТ» должны быть включены в каталог услуг как услуги «ИТ дл ИТ», а также должны быть частью планов доступности и непрерывности. 102. Для этих систем должны быть предусмотрены основные среды, как минимум тестовая, учебная и операционная.

1 2

Например, Basecamp www.basecamphq.com Например, Open Workbench www.openworkbench.org

61

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

Заключение («Завершение»? «Подытог»?) ITIL - отличная идея, когда это отличная идея. К сожалению, на пике моды вокруг ITIL возникло множество предложений, которые хорошими идеями не являются. Вендоры не помогут вам отличить одно от другого, и консультанты тоже не всегда помогут. Основным правилом заказчика в ИТ-отрасли становится «подвергай сомнению». В книгах ITIL полно интересных идей. Но это не священное писание, и даже не руководство к действию. Необходима большая работа, направленная на определение того, какие из этих идей подходят вашей организации и в какой форме. ITIL - это не чудо. Это просто один из инструментов для трансформации процессов и культуры в вашей организации. Именно культуры. ITIL - прежде всего о людях. Если не уделять людям должных внимания, усилий и средств, процессы и технологии не имеют смысла. Впрочем, это справедливо для любой организационной инициативы. Если вам понравилась эта книга, вы можете найти ещё несколько, с комментариями, на www.itskeptic.org. и www.realitsm.ru

14 вопросов про предложение о внедрении ITIL 1. Каково видение? Какова стратегия реализации этого видения? 2. В чём состоят требования/нужды, инициировавшие проект? 3. Как будет оцениваться успех? Какие ориентиры используются для измерений и оценки? Используются ли критерии, взятые не из ITIL (см. стр. 30)? Связаны ли метрики с заявленными преимуществами от реализации проекта? 4. Какова целевая зрелость процессов? (см. стр. 29) 5. Какова итоговая ценность? Чего мы ждём - снижения затрат, повышения удовлетворённости заказчиков, снижения рисков, повышения конкурентоспособности? Можно ли выразить эту ценность в деньгах? На каких метриках основаны эти ожидания, и откуда взяты метрики? 6. Зачем и почему нам это нужно? Что неправильно сейчас? (см. стр. 31) В самом ли деле нам нужны «лучшие практики»? Есть ли более простое решение? (см. стр. 22). В частности, есть ли в предложении CMDB? Зачем она нам? (см. стр. 32) Что она добавит к тому, что уже есть сейчас? Какие проблемы решит? Насколько оправданы связанные с ней затраты? Включают ли они текущие затраты на сопровождение и актуализацию данных? 7. Есть ли те, кто против внедрения ITIL? Почему они против? Иногда на то есть причины. Поговорите с противниками проекта. 8. Какая часть бюджета проекта запланирована на работу с людьми: обучение, мотивацию? (см. стр. 45) 9. Откуда планируется брать людей? Нельзя внедрять ITIL в свободное от работы время. И нельзя учиться внедрять ITIL только лишь пробуя внедрять ITIL. Привлеките внешнюю экспертизу. 10. Кто оценивал риски, время, затраты? Каков их практический опыт в таких делах? Этот опыт применим в нашей ситуации? Достаточно ли внимания уделяется людям и процессам, или в центре проекта - опять технологии? 62

11. Какие меры призваны обеспечить, что изменения «приживутся», а улучшения продолжатся и дальше? Кто отвечает за реализацию этих мер? Как они финансируются? (см. стр. 45). Проекты, ориентированные только на технологию, обычно проваливаются. 12. Как проект интегрирован в текущую практику и связан с используемыми методологиями управления (см. стр. 49)? 13. Вы уже выбрали систему автоматизации? Если да - забудьте об этом выборе. Инструментарий нельзя выбирать раньше, чем будут спроектированы процессы. 14. СЕО и СIО поддерживают этот проект? Если нет - почему вы думаете, что они передумают? Не будет поддержки руководства - не будет надежды на успех. Это не исчерпывающий список. На странице www.itskeptic.org/owningitil можно проверить, не изменилось ли в нём что-нибудь, и предложить свои варианты.

14 вопросов по ходу ITIL-проекта 1. Проект встречает сопротивление? (Сопротивление это хорошо). Вы справились/справляетесь с ним? (игнорируемое сопротивление - это плохо). 2. Есть ли у проекта сторонники, которых вы «обратили» уже после начала работ? 3. Какие действия по изменению культуры вы предпринимаете (семинары, рассылки, консультации, разборы полётов, тренинги, мониторинг, обратная связь...). Помните, что электронная почта - не способ общения. 4. Кто и как участвует в проекте со стороны разработчиков, эксплуатации, тестировщиков, управления проектами, архитекторов, финансистов, бизнес-менеджеров, управления персоналом? 5. Как вы социализируете свои процессы? (Электронные письма и интранет - не считаются). 6. В терминах Коттера1, кто ваша «команда единомышленников»? 7. Насколько сознательно вы выбрали ITIL в качестве основы проекта? Оценивали ли другие варианты (COBIT, MOF, FITS, ISO20000... см. стр. 18) 8. Как поддерживается вовлечённость руководства? Все ли руководители приняли проект? Есть ли такие, что хотят для себя исключений из правил? 9. Готов ли каталог услуг (он должен стать одним из первых результатов проекта, по меньшей мере - его актуальная версия (см. стр. 52))? 10. Документируются ли корректировки, решения, исключения, отличающиеся от канонического текста ITIL, и их обоснования? (Адаптация - это отлично, пока мы понимаем её причины и пользу от неё). 11. В какой степени мы воспроизводим или меняем существующие процессы? Была ли рассмотрена возможность использования текущих практик? Рассматривались ли компромиссы и почему их отвергли? 12. Чего ждут от нас заказчики? Учтено ли это в красивом каталоге (стр. 52)? Что из этого мы можем предоставлять на практике? Что мы можем измерять? 13. Есть ли потребность в новых технологиях? Как это определили? (Требования к автоматизации должны вытекать из решений об улучшении процессов - см. стр. 55) Работы интегратора по внедрению системы включают в себя создание новых процедур (стр. 57)? Какая кастомизация системы необходима? (любая кастомизация должна быть тщательно обоснована и может выполняться только в случае крайней необходимости: она всегда сильно удорожает последующую работу по сопровождению системы). 14. Управляющий комитет проекта по-прежнему активно работает? Есть что-то, что вы не хотели бы им сообщать?

1

«Восемь шагов Коттера». Яндекс. Найдется всё.

63

Это не исчерпывающий список. На странице www.itskeptic.org/owningitil можно проверить, не изменилось ли в нём что-нибудь, и предложить свои варианты.

14 вопросов перед закрытием ITIL- проекта 1. Как проект изменил то, как люди думают, говорят и действуют? Приведите примеры, анекдоты... 2. Что сказали заказчики? А поставщики? 3. Как мы измеряли успешность проекта? Использовали мы при этом что-то кроме ITIL? Каковы результаты измерений? 4. Что пришлось изменить по сравнению с первоначальным планом и обоснованием? 5. Измеряется ли отдача от сделанных инвестиций? На какое время запланирована следующая оценка ROI? 6. Кто владеет каждым процессом? Один человек на процесс. Эти люди в курсе? 7. Есть ли у нас описания процедур для каждой роли? Откуда каждый исполнитель знает, чего от него ждут и что для него изменилось? Какие у исполнителей KPI? Мы их собираем? Какие поощрения предусмотрены за достижение целей? 8. Где процессная документация? Как организован доступ к ней? Кто знает, что она там? Кто отвечает за неё и поддерживает её в актуальном состоянии? Кто ей пользуется? 9. Какие системы были внедрены? Они переданы в промышленную эксплуатацию? (см. стр. 61) 10. Были ли документированы корректировки, решения, исключения, отличающиеся от канонического текста ITIL, и их обоснования? 11. Самое главное: Какие процессы обеспечивают поддержку, сохранение, консолидацию сделанных инвестиций? Осуществляются ли мониторинг и оценка? Про водится/.запланирован ли аудит внедренных процессов? Оценивается ли качество процессов? (см. стр. 45) проводим ли мы регулярное обновление знаний и навыков? Есть ли программа наставничества? Подтягиваем ли мы отстающих? Обучаем ли новичков? Празднуем ли успехи и находим ли новые источники вдохновения? 12. В чём состоит процесс постоянного улучшения? Кто за него отвечает? Кто его финансирует? Перед кем они отчитываются? Что мы измеряем? Кем и как устанавливаются цели совершенствования? 13. Каковы дальнейшие планы? Кто будет отвечать за ITIL в дальнейшем? 14. Каков следующий этап проекта? Когда он начнется? Это не исчерпывающий список. На странице www.itskeptic.org/owningitil можно проверить, не изменилось ли в нём что-нибудь, и предложить свои варианты.

14 вопросов о жизни в ITIL-среде 1. Кто отвечает за отношения с заказчиками? Все ли заказчики учтены? 2. Какой каталог услуг доступен заказчикам? Пользователям? Персоналу ИТ? (см. стр. 40) 3. Как пользователи заказывают новые услуги или изменения в имеющихся? Как выполняются такие запросы? 4. Когда вы последний раз праздновали успехи в работе или достижение целей? 5. Кто владеет каждым процессом? 6. Кто и как отвечает за правильную работу процессов? Как это оценивается? 7. Проводится ли регулярная оценка качества услуг? Как обрабатываются отклонения, выявленные в ходе такой оценки? 8. Какую подготовку проходят новые сотрудники? Включает ли она обучение процедурам? Как обновляются знания и навыки действующих сотрудников? 9. Что улучшилось за прошедший год? Откуда вы это знаете? 64

10. Как отслеживается удовлетворённость заказчиков? Как она измеряется? Насколько часто? 11. Как отслеживается удовлетворённость пользователей? (Это не повтор. Заказчики платят. Пользователи пользуются.) 12. Как проводится оценка процессов и процедур? Кто в этом участвует? Как часто? 13. Когда был последний инцидент высшего приоритета? 14. Насколько достоверны данные в отчётах, в частности - в отчётах о качестве услуг? О чём вы не можете предоставить отчётность? Это не исчерпывающий список. На странице www.itskeptic.org/owningitil можно проверить, не изменилось ли в нём что-нибудь, и предложить свои варианты. Об авторе ИТ-скептик (The IT Skeptic) - это псевдоним Роба Ингланда, ИТ-консультанта и комментатора. Несмотря на то, что он работает в ИТ, он не намерен ничего вам продавать, кроме идей в этой книге. Более двадцати лет Роб занимается тем, что связывает требования бизнеса и возможности ИТ, десять из них - с помощью ITSM. (Некоторые читатели будут рады узнать из этой книги, что же все-таки значит эта аббревиатура). Он активно участвует в работе itSMF (сообщество ITILпрофессионалов). Он ведет популярный блог (www.itskeptic.org), написал смешную книгу «Введение в реальный ITSM» и множество статей о несуразицах в мире ИТ, особенно - ITILнесуразицах. Роб живет с женой и сыном в маленьком доме в небольшой стране очень-очень далеко.

65