Обнаружение, самообслуживание и регистрация

На приведенном ниже рисунке показана блок-схема для обнаружения, самообслуживания и регистрации.

Подписи к рисунку: Detection, Self-Service and Recording - Обнаружение, самообслуживание и регистрация Alerts from event management systems - Предупреждения от систем управления событиями Walk-ins - Личные обращения Voice or video requests - Голосовые или видео запросы Faxes - Запросы по факсу Telephone requests - Запросы по телефону E-mail - Запросы по электронной почте Internet / Browser requests - Запросы по интернету / через браузер Self-Service - Самообслуживание Telephone - Телефон Contact method - Метод контакта Other - Другое Which service required? - Какой сервис требуется? Check progress - Проверка прогресса Alerts automatically generate incident records - Предупреждения автоматически генерируют регистрационные записи инцидента E-mail or Browser - Электронная почта или браузер Use self-help - Применение справки для самостоятельного использования Access self-help information - Доступ к справочной информации Access self-tracking facility - Доступ к средству самостоятельного отслеживания Initial support records basic details and acknowledges receipt - Группа начальной поддержки регистрирует основные детали и подтверждает получение Customer records basic details and gets acknowledgement - Клиент регистрирует основные детали и получает подтверждение Return to previous menu? - Возврат в предыдущее меню? End - Конец Further details or clarification required? - Требуются дополнительные детали или разъяснение? No - Нет Yes - Да Where possible, contact initiator for information or clarification - Где возможно, обращайтесь к инициатору для получения информации или разъяснения Service request? - Сервисный запрос? Classification and initial support - Классификация и начальная поддержка Handling of service requests - Обработка сервисных запросов

Рисунок 3. Блок-схема обнаружения, самообслуживания и регистрации

Обнаружение

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

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

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

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

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

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

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

Дата добавления: 2015-10-29