- •Оглавление
- •Управление Инцидентами
- •4.1. Введение
- •4.1.1. Терминология
- •4.2. Цель
- •4.2.1. Преимущества использования процесса
- •4.3. Процесс
- •4.4.1. Прием и регистрация
- •4.4.2. Классификация
- •4.4.7. Мониторинг хода решения и отслеживание
- •4.5. Контроль процесса
- •4.5.1. Критические факторы успеха
- •Управление Проблемами
- •5.1. Введение
- •5.1.1. Определение — «проблема» и «известная ошибка»
- •5.1.2. Взаимоотношения с Процессом Управления Инцидентами
- •5.2. Цель процесса
- •5.3. Процесс
- •5.3.3 Управление Конфигурациями
- •5.4.2. Контроль ошибок
- •5.4.3. Проактивное Управление Проблемами
- •5.5.3. Функции и роли
- •5.6. Затраты и проблемы
- •5.6.2. Проблемы
- •Управление Конфигурациями
- •6.1.1. Основные понятия
- •6.2. Цель процесса
- •6.2.1. Преимущества использования процесса
- •6.3. Процесс
- •6.4. Виды деятельности
- •6.4.3. Мониторинг статуса
- •6.4.4. Контроль
- •6.4.5. Верификация и аудит
- •6.5. Контроль процесса
- •6.6. Затраты и проблемы
- •Управление Изменениями
- •7.1. Введение
- •7.3.1. Управление Инцидентами
- •7.3.1. Управление Инцидентами
- •7.4. Виды деятельности
- •7.4.1. Регистрация
- •7.4.4. Планирование
- •7.4.5. Координация
- •7.5 Контроль процесса
- •7.5.1 Отчеты для руководства
- •Управление Релизами
- •8.1.1. Основные понятия
- •8.2. Цель процесса
- •8.2.1. Преимущества использования процесса
- •8.3. Процесс
- •8.3.4. Виды деятельности
- •8.4. Виды деятельности
- •8.5.2. Проблемы
- •Служба Service Desk
- •9.1. Введение
- •9.3.3. Варианты организации Службы Service Desk
- •9.3.4. Персонал Службы Service Desk
- •9.3.5. Технологии для работы Службы Service Desk
- •9.5. Эффективность
- •Управление Уровнем Сервиса (Услуг)
- •10.1. Введение
- •10.1.1. Основные понятия
- •Управление финансами ит
- •Управление Мощностями
- •Управление Непрерывностью ит-сервисов
- •Управление Доступностью
5.4.2. Контроль ошибок
Деятельность по Контролю ошибок заключается в ведении мониторинга и исправлении известных ошибок до момента их полного устранения (в тех случаях, когда это возможно и целесообразно). Эта задача решается путем подачи Запроса на Изменение (RFC) в Процесс Управления Изменения-
Идентификация и регистрация проблемы
В принципе, любой инцидент, возникший по неизвестной причине, может быть связан с проблемой. Па практике это имеет смысл делать только тогда, когда инцидент повторяется, возможно его повторение или если это единичный, но серьезный инцидент.
Деятельность по «идентификации проблем» часто выполняют Координаторы проблем. Однако бывает так, что персонал, изначально не вовлеченный в эту работу, например, специалисты но Управлению Мощностями, тоже может выявлять проблемы. Такие «находки» также следует регистрировать как проблем ы.
Регистрационные детали проблем схожи с деталями инцидентов, но в случае проблемы не нужно включать в описание информацию о пользователе и т. д. Однако инциденты, связанные с конкретной проблемой, следует идентифицировать и соответствующим образом регистрировать. . Ниже даются примеры случаев, когда могут быть идентифицированы проблемы:
Анализ инцидентов показывает, что некоторый инцидент повторяется, возникает большое количество инцидентов или возникает негативная тенденция.
Анализ инфраструктуры позволил определить ее слабые места, где могут произойти иовые-инци- денты (возможно, это проводилось средствами Процессов Управления Доступностью и Управления Мощностями).
Произошел серьезный инцидент, требующий структурного решения для предотвращения его повторения в будущем.
Существует угроза срыва Уровня Услуг, согласованного с заказчиком (по показателям производительности, мощности ИТ-средств, затрат и т. д.)
Нельзя установить связь между новыми инцидентами и уже известной проблемой или ошибкой.
Нельзя установить связь между зарегистрированными инцидентами и любой из известных проблем или ошибок.
Анализ тенденций позволяет обнаружить области, которым требуется особое внимание. Необходимые для этого дополнительные ресурсы нужно обосновать с позиции издержек и выгод для организации. Например, определить области, которым требуется более действенная поддержка, и понять, насколько они важны для предоставляемых услуг.
Такая оценка может базироваться на «болевом показателе» инцидентов, в котором учитываются:
издержки, которые несет бизнес из-за инцидентов;
количество инцидентов;
количество пользователей и бизнес-процессов, затронутых инцидентами;
время и затраты на разрешение инцидентов.
Классификация и назначение
Проблемы можно классифицировать по областям (категориям). Классификация проблемы выполняется одновременного с анализом степени се воздействия, т. е. уровня серьезности проблемы и ее влияния на услуги (срочность и степень воздействия). Вслед за этим проблеме присваивается приоритет, точно так же, как в Процессе Управления Инцидентами. Затем на основе результатов классификации за проблемой закрепляются ресурсы и персонал и определяется время, необходимое для ее решения.
Классификация проблемы включает в себя следующее:
Категория: определение области, например, программное или аппаратное обеспечение;
Степень воздействия на бизнес-процесс;
Срочность: допустимая задержка в решении проблемы;ми и оценки внесенных изменений с помощью Анализа результатов внедрения (PIR). В рамках Контроля ошибок осуществляется деятельность по мониторингу всех известных ошибок с момента их идентификации и до устранения. К Идентификация и регистрация ошибок
После определения причины проблемы и связанной с ней Конфигурационной Единицы, проблеме присваивается статус «Известной ошибки» и начинается деятельность по Контролю ошибок. Во многих случаях уже имеется обходное решение для проблемы, даже если ошибка найдена самими разработчиками. Но в некоторых случаях обходное решение нужно найти, а затем передать его в Процесс Управления Инцидентами, если там еще имеются открытые инциденты. Это обходное решение также можно использовать во время сопоставления инцидентов.
Поиск решения
Персонал, участвующий в Управлении Проблемами, определяет, что необходимо сделать для разрешения известной ошибки. Специалисты сравнивают различные решения, принимая во внимание Соглашения об Уровне Услуг (SLA), возможные издержки и выгоды. Они определяют степень влияния и срочность Запросов на Изменения. Все работы по выработке решения должны быть зафиксированы в системе, у персонала должны быть средства для мониторинга проблем и определения их статуса.
Например, компания, у которой есть проблемы с собственными разработками системы KRP, приос- танавливаег любые исправления колов существующей системы, так как принято стратегическое решение о переходе на SAP к концу года. В этом и других аналогичных случаях полученные преимущества не перевешивают затраты на исправления. Или же в другом случае степень воздействия ошибки может оказаться приемлемой, инцидент может оказаться легким для исправления или же вероятность его повторения невысока. В некоторых случаях исправление известной ошибки вообще невозможно без приложения усилий, несоразмерных проблеме. Но какое бы решение не было принято, оно должно быть отражено в системе, чтобы его можно было использовать в Процессе Управления Инцидентами.
После окончания этапа выбора существует достаточно информации для подачи Запроса на Изменение. Далее исправление известной ошибки будет произведено в рамках Процесса Управления Изменениями.
Анализ результатов внедрения (PIR)
Изменение, предназначенное для устранения известной ошибки, должно быть рассмотрено при анализе результатов внедрения до закрытия проблемы. Если изменение дало ожидаемый результат, проблема может быть закрыта, и в базе данных о проблемах ее статус будет изменен на статус «решена». Управление Инцидентами будет проинформировано об этом и инциденты, связанные с этой проблемой, тоже могут быть закрыты.
Примечание: Во многих организациях процесс реализован таким образом, что проблема закрывается только после того, как будут закрыты связанные с ней инциденты (и закрытие проверено заказчиком), иначе если инциденты не удается закрыть, то проблему будет необходимо открывать снова.
Отслеживание и мониторинг
Данная задача предполагает выполнение мониторинга хода работ но разрешению проблем и известных ошибок на всех этапах Контроля проблем и Контроля ошибок. Цели состоят в следующем:
Определить, изменилась ли степень влияния или срочность проблемы, и на основании этого производить корректировку приоритета проблемы.
Вести мониторинг процесса выработки и реализации решения и контролировать правильность исполнения Запроса на Изменение. По этой причине Управление Изменениями регулярно передает информацию о состоянии Запросов на Изменение в Контроль ошибок.
Предоставление информации
В течение всего процесса информация об обходных решениях и быстрых исправлениях передается в Управление Инцидентами. Пользователи также могут информироваться об этом. Хотя данные предоставляет Процесс Управления Проблемами, их распространением занимается Служба Service Desk. Управление Проблемами использует Конфигурационную Базу Данных, а также Соглашения об Уровне Услуг, для уточнения, какую информацию и кому следует предоставлять.