Управление инцидентами и проблемами: как распределить ресурсы

ITIL

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

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

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

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

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

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

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

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

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

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

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

Версия для печати