Управление проблемами Archives – Страница 3 из 7

Зачем нужна категоризация?

Обсуждая тему эксплуатации услуг и сравнивая модели инцидентов и запросов на обслуживание, возник вопрос: а зачем нужна категоризация? И действительно, кому нужна эта информация? Как создать категоризатор и на что ориентироваться? Общий подход к категоризации используемый процессами в поддержке предоставляемых услуг может быть не только полезен с точки зрения осмысления и обработки данных, но и в повышении производительности службы поддержки. Категоризация является важным шагом многих процессов управления услугами. Категоризация инцидентов. Категоризация – это способ сортировки инцидентов по классам или категориям. В процессе управления инцидентами это дает нам возможность отслеживать аналогичные инциденты, связанные с продуктами и услугами, предоставляемыми бизнесу. В управлении…

Игорь Фадеев, 21 декабря 2019, последний комментарий 13 февраля 2023

Лучший способ предотвратить инциденты

Организации, которые тратят время и усилия на решение проблем, получают огромную отдачу от своих инвестиций. Хотя исправление инцидентами, когда они происходят, очень важно, гораздо лучше, чтобы они вообще не происходили; и если вы не можете их предотвратить, то по крайней мере убедитесь, что вы знаете, как минимизировать влияние будущих инцидентов. ITIL (ведущие в мире лучшие практики управления ИТ-услугами) говорит, что целью управления проблемами является «снижение вероятности и воздействия инцидентов путем выявления фактических и потенциальных причин инцидентов, а также управления обходными решениями и известными ошибками». Каковы фазы управления проблемами? Согласно ITIL 4 (последний выпуск ITIL, опубликованный в феврале 2019 года), управление…

Граница между постоянным совершенствованием и управлением проблемами

