Чем библиотека ITIL 2011 лучше, чем ITIL 2007? Короткий ответ: структурностью и практической полезностью. Сейчас расскажу.

Про структурность: стало однозначно лучше. Например, авторы всё-таки договорились о том, что такое "назначение" и "задачи" ("Purpose & Objectives") процесса, и согласились с Дмитрием Исайченко, что цели процесса у каждого поставщика услуг – уникальные, поэтому перечисления "Goals" теперь нет вообще. Структура описания теперь совпадает во всех пяти книгах, для всех 26 процессов.

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

В версии 2007 были описаны техники диагностики проблем:

1. Хронологический анализ (Chronological analysis)
2. Анализ стоимости потерь (Pain value analysis)
3. Метод Кепнера-Трего (Kepner and Tregoe)
4. Мозговой штурм "Групповое творчество" (Brainstorming)
5. Диаграммы Исикавы (Ishikawa diagrams)
6. Анализ Парето (Pareto analysis)

А вот содержание этого же раздела в 2011 году:

1. Хронологический анализ
2. Анализ стоимости потерь
3. Метод Кепнера-Трего
4. Коллективное обсуждение идей 
5. "5-причин" (5-Why’s)
6. Изоляция неисправностей (Fault isolation)
7. Карта сходств (Affinity mapping) 
8. Проверка гипотез (Hypothesis testing)
9. Диаграммы Исикавы
10. Команда технического наблюдения
11. Анализ Парето

После описания методов размещена таблица: ваша ситуация – применимые к ней методы.

• Сложная проблема, с непонятной последовательностью ошибочных действий? Хронологический анализ и техническое наблюдение.
• Не знаете, за какую проблему браться первой? Анализ стоимости потерь и коллективное обсуждение идей.
• Непонятно, откуда начинать поиск причины? Метод Кепнера-Трего, "мозговой штурм", карта сходств и 5-Why's. И так далее, на полстраницы, мелким почерком.

В следующем посте напишу про одну из техник, которая мне особенно приглянулась.

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

Почитать на эту тему можно у знатоков (Роб Ингланд, Джеймс Финистер, Евгений Шилов и другие), а отследить волну щебета, хотя бы у нас на портале realitsm.ru, в Дайджесте ITSM-твитов.

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

Тот же Джеймс Финистер указывает семь:

• Сбор "разведданых" о пользователях: их желаниях, степени удовлетворённости, и даже о конкретных сервисных инцидентах
• Проверка идей: например, опросы типа "Что вы скажете, если мы прикрутим к нашей электронной почте ЭЦП?"
• Коммуникации с пользователями: оперативные и маркетинговые, с активной обратной связью
• Выстраивание отношений с пользователями и заказчиками
• Выстраивание сообществ (про кладбище сообществ писал не так давно Роб Ингланд)
• Обучение пользователей. Включая самообучение и передачу знаний между пользователями. Опасная штука.
• Gamification (поостерегусь пока переводить это замечательное слово; здесь оно используется узко: накопление "кармы" и авторитета в социальной сети, к чему могут стремиться некоторые пользователи, ну как на Хабрахабре).

Из такого списка, в России на текущем уровне развития мне кажутся приземлёнными и приносящими пользу быстро только такие:

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

Как и всегда, реализовывать эти рекомендации следует, если ожидается действительно существенная информация и обратная связь от сообщества пользователей. А после реализации поставщик услуг должен делать так, чтобы сеть продолжала работать. Это сложная задача: большинству пользователей "некогда, работать надо!", а топливом для самообеспечения сообщества пользователей может служить только недовольство поставщиком услуг. Шутка.

И главное, в чём я полностью согласен с дядей Робом Ингландом: социальные сети — это "модная игрушка", технология. А технологии в ITSM, как известно, только на третьем месте, после людей и процессов...

Как считаете?

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

В стандарте ISO/IEC 20000-1:2011 появилось определение Internal group (внутренняя группа), следующего вида:

internal group — part of the service provider's organization that enters into a documented agreement with the service provider to contribute to the design, transition, delivery and improvement of a service or services

NOTE The internal group is outside the scope of the service provider's SMS

Мой перевод:

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

ПРИМЕЧАНИЕ Внутренняя группа находится вне охвата системы управления услугами (СМС).

Это определение в тексте стандарта встречается 6 раз (вне глоссария):

• 2 раза в Governance of processes operated by other parties, где эта внутренняя группа приравнивается к внешним поставщикам услуг или компонентов.
• 1 раз в Design and transition of new or changed services, где внутренние группы являются источником новых требований к услугам, наряду с заказчиками и внешними поставщиками.
• 3 раза в требованиях к процессу Service Level Management, где стандарт требует заключения SLA с заказчиками, внешними поставщиками и внутренними группами.

Теперь из глоссария ITIL урожая того же года:

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

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

И там и там фигурирует некая "организация поставщика услуг", зажатая между заказчиком и внешними контрагентами.

Меня интересует ее "часть", которая упоминается в стандарте как internal group, а в ITIL — как субъект, с которым поставщик услуг заключает OLA.

ITIL даёт два варианта ответа: 

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

Стандарт же, насколько я могу трактовать вышеприведённое ПРИМЕЧАНИЕ, от второго варианта отказывается вовсе.

То есть аудитор, который будет сертифицировать СМС организации  на соответствие стандарту ISO 20000 (не важно — по версии 2005 или 2011 года), не будет рассматривать имеющиеся OLA как свидетельства СМС? 

То есть OLA в смысле договорённостей между различными командами\департаментами\отделами поставщика услуг — не нужны?!

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

То есть ITIL не прав?!.. дальше уж боюсь думать;)

Спасайте в комментариях! =)

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

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

На портале realitsm.ru мы редко поднимаем вопросы, связанные с Quality Assurance, а ведь они действительно значимы. И предложенный мини-кейс очень похож на то, что я видел на практике.

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

1. На стратегическом уровне: следует определить список наиболее важных систем, продемонстрировать потери, которые терпит бизнес от невыявленных при тестировании ошибок. Следует убедить заказчиков выделять средства на обустройство полноценных тестовых сред, расходы на которые будут меньше, чем такие потери. Наглядно сработает в бизнесе, результаты которого критичны для конечных клиентов: здравоохранение, военная промышленность…
2. На тактическом уровне: организовать «опытно-промышленный периметр»: часть продуктивной среды, в которой новые версии будут тестироваться уже в боевых условиях, с реальными сценариями, данными и нагрузкой. Влияние выявленных ошибок будет ограничено этим небольшим периметром. Здесь нужно предусмотреть резервные мощности и сверхбыстрые механизмы отката на стабильную версию. И, конечно, широко разрекламировать «лётчиков-испытателей» – пользователей, которые попали в периметр.
3. На операционном уровне: конечно же, поможет виртуализация. Сегодня можно настроить имитацию почти любых аппаратных ресурсов, и установить буквально «за один щелчок» почти любое ПО в ней. Стоит недорого. Позволит нескольким командам QA использовать одну и ту же платформу, обеспечивая ее ритмичную нагрузку.

Вот. А что думаете вы?

Я часто вижу и удивляюсь, что управление уровнем услуг (Service Level Management) привлекает внимание со стороны сотрудников технической поддержки. Они пытаются найти в этом процессе ответы на свои вопросы.

Причина этого внимания, как мне кажется — толкование ИТ-услуги как «обслуживания»: работа с клиентом в процессе потребления (автосервис, ресторан и так далее).

А ведь во многих сводах знаний (в том числе и в ITIL) подчёркивается разделение «клиентов» на заказчиков и пользователей.

Заказчик платит ИТ за результат, чтобы достичь своей выгоды.

Пользователь, извините, использует результаты ИТ, чтобы ему было удобно делать свою работу.

Чувствуете, куда веду?

Конечно. Акула капитализма и член профсоюза Работодатель и работник!

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

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

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

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

Или можно?

Голова пошла кругом от PAM, CMMI и прочих моделей. Чтобы вернуться в реальность, я попытался честно ответить себе на вопрос — зачем вообще повышать зрелость процессов? Решил поделиться ответом с вами =)

Я вижу всего 4 последовательных и значимых уровня зрелости ИТ-процессов:

• Не-процесс. Когда работа просто выполняется. Документации нет или её мало или она устарела. Отчётность составляется от случая к случаю, для "разбора полётов". Автоматизация лоскутная, возможно, дорогими "микроскопами".

Такой "процесс" есть у всех: работа просто выполняется.

• Дорогой процесс. За него мы платим экспертам "на зарплате", внешним консультантам или вендорам. Есть вся документация и формы отчётов, за которые заплатили. Причём отчётность и реакция на её анализ уже заложены в регламенты и процедуры — пока этого нет, процесс Дорогим не станет. Автоматизация поддерживает процесс. 

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

• Настоящий процесс. Соответствующим духу книг и аудируемым (по ISO 20000) становится Дорогой процесс, если о нём долго никто не забывает после внедрения. Появляются доказательства существования процесса: например, артефакты и протоколы. На этом уровне появляется осведомлённость о процессе и работает система мотивации на основе процессных метрик. Автоматизация поддерживает изменения в процессе.

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

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

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

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

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

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

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

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

С ходу:

• "Верхушка айсберга"

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

• "Подводные камни"

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

• "Возьмём любую ИТ-услугу, например, электронную почту"

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

• "Девочка из коллцентра с приятным голосом"

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

• "Бородатый сисадмин, который против ITSM"

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

• Сравнение жизненного цикла ИТ-систем и услуг с рестораном

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

• "Мы хотим построить ресурсно-сервисную модель"

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

Вот что удалось вспомнить. Рейтинги сегодня в моде, предлагаю в комментариях голосовать за лучший канцеляризм. Ну и пополняйте список! Может быть, издадим отдельным словарем в рубрике "BS-Free zone" =)

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

Теория не влечёт: вся эта временная структура управления и постоянное подтверждение бизнес-обоснования оторваны от реальности, которая у коллег каждый рабочий день перед глазами. Гораздо нужнее получить ответ: какое ПО можно внедрить, чтобы устранить все трудности, с которыми сталкиваешься в проекте? Этого ждут от курса.

Ну так вот. Мне совершенно не хочется рекламировать какие-то продукты (попробуйте, кстати, угадать сколько продуктов в списке Project Management Software в англоязычной Википедии, перед тем как туда заглянуть. Угадали?). План курса уже занят гораздо более интересными темами. И кстати, курс — о другом: об общих принципах, техниках и видах деятельности, которые необходимо адаптировать под конкретные нужды.

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

1. Классический. Начинайте с Excel. С простейшего. Примерно, как описано здесь, спасибо нашим читателям-комментаторам =).
2. Социальный. Пусть инструмент экономит вам время на синхронизацию информации среди участников проекта. Интереснейшая тема инструментария совместной работы (Collaboration tools) очень недооценена у нас, а ведь может принести существенные выгоды не только в проектной работе. Отслеживание обновлений в результатах проекта, тиражирование информации, дистанционные совещания и т.д. Напишу по этому поводу подробно, в другой раз.
3. Арифметический. Инструмент должен считать ресурсы. Вот цитата из прошлой жизни:
   

   ...теперь системный администратор 60% времени занимается «своими делами», остальное время – работает на «вашем» проекте.

   Классно, но как измерить эти 60% и какие-такие «свои» дела будут у системного администратора – должен уметь подсказать инструмент автоматизации учёта рабочего времени. Так же, как и в предыдущем пункте, такой функционал пригодится не только для проекта.

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

А что из важного не упомянул? Поделитесь и поспорьте в комментариях

Как и обещал, начинаю цикл статей "Standing up for ITIL" с того, каким замечательным мне кажется определение услуги, данное в глоссарии:

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

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

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

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

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

Специфические расходы и риски — самое интересное. Когда вы включаете кран, вы не думаете:

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

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

Также вы не вспоминаете:

• телефон водопроводчика (пока ничего не сломалось),
• размер и срок внесения очередного платежа «за воду»; конечно же, порядок расчётов с поставщиком услуги вам известен, однако вы вряд ли вспоминаете о нём каждый раз, когда открываете кран.

А это — примеры рисков, которые могут наступать в ходе предоставления и потребления услуги.

В этом же примере удобно иллюстрировать различие utility и warranty.

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

А параметрами гарантии услуги станут:

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

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

Подводя итог, моё мнение: будучи правильно проиллюстрировано, многословное определение услуги из ITIL V3 (кстати, в глоссарии 2011 оно существенно не изменилось), довольно хорошо демонстрирует различные цели поставщика ИТ-услуг и подчёркивает важность выстраивания тактических и стратегических отношений с заказчиками услуг. Где-то за рамками остались пользователи, ну да ведь они — часть транзакции, правда?

Обещанная в предыдущем посте неделя растянулась и еще дальше отложилась. Много чего интересного довелось делать этим летом.

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

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

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

И вот, где-то после процессов из Service Design (некоторые из которых бесконечно далеки от технических специалистов), в перерыве задают вполне себе обычный вопрос: "А есть в России компании, где вот этот ваш сервисный подход уже работает?".

Тут меня осенило: "Да. Это, например, ваша компания". Ведь:

• Руководство ИТ-службы считает возможным и необходимым выдернуть 20 человек (из примерно 70) из работы на два дня. 
• Руководство ИТ-службы сумело убедить сотрудников, что учиться стоит, и стоит учиться хорошо.
• Руководство ИТ-службы имеет рычаги влияния на распределение образовательных фондов.

Процессы из Service Design и Strategy, регламенты, метрики, SLA и так далее — являются только следствиями успеха реализации ITSM. Скорее всего — сильно разнесёнными во времени.  

А мне повезло увидеть в деле прямое проявление сервисного подхода — management commitment.

Тут лирическое отступление по поводу перевода. 

Вот и подошёл к концу первый день ITIL V3 2011 Edition. Не волнуйтесь, мир ITSM не рассыпался и не перевернулся. На текущий момент нет даже пафосного коммюнике на официальном сайте.

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

И вот что подумалось: обидеть художника может каждый. А вот встать на защиту ITIL, если твои интересы не пересекаются с интересами Британской короны — испытание посерьёзнее.

В своём блоге на realitsm.ru я буду рассматривать самые очевидные неувязки в библиотеке версии 2007 и приводить весомые (надеюсь) контраргументы и пояснять почему в "умной книжке" написано именно так.

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

На следующей неделе я буду защищать вот такой тезис: "определение услуги из ITIL универсально, ёмко, и не лишено изящной многослойности смыслов"