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

 

баннер

 

баннер

 

поделиться

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


Состав itSMF Russia


 

 


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



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

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



facebook linkedin баннер twitter



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


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



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




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


Управление инцидентами и проблемами: как распределить ресурсы
Виктор Михалев, PC Week/RE №4 (562), 13 — 19 февраля 2007
Untitled Document PC Week/RE №4 (562), 13 — 19 февраля 2007
Автор: Виктор Михалев
13.02.2007

ITIL

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

ITIL определяет процесс управления проблемами как один из самых дорогостоящих с точки зрения выделяемых под него специалистов.

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

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

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

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

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

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

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

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

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

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

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

С автором, начальником отдела архитектурных решений департамента консалтинга компании "Ай-Теко", можно связаться по адресу: mikhaliov@i-teco.ru.

PC Week/RE
Управление инцидентами и проблемами: как распределить ресурсы
Для примера рассмотрим типичную ситуацию, когда регистрируются повторяющиеся инциденты, которые затем устраняются определенными специалистами …
Открыть материал
Документ без названия


 

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


баннер


баннер


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



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

Information Management

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



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

ABPMP Russian Chapter

GlobalCIO

СоДИТ

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

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

МИИТ

ГУУ

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

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

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

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



Блоги: