4.4.7. Мониторинг хода решения и отслеживание

В большинстве случаев ответственной за мониторинг хода решения является Служба Service Desk, как "владелец" всех инцидентов. Эта служба должна также информировать пользователя о состоянии инцидента. Обратная связь с пользователем может быть уместной после изменения статуса, например, направлении инцидента на следующую линию поддержки, изменении расчет­ного времени решения, эскалации и т. д. Во время мониторинга возможна функциональная эска­лация к другим группам поддержки или иерархическая эскалация для принятия руководящих решений.

4.5. Контроль процесса

Основой контроля процесса являются отчеты для различных целевых групп. Руководитель Процес­са Управления Инцидентами является ответственным за эти отчеты, а также за составление списка рассылки и графика составления отчетов. Отчеты могут включать специализированную информацию для следующих функциональных подразделений:

? Руководителю Процесса Управления Инцидентами отчет необходим для:

? идентификации недостающих звеньев процесса;

? идентификации нарушений исполнения соглашений об Уровне Услуг (SLA);

? отслеживания хода выполнения процесса;

? определения тенденций развития.

? Руководство Линейными ИТ-подразделениями – отчет для руководства группы поддержки; он также может быть полезен в Управлении ИТ-подразделениями. Отчет должен содержать следую­щую информацию:

? прогресс в решении инцидентов;

? время разрешения инцидентов в различных группах поддержки.

? Управления Уровнем Сервисов (Услуг) – отчет должен, прежде всего, содержать информацию о качестве предоставляемых услуг. Руководитель Процесса Управления Уровнем Услуг должен получать всю информацию, необходимую для составления Отчетов об Уровне Услуг перед заказчиками. Отчеты для заказчиков должны предоставлять информацию о том, выполняются ли соглаше­ния в отношении Уровня Сервисов (услуг) в рамках Процесса Управления Инцидентами.

? Руководителей других процессов ИТ Сервис-менеджмента – отчеты для руководителей других процессов должны быть, в первую очередь, информативными, то есть содержать всю необходимую им информацию. Например, Процесс Управления Инцидентами на основе регистрационных запи­сей об инцидентах может предоставлять следующую информацию:

? число обнаруженных и зарегистрированных инцидентов;

? число разрешенных инцидентов, с разделением по времени разрешения;

? статус и число неразрешенных инцидентов;

? инциденты с разбивкой по периодам возникновения, группам заказчика, группам поддержки и временем разрешения в соответствии с соглашением (SLA);

? инциденты с разбивкой по категориям, приоритетам и группам поддержки и др.

4.5.1. Критические факторы успеха

Для успешного Управления Инцидентами необходимо следующее:

? Актуальная Конфигурационная База Данных (CMDB), помогающая оценить степень воздействия и срочность инцидентов. Эта информация также может быть получена от пользователя, но в этом случае она, возможно, будет менее полной и достаточно субъективной, что приведет к увеличе­нию времени разрешения инцидентов.

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

? Соответствующую автоматизированную систему регистрации, отслеживания и мониторинга ин­цидентов.

Дополнительно необходимо тесное взаимодействие с Процессом Управления Уровнем Сервисов (Услуг) для определения требуемых приоритетов и времени разрешения инцидентов.

4.5.2. Показатели эффективности

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

? общее количество инцидентов;

? среднее время разрешения инцидентов;

? среднее время разрешения инцидентов по приоритетам;

? среднее число инцидентов, разрешенных в рамках соглашений (SLA);

? процент инцидентов, разрешенных первой линией поддержки (без направления в другие группы);

? средняя стоимость поддержки на инцидент;

? число решенных инцидентов на одно рабочее место или на одного сотрудника службы Service Desk;

? инциденты, решенные без посещения пользователя (удаленно);

? число (или процент) инцидентов с первоначально некорректной классификацией;

? число (или процент) инцидентов, неправильно распределенных в группы поддержки.

4.5.3. Функции и роли

Реализация процессов проходит в горизонтальной плоскости через иерархическую структуру орга­низации. Это возможно только при четком определении ответственности и полномочий, связанных с реализацией процессов. Для повышения гибкости может быть использован ролевой подход (т.е. определение ролей). В небольших организациях или в целях снижения общих расходов возможно комбинирование ролей, например, совмещение ролей Руководителя Процессов Управления Изме­нениями и Управления Конфигурациями.

Руководитель Процесса Управления Инцидентами

Во многих организациях роль Руководителя Управления Инцидентами играет менеджер Службы Service Desk. В сферу ответственности Руководителя Процесса Управления Инцидентами включа­ется следующее:

? мониторинг эффективности и рациональности работы процесса;

? контроль работы групп поддержки;

? составление рекомендаций по совершенствованию работы процесса;

? развитие и сопровождение системы Управления Инцидентами.

Персонал групп поддержки

? Первая линия поддержки несет ответственность за регистрацию, классификацию, сопоставление (привязку), распределение по группам поддержки, разрешение и закрытие инцидентов.

? Остальные группы поддержки, прежде всего, принимают участие в расследовании, диагностике и разрешении инцидентов в рамках установленных приоритетов.

4.6. Затраты и проблемы

4.6.1. Затраты

Затраты, связанные с Управлением Инцидентами, включают первоначальные затраты на внедрение (например, расходы на разработку процесса, обучение и инструктаж персонала), выбор и закупку инструментальных средств поддержки процесса. Выбор инструментальных средств может занять значительное количество времени. Кроме того, существуют операционные расходы, связанные с оп­латой работы персонала и использованием инструментальных средств. Эти затраты во многом зави­сят от структуры Управления Инцидентами, диапазона видов деятельности, включенных в процесс, сфер ответственности и числа подразделений.

4.6.2. Проблемы

При внедрении Управления Инцидентами могут возникнуть следующие проблемы:

? Пользователи и ИТ-специалисты работают в обход процедур Управления Инцидентами – если пользователи будут устранять возникающие ошибки сами или напрямую связываться со специа­листами, не следуя установленным процедурам, ИТ-организация не получит информацию о реально предоставляемом Уровне Услуг, числе ошибок и многое другое. Отчеты руководству также не будут адекватно отражать ситуацию.

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

? Эскалация – как известно, в рамках Процесса Управления Инцидентами возможна эскалация ин­цидентов. Слишком большое число эскалаций может оказать отрицательное воздействие на рабо­ту специалистов, которые из-за этого отрываются от своей запланированной работы.

? Отсутствие Каталога Услуг и Соглашений об Уровне Сервисов (SLA) – если поддерживаемые услуги и продукты недостаточно точно определены, тогда специалистам, вовлеченным в Управле­ние Инцидентами, бывает трудно обоснованно отказать пользователям в помощи.

? Недостаточная приверженность процессному подходу со стороны руководства и персонала – решение инцидентов с помощью процессного подхода обычно требует изменения культуры и более высокого уровня ответственности за свою работу со стороны персонала. Это может вы­звать серьезное сопротивление внутри организации. Эффективное Управление Инцидентами требует от сотрудников понимания и реальной приверженности процессному подходу, а не просто участия.

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

5.1. Введение

Как было сказано в предыдущей главе, Процесс Управления Инцидентами начинает действовать с появлением инцидента и прекращает свою работу после исправления ситуации. Это означает, что корневая причина возникновения инцидента не всегда бывает установлена и инцидент может повто­риться снова.

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

5.1.1. Определение – "проблема" и "известная ошибка"

На рис 5.1 показаны взаимосвязи между проблемой, известной ошибкой и Запросом на Изменение и даны определения этих терминов.

Рис. 5.1. Отношения между проблемами и известными ошибками (источник OGC)

5.1.2. Взаимоотношения с Процессом Управления Инцидентами

Процесс Управления Проблемами поддерживает Процесс Управления Инцидентами, предоставляя ему обходные решения и быстрые исправления , но при этом не неся прямой ответственности за раз­решение инцидента. Управление Инцидентами помогает быстро исправить ошибку любыми доступ­ными средствами, включая обходные решения, в то время как Управление Проблемами занимается поиском причины произошедшего и ее устранением. Инцидент может никогда "не стать" проблемой. Однако кроме самого инцидента, может быть определена связанная с ним проблема. Поэтому работа над проблемой может помочь в разрешении текущего инцидента, если он еще открыт.

На рис. 5.2 показаны отношения между инцидентами, проблемами, известными ошибками и изме­нениями.

Рис. 5.2. Отношения между Процессами Управления Инцидентами, Управления Проблемами и Управления Изменениями

5.2. Цель процесса

Целью Процесса Управления Проблемами является установление корневой причины возникнове­ния проблемы и, как следствие, предотвращение инцидентов. Управление Проблемами включает в себя проактивные (упреждающие) и реактивные виды деятельности. Задачей реактивных составля­ющих Процесса Управления Проблемами является выяснение корневой причины прошлых инцидентов и подготовка предложения по ее ликвидации. Проактивные Управление Проблемами помога­ет предотвратить инциденты путем определения слабых мест в инфраструктуре и подготовки пред­ложений по ее усовершенствованию.

Управление Проблемами гарантирует, что:

? существующие и регулярно возникающие ошибки идентифицированы, документированы и отслеживаются;

? симптомы ошибок, постоянные или временные решения документируются;

? подаются Запросы на Изменения с целью модификации инфраструктуры;

? предотвращается возникновение новых инцидентов;

? создаются отчеты о качестве инфраструктуры ИТ и самого процесса.

Управление Проблемами позволяет быстро улучшить качество услуг путем значительного сокраще­ния количества инцидентов и уменьшения рабочей нагрузки на ИТ-организацию. Некоторые из преимуществ данного процесса состоят в следующем:

? Улучшение качества ИТ-услуг и Управления – результат документирования ошибок и/или их устранения.

? Повышение производительности труда пользователей – за счет улучшения качества услуг.

? Повышение производительности труда персонала – наличие документированных решений проб­лем позволяет даже менее опытным участникам Процесса Управления Инцидентами разрешать инциденты быстрее и эффективнее.

? Улучшение репутации ИТ-услуг – в результате улучшения стабильности услуг заказчики с боль­шим желанием сотрудничают с ИТ-организацией в новых сферах бизнеса.

? Совершенствование знаний в области Управления, эффективное обучение – Процесс Управле­ния Проблемами позволяет хранить исторические данные , которые используются при определе­нии тенденций и помогают принять меры по предотвращению новых инцидентов. Исторические данные также можно использовать при проведении исследований и диагностирования, а также, при создании Запросов на Изменения.

? Улучшение регистрации инцидентов – Управление Проблемами вводит стандарты на регистра­цию и классификацию инцидентов с целью эффективного определения проблем и их симптомов. Это также помогает улучшить составление отчетов об инцидентах.

? Более высокая доля инцидентов, разрешенных на первой линии поддержки – поскольку Про­цесс Управления Проблемами разрабатывает решения для ликвидации инцидентов и проблем, а обходные решения можно найти в базе знаний, то первая линия поддержки с большим успехом сама разрешает инциденты.

5.3. Процесс

Входами для Процесса Управления Проблемами являются:

? детальные описания инцидентов;

? обходные решения, найденные Процессом Управления Инцидентами;

? детали конфигурации из Конфигурационной Базы Данных (CMDB);

? подробная информация от производителя используемых в инфраструктуре продуктах, включая известные ошибки в этих продуктах и технические детали;

? подробная информация об инфраструктуре и ее поведении, такая как записи о имеющихся мощ­ностях, замеры производительности, отчеты о соблюдении Уровней Услуг и так далее.

Основными видами деятельности в рамках Процесса Управления Проблемами являются:

? контроль проблем: определение и исследование проблем;

? контроль ошибок: отслеживание известных ошибок и подача Запросов на Изменения (RFC);

? проактивное Управление Проблемами: предотвращение инцидентов путем совершенствования инфраструктуры;

? предоставление информации: отчеты по серьезным проблемам и достигнутым результатам.

Выходами процесса являются:

? известные ошибки;

? Запросы на Изменения (RFC);

? новые регистрационные данные о проблемах (обновленные с учетом информации о способах ре­шения и/или обходных решениях);

? закрытые после устранения причины проблемы регистрационные записи;

? информация для руководства.

Рис. 5.3. Управление Проблемами среди других процессов

5.3.1. Управление Инцидентами

Управление Инцидентами является важным партнером Процесса Управления Проблемами. Эффек­тивная регистрация инцидентов важна для успешного Управления Проблемами, так как эта инфор­мация используется при идентификации проблемы.

Управление Проблемами поддерживает Процесс Управление Инцидентами. Процесс Управления Проблемами изучает проблемы и, пока не будет найдено решение, Управлению Инцидентами пред­лагаются обходные решения для работы над инцидентом. После установления причины и определе­ния Известной ошибки, может быть предложено быстрое решение ("заплатка") , которое поможет предотвратить возникновение инцидентов на некоторое время или уменьшит их негативные послед­ствия. Управление Проблемами может подать Запрос на Изменение, который приведет к оконча­тельному решению.

Примечание. Обходные решения могут создаваться и в Процессе Управления Инцидентами, и в Про­цессе Управления Проблемами.

5.3.2. Управление Изменениями

Управление Изменениями отвечает за контролируемое проведение изменений, включая Запросы на Изменения для устранения проблем, предложенные Процессом Управления Проблемами. Управле­ние Изменениями несет ответственность за определение степени воздействия изменения и ресурсов, необходимых для его реализации, а также за планирование, согласование и оценку запрашиваемых изменений. Кроме того, Управление Изменениями информирует Процесс Управления Проблемами о ходе работ и о завершении корректирующих изменений. Оценка этим изменениям дается совмест­но с Процессом Управления Проблемами. Итогом работы является Анализ результатов внедрения , после которого в рамках подпроцесса Контроля ошибок может быть закрыта известная ошибка, а также относящиеся к ней (открытые) инциденты.

5.3.3 Управление Конфигурациями

Процесс Управления Конфигурациями предоставляет важную информацию об элементах инфра­структуры, документации, конфигурации программного и аппаратного обеспечения, ИТ-сервисах и других отношениях типа "связан с", "использует" и "является частью". Эти отношения являются исключительно важными для решения проблем.

5.3.4. Управление Доступностью

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

5.3.5. Управление Мощностями

Управление Мощностями позволяет оптимизировать использование ИТ-ресурсов. Данный процесс предоставляет Управлению Проблемами важную информацию, которую можно использовать для определения проблем. Управление Проблемами оказывает поддержку Управлению Мощностями, устанавливая причины соответствующих проблем и устраняет их.

5.3.6. Управление Уровнем Услуг

Управление Уровнем Услуг включает в себя работы по согласованию и заключению Соглашений о Качестве ИТ-услуг. Управление Уровнем Услуг передает в Процесс Управления Проблемами ин­формацию, которая используется при определении проблем. Процедуры Процесса Управления Про­блемами должны поддерживать предоставление услуг в соответствии с согласованными стандарта­ми качества. Эту же роль Управление Проблемами играет в Процессах Управления ИТ-финансами и Управления Непрерывностью ИТ-услуг.

5.4. Виды деятельности

5.4.1. Контроль проблем

Целью этого вида деятельности является выявление проблем и изучение их причин. Контроль проб­лем должен преобразовать проблему в известную ошибку путем диагностирования неизвестной при­чины ее возникновения. На рис. 5.4 показаны действия, выполняемые в рамках контроля проблемы.

Рис. 5.4. Контроль проблем (источник: OGC)

Идентификация и регистрация проблемы

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

Деятельность по "идентификации проблем" часто выполняют Координаторы проблем. Однако бы­вает так, что персонал, изначально не вовлеченный в эту работу, например, специалисты по Управле­нию Мощностями, тоже может выявлять проблемы. Такие "находки" также следует регистрировать как проблемы.

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

? Анализ инцидентов показывает, что некоторый инцидент повторяется, возникает большое количе­ство инцидентов или возникает негативная тенденция.

? Анализ инфраструктуры позволил определить ее слабые места, где могут произойти новые инци­денты (возможно, это проводилось средствами Процессов Управления Доступностью и Управле­ния Мощностями).

? Произошел серьезный инцидент, требующий структурного решения для предотвращения его по­вторения в будущем.

? Существует угроза срыва Уровня Услуг, согласованного с заказчиком (по показателям производи­тельности, мощности ИТ-средств, затрат и т. д.)

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

? Нельзя установить связь между зарегистрированными инцидентами и любой из известных проб­лем или ошибок.

Анализ тенденций позволяет обнаружить области, которым требуется особое внимание. Необходи­мые для этого дополнительные ресурсы нужно обосновать с позиции издержек и выгод для органи­зации. Например, определить области, которым требуется более действенная поддержка, и понять, насколько они важны для предоставляемых услуг.

Такая оценка может базироваться на "болевом показателе" инцидентов, в котором учитываются:

? издержки, которые несет бизнес из-за инцидентов;

? количество инцидентов;

? количество пользователей и бизнес-процессов, затронутых инцидентами;

? время и затраты на разрешение инцидентов.

Классификация и назначение

Проблемы можно классифицировать по областям (категориям). Классификация проблемы выпол­няется одновременного с анализом степени ее воздействия, т. е. уровня серьезности проблемы и ее влияния на услуги (срочность и степень воздействия). Вслед за этим проблеме присваивается при­оритет, точно так же, как в Процессе Управления Инцидентами. Затем на основе результатов класси­фикации за проблемой закрепляются ресурсы и персонал и определяется время, необходимое для ее решения.

Классификация проблемы включает в себя следующее:

? Категория: определение области, например, программное или аппаратное обеспечение;

? Степень воздействия на бизнес-процесс;

? Срочность: допустимая задержка в решении проблемы;

? Приоритет: показатель, объединяющий срочность, степень воздействия, риск и необходимые ре­сурсы;

? Статус: например, проблема, известная ошибка и т. д.

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

Расследование и диагностика

Расследование и диагностика являются итеративными фазами процесса, они неоднократно повторя­ются, каждый раз приближаясь все ближе к намеченному результату. Часто делаются попытки вос­произвести инцидент в условиях тестирования. Для решения проблемы могут потребоваться допол­нительные знания, например, для анализа и диагностики проблемы можно привлечь специалистов из группы поддержки.

Проблемы возникают не только из-за программных или технических средств. Они могут быть вы­званы ошибками в документации, ошибками персонала или процедурными ошибками, такими как выпуск неправильной версии программного обеспечения. Поэтому желательно включать описания процедур в Конфигурационную Базу Данных и проводить контроль их версий. В то же время мно­гие ошибки связаны с компонентами ИТ-инфраструктуры.

После того как установлена причина проблемы, определены Конфигурационные Единицы или груп­пы единиц, ее вызвавшие, установлена связь между Конфигурационной Единицей и инцидентом (инцидентами), становиться возможным определить Известную ошибку. После этого Управление Проблемами продолжит свою работу, выполняя функции контроля ошибок.

Источники ошибок в других средах

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

Если известные ошибки в продукте не представляют серьезной опасности или если бизнес настаива­ет на запуске релиза, несмотря на имеющиеся недостатки, то может быть принято решение об ис­пользовании разработанного продукта в производственной среде, но при этом необходимо, чтобы известные ошибки были учтены в рамках деятельности по Контролю ошибок. В этом случае следует организовать взаимодействие с Процессом Управления Инцидентами, чтобы быстро распознавать инциденты, произошедшие в результате внедрения таких продуктов. В случаях необходимости так­же могут быть предоставлены обходные решения или быстрые исправления. Перед началом внедре­ния продукта Процессу Управления Изменениями следует принять решение о приемлемости имею­щихся известных ошибок. Часто такое решение принимается под давлением, так как пользователи ждут появления новой функциональности.

5.4.2. Контроль ошибок

Деятельность по Контролю ошибок заключается в ведении мониторинга и исправлении известных ошибок до момента их полного устранения (в тех случаях, когда это возможно и целесообразно). Эта задача решается путем подачи Запроса на Изменение (RFC) в Процесс Управления Изменениями и оценки внесенных изменений с помощью Анализа результатов внедрения (PIR). В рамках контроля ошибок осуществляется деятельность по мониторингу всех известных ошибок с момента их идентификации и до устранения. К работе по Контролю ошибок привлекаются многие подразделения, как операционной среды, так и из среды разработок.

Рис. 5.5. Контроль ошибок (источник: OGC)

Идентификация и регистрация ошибок

После определения причины проблемы и связанной с ней Конфигурационной Единицы, проблеме присваивается статус "Известной ошибки" и начинается деятельность по Контролю ошибок. Во многих случаях уже имеется обходное решение для проблемы, даже если ошибка найдена самими разработчиками. Но в некоторых случаях обходное решение нужно найти, а затем передать его в Процесс Управления Инцидентами, если там еще имеются открытые инциденты. Это обходное ре­шение также можно использовать во время сопоставления инцидентов .

Поиск решения

Персонал, участвующий в Управлении Проблемами, определяет, что необходимо сделать для разре­шения известной ошибки. Специалисты сравнивают различные решения, принимая во внимание Со­глашения об Уровне Услуг (SLA), возможные издержки и выгоды. Они определяют степень влияния и срочность Запросов на Изменения. Все работы по выработке решения должны быть зафиксирова­ны в системе, у персонала должны быть средства для мониторинга проблем и определения их статуса.

Срочное исправление

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

Определение окончательного решения

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

Например, компания, у которой есть проблемы с собственными разработками системы ERP, приос­танавливает любые исправления кодов существующей системы, так как принято стратегическое ре­шение о переходе на SAP к концу года. В этом и других аналогичных случаях полученные преимущества не перевешивают затраты на исправления. Или же в другом случае степень воздействия ошибки может оказаться приемлемой, инцидент может оказаться легким для исправления или же вероятность его повторения невысока. В некоторых случаях исправление известной ошибки вообще невозможно без приложения усилий, несоразмерных проблеме. Но какое бы решение не было принято, оно должно быть отражено в системе, чтобы его можно было использовать в Процессе Управ­ления Инцидентами.