Управление бизнесом |
---|
Управление из бизнеса |
|
Управление проблемами - это процесс, отвечающий за управление жизненным циклом всех проблем, которые происходят или могут произойти в ИТ-службе. Основными задачами управления проблемами являются предотвращение возникновения проблем и связанных с ними инцидентов, устранение повторяющихся инцидентов и минимизация воздействия инцидентов, которые невозможно предотвратить. ITIL определяет проблему как причину одного или нескольких инцидентов .
Сфера [ править ]
Управление проблемами включает в себя действия, необходимые для диагностики основной причины инцидентов, выявленных в процессе управления инцидентами , и определения решения этих проблем. Он также несет ответственность за обеспечение того , чтобы разрешение осуществляется через соответствующие процедуры контроля, в частности управления изменениями и управления релизами .
Управление проблемами также будет хранить информацию о проблемах и соответствующих обходных путях и решениях, чтобы организация могла со временем уменьшить количество и влияние инцидентов. В этом отношении Управление проблемами имеет надежный интерфейс с Управлением знаниями , и такие инструменты, как База данных известных ошибок, будут использоваться для обоих. Хотя управление инцидентами и управление проблемами являются отдельными процессами, они тесно связаны и, как правило, используют одни и те же инструменты, а также могут использовать аналогичные системы категоризации, воздействия и кодирования приоритета. Это обеспечит эффективное общение при решении связанных инцидентов и проблем.
Ценность для бизнеса [ править ]
Управление проблемами работает вместе с Управлением инцидентами и Управлением изменениями, чтобы обеспечить повышение доступности и качества ИТ-услуг. Когда инциденты разрешены, информация о разрешении записывается. Со временем эта информация используется для ускорения времени разрешения и определения постоянных решений, сокращая количество и время разрешения инцидентов. Это приводит к сокращению времени простоя и прерывания работы критически важных для бизнеса систем.
Действия, методы и приемы процесса [ править ]
Управление проблемами состоит из двух основных процессов:
- Реактивное управление проблемами, которое обычно выполняется как часть работы службы.
- Упреждающее управление проблемами, которое инициируется в процессе работы службы , но обычно осуществляется как часть постоянного улучшения обслуживания (CSI) .
Обнаружение проблемы [ править ]
- Подозрение или обнаружение причины одного или нескольких инцидентов Службой поддержки , в результате чего создается запись о проблеме - Служба поддержки могла разрешить инцидент, но не определила окончательную причину и подозревает, что она может повториться.
- Анализ инцидента группой технической поддержки, который показывает, что основная проблема существует или может существовать.
- Автоматическое обнаружение сбоя инфраструктуры или приложения с автоматическим использованием инструментов событий / предупреждений для инициирования инцидента, который может выявить необходимость в записи о проблеме .
- Уведомление поставщика или подрядчика о том, что существует проблема, которую необходимо решить.
- Анализ инцидентов как часть упреждающего управления проблемами: смотри бюллетени, релизы, актуальные статьи
Регистрация проблем [ править ]
Все соответствующие детали проблемы должны быть записаны, чтобы существовала полная историческая запись. Это должно быть отмечено датой и временем, чтобы обеспечить надлежащий контроль и эскалацию. Необходимо сделать перекрестную ссылку на инцидент (ы), инициировавший «Запись о проблеме»:
- Детали услуги
- Детали оборудования
- Дата и время первоначальной регистрации
- Детали приоритета и категоризации
- Описание инцидента
- Подробная информация обо всех предпринятых действиях по диагностике или попытках восстановления.
Приоритизация проблем [ править ]
Проблемы могут быть классифицированы в соответствии с их серьезностью и приоритетностью так же, как и инциденты, чтобы облегчить их отслеживание, принимая во внимание влияние связанных инцидентов и их частоту возникновения. С точки зрения инфраструктуры можно спросить:
- Можно ли восстановить систему или ее нужно заменить?
- Сколько это будет стоить?
- Сколько людей потребуется для устранения проблемы?
- Сколько времени потребуется, чтобы устранить проблему?
- Сколько дополнительных ресурсов будет задействовано?
- Что такое влияние не решение проблемы?
Исследование и диагностика проблемы [ править ]
Результатом расследования проблемы будет диагностика основной причины или отчет о RCA. Решение должно быть суммой соответствующего уровня ресурсов и навыков, используемых для его поиска. Существует ряд полезных методов решения проблем, которые можно использовать для диагностики и решения проблем.
- Систему управления конфигурацией (CMS) необходимо использовать для определения уровня воздействия и определения точки отказа.
- База известных ошибок или KEDB должны быть доступны и проверены для того , чтобы выяснить , если проблема возникла в прошлом, если это разрешение должно быть уже на месте.
- В ходе хронологического анализа события, вызвавшие проблему, будут проверяться в хронологическом порядке, чтобы иметь временную шкалу событий. Цель состоит в том, чтобы увидеть, какое событие запускает следующее событие и так далее, или исключить некоторые возможные события.
Value Analysis Pain содержит более полное представление о влиянии инцидента или проблемах в бизнесе. Вместо анализа количества инцидентов / проблем определенного типа в конкретном временном интервале метод фокусируется на глубоком анализе того, какой уровень боли был причинен бизнесу этими инцидентами / проблемами. Формула для расчета уровня боли должна учитывать:
- количество пострадавших
- продолжительность простоя, вызванного
- стоимость для бизнеса
Метод Кепнера и Трегое используется для исследования более глубоких проблем. Они определили следующие этапы:
- определение проблемы
- описание проблемы с точки зрения личности, местоположения, времени (продолжительности) и размера (воздействия)
- установление возможных причин
- проверка наиболее вероятной причины
- проверка истинной причины
Анализ Парето или диаграмма Парето - это метод отделения важных потенциальных причин от тривиальных проблем. Необходимо предпринять следующие шаги:
- Сформируйте таблицу, в которой перечислены причины и их частота в процентах.
- Расположите строки в порядке убывания важности причин (сначала самая важная причина).
- Добавьте в таблицу столбец с накопительным процентом
- Создайте гистограмму с причинами в порядке их процента от общего числа.
- Нарисуйте линию на 80% по оси Y, затем опустите линию в точке пересечения с осью X. На диаграмме вы можете увидеть основные причины сбоев в сети. Они должны быть нацелены в первую очередь.
Причины | Процент от общего | Расчет% |
---|---|---|
Сетевой контроллер | 35 год | 0 + 35% = 35% |
Повреждение файла | 26 год | 35% + 26% = 61% |
ОС сервера | 6 | 61% + 6% = 67% |
Запись об известной ошибке [ править ]
После завершения расследования и поиска обходного пути (или даже постоянного решения) необходимо создать запись об известной ошибке и поместить ее в базу данных известных ошибок, чтобы выявить и устранить подобные проблемы в дальнейшем. Основная цель - как можно скорее восстановить поврежденный сервис с минимальным влиянием на бизнес.
Хорошей практикой было бы поднять запись об известных ошибках как можно раньше в ходе расследования; после успешного тестирования обходного пути или определения основной причины.
Обзор основных проблем [ править ]
Хорошая практика - проверять все основные проблемы. Но это требует затрат. Обзор должен исследовать:
- Сделанные правильные шаги
- Проблемы, возникшие при внедрении решения
- Необходимость улучшения
- Предотвратить повторение подобных инцидентов в будущем.
- Сторонняя сторона / поставщик / поставщик, участвующий в реализации
Знания, полученные в результате проверки, должны быть включены в анализ обслуживания с бизнес-заказчиком, чтобы гарантировать, что заказчик осведомлен о предпринятых действиях и планах по предотвращению возникновения подобных инцидентов в будущем. Это помогает повысить уровень удовлетворенности клиентов и гарантировать бизнесу, что отдел обслуживания ответственно подходит к серьезным инцидентам и активно работает над предотвращением их повторения в будущем.
См. Также [ править ]
- ISO / IEC 15504
- Гарантия качества
- Диагностика проблем RPR
- Серая проблема
- Парето анализ
Ссылки [ править ]
- Новый Rational Manager - описывает решение проблем и принятие решений KT (PSDM)
- Оффорд, Пол (2011). RPR: метод диагностики проблем для ИТ-специалистов . Эссекс, Англия: Advance Seven Limited. ISBN 978-1-4478-4443-3.