Не инцидент, не запрос на обслуживание, а что?

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

Событие – любое изменение состояния системы или услуги, имеющее значение для управления ИТ-услугой. (ITIL 4)

Но просто зарегистрировать событие недостаточно. Для контролируемости этого вопроса, для учета времени, потраченного на эту задачу, для координации деятельности нескольких исполнителей, если к выполнению задачи нужно подключить несколько человек, хорошо бы зарегистрировать на основе события некоторый дополнительный объект управления в ITSM-системе. Что же это должно быть?

Инцидент, ЗНО или изменение? Проверяем кандидатов

Не похоже, что это инцидент, ведь…

Инцидент – это незапланированное прерывание услуги или снижение ее качества (ITIL 4).

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

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

Давайте обратимся к теории.

Запрос на обслуживание (ЗНО) – это запрос от пользователя или авторизованного представителя пользователя, который инициирует сервисные операции, согласованные как часть нормального предоставления услуги. (ITIL 4)

Что мы видим? Мы видим, что ЗНО инициируется пользователем, и это его важная особенность! Важная, потому что в том, как выстраивается работа с запросом, удовлетворенность пользователя, впечатление, которое он получает, играет большую роль. В рамках работы над запросом мы стараемся выполнить его максимально удобно и эффективно для пользователя, собираем с него обратную связь после выполнения запроса. Причем работа над повышением удовлетворенности пользователя не является обязательной частью для выполнения технической задачи в рамках запроса (т.е. для того, чтобы технически выдать кому-то доступ, совершенно не требуется собрать с него обратную связь), но для того, чтобы на стороне пользователя создалась ценность, это обязательно.

Будет ли у нас подобная деятельность, когда мы продляем лицензию? Нет, для выполнения этой работы мы никак не соприкасаемся с пользователем, не думаем об удобстве для него, не собираем обратную связь. Собственно, пользователи и не в курсе, что на нашей стороне осуществляется подобная деятельность. Именно поэтому это не ЗНО.

Возможно, деятельность по продлению лицензии – это изменение? Тоже не совсем подходит.

Изменение – это добавление, модификация или удаление чего-либо, способного оказать влияние на ИТ-услуги. (ITIL 4)

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

Простое решение: рабочая задача

Так что же это тогда за объект – наша деятельность по продлению лицензии? Как можно его назвать, как можно его учитывать?

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

Если у нас есть необходимость управлять подобными работами, вести их учет, знать, кто ими занят и сколько по времени, проводить по ним аналитику, то мы можем так и называть их у себя: работы, задачи.

Например, у нас в Altevics такой объект управления называется Заданием.

В других системах можно встретить так же названия «тикет», «таск», «рабочее задание» и им подобные. Да, они не выделяются в ITIL, как отдельные объекты, нет отдельной практики, которая называлась бы «Управление рабочими заданиями», но их упоминание есть во многих местах публикаций. Да и сами авторы ITIL во многих местах напоминают нам, что ITIL – это свод рекомендаций, описание того, что бывает, а как конкретно реализовать ту или иную рекомендацию, какой вариант выбрать – это управленческое решение именно вашей организации.

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

Кстати, коллеги, а как у вас, как вы организуете учет таких задач в своей команде?