itSMF Russia :: Ассоциации организаций и специалистов в сфере управления информационными технологиями «ИТ сервис-менеджмент форум» баннер
НОВОСТИ УЧАСТИЕ В АССОЦИАЦИИ ОБ АССОЦИАЦИИ БИБЛИОТЕКА СОБЫТИЯ ДЛЯ УЧАСТНИКОВ ТРЕБУЮТСЯ СПЕЦИАЛИСТЫ БЛОГИ

30 ноября 2017. Семинар
"Особенности и опыт управления ИТ-активами в госструктурах" >>>

 

 

баннер

 

Присоединиться к ITSM сообществу


Состав itSMF Russia

 

 


книжный магазин itSMF



Подпишитесь на новости ITSM-сообщества

* обязательные поля
Архив рассылок >>>



facebook linkedin баннер twitter



Реестр аккредитованных учебных центров, работающих в Российской Федерации и имеющих право проводить обучение по утвержденному списку курсов ITIL®


Manager’s Certificate in IT Service Management Список ITIL Expert'ов и сервис-менеджеров России и стран СНГ



Список российских профессионалов сервис-менеджмента, обладателей сертификатов priSM




Работа для Вас: актуальные вакансии


О 'бенефитах' управления инцидентами
Untitled Document

 

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

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

Какие же преимущества от работы процесса управления инцидентами обещает ITIL, и что надо знать, чтобы не обмануться в связанных с ними ожиданиях?

 Что написано в ITIL

В ITIL второй версии приводится следующий список преимуществ, даруемых процессом управления инцидентами:

Для бизнеса в целом:

  • Снижение негативного влияния инцидентов благодаря их своевременному разрешению, как следствие – повышение результативности
  • Проактивное определение возможных полезных изменений и добавлений в системах
  • Доступность бизнес-ориентированной информации, соотносимой с SLA

Для ИТ организации:

  • Улучшение мониторинга, возможность соотносить данные с требованиями SLA
  • Улучшенная отчетность для руководства о качестве сервисов
  • Повышение рациональности за счет лучшей загрузки персонала
  • Устранение потерь и искажений информации при работе с запросами и инцидентами
  • Более точная информация в CMDB (за счет проверок при регистрации инцидентов)
  • Повышение удовлетворенности пользователей и заказчиков

Третья версия добавляет к списку выгод для бизнеса еще два пункта:

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

Вот этот список инициатор проекта по «внедрению управления инцидентами» и «продает» спонсорам – высшему руководству ИТ и заказчикам.

Чтобы сказка стала былью…

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

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

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

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

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

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

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

Ставьте реальные цели

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

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

полная версия статьи на сайте IT Expert >>>

Планируемые будущие темы:

1. Оценка работы процессов, показатели и метрики
2. Структура сервисных соглашений SLA
3. "Быстрые победы" при использовании ITIL
4. Аудит управления ИТ
5. Владение и управление процессом
6. Управление знаниями. Data — Information — Knowledge — Wisdom.
7. Что такое руководство ИТ?
8. Запрос на обслуживание и стандартное изменение. Где граница?

Комментарии и предложения темы для следующей заметки можно отправлять на items@itexpert.ru.


 

 



Помогите своим коллегам быть в курсе интересных новостей! Поделитесь!
Документ без названия


баннер

 

 

Приглашаем принять участие
в воркшопе ITSM Labs
баннер


 


баннер


Партнеры itSMF России



 Директор информационной службы
 

Information Management

Открытые системы



Московское отделение ISACA

ABPMP Russian Chapter

GlobalCIO

СоДИТ

SPb CIO Club — партнер itSMF России

Высшая школа бизнес-информатики Государственного университета – Высшей школы экономики (ВШБИ)

МИИТ

ГУУ

Московский государственный университет экономики, статистики и информатики (МЭСИ)

Факультет ВМК МГУ имени М.В. Ломоносова

Московский институт электроники и математики (МИЭМ)

Институт информационных бизнес систем



Блоги: