Comments 14
Спасибо за статью. Взял в закладки . Год назад , почитал бы углубленно и более вдумчиво .
Сейчас , слава богу , тема очень уже далека. Просто по привычке , как академическая статья. Местами очень даже интересно
С заключением не согласен
Менеджмент процессов — это нехитрая наука, которой может овладеть любой хороший руководитель.
Это не наука, а искусство , очень хитрая и неоднозначная тема , и не любой руководитель способен те то, что овладеть а для начала даже понять зачем это все нужно .
Я этим накушался с запасом .....
Интерпретация методологий ITIL/ITSM своими словами?
Очень понравилась статья и отдельное спасибо за схему процесса. А про управление проблемами продолжение будет? И очень круто почитать про эскалацию инцидента, на схеме как будто только эскалация проблемы есть. Например, инцидент не решается разработанными инструкциями, обходных решений поддержка не нашла, считается ли что они на своем уровне показатель выдержали?
Крайне занимательная статья, хотелось бы чтобы больше крупных компаний применяла что-то хотя бы близкое к этому (имелся печальный опыт работы в структуре с не отлаженной системой устранения интцидентов)
В целом, неплохая статья, вопросы вызывает только вторая схема, где организационные изменения, разработку обходного решения и пр запускает администратор системы. Как правило, ни полномочий, ни времени у администраторов систем на такие действия нет
Это условная схема. Очень много зависит от организационной структуры эксплуатации ИТ и от зрелости процесса управления проблемами. При нормальной организации работы, администратор просто классифицирует проблему и дальше автоматически запускаются механизмы эскалации вверх и вбок. Так же автоматически запускается цепочка организационных изменений. Это, конечно, требует определенных навыков менеджмента. Обходные решения часто инициируются после анализа логов и первичной диагностики. У меня на практике организовано так, что админов курирует менеджер проблем по направлению, и, по сигналу админа решает организационные моменты.
По ходу придется пилить пост про проблемы. Если в минусы не загонят:)
тут есть операционный директор, аналитик - логично им это передать. Или отдельную роль выделить - инцидент менеджер.
Да, много чего еще можно описать, к примеру "Управление измнениями".
Обычно аналитик не является субъектом управления. Операционный директор отвечает за эксплуатацию. Он заказчик решения проблемы. Управление решением проблем — это скорее первый заместитель/исполнительный директор. Он обеспечивает взаимодействие с вендорами, разработчиками, поставщиками, от которых зависит организационная и ресурсная составляющие решения проблем.
Но, безусловно, очень много зависит от оргструктуры эксплуатации ИТ.
Почему не является? Часто, аналитик 3-й линии отвечает за доработки/ взаимодействие с вендорами. В тч за эскалацию тикетов в их системы. Операционный директор скорее осуществляет надзор за процессом/ метриками, без детального погружения.
Всё. Понял: у нас разночтения определений. Ок. Эскалация инцидента или обращение к разработчику или мегаэксперту за помощью, прописывается в процессе управления инцидентами и контрактом с разработчиком/ поставщиком. Это алгоритмизируемая операция, которая на схеме не выделена и требует отдельного разговора. Может быть решена с помощью SLA/OLA, но здесь есть риск манипуляций. С моей точки зрения, лучше проактивно прорабатывать сценарии устранение инцидентов для особо критичных моментов эксплуатации. Хых. У меня в голове аналитик третьей линии поддержки — это эксперт, поэтому некоторая путаница. Аналитик же в моей парадигме — это мозг, оперирующий технологиями управления.
"Пусть целевое значение показателя MTTR—58 минут, а фактическое значение 65минут после пяти сбоев."
"достаточно быстренько перегрузить какой‑нибудь маловажный сервер. К примеру за 10 минут. После быстрого рестарта вы поправите себе показатель и получите премию вместо нагоняя. Проверим: (65+10)/6=12,5 минут. Вы‑действительно молодец!"
У меня арифметика не сходится. Либо 65 минут в среднем после 5 сбоев, тогда после перезагрузки сервера будет (65*5 + 10)/6=55,8. Да, молодец, но не 12,5.
Либо 65 минут за 5 сбоев, и тогда 65/5=13, и так молодец.
Столкнулся с ситуацией: телекоммуникационная компания решила послушать курс ВВедение в ITIL. Во время курса выяснилось, что бедную девочку послали не этот курс, чтобы она выстроила процесс управления инцидентами и внедрила KPI. Поэтому после курса Введение в ITIL была паника. Что делали: сели и описали процесс. Проблема 1: управление инцидентами не изолировано, а взаимодействует с другими процессами, например, управление запросами на обслуживание, управление проблемами. На первом этапе ограничились только инцидентами. Проблема 2: руководство хотело KPI. Я задал вопрос - а вы можете измерить ваш процесс с разбивкой по шагам. Ответ был - нет. Поэтому я и сказал: не можете измерять и не понимаете базовые метрики, значит KPI не может быть
Нюансы менеджмента процессов на примере процесса «Управление инцидентами ИТ»