Процесс дело тонкое. Перенос сроков.

itsm_ru — 10.12.2010  Друзья, хочется немного отступить от обсуждения общих перспектив менеджмента ИТ к прикладным моделям и элементам процессов управления.
Выполняя проекты по проектированию и реализации процессов у заказчиков, накапливается множество идей и находок. Самые хорошие идеи уже описаны в библиотеке ИТИЛ, но в ходе реализации у конкретных заказчиков возникает немало вопросов, ответы на которые мы находим в ИТИЛ в виде намеков или не находим совсем. Может они покажутся банальными, но без проработки таких деталей эффективную деятельность не построишь. Принимаемые в ходе проекта решения могут быть применимы исключительно в данной компании, а может и решения не так хороши и оптимальны.
Предлагаю к обсуждению тему из процесса управления инцидентами, что делать когда мы вышли из сроков разрешения, установленных целями SLA и не важно, по объективной причине или нет.
В таких случаях применим один из следующих способов, каждый из которых имеет свои достоинства и недостатки.
1) Вариант 1. Действовать строго по букве соглашения. После того как срок SLA был нарушен, считаем показатель нарушений SLA, никаких специальных мер по дальнейшему контролю не производим. Казалось бы все четко и ясно, зачем что-то добавлять, большинство производителей крупных решений в коробочных конфигурациях предлагают именно этот вариант. Но практика показывает, что после истечения срока SLA запрос лишается какого бы то не было ориентира для контроля, и очень часто такая задача «подвисает» и образуется ком нерешенных задач с неактуальным состоянием, и распутывать его даже самому горячему менеджеру не просто. Приходится много вникать в детали, много запоминать, исчезают преимущества организации деятельности в виде процесса.

2) Вариант 2. Основывается на ряде рекомендаций ITIL v3.
В первой описывается, что при изменившихся обстоятельствах, приоритет должен измениться, более того - (цитата) “must be changed”.
Вторая - это пример приоритета «по плану» для инцидентов с минимальным влиянием, для которых срок устанавливается по обстоятельствам.
Так вот изменять срок можно именно для инцидентов с приоритетом «по плану» и все усилия персонала направлены на снижения этого влияния инцидентов путем применения обходных и временных решений. Данный подход решает проблемы первого варианта, но имеет значительный недостаток - в отчетности по процессу не будет информации, оценивающей выполнение нами начальных параметров SLA, т.е. насколько быстро мы потушили пожар. Получить информацию о том, как быстро мы добились снижения влияния конечно можно, но нужны дополнительные разъяснения в SLA для заказчиков (потребителей ИТ услуг).

3) Вариант 3. Помимо цели SLA вводится дополнительный ориентир, назовем его «срок выполнения» или «плановый срок», который при регистрации инцидента соответствует целям SLA, а после его истечения при наличии объективных причин корректируется и контролируется процессом. Заставляем исполнителей описывать причины переноса, оповещать пользователей, даже согласовать срок, классифицировать причины переноса, анализировать их, управлять деятельностью по минимизации числа просроченных инцидентов и, главное, в этом случае легко обеспечить актуальное состояние по всем просроченным задачам. К минусам можно отнести нелегитимность с точки зрения ITIL v3, там про это ни слова, и возможное недоверие к такому подходу, а также сложность в предоставлении отчетности. С другой стороны, налицо явные преимущества. С точки зрения отчётности, мы как бы делим показатель на 2 части. Первый демонстрирует степень «соответствия SLA» и предназначен для потребителей услуг, а второй - «выполнение в согласованный срок», используемый для оценки деятельности внутри ИТ, для мотивационных механизмов и т.д.

Найдутся ли сторонники у каждого варианта? Может у кого-то принципиально другая позиция, будет интересно услышать.

Оставить комментарий

Популярные посты:

• Архив