Вопрос о том, имеет ли смысл включать проактивное управление проблемами как отдельную процедуру в процесс управления проблемами (problem management, PRB), или это отдельный процесс, отличающийся по своей природе от реактивной составляющей управления проблемами обсуждался уже неоднократно. Также затрагивался и вопрос взаимоотношения процесса управления проблемами с практикой постоянного совершенствования (continual service improvement, CSI). Интересные заметки по данной теме (и ещё более интересные обсуждения в комментариях к ним) можно посмотреть, например, здесь и здесь, а также в комментариях к этой заметке В результате размышлений на эту тему, обсуждений на курсах и споров с коллегами у меня сформировалась картина, которой хочу поделиться. (Спойлер…

Игорь Гутник, 2 июля 2018, последний комментарий 12 июля 2018

Управление проблемами в COBIT 5

Цифровая трансформация проникает во все сферы бизнеса. Постоянные изменения в деловой среде несут компаниям не только новые бизнес-возможности, но и повышенные риски. Эффективное использование ИТ все чаще попадает в бизнес и ИТ-стратегии. Выстраивание качественной «жизни в ИТ» предполагает формализацию «правил игры» с заказчиками и умелое управление обращениями пользователей. Однако, проактивность по недопущению нарушений SLA и выявлению потенциальных угроз возникновения несоответствий в ИТ-инфраструктуре и приложениях редко налажена в компаниях на должном уровне. Процесс управления проблемами помогает организовать деятельность по «работе над ошибками». На страницах портала («Определяем сроки обработки проблем», «Измеряем Problem Management» и др.) и на вебинарах («Управление проблемами – где…

Сохранение контроля

Можно наглядно наблюдать, как компании сталкиваются со проблемой управления сложностью современных приложений. Создание ПО собственной разработки для внутренних нужд, для реализации ключевых бизнес-процессов компании, чаще всего основывается на принципе микросервисной архитектуры. Эта метаструктура приложения очень далека от представления последнего в виде некоторого монолитного объекта, обладающего определенными характеристиками. При использовании микросервисной архитектуры приложение конструируется в виде облака (хотел написать – массива, но слово “облако” гораздо лучше описывает картину) маленьких приложений, хорошо выполняющих только одну функцию. Отдельные экземпляры запущенных микросервисов абсолютно изолированы друг от друга, для их создания и/или удаления используются автоматические средства доставки, контейнеры. Каждый из таких сервисов имеет свои требования…

Problem Management: эскалация инцидента на вторую линию

В редакцию портала поступил вопрос: Коллеги, добрый день! Прочитал много материалов, касающихся Problem Management. Совсем не прочувствовал идею, что Управлению проблемами сложно внедрять и до него нужно "дорасти". Возьмем на примере. Звонит пользователь, и говорит, что не может на компьютер зайти — заблокирована учетная запись. Причем утверждает, что это происходит каждый день. Проверяю по тикетам — так и есть. Каждый день мой сотрудник первой линии успешно решает данный инцидент. То есть налицо наличие проблемы. Но Problem Management не выстроен. Я хочу, чтобы ITSM система мне позволила на основе данного инцидента создать проблему, которую перевести на вторую линию, к которой можно приклеить прошлые такие…

Вопрос из зала, 18 июля 2017, последний комментарий 2 августа 2017

Правильная последовательность внедрения ITSM-процессов

В редакцию портала поступил вопрос: Добрый день, коллеги! Наша компания находится на этапе внедрения процессов ITSM. В качестве первоочередных к внедрению процессов остановились на 6: управление обращениями, управление инцидентами, управление запросами на обслуживание, управление изменениями, управление конфигурациями, управление проблемами. Возник спор: в какой последовательности внедрять процессы. Я считаю, что правильнее было бы сперва смоделировать и описать регламенты всех шести процессов, а уже после этого формировать требования для разработчиков системы автоматизации, автоматизировать и обучать персонал новым правилам работы, т.к. часть изменений в системе автоматизации по одному процессу затронет и другие. Коллеги придерживаются мнения, что внедрять каждый из процессов нужно последовательно. Подскажите, есть…

Вопрос из зала, 4 июля 2017, последний комментарий 8 июля 2019

Правильные вопросы

Недавно, в очередной раз обсуждая техники анализа проблем, используемые в рамках процесса управления проблемами (Problem Management), спорили по поводу количества вопросов, которые нужно/можно задавать, реализуя методику «Пять «Почему?» («5-why»). Суть метода, напомню, заключается в том, что мы берём какое-то явление (проблему) и задаём себе вопрос: «Почему это происходит?». Найдя ответ на этот вопрос («Это происходит, потому что, происходит то»), мы задаём тот же самый вопрос «почему?» про «то» («А почему происходит то?»). И т.д. и т.п. Утверждается [ITIL SO, 4.4.4.3], что, следуя по этой цепочке, мы «обычно на пятой итерации добираемся до корневой причины». На самом деле то, как быстро…

Игорь Гутник, 25 декабря 2016, последний комментарий 27 декабря 2016

Всегда ли Known Error – ошибка?

Согласно ITIL® процесс «Управление проблемами» (Problem Management) направлен на минимизацию негативного влияния на бизнес инцидентов, вызванных ошибками в ИТ-инфраструктуре и предотвращение повторного возникновения таких инцидентов [SO, 4.4.1.1]. Часть работы процесса заключается в поиске корневой причины, вызывающей инцидент(ы) или, если не забывать и про проактивную составляющую процесса, корневой причины, которая может вызвать инцидент(ы) и устранению данной причины, либо, если это по какой-либо причине невозможно и/или не рационально, предложению обходного решения (workaround). При этом нужно понимать, что в общем случае ошибка – это не всегда ошибка в прямом смысле слова. Это может быть сложное сочетание конфигурационных единиц и условий их эксплуатации, которое…

Координатор проблем в слабой матрице

В процессе управления проблемами есть такая роль: координатор проблем. Как правило, эта роль предполагает ответственность за диагностику и решение проблем в какой-то предметной области, в том числе, с привлечением специалистов из смежных областей. И иногда я слышу от заказчиков вопрос: «А кто, собственно, должен быть координатором той или иной проблемы»? Например, время от времени начинает тормозить приложение. Вполне логично координатором данной проблемы становится один из ведущих специалистов app-саппорта. Далее, предположим, в результате диагностики он выясняет, что тормоза возникают на СХД. Почему? Причин может быть множество, способов решения еще больше. А наш координатор проблемы в СХД не специалист. Как быть? Кто…

Дмитрий Исайченко, 22 августа 2016, последний комментарий 29 августа 2016

Major incident – когда становится горячо…

На курсе ITIL Foundation слушатели часто задают вопрос о значительных инцидентах (major incident). Иногда потому, что тема управления ИТ-подразделением для них вообще новая и термин «значительный инцидент» слышится впервые, хотя в реальной жизни – это знакомая ситуация, иногда – потому что не совсем ясно, где провести границу между просто инцидентом и значительным инцидентом, и почти всегда – как с ним работать. О ключевых моментах, которые нужно учесть при работе со значительными инцидентами, пишет Neven Zitek в своей статье «Управление значительными инцидентами – когда становится горячо…» Что такое значительный инцидент? В теории значительный инцидент – это инцидент с самым высоким влиянием и…

Новостной поток, 18 июля 2016, последний комментарий 26 июля 2016

Портал №1 по управлению цифровымии информационными технологиями

Управление проблемами

Портал №1 по управлению цифровыми
и информационными технологиями