7 января 2007 года состоялся 12 Круглый стол по ИТ сервис менеджменту.

В отличие от прошлого мероприятия, которое мне откровенно не понравилось, этот был на гораздо более высоком уровне. Понравилось конструктивное выступление Михаила Потоцкого относительно 3 версии ITIL (Михаил приоткрыл завесу таинственности над ITIL3 и назвал конкретные сроки выхода: примерно май 2007 года). ITIL 3 является логическим продолжением ITIL 2, значительно переработанным и усовершенствованным. По утверждению М.Потоцкого, в работе над 3 версией ITIL приняло рекордное количество специалистов из Америки (напомню: традиционно над ITIL работали европейские специалисты). Благодаря этой «свежей крови» рекомендации (по заявлениями знакомых с пре-релизами ответственных товарищей) стали более конкретными, смещаясь от акцента относительно того «что надо делать» к акценту «как надо делать». Отмечу, что вторая версия ITIL не отвечала на вопрос «как надо делать» вообще никак. Кроме того, в третьей версии ITIL появятся разделы, ориентированные на малые (до 100 человек) предприятия, и декларативно будет описан процесс управления персоналом (читаем между строк: самым общими фразами). Кроме того, ITIL 3 полностью перегруппирует и перекомпанует процессы, характерные для ITIL 2 (что говорит о их переосмыслении). Среди официальных языков ITIL 3 значится и русский, что не может не радовать. Правда, пока непонятно, кто именно будет выполнять перевод (оригинал все равно разрабатывается на английском).

Вторая часть Круглого стола была посвящена проблеме оценки рисков при управлении проектами. Выступал представитель компании PM Expert, который здорово (действительно здорово!) описал, как можно управлять рисками проекта со стороны заказчика. За что и был засыпан горой вопросов относительно того, а как управлять рисками проекта в целом (и заказчика, и исполнителя), а также как отдельно управлять рисками исполнителя.

Подробности – на http://www.itsmforum.ru/

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

Сразу же скажу, что с моей точки зрения она (служба) однозначно необходима по следующим причинам:

1. Пользователь порой не в состоянии квалифицированно определить суть инцидента. Например, инцидент с описанием «не работает компьютер», отнесенный пользователем к категории «Сетевые проблемы» может быть просто потерян на той стадии, когда пользователю будет необходима помощь и поддержка за счет того, что проблема не в сети, а в чем-то другом.
2. Автоматизированный ввод инцидентов самим пользователем не отменяет механизма ввода и диспетчеризации инцидентов оператором ServiceDesk, поскольку в ряде случаев пользователь просто не имеет возможности завести заявку (инцидент) для автоматической обработки; (например, компьютер сломан и не включается - как заводить инцидент?)
3. В случае наличия Service Desk пользователь получает единую точку контакта. Это очень важно, поскольку отпадает необходимость запоминать, какой ИТ специалист за что отвечает;
4. В случае отсутствия SD у пользователя может возникнуть «синдром любимого ИТшника», который заключается в том, что свои инциденты он направляет только ему (или, что еще хуже – на его группу, с последующей просьбой взять их в работу именно конкретного сотрудника);
5. При отказе от SD возможна организация «очередей» заявок у высококвалифицированных ИТ специалистов;
6. Через некоторое время после запуска SD при правильной организации работ на первой линии (то есть службой SD) разрешается до 70% (в среднем) заявок (за счет накопления базы знаний). Это экономит время высокооплачиваемых специалистов, освобождая их для других (более важных) задач.
7. Оставшиеся 30% заявок маршрутизируются таким образом, что гарантируется их скорейшее решение. Это происходит из-за того, что первичную классификацию заявок проводит не пользователь, а оператор SD
8. Консультационная помощь пользователям (как правило) может оказываться специалистами SD.
9. В случае отсутствия SD ее роль играет весь отдел ИТ
10. Психологический момент: пользователь всегда знает, куда обратиться с проблемами.

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

Недавно в википедии (ru.wikipedia.org) нашел статью, посвященную ITIL. В ней утверждалось, что ITSM является подмножеством ITIL. Наверное, вопрос из разряда "курица или яйцо", но...

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

• ИТ предоставляет бизнесу сервиы (услуги);
• Качество поставляемых сервисов является измеримой величиной;
• Отношения между бизнесом и ИТ строятся на принципах, описанных в соглашении об уровне сервиса;

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

Кстати, ITSM является частью более общей концепции - BSM (Buisness Service Management), то есть концепции сервисного управления бизнесом.

ITIL (Information Technology Infrastructure library) - это библиотека передового опыта в области организации деятельности ИТ служб. В ней описано - что надо делать. Справедливости ради следует отметить, что и в ней маловато конкретики, но есть рекомендации: как надо организовать деятельность ИТ, чтобы получить некоторые выгоды в виде улучшения ИТ сервисов (сокращение времени обслуживания, повышение отказоустойчивости и т.д.), сокращения расходов (что происходит далеко не всегда). Таким образом, прослеживается совершенно четкая зависимость: BSM - ITSM - ITIL (от теории к практике).

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

Ссылки по теме:

1. Обсуждение статьи ITIL в Wikipedia
2. Статья ITIL в Wikipedia
3. Ветка "Что такое ITSM " на форуме ITSMF

PS. В обсуждении статьи ITIL в Wikipedia скопировал эту заметку. Лучше аргументацию построить все равно вряд ли получится